[vanderZwan]

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?

[sidlls]

Such comparisons are at best guesses. An existing code base has a history of feature and bug accretion that any new, replacement system benefits from with respect to design and implementation.

[wtetzner]

But was the existing code base that was replaced running concurrently?

[Zenbit_UX]

I'd love to know what this concurrency thing is and why it's so fearless in rust.

[odabaxok]

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)

[kenhwang]

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

[vanderZwan]

> 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?

[kenhwang]

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.

[kbenson]

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.

[wtetzner]

It would probably be more accurate to say "if it can't prove there aren't any data races".

[CodesInChaos]

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.

[steveklabnik]

https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... Is from just before 1.0, and so is slightly dated in some ways (scoped threads are in a package, not in std) but should give you some explanation.

[eru]

Have you followed any of the links?

[vanderZwan]

Ah, true. But I thought Rust was supposed to help with more than just concurrency related bugs?

[kibwen]

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.