The US has the 5th amendment protecting you from self-incrimination, while in the UK you can go to prison for not divulging your encryption password (even if you forgot it!).
The US doesn't have ISP/DNS level blocking for all I'm aware of, but there's the ultimate blocking that sometimes does happen (FBI raiding your servers, even if outside of the US).
The US has the 1st amendment protecting speech, while in the UK people routinely get arrested for social media posts.
Maybe there are areas where the UK is better about privacy/freedom than the US, but no examples immediately come to mind.
This, and other similar legislation, serve as a constant reminder of why the American founding fathers had to revolt against tyranny, and why constitution amendments like the 1st and 4th exist. The 4th in particular was written as a response to a British law similar to Chat Control (writs of assistance).
These are two sides of the same coin. Go has its quirks because they put things in the standard library so they can't iterate (in breaking manners), while Rust can iterate and improve ideas much faster as it's driven by the ecosystem.
Edit: changed "perfect" to "improve", as I meant "perfect" as "betterment" not in terms of absolute perfection.
Pixels are pretty weak hardware wise in the areas people care about (heavy, relatively slow charging, big, etc.); I'd probably recommend people buy Samsungs which also get long term software updates nowadays.
I think this framing is a bit backwards. Many C programs (and many parts of C programs) would benefit from being more like Go or Python as evident by your very own sds.c.
Now, if what you're saying is that with super highly optimized sections of a codebase, or extremely specific circumstances (some kernel drivers) you'd need a bit of unsafe rust: then sure. Though all of a sudden you flipped the script, and the unsafe becomes the exception, not the rule; and you can keep those pieces of code contained. Similarly to how C programmers use inline assembly in some scenarios.
Funny enough, this is similar to something that Rust did the opposite of C, and is much better for it: immutable by default (let mut vs. const in C) and non-nullable by default (and even being able to define something as non-null).
Flipping the script so that GOOD is default and BAD is rare was a huge win.
I definitely don't think Rust is a silver bullet, though I'd definitely say it's at least a silver alloy bullet. At least when it comes to the above topics.
The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated.
I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other projects suffer from these classes of bugs consistently. Additionally, that's why people use linters and code formatters even though developers can develop a sensitivity to coding conventions (in fact, these tools used to be unpopular in C-land). Trusting humans develop sensibility is just not enough.
Specifically, about the concurrency: Redis is (mostly) single-threaded, and I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).
Can people write safer C (e.g. by using sds.c and the likes)? For sure! Though we've been writing C for 50+ years at this point, at some point "people can just do X" is no longer a valid argument. As while we could, in fact we don't.
Slightly different as I generate a PGP key on the computer and then load it to the Yubikey, which means I can have backup keys with the same secret keys.
I never really got "touch to use" working though, if anyone knows how to do it with GPG keys I'd really appreciate it!
https://stosb.com
https://www.etebase.com
https://www.etesync.com
https://github.com/tasn
https://mastodon.social/@tasn
https://twitter.com/TomHacohen
Contact: at tom @ any of the domains above.