top | item 23427665

(no title)

What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.

discuss

jerf|5 years ago

It isn't clear to me you're looking at a clear win there. If you do want to try it out, I recommend the strangler pattern: https://docs.microsoft.com/en-us/azure/architecture/patterns... With HTTP it's really easy to rewrite one URL at a time. You just need some way to proxy things around, nginx if nothing else, and then you can swap things as you go along, so you can pick and choose which URLs to test the Go implementation on.

My rule of thumb for Go performance is that's roughly 2-3x slower that C/C++. While human loss aversion is probably kicking in and making that sound horrible, from an engineering perspective, it's likely you'll not notice it, speaking broadly from my position of ignorance. However, if you do have your code deployed to places that are routinely running the CPU at 50%+ all the time in your C++ code (as opposed to DB wait or whatever), and you are not interested in investing in more hardware, I wouldn't even consider switching to Go.

dirtydroog|5 years ago

It's mainly binary to JSON conversion, and firing that out over HTTP a few thousand times a second. That's the only IO. Goroutines look very interesting, and as I said, ASIO (C++ async networking) is a real pain to work with. But there are latency requirements here. Something that previously took 1ms cannot now take 10ms.

yencabulator|5 years ago

Here's the classic story about replacing a C++ HTTP server with a "slower" Go one: https://talks.golang.org/2013/oscon-dl.slide

Mind you, in 2013 the Go compiler was at go1.1, and had practically no optimizers at all.

hxegon|5 years ago

Pretty new to the language myself but it might be worth it to just dive in yourself and see. I imagine getting a proof of concept wouldn't take too long given how easy go is to learn, great builtin benchmarking, and the (from what I've heard) exceptional net/http library.