Going from Java 8 to Scala was mind melting. Would never want to go back. Though I’ve heard later versions of Java are better. And katlin seems like an in between.
Or stick to kotlin and keep the mind conveniently solid ;)
I was one of the Bored Scala Crowd in the audience of a presentation by jetbrains people that must have been not too long after 1.0, took me half a decade to accept that a "poor man's scala" is actually the language that I want.
I found just the opposite. Kotlin would rather add 10 special cases than one higher-order abstraction; I'd rather learn one slightly fancy concept than a laundry list of ad-hoc cases.
That's actually a quite accurate description of my own feelings. "Why emulate parts of scala on syntax level when you can have the real thing?". But that "real thing" is the one that drives people to lose themselves in cats vs scalaz debates and the like, there's clearly something in scala that causes a very strong "if you use it to write java without semicolons you're doing it wrong" undercurrent. "java without semicolons" kotlin isn't considered good either, but the distance from there to "kotlin as intended" isn't big at all.
Regardless of programming language, every substantial software development needs to make
serious architectural choices, otherwise things will become messy.
I learned this the hard in my first programming job out of university. We were a C/C++ shop doing distributed software and
one question to decide right upfront is: shared memory vs message passing. Both have advantages and disadvantages, but don't mix well.
We started out with message passing, but over time somebody added POSIX shared memory as a performance hack (which two processes happen to run on the same machine).
Over time, we added a second, non-POSIX shared memory layer for performance reasons under Windows. It was an unmaintainable mess.
The core problem was that the CTO didn't understand distributed programming well enough to push back against those performance hacks. "How do you handle software architectural leadership?" used to be one of my replies to the inevitable "have you got questions for us?" in job interviews, when I was being interviewed. Now that I am making architectural decisions myself, I put a lot of efforts into this, for example building suitable linters that flag violations in code reviews.
If your team fights over cats vs scalaz or over Scala-as-OO vs Scala-as-FP then that's a sign that the technical / architectural leadership is weak. Choices like pure-OO vs pure-FP vs
mixing them require care, and are hard to change in-flight. If you have strong modularisation, you can successfully use different paradigms in different modules, but strong
modularisation needs care and architectural discipline, too. Part of the problem is that the style of programming that libraries like cats require (monads, functors, applicative, type-classes, HKTs) is not yet widely understood. This approach to programming needs its 'map/reduce moment' and become part of the mainstream introduction-to-programming curriculum. We'll get there, maybe in about a decade.
Yea, I'd imagine comparing a 9 year old version of a language to another would be "mind melting". And you are comparing to Java 8, from before Java re-organized their JEP process to ship features far faster, with a different release philosophy and feature roadmap.
Kotlin is worth picking up, but after seeing the speed at which Kotlin moves compared to how Java moves now, I don't think Kotlin will keep up long term.
(Unlike Haskell,) Scala does not force monadic composition on you at all. You can use Scala as a pure OO language, or for old-skool ML-like FP where you don't use monadic context abstraction. I've done both successfully in production. Indeed I strongly advise against a monadic programming style for programmers with a mainstream programming background (imperative and OO).
In my (considerable) experience of teaching programming, imperative programmers find jumping straight from imperative programmers to a monadic style extremely difficult, the more experienced, the more difficult.
