Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language. For some, things like Kotlin hit a sweet-spot. One can lean a bit more into a functional style, or they can lean more into an OO style and it's acceptable. Some are very interested in thinking in terms of Functors, Applicatives, Readers, etc... some just want map/filter/reduce. That's what the Streams API did for Java devs. For me, Haskell isn't "the goal". It's simply one way of solving problem-sets.
The meaning of my message wasn't that everyone should move to a functional language, but that Java devs shouldn't. The language has some decent features. Under all the OO patterns and abuses of framework, there was a decent core to save. My issue is that the community has declined to write their own "Java - the good parts", and tried to bolt half a dozen pair of wings on their supertanker because planes are faster than boats.
As a java-turned-haskell-turned-java dev, I can enjoy some OO programing, even though I prefer FP, but I definitely don't enjoy unprincipled FP riddled with side-effects, null pointers and built upon the quicksands of frameworks that are thoroughly unfit for that purpose.
Kotlin doesn't get enough love. It gets derided by some Java developers for being too cutesy and sugary and it's not talked much about by the kinds of people who love to talk about Haskell, Lisp or Rust (no shade to these languages), but to me it's the most pragmatic language I've used so far.
Speaking as a lover of Scala who has seen Scala codebases go wrong in the cliché ways, Kotlin would be the first language I would consider if I were starting a new commercial software codebase today. Kotlin seems to have enough of the pragmatic elegance of Scala to get the job done with clarity and accuracy, without the curse of attracting the compulsive intellectual thrill-seekers that will ruin your Scala team if you accidentally hire one.
Compulsive intellectual thrill-seekers... while I never want to call names, this does seem to explain the phenomena quite well. There are just some people out there that need the world to know how smart they are.
Anecdotal: I do know one guy however who's just so ecstatic every time he figures new things out. To his way of thinking, everything that comes with "functional" truly is simpler. He built a dependency injector based on a Reader. He built a cool Result library where he managed to get at the internals of the JVM. Never once did he come off as holier than thou. I can appreciate and respect that.
IMO "compulsive" is the damning word there. People who don't enjoy learning typically don't make good programmers, but you have to show respect for your coworkers when you choose your learning opportunities.
This is exactly how I feel, having written tons of Scala, some Haskell and a multitude of other languages. It's why I recently decided to build most new, large projects with Kotlin at $job
I really liked Kotlin in the beginning, but it's error handling story is non-existent. They removed the ONLY decent (not great, very flawed) complier validated method for error handling, checked exceptions, and gave us nothing in return.
It'd be so easy to simply do exactly what Rust does. Kotlin already has the ADT stuff necessary, all we need is some kind of "bubbling" operator, like the ? in Rust. Because right now, it's all just super horrible manual checks everywhere.
Different strokes... I think Java checked exceptions are a design flaw and the fact that no other language that I'm aware of has them is telling. Maybe it even was a good idea in the beginning, but it was just horribly abused by basically every library under the sun - no, I don't want to catch some low-level exception when I'm calling your library, thank you very much.
I don't mind making error handling part of compile-time checking (as long as you can opt out by something like unchecked exceptions), but that should be done in a way that is compatible with the regular type system. That way you can abstract over error handling in ways that using checked exceptions disallows.
IIRC, the stance of the Kotlin team is that if you want compile-time checked error handling, you should use Result types. Maybe the ergonomics aren't as good as in Rust, but if you use something like arrow, they're still decent.
As someone that has done some Haskell, and does Java for a living, I think their metaphor is extremely accurate. It's not about purity, it's about how the functional parts were grafted onto the language, and therefore don"t "interop" with the classical ways very well.
In a good mixed paradim language like Rust, you can freely choose the correct paradigm for the problem, and can easily mix them. In Java, they are often at odds with each other. Best example is exceptions (esp. checked exceptions) and all Stream operations. They take a lambda which does NOT throw any exceptions. So, you need to either never use checked exceptions (which is impossible, because most libraries still do) or not use streaming, or create a horrendous hybrid.
This is a very solid counterpoint to my argument. The no throw in a lambda is a fairly nasty wart and should have been handled in a more conformant way.
To be fair, mixing higher order functions with effects (exceptions) is really hard without changing the type system completely. At that point you're moving into novel encoding territory.
> Perhaps, but what you may not understand is that not ALL developers _want_ a purely functional language.
The ability to use pure functions is one of those hills I'll die on. Hearing that not all developers want a purely functional language is like hearing not all surgeons want to wash their hands, or not all accountants want to use ledgers.
