Hacker News Reader

Comment by npalli | Hacker News Reader

"For each system that Google brings on-line with Go, even if it took a team of 10 6 months, they've likely saved themselves millions of dollars in new capex infrastructure acquisition"

I thought the old systems were in c++. So, how did the infrastructure savings accrue? In fact, I don't recall anyone doing analysis on that front.

View on HN

Matt linked to my course, but also: I did a tiny analysis of this with my pi searcher (http://da-data.blogspot.com/2013/05/improving-pi-searchers-s... ) -- it's a toy compared to the kind of system that Matt described, but my experience was extremely positive. Rewriting it in Go made it easier to architect the system right to take advantage of persistence. It's hugely faster.

We also have a paper accepted to SOSP this year (the academic weenies will understand that) where the system - a Paxos variant - is implemented in Go. We also implemented about four other Paxos variants in Go to compare against them, a task that would have been absolutely grueling in C++. In Go it wasn't too bad. Our performance isn't super-blazing, but it turns out to be one of the faster publicly available Paxos implementations anyway. I'll have to write up a bit about our experience with it -- I'm with Matt 100% on this one.

I have no doubt it must have been easier programming in go. My question was on resource efficiency. I doubt anyone programs in C++ for fun anymore :-). The issue with toy problems you can write a vanilla python or perl program that processes text faster than C++ (without extensive fiddling) however the memory and CPU utilization can be 5-10 times higher. This doesn't matter on a single box for toy problems, but matters when you have an infrastructure costs of Google that run into the billions.

Everybody talks about using C++ for efficiency, but the way most people end up writing C++? Not very efficient.

Because many try to write C in C++, instead of learning how to do it properly.

I think you'd have to agree that C++ does not make it easy to learn how to do it properly, and nor does it make it easy to actually do it properly. Go at least makes it far easier for most programmers to do an acceptable job which has to count for something.

> I think you'd have to agree that C++ does not make it easy to learn how to do it properly, and nor does it make it easy to actually do it properly.

I know C++ since 1993. Having used it alongside many other programming languages and followed quite closely the standardization process in "The C++ Report" and "The C Users Journal", latter named "The C/C++ Users Journal".

I only used C instead of C++ when forced to do so.

Yes it is a complex language, requiring a good background in programming languages to use it properly, but so are quite a few other languages that provide a similar set of abstractions.

> Go at least makes it far easier for most programmers to do an acceptable job which has to count for something.

True, although in a similar way as Java 1.0 was a better C++, however we are no longer in 1995.

We've done lots of load testing and the CPU and memory footprint of the Go version is better than the C++ version. Not surprising since we reduced the code size so much, but at least using Go did not involve significant bloat.

What about throughput and latency, how does your Go version compare to the C++ version?

Identical. The bulk of our system's latency involves making calls out to other services, so that is not the bottleneck in this case.

Implement Raft and compare that too?

What you say sounds cool. I wrote a bunch of Paxos implementations for distributed databases in C++:

https://github.com/scalien/scaliendb/tree/master/src/Framewo...

Can you share your Go code?

You're right. I think I got ahead of myself in what I was thinking, conflating the rewrite of the C++ system into Go with the some of the other speedups I've been reading about coming from other languages/frameworks.

I'd be interested to know more from Matt about speedups or slowdowns in specific subsystems that are feature-for-feature complete (as opposed to comparisons of Go to C++ where the Go rewrite is simply doing less stuff because lots of cruft was tossed out).

Reply on news.ycombinator.com