4 ms·
Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implemen
by EdSharkey 11y ago
Well you kindof sound like a performance zealot. Burn some cycles, stop running unmanaged code, just take the hit. It should be justifiable if a Rust implementation of a library is 5-10% slower than its C equivalent. How can choosing to build and deploy unsafe code in today's legal/political/financial environment be defensible? Is it going to take public shaming and frogmarching developers to jail for our industry to make a change?
We need to discredit performance zealots and gently herd them to a profitable careers in videogame development where they can't do much harm.
And, there's plenty to dog on Java about, but that language and VM very intentionally makes it an ordeal to load a 3rd party binary blob. Modern development systems/VM's seem to have waved off concerns about unmanaged code and security; Node.JS compiles and loads binary blobs from dependencies all willy-nilly. Java took and takes security seriously.
- steveklabnik 11y agoDepending on what you're doing, it might even be faster, not 5-10% slower. We're currently sometimes faster, sometimes slower, but we should never be slower by a huuuuuge magnitude, though of course, bugs do exist. I've been excitedly watching this over time; I think in a few years Rust could just be straight-up faster than C the majority of the time, depending.
- EdSharkey 11y agoI think you're right with all the new opportunities for optimization in Rust. I wanted to encourage developers to be open to compiled Rust being nowhere-near an order of magnitude slower than equivalent compiled C and still have it be an acceptable architecture choice for systems-programming.
- steveklabnik 11y agoAbsolutely. I think trading a bit of speed for a bit of safety is the right choice 99.99% of the time. I've just been excited to watch the benchmarks improve :)