Hacker News Reader

The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (towards a core that we can evolve much more slowly, and modules that can move more quickly, but where you can opt to stay with older versions as you prefer).

We've also invested heavily in incremental compilation in sbt. Sbt is meant for use as a shell, and it's super powerful when used like that. When I'm hacking the compiler in IntelliJ, recompiles of some of the biggest source files in the compiler (Typers.scala, say) take just a few seconds. I rarely have time for office chair sword fights anymore.

With Scala 2.13, half of my team at Lightbend is dedicated to compiler performance. We'll have some graphs to show you soon, but our internal benchmarking shows our performance has steadily improved since 2.10.

I still have the problem of upgrading because not all of the libraries are cross compile or do work. At the end of last year we've upgraded one library which cost us many days.

Next is upgrading Lift to 3.0 which will be a nightmare (again).

"We've also invested heavily in incremental compilation in sbt."

Yes, I read this over and over again, and I see micro benchmarks posted.

Using SBT with continuous unit testing I can't feel a difference - or it is so slow with a major code base that it's still much to slow and I judge it having no progress. Either way, after years it is still too slow (newest Scala + newest SBT).

"I rarely have time for office chair sword fights anymore."

Today I expect Kotlins practically instant compilation. 10 seconds for compiling some changed files is already to much for rapid development with TDD/Web, it breaks my flow, but YMMV.

"We'll have some graphs to show you soon,"

See above, I've seen dozens of micro benchmarks that claim improvements, in the end it doesn't show up in my real projects - at least in mine and the person who migrated to Go in the linked article. And all the other blog post authors that moved away from Scala towards something faster (Kotlin, Java 8, Go, ...)

But as I've said, I've moved on to Kotlin for new projects because for me Scala is a lost course.

Another site note: I would never argue with my users and tell them how wrong they are about the product and that their perception of the lack of some feature or quality is wrong.

The Scala compiler is indeed slow, mostly because it has to do a lot more work than the Java or Go compiler. However, in my experience Sbt's incremental compilation works well for small to medium sized projects. Beyond that we need a bigger hammer, and we're working on a parallel (and later, distributed) Scala compiler [1].

Full disclosure: I'm one of the founders.

[1] https://triplequote.com/hydra.html

> Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin developers think Option is only about nullable Types and don't embrace it.

Because Kotlin's native support for nullable types makes `Option` unnecessary.

Nope.

If you ever find yourself working in JS and want Options, I've got you covered: https://github.com/jiaweihli/monapt

Is there something that you can express with Option that you cannot express with a nullable type?

For me nullable type expresses something semantically different than Option. Option is a higher concept expressing optionality - duh ;-)

- contrived example - it might make semantical sense to express Option[Option[A]] as a type, it does not make sense to have wrapped nullable types (except as a result of nested function calls).

Nullable types feel like a bugfix to null, Options fell like a concept to model business domains. Same as None expresses something different (not there) than null (usually e.g. in Java conflating not there with not initialized).

With Option it also makes sense to have flatMap, for comprehensions etc.

I think you're only meant to use nullable types in Kotlin for exactly that purpose - expressing a value that may or may not be there (aside from the compatibility with Java libraries of course).

For things that just cannot be initialized directly in a constructor, you have more idiomatic constructs, such as the `lazy` property delegate, or in the worst case, the `lateinit` keyword (though at that point it may be better to rethink the design of your interfaces).

For indicating that an error occurred, you have exceptions.

There are many things you can express with ADTs that you can't express with nullable types, and once you have those, Option is simpler than extending the type system.

EDIT: Another thing you can do with Option is define generic abstractions that work on it and other types, like map/flatMap. This in turn means you can write generic functions over anything that can be flatMapped which work automatically for Options. (I don't know if there's anything equivalent in Kotlin though?)