Rewriting a Large Production System in Go
My whole attitude changed when Michael Piatek (one of the star engineers in the group) sent me an initial cut at the core system rewrite in Go, the result of less than a week’s work. Unlike the original C++ based system, I could actually read the code, even though I didn’t know Go (yet). The #1 benefit we get from Go is the lightweight concurrency provided by goroutines. Instead of a messy chain of dozens of asynchronous callbacks spread over tens of source files, the core logic of the system fits in a couple hundred lines of code, all in the same file. You just read it from top to bottom, and it makes sense.
4 Comments RSS · Twitter
Just like a properly implemented system in C++11 based on std::futur and lambda, or libdispatch, or any other modern concurrency library.
This is a pointless question. You don't try to map types and constructs one to one when comparing two libraries.
If you want to seriously compare two libraries, find real use cases, and search for the equivalent way to perform them using the other library. It may involved completely different construct, but it does not means one is better and the other one should be avoided.
My point was not to say that "go" is not a good tool for what was done, my point was about the implicit notion that switching from C++ to Go was the only way to get such improvement.
A fine point and one I made myself in the original article's comments. I thought you were actually saying that "any other modern concurrency library" worked like Go. Which as you note is a hell of a statement.
