I don't have an issue with autonomous vehicles (though I think we should also reduce the overall proportion of trips by car) but yes, obviously you need societal buy-in. "People want this" into 'some don't but they'll die' is hardly a serious approach to policies that impact everyone.

Anyway, I don't think your interpretation is supported by that data. Every age group responded net negatively, and age wasn't the strongest factor – for instance, women were less than half as likely as men to be comfortable sharing roads with self-driving vehicles

Could you justify this? e.g. https://doi.org/10.1080/17450101.2024.2325386 (N=1890):

"What first comes to mind when you hear the term self-driving vehicles?" (coded free-text) 17% positive, 34% neutral, 49% negative

"How would you feel about riding in a self-driving vehicle instead of the existing ways you travel?" 28% comfortable, 15% neutral, 53% uncomfortable

"How would you feel about using the roads alongside self-driving vehicles?" 29% comfortable, 20% neutral, 49% uncomfortable

C#, Go, Swift are (mostly) memory safe, but I don't think they provide this level of modularity or broader reliability. Expressive interfaces/contracts are useful for all sorts of things, you can use them for memory management but for me that's almost a by-product. I certainly don't consider it a restriction on the kinds of program you can write

> you can push to the vec even while holding references to elements that have already been pushed.

Expressing this in Rust (without leaking references to a dropped container) means taking &self. It's true that the container struct itself (chunk pointers, len) is mutated, but the compiler has no distinction between this and the pointee data, so you use ..Cell. It does allocate, there's no capacity limit, but it guarantees stable pointers to existing items.

Yours will reallocate every so often, invalidating element references. append_only_vec requires only `&self` to push, and can also be used concurrently. Adding these abilities requires unsafe, so it wants its own module to uphold invariants on private members. Add an efficient well-tested impl and several other traits you might want, and a shared crate is entirely reasonable.

That doesn't mean you jump to importing nonsense or trivial dependencies. The top hundred are efficient, well-designed crates of the quality you'd expect in a large std like Go or Swift, sometimes even higher as people can write better implementations that they otherwise wouldn't (or wouldn't be used over std). And those languages make breaking changes! C++ is mostly stable, so it's full of junk like or just unordered_map. Rust managed to wholesale reimplement HashMap 6 months after SwissTable released, like it is also easier to express this level of encapsulation, but that's part of countless design/interface decisions made deliberately to not constrain forwards compatibility, including a smaller std.

However, that's no excuse to have a worse developer experience in this area. We need better tools to vet and communicate the quality of a crate and its supply-chain, like community-curated or even additional org-maintained crates, and maybe a handful delivered precompiled in the default rustup distribution which can change over time. I don't think they need to be added to std itself though

I find it rather annoying that so many submissions on hn are LLM writing, but yes I don't generally find it worth discussing. except that this one explicitly claims not to be

[0] https://tinfoil.sh

Obviously it would be even better to keep one EV longer (hard to say how much better, they do displace ICE vehicles in the used market) but they're almost certainly consuming less than you.

Hopefully then it's not too hard to believe you can build an encryption scheme and operations where `dec(enc(X) ⊞ Y) = X + Y` and `dec(enc(X) ⊠ Y) = X × Y`. If these operations can also be composed, i.e. homomorphism, then they're Turing complete! You can turn any function f(X) into a ciphertext version `dec(F(enc(X))) = f(X)`. It can't leak any information about X, because you only ever provided enc(X). For example you transform 'branching' code to something which traverses every path, and paths which do nothing will still appear to randomize the ciphertext, because you can't invent operations that distinguish which path is taken, because it's a secure ciphertext.

Modern homomorphic encryption uses more complex encryption schemes and primitives, to achieve thousands/hundreds rather than millions of times slower than f. Nonetheless it's impossible for the provider to gain a single bit of information about X.

[0] https://ente.com