On: Implications of Rewriting a Browser Component in Rust

[blub]

It's not, that's C++.

Rust requires a lot of runtime checks, but that's the price one has to pay for memory safety.

[sciurus → blub]

"Abstraction without overhead" is explicitly a goal of Rust.

https://blog.rust-lang.org/2015/05/11/traits.html

[blub → sciurus]

From your link:

"C++ implementations obey the zero-overhead principle: What you don't use, you don't pay for".

In Rust you pay for e.g. bounds checking or integer overflow handling or optionals. But I don't understand why everyone's getting so defensive about this, since it's the only way (static verification and proofs aside) to get the desired safety characteristics...

[carlmr → blub]

In Rust release builds the integer overflow of checks are disabled. They're not zero cost and there's no magical way to do it, so it's only done in debug builds.

You can disable them in debug builds as well with wrapping integers. So this is again a practice of making the safer option the default, but won't incur runtime costs if it bothers you.

If there is a way to do it at compile time that will usually be used in rust.

[steveklabnik → blub]

You only pay for bounds checks if you use them, same with the overflow stuff, or option types. That's not in contradiction to this principle.

[steveklabnik → blub]

What checks are you thinking about? There are some, but the vast majority of Rust's checks are at compile time, not runtime.

[ordu → blub]

> Rust requires a lot of runtime checks, but that's the price one has to pay for memory safety.

It requires a lot of runtime checks on the boundary between rust and C/C++ code. You cannot trust C/C++ code, so you are forced to check everything. C-function returns a enum value? Check that this value is in the enum, before converting it to the rust enum. Check that there are no situations like

    enum MyEnum {
        val1, val2=5
    };
    enum MyEnum foo() {
        return 42;
    }

But after you've done all that checks you need to check almost nothing, because if you have a enum value in Rust, you know for sure that it is a valid value. And compiler knows that the value is valid and optimizes accordingly. If you have an &str, you know that it is a valid utf8, you need not to check it on each access, it have been checked already. You got a valid pointer from C? Wrap it into NonNull, so neither you, nor compiler would need to check validity of a pointer once more.

It is unclear thing, who needs more checks -- safe code or unsafe code. I'm gravitating to a belief that unsafe code needs much more runtime checks.

[rat9988 → blub]

Rust is about zero cost abstraction. Bound checks can be disabled.

[blub → rat9988]

And then it's no longer memory safe, which makes the whole exercise pointless...

[littlestymaar → blub]

If your use iterators instead of indexes, you have no bound-checks because they are optimized away. I've been working full time with rust for a year and I'd say I need indexes less than 10 of the time, most of which are for fixed-size array with constant indexes, for whom the bound checks are also optimized away. So I'd say they aren't really a problem in practice 95% of the time. If you really need to go unsafe for the last 5%, well you're still 95% safer than C++ :)

[phkahler → blub]

Even in that case it's not pointless. You can do a lot of testing and fuzzing with checks enabled to get some confidence that you don't have bugs. Then disable the checks for performance. That's just one option. I think it's nice to have options even if I choose not to use them.

Even better is to use iterators and other abstractions that don't require bounds checking at all. Rust has lots of good tools to build efficient code.

[int_19h → blub]

Your choices are exactly the same as in C++ - memory-safe with runtime checks, or memory-unsafe without - except that the default is different.

But the real benefit of Rust is ownership tracking - and that one is zero overhead.