Indeed, Scala looks like a language research project, more like Perl and Haskell. You definitely can use all of them in production and benefit from that, but you need both mastery and restraint in using such a language.

Golang is the opposite: it takes the ideas from 1980s with some early 1990s (Pascal, Modula-2, Oberon; CSP; garbage collection) and executes them to near perfection. It even ignores some of the obvious faults in ergonomics (if (err != null) return err; everywhere) to keep things dead simple and reasonably performant. It's much harder to write incomprehensible code in Golang, even if you try, so lack of mastery and restraint would have much less catastrophic consequences than in a highly expressive language like Scala (or e.g. C++).

My issue with Golang is that I find my ability to write code to just takes so much longer (and often with more lines) than other contemporary languages like Swift. The rigidity is a double-edged sword.. it removes potential issues that could cause you to trip on yourself, but at the cost of productivity.

Maintaining Haskell code in my experience is s piece of cake. The community is really careful to avoid breaking changes, and when they can't be avoided, to introduce them in the most polite, gradual, convenient way possible.

Recent Javas made many QoL improvements to remove some of the complaints IMO. And there are more neat improvements coming (already there?) with 15 and 17.

Also, Kotlin is a rather nice and much less radical "better Java", well-supported, but mostly popular on mobile.

Kotlin is by far my favorite language-to-date. I moved my dev team to it years ago, it's all server side. We still have over a decade's worth of Java code to maintain, but anything new is in Kotlin (even in the legacy applications, we just add Kotlin). So nice. Makes me happy when other people get onboard and say "oooh yes, this is much better than our legacy Java". I was a HUGE Java proponent from 1999 to around 2010, when I started really getting annoyed that the language was missing so much that other languages had. Eventually we tried Scala, too complex to deal with in large teams to get everyone onboard, Clojure was a pain as everyone tried to be as clever as possible (and errors were awful, tooling was painful as not everyone wants to use emacs), then Kotlin came around and we never looked back.

Kotlin on the server is growing though and has the biggest library ecosystem to exist

Glad to hear this. There's really no reason it for it not to do well on the server.

Pattern matching is (will be) better implemented in Java. It's fully fledged compared to Kotlin's implementation.

When will the last-argument-as-block be implemented in Java?

This one brilliant feature allows for easy DSLs without macros, parsing, or otherwise introducing new concepts to the language.

The ironic thing is, Java now has records (case classes in Scala) and pattern matching (fully fledged Scala-like pattern matching is in the works). It's better designed than Scala, and will be faster due to better integration with the JVM.

> better designed than Scala

How so? Do you mean Java in general, or just the pattern matching part? Can you provide an example where Java is "better designed"?

Destructuring in Scala is allocation heavy, I expect it to be much lighter weight in Java.

Scala compiles to java bytecode. Scala can only be faster then Java, in that Scala can leverage all functionality of the JVM and on top provide extra smarts that Java cannot due to backwards compatibilty it has to offer.

This has never been true for non-native languages (Scala, Clojure, Kotlin, etc.) as far as I'm aware. They've always been slower. The JVM is designed with Java in mind and co-evolves with it.

One of the benefits of Scala's willingness to break bytecode compatibility all the time is that whenever Java/JVM implements a Scala concept, Scala switches to the Java method under the hood. Whenever the JVM gets Java-specific optimisations, Scala will use those. That's honestly pretty cool.

They have in practice been slower because they try to be higher level, more ergonomic languages than Java. There aren't many performance-first JVM languages yet I think (Fortress maybe? They cited JVM problems when they wrapped up though).