loonyphoenix

The parent comment literally says

> You can have data races in Python, Javascript and Rust as easily as you can in C.

Don't use "race conditions" and "data races" interchangeably if you understand the difference...

You cannot have data races in safe Rust.

How do you get that C# is way behind Go on this one? If anything, those benchmarks show these groups of languages performing at roughly the same level:

1. C/Rust

2. Go/C#

3. Java/OCaml/Haskell

4. JavaScript/Swift

5. Python

Yep. Rust has a PathBuf[1] type for dealing with paths in a platform-native manner. You can convert it to a Rust string type, but it's a conversion that can fail[2] or may be lossy[3].

[1] https://doc.rust-lang.org/std/path/struct.PathBuf.html

[2] https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho...

[3] https://doc.rust-lang.org/std/path/struct.PathBuf.html#metho...

> the GC and runtime make it impossible to leak, double-free, or access out-of-bounds

This is false.

Neither C# nor Rust protect from memory leaks. There are actually some gotchas in C# that can cause memory leaks - for example, you have to be very careful about events. Memory leaks are not memory unsafe, though.

On the topic of actual memory safety - C# has unsafe blocks just like Rust does. Safe Rust is just as safe from memory safety problems as safe C#, even more so, because C# doesn't require unsafe for FFI, where all bets are off. And unsafe C# is just as unsafe as unsafe Rust can be.

Yes, it's quite possible to cause tearing in C#. It does not cause undefined behavior, but it can, for example, break invariants (supposedly enforced by privacy) in large enough structs.

See this example where I break encapsulation in a struct by abusing a race condition:

https://github.com/VictorGavrish/MultiThreading/blob/master/...

How would protecting a single website help? If the password is shared among different sites, and one of the sites turns out to be malicious, I'll be able to access your single website just fine by typing the sniffed password into your textbox, whereupon it can use however much hashing and encryption as it wants and it won't help.

That relies on every website implementing this solution, and I don't think such coordination is possible.

Also I don't see the advantage over just server-side hashing. Client-side hashing (without a password manager) is public, so the salt the site uses is known.

Rayon[1] is artificial silk.

[1]: https://en.wikipedia.org/wiki/Rayon

Doesn't this process break when, e.g., master + A passes tests, master + A + B fails, but master + A + B + C + D passes again (having been fixed by C + D accidentally)?

I mean, it's pretty unlikely to happen, but it's possible. Plus it doesn't matter if all you cared about was that the HEAD of master passes tests, but not the whole history.

However, the current approach, if rebasing is used to squash every merge request into a single commit on top of master, allows you to have a linear history of the master branch where every commit is known to pass the whole test suite that was in existence at that moment, which, I think, helps a lot when bisecting.

I'm not sure if Rust compresses merge requests into a single commit on top of master, though.