There have been some great improvements in Scala tooling in recent years. Li Haoyi talks about all these new tools in the Hands-On Scala programming book. Some specific responses:

* tooling for writing VSCode: the metals project is great: https://github.com/scalameta/metals

* NullPointerExceptions: those should be handled with Option/ Some / None

* the inability to enforce a coding style properly - scalafmt is great for this and provides a "Go-like" automatic formatting experience https://scalameta.org/scalafmt/

* SBT - there are now alternatives like Mill: https://github.com/lihaoyi/mill

Glad you're happier with Rust, but know that Scala is a lot better now if you ever come back ;)

I wrote Scala for three years or so professionally and agree with most of your points. A couple of comments though that haven’t been addressed by the sibling commenter who also addressed some of your points:

- JVM is JVM I guess. You either love it or you don’t. I personally really enjoyed the access to the ecosystem so that was a major boon for me.

- Gradle is just so much better than SBT in almost every way aside from simplicity. I found building Scala projects with Gradle to be quite straightforward and nearly every project that supports SBT also supports Gradle.

- I agree about VSCode tooling but I do want to establish that there are actually really nice tools for writing code in Scala - specifically Jetbrains is quite great. I am not saying your point is any less worthwhile, only that I don’t want someone to read your comment and take away that there are no good code assistance tools for writing Scala.

- Agree with the Java NPE’s. This is annoying

- Entirely agree with implicits. The Scala team either needs to better educate people on how to use them or just tell people not to use them unless it’s a very specific circumstance. I cannot tell you how many times I’ve dived into someone else’s code and spent literally hours trying to coax the compiler to do something that was bizarrely prevented by a poorly thought out usage of implicits.

- it is definitely possible to write “Scava”, and I wouldn’t really recommend a team adopting it without someone having at least a decent background in functional programming. Otherwise you might as well write Java if you are going to write imperatively.

- Yes, I find that the usage of symbols in Scala is a bit excessive, but once you learn what they do it does feel more terse and concise. It doesn’t stray into the illegibility of Perl IMO.

Overall it’s a nice language, fun to write in, but a bit frustrating at times. I wouldn’t use it personally at home but it does fill a nice niche professionally and it’s absolutely great for writing Spark code.

Yeah, the symbolic method names can be quite annoying and (often) make code unreadable. Especially ScalaZ went really overboard there.

I'm happy to say that the convention is becoming more strict in this regard and symbolic method names are (mostly) discouraged [0].

[0] https://docs.scala-lang.org/style/naming-conventions.html#sy...

- compilation time