[remus]

> It should be noted that "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project.

If we assume complexity ~= "takes up a significant part of the language spec, compiler, and VM" then I think it's an excellent reason not to include something! Somebody has to maintain this stuff and making it complicated makes that hard, which in turn means less time to spend on things like tooling, performance improvements and documentation which then makes our lives as users of the language harder.

Of course there is a trade-off here but I think, in general, the go team manage to strike a nice balance.

[nauticacom]

Right, but the entire point of my comment was that "takes up a significant part of the language spec, compiler, and VM" is not a good approximation of complexity. It can be related, but it is not necessarily true that something with a complex implementation has a complex interface.

[remus]

I think we are talking past each other a bit, as I completely agree with

> it is not necessarily true that something with a complex implementation has a complex interface.

In turn, my point is that as a language implementer you only have so much time available to work on the language and surrounding ecosystem. If your time is spent dealing with a complex spec, compiler and VM then you have less time to spend on the rest of the ecosystem. I think go has shown that spending tim on the surrounding ecosystem can be very valuable (e.g. go fmt, go vet and more recently go fuzz).

[nauticacom]

Ah, I understand now. That's a fair point! I agree that the excellent Go tooling is one of its strengths.