Hacker News Reader

Comment by gizzlon | Hacker News Reader

> But, people now expect to see more obviously [..]

I don't. I mean, yay for improvements, but it's already working great for my usecases.

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.

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.

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.

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.

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.

Same here. Go is now my daily driver and main language, and I'm perfectly satisfied with it. Quite the opposite of expecting more, I'm very fearful on what may change or be added in go-2 (which is actually a reason why I'm currently learning C, just in case).

Personally, if Go takes a bad turn, I'm likely to just go back to JVM languages.

Not Scala though, they went overboard with that one.

Disclaimer: I'm a Go fanboy so I'm biased.

> if Go takes a bad turn

The conservative nature of the Go team seems to recognize this worry. It's been bashed from the beginning for no generics but they are working on it. They just haven't found something that "feels right".

Of course there's just no pleasing all the people all the time.

Reply on news.ycombinator.com