5 ms·

If you like Haskell but want something else, you really should consider Scala. It's not the same. But it has many of the same niceties around the rich type sys

If you like Haskell but want something else, you really should consider Scala. It's not the same. But it has many of the same niceties around the rich type system, but with generally good tooling, the amazingly rich JVM ecosystem (tooling, libraries, learning materials), and a somewhat more pragmatic bent to it. Scala has a bad rep, justifiably so, due to a lot of its problems in the past: community, libraries, tools, etc. But many of those past problems are much better today. Scala today is a much better platform than it was at peak-hype circa 2015, despite some ongoing warts. Nowhere near perfect, but pretty good overall I see people in the comments looking for a "better OCaml" or a "industrial Haskell", those folks should definitey try Scala

urthor 3y ago
I find the issue is most of the niceties are also built into Rust. Scala's perfectly good though, there's very little to complain about.
- paulddraper 3y ago
  JVM debugging+monitoring is leagues better
paulddraper 3y ago
Scala 3 was a massive step forward. Though for whatever reason it seems that its popularity is declining. [1] [1] https://twitter.com/jdegoes/status/1656566825356754945 https://twitter.com/jdegoes/status/1656566825356754945
- wavemode 3y ago
  Because Scala 3, as great as it is, has fractured the community and caused a lot of churn. Twice, just in my recent job history, have I worked for companies that were using Scala 2 for a long time but are now deciding to develop new projects in Java and/or Kotlin instead.
  - kagakuninja 3y ago
    I think that is less about Scala 3, and more that the companies were not committed to the use of Scala, and would eventually move to some other flavor of the month language, such as Go or Rust. The transition to Scala 3 at my current job has not been an issue. Scala 3 is mostly the same language, with some nice new features which are optional. Our old projects are still on Scala 2, as there isn't a huge benefit from upgrading. The main downside in upgrading was library support, but we are now 2+ years since the release of Scala 3, the issue is mostly solved unless you depend on unmaintained libraries.
    - chriswarbo 3y ago
      Library compatibility was preventing us upgrading from 2.12 -> 2.13; Scala 3 wasn't even on our horizon :(
      - kagakuninja 3y ago
        By contrast, over the last 8 years I've migrated a number of small micro services up from every version of Scala since 2.10 with no problems, maybe some minor dependency hell with some of them. I've even upgraded a simple project to Scala 3 with no code changes. It depends on what libraries you use. The big hurdles tend to involve macros and Spark.
otter-in-a-suit 3y ago
I agree. Scala is actually usable for real-world use cases on a much broader scale, simply by virtue of being on the JVM. I wrapped some of the (unergonimic-because-code-gen'd) AWS libraries in cats-effect just the other day, matter of fact. Some of the native libraries do suffer from this "stylistic neophilia" too, imo, but maybe not to the same degree as Haskell. Also, Scala 3 made a lot of great improvements, although the tooling and library support arguably regressed w/ IntelliJ (I assume that's temporary) and some of the (on paper) positive changes - especially the whole type class derivation topic - make older articles and books _very_ confusing for people just getting into the language. I'd say making that migration happen in larger code bases and companies will continue to be a real-world challenge, but hopefully in the shape of a one-time effort, rather than constant changes. Also, based on the username, I assume that the parent comment is by Li Haoyi. Funny how small the scala world is - I tend to see the same names (you, Alvin Alexander, Gabriel Volpe, John A De Goes) over and over. :)
jsbg 3y ago
I found Scala to be missing too much of what I liked about Haskell. If I'm gonna lose out on the niceties that are unique to Haskell, then I'd rather go with something more pragmatic, like Kotlin.
foderking 3y ago
...or f#, which is actually the "better ocaml"
reidrac 3y ago
Scala has mostly all the issues the post is discussing. Perhaps once you're on Scala 3 you're going to enjoy stability, but your dependencies most likely won't give you that. And the JVM, and compilation times, and poor Scala 3 support on editors / IDEs. I prefer the Haskell tooling TBH.
- yw3410 3y ago
  The Scala community is incredibly committed to stability; every open source maintainer I know of in that space checks for binary compatibility when releasing as well as cross-compiling for multiple targets (Node, Web, Native) and versions.
  - valzam 3y ago
    The problem with scala is that the core devs seem to be working against what the community wants. At it's core it's still a research platform for many and it shows in the priorities for what gets included in Scala 3. Also while individual open source libraries are generally very stable and high quality the overall ecosystem is very fragmented and there is lots of churn (cats vs zio holy wars etc.).
