Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implications of Rewriting a Browser Component in Rust

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#51

Post by duxup »

chillydawg wrote: post #46
duxup wrote: post #33

Earlier quoted context omitted.

Yeah I keep hearing / reading about rust, even seen some demos but the demos all end with "oh no I'm not using this for anything". Still cool but ... want to see someone doing something in production / get their thoughts on that. Edit: To be clear I'm not saying anyone isn't using it, this is just more of a comment about the impression I can get when I hear about X tech is so cool, but that's most of what I hear and…

Firefox?

I'm not saying nobody is using it, just the volume of "hey this is so cool" gets to be a bit much and I want to see more "here it is solving problems in production for a real thing".

Re: Implications of Rewriting a Browser Component in Rust

#52

Post by steveklabnik »

rini17 wrote: post #50

Does Rust allow for taint analysis too like Perl has for long time? If not I'd say it's missed opportunity. (It marks all untrusted input as tainted and programmer must explicitly parse the data or mark them untainted to pass them further.)

There's not a language feature to do so, but you can do it through the type system if you wish.

Re: Implications of Rewriting a Browser Component in Rust

#53

Post by carlmr »

blub wrote: post #38
sciurus wrote: post #16

Earlier quoted context omitted.

"Abstraction without overhead" is explicitly a goal of Rust. https://blog.rust-lang.org/2015/05/11/traits.html

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

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.

Re: Implications of Rewriting a Browser Component in Rust

#54

Post by [deleted] »

blub wrote: post #38
sciurus wrote: post #16

Earlier quoted context omitted.

"Abstraction without overhead" is explicitly a goal of Rust. https://blog.rust-lang.org/2015/05/11/traits.html

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

[deleted]

Re: Implications of Rewriting a Browser Component in Rust

#55

Post by hedora »

rkangel wrote: post #4

It's nice to see a balanced, real world, case study including 'these things are fixed by Rust', 'these are problems that don't occur in idiomatic Rust', and 'these are problems that Rust can't help you with'. I'm a big fan of Rust, but the one sided 'Rust makes all the problems go away' articles don't provide any value.

Overall, it did a decent job of being balanced, but I don’t buy the memory overflow example at all.

For one thing, idiomatic C++ bounds checks by default. You need to use at(). If you don’t like typing at(), you can implement an array type that always bounds checks fairly easily. On that note, the vulnerable c++ code should be using accessors, not indexing to access the oddly packed and laid out array. Even the fixed version wouldn’t pass a code review from me. You could write equivalently bad code in any language that supports array types, and get similarly broken results.

For another thing, there’s no evidence that you couldn’t achieve the same improved data structures in C++ using its type system (which is turing complete...)

The “thread safe by default” property sounds interesting; I’d be interested in reading more about that.

Re: Implications of Rewriting a Browser Component in Rust

#56

Post by ordu »

blub wrote: post #8
gubbrora wrote: post #6

> could have been caught by a run time bounds check And here I thought rust was all about zero cost abstractions.

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.

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

Re: Implications of Rewriting a Browser Component in Rust

#57

Post by palotasb »

rini17 wrote: post #50

Does Rust allow for taint analysis too like Perl has for long time? If not I'd say it's missed opportunity. (It marks all untrusted input as tainted and programmer must explicitly parse the data or mark them untainted to pass them further.)

In Rust, or any statically typed language such as C++ or Java, the idiomatic way to handle untrusted input is to treat it as a "bag of bytes" before you access it. Then either parse it into a strongly typed object or bail out of parsing. The strongly typed object is safe to use. Bailing out (throwing an exception or returning an error type) does not allow the program to continue assuming that the (malformed) input was correct.

Re: Implications of Rewriting a Browser Component in Rust

#58

Post by rapsey »

duxup wrote: post #33
rkangel wrote: post #4

It's nice to see a balanced, real world, case study including 'these things are fixed by Rust', 'these are problems that don't occur in idiomatic Rust', and 'these are problems that Rust can't help you with'. I'm a big fan of Rust, but the one sided 'Rust makes all the problems go away' articles don't provide any value.

Yeah I keep hearing / reading about rust, even seen some demos but the demos all end with "oh no I'm not using this for anything". Still cool but ... want to see someone doing something in production / get their thoughts on that. Edit: To be clear I'm not saying anyone isn't using it, this is just more of a comment about the impression I can get when I hear about X tech is so cool, but that's most of what I hear and…

We're doing a low level core functionality lib in Rust that is shared between Windows desktop, iOS and Android apps.

It works really well.

If we were to do it again, the core Rust lib would do much more and the platform native code would only be things that need to be like UI and notifications.

Re: Implications of Rewriting a Browser Component in Rust

#59

Post by masklinn »

hedora wrote: post #55
rkangel wrote: post #4

It's nice to see a balanced, real world, case study including 'these things are fixed by Rust', 'these are problems that don't occur in idiomatic Rust', and 'these are problems that Rust can't help you with'. I'm a big fan of Rust, but the one sided 'Rust makes all the problems go away' articles don't provide any value.

Overall, it did a decent job of being balanced, but I don’t buy the memory overflow example at all. For one thing, idiomatic C++ bounds checks by default. You need to use at(). If you don’t like typing at(), you can implement an array type that always bounds checks fairly easily. On that note, the vulnerable c++ code should be using accessors, not indexing to access the oddly packed and laid out array. Even the fixed…

> For one thing, idiomatic C++ bounds checks by default. You need to use at().

Sounds like it doesn't check by default then. It checks if you remember to check using the more verbose bounds-checking method. Not unlike the issues with subscripting std::map.

Re: Implications of Rewriting a Browser Component in Rust

#60

Post by jupp0r »

One of the major hurdles in rewriting parts of C++ projects in Rust is that the interop surface between both languages is C. The necessary interface layer has created more bugs and work than the conversion saved. I'd really like to see more high-level interoperability between the two languages in the future, although C++ is a pretty fast-moving target at this point, with all the changes in C++20.
Post reply on HN