Erlang and Go are very different programming languages. They have a similar form of message passing, but the semantics are very different. Go's concurrency model still exists within a single process with a shared heap, which is very different to Erlang's model.
> it includes null references, also known as Hoare's Billion Dollar Mistake.
The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true.
> Ain't nobody got time for that — wait, what? Oh, Rust does?
Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust.
> ignoring the last 30 years of programming language research is not.
This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language.
Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives.
And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.
> it includes null references, also known as Hoare's Billion Dollar Mistake.
The very notion of null references being inherently bad is highly contentious. Just because someone gave an idea a catchy name, doesn't make it true.
> Ain't nobody got time for that — wait, what? Oh, Rust does?
Go and Rust have very different design goals. If you think Rust is more appropriate for you, use Rust.
> ignoring the last 30 years of programming language research is not.
This is a common refrain from Go haters, but it's really not true. Just because you don't do everything everyone else is doing doesn't mean you have ignored them. Go includes the language features we felt were necessary in a productive language.
Your comment frames Go as this language that thumbs its nose at a lot of good ideas, but the reality is that every design decision has tradeoffs. If you don't have null pointers or generics, then you need a more complex type system. The Go designers may not have made all the decisions _you_ would have made, but they were not made in ignorance of the alternatives.
And this leads back to the message of the original article: Go encourages the programmer to write simple code that is obviously correct. A more complex type system would detract from that goal.