Top all-time · #1020
Yosh Wuyts
Personal blog · blog.yoshuawuyts.comprogrammingsystems
Yosh Wuyts's personal blog at blog.yoshuawuyts.com covers programming and systems. Since 2019, 65 different Hacker News readers have linked it 126 times, most often “Why Async Rust?”. It is still writing: the last post was on 2026-10-29, and you can follow it by feed.
Too few sampled comments (16) to say how often HN recommends it.?
Why HN links it
HN readers link Yosh Wuyts's posts on Rust async, effect systems, concurrency and error handling. The error-handling survey is cited as a good summary of the available options.
- Recommended for · 1 comments
- Described the error-handling survey as a good summary of what's out there.
Summarised by Claude from a sample of 16 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Why Async Rust?6 people · 6 mentions · first linked 2022-09-26
- Syntactic musings on match expressions in Rust5 people · 5 mentions · first linked 2025-04-29
- Overview of Rust error handling libraries5 people · 5 mentions · first linked 2019-11-21
- Ergonomic Self-Referential Types for Rust4 people · 4 mentions · first linked 2024-07-01
- Extending Rust's Effect System4 people · 4 mentions · first linked 2024-02-10
- Rust should own its debugger experience3 people · 3 mentions · first linked 2023-01-12
- Async Cancellation3 people · 3 mentions · first linked 2021-11-11
- Async Overloading3 people · 3 mentions · first linked 2021-08-27
- Placing Functions3 people · 3 mentions · first linked 2025-07-11
- Async Iteration Semantics in Rust — Parallel vs Sequential2 people · 2 mentions · first linked 2020-09-25
What Hacker News says?
That would require an effects system[0] like Koka's[1]. Then one could not only express the absence of panics but also allocations, infinite loops and various other undesirable effects within some call-trees. This is a desirable feature, but an enormous undertaking. Absent that there are hacks like no_panic[2] [0] https://blog.yoshuawuyts.com/extending-rusts-effect-system/ [1] https://koka-lang.github.io/koka/doc/bo…
Comment linking /extending-rusts-effect-system/
on “Cloudflare outage on November 18, 2025 post mortem”Submitted State Machines in Rust as a story · 297 points
HN discussionI don't think a good conversation can be had if we start by arguing about whether or not "rust's strategy has to be the only way to achieve memory safety". There are other ways to achieve memory safety. Java's strategy is definitely a valid one; it's just not as suitable for systems programming. The strength of Rust's approach ultimately stems from its basis in affine types -- it is a general purpose and relatively…
Comment linking /linearity-and-control/
on “Greg K-H: "Writing new code in Rust is a win for all of us"”Submitted Overview of Rust error handling libraries as a story · 222 points
HN discussionSwift did some interesting work around Async, which I know is making its way into Rust now. Random example here: https://blog.yoshuawuyts.com/futures-concurrency-3/
Comment linking /futures-concurrency-3/
on “Chris Lattner left Swift core team”Submitted Extending Rust's Effect System as a story · 151 points
HN discussion> You may not like Go's convention (indeed, I don't love it although I think it works fine in practice), but the only error handling mechanism in Go is `if err != nil { ... }`. On the other hand Rust has many. This is not incompatible with your observation of "a standardized Result type". Here is a survey of the error handling landscape circa 2019: https://blog.yoshuawuyts.com/error-handling-survey/ By this definiti…
Comment linking /error-handling-survey/
on “Green vs. Brown Programming Languages”Submitted Asynchronous Programming in Rust as a story · 146 points
HN discussion> Not sure what's meant by this; Rust has a standardized Result type, with dedicated syntax for early-returning errors and type checks that make sure you handle them (or at least explicitly ignore them). Go, on the other hand, has a shaky error story and from what I've heard it's a constant problem due to enforcement-by-convention. You may not like Go's convention (indeed, I don't love it although I think it works f…
Comment linking /error-handling-survey/
on “Green vs. Brown Programming Languages”Submitted Async Cancellation as a story · 114 points
HN discussionhttps://blog.yoshuawuyts.com/error-handling-survey/ is a good summary of what's out there. I think current rough consensus is anyhow/thiserr depending on if you're writing an application or library. I haven't actually used them myself, though. You don't have to keep up with the cool new libraries.
Comment linking /error-handling-survey/
on “I can't keep up with idiomatic Rust”Submitted Nesting Allocators (2023) as a story · 99 points
HN discussion> any blocking operation (a method where Ruby interpreter waits) is compatible with Async and will work asynchronously within Async code block with Ruby 3.0 and later. That's pretty magical. Does this mean it would be possible to implement structured concurrency [0], but without the function coloring problem? Regardless, I think I prefer how this looks from a code read/writeability perspective compared to Zig's or S…
Comment linking /async-overloading/
on “Async Ruby”Submitted Parallel-Stream as a story · 80 points
HN discussionthe type system simply does not allow you to ignore errors Which is excellent. the gold standard in error handling is Rust Really? What library is in fashion this week for handling errors? I have so far used vanilla Rust, error-chain and Failure. Seems like there is so much choice to improve the gold standard: https://blog.yoshuawuyts.com/error-handling-survey/#librarie...
Comment linking /error-handling-survey/
on “Learn Go in five minutes”Submitted State Machines II as a story · 70 points
HN discussionIt’s hard to say. If you want to use green threads, you may want to look at the may crate [1]. The reason Rust prioritized stackless async just like C++ did is that it fits better the systems programming needs (i.e. it’s syntactic sugar for a state machine you could hand implement) while not preventing things like stackful coroutines. If Rust manages to solve the coloring problem of async (e.g. by adopting effect sy…
Comment linking /extending-rusts-effect-system/
on “Async Rust in Three Parts”Submitted Async Overloading as a story · 59 points
HN discussionHere's a semi-recent link (~a year ago) by one of the leaders of this initiative: https://blog.yoshuawuyts.com/extending-rusts-effect-system/
Comment linking /extending-rusts-effect-system/
on “Verus: Verified Rust for low-level systems code”Submitted Placing Functions as a story · 17 points
HN discussionMSVC's C++ Parallel algorithms library gets close [1], and so does Rust's Rayon crate [2]. C# has parallel for loops [3], and apparently so does PowerShell [4] Though none of these are quite as convenient as I think they could be. I suspect there is a path for Rust to add parallel iteration syntax in the future [5]. There are quite a few steps needed to get there, but the result could look something like this: let m…
Comment linking /parallel-stream/
on “A 1000-processor chip powered by an AA battery (2016)”Submitted Why Async Rust? as a story · 8 points
HN discussionIIRC been some proposals floating around, but one major block is asncy drop. This is the article I'm thinking of specifically: https://blog.yoshuawuyts.com/tree-structured-concurrency/
Comment linking /tree-structured-concurrency/
on “Asynchronous Rust on Cortex-M Microcontrollers”Submitted Ergonomic Self-Referential Types for Rust as a story · 7 points
HN discussionYou're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions: https://blog.yoshuawuyts.com/gen-auto-trait-problem
Comment linking /gen-auto-trait-problem
on “Rust project goals: Immobile types and guaranteed destructors”Submitted Tasks Are the Wrong Abstraction as a story · 7 points
HN discussionRust Async WG member here: This question comes up pretty regularly when people first learn about async Rust. I suspect it’s because performance is often emphasized as the main benefit of async Rust. In my opinion performance is always relative and dependent on the workload. Instead it’s worth looking more at which capabilities async Rust provides which aren’t present in non-async Rust. This includes ad-hoc cancellat…
Comment linking /why-async-rust/
on “Why should you use Tokio vs. threads in Rust?”Submitted Async Cancellation I as a story · 7 points
HN discussionFor the past seven years I've been urging people to stop using `select!` in async Rust code and use dedicated structured control flow primitives instead. Correct use of `select!` cannot be guaranteed by the compiler [1], and so it's unsurprising it leads to bugs. For the first example the better option would be to use the `race` operation [2]. For the second it would be better to use `ConcurrentStream` [3]. Many (bu…
Comment linking /futures-concurrency-3/
on “Never Snooze a Future”Submitted Runtime: A crate to empower everyone to write async rust as a story · 7 points
HN discussion
