3 ms·

> I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code Wh

> I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code What gave you that impression? I'd say approximately 0 people from the Go community and at most 2 people from Rust expected that.

npalli 2y ago
>> I'd say approximately 0 people from the Go community Quite literally that's what Rob Pike (golang co-creator) thought was going to happen https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
- sapiogram 2y ago
  The person I responded to said that "they expected everyone to jump on the bandwagon and abandon all their legacy code". That's not even close to what Rob Pike wrote on his blog.
  - UncleEntity 2y ago
    Perhaps the reason they didn't see many C++ coders is because of this?
    - sapiogram 2y ago
      Because of what?
  - pjmlp 2y ago
    Rob Pike literally wrote that, as the OP points out. What part of "Although we expected C++ programmers to see Go as an alternative" isn't clear enough?
    - sapiogram 2y ago
      Nothing about that implies re-writing legacy code.
      - pjmlp 2y ago
        Neither does this remark > I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code Abandon is not a synonymous with rewrite, last time I checked a dictionary.
- o11c 2y ago
  It really shouldn't be a surprise given that it took until 2022 to implement one of the basic features that everybody relies on constantly.
- nicce 2y ago
  Very odd to hear that from Golang co-creator. I don't really see how Go actually could compete with C++. Maybe in few cases, when people have accidentally chosen C++ incorrectly for their projects.
  - sapiogram 2y ago
    Definitely agree. My theory is that Rob Pike was mentally stuck in the 90s, when C++ was still a common choice for non-performance-critical entreprise code.
  - ncruces 2y ago
    It's odd because at Google people still write networked servers in C++, which I'd argue, almost no one outside Google does? Rob probably assumed Go could displace this. And it's not unreasonable to assume so, although it's closer to a better Java, than a better C++ for this. Instead it displaced Python for this (not for research/NumPy/Colab stuff), maybe some Java (where it's easier to containerize). And if it did displace C++, it was in greenfield projects, with non-C++ developers. So it didn't necessarily convert any C++ developers at all.
    - oddthink 2y ago
      There's just so much C++ at Google that really has no business being C++ and falls into the "networked server" category. At least large swaths of the Search and Maps codebase, large chunks of flume (beam) batch pipelines, etc., etc. It's only historical accident and network-effect stickiness that keep that from being written in Java. I could easily imagine him thinking Go could make inroads there. But then it took a very long time to get a flume port, and even then it didn't have half of the nice affordances that the C++ version did. People say they need the efficiencies of C++, but IMHO they really don't when so much of the actual code time is spent slurping data from one sstable and writing it to the next sstable.
    - pjmlp 2y ago
      Google themselves never were big Go adopters, the language adoption is mostly an external factor.

npalli 2y ago

>> I'd say approximately 0 people from the Go community Quite literally that's what Rob Pike (golang co-creator) thought was going to happen https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti... I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

sapiogram 2y ago
The person I responded to said that "they expected everyone to jump on the bandwagon and abandon all their legacy code". That's not even close to what Rob Pike wrote on his blog.
- UncleEntity 2y ago
  Perhaps the reason they didn't see many C++ coders is because of this?
  - sapiogram 2y ago
    Because of what?
- pjmlp 2y ago
  Rob Pike literally wrote that, as the OP points out. What part of "Although we expected C++ programmers to see Go as an alternative" isn't clear enough?
  - sapiogram 2y ago
    Nothing about that implies re-writing legacy code.
    - pjmlp 2y ago
      Neither does this remark > I feel like languages like Go and Rust didn’t become C++ killers because they expected everyone to jump on the bandwagon and abandon all their legacy code Abandon is not a synonymous with rewrite, last time I checked a dictionary.
o11c 2y ago
It really shouldn't be a surprise given that it took until 2022 to implement one of the basic features that everybody relies on constantly.
nicce 2y ago
Very odd to hear that from Golang co-creator. I don't really see how Go actually could compete with C++. Maybe in few cases, when people have accidentally chosen C++ incorrectly for their projects.
- sapiogram 2y ago
  Definitely agree. My theory is that Rob Pike was mentally stuck in the 90s, when C++ was still a common choice for non-performance-critical entreprise code.
- ncruces 2y ago
  It's odd because at Google people still write networked servers in C++, which I'd argue, almost no one outside Google does? Rob probably assumed Go could displace this. And it's not unreasonable to assume so, although it's closer to a better Java, than a better C++ for this. Instead it displaced Python for this (not for research/NumPy/Colab stuff), maybe some Java (where it's easier to containerize). And if it did displace C++, it was in greenfield projects, with non-C++ developers. So it didn't necessarily convert any C++ developers at all.
  - oddthink 2y ago
    There's just so much C++ at Google that really has no business being C++ and falls into the "networked server" category. At least large swaths of the Search and Maps codebase, large chunks of flume (beam) batch pipelines, etc., etc. It's only historical accident and network-effect stickiness that keep that from being written in Java. I could easily imagine him thinking Go could make inroads there. But then it took a very long time to get a flume port, and even then it didn't have half of the nice affordances that the C++ version did. People say they need the efficiencies of C++, but IMHO they really don't when so much of the actual code time is spent slurping data from one sstable and writing it to the next sstable.
  - pjmlp 2y ago
    Google themselves never were big Go adopters, the language adoption is mostly an external factor.