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:
I agree that my wording is too strong due to my memory of the latency results. As you increase the load, Go is closer to Rust/C than C# (see last benchmarks) and at a given load, C# isn’t in picture. It’s fair to say that Go/C# is similar while Java is far behind depending on the benchmarks that are important to you.
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].
> 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.
The only gotcha that can cause memory leaks in C# is a GC root, i.e. referencing something on a stack, that is static or that is pinned. Events/delegates are not special in any way, they are simply a reference footgun because it's non-obvious that they contain a reference to the object that contains the handler.
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:
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.
Well any website serious about security - yes. But if a single website decides to do it it would work fine. It would be quite easy to just add a js file with this. For example this one for the Stanford JS Crypto Library: https://github.com/bitwiseshiftleft/sjcl/blob/master/core/sh...
We're currently putting the onus on the end user (who are mostly apathetic), when really the onus should be on the websites.
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.
Ah I see what you're saying. You're right, in the interim period before everyone changes to client side hashing that is an issue. Though there's no loss to implementing it, but it's just not as beneficial until more sites have it.
For example:
If there is no client side hashing: a user uses the same password for n websites. If one of the n websites gets hacked, an attacker can login to all n sites.
If one on site you have client side hashing: a user uses the same password for n websites. If one of the n-1 websites gets hacked, an attacker can login to all n sites. If the client side hashed website is hacked, the attacker can only login to 1 site.
Once each site has a unique salt, then we're secure.
Another issue is how can a website migrate over to client side hashing? I don't think there's an elegant way to do this.
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.
In Rust the "verified product" is the chain of bors merges - we even save build artifacts for each node in the chain for easy bisection of issues. A rollup creates a single bors merge for all the commits in them, so it's only 1 link in the chain.
Yes, it's theoretically possible. When it happens in Kubernetes, it's far more common that m+A+B failed because of a flaky test than because B was actually broken, and C+D fixed it.
What we often see is m+A fails because of a flake, and m+A+B+C+D+E passes and merges as a batch. We have a lot of flaky tests. :(
