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.
