[throwaway34241]

I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense.

The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout.

Many of the design decisions make no sense without that context. Go can’t simply copy generics from Java or memory sharing from Erlang, since the design decisions made by those languages would introduce too much overhead in a language intended to be lower level. In a lower level language more aspects of how a program executes are specified explicitly, rather than accepting more overhead or guessing what a complex optimizer will do.

On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++.

I feel like a lot of HN commenters compare Go to higher level languages and find it lacking, which may be a fair assessment for certain problems but isn’t really understanding the niche it tries to occupy.

[rat9988]

> On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++.

That was not the initial team position. Their initial position was "why would you even need generics? Please provide us a usecase". They actively denied there was a need for generics.

[foldr]

>Their initial position was "why would you even need generics? Please provide us a usecase"

Do you have a source for this? It doesn't match my recollection. As I recall, the Go team always said that they may add generics in the future, but also that they would also like to see compelling use cases for it. That is not an unreasonable request.

[LaPingvino]

They have mentioned that you don't really need it as an explanation after they already said for a long time that they do consider it, from the start. They never strayed from that POV.

[saturn_vk]

This has never been the case, and stating it as a fact is a big lie

[kerkeslager]

Exactly.

[staticassertion]

How is Go lower level than C#?

[throwaway34241]

I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level.

There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc (unless C# added that recently).

Anyway I like both languages and I’m not trying claim one is better than the other, just trying to explain the design space Go seems to occupy.

[ptsneves]

We use go in an embedded Linux environment. I do C#for web stuff and it would never cross my mind to do c# in an armv7 Raspberry. Also what about cross compilation? The c# runtime is not easily available to use in embedded devices at least that i know of. With go you just set it to compile statically and set the arch target. I can deploy it as a single binary. Love it after years of maintaining cross tool chains.

[MobiusHorizons]

One major difference that makes Golang lower level is that it compiles to machine code for the target CPU arch/OS instead of bytecode.