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

121–130 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#121

Post by Manishearth »

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…

In systems contexts "crash" means sigsegv or sigill (but not e.g. an intentional abort)

In non-systems contexts it can just mean "premature termination". Rust, having both kinds of programmers, uses .... both :)

So a Rust panic is a crash, but so is a Rust segfault, depending on who you talk to.

Generally I try to explicitly say "panic" and "segfault".

Re: Fearless Concurrency in Firefox Quantum

#122

Post by Manishearth »

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

See also: https://www.schneems.com/2016/08/16/sharp-tools.html

Re: Fearless Concurrency in Firefox Quantum

#123

Post by Manishearth »

Zenbit_UX wrote: post #60
vatotemking wrote: post #38

Firefox Quantum is blazing fast, and I finally ditched Chrome. My only problem is that it drains my battery life fast. So whenever I'm not plugged I use Edge. Other than that, FF is amazing. It is now my default browser and I even wrote a FF add-on a few days ago using their new API!

As a front end Dev I'll never fully ditch Chrome as its Dev tools are vastly superior. I've tried the Firefox inspect menu and I'm just immediately turned off and confused.. However Firefox has been, and always will be my daily driver for all Web browsing. It's eco system is richer, noscript and the fact that it's not a Google product is a huge selling point.

Have you tried the new devtools in the recent release? I've heard folks like them a lot more.

Re: Fearless Concurrency in Firefox Quantum

#124

Post by Manishearth »

vatotemking wrote: post #82
timsayshey wrote: post #71

Earlier quoted context omitted.

Their devtools have come a long way. And are almost caught up with Chrome. I've only noticed the following things missing: When an XHR response comes back as HTML, there is no "Preview" tab like in Chrome. Also, the responsive testing tool doesn't have the device frames (ie, iPhone, iPad, etc) and it also doesn't have the little touch circle cursor that let's you drag and swipe while testing.

Perhaps you're on an older version of FF, no? Because the things you mentioned are present, just not an exact UI/UX as that with Chrome. Im on FF Quantum 57.0 (non dev, vanilla FF) and here are my observations: > When an XHR response comes back as HTML, there is no "Preview" tab like in Chrome. This is consolidated in the Response tab. You can view it as raw response, or JSON (with filtering options). > Also, the res…

For XHR there's also an "edit and resend" button as well as "copy as cURL" which is amazing

Re: Fearless Concurrency in Firefox Quantum

#125

Post by Manishearth »

Crespyl wrote: post #94
Santosh83 wrote: post #24

Earlier quoted context omitted.

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.

"quantum" doesn't mean "small".

"quantum leap" means an abrupt, large, leap.

See https://en.wiktionary.org/wiki/quantum_leap

Re: Fearless Concurrency in Firefox Quantum

#126

Post by vanderZwan »

kenhwang wrote: post #115
odabaxok wrote: post #80

Earlier quoted context omitted.

Here is a nice game about concurrency. It should answer your question why it should be feared by understanding how it works: https://deadlockempire.github.io/ As of my understanding it is fearless in Rust, because the problems that might came up are solved on language level or the compiler warns you about them. (I have never coded Rust, I just deduced this from the comments)

"Warn" is nicer phrasing than what the compiler actually does. Rust's compiler will straight up refuse to compile your code if it thinks it has a concurrency bug in it.

> if it thinks it has a concurrency bug in it.

This makes it sound like it is wrong sometimes. I'm not using Rust, if this is what you meant, could you give examples of that?

Re: Fearless Concurrency in Firefox Quantum

#127

Post by Manishearth »

twic wrote: post #35
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…

When this controlled program exit happens, does your monitoring system wake your operations staff up? If so, it's a crash.

In Rust a panic brings down a single thread (unless you have it set to panic=abort, which is the case in firefox but not elsewhere).

Panics can also be "caught" like exceptions, though this is not something you're supposed to use to implement exception handling. The idea is that if you want to make your application robust you can catch these panics near the top and try to recover.

Often panics bringing down a single thread will bring down other threads that try to read messages from it and have declared that they will panic if that is not possible. (.recv().unwrap() is a common idiom).

So it depends on how you use it.

And "monitoring system" is assuming the context of a server side application.

Re: Fearless Concurrency in Firefox Quantum

#129

Post by kenhwang »

vanderZwan wrote: post #126
kenhwang wrote: post #115

Earlier quoted context omitted.

"Warn" is nicer phrasing than what the compiler actually does. Rust's compiler will straight up refuse to compile your code if it thinks it has a concurrency bug in it.

> if it thinks it has a concurrency bug in it. This makes it sound like it is wrong sometimes. I'm not using Rust, if this is what you meant, could you give examples of that?

The borrow checker can't reason about certain scenarios that are (obvious to the human) safe. When that happens it'll error on the side of caution and prevent the safe code from being compiled.

The discussion here: https://news.ycombinator.com/item?id=14915539 and the linked previous discussion and ELI5 have a good collection of examples with explanations.

Re: Fearless Concurrency in Firefox Quantum

#130

Post by benjvmin »

nwah1 wrote: post #65
Zenbit_UX wrote: post #60

Earlier quoted context omitted.

As a front end Dev I'll never fully ditch Chrome as its Dev tools are vastly superior. I've tried the Firefox inspect menu and I'm just immediately turned off and confused.. However Firefox has been, and always will be my daily driver for all Web browsing. It's eco system is richer, noscript and the fact that it's not a Google product is a huge selling point.

From a feature standpoint, I can't think of anything that Firefox devtools are lacking. This seems like a gripe about the UI, and my feeling is precisely the opposite of yours, but equally subjective.

Just testing out FF devtools, I do appreciate how similar they are to Chrome. The biggest differences seem to be geared towards PWAs, such as auditing w/ Lighthouse.
Post reply on HN