I'm happy to take a crack at Go and C++, but coming from Java it is totally impossible to decipher wtf is going on in Scala. Kotlin is better, but still pretty awful.

Also, devs who use Go and C++ usually have a good reason (embedded systems and such), but Kotlin and Scala use seems to be motivated mostly by vaguely hipster-y annoyance with Java 8. And, like, sure, if you are annoyed by Java 8 and then use a language designed to have nothing in common with Java 8 except that it can import Java libraries and run in the JVM... well, it's gonna be a pain in the butt for your colleagues who do Java all day. And some of them aren't going to make the effort to work with it.

> Also, devs who use Go and C++ usually have a good reason (embedded systems and such)

Just.. drop go from that. Go is closer to JS than to C++/embedded.

Go is great for CLIs and utilities. It compiles to native code, has a low memory footprint, and the source code is pretty readable even if you've never written Go before. And when it crashes you get a human-readable stack trace not just a core dump :)

But I've never seen a large-ish Go application that I didn't hate. Because, yeah, as you said, it's closer to JS in a lot of ways.

I meant it in the way that Go is not cut out for most embedded use cases due to having a fat runtime with GC.

It is ok for CLIs and small utilities, but I can’t really stand looking at it (they went with a type syntax that is neither C-like, neither Haskell-like and is absolutely unreadable to me, even though I can usually get the gist of any language from having seen my fair share of syntaxes).

All great points. Specially:

> Kotlin and Scala use seems to be motivated mostly by vaguely hipster-y annoyance with Java 8.

Now that I think about it they seem like Instagram of language/code/devs. Mostly obsessed on surface level, superficial syntax features. IMO it is great in same sense as cooking with meal kit cooking is superior to cooking with grocery shopping.

In my experience Scala is one of the most intuitive and coherent languages out there. Very hard to beat in those regards.

A tiny language with only a few, but powerful, features which can be used as building blocks to express even the most advanced patterns.

The problem are just the people "holding it wrong".

If you try to use it as Java++ Scala will be more cumbersome than Kotlin.

If you try to use it as Haskell this will become very painful quite quickly.

You need to use it as Scala… This means you need to embrace its features and philosophy. Just use the best parts of OOP and FP together!

> A tiny language with only a few, but powerful, features which can be used as building blocks to express even the most advanced patterns.

And yet from the scala 3 website itself :

> One underlying core concept of Scala was (and still is to some degree) to provide users with a small set of powerful features that can be combined to great (and sometimes even unforeseen) expressivity. For example, the feature of implicits has been used to model contextual abstraction, to express type-level computation, model type-classes, perform implicit coercions, encode extension methods, and many more. Learning from these use cases, Scala 3 takes a slightly different approach and focuses on intent rather than mechanism. Instead of offering one very powerful feature, Scala 3 offers multiple tailored language features, allowing programmers to directly express their intent:

> The problem are just the people "holding it wrong".

If enough people have the same problem with a programming language, at one point it become the problem of the language, not the people.

> Just use the best parts of OOP and FP together!

Assuming that one can cleanly extract the best part of OOP and FP without bringing the baggage of eiter. It's not clear to me that those part don't have a certain level of "contradiction" which leads to the whole beeing less coherent than just OOP or FP.

> most confusing and intuitive

unintuitive, perhaps?

+1