Implications of Rewriting a Browser Component in Rust • Hacker News Board

Re: Implications of Rewriting a Browser Component in Rust

#11

Post by vaylian » Thu, Feb 28, 2019, 3:34 PM UTC

Eridrus wrote: post #5

orf wrote: post #3

Earlier quoted context omitted.

Nullpointer exceptions are a huge thing in Java.

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

Re: Implications of Rewriting a Browser Component in Rust

#12

Post by tspiteri » Thu, Feb 28, 2019, 3:35 PM UTC

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.

This comment is confusing two completely separate concepts: zero cost abstractions and run time bounds checks. Rust does provide zero cost abstractions: if you do something explicitly/manually instead of using the abstraction you get the same generated code.

If you want to combine the two concepts, I guess you could go for an example like this:

    if index >= vec.len() {
        panic!("out of bounds");
    }
    let value = unsafe { vec.get_unchecked(index) };

which can be rewritten using higher level abstractions as:

    let value = vec[index];

The second is more abstract, and that abstraction is zero cost, you do not pay for using the abstraction more than the explicit code above it.

Re: Implications of Rewriting a Browser Component in Rust

#13

Post by jjnoakes » Thu, Feb 28, 2019, 3:36 PM UTC

Eridrus wrote: post #5

orf wrote: post #3

Earlier quoted context omitted.

Nullpointer exceptions are a huge thing in Java.

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.

It is possible, but the causes and frequencies are quite different.

In Rust runtime panics are certainly possible (array out of bounds, out of memory, etc), but the ones analogous to Java's NullPointerException have to be explicit opted into (unwrapping optionals) and do not happen implicitly.

Rust lets you handle optionals in nicer ways which lets you be sure you covered the "null" cases at compile time with no runtime panics possible, if you like.

Re: Implications of Rewriting a Browser Component in Rust

#14

Post by blub » Thu, Feb 28, 2019, 3:40 PM UTC

rat9988 wrote: post #10

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.

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

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

Re: Implications of Rewriting a Browser Component in Rust

#15

Post by mrath » Thu, Feb 28, 2019, 3:41 PM UTC

Eridrus wrote: post #5

orf wrote: post #3

Earlier quoted context omitted.

Nullpointer exceptions are a huge thing in Java.

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.

I think that is somewhat related to the article. There a class of bugs not possible in Rust, they are also not possible in my GCed langs. unwrapping an `Option` is similar to NPE. but that code does not feel idiomatic Rust. IMO there is higher chance of making NPE mistake in Java than unwrapping None in Rust for similar logic.

Re: Implications of Rewriting a Browser Component in Rust

#16

Post by sciurus » Thu, Feb 28, 2019, 3:44 PM UTC

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.

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

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

Re: Implications of Rewriting a Browser Component in Rust

#17

Post by jononor » Thu, Feb 28, 2019, 3:52 PM UTC

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

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

Re: Implications of Rewriting a Browser Component in Rust

#18

Post by rocqua » Thu, Feb 28, 2019, 3:57 PM UTC

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.

Re: Implications of Rewriting a Browser Component in Rust

#19

Post by mitchty » Thu, Feb 28, 2019, 3:58 PM UTC

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.

You can't know everything at compile time. Runtime checks are witnesses that run at program execution instead of compile time.

Re: Implications of Rewriting a Browser Component in Rust

#20

Post by latencyloser » Thu, Feb 28, 2019, 3:59 PM UTC

orf wrote: post #3

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…

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 Objects.requiresNonNull() or similar. Using spring? Don't use field or setter injection, always constructor so the above applies as well. Making the state of your objects largely immutable means their state is more consistent and what is null and when becomes a lot less surprising.

Lastly, write good tests. If you're exhausting the behavior of your system with tests, these things are much less likely to surprise you later.

NPEs are definitely a problem with Java, but they're a very avoidable one as well.

Edit: I don't understand the downvotes. The parent said they're a huge deal and I'm disagreeing because I think they're relatively simple to avoid?