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

Fearless Concurrency in Firefox Quantum

blog.rust-lang.org

Post reply on HN
Print view View original

91–100 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#91

Post by Crespyl »

sgift wrote: post #22
rkangel wrote: post #15

Earlier quoted context omitted.

Note that the panic you get by calling unwrap() where you shouldn't isn't a crash. It's a controlled program exit due to an unexpected condition. While yes, the panic will cause your program to stop, it will do it in a clean deterministic way (with a backtrace). Actual crashes (due to segfaults) can happen a long way from the bug that actually caused the issue, can happen intermittently and generally be a nightmare t…

IMO it is good to call this a crash in the sense of fail-fast. Then you do not get into the "but my program doesn't run anymore after that, what do you mean that's not a crash" discussion. But it is not undefined behavior. It crashes _all the time_ in that situation, which makes life so much easier than UB.

Perhaps it's an "emergency landing".

Re: Fearless Concurrency in Firefox Quantum

#92

Post by throwaway613834 »

maffydub wrote: post #46
throwaway613834 wrote: post #41

Earlier quoted context omitted.

Thanks (upvoted)! However how in the world would the compiler know if the mutex belongs to the same vector you are accessing? (Unless you're saying the mutex wraps the vector implying that each vector can have one corresponding mutex at most? Which seems quite limiting?)

Thanks! Yes, when you construct a mutex, you give it ownership of the vector you want it to protect. Due to the way Rust works, once you've given ownership to something else, you can no longer access it yourself. The only way you can get access to the data again is to "borrow" a reference to it, but this borrow has a "lifetime", which is tied to the period for which you're holding the mutex. This is how the compiler…

Yeah that makes sense! It strikes me as pretty similar to volatile-correctness in C++ (it's a technique -- look it up if you haven't heard of it) with the additional constraint that there is only ever one mutable reference, for better or for worse.

Re: Fearless Concurrency in Firefox Quantum

#93

Post by zellyn »

jsf666 wrote: post #7

> It replaces approximately 160,000 lines of C++ with 85,000 lines of Rust Wow! This is great, especially considering how bad and complex (in the bad sense) C++ is. Maybe Rust and Go will finally make the Frankenstein go to sleep

Is this reduction in line count typical? I'm surprised. Or is this discounting parts of the code that have been moved out into separate crates?

Re: Fearless Concurrency in Firefox Quantum

#94

Post by Crespyl »

Santosh83 wrote: post #24
MaxBarraclough wrote: post #17

Earlier quoted context omitted.

My only complaint is the marketing. Firefox isn't slow, sure enough. But it wasn't slow last week either. I've been using it as my primary browser for a long time, and performance was never an issue. Also, 'Quantum'? Come on now. If they're aiming Firefox at power-users (which they should be), they should know that kind of buzzword abuse is only going to annoy.

Agree about marketing. Mozilla needs to get the word out to those who don't follow the tech scene in any way, shape or form. That's the real challenge, but there also lie the bulk of its potential user base. Not sure exactly how they can do that without resorting to annoying, almost sleazy stuff that Google do (like bundling their browser with many other s/w and OEM system builders)... Quantum... I like to think of 5…

> quantum leap from before

So, the smallest possible leap? :P

I like to think that it's loosely related to the multithreaded work-stealing features, breaking as much as possible up into "quanta" of work to be grabbed by the next available thread.

It's a decently memorable codename in any case, and works well enough for that purpose.

Re: Fearless Concurrency in Firefox Quantum

#95

Post by nickpsecurity »

rbehrends wrote: post #49
throwaway613834 wrote: post #40

Earlier quoted context omitted.

> Rust doesn't allow having two mutable references to the same memory location at the same time, so you would never encounter that. Wouldn't that make a whole class of efficient algorithms impossible though? Like let's say you have an std::list and you want a sorted "view" of the elements. In C++ you'd create an array of pointers and then sort it, and after that you can just modify whatever each slot points to. In Ru…

> Wouldn't that make a whole class of efficient algorithms impossible though? Correct. What it does is prevent data races; this is per se nothing new, but was done as early as the 70s [1]. There've been various and sundry approaches to the same problem over the years (the 90s and early aughts produced a lot of research in this area). In a way, it is frustrating that so few programming languages offer prevention of da…

I'll add SCOOP to your list since it was commercially deployed as part of Eiffel. I'll throw in the Eiffel paper from the 1980's for people curious about the overall language and methodology.

https://www.eiffel.org/doc/solutions/Concurrent%20programmin...

http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf

http://www.eiffel.com/developers/design_by_contract_in_detai...

Since they have strong QA focus, they also have things like test generation from contracts specifying intended behavior. So, safe concurrency was just one benefit of the work that started in the 1980's. Rust takes things further with a simpler and more flexible approach that supports quite a few different styles of concurrency. That's on top of the temporal safety inspired by the Cyclone language for safe, C-like programming.

Rust's real success is it's the first of the safe, system languages to take off with a massive ecosystem due to their great community efforts. That's probably what Ada and Eiffel needed on top of earlier FOSS implementations.

Re: Fearless Concurrency in Firefox Quantum

#96

Post by kbenson »

StavrosK wrote: post #50
ekidd wrote: post #45

Earlier quoted context omitted.

I've spent the last few days aggressively parallelizing some Rust code with crossbeam, and it's really just... painless (once you're used to Rust). Rust actually understands data races, and it grumbles at me until my code is provably safe, and then everything Just Works. The Rayon library is also lovely for data parallelism. Sometimes, I think, "Rust is basically a nicer C++ with the obvious foot guns removed and gre…

> painless (once you're used to Rust) This needs to be Rust's motto or something.

Rust: Front-loading the pain so the rest is relatively easy. Just like High School. ;)

Re: Fearless Concurrency in Firefox Quantum

#97

Post by steveklabnik »

Zenbit_UX wrote: post #58
wtetzner wrote: post #47

Earlier quoted context omitted.

But was the existing code base that was replaced running concurrently?

I'd love to know what this concurrency thing is and why it's so fearless in rust.

https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... Is from just before 1.0, and so is slightly dated in some ways (scoped threads are in a package, not in std) but should give you some explanation.

Re: Fearless Concurrency in Firefox Quantum

#98

Post by Analemma_ »

tareqak wrote: post #83

Congratulations to the Mozilla and Rust teams! Accounts like this one really help people who advocate investing in and building new tools to help against the heavy-handed application of phrases like "a bad workman always blames his tools" [0][1]. [0] https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h... [1] https://en.oxforddictionaries.com/definition/a_bad_workman_a... Edit: formatting and typo

I hate that phrase and its reflexive usage so much. Yes, a bad workman blames his tools, but so does a good workman using lousy tools.

Re: Fearless Concurrency in Firefox Quantum

#99

Post by chowells »

Analemma_ wrote: post #98
tareqak wrote: post #83

Congratulations to the Mozilla and Rust teams! Accounts like this one really help people who advocate investing in and building new tools to help against the heavy-handed application of phrases like "a bad workman always blames his tools" [0][1]. [0] https://en.wiktionary.org/wiki/a_bad_workman_always_blames_h... [1] https://en.oxforddictionaries.com/definition/a_bad_workman_a... Edit: formatting and typo

I hate that phrase and its reflexive usage so much. Yes, a bad workman blames his tools, but so does a good workman using lousy tools.

You can respond with "that's because a good workman doesn't use poor tools."

It nicely suggests that maybe it's the programmer's responsibility to advocate for something better.

Re: Fearless Concurrency in Firefox Quantum

#100

Post by naasking »

StavrosK wrote: post #50
ekidd wrote: post #45

Earlier quoted context omitted.

I've spent the last few days aggressively parallelizing some Rust code with crossbeam, and it's really just... painless (once you're used to Rust). Rust actually understands data races, and it grumbles at me until my code is provably safe, and then everything Just Works. The Rayon library is also lovely for data parallelism. Sometimes, I think, "Rust is basically a nicer C++ with the obvious foot guns removed and gre…

> painless (once you're used to Rust) This needs to be Rust's motto or something.

> This needs to be Rust's motto or something.

Rust: climb that mountain so you can see further.

Post reply on HN