No, for systems programming it means nobody needs it to be faster.
You're welcome to use Python for whatever slow scripting you personally need, but it's not suitable for writing an OS and libraries because it's going to make every program slower, and while that might be ok for you, it's not going to be ok for a lot of people.
I explicitly said "for the vast majority of use-cases". Of course you can pick one that is not part of it and pretend I included it in that majority, but then... what's the point of even trying to communicate?
The comments you're replying to aren't claiming that Rust is the only language that is fast enough for any use case. They're pointing out that Rust is the only language that is memory safe
> without compromising on speed
I was just trying to explain why that matters to you.
Nobody is saying you have to use Rust for everything.
Well, Java is memory safe, and the JVM is fast enough for tons of use-cases.
Before you get at me for "fast enough", let me say that "without compromising on speed" doesn't mean anything either. I can write super slow code in Rust, it's not like the language prevents me from doing it.
My point is that in many cases, the speed is really not the problem with the JVM.
> "without compromising on speed" absolutely does mean something, and it doesn't mean "fast enough".
I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there?
"Zero-cost abstraction" is a concept I understand. But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
Feels like it is compromising on speed, to some extent.
> but in general it means there aren't any systematic overheads
Or maybe I am wrong and there are absolutely no systematic overheads in any concept similar to `RefCell` in Rust? Is `RefCell` zero-cost? That's not my understanding.
> I Googled "without compromising on speed" and didn't find a formal definition. Would you mind helping me there?
It's not a formal term. The meaning was clear though.
> But... are you sure that it would be impossible to write faster code (even if you did it perfectly in assembly) than what Rust generates when you use `RefCell`?
The second example is what you'd do if you were writing C or assembly. Rust takes the safer option by default.
> Is `RefCell` zero-cost? That's not my understanding.
I think you are misunderstanding what "zero-cost" means. Or maybe what RefCell does. RefCell checks are runtime if a value is borrowed by some other code. It's kind of like a single-threaded mutex. You can't implement that in assembly any better, so it is zero cost.
You are probably thinking "but in C you don't need to use RefCell at all!", and that is true but unsafe. You can avoid that in Rust, but nobody does because it's 2 instructions (which will be perfectly branch predicted) so it essentially costs nothing.
It's kind of like how `std::vector::at()` is still a zero-cost abstraction in C++. The thing you are abstracting is "array access with bounds check". You can't perform that function any better with hand-written assembly. Saying "aha, but in C we never bother with bounds checks!" doesn't invalidate that.
Was it? You are telling me that it is actually possible to write faster code if it is unsafe, but for some reason it doesn't count as faster in your book, and therefore it's not compromising on speed ("just ignore the faster solutions").
With that kind of definition, all the code I ever wrote is provably optimal: if you ignore all the solutions that are more efficient than my code, then my code is the fastest.
Yes it was clear. Unsafe Rust is still Rust. I already explained that in some cases you can beat the compiler but there aren't any systematic overheads.
I think you understand at this point and are just nitpicking to avoid admitting it, so goodbye.
You're welcome to use Python for whatever slow scripting you personally need, but it's not suitable for writing an OS and libraries because it's going to make every program slower, and while that might be ok for you, it's not going to be ok for a lot of people.