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

21–30 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#21

Post by alkonaut »

rkangel wrote: post #15
pimeys wrote: post #10

Earlier quoted context omitted.

I've built now several concurrent services with Rust. The language definitely gives confidence to try several things with different approaches to concurrency. None of my services crash (except once per 3-4 months when I deployed something "that will never crash" using `.unwrap()`). The crashes are always my own laziness, but if I follow the pattern of checking return values and unwraping only when the input is static…

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…

I think the use of the term "crash" varies. While it's true for e.g. a C program that there are better or worse crashes, in most other modern langs with some more safety guarantees, the term "crash" is normally used for controlled program termination due to unhandled exceptions.

So coming from that type of language (where you can't segfault) I'd definitely call a panic a "crash" simply because it's the analog of an unhandled exception, which I always called a crash.

So this terminology probably varies between ecosystems

Re: Fearless Concurrency in Firefox Quantum

#22

Post by sgift »

rkangel wrote: post #15
pimeys wrote: post #10

Earlier quoted context omitted.

I've built now several concurrent services with Rust. The language definitely gives confidence to try several things with different approaches to concurrency. None of my services crash (except once per 3-4 months when I deployed something "that will never crash" using `.unwrap()`). The crashes are always my own laziness, but if I follow the pattern of checking return values and unwraping only when the input is static…

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.

Re: Fearless Concurrency in Firefox Quantum

#23

Post by nickik »

simias wrote: post #14
margorczynski wrote: post #13

From the article it seems Rust is really a great replacement for C++ and all it's complexity and quirks. I wonder how many other C++ projects are considering moving to it, anyone know about any major one like FF?

I'm a former C++ dev who went all in on Rust. I think the main problem is that the learning curve works in Rust's disadvantage here. If you start learning C++ it's relatively smooth sailing at first, especially if you're already familiar with C. Basic OOP, basic RAII, inheritance, virtual functions, basic templates. Easy peasy. It's once you start getting to the advanced topics that the footguns become apparent. The…

As somebody who tried his hands on C++ a couple of times only I have to say that basic RAII, templates and virtual functions are not really easy. I mean maybe compared to even worse stuff in C++, but compared to almost every other language, they are still a pain.

Re: Fearless Concurrency in Firefox Quantum

#24

Post by Santosh83 »

MaxBarraclough wrote: post #17
ape4 wrote: post #11

The new Firefox is actually faster.

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 57 and beyond as a quantum leap from before. They did after all let go of XUL overnight, and people do praise its speed overnight. :-)

Re: Fearless Concurrency in Firefox Quantum

#25

Post by s_kilk »

MaxBarraclough wrote: post #17
ape4 wrote: post #11

The new Firefox is actually faster.

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.

Firefox was, up until today, noticeably slower than Chrome. Today it's faster.

Re: Fearless Concurrency in Firefox Quantum

#26

Post by lucozade »

adrianN wrote: post #18
simias wrote: post #14

Earlier quoted context omitted.

I'm a former C++ dev who went all in on Rust. I think the main problem is that the learning curve works in Rust's disadvantage here. If you start learning C++ it's relatively smooth sailing at first, especially if you're already familiar with C. Basic OOP, basic RAII, inheritance, virtual functions, basic templates. Easy peasy. It's once you start getting to the advanced topics that the footguns become apparent. The…

Already basic C contains more than enough footguns. If you think basic C++ is relatively free of footguns you're kidding yourself. Rust has a steep learning curve because the compiler nags you a lot about things that would have been a potential footgun in C. Unfortunately it is not smart enough to see in all cases that your code wouldn't have triggered that particular footgun and has to be overly conservative.

Not to belabour the metaphor or anything but if your footartillery doesn't fire, you still have feet.

This is probably the point that simias is making and I tend to agree. It's straightforward to get a simple C++ program working with decent performance if you know C. And RAII, std::vec etc makes you feel quite productive.

Now, at some point you'll notice that debug and release don't act the same way. Occasionally. Or you try to add threading to a single-threaded program. Then the love will die (due to bloodloss from blowing off the whole leg). But that's often after months of reasonably productive development.

Rust, to a large extent, will prevent you from ever getting to that state and that's a very good thing. But the upfront cost is quite high. My guess is that those of us who have experienced the C++ pain will appreciate the value that that cost is buying.

But I'm hopeful that Rust will draw a wider audience primarily because of your last point. It's really quite conservative at present. The NLS work is already expanding the scope of acceptable programs and, I presume, that what is learnt from that effort will seed further work in that space.

Re: Fearless Concurrency in Firefox Quantum

#28

Post by nikbackm »

asadjb wrote: post #19
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.

Anecdotal evidence, so take it with a grain of salt. I switched to Firefox 2 days ago, after reading a post about how Firefox has recently got faster. I have been a Chrome user for more than a couple of years now, when I switched from Firefox because it was slow in comparison. After using Firefox for 1 day, it already seemed slower than what I was used to in Chrome. This was most noticeable on ad-laden sites that dis…

Why did you switch 2 days ago instead of waiting for 57?

Just a co-incidence?

Re: Fearless Concurrency in Firefox Quantum

#29

Post by Argorak »

deckarep wrote: post #5
Argorak wrote: post #3

Earlier quoted context omitted.

Rust only saves you from simple races, not more complex ones. That's quite a lot already. Most importantly, though, it preserves _memory safety_ in concurrent situations, so your stuff won't randomly crash, but properly panic. It's no silver bullet, but it _is_ the "magic sauce" behind Stylo.

I’m pretty sure Rust saves you from ALL data races so long as you stay within the boundaries of safe code. Do you have anything at all to reference otherwise that says only certain data races are detected while others are not? To my knowledge you can defeat the compile-time data race detection if you are either doing unsafe or certain scenarios with Cell/RefCell but even in that case you are guaranteed runtime detect…

qznc puts that better then I do. It saves you from data races, but not from race conditions.

Cell and RefCell are both not Sync (that means they can't be used from multiple threads) for a reason. RefCell does, however, allow borrow checking at runtime, for wrapping it with something that establishes Sync.

Re: Fearless Concurrency in Firefox Quantum

#30

Post by throwaway613834 »

Could someone give a very simple, to-the-point example of a kind of concurrency bug that Rust prevents, for those of us who don't know Rust? (The author explicitly fails to think of any, so I'm hoping someone else can. It'd be more convincing to see one.)

EDIT: I meant a code example, not a paragraph. And I would obviously expect to see how the intended goal is achieved without the bug... otherwise it'd be trivial to prevent any bug (just make everything impossible).

Post reply on HN