> They got so much right from the start, then have managed to make consistent well reasoned, meaningful and safe improvements to the language over the years
In which universe? They have to constantly patch the language up and go back on previous assumptions.
Fast compiler, simple tooling, baked in fmt, simple cross platform compilation, decent standard library, a tendency towards good enough performance if doing things the Go way, async without function coloring. They got some things right and some things wrong. When tossing out orthodoxy, you’ll tend to get some things wrong. I think a lack of sum types is my biggest gripe.
The std library is a big part of the magic. It’s so shocking to go to JS land and see that there are 10 different 3rd party libraries to make http requests, all with wildly different ergonomics all within one code base due to cross dependency heck.
In Go there’s pretty much only the http package, and any 3rd party packages extend it and have the same ergonomics.
For a while my biggest gripe was package management but it’s a dream where we are now.
That's the first language change that can in theory break programs (in practice, it won't). Everything else was just additions to the existing language with full backwards compatibility. That's the opposite of constantly patching the language up.
Robert Griesemer, Rob Pike, and Ken Thompson are objectively smart men and pioneers and have learned from lots of mistakes both they and the industry made.
Go embodied a lot of those learnings out of the gate.
If the bar is to be perfect out of the gate that’s impossible and I can’t think of any language that could pretend to be so.
Go was very good out of the gate and has slowly but surely evolved to be great.
That's the embodiment of Go though; they didn't rush to implement generics because they didn't want to repeat Java's mistakes (just have a look at http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypePa...). They took their time with a module / dependency system to avoid the mistakes that NodeJS made. Every decision in Go is deliberate.
Sure, it may not be perfect, or as elegant as other languages, but it's consistent and predictable.
Generics made Java’s type system unsound due to an unanticipated edge case. The Go team got a bunch of top-class type theorists (e.g. Phil Wadler) to make sure that Go’s generics implementation doesn’t introduce a similar problem.
>just an academically interesting property - had zero real life impact.
Only because Java runs on the JVM, which preserves enough type information that an exception will be thrown if you try to treat a list of String as a list of Integer. In a language that compiles to native code with full type erasure, that could give rise to serious security problems.
You can just imagine what Go critics would be saying on HN if Go's generics implementation allowed that kind of thing to happen!
No, you need to go way way out of your way to make a real world example for that - otherwise it would have been discovered by a bug, not by academics. It’s similar to Java’s generics being Turing complete - cool, but you can never make use of that/write it accidentally.
I am not as inclined as you to think that accidentally creating an unsound type system is no big deal. Soundness is exactly the property that makes type systems useful. Note the adverb at the beginning of the paper’s abstract:
> Fortunately, parametric polymorphism was not integrated into the Java Virtual Machine (JVM), so these examples do not demonstrate any unsoundness of the JVM.
In which universe? They have to constantly patch the language up and go back on previous assumptions.