|
|
|
|
|
by kerkeslager
1124 days ago
|
|
> It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do? 1. Yes, we didn't see a massive regression in compiler performance. Which begs the question why they didn't benchmark the options to see that might be the case. 2. Circumstances didn't change. The options for how to implement generics are roughly now what they were in 2009. What we need from languages in Go's sphere, is roughly the same as well. 3. What would I have done? a) Benchmark before making claims about speed. b) Assess features from other languages to see what works and what hasn't (literally nothing about the problems with lacking generics was unforseeable--I was talking about them early on and I'm not some sort of prophet). c) Admit rejecting generics was a mistake instead of pretending they were part of the plan all along. |
|
In terms of changed circumstances, obviously something caused them to spend the time and effort to get it done. Maybe they thought modules were more important? Features don’t just magically appear, they need resourcing. The rest of your points are asinine. You mention benchmarking twice which begs the question, how did they maintain good compiler performance for all these years? Was it just luck?
This feels a lot like those conversations where the winners get what they ostensibly wanted, but then they want a pound of flesh to go with it. If you don’t like Go then use something else. The world is full of wonderful programming languages.
[0] https://go.dev/blog/slices