premium-concern

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.

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.

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.

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.

  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]

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.

Kotlin marketing != reality, it seems.

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.

A language limited to a level of advanced beginners is not necessarily bad, though.

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

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

  (int64, error)

Either gives you exactly the two you want.

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

Is everything perfect? No! Can you write stuff with it and have it work? Absolutely!

Deals with SDK dependencies automatically, typed resources and views, better Instant Run, ProGuard caching, extremely low overhead, fast compiles, ...

I think there is large audience of people who want the best OOP tools, or the best FP tools or both.

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

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.