Author here. I use the term 'genuinely' too often, but that's just me. I do that when speaking here as well. Suffice to say that I'm not a native speaker, so that might have something to do with it. I will go over the text and replace some of those. thx.
Author here; thanks! I had the same impression, which is why I started writing these short-form articles about idiomatic Rust. The blog post overview is here: https://corrode.dev/blog/
Do you mean `Arc<Mutex<T>>`? Yeah, I agree.
Wrote a blog post on that topic as well: https://corrode.dev/blog/prototyping/
The title is a bit of a misnomer, but it's about beginner-friendly escape hatches in the language. Perhaps it's useful to newcomers.
The thing is, once you internalized the concepts (ownership, borrowing, lifetimes), it's very hard to remember what made it difficult in the first place. It's "curse of knowledge" in some sense.
What's changed since 2015 is that we ironed out some of the wrinkles in the language (non-lexical lifetimes, async) but the fundamental mental model shift required to think in terms of ownership is still a hurdle that trips up newcomers.
For people who don't get the reference, this might be referring to the notoriously gnarly task of implementing a doubly-linked lists in Rust [1]
It is doable, just not as easy as in other languages because a production-grade linked-list is unsafe because Rust's ownership model fundamentally conflicts with the doubly-linked structure. Each node in a doubly-linked list needs to point to both its next and previous nodes, but Rust's ownership rules don't easily allow for multiple owners of the same data or circular references.
You can implement one in safe Rust using Rc<RefCell<Node>> (reference counting with interior mutability), but that adds runtime overhead and isn't as performant. Or you can use raw pointers with unsafe code, which is what most production implementations do, including the standard library's LinkedList.
It's true that he no longer steers the project, but his first version shaped the internet as we use it today. At least one could how a modern version of a similar idea would look like. What has changed since then? Which issues should be fixed? You might end up with Deno or perhaps WebAssembly or something else entirely, but it definitely helps to know the people behind the tools we use every day.
In my book that's not a guess, but a hypthesis, which is indeed a great way to narrow down the problem space. What I meant was to avoid blind guessing in the hope of striking luck, which comes back to haunt us most of the time.
The creator matters because they are the key to understand the reason was created in the first place and under which circumstances. You get to learn about their other work, which might also be relevant to you, the limitations of the tool based on the problem is was designed to solve, and the broader ecosystem at the time of creation. For example, if you're a frontend developer it helps to know who Brendan Eich is, where he worked when he invented JavaScript, and what Netscape wanted to achieve with it. You would even learn a bit about the name of the language.
Similarly, it helps to know who maintains the code you depend on. Is there even a maintainer? What is the project roadmap? Is the tool backed by a company or otherwise funded? What is the company's mission?
Without those details, there is a supply chain risk, which could lead to potential vulnerabilies or future technical debt.
Or at least it used to be the answer when I still cared about analytics. Nowadays, friends send me a message when they find my stuff on social media, but I long stopped caring about karma points. This isn't me humblebragging, but just getting older.
The longer answer is that I got curious about Cloudflare workers when they got announced. I wanted to run some Rust on the edge! Turns out I never got around to doing anything useful with it and later was too busy to move the site back to GH pages. Also, Cloudflare workers is free for 100k requests, which gave me some headroom. (Although I lately get closer to that ceiling during good, "non-frontpage" days, because of all the extra bot traffic and my RSS feed...)
But of course, the HN crowd just saw that the site was down and assumed incompetence. ;) I bury this comment here in the hope that only the people who care to hear the real story will find it. You're one of them because you did your own research. This already sets you apart from the rest.
Author here. The site was down because I'm on Cloudflare's free plan, which gives me 100k requests/day. I couldn't care less if the site was up for HN, honestly, because traffic costs me money and caches work fine. FWIW, the site was on Github Pages before and it handles previous frontpage traffic fine. So I guess if there were any irony in it, it would be about changing a system that worked perfectly well before. My goal was to play with workers a bit and add some server-side features, which, of course, never materialized. I might migrate back to GH because that's where my other blog, corrode.dev, is and I don't need more than that.
True, I should add the wrapping types. They are actually quite useful if you know that you have a fixed range of values and you can't go above the min/max. Like a volume dial that just would stay at "max" if you turn up the volume; it wouldn't wrap around.
> However, their use is the exception, not the rule, and their use—in particular in combination—requires security expertise and investment that is not common. For them to provide real-world, large-scale improvements in the security outcomes of using C and C++ software, there remains significant work to be done. In particular, to provide security benefits at scale, for most software, these protections must be made an integral, easy-to-use part of the world-wide software development lifecycle. This is a big change and will require a team effort.
That's the core problem.
The mechanisms mentioned are primarily attack detection and mitigation techniques rather than prevention mechanisms. Bugs can't be exploited as easily, but they still exist in the codebase. We're essentially continuing to ship faulty software while hoping that tooling will protect us from the worst consequences.
Couldn't one argue that containers and virtual machines also protect us from exploiting some of these memory safety bugs? They provide isolation boundaries that limit the impact of exploits, yet we still consider them insufficient alone.
It's definitely a step in the right direction, though.
The paper mentions Rust, so I wanted to highlight a few reasons why we still need it for people who might mistakenly think this approach makes Rust unnecessary:
- Rust's ownership system prevents memory safety issues at compile time rather than trying to mitigate their effects at runtime
- Rust completely eliminates null pointer dereferencing
- Rust prevents data races in concurrent code, which the paper's approach doesn't address at all
- Automatic bounds checking for all array and collection accesses prevent buffer overflows by design
- Lifetimes ensure pointers are never dangling, unlike the paper's approach which merely tries to make dangling pointers harder to exploit
So, we still need Rust, and we should continue migrating more code to it (and similar languages that might emerge in the future). The big idea is to shift bug detection to the left: from production to development.