Comment by tialaramex
3 hours ago
> If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
If you actually care about performance where you'd start is with measurements. What we see so much from C++ isn't measurements it is dogma. Things C++ forces on you must dogmatically be imagined as free without measuring them, things C++ does not have get treated as expensive, again without measuring so as to justify their absence.
For example, the unstable sort in C++ (std::sort) is typically implemented in a way which introduces Undefined Behaviour if your ordering isn't coherent either because you didn't realise that was mandatory or through some minor programming error. In contrast all of Rust's unstable sort implementations have been entirely safe even in the face of such mistakes.
And your dogma might tell you OK, but the C++ sort must be faster. That's why we're doing unsafe things, it must be faster. Except, nope, slower. Slower, but unsafe. Pointlessly worse. Only acceptable because of dogmatic belief.
With all due respect, are you sure you're not the one being dogmatic here?
90% of the code I write these days is Rust. It's a great tool, and the performance/safety balance, as well as general developer experience makes it well-suited to a wide variety of applications.
But in the past I've also built an ECS implementation. For that to optimize performance (and yes I did measure this) you want to do bulk memory allocations memory, pack bytes in order to minimize cache misses, and dispatch multiple threads to read and write concurrently over your memory pool. You can do all that in Rust, and people have, but it's a pain in the ass.
And for example, if I were working on a high-frequency trading application, where every millisecond of additional latency represents millions of dollars of lost revenue, I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
Rust is an amazing tool, but that doesn't mean it's the optimal tool for every job.
I suspect that the additional friction in doing these things in Rust is still largely outweighed by everything else. I won't deny the friction - it's definitely there - but it has never been large enough for me to consider using anything else (especially reverting to C++!)
With that being said, I did write a compiler to specifically help me match C++ memory layouts in Rust [0], so I might be an outlier case :-)
[0]: https://github.com/ferrobrew/pyxis
> With all due respect, are you sure you're not the one being dogmatic here?
Obviously like Michael Burry it is always possible that I'm wrong and I can't see why. But I did give you a specific example where the dogma says well we have to choose this unsafe way to do it, but the reality is that's not only unsafe it's also slower. It is just worse.
I am glad to hear that you measured. I've been yelling at people for not measuring for much longer than Rust has existed - if people measure and choose C++ because the numbers were better I feel a lot better about that outcome.
As to being the right tool, I firmly believe we should use a lot more niche languages which do only one narrow thing very well. One common thing you'll see argued about the Memory Safe languages is that they need runtime bounds checks and such checks are a performance cost the unsafe languages do not incur. WUFFS illustrates that if we're willing to give up generality we can have a language which is entirely safe but doesn't do runtime bounds checks - because it proved mathematically at compile time that your code has no bounds misses so such checks are needless.
Arguably for HFT in particular the dirty secret is that if things go badly enough wrong you just say "Oops" and get a do-over because money isn't real.