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

131–140 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#131

Post by cname »

vatotemking wrote: post #74
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.

I kinda agree. A few key things missing in FF that I need: * selecting CSS colors in other colorspace (eg. RGBA) as oppose to just hex * throttling the network in desktop mode. I think the option just shows up in responsive design mode. Although I dont think Chrome is "vastly" superior at this point as FF has certainly narrowed the gap. > I've tried the Firefox inspect menu and I'm just immediately turned off and con…

> selecting CSS colors in other colorspace (eg. RGBA) as oppose to just hex

I'm not sure if this is what you mean, but you can go into the dev tools config and change the default color unit under Inspector. The eyedropper will show values using the selected unit and style rules will be converted to that unit.

Re: Fearless Concurrency in Firefox Quantum

#132

Post by nachtigall »

jchw wrote: post #69
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.

I don't feel this way. What are some neat features of Chrome Dev Tools that I might not be taking advantage of? One I know of is the ability to inspect WebSocket connections, I really wish Firefox had that.

This is the bug for this in case you are interested or want to follow progress: https://bugzilla.mozilla.org/show_bug.cgi?id=885508

Re: Fearless Concurrency in Firefox Quantum

#133

Post by nachtigall »

timsayshey wrote: post #86
vatotemking wrote: post #82

Earlier quoted context omitted.

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…

>> 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). Yeah, I can see the raw HTML or JSON response. But Chrome actually allows you to see the rendered HTML response in the "Preview" tab. Are you saying there is a way to see the rendered HTML from the XHR response? I'm not see…

Looks like this has been fixed now: https://bugzilla.mozilla.org/show_bug.cgi?id=1353319

If you grab Nightly (I've been using it for a year now for frontend development and my normal browsing and it's just fine) you can test it.

Re: Fearless Concurrency in Firefox Quantum

#134

Post by nachtigall »

vatotemking wrote: post #85
philliphaydon wrote: post #77

Earlier quoted context omitted.

Probably network throttling and responsiveness is the only reason I would switch to chrome for testing. Today is the first day I spent my entire day in Firefox and didn’t get angry. I love it! Ditched chrome for default browser now.

Network throttling is present, but only in responsive design mode. And responsive design mode has the same features with Chrome, but its a bit wonky at the moment.

I think you should open a bug report about this at bugzilla.mozilla.org I did the same for several feature requests or ideas and the firefox developers and community is very nice and responsive (I'd say most of my bug reports were fixed within days/weeks whereas feature request usuallly takes longer - but is always consider).

They are very open to feedback!

Re: Fearless Concurrency in Firefox Quantum

#135

Post by kibwen »

s17n wrote: post #117
deckarep wrote: post #5

Earlier quoted context omitted.

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…

Given the a "data race" is essentially defined to be the class of races that Rust's type system guards again, yeah it saves you from all of them.

Rust's definition of "data race" isn't just "what the Rust compiler rejects", it has a specific meaning:

"Safe Rust guarantees an absence of data races, which are defined as: 1. two or more threads concurrently accessing a location of memory, 2. one of them is a write, 3. one of them is unsynchronized."

https://doc.rust-lang.org/nomicon/races.html

Re: Fearless Concurrency in Firefox Quantum

#137

Post by kibwen »

vanderZwan wrote: post #16
kibwen wrote: post #8

I like this explanatory comment by Manishearth, a Servo dev, in the thread over on /r/rust: "This blog post brought to you by the 'how many times can you say 'fearless concurrency' and keep a straight face' cabal. "Seriously though, I now appreciate that term a lot more. One thing that cropped up in the review of this post was that I didn't have examples of bugs Rust prevented. Because I couldn't think of any concret…

Quoting what I just replied in that thread: > Given that this Servo code replaces an existing code base, couldn't we get a "guestimate" by looking at how many unsolved bug reports are now closed because their associated previous (presumably C++) code has been replaced? How many open bugs existed in Stylo's precursor that are removed now?

For those not reading the other thread, I'll quote Manishearth's reply:

> I don't think there would be many of these. Specific threading bugs once found get fixed, and we don't know how many go undetected.

Re: Fearless Concurrency in Firefox Quantum

#138

Post by virgilp »

jmcomets wrote: post #79
virgilp wrote: post #67

Earlier quoted context omitted.

You could say the same about NullPointerExceptions, and while they're better than segfaults - in practice they're not that much better.

I think you're hitting an interesting point here. In my experience, there are two kinds of NPEs: 1) On a method call somewhere in a stack with no null checks: here it's not very useful to have an NPE, since it should work (eg. there's no null checks, so why should it fail?). 2) `Objects.requireNonNull(o)` (or an explicit through). This indicates that a pre-condition is that the object should not be null. These tell t…

It's really all about the practice. If you make liberal use of `panic!` (or things that may panic, like `unwrap()`, then you basically get into situation 1.

You're definitely right that Rust is better than Java in that it makes things that may crash (like the naked unwrap()) obvious and "yucky", rather than "usual business". But that doesn't mean that a panic is not a crash - it still is. The language itself is better - but that doesn't mean you can't write code that crashes :)

Re: Fearless Concurrency in Firefox Quantum

#139

Post by kbenson »

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 compiler enforces rules that when followed mean that your code should not have any concurrency bugs. Those rules enforce a subset of behavior that is actually safe. There are other ways of structuring the data and processing that are also safe that Rust doesn't allow because it's not smart enough to reason about (and to be clear many people aren't smart enough to easily reason about either). In those cases, you can wrap the code in in question an unsafe block, which tells Rust to relax certain rules for the scope of that block, and gives you control somewhat analogous to what you get in C. The benefit is that when used sparingly and concisely (if at all), this allows certain bugs to be reduced to originating in very limited parts of the code base.

As an example, if you have a data structure or algorithm that you know is safe when implemented correctly, you can implement it in an unsafe black and expose it through a safe API/function. To my understanding, a lot of Rust's standard library core containers do exactly this. It's not guaranteed to be bug free, but it does provide quite a bit more assurance.

Re: Fearless Concurrency in Firefox Quantum

#140

Post by unrealhoang »

quotemstr wrote: post #110
pcwalton wrote: post #108

Earlier quoted context omitted.

You can't implement it soundly.

Define "soundly". Follow the rules and it won't break. Will it break if someone memcpys some object internals or something? Sure. Just don't do that. The rules that make this abstraction robust in C++ are easy to follow, just like the rule that says "don't use unsafe" in Rust. Just like Rust, you can break the rule if you know what you're doing.

It’s an exactly same reasoning behind static & dynamic type system. “Don’t put null value to this function and it will not break. Just put object with these properties into this function and it will not break.” Static type system allow you to ENFORCE those contracts regarding what is the data. Same with this, Rust’s affine type system allows you to ENFORCE the contracts regarding HOW to use the data (i.e. if already be free, it couldn’t be used any more) as opposed to the infamous guideline “Don’t use the data after it’s already been freed “
Post reply on HN