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

Re: Implications of Rewriting a Browser Component in Rust

#101

Post by atoav » Thu, Feb 28, 2019, 6:39 PM UTC

amalcon wrote: post #36

jononor wrote: post #17

Earlier quoted context omitted.

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…

I think safety is about risk managment. Having a seatbelt on in a car is safer than not having one. This is despite the fact that most regular people really don’t desire crashing their car. By putting on a seatbelt you pay a small prize to weaken the impact of a existing risk (crashing your car).

Rust’s idea of safety is similar: it tries to reduce the impact of common risks that happen during programming. It won’t save you from logical errors — just like a seatbelt won’t save you when you decide to maneuver your vehicle into a flaming pit of lava. The only thing that would save you in that situation is not maneuvering into flaming lava pits.

That beeing said rust has a very straightforward implementation for Unit Tests and Integration tests which could help you dealing with remaining risks.

Of course you can always live on the edge, ignore seatbelts and do things like calling unwrap() on results that might not retun Ok(value) at all times. But that will bite you sooner than later.

What Rust is really good at IMO, is to make risks clear at any givrn moment in time. The routes your program can take are very well represented, especially because of the ownership model. Once you understood it you can make very strong assumptions about which part of the software is manipulating which data. These strong assumptions also help mitigating risk. It is harder in Rust to do things just wrong than in most other languages and it is still fast

Re: Implications of Rewriting a Browser Component in Rust

#102

Post by c3534l » Thu, Feb 28, 2019, 6:40 PM UTC

johnisgood wrote: post #90

atoav wrote: post #72

This is in tune with my own experience using Rust in production: it can stop you from doing certain classes of mistakes, but it won't stop you from doing stupid things. But the idea that I don't have to think about certain classes of problems allows me to give these stupid things more focus, which is surprisingly refreshing. The predictable nature of Rust was so refreshing for me that I ended up using it even for sma…

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

I assumed borrowing and lifetimes were part of his experience as well.

Re: Implications of Rewriting a Browser Component in Rust

#103

Post by jhrmnn » Thu, Feb 28, 2019, 6:46 PM UTC

johnisgood wrote: post #90

atoav wrote: post #72

This is in tune with my own experience using Rust in production: it can stop you from doing certain classes of mistakes, but it won't stop you from doing stupid things. But the idea that I don't have to think about certain classes of problems allows me to give these stupid things more focus, which is surprisingly refreshing. The predictable nature of Rust was so refreshing for me that I ended up using it even for sma…

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

And with something like Mypy, you can get most of the benefits of static typing even in Python, if you want to. But Rust has so much more to offer, such as memory ownership.

Re: Implications of Rewriting a Browser Component in Rust

#104

Post by matthewmacleod » Thu, Feb 28, 2019, 6:46 PM UTC

johnisgood wrote: post #90

atoav wrote: post #72

This is in tune with my own experience using Rust in production: it can stop you from doing certain classes of mistakes, but it won't stop you from doing stupid things. But the idea that I don't have to think about certain classes of problems allows me to give these stupid things more focus, which is surprisingly refreshing. The predictable nature of Rust was so refreshing for me that I ended up using it even for sma…

> before but soon got annoyed with obvious errors that would only show up once you run a program. From what I gather you are comparing static vs dynamic typing, and I agree. I do not use Python because I prefer a subset of errors caught at compile-time. However, it is silly to make it sound like that this is somehow limited to Rust. You could just as well have used Go or OCaml and feel "refreshed" because obvious err…

That’s one aspect of the errors that are avoided, but there are many others too - some of which aren’t solved by other languages. Go, for example, will happily nail through all of your obviously null pointers with gay abandon. The Rust ownership model prevents other classes of bugs.

It’s not a panacea—and to be blunt, I find Rust more work than it is worth for the sort of projects I typically work on. But any tools which can eliminate whole error categories are worth looking at for sure!

Re: Implications of Rewriting a Browser Component in Rust

#105

Post by jcranmer » Thu, Feb 28, 2019, 6:50 PM UTC

jupp0r wrote: post #60

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.

Honestly, I wish a few different major languages would get together and start developing system ABIs that move beyond C as the interchange language.

Re: Implications of Rewriting a Browser Component in Rust

#106

Post by ilovecaching » Thu, Feb 28, 2019, 6:50 PM UTC

Rust is often sold feature by feature; the borrow check offers proof like safety over fuzzing, cargo provides real versioned package management over makefiles or git commits...

I choose Rust because taken as a whole, Rust changed the way I approached laying out my memory and how I composed my code. I think this more than anything leads to less issues than the equivalent C++. The article points out that a Rust vs C++ solution to any given problem are going to be completely different.

My only desire for Rust is to see compile times speed up and the C++ interop to improve.

Re: Implications of Rewriting a Browser Component in Rust

#107

Post by pum-purum » Thu, Feb 28, 2019, 6:51 PM UTC

millstone wrote: post #35

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?

Compile time. For my 9k lines project it takes 20 sec to compile in debug mode and 1 minute in release. Wich is insane because I have to do a lot of runs to test things(where cargo check can't help).

Re: Implications of Rewriting a Browser Component in Rust

#108

Post by FreeFull » Thu, Feb 28, 2019, 6:52 PM UTC

svnpenn wrote: post #99

masklinn wrote: post #83

Earlier quoted context omitted.

> I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. Everybody knows you're supposed to check pointers for being null, and yet time and time again developers fail. As long as you rely on human nature and provide one API which is simple, convenient, obvious and dangerous and one which is complex, inconven…

this is so true and has been my experience with unwrap they dont want people to use it but the alternative is so verbose and clunky

The alternative tends to be to propagate the error upwards using the `?` operator, up to some point where it makes sense to handle errors

Re: Implications of Rewriting a Browser Component in Rust

#109

Post by steveklabnik » Thu, Feb 28, 2019, 6:56 PM UTC

esrauch wrote: post #82

tspiteri wrote: post #12

Earlier quoted context omitted.

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 { v…

What's an example of a language where the second would be more expensive than the first?

There are some languages where you cannot write the first yourself at all. Including leaving off the assert if you know better than the compiler.

Re: Implications of Rewriting a Browser Component in Rust

#110

Post by barrkel » Thu, Feb 28, 2019, 6:56 PM UTC

FreeFull wrote: post #108

svnpenn wrote: post #99

Earlier quoted context omitted.

this is so true and has been my experience with unwrap they dont want people to use it but the alternative is so verbose and clunky

The alternative tends to be to propagate the error upwards using the `?` operator, up to some point where it makes sense to handle errors

Aka exceptions.

Yes, chaps, that Result type is all but isomorphic with checked exceptions, Java-style.