Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>> 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-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++.



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.


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?


Nothing about that implies re-writing legacy code.


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.


Perhaps the reason they didn't see many C++ coders is because of this?


Because of what?


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.


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.


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.


Google themselves never were big Go adopters, the language adoption is mostly an external factor.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: