3 ms·

I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.c

I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). CloudFlare has it sitting in the middle of every request for some sites (in the form of Railgun, their delta compression for pages). I'm not exactly a perf ninja and got some Go code packing Wikipedia history dumps at >100 MB/s. Dropbox uses Go for, their words, "our performance-critical backends" (https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-libraries/ https://blogs.dropbox.com/tech/2014/07/open-sourcing-our-go-...). So folks manage to heavy lifting with it. I see "I couldn't possibly use X for performance reasons" here a lot, as an almost immediate response about a wide range of different tools, and two things come up in my mind: 1) you can always set the standard arbitrarily high. If you're doing AAA shoot-'em-up games or something, yes, use something else. 2) you're often not as good at tools that're new or different. It's possible you could go further with just a few more tricks about profiling or using free pools or whatever, or a little more info about how your code executes or what the runtime does. FWIW, if you hit a specific wall that's a problem for your app, folks on golang-nuts (or StackOverflow, where I've hung out sometimes) are often happy to try and help. Hope this is more helpful than fussy. Mostly just don't want folks to be discouraged into thinking certain things are impossible when in some cases they're really being done in production out there.

coldtea 12y ago
>I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). Not as impressive as it sounds. Most of it is cached in memory anyway...
tylertreat 12y ago
Agreed with setting the standard arbitrarily high. It depends on what problem you're trying to solve—just like deciding when to use any other tool. Context matters. Where I work, we've been trying to build some super-fast systems and things like the GC and even calling interface methods matter. We open sourced some data structures that show just how optimized we're trying to get (https://github.com/Workiva/go-datastructures https://github.com/Workiva/go-datastructures), but in hindsight, Go might not have been the right tool for the problem.
sirclueless 12y ago
No one doubts that Go is production ready at this point. But the performance requirements of a systems programming language are just very different from the requirements for a web server or applications language. From my point of view, and the industry I'm in, the latency requirements of a web server stack look completely laughable. That's not to say there aren't challenges in a web stack, because many web servers have to handle orders of magnitude more I/O than we do, and efficient load balancing over a distributed system is extremely difficult and I am fortunate to rarely have to think about that kind of thing. But a requirement like "99% of requests need to have a response time of 200ms or lower" looks like fiddlesticks compared to a requirement like "a round-trip-time of more than 100us will be a large problem and get noticed". My point is that Google's, CloudFlare's, and Dropbox's "performance-critical backends" don't require the same things as some other workloads. As a more mundane example, the latency requirements of Google's search engine are probably less stringent than the latency requirements of your text editor. None of this should be taken to mean Go is slow or can't handle 99% of the world's performance requirements. But you can't just say "Go is high performance and fits in all of these company's critical paths. Try harder and it will work." Sometimes it might just not be cut out for it.
rdtsc 12y ago
JVM is in use in a lot more performance critical paths than Go. Go just seems new so it is easy to list the 2-3 places that use at scale.
- Roboprog 12y ago
  The JVM is awesome for long running programs with minimal memory constraints. For transient programs, not so much.

coldtea 12y ago

>I mean, Go is (or was) in the loop whenever YouTube hit its MySQL clusters (vitess) and on on the server providing downloads of Chrome and so forth (dl.google.com). Not as impressive as it sounds. Most of it is cached in memory anyway...

tylertreat 12y ago

Agreed with setting the standard arbitrarily high. It depends on what problem you're trying to solve—just like deciding when to use any other tool. Context matters. Where I work, we've been trying to build some super-fast systems and things like the GC and even calling interface methods matter. We open sourced some data structures that show just how optimized we're trying to get (https://github.com/Workiva/go-datastructures https://github.com/Workiva/go-datastructures), but in hindsight, Go might not have been the right tool for the problem.

sirclueless 12y ago

No one doubts that Go is production ready at this point. But the performance requirements of a systems programming language are just very different from the requirements for a web server or applications language. From my point of view, and the industry I'm in, the latency requirements of a web server stack look completely laughable. That's not to say there aren't challenges in a web stack, because many web servers have to handle orders of magnitude more I/O than we do, and efficient load balancing over a distributed system is extremely difficult and I am fortunate to rarely have to think about that kind of thing. But a requirement like "99% of requests need to have a response time of 200ms or lower" looks like fiddlesticks compared to a requirement like "a round-trip-time of more than 100us will be a large problem and get noticed". My point is that Google's, CloudFlare's, and Dropbox's "performance-critical backends" don't require the same things as some other workloads. As a more mundane example, the latency requirements of Google's search engine are probably less stringent than the latency requirements of your text editor. None of this should be taken to mean Go is slow or can't handle 99% of the world's performance requirements. But you can't just say "Go is high performance and fits in all of these company's critical paths. Try harder and it will work." Sometimes it might just not be cut out for it.

rdtsc 12y ago

JVM is in use in a lot more performance critical paths than Go. Go just seems new so it is easy to list the 2-3 places that use at scale.

Roboprog 12y ago
The JVM is awesome for long running programs with minimal memory constraints. For transient programs, not so much.