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

271–279 of 279 posts

Re: Implications of Rewriting a Browser Component in Rust

#271

Post by int_19h »

atoav wrote: post #231
int_19h wrote: post #197

Earlier quoted context omitted.

I wonder if it has something to do with the nature of the problems. Rust can be very smooth or a real pain, depending on the data structures you need to model - basically, whenever ownership is unclear and sharing is common, it's going to be more painful.

Usually that just means you have to think much harder about the problem you are trying to solve within the new set of requirements (borrow checker, lifetimes). Weirdly enough these things should also be a hard problem in other non-Garbagecollected languages, but you get away with a lot more when the compiler doesn’t force you. From a purely practical level there is so much already that I had a hard time finding some…

> Weirdly enough these things should also be a hard problem in other non-Garbagecollected languages, but you get away with a lot more when the compiler doesn’t force you.

It's the same as with static vs dynamic typing - some things are just easier to model with dynamic, because you don't have to fight with the type checker to prove that your program really is sound when you know that it is. But, of course, you might believe it to be sound when it really isn't...

Re: Implications of Rewriting a Browser Component in Rust

#272

Post by igouy »

pjmlp wrote: post #215
galangalalgol wrote: post #189

Earlier quoted context omitted.

I knew you could turn off the runtime but not about the formal verification lint tools that make it safe to do so. My reference for performance is the benchmark game. If you or someone else can mod those programs to beat rust I'd be thrilled. I like Ada.

Many planes, trains, rockets and medical devices run on Ada. There is more to commercial compilers than winning the benchmarks game.

For sure.

The benchmarks game is just an easily available source of examples.

Which, for instance, may show an Ada program with much the same measured time as a Rust program —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: Implications of Rewriting a Browser Component in Rust

#273

Post by Sharlin »

asdkhadsj wrote: post #264
Sharlin wrote: post #173

Earlier quoted context omitted.

> I find it odd that some things like slice reads can still panic by default. Yes, I can use `foo.get(1)` to avoid panics, but still - it's a bit odd to me. Panicking is a perfectly good way to handle the situation where an invariant of the program is violated. That is, it is perfectly fine to index using [] in cases where there cannot possibly be an out-of-bound access unless the program has a logic bug . And if it…

I don't understand, tbh. Eg does Rust not make great effort to prevent null pointer exceptions? OOB feels quite similar to null pointer. It's strange to me because a lot of what I value in Rust is writing code that handles all outcomes safely and with confidence. Yet that all seems to be out the window if you access array values - as it may or may not work. The safety of [] slice/array access is entirely up to how th…

The usage pattern is somewhat different. The primary problem with null references in languages such as Java is that they are not opt-in, and they're not even opt-out! That is to say, you don't even have an option (heh!) to encode in the type system the fact that a reference is never null. What's worse, references tend to get passed around a lot, and stored inside objects, and programmers are lazy and don't assert or even think about preconditions, so the root cause of an unexpected NPE can be far removed from the code that finally triggers it.

With code that indexes slices, the index computation is usually much more proximate to the actual indexing operation. If ensuring the validity of the index is about upholding an invariant internal to the module, it makes no sense to return an "sorry, I have a bug" error to the caller if that invariant fails to hold. What would the caller do about that?

Re: Implications of Rewriting a Browser Component in Rust

#274

Post by [deleted] »

igouy wrote: post #270
johnisgood wrote: post #268

Earlier quoted context omitted.

No worries. I got rid of the unnecessary `range' in the last version, but it does not matter much anyway.

My guess is that the Ada regex-redux #6 program is also easily fixable: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... :and there's a working Ada regex-redux #5 program: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[deleted]

Re: Implications of Rewriting a Browser Component in Rust

#275

Post by empath75 »

scoutt wrote: post #257
empath75 wrote: post #253

Earlier quoted context omitted.

That's still a bug. I feel like you're being intentionally obtuse about what's considered to be a security problem in code. Nobody ever suggested that rust code can never crash or have bugs. It's just about memory safety, which obviously has nothing to do with door locks.

Sorry if I gave that impression. It was not my intention. > A crash is a bug but not a security problem. I think that all bugs, the ones that produces crashes and security bugs should be all treated equally. A bug is a bug, whenever it has security implications or not. To me, the article gives the impression that a system crash is not a security problem, because a Rust program will "terminate in a controlled fashion,…

Security problems are bugs but not all bugs are security problems.

Re: Implications of Rewriting a Browser Component in Rust

#276

Post by sanderjd »

asdkhadsj wrote: post #264
Sharlin wrote: post #173

Earlier quoted context omitted.

> I find it odd that some things like slice reads can still panic by default. Yes, I can use `foo.get(1)` to avoid panics, but still - it's a bit odd to me. Panicking is a perfectly good way to handle the situation where an invariant of the program is violated. That is, it is perfectly fine to index using [] in cases where there cannot possibly be an out-of-bound access unless the program has a logic bug . And if it…

I don't understand, tbh. Eg does Rust not make great effort to prevent null pointer exceptions? OOB feels quite similar to null pointer. It's strange to me because a lot of what I value in Rust is writing code that handles all outcomes safely and with confidence. Yet that all seems to be out the window if you access array values - as it may or may not work. The safety of [] slice/array access is entirely up to how th…

I think the slightly odd or inconsistent thing is that rust has [] at all. I think of it as a compromise for people's familiarity with the operator. And if that's all it is, it makes sense that it behaves the way it does; I think a panic is more similar to what other languages with that operator do with an out of bound index than returning Option would be.

Re: Implications of Rewriting a Browser Component in Rust

#277

Post by sanderjd »

yjftsjthsd-h wrote: post #184
asdkhadsj wrote: post #84

Earlier quoted context omitted.

Agree completely. For a bit of my own story, a year+ ago I had the option to write a project in Rust and evaluated it vs Go. Long story short, I tried rust, and it was a massive headache and I failed. We used Go (as I had been for ~4 years). Fast forward to ~2 months ago, a work project dictated tight control over memory which, while possible in Go, had me looking at alternatives. I decided to give Rust another try.…

> I have no understanding why last time was so painful, and this time it's been so amazing. It has been my experience that if I try to learn something hard and give up and then come back to it a few months later, I have a way easier time even with no apparent changes in process. I suspect some of it is giving your brain time to process fundamentals or something.

This seems true and unsurprising - it strikes me as being similar (or identical) to spaced repetition, which is a powerful learning technique.

Re: Implications of Rewriting a Browser Component in Rust

#278

Post by ShinTakuya »

baroffoos wrote: post #207
Twirrim wrote: post #205

Earlier quoted context omitted.

Use a linter. Most IDEs will do it for you natively, and even if you're dealing with a terminal based editor like vim, it's really easy to get the output of pylint, flake8 etc. running in it. It's extremely rare I ever get a syntax error make it through to code review, let alone build/deploy.

Linters catch the easy cases but when the problem spans multiple files they have no clue what is going on.

The mypy type linter performs type checking across files, in many cases even without explicit annotations.

Re: Implications of Rewriting a Browser Component in Rust

#279

Post by indolering »

dmix wrote: post #201
eridius wrote: post #179

Earlier quoted context omitted.

What confuses me about this is the tests were turned off because they were taking too long. But wouldn't the appropriate behavior there be "run a subset of the tests normally, but run the full test suite occasionally" rather than just disabling the tests completely?

Or turn off some during development but run the whole suite before release? I have a feeling the a bunch of the tests in that particular category needed to be updated, so it wasn't simply just too long.

Pretty clear that the QA process is at fault here, which is sadly common in the software industry.
Post reply on HN