Hacker News Reader

Comment by dgacmu | Hacker News Reader

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.

View on HN

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.

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.

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?

Implement Raft and compare that too?

Reply on news.ycombinator.com