4 ms·

Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These re

Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type inference. Sad that after Java devs already recognized how bad inheritance is that Scala also got inheritance. The sticking out problems is how very very very slow Scala compiles. This makes web development (even with Play) and unit testing a huge pain (and the complicated syntax + implicits + type inference makes IntellJ as an IDE very very slow on detecting problems in your code) Concerning the article I do think Futures are a more powerful (and higher) concept compared to coroutines. They are easier to combine IMHO [2] Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin developers think Option is only about nullable Types (it's not and something differen!) and don't embrace it. [1] http://codemonkeyism.com/scala-unfit-development/ http://codemonkeyism.com/scala-unfit-development/ [2] http://codemonkeyism.com/a-little-guide-on-using-futures-for-web-developers/ http://codemonkeyism.com/a-little-guide-on-using-futures-for...

adriaanm 10y ago
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.
- _Codemonkeyism 10y ago
  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.
- _Codemonkeyism 10y ago
  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.
hota_mazi 10y ago
> 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.
- _Codemonkeyism 10y ago
  Nope.
jiaweihli 10y ago
If you ever find yourself working in JS and want Options, I've got you covered: https://github.com/jiaweihli/monapt https://github.com/jiaweihli/monapt
dragosiulian 10y ago
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 https://triplequote.com/hydra.html
realharo 10y ago
Is there something that you can express with Option that you cannot express with a nullable type?
- _Codemonkeyism 10y ago
  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.
  - realharo 10y ago
    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.
- aninhumer 10y ago
  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?)

adriaanm 10y ago

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.

_Codemonkeyism 10y ago
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.
_Codemonkeyism 10y ago
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.

hota_mazi 10y ago

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

_Codemonkeyism 10y ago
Nope.

jiaweihli 10y ago

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

dragosiulian 10y ago

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 https://triplequote.com/hydra.html

realharo 10y ago

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

_Codemonkeyism 10y ago
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.
- realharo 10y ago
  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.
aninhumer 10y ago
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?)