I know on HN people like Scala but it's by far one of the language I hated the most when I worked with it. It's the complete opposite of Go, every time the Go team said no to a random feature, the Scala team said yes to that random feature. Scala feels to me like a kind of functional Perl.
The Scala team appear to have their hearts in the right place. They seek to empower their users and have respect for them. I can't really say the same about the Go team, based on at least one Google presentation I have seen. This isn't that surprising given the goals of the projects.
I did not want to start a flame-war Scala vs Go, it's just that I like Go simplicity & readability (I also like Python and Ruby for those reasons as well) whereas I'm not a huge fan of the Perl feeling of Scala.
When there's no ability in the language to abstract, there's no abstractions to learn, beyond what is built in. But this is not a blessing, it means we have to study every line of code and hope that we can uncover some emergent higher-level structure, if it exists.
> hope that we can uncover some emergent higher-level structure, if it exists.
That's exactly what I feel when I read Scala code, everything is a soup of custom operators, implicits and objects disguised like functions (or the opposite, you think it's an object but actually it's a function), it makes the code very hard to maintain and read. At least with Go, Python or Ruby your logic is in plain English, that makes it much easier.
I find the opposite. With Scala my logic can be plain English written in the language of the domain, because Scala makes it very easy to push out secondary concerns like authentication or audit logging or error handling out into the type system where they're still there, still managed, still checked by the compiler, still visible on mouseover/click-through in my IDE, but they don't have to obscure the straight-through happy-path business logic. Whereas in Go, all the secondary logic has to be right there, which clutters up the code and makes it harder to see the primary thread, and in Python or Ruby either you do the same thing or else the secondary logic has to work by invisible magic (metaclasses, exceptions, method_missing...) and you have no hope of ever being able to understand what's actually going on.
This is analogous to the tension between “worse is better” and “perfect is the enemy of good.” One the one hand, elegance is impossible and one must settle early on inelegance. On the other hand, elegance is possible but one must be clever and spend a lot of time looking for it. These trade offs are really apparent in competing language designs (Scala, Go) and it isn’t clear which ones are the better ones to make.
Right: phrased differently, weaker abstraction power means recurring problems have to be addressed by documenting patterns with fill-in-the-blanks recipes, instead of reusable code libraries.
You said [Scala] it's by far one of the language I hated the most. If you don't want to start a flame-war maybe you should change the tone of the comment.
I share the same opinion of Scala. It definitely feels like it has too many features and is too complicated.
Back in 2010 - 11, when I last worked with it, the compiler was also dog slow and IDE support was terrible. No doubt this has changed for the better, but it did ruin the language for me. I'll stick to Kotlin and Java, thanks.
Can you be specific? This is a popular meme but it doesn't match my experience of Scala's language features at all (indeed I'd say Scala is very good at pushing things out into libraries or composition of existing features rather than making them language features), and often I find people with this kind of complaint were actually using a library with poorly named functions and mistaking its features for language features.
I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them.
Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.
> I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them.
Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them - no language is impossible to write bad libraries in. Certainly I wouldn't ever want to go back to a language that uses magically-named methods for operator overloading, like Python and Kotlin do - I find that far more confusing, I can never remember whether a * b is calling a.__times__(b) or a.__star__(b) or something else. I could get behind a language that disallowed symbolic names entirely, but I don't think I've seen one of those since Java.
> Secondly, the implicit concept makes the code difficult to read.
IDE support has gotten a lot better now (green underline to highlight any implicit conversion, expand out implicit parameters) which makes them much easier to work with. If you only use implicits in cases where you otherwise wouldn't do anything in code at all, they enhance readability - but of course if you use them to replace things that you'd otherwise make explicit then they can reduce readability. I don't have a good answer, because I definitely want extension methods, typeclasses with derivation, and the magnet pattern, but I haven't yet seen a language design that makes those things possible while disallowing the bad uses of implicits.
most of these criticisms I agree with but I don't blame scala as a language for it. I write, and encourage my colleagues to write, code that is very easy to follow and reckon about. Few obscure operators, almost zero implicits....
They don't upgrade the open source version because their internal version depends on that open source version and they don't can't upgrade internally to 2.12.
They can't upgrade because of several dependencies of their own, the last one Finagle.
All of those although "cross compiles are no problem" as the default answer from the Scala development team on these issues.
