[valenterry]

That's true. If you use a more restricted language, such as Go, then in does not happen so often that a developer chooses to (or even can) over-engineer something.

Unfortunately, at the same time it also takes away the power in situations where it should be used and where the benefits of abstraction overweigh the drawbacks. This then leads to repetitive and bloated code, runtime errors and all the problems that come from it.

Pick your poison...

[Cthulhu_]

Repetitive yes, bloated, not sure what you mean by it. But it's readable and maintainable, and will be that for the next decade, both by the original authors and the potentially hundreds or thousands that will follow.

With Scala, and I've worked with the language and some Scala oriented developers, I get the feeling that each individual developer styles themselves an artisan, and their code is not for the likes of mortals to comprehend.

I mean I kinda get it, it makes them feel smart and empowered and above the common Java developers and will probably earn them more money. Hell, I've been at one and heard of at least one other place where they decided for Scala not so much because it was the best language for the job, but because if they went with Java they would have to weed out 95% of applicants because they're mediocre - if you nab a Scala developer you know you've got someone from the top 10% at least.

I mean the one project failed and they went back to C# / .NET after a few years because they couldn't find developers and the other one probably muddles on because of sunk cost, but still.

[nikitaga]

Indeed, Scala code quality varies a lot based on developer / team / org. Code can be several different flavors of crap, but it can also be magnificently good in the hands of strong developers, and the quality is definitely scalable to team / org, with the right attitude and hiring practices.

Thankfully the Scala teams I worked on have been great, and to be fair the issues we did encounter were mostly from developers having little Scala experience being lost without mentorship. I'm yet to encounter the stereotypical overengineers or FP nazis, I think the fashion for those attitudes might be more in the past these days.

[valenterry]

What I mean with bloated is that Golang has great limitations in how flexible the syntax is. This is not inherently bad, but it causes bloat. Scala on the other side is very flexible on the syntax side, but that causes a steeper learning curve to some degree, both in general for the language but also each time this flexibility is used.

A simple example would be datetimes. Let's say you have a Datetime library and you have to write "currentTime.plusMinutes(1).plusSeconds(5)". In Scala you can adapt it to be able to write "currentTime + 1.minute + 1.second" without even changing the original library, for better or worse. In Golang you cannot, for better or worse.

> But it's readable and maintainable, and will be that for the next decade

Well, you could say the same about Scala. The thing is: each line of Golang-code might be easy to understand and readable. But in the end what matters is the understand the whole system or at least the part where you need to make a change. And while in Scala you pay the price of a much steeper learning curve, you also have the benefit of more concise code (see example above) which makes understanding the whole picture easy, even if every single line is harder.

But as I said, not only does it not come for free because of the learning curve. The freedom and power also can cause problems when it used correctly, so it also requires greater discipline than, say, Java or Golang.

> With Scala, and I've worked with the language and some Scala oriented developers, I get the feeling that each individual developer styles themselves an artisan, and their code is not for the likes of mortals to comprehend.

Unfortunately it is hard to tell if that is because you were not experienced enough in Scala at that time, or if someone really just messed up and abused the language (it definitely happend, even more so in the past).

> I mean the one project failed and they went back to C# / .NET after a few years because they couldn't find developers and the other one probably muddles on because of sunk cost, but still.

Yeah, you can't scala a Scala project to the next Google. That's not gonna work. But then again, I think that it makes perfect sense to have multiple languages, even in the same company. People who start out might want to use go because it's easy to learn it and get started (and still has some strong points for certain concurrency problems etc.). Eventually you want to move on and go for Rust or Scala or others. And even then, some people just prefer dynamic typing, some prefer static typing, just like some prefer pizza and some prefer pasta.