4 ms·

> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Apples to oranges. Rust is aiming

by azth 12y ago

> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Apples to oranges. Rust is aiming to be a C++ replacement.

en4bz 12y ago
Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...
- pcwalton 12y ago
  And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
  - en4bz 12y ago
    I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
    - pcwalton 12y ago
      The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out. A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.
      - CatDevURandom 12y ago
        edit: This wasn't a productive comment.
    - azth 12y ago
      > I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. I was following Go from the start, and I am aware of this fact. What I was pointing out is that they backed out of this claim eventually (event regretting using the term "systems programming language").
    - 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.
      - 12y ago
crawshaw 12y ago
Go has replaced C++ in my life. There are still jobs I have done in the past that would require C today, but they were never suited for C++. Specifically it was work for realtime systems that required a highly trustworthy compiler like CompCert, the likes of which did not (and I believe still does not) exist for C++.
nemo44x 12y ago
After using Rust I see no reason why C++ should exist any longer. Maybe in really limited embedded systems. Rust is so unbelievably safe to use in complex, efficient systems. Rust is, IMO, the state of the art in programming languages. Once you put the few months into actually getting OK at it you can write really great code, really fast and not be stuck with burdens since the compiler makes you write code that will work.
- deleted 12y ago
  [deleted]
- weland 12y ago
  > Maybe in really limited embedded systems. Given the incredible complexity of C++, I would much rather see Rust or Go come to those systems rather than C++.

by azth 12y ago

> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust. Apples to oranges. Rust is aiming to be a C++ replacement.

en4bz 12y ago

Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers. http://commandcenter.blogspot.it/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.it/2012/06/less-is-exponential...

pcwalton 12y ago
And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
- en4bz 12y ago
  I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
  - pcwalton 12y ago
    The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out. A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.
    - CatDevURandom 12y ago
      edit: This wasn't a productive comment.
  - azth 12y ago
    > I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this. I was following Go from the start, and I am aware of this fact. What I was pointing out is that they backed out of this claim eventually (event regretting using the term "systems programming language").
  - 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.
    - 12y ago

crawshaw 12y ago

Go has replaced C++ in my life. There are still jobs I have done in the past that would require C today, but they were never suited for C++. Specifically it was work for realtime systems that required a highly trustworthy compiler like CompCert, the likes of which did not (and I believe still does not) exist for C++.

nemo44x 12y ago

After using Rust I see no reason why C++ should exist any longer. Maybe in really limited embedded systems. Rust is so unbelievably safe to use in complex, efficient systems. Rust is, IMO, the state of the art in programming languages. Once you put the few months into actually getting OK at it you can write really great code, really fast and not be stuck with burdens since the compiler makes you write code that will work.

deleted 12y ago
[deleted]
weland 12y ago
> Maybe in really limited embedded systems. Given the incredible complexity of C++, I would much rather see Rust or Go come to those systems rather than C++.