Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
premium-concern
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
1.
▲
by
premium-concern
10y ago
No, it has been worked the way GP wrote since approximately forever.
2.
▲
by
premium-concern
10y ago
True in the sense that Scala has a magnitude higher number of repos, commercial adoption, libraries, than F# (while being much closer to ML than F# in a few important was).
3.
▲
by
premium-concern
10y ago
Every dollar earned by advertising prescription drugs to the general population is a dollar that shouldn't have been earned in the first place. See the Opioid epidemic that is still taking lives in the US for more than 20 years. Imagin
4.
▲
by
premium-concern
10y ago
> But if their revenue levels in the U.S. were at the level they are in Europe, they absolutely could not justify their enormous fixed costs. Maybe the public could help them substantially lower the costs by not allowing to advertise pre
5.
▲
by
premium-concern
10y ago
So you blame Scala both for Java's mistakes as well as addressing them, while Kotlin, which doubles down on Java's poor decisions does everything right? This makes literally no sense at all. Also, only a few of the newer concurren
6.
▲
by
premium-concern
10y ago
> (Option, nullable return value, and throw an exception if not found) Which Map are you talking about? I don't see the method that returns nulls for missing values. > Kotlin has only single way. ... with the nice side-effect of
7.
▲
by
premium-concern
10y ago
Consider two functions (excuse my Scala): val str: Function[String, String] = s => if (s.length > 3) s else null val num: Function[String, Integer] = s => if (s == null) -1 else s.length With Optional, you receive differe
8.
▲
by
premium-concern
10y ago
> Also, Optionals are a light introduction to functors which is nice. Optional is not a functor, in fact it violates the functor laws quite blatantly.
9.
▲
by
premium-concern
10y ago
This problem was coined by Paul Graham as the "blub paradox": you can only notice inferior languages, abstractions and paradigms to what you currently know, but you can't easily notice superior ones, unless you mak
10.
▲
by
premium-concern
10y ago
Someone measured it and and it is fact it's substantially slower than Scala: https://twitter.com/kmizu/status/817570546179194881 Kotlin marketing != reality, it seems.
11.
▲
by
premium-concern
10y ago
Do you have an example of what broke between 2.11.7 and 2.11.8?
12.
▲
by
premium-concern
10y ago
In my experience Scala(.js) works way better than "(node -> JS, Java -> GWT, etc)". There is a large gap between those and the way Scala _just works_ across platforms. The huge difference is that you can depend on libraries
13.
▲
by
premium-concern
10y ago
That says more about your preferred language than the listed concepts. A language limited to a level of advanced beginners is not necessarily bad, though.
14.
▲
by
premium-concern
10y ago
I'm not the one being ignorant. See your other comment where you have been flat-out misinformed.
15.
▲
by
premium-concern
10y ago
If all you found was an old API from half a decade ago that doesn't even exist anymore, than I think that's a pretty good case for Scala.
16.
▲
by
premium-concern
10y ago
> theoretically capable of supporting even banks https://scala.epfl.ch/ > The examples you mentioned are relative small. You know what's big? Walmart. WellsFargo. Honeywell. Novartis. https://www.light
17.
▲
by
premium-concern
10y ago
I'd say this is blatant non-sense usually coming from people who lack any kind of experience in C++, Scala or both.
18.
▲
by
premium-concern
10y ago
(value, no error) (value, error) (no value, error) (no value, no error)
19.
▲
by
premium-concern
10y ago
(int64, error) gives you exactly four possibilities. Either gives you exactly the two you want.
20.
▲
by
premium-concern
10y ago
cringe . How ecactly is having to check twice the amount of cases an improvement (note btw, that checking for Left/Right is doing it wrong)?
21.
▲
by
premium-concern
10y ago
Method count has nothing to do with size. Nobody ever said that. It should still be obvious though that 30kB can't even remotely fit the method overhead you are claiming. Look at your own link: Java => 16,306 Scala =>
22.
▲
by
premium-concern
10y ago
Method count forces multidex insanely early into development and for people who want the best UX that alone is a show stopper. That's a complete non-problem. Minimal overhead of Scala is 30kB (see http://scala-
23.
▲
by
premium-concern
10y ago
Scala-Native has already a sizable community around it. It got almost 100 PRs shortly after it was published. Is everything perfect? No! Can you write stuff with it and have it work? Absolutely!
24.
▲
by
premium-concern
10y ago
How? Even the tooling seems to be vastly superior to the Gradle one. Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...
25.
▲
by
premium-concern
10y ago
Scala was designed to provide the best of OOP and the best of FP, without adding cruft or having multiple non-orthogonal features of one concept. I think there is large audience of people who want the best OOP tools, or the best FP tools or
26.
▲
by
premium-concern
10y ago
I don't think it is vastly different from Swift. In Scala the language is stable, the std lib is stable and the runtime is being worked on, in Swift the language is changing heavily, the libraries are under development, but the runtime
27.
▲
by
premium-concern
10y ago
Same with Scala.
28.
▲
by
premium-concern
10y ago
Except IDE and tooling support, maturity and stability, and you can't share any libraries between Typescript and C#.
29.
▲
by
premium-concern
10y ago
In which sense?
30.
▲
by
premium-concern
10y ago
Then use Scala! You almost never need to deal with Java except if you want to. Plus, unlike C/Ruby/Python/.NET you get a JS backend that actually works¹ (unlike mess like GWT, or various other languages). ¹ In the sense of: S
More ›