8 ms·

Due to Scala's JVM heritage, it takes some discipline in order to have confidence in Scala code (e.g. that it won't throw exceptions, or return nulls, or do wei

Due to Scala's JVM heritage, it takes some discipline in order to have confidence in Scala code (e.g. that it won't throw exceptions, or return nulls, or do weird type casts, or overflow the stack, or have spooky action-at-a-distance, or have race conditions, or do inexhaustive pattern-matches, or not actually accept/return the types in its signature, etc.). This can be a tall order for shops which have a Java background (e.g. my last job used Scala extensively, but most had a Java background and treated Scala like a different syntax for Java; I had written more Haskell and ML, and treated it like an ML with JVM-gotchas). I highly recommend turning on all the scalac -Xlint options, using other linters like WartRemover, and treating the warnings as errors (annotations can silence the rare cases of "I know what I'm doing"; but there had better be a comment with a good justification, if you want it to pass code review!) Whilst it's nice that there are loads of Java packages to import and use from Scala, it's usually a good idea to encapsulate them in a more "Scala-friendly" wrapper; e.g. to replace exception-throwing with `Try`, `null` with `Option`, etc. in order to maintain confidence in our code. With a little thought, and a sprinkling of Scala features (e.g. `lazy val`, by-name parameters, implicit arguments, etc.) such wrappers can end up being much easier to use than the original, too!

theCodeStig 3y ago
This exactly. The Scala community caters a lot to JVM/Java inter-op, and to recruitment of Java engineers. In the peak-hype days, Java compatibility, and Scala for Java engineers learning resources were a huge selling point for Scala. Now it is one of its greatest weaknesses holding it back. Even as late as June 2023, the second edition of Functional Programming in Scala is catered toward Java programmers. Functional purity is an option in Scala (no pun intended), and the org/team must have the collective discipline to write pure code in-order to make it work. Pure/lazy effect handling is not included, one must use a 3rd party library. There should be one, or a small handful of compiler options which would enforce purity by the compiler. There isn't. The -Xlint options are not easily discoverable. WartRemover is a 3rd party library, which doesn't get enough visibility. Some of the "good stuff" from Typelevel should be absorbed into the standard lib. The numeric types are not ergonomic, there is no natural number type for example. I haven't had issues with Haskell tooling, though I also use Nix. On the flip side, I've never heard anyone say "I love SBT". Yes there are alternatives to SBT (Mill for example), but again they suffer from low visibility. Martin Odersky has admitted faults with SBT, and praised Mill; yet, what does the Scala community push... SBT.

theCodeStig 3y ago

This exactly. The Scala community caters a lot to JVM/Java inter-op, and to recruitment of Java engineers. In the peak-hype days, Java compatibility, and Scala for Java engineers learning resources were a huge selling point for Scala. Now it is one of its greatest weaknesses holding it back. Even as late as June 2023, the second edition of Functional Programming in Scala is catered toward Java programmers. Functional purity is an option in Scala (no pun intended), and the org/team must have the collective discipline to write pure code in-order to make it work. Pure/lazy effect handling is not included, one must use a 3rd party library. There should be one, or a small handful of compiler options which would enforce purity by the compiler. There isn't. The -Xlint options are not easily discoverable. WartRemover is a 3rd party library, which doesn't get enough visibility. Some of the "good stuff" from Typelevel should be absorbed into the standard lib. The numeric types are not ergonomic, there is no natural number type for example. I haven't had issues with Haskell tooling, though I also use Nix. On the flip side, I've never heard anyone say "I love SBT". Yes there are alternatives to SBT (Mill for example), but again they suffer from low visibility. Martin Odersky has admitted faults with SBT, and praised Mill; yet, what does the Scala community push... SBT.