> I like to refer to it as Haskell with an extra chromosome: slow, hard to comprehend, and incredibly strong.

that's a weird and offensive thing to say

Didn't know that Scala was so easily offended. :D

It has one advantage compared to Haskell though: as a Java/Kotlin (or even Python or javascript) developer, you can start with it an be productive immediately. You can then slowly absorb new concepts until you are pretty much ready to write full-fledged Haskell.

That's why some call it Haskellator. :)

This also means that many codebases have different styles though, whereas in Haskell you have one style (FP).

More importantly, you can use the mature ecosystem around Java (tools, libraries and so on).

Then again, considering the JVM's disastrous recent trajectory (Loom, JPMS, renewed wasted focus on Java-the-language, and so on) that doesn't seem like such a great upside anymore.

Wat? How is the recent trajectory disastrous?

To take Loom as an example..

The primary problem with threads isn't their performance, but the way that they encourage bugs and race conditions by decoupling data access from flow control.

They're fine as a low-level API for implementing a more usable API, but not as the primary API that you expect application developers to use.

Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism?

And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking. Abstraction built on top of them will be easier to reason about, no callback hell, etc.

> Java/the JVM provides a low-level API for threads on top of which abstractions can be built. How do you think clojure implements their parallelism?

As I already wrote? But doing M:N scheduling at the JVM level (which is ultimately what Loom is) won't help your future (/promise) runtime which already implements a thread pool internally.

> And Loom will be absolutely killer feature, it’s not about performance, it’s about blocking.

If you like the blocking model and don't care about performance then you can go and use native OS threads in the same way right now.

M:N scheduling (including Loom) is ultimately about making threads cheaper to create, which means that theoretically you can have the "best" of both worlds (performance of futures, API of threads). My point is that this is a nonsensical goal, because the API of threads is awful.

> Abstraction built on top of them will be easier to reason about, no callback hell, etc.

Until you try to introduce concurrency, at which point you're back to the hellscape that is manual multithreading.

This seems to be more of a Java problem, not a JVM problem.

With version 3 it has another: Haskell doesn't yet have dependent types.

Hrm. Scala has had dependent types for quite some time.

Actually it appears to depend on your definition of dependent types. Scala apparently can't allow a type to depend on an IO-ingested value:

https://www.reddit.com/r/haskell/comments/ncaud3/scala_has_d...

Slow from a performance perspective, or to read and write code?

I meant slow to compile. Think runtime performance is pretty solid.

Or a lot less money :)