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

71–80 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#71

Post by timsayshey »

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.

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.

Re: Fearless Concurrency in Firefox Quantum

#72

Post by sidlls »

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?

It's not moving, per se, but I've almost convinced my colleagues to use Rust for future projects to move our prototype and research grade machine learning pipeline implementations and data services to Rust. The alternatives were go and C++.

Rust is a clear winner over either in my view because of its traits system and immutable-by-default story. It feels like the kind of C++ I write, but with less boilerplate and typing. The safety story is irrelevant in our case (it's nice, but wasn't an explicit factor in the decision: the other features in Rust may have been developed to support safety, but safety need not exist to provide them). The biggest pain point is that it's not an appropriate language for high performance numerical computation, so we'll have some "glue" there. How that will work is yet to be determined, but the data engineering and infrastructure around the pipeline is definitely going to Rust.

Re: Fearless Concurrency in Firefox Quantum

#73

Post by simias »

nickik wrote: post #23
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…

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.

Well I was mostly talking from a C dev standpoint. At first I think it's easy to think of C++ as "C with classes". It just feels like syntactical sugar for stuff you'd do in C. RAII just means calling a destructor function at the end of the scope. Virtual functions are like stuffing function pointers in structs, templates are like "macros on steroid" etc... It's like C with some stuff on top.

Of course it turns out that it's a lot more complicated and powerful than that and it's probably the wrong way to look at C++ but it might take a while until you realize that you're not in Kansas anymore. Rust on the other hand forces you to become acquainted with its paradigm right away, unless you're willing to put all your code in unsafe blocks.

Re: Fearless Concurrency in Firefox Quantum

#74

Post by vatotemking »

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.

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 confused..

I remember feeling the same when I switched from Firebug to Chrome. It takes a few days to get used to a new UI.

Re: Fearless Concurrency in Firefox Quantum

#75

Post by CodesInChaos »

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.

Rust ensures that while one thread is accessing a datastructure that no other thread will modify it. It does this by only allowing you to have either one mutable or multiple readonly references to a datastructure. Code marked unsafe could violate this, which is why it should be rare and well reviewed.

Re: Fearless Concurrency in Firefox Quantum

#76

Post by pdpi »

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.

C++ gives you an embarrassment of footgun riches above and beyond what C provides. On the other hand, idiomatic modern C++ also deftly avoids many of the C pitfalls. e.g. You don't ever touch new, delete, or raw pointers — instead favouring RAII-based smart pointers, and references. You avoid arrays in favour of vectors. This style (as opposed to old-school C-with-classes C++) is way more productive, and way safer.

Re: Fearless Concurrency in Firefox Quantum

#77

Post by philliphaydon »

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.

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.

Re: Fearless Concurrency in Firefox Quantum

#78

Post by kirse »

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.

You are comparing FF Developer Edition to Chrome here?

Re: Fearless Concurrency in Firefox Quantum

#79

Post by jmcomets »

virgilp wrote: post #67
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…

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 that the fault is in the preceding call stack, therefore you don't even need to understand what the underlying one is to know where the error is coming from.

Although all types are nullable in Java, I don't expect _everything_ to be null-checked. Nullable types in Rust stand out, therefore should be matched or checked. If I have a panic due to a naked `unwrap()`, either there's a documented pre-condition and the system isn't recoverable (hence the crash), or the error handling is missing and I know what to do.

Hence `unwrap()` is similar to (2), which are useful panics.

Re: Fearless Concurrency in Firefox Quantum

#80

Post by odabaxok »

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.

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)

Post reply on HN