3 ms·

This is a controversial opinion, but I’ve been generally unimpressed with the performance of real world systems written in Rust or C++. While the theoretical p

This is a controversial opinion, but I’ve been generally unimpressed with the performance of real world systems written in Rust or C++. While the theoretical performance ceiling is higher, I’ve personally observed that it usually takes several times longer to write the systems in Rust/C++ and often the “naive” Rust implementation is less performant than the “naive” go implementation. There are obviously cases where using Rust or C++ makes a lot of sense, but I prefer Go. I can get a performant prototype up and running quickly, the “critical path” can usually be micro optimized to within +/- 10% of Rust if you know what you’re doing, and by the time the Rust implementation matures the Go implementation has already had time to iterate repeatedly on key architectural, data structure, and algorithmic choices based on real world usage. That’s just my 2cents though and doesn’t reflect the views of all the people I work with.

purplerabbit 4y ago
Very astute observation. Although it's a bit painful to admit, as Rust scratches a perfectionist itch which Go absolutely does not. I've read a bit about algorithm-driven performance gains vs. hardware-driven performance gains... this seems like an argument for a third category: DX-driven performance gains.
the_duke 4y ago
These systems usually spend a lot of time waiting for network/disk IO, which means there is plenty of CPU time available to do the computations or GC runs, and the added memory pressure isn't so significant. The Go runtime is also finely tuned for exactly these kinds of workloads, with language level insight into blocking operations. If we take the Tokio async runtime for Rust: it's not exactly the fastest runtime out there, comparatively new, you need to carefully avoid introducing blocking calls that stall the worker threads, there is no language level integration, and Rusts trait system currently often requires boxing of futures. Combine all of that and you often end up with code that isn't noticeably faster than Go in practice. One counterpoint though: I've found that Rust code takes longer to write, but it's significantly easier to refactor, thanks to the much stronger type system.
jerryjerryjerry 4y ago
Good points on performance side, but IMHO one of the pain points is still the memory management. Go GC can do some of the work, however it can be hard to do real-time tracking and management while this is exactly what db kernel needs.

purplerabbit 4y ago

Very astute observation. Although it's a bit painful to admit, as Rust scratches a perfectionist itch which Go absolutely does not. I've read a bit about algorithm-driven performance gains vs. hardware-driven performance gains... this seems like an argument for a third category: DX-driven performance gains.

the_duke 4y ago

These systems usually spend a lot of time waiting for network/disk IO, which means there is plenty of CPU time available to do the computations or GC runs, and the added memory pressure isn't so significant. The Go runtime is also finely tuned for exactly these kinds of workloads, with language level insight into blocking operations. If we take the Tokio async runtime for Rust: it's not exactly the fastest runtime out there, comparatively new, you need to carefully avoid introducing blocking calls that stall the worker threads, there is no language level integration, and Rusts trait system currently often requires boxing of futures. Combine all of that and you often end up with code that isn't noticeably faster than Go in practice. One counterpoint though: I've found that Rust code takes longer to write, but it's significantly easier to refactor, thanks to the much stronger type system.

jerryjerryjerry 4y ago

Good points on performance side, but IMHO one of the pain points is still the memory management. Go GC can do some of the work, however it can be hard to do real-time tracking and management while this is exactly what db kernel needs.