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".

It means you couldn't write faster code if you did it by hand in assembly. In C++ they call it "zero-cost abstraction" (you can Google that).

Adding GC adds all sorts of overheads that you can avoid in C and Rust.

Obviously in some cases you can beat the compiler, but in general it means there aren't any systematic overheads.

> "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`?

Absolutely!

https://godbolt.org/z/aMPfqz396

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.

> The meaning was clear though.

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.

I started by saying "hmm, it's not exactly not compromising on speed, but it's better for some use-cases indeed".

You said "you're wrong, it is optimal".

Now you say "it is not optimal, but it is very good, and I think you are nitpicking when you say it is not optimal".

Sure, I'm nitpicking. I was nitpicking from the beginning on, I'm not sure what you were trying to say now.