That’s gonna depend. I see a lot of people — so for many people the move to Go and the move away from an interpreted language like Perl or Python, or even a very fast language like Node.js, the switch to Go is enough. You say “Yeah, Go is twice as slow as C”, but on the other hand, Perl and Python, which are like 30 times slower than C, all of a sudden by going to Go you are now 10 or 15 times faster. That’s simply by switching technologies.
So for most things that people are doing, if you’re in what we would call a traditionally slow language, then moving to something like Go probably is enough. It’s really the places where you’re doing things where you need to be smarter about what you’re doing where you need to start thinking about performance. I would say, again, at least with my experience at Booking.com, which is a huge company – you know, lots of developers, massive codebase… How many of them were focusing on performance? How many of them needed to be focusing on performance? You know what, it really kind of varies, but I think that the most important thing is what is the software that you’re doing doing, and is it doing it well enough, is it doing it fast enough? Is it using a reasonable amount of memory? And I think for most people the answer is “Yeah, it’s doing fine.”
So it’s really a very small amount of people that actually need to focus 100% on performance and really get those last 10% or 20%, or 1% or 2%, to sort of grind the cycles and really get the hardcore optimization. Everything else is — I mention this in the perf book, I say “Basic tips for writing not slow software – choose a reasonable data structure”, and that’s basically like “Don’t be dumb.” [laughter] And then tips for writing fast software is “Okay, here’s actually what we’re gonna do, and this is how to minimize GC allocation. Here’s how to optimize GC performance, here’s how to really work around some of the issues with the runtime.” But the first thing to write not slow software – just don’t be dumb.
[00:12:03.29] If you’re doing mostly key-based look-ups, use a map. Ta-da! If you need stuff in order, use a slice. Ta-da! Just choose the reasonable data structure for your data access patterns, and then that’s kind of it. Then it’s really — after the program you’re trying to write, you determine that it isn’t fast enough. “I have an hourly report that takes an hour and a half to run” – okay, well that’s clearly not fast enough. “I have this box and I have to solve this problem, but all of a sudden I don’t have enough RAM. If I do the obvious thing, then I don’t have enough RAM to solve it” – okay, now we need to go in and shrink data sizes, compress data structures in memory, kind of do the extra that is required. I think in almost all cases, don’t optimize… But on the other hand, also don’t be dumb.