4 ms·

That is taken out of context. Practically all Google server code is written in C++ or, at a much smaller scale, Java. Go is used for logs analysis, internal s

That is taken out of context. Practically all Google server code is written in C++ or, at a much smaller scale, Java. Go is used for logs analysis, internal services, monitoring and automation, etc. Nobody at Google reaches for Go when they are thinking of high performance nor would anyone try to optimize a large service in Go. They would just write it in C++ instead as soon as it starts to cost non-trivial amounts of money. Remember that Pike wrote Sawzall and Go replaces it, in a similar role.

skybrian 7y ago
Hmm, that seems a bit exaggerated. I seem to recall someone on the Go team describing the rewrite of a server that was originally in C++ and became much faster. (Largely because it started out at a heap of legacy code that was neglected for years.) That's probably pretty unusual, but the point is, just because it was written in C++ doesn't mean it's any good. Not everything gets serious attention from people who know what they're doing.
- shereadsthenews 7y ago
  You are thinking of dl.google.com. It was a Go program that replaced a very old single-threaded C++ server (using the ancient SelectServer C++ core, deprecated at that time). The thing you have to realize about Google infrastructure is it does not require vertical scalability of its service backends. It is very typical to write a program and deploy it with 100 replicas having one CPU each on 100 different machines. A variety of load balancers (all written in C++, naturally) papers over the complexity. Nobody at Google expects a Go program to occupy an entire machine because Borg packs hundreds of services onto a single machine. The question is for _you_ do _you_ have Borg or another workload coordinator that allows you to do this? Or do you have "the database machine" and "the server" where you expect individual processes to scale up to many cores? BTW the reason dl.google.com rewrite was faster was not because it was in Go, it was because the C++ server was serving off its local disk and the rewrite was serving off a cluster file system with ~infinite I/O capabilities. Apples and oranges.
  - puzzle 7y ago
    It was even crazier: when the original download server was written, local disk was faster, mainly because the network wasn't too fast (rack locality was a concern, way back when), but also because GFS chunk servers weren't, either. At the time of the rewrite, Firehose and co. were being deployed everywhere, D did a better job at serving bytes and, later, local disk use was placed in a lower QOS level. Unless you were one of the few teams that had a good rationale for dedicated machines, if you fought for I/O time on a given disk against D, invariably you lost.
  - tmerr 7y ago
    Apples and oranges, though still an important lesson: many optimizations happen at the level of interactions between services. C++ is more micro-optimizable than Go, but it doesn't matter when the low hanging fruit has nothing to do with language (and I would argue this is more often than not).
- deleted 7y ago
  [deleted]
Thaxll 7y ago
High performance is a very vague terms now days, there are company that have Google scale problems that don't use C++ as main language ( Nerflix Uber ect ) any modern runtime can do "high performance" especially for backend applications. YouTube primary language is Python for instance.
- deleted 7y ago
  [deleted]
- rightbyte 7y ago
  Netflix OK but Uber? They did 4 billions rides in 2017. Thats naivly about 130 rides per second with nice parallelism due to locality of the physical rider. That's not an insane amount of data crunching.
  - Thaxll 7y ago
    You could say the same for Netflix, it's a giant CDN so why do they need 150k ec2 instances? The problem they solve looks simple on the outside, the reality is different. https://eng.uber.com/managing-data-workflows-at-scale/ https://eng.uber.com/managing-data-workflows-at-scale/
  - devonkim 7y ago
    In my experience, most non-trivial sites are similar to icebergs of code - users might see 5% of the codepath in normal usage for what they want, but there's boatloads of OLAP, data analysis, instrumentation, error handling, and reporting being done on those transactions to help make that 5% both more profitable and reliable.
  - weberc2 7y ago
    It’s not just rides, but also matching drivers with riders, geofence lookups, etc. it’s not a CRUD app.
pjmlp 7y ago
It is not out of context, it was stated just like that on a talk given by Rob Pike at Microsoft, it is available on Channel 9.

skybrian 7y ago

Hmm, that seems a bit exaggerated. I seem to recall someone on the Go team describing the rewrite of a server that was originally in C++ and became much faster. (Largely because it started out at a heap of legacy code that was neglected for years.) That's probably pretty unusual, but the point is, just because it was written in C++ doesn't mean it's any good. Not everything gets serious attention from people who know what they're doing.

shereadsthenews 7y ago
You are thinking of dl.google.com. It was a Go program that replaced a very old single-threaded C++ server (using the ancient SelectServer C++ core, deprecated at that time). The thing you have to realize about Google infrastructure is it does not require vertical scalability of its service backends. It is very typical to write a program and deploy it with 100 replicas having one CPU each on 100 different machines. A variety of load balancers (all written in C++, naturally) papers over the complexity. Nobody at Google expects a Go program to occupy an entire machine because Borg packs hundreds of services onto a single machine. The question is for _you_ do _you_ have Borg or another workload coordinator that allows you to do this? Or do you have "the database machine" and "the server" where you expect individual processes to scale up to many cores? BTW the reason dl.google.com rewrite was faster was not because it was in Go, it was because the C++ server was serving off its local disk and the rewrite was serving off a cluster file system with ~infinite I/O capabilities. Apples and oranges.
- puzzle 7y ago
  It was even crazier: when the original download server was written, local disk was faster, mainly because the network wasn't too fast (rack locality was a concern, way back when), but also because GFS chunk servers weren't, either. At the time of the rewrite, Firehose and co. were being deployed everywhere, D did a better job at serving bytes and, later, local disk use was placed in a lower QOS level. Unless you were one of the few teams that had a good rationale for dedicated machines, if you fought for I/O time on a given disk against D, invariably you lost.
- tmerr 7y ago
  Apples and oranges, though still an important lesson: many optimizations happen at the level of interactions between services. C++ is more micro-optimizable than Go, but it doesn't matter when the low hanging fruit has nothing to do with language (and I would argue this is more often than not).
deleted 7y ago
[deleted]

Thaxll 7y ago

High performance is a very vague terms now days, there are company that have Google scale problems that don't use C++ as main language ( Nerflix Uber ect ) any modern runtime can do "high performance" especially for backend applications. YouTube primary language is Python for instance.

deleted 7y ago
[deleted]
rightbyte 7y ago
Netflix OK but Uber? They did 4 billions rides in 2017. Thats naivly about 130 rides per second with nice parallelism due to locality of the physical rider. That's not an insane amount of data crunching.
- Thaxll 7y ago
  You could say the same for Netflix, it's a giant CDN so why do they need 150k ec2 instances? The problem they solve looks simple on the outside, the reality is different. https://eng.uber.com/managing-data-workflows-at-scale/ https://eng.uber.com/managing-data-workflows-at-scale/
- devonkim 7y ago
  In my experience, most non-trivial sites are similar to icebergs of code - users might see 5% of the codepath in normal usage for what they want, but there's boatloads of OLAP, data analysis, instrumentation, error handling, and reporting being done on those transactions to help make that 5% both more profitable and reliable.
- weberc2 7y ago
  It’s not just rides, but also matching drivers with riders, geofence lookups, etc. it’s not a CRUD app.

pjmlp 7y ago

It is not out of context, it was stated just like that on a talk given by Rob Pike at Microsoft, it is available on Channel 9.