mre

I recommend reading Steve's article for context: https://steveklabnik.com/writing/arguing-about-arguments/

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.

We use httpmock [1] for lychee, and it works quite well. Haven't looked too closely at the differences yet.

[1] https://docs.rs/httpmock/latest/httpmock/

As a counterpoint, I quite enjoyed the writing style. Not everything has to be summarized. To me, it was more about the human experience.

My vote goes to .ws which redirects to a beer brand.

Recently watched Mickey 17 and it reminded me a bit of Idiocracy. Maybe someone is looking for related movies.

Fair point. Your wording was a bit strong, but I assume you meant well. I will update the article.

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.

https://rust-unofficial.github.io/too-many-lists/

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.

Author here. That's the answer.

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.

Sorry, it's fixed now.

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.

If you're looking for a Firefox fork, a couple of options come to mind:

- Floorp (https://floorp.app) - Zen (https://zen-browser.app) - Mullvad Browser (https://mullvad.net/browser) - LibreWolf (https://librewolf.net) - WaterFox (https://www.waterfox.net)

Besides that, there's also Brave and perhaps Chromium.

Genuinely curious, what's wrong with that? Did you expect a different platform like Slack?

Exactly. I wrote an entire blog post about that: https://corrode.dev/blog/dont-use-preludes-and-globs/

Author here. That sums it up pretty well.

I don't mind making quick decisions, but the execution should be deliberate. One of the best things of working for myself is that all-hands meetings are pretty short. I have an idea, I ask a few friends about their opinion; then, I set to work - it's simple.

But what I don't do is wreak havoc along the way. For I know, that the time to fix what I might break never comes.

Author here; pleasantly surprised to see this on HN!

This started off as a rant with a friend a few days ago. We both lamented the sorry state of the web, particularly web browsers. There's a monoculture that we both have trouble understanding. As a result, the tone might be a bit rough around the edges.

To anyone who's using Chrome: I understand. It's a decent browser, and switching to a different one is work. However! If everyone is thinking that way, we'll be stuck with whatever Google decides browsers should look like, tracking and half-baked quasi-standards included.

Take that as a friendly encouragement to go out and give FF another chance. We urgently need more diversity in the browser space. Brave and Vivaldi are good, but they are still a flavors of Chrome. I actually believe, that if you give Firefox an honest attempt, you might be surprised at how refreshing it can feel. They really turned it around in the last few years.

Yes, there are problems. Yes, you'll have to find workarounds. But you are developers. You can figure this out! Writing browser extensions isn't that hard, and a lot of things (including the UI) are very customizable in FF.

Author here. Thanks for posting. Just to clarify, there are some cases where globs make sense, e.g. for importing types in tests:

  struct Foo;
  struct Bar;

  mod tests {
    use super::*;
  }

Apart from that, I use globs very rarely.

Good question. I asked Jakub, and he said they don't currently use camera feed in their flight controller. The video feed is routed outside the flight controller through a telemetry module.

I interviewed Fusion Engineering about using Rust for drone controllers. Some things surprised me:

- Their approach is closer to game development than I expected; same focus on predictable performance.

- They run their main loop at 1kHz on Linux. Hardware is a Compute Module 4 from Raspberry Pi.

- Non-software engineers on their team picked up Rust quickly. That's not what you usually hear about Rust.

- They can handle a rotor failing mid-flight. The drone keeps flying.

They open-sourced some interesting crates too. Worth checking out if you're into embedded Rust. Links in the show notes.

I spoke with Folkert, one of the developers on this project, on the 'Rust in Production' podcast. Some of you might find it interesting: https://corrode.dev/podcast/s01e05-tweede-golf/

Use it for 50% of my dev work now. It has improved significantly in the last six months. The vim support is quite decent already.

Search hasn't been an issue for me yet. It feels instant and I like that I can use my keyboard for browsing search results in one view, just like in Sublime. Might depend on the project size, although I use it on bigger projects, too.

The one thing I'm missing is Git support. After getting used to Gitlens, it's really hard to move back to the command line.