[jonlawlor]

I don't think that Go is a good language to compare with Scala. (I do like Go, though.) The two languages could not be more different in philosophy. Scala is maximalist - you can do things many ways, you can call java, you can have tremendously intricate types, etc. Go is minimalist - there are just enough tools to get by, and sometimes it feels like you are missing one. My experience with Scala is that you spend more time telling it what to do but not how to do it (and it is often not obvious exactly how things will be done), while in Go you have to tell it both what and how to do things, which results in longer code, and repetition, but less ambiguity. You can't add to Scala to make it more like Go - the only way to make it more Go-like is to remove from it, which is impossible.

I think a more appropriate comparison for the language would be F#, which is probably not a surprise to you. I have never used Scala professionally, so I can't give any suggestions that would improve the use of Scala for day to day programming. Years ago I was learning 1 language per year, and picked up Scala and F# that way. After completing the Coursera courses on Scala, I put together a few projects on github using it, enough to get some job feelers that ignored my "don't send me job offers." And I realized that while I enjoyed fiddling around with the language on my own, I didn't want to spend my professional time deciphering other people's Scala code, and so I dropped it. Take from that what you will - maybe I am just not cut out for it.

I do use Go professionally, although it is a minority language where I work.

[adriaanm]

Thanks for your balanced reply. Sadly, some people see it as a badge of honor to write super clever code that's essentially write-only, and Scala somehow triggers this in them :-)

We, as the Scala community, play an important role in shaping the culture of programming in Scala as one that embraces simplicity as the true elegance, maintainability and testability, friendliness and openness to criticism. The language will remain flexible (though we're always looking to remove warts), it's really up to your company culture to decide how to use it (which is different for different teams over time).

Many big players, such as Twitter, have done a great job with that (and continue to do so).

[jonlawlor]

Yes maybe some of the success stories regarding changing from X language to Go are actually because Go enforces behavior at the language & tooling level that could potentially be enforced culturally at the company, but for whatever reason, the company has not been able to develop. Kind of, "if you don't play well with your toys, we take them away," instead of teaching them to play well from the start. When you're just a senior developer, you probably can't change the culture but you might be able to change the language for some applications.

There is the old jeremiad to not use technology to fix cultural problems, but when you're just a part of a much larger institution that may or may not have the ability to intentionally change its programmer culture, it can make a lot of sense to move to a language that reduces your reliance on those cultural behaviors if they are lacking.

Some of that could be addressed automatically in Scala with code standards enforcement like with scalacheck. And you can help with good practices like code review or pairs programming. But in a lot of places there is no appetite for "wasting time" on stuff like that (I vehemently disagree with that kind of attitude, but changing other people's view is not easy).

The advantage of Go is that left to their own devices, people will tend to gravitate towards more readable code, in a standard format, using standard tools that are pretty good in most situations. The entropy of having a bunch of people work on a project will then work in favor of coherent approach and style, instead of tending to diverge into using the tools they like best in the format they prefer.