chriswarbo 3y ago
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.

urthor 3y ago

I find the issue is most of the niceties are also built into Rust. Scala's perfectly good though, there's very little to complain about.

paulddraper 3y ago
JVM debugging+monitoring is leagues better

paulddraper 3y ago

Scala 3 was a massive step forward. Though for whatever reason it seems that its popularity is declining. [1] [1] https://twitter.com/jdegoes/status/1656566825356754945 https://twitter.com/jdegoes/status/1656566825356754945

wavemode 3y ago
Because Scala 3, as great as it is, has fractured the community and caused a lot of churn. Twice, just in my recent job history, have I worked for companies that were using Scala 2 for a long time but are now deciding to develop new projects in Java and/or Kotlin instead.
- kagakuninja 3y ago
  I think that is less about Scala 3, and more that the companies were not committed to the use of Scala, and would eventually move to some other flavor of the month language, such as Go or Rust. The transition to Scala 3 at my current job has not been an issue. Scala 3 is mostly the same language, with some nice new features which are optional. Our old projects are still on Scala 2, as there isn't a huge benefit from upgrading. The main downside in upgrading was library support, but we are now 2+ years since the release of Scala 3, the issue is mostly solved unless you depend on unmaintained libraries.
  - chriswarbo 3y ago
    Library compatibility was preventing us upgrading from 2.12 -> 2.13; Scala 3 wasn't even on our horizon :(
    - kagakuninja 3y ago
      By contrast, over the last 8 years I've migrated a number of small micro services up from every version of Scala since 2.10 with no problems, maybe some minor dependency hell with some of them. I've even upgraded a simple project to Scala 3 with no code changes. It depends on what libraries you use. The big hurdles tend to involve macros and Spark.

otter-in-a-suit 3y ago

I agree. Scala is actually usable for real-world use cases on a much broader scale, simply by virtue of being on the JVM. I wrapped some of the (unergonimic-because-code-gen'd) AWS libraries in cats-effect just the other day, matter of fact. Some of the native libraries do suffer from this "stylistic neophilia" too, imo, but maybe not to the same degree as Haskell. Also, Scala 3 made a lot of great improvements, although the tooling and library support arguably regressed w/ IntelliJ (I assume that's temporary) and some of the (on paper) positive changes - especially the whole type class derivation topic - make older articles and books _very_ confusing for people just getting into the language. I'd say making that migration happen in larger code bases and companies will continue to be a real-world challenge, but hopefully in the shape of a one-time effort, rather than constant changes. Also, based on the username, I assume that the parent comment is by Li Haoyi. Funny how small the scala world is - I tend to see the same names (you, Alvin Alexander, Gabriel Volpe, John A De Goes) over and over. :)

jsbg 3y ago

I found Scala to be missing too much of what I liked about Haskell. If I'm gonna lose out on the niceties that are unique to Haskell, then I'd rather go with something more pragmatic, like Kotlin.

foderking 3y ago

...or f#, which is actually the "better ocaml"

reidrac 3y ago

Scala has mostly all the issues the post is discussing. Perhaps once you're on Scala 3 you're going to enjoy stability, but your dependencies most likely won't give you that. And the JVM, and compilation times, and poor Scala 3 support on editors / IDEs. I prefer the Haskell tooling TBH.

yw3410 3y ago
The Scala community is incredibly committed to stability; every open source maintainer I know of in that space checks for binary compatibility when releasing as well as cross-compiling for multiple targets (Node, Web, Native) and versions.
- valzam 3y ago
  The problem with scala is that the core devs seem to be working against what the community wants. At it's core it's still a research platform for many and it shows in the priorities for what gets included in Scala 3. Also while individual open source libraries are generally very stable and high quality the overall ecosystem is very fragmented and there is lots of churn (cats vs zio holy wars etc.).

chriswarbo 3y ago

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.