The title is interesting but the article lacks a lot of background information. There’s no explanation of what the CPU-bound endpoints are, what causes them to be CPU-bound etc. They mention they didn’t think optimising the Go code would’ve given them enough, but there’s nothing to substantiate it and no way for the reader to form their own opinion since we’re never told what the problem is other than “doesn’t scale.”
I have no issue with Rust, there’s nothing wrong with what they did, they approached it sensibly and the results are certainly compelling. But it reads a lot like “we wanted to write something in Rust” and found a reason to do so.
TLDR: Today's 10,000 [1] discovers that rewriting a performance bottleneck in a more performant language results in significant overall gain for the system as a whole.
The title is interesting but the article lacks a lot of background information. There’s no explanation of what the CPU-bound endpoints are, what causes them to be CPU-bound etc. They mention they didn’t think optimising the Go code would’ve given them enough, but there’s nothing to substantiate it and no way for the reader to form their own opinion since we’re never told what the problem is other than “doesn’t scale.”
I have no issue with Rust, there’s nothing wrong with what they did, they approached it sensibly and the results are certainly compelling. But it reads a lot like “we wanted to write something in Rust” and found a reason to do so.
TLDR: Today's 10,000 [1] discovers that rewriting a performance bottleneck in a more performant language results in significant overall gain for the system as a whole.
[1] https://xkcd.com/1053/