[Cthulhu_]

They all CAN be complex, but I feel like Scala was designed to BE complex, to give a developer as many tools as possible to write complex code. Contrast this with Go which was designed to be simple, to give developers few options and few points of contentions. And it's not just the language, but the mindset of the developing community.

I mean in a future release of Scala, they will add generics - that, combined with higher-order functions, will allow for functional programming constructs like Option and operations like map, filter, etc - those are already possible, but the function they operate on has to be declared for every type.

But while that has really taken off in some languages and environments, it's heavily discouraged in Go - the runtime is not designed for it, it can't cleverly unroll and optimize it, and the function call overhead will make its performance terrible compared to a regular loop.

TL;DR while it is or will be possible, it conflicts with the principle of least power described here, and a number of e.g. Go proverbs and other wisdoms.

[dhconnelly]

Yeah, no argument there. And I definitely like the Go community’s tendency towards straightforward code. But even there (among less Go philosophy-minded engineers, possibly) I’ve seen crazy abstractions built using interface{} that didn’t need that kind of generic code for the use case. Another one in Go is the nil/interface type interaction, for example. And this kind of thing can be hard to reason about, and that’s what I’m trying to say. All the languages have these complex and tricky bits and it’s best to stay away from them unless truly necessary.

[nikitaga]

> I mean in a future release of Scala, they will add generics

This is a typo, the great old one meant to say Go, not Scala.