Live data from Hacker News

Fearless Concurrency in Firefox Quantum

blog.rust-lang.org

161–170 of 177 posts

Re: Fearless Concurrency in Firefox Quantum

#161

Earlier quoted context omitted.

Right, but it doesn't mean "small", some quanta are quite large.

I agree, not small (seems subjective), but still the smallest! The smallest leap is probably not very large :D

No, a quantum leap is any abrupt leap between any two energy levels (i.e. you can span multiple), it characterizes the abruptness, not the size.

IIRC the term's usage in English derives both from the fact that it is an abrupt leap, and also from the radical change to physics brought forth by quantum mechanics.

Re: Fearless Concurrency in Firefox Quantum

#162

Earlier quoted context omitted.

You can't just wrap a statement the compiler has deemed to not pass the borrow checker and make it compile. Unsafe blocks can bypass the type system, but you have to call extra magic to do so.

So, really, what we're discussing is how much ceremony a language ought to require before enabling unsafe behavior. I think C++ provides enough ceremony that you can write decently safe programs in C++.

It's not about ceremony - it's disingenuous to say that C++ can enforce the same safety rules as Rust w.r.t. to lifetimes or that C++ is as safe as Rust is within it's unsafe blocks.

Whilst currently the borrow checker is a bit greedy, it's safe to say that most of the time the borrow checker is checking the code is safe the same way I try to reason about memory accesses in C and C++ when dealing with concurrency or freeing memory. The power of the borrow checker shows itself when reasoning about a local function and no longer requires you to reason about the whole application state as the compiler ensures locality to the extent that shared mutable state is not allowed.

Re: Fearless Concurrency in Firefox Quantum

#164

Earlier quoted context omitted.

> The issue here seems to have little to do with exception handlers; see that > head [0, throw E] > also produces such an "indeterminate" answer depending on order of evaluation, as long as you define things as you have here. I disagree; note that I said: > we treat an "unhandled exception" as not getting an answer (equivalent to an infinite loop) More formally, throwing an exception/error results in _|_ (bottom) and…

> throwing an exception/error results in _|_ (bottom) and all _|_ results are equivalent My point is that they're not when you have `catch`, and that this distinction adds nothing that ⊥ doesn't already add with regards to order of evaluation.

I'll have to think about this some more, since I don't quite understand.

Let's say we have the following Haskell definitions:

    error msg = undefined  -- "throwing an error"
    undefined = undefined  -- infinite loop
In this setup, there's no way for us to tell, under any evaluation strategy, whether or not an expression evaluates to _|_. Any code we might write to "check" for this would have to run "after" an infinite loop, which is impossible. Hence it's impossible to write an expression which, under any evaluation strategy, normalises to two distinct non-_|_ values: either it always produces the same value, or it sometimes produces one value and sometimes _|_ (depending on the strategy), or it always produces _|_ regardless of strategy.

If we can distinguish between "different _|_s", e.g. catching some as exception values, then we can write an expression which reduces to different non-_|_ values depending on the evaluation strategy, and hence we lose confluence (the weaker form; we already lost the stronger Coq/Agda form by having _|_ in the first place).

This is fundamentally different to the value-or-_|_ uncertainty, since that's unobservable from within the language.

Re: Fearless Concurrency in Firefox Quantum

#165
post #78

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.

You are comparing FF Developer Edition to Chrome here?

Nope, stock to stock. Didn't know FF had that, I'll check it out.

Re: Fearless Concurrency in Firefox Quantum

#166

Earlier quoted context omitted.

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!

Done!

Mind sharing the link to the bug? I'd like to follow it as I think it would be a good enhancement.

Re: Fearless Concurrency in Firefox Quantum

#167
post #10
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…

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…

What would you say are the advantages of cargo over any other package manager / build system?

Re: Fearless Concurrency in Firefox Quantum

#168

Earlier quoted context omitted.

> throwing an exception/error results in _|_ (bottom) and all _|_ results are equivalent My point is that they're not when you have `catch`, and that this distinction adds nothing that ⊥ doesn't already add with regards to order of evaluation.

I'll have to think about this some more, since I don't quite understand. Let's say we have the following Haskell definitions: error msg = undefined -- "throwing an error" undefined = undefined -- infinite loop In this setup, there's no way for us to tell, under any evaluation strategy, whether or not an expression evaluates to _|_. Any code we might write to "check" for this would have to run "after" an infinite loop…

> This is fundamentally different to the value-or-_|_ uncertainty, since that's unobservable from within the language.

This seems to be a much weaker claim than I thought you to be making; of course being able to catch errors moves visibility of errors from externally visible to internally visible. That's the goal, after all.

I disagree, however, that this matters in the regards you raise, because a language which can arbitrarily decide to return ⊥ on the basis that it isn't internally visible is a broken language and any reasonable implementation needs to avoid that.

Re: Fearless Concurrency in Firefox Quantum

#169

Earlier quoted context omitted.

I'll have to think about this some more, since I don't quite understand. Let's say we have the following Haskell definitions: error msg = undefined -- "throwing an error" undefined = undefined -- infinite loop In this setup, there's no way for us to tell, under any evaluation strategy, whether or not an expression evaluates to _|_. Any code we might write to "check" for this would have to run "after" an infinite loop…

> This is fundamentally different to the value-or-_|_ uncertainty, since that's unobservable from within the language. This seems to be a much weaker claim than I thought you to be making; of course being able to catch errors moves visibility of errors from externally visible to internally visible. That's the goal, after all. I disagree, however, that this matters in the regards you raise, because a language which ca…

You're right that having some mechanism to act gracefully in the case of errors is almost always required. "Internally" this might be a "main loop" with an exception handler. "Externally" this might be a bash script which runs our binary in a loop, or a systemd service, etc.

The intriguing thing about Haskell's approach is that it shows us that such mechanisms aren't pareto-improvements: we have to give up something, like confluence.

Keep in mind that confluence isn't just academic, it's the thing which makes functional programming attractive for parallelism. Confluence solves the hard problem of taking all possible interleavings of concurrent execution into account, since they act like different evaluation orders, and hence can't mess up the result.

Servers are a scenario where these two features clash: we want concurrency and parallelism for scaling, but we need restart loops to prevent downtime.

The use of external restart loops reminds me of delimited continuations, where even "undelimited continuations" are still delimited by the OS (e.g. Scheme's current continuation doesn't include the state of other OS processes). Likewise, "unobservable errors" can still be observed by the OS (e.g. when our process dies, as in a bash or systemd loop).

I think a good compromise is to "stratify" error handling: we write our business logic (or whatever) in a provably confluent sub-set of our language, and execute that logic using non-confluent features like error handlers. Confluent expressions can take advantage of optimisations (e.g. speculative evaluation) which are invalid for the wrapper.

One thing I'm not sure about is nesting exception-handling code in pure code. Approaches like algebraic effect systems let us mark expressions as requiring effects like 'stdio', yet we can handle those effects in a pure way (e.g. using hard-coded strings during a test). I don't think this is enough to maintain confluence in the face of concurrency though; we'd probably have to pass in a deterministic scheduler, but that may parallelism gains of things like speculative evaluation, work-stealing, etc.

Post reply on HN