I did a lot of Scala some years ago and also ended up in sort of a ragequit. Nowadays I'm mostly doing Rust or Swift. Rust, of course, has a steep learning curve due to the lifetime & borrowing system. However, the errors are usually very easy to understand. In the rare case where they aren't, it is easy enough to figure out what's wrong by searching for the error message. One of the Scala issues I had was that the error was the compiler throwing up a stream of sigils because some generic requirement didn't hold and it was very very difficult to search for, let alone understand what was wrong. Granted, it's been almost 6 years since I stopped using Scala. The experience that broke me back then was trying to use Slick, a typesafe Scala ORM. I forgot the details but I remember it was astonishingly hard to use back then and I couldn't for the life of me tell what was wrong because the compiler error message was so cryptic.

The maintainer of Slick was in the last round of layoffs at Lightbend. Not sure who maintains Slick these days.

https://news.ycombinator.com/item?id=22854494

Yeah slicks errors were terrifying back in the days. They fixed both slick and scala to simply tell you which implicits were missing

Yeah, it has gotten tremendously better in the last couple years when it comes to cryptic compiler errors. But even then Slick was a particularly egregious example. I had many WTF moments using Slick a few years back.

I love Rust, but it always looks ugly.

It's the semantics that counts.

Wrote 100k+ lines of Scala, now write Rust. It's very different, Rust has much more noise (but I like Rust as a language a lot) and doesn't look beautiful.

In my little experience with rust, things can get ugly very quickly, but it depends very much on the task. I wrote a game server monitor, and a fairly extensive command line calculator in rust, and that code for all those looks quite fancy. I wrote a tool that converts a lexicon to a trie and one that can do error correction using that trie, and that has some quirks. I also tried porting an Earley parser from C, and that took a nasty turn, since it relies a lot on pointer sharing.

I have more experience writing in Go, and I think the code for all would look similar-ish. Go is a bit of a grey language, but it gets the job done without a lot of refactoring and restructuring.