It doesn’t have a stable abi, how could it be easier? I would argue that the vast majority of what rust gives you comes at a direct cost of precisely the ergonomics of manual memory management. It’s a tradeoff that makes sense much of the time, but it’s still very obviously a tradeoff.
It’s easier in that you can cordon off the tricky parts being unsafe and define safe mechanics. Proof point: the Linux kernel using more and more rust and at once the platform support gets there more if the core memory management and what not will start getting ported too.
There’s also work actively ongoing to make certain constructs even easier to express more ergonomically and letting user programs implement some of the magic that’s currently restricted to the standard library
The Linux kernel has to balance security and performance concerns, security probably being primary, so it makes sense to make the tradeoff for more safety with worse ergonomics for memory management.
If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
> 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 :-)
You’ve played sleight of hand with the argument saying it’s easier to do it in C++ whereas before you were claiming it’s faster. I don’t disagree with the easier part and no one on this thread has. But it’s also super easy to shoot off your own foot with a hairline trigger. Rust at least has better tooling to both verify your unsafe code is safe for memory access (Miri is a stronger proof than sanitizers) while letting you define careful interfaces for using said memory safely.
Again - no one takes issue with the ease argument. The only issue was claiming that c++ somehow let you go faster. Indeed, it’s likely not the case because rust has stronger aliasing protections that let it emit more efficient code, closer to Fortran - that’s why the old math libraries you’re probably using in c++ are written in Fortran and not c++ (rust didn’t exist and Fortran enforces no aliasing whereas c++ doesn’t).
Redox OS, Asterinax. PD: my first distro was Debian Woody, comparable to Slackware with a 2.2 kernel back in the day, 2.4 was optional. So I've seen everything.
Rust will replace C++. C will we kept as a "low level ASM" similar to what inline ASM was for C.
Still, I can perfectly predict Rust based Qemu and FFMPEG's being rewritten from Bellard et all replacing the former C base. Legacy users can just use legacy machines with Hyperbola (and I'm one of them), but Rust will be almost mandatory to be protected against automatic AI attacks. Kinda like blaster/sasser but much worse. Multiplatform virii written in Golang for instance.
Servers getting poisoned media targetting ImageMagick/GM and FFMPEG on purpose, and VM's too. Thus, rustifying Qemu/Libvirt and FFMPEG will almost be a mandatory task.
> I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
I understand your argument as "it's easier to botch an implementation in C++ than in Rust", which is true and that is actually an argument in favour of Rust.
I strongly believe it is harder to write a C++ implementation that is sound and does not rely on UB.
The point is, there are some domains (data-oriented programming) where Rust actively resists the kind of work you need to do to solve the problem in an optimal way, and it makes sense to use a language built around the type of memory management required.
There's no point in using Rust when 90% of your work is deactivating the benefits Rust provides and working around its default behavior.
> 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.
While this is true - and I see the same sentiment as i am about to make ad nauseam - it is kind of amazing how far the goal posts have moved in such a short space of time.
DS4's architecture was redesigned for cache efficiency. It's the model itself that is just way more cache efficient, in addition to a distributed KV cache (which they open sourced last year). You could run your own LLM provider just for DS4 models, recreate their setup, and get the same cache efficiency, but it would only work for that one model family.
Other models would also need to be rearchitected to get the same benefit, and I suspect they don't want to, because it seems to create both larger models and slightly less intelligence (DS4* has smaller active experts to get faster results).
if you think about that statement a bit more deeply, how else are you going to incentivize a society as a whole to take risks? If all the risk from your actions is ultimately your responsibility, no one would take risks, no one would explore for the sake of it.
Solve by collecting taxes properly and then using the funds to provide research grants. Then it's a shared risk, shared reward.
But no instead we have our governments pissing away money on useless bullshit and private enterprise bending over backwards to avoid paying corporate taxes, entire countries who exist to be tax havens. And an apathetic voterbase who don't understand anything but will tell you why they don't like it all, anyway.
You could say the same about more or less any language feature - the thing is though that having a standard feature people can agree on is better than several people’s divergent opinions on which macros are sufficiently aesthetically pleasing.
reply