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

31–40 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#31

Post by Yoric »

vaylian wrote: post #11
Eridrus wrote: post #5

Earlier quoted context omitted.

I haven't written any Rust in a few years, but last I knew, it was very possible for a Rust program to crash. The guarantee is that it won't corrupt memory while doing so.

There are different reasons why a program can crash. Nullpointer exceptions are one of them. Out-of-memory situations are another. Rust protects you against the former, but not the latter. But at least in my experience I only encountered crashes when I disabled safety checks by calling .unwrap().

Not exactly "disabled safety check": `unwrap()` is an assertion check (that may sometimes be optimized away by the compiler). You're still checking safety, but you're doing it in a much more terminal manner.

Re: Implications of Rewriting a Browser Component in Rust

#32

Post by firebird84 »

latencyloser wrote: post #20
orf wrote: post #3

Earlier quoted context omitted.

Nullpointer exceptions are a huge thing in Java.

I write Java daily, I haven't seen one in a production environment in... at least recent memory. Most common NPEs I've seen can be resolved by doing two things: 1) for returning a single, nullable value, wrap it in Optional. 2) Never return null collections, always default to an empty collection instead. More nuanced ones can often be caught by using all args constructors and requiring the constructor values with Obj…

Can also use checkerframework to statically analyze your code for NPEs. It effectively augments the type system to require you to handle nulls where appropriate. It doesn't recognize I/O boundaries for you, you have to make sure those are annotated properly, but after that with sensible defaults, you can be more confident of the NPE-free-ness of your code.

Re: Implications of Rewriting a Browser Component in Rust

#33

Post by duxup »

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 at some point I want to see those same articles about real world use / experiences. I'm aware Mozilla and others are using it.

Re: Implications of Rewriting a Browser Component in Rust

#34

Post by bluejekyll »

latencyloser wrote: post #20
orf wrote: post #3

Earlier quoted context omitted.

Nullpointer exceptions are a huge thing in Java.

I write Java daily, I haven't seen one in a production environment in... at least recent memory. Most common NPEs I've seen can be resolved by doing two things: 1) for returning a single, nullable value, wrap it in Optional. 2) Never return null collections, always default to an empty collection instead. More nuanced ones can often be caught by using all args constructors and requiring the constructor values with Obj…

> I think they're relatively simple to avoid?

Most issues in software fall into this category, though. The issue with Java’s null is that it’s not type safe. The language is generally a strongly typed language, except in the case of null. And until Value Types land, there is no way to express nullability to the compiler.

The arguments you make aren’t all that different than the undefined behavior arguments with C. “Just follow these simple rules and you’ll avoid all issues”, a compiler should do that for you IMO.

I can’t wait for Value Types in Java, at that point we can have real Option types.

Re: Implications of Rewriting a Browser Component in Rust

#35

Post by millstone »

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.

These are all ways that Rust is neutral or better. Were there any ways that Rust was worse? For example, did the previous code use value-type templates? If so how was their absence worked around in the new code?

Re: Implications of Rewriting a Browser Component in Rust

#36

Post by amalcon »

jononor wrote: post #17
vaylian wrote: post #11

Earlier quoted context omitted.

There are different reasons why a program can crash. Nullpointer exceptions are one of them. Out-of-memory situations are another. Rust protects you against the former, but not the latter. But at least in my experience I only encountered crashes when I disabled safety checks by calling .unwrap().

unwrap() does not disable safety checks, it just means you ignore/disregard error handling. It will panic and abort the program, but not cause a safety issue. /pedantic

This is actually an interesting distinction. The way that Rust defines "safety" is a little jargon-ish. It's probably more useful than the (highly impractical) colloquial meaning, but still different. In a rust context, "safety" means that the program is protected from a very specific set of things.

One might expect that set to contain things like crashing (panic! and friends) and leaking memory (forget). It does not, and is not intended to.

Re: Implications of Rewriting a Browser Component in Rust

#37

Post by Filligree »

rocqua wrote: post #18
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.

Speculative execution and branch prediction make bound-checks much less of a burden. I believe this is actually a whole category of Spectre/Meltdown.

It is. As you say, there's a category of Spectre bugs where the CPU speculatively assumes a bounds check succeeds, then goes on to execute attacker-provided code.

Re: Implications of Rewriting a Browser Component in Rust

#38

Post by blub »

sciurus wrote: post #16
blub wrote: post #8

Earlier quoted context omitted.

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.

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

Re: Implications of Rewriting a Browser Component in Rust

#39

Post by [deleted] »

dotancohen wrote: post #29
latencyloser wrote: post #20

Earlier quoted context omitted.

I write Java daily, I haven't seen one in a production environment in... at least recent memory. Most common NPEs I've seen can be resolved by doing two things: 1) for returning a single, nullable value, wrap it in Optional. 2) Never return null collections, always default to an empty collection instead. More nuanced ones can often be caught by using all args constructors and requiring the constructor values with Obj…

I suppose that you are being downvoted because, though your arguments are correct, this thread is not about "how to avoid NPEs in Java" and is therefore OT. That said, "write good tests" is impossible. You can write as many tests as you want, you can make sure those loops loop or don't, and those ifs if or don't, but you cannot write "good" tests. Tests will always miss some corner case, some input, some unexpected l…

[deleted]

Re: Implications of Rewriting a Browser Component in Rust

#40

Post by ianlevesque »

mrath wrote: post #2

I primarily use Java for my job. Security and memory related features of Rust are not an advantage compared to Java. But I like rust because it feels modern and produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…

I use Java constantly in my job and recently tried rewriting a math & memory heavy component in rust to see what performance gains there might be. Surprisingly (to me) the naive rust version was ~15% slower than Java. There’s probably room for more rust optimization but it was interesting that “efficient standalone binaries” doesn’t automatically mean faster too when competing with HotSpot.
Post reply on HN