4 ms·

> Go was trying to be a C++ replacement Let me amend that: Go was a replacement for C++ in a context where C++ was considered unfit and unsafe. Therein - I bel

by lloeki 12y ago

> Go was trying to be a C++ replacement Let me amend that: Go was a replacement for C++ in a context where C++ was considered unfit and unsafe. Therein - I believe - lies the source of the misconception: Go was made to fill a gap that people tried to fill with various languages they had at hand due to lack of a fitting language. It just so happens that C++ was the one used by Google in that case. IOW, Rust aims to be a C++ replacement while Go aims to be something that didn't really exist previously (at least not at this scale or in its entirety).

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 ago
  I 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.
en4bz 12y ago
I would agree with the statement that Go was intended to be used in situations where C++ was not necessary but I think Java or C# would have easily sufficed for these problems. The problem is that both Java and C# are controlled by Google's competitors (Oracle and Microsoft) which is why Go probably got the green light from management.

by lloeki 12y ago

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 ago
I 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.

en4bz 12y ago

I would agree with the statement that Go was intended to be used in situations where C++ was not necessary but I think Java or C# would have easily sufficed for these problems. The problem is that both Java and C# are controlled by Google's competitors (Oracle and Microsoft) which is why Go probably got the green light from management.