3 ms·
That is an excellent comment. I wish I could give you a prize, but all I have right now is a banana. Every time somebody mentions the "C++ replacement" aspect,
by PopsiclePete 12y ago
That is an excellent comment. I wish I could give you a prize, but all I have right now is a banana. Every time somebody mentions the "C++ replacement" aspect, people freak out because you can't use Go to write Unreal Engine 6 in it.
There was a talk/video somewhere where Pike/Griesemer explained how it all started. They were waiting for some gigantic C++ project to compile on their compile farm and every compile took hours. So during one of these down times, they started shooting ideas back and forth of how to speed up compilation. Then they figured out it's easier to start a new language with simple parsing rules than to fix the mess that is C++ grammar.
That's really it - it started with a pain point about C++ compilation speed, not C++ performance.
- Jweb_Guru 12y agoI have mixed feelings about this. In one sense, it's actually pretty true that no new language has really been developed with compilation speed as its primary focus for ages. So in that sense I applaud Go for its dedication to that purpose. On the other hand, a language devoted largely to compile speed (and that's really the one unifying principle I've seen in Go's feature set, since I view "simplicity" as essentially arbitrary in a formal sense) might be a cool research language, but I wish Go did make a few concessions for the sake of productivity. There are some really fast ahead-of-time compiling variants of ML, like Poly/ML, and in the spirit of pragmatism I think Go could have settled for "fast enough" compilation instead and used well-known techniques like type erasure to basically get 'interface{} but with static checking' generics.