premium-concern

No, it has been worked the way GP wrote since approximately forever.

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).

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. Imagine what an economic benefit it would be for the populace if all those average middle-class Jane and John Does wouldn't have had their life shattered by addiction and instead would be holding down a steady job paying taxes.

Or imagine how much cheaper it would be if the US' reckless abuse of antibiotics in both humans and livestock wouldn't cause such a rise of multi-resistant strains of diseases.

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 prescription drugs to laypeople?

Agree with the GP. There is some massive Stockholm syndrome going on here.

Some countries have well-functioning health care systems since the 18XX, not just since the feel-good story of "Murica is subsidizing other countries because we are such a great nation" became a thing.

Working health care is not rocket science, but it looks like everything that doesn't fit the American narrative of exceptionalism is conveniently ignored these days.

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 concurrent Java collections disallow nulls. All the classes commonly used allow null, as well as the collection interfaces themself.

Java had the chance to address this with Optional, but they got the implementation of the null handling completely wrong. Now they are stuck with it, which caused an obscene amount of complexity in the new generics spec to work around it.

(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 being unable to tell whether the key didn't exist or if it was null. That's the single worst approach one can take.

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

  scala> Optional.of("Foo").map[String](str).map[Integer](num)
  res12: java.util.Optional[Integer] = Optional.empty

  scala> Optional.of("Foo").map[Integer](str.andThen(num))
  res15: java.util.Optional[Integer] = Optional[-1]

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.

  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 make an effort to learn more.

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.

Do you have an example of what broke between 2.11.7 and 2.11.8?

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 and have them "just work" regardless of whether they are implemented identical on each platform, or need specific variations to implement the expected features.

Neither JS/Node nor Java/GWT have that.

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.

I'm not the one being ignorant. See your other comment where you have been flat-out misinformed.

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.

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.lightbend.com/resources/case-studies-and-stories...

https://www.lightbend.com/resources/case-studies-and-stories...

https://medium.com/@kvnwbbr/transitioning-to-scala-d1818f25b...

I'd say this is blatant non-sense usually coming from people who lack any kind of experience in C++, Scala or both.

  (value, no error)
  (value, error)
  (no value, error)
  (no value, no error)

  (int64, error)

Either gives you exactly the two you want.

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)?

  Method count has nothing to do with size.

  Look at your own link: Java => 16,306 Scala => 67,608 (Already in multidex territory)

  And if you do grow an app past the point of being trivial as that example is Proguard 
  gains will not be nearly as drastic

You pay for exactly the stuff you are using, just like with every other library.

  Your measure of "how long it takes to pick up a phone" is far from scientific", but 
  to compare, not a single app[sic] non-trivial app I've worked on is so simple that 
  installing a fully compiled APK over ADB would be less than a 5-10 second process.

  That would leave 0-5 seconds for the entire app to build, proguard, and predex (with 
  multidex). Not possible.

  To me the proof is in the pudding, if there were real gains to be had with Scala it'd 
  have more traction than it does.

  Method count forces multidex insanely early into 
  development and for people who want the best UX that 
  alone is a show stopper.

Here is a data point from a small example app written in multiple languages: https://github.com/SidneyXu/AndroidDemoIn4Languages

If you need multidex (you probably don't), it's a single setting away.

  Very slow compiles (contrary to what you claim).

testQuick is also amazing as it runs only the tests that have failed, haven't run before or depended on code you just changed: http://www.scala-sbt.org/0.12.4/docs/Detailed-Topics/Testing...

  Language style encourages constructs that cause GC 
  spikes, closures are not low overhead

  SDK dependencies automatically meaning what? The thing AS 
  does for imports from AppCompat and co?

  Better instant run?

...

And then you have goodies like typed resources: http://scala-android.org/tips_and_tricks-typed_resources/

Or the automated Gradle config import which means you don't need to do configure anything except adding the plugin: https://github.com/scala-android/sbt-android/blob/master/GRA...

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!

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, ...

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 both.

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 might be slightly ahead. (If one can describe reference counting as "ahead".)

Same with Scala.

Except IDE and tooling support, maturity and stability, and you can't share any libraries between Typescript and C#.

In which sense?

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: Scala.js is stable, mature and production-ready. You can use it, save a lot of time, share a lot of code, use mny of the libraries you already know, enjoy great IDE and tooling support, use it in real projects and make money with it.