You can patch things up without breaking backwards compatibility.
But, going on a well-trodden path slower than the pioneers is not a big achievement.
But, going on a well-trodden path slower than the pioneers is not a big achievement.
Smart men learn from the mistakes of others.
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.
Nothing is perfect to begin with, and I think you could probably be a bit kinder to Golang here.
-- https://en.wikipedia.org/wiki/Green_thread
Also see https://stackoverflow.com/questions/5713142/green-threads-vs... , https://docs.oracle.com/cd/E19455-01/806-3461/6jck06gqe/inde... .
Sure, it may not be perfect, or as elegant as other languages, but it's consistent and predictable.
Reference for this?
>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.
> Fortunately, parametric polymorphism was not integrated into the Java Virtual Machine (JVM), so these examples do not demonstrate any unsoundness of the JVM.