Mutability & concurrency, nils, interface casts -- these things all go against safe.
> Tell me again that there isn't good engineering behind Go.
You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good engineering" behind it. I don't understand how one leads to the other.
When so many mistakes and regressions go into a language, one shouldn't care that famous names are behind it.
> Go tackles newer problems in a newer way
Go is essentially Algol 69 with baked in concurrency syntax.
> Tell me again that Go is a regression from other programming languages
Losing null safety, sum types & pattern matching, parameteric polymorphism and type-classes, all form a huge regression in PL design from the state of the art.
You're thinking wrong. You're also proving the grandparent's point.
You're thinking in terms of "here's this set of bullet point features that I think a language has to have to be a proper, modern language." But the grandparent was asking you to consider that a different set of features might have value form some real-world problems that Go's authors had really bumped into. You reply, "Nope, couldn't have - it doesn't have my bullet point features!"
There are more things in programming than are dreamt of in your philosophy of what a programming language should be.
He said Go had something new to offer, and listed old things.
He said Go makes concurrency safe & easy, when Go emphasizes features that contradict safety and ease.
He said Go tackled problems in a newer way, when Go is really Algol69 + coroutines.
He denied Go regressing from other languages, when it throws away decades of PL research.
In none of this did he say "Here's an alternate set of features that ...". No. He said concrete, specific, wrong things.
What you are saying is a different thing -- and I also disagree with you.
These "bullet list" features weren't invented for the lols. They were created to solve real problems. Problems that Go doesn't have an alternate solution to.
Go programs dereference null. That is a bad thing. Languages with my "bullet point features" do not dereference null.
Go programs duplicate code to handle different types. Ditto.
Go programs can (and thus do!) mutate some data after it was sent to a concurrent goroutine. Ditto.
Go programs can cast down to incorrect types. Ditto.
The "bullet point features" are important. There are alternatives, but Go doesn't sport any of them.
None of the things you mentioned are new.
> Go makes concurrent programming safe and easy
Mutability & concurrency, nils, interface casts -- these things all go against safe.
> Tell me again that there isn't good engineering behind Go.
You seem to think that a language that has baked in syntax for concurrency, or that has famous people behind it necessarily has "good engineering" behind it. I don't understand how one leads to the other.
When so many mistakes and regressions go into a language, one shouldn't care that famous names are behind it.
> Go tackles newer problems in a newer way
Go is essentially Algol 69 with baked in concurrency syntax.
> Tell me again that Go is a regression from other programming languages
Losing null safety, sum types & pattern matching, parameteric polymorphism and type-classes, all form a huge regression in PL design from the state of the art.