Principles for Fast Tokio Applications

Post by saghm » Wed, Sep 16, 2026, 1:48 PM UTC

eru wrote: post #69

saghm wrote: post #66

Earlier quoted context omitted.

I honestly stopped taking Go channels seriously when I found out that reading from a closed channel is indistinguishable from reading the zero value, but writing to a closed channel will panic. I don't want to have to use booleans and write `true` in order to ping another task and have it tell the difference between getting pinged or being hung up on, and I really don't want to have to architect things so that I need…

Historically, Go was also really weird in having a very arrogant design: the language designers allowed themselves a lot of generic operators and structures (like arrays, map, channel, the 'make' function etc), but they were considered taboo for the hoi polloi which had to make do with the equivalent of void* pointers and runtime casting (the empty interface shenanigans). I say historically, because they got generics…

Yeah, I honestly was surprised they did end up eventually getting generics. My brief stint with it ended a while before then, but my impression at the time was that they were bizarrely insistent on trying to come up with a design from first principles rather than taking the time to understand the literal decades of designs that came before. It was impossible for me to tell the difference between their position and "we don't like Java generics and are either not aware of languages like ML or are too arrogant to read about them".

Post by saghm » Thu, Sep 17, 2026, 3:47 AM UTC

CoolestBeans wrote: post #70

saghm wrote: post #63

Earlier quoted context omitted.

I've long pined for an ergonomic way of defining actors in Rust. I feel like there must be some way to abstract things that doesn't leak a bunch of a details into the mental model around how to think about starting/stopping/communicating between actors, but every time I've tried to figure it out (or use a solution someone else made) it ends up being way more complicated than it feels like it needs to be, and not wort…

Yeah the Actor model just doesn't fit well with Rust without feeling like a DSL. Tokio works well because Rust's ownership model overlays with tokio nicely. The language is already doing the hard data safety stuff for tokio, tokio just adds a lot of conveniences. Erlang and Go make their concurrency models work because it is embedded into the fabric of the language. Neither cares about zero cost abstractions or minim…

I guess in the framing you're describing, the issue I ran into is that Tokio still just isn't anywhere close to as opinionated as a runtime as the other ones you mention. Even just taking message passing as an example, Go gives you one channel, and that's what you have to use for everything; Tokio gives you a single use channel, both a bounded and unbounded channel for an arbitrary number of senders to a single receiver, and two separate multi-producer-multi-consumer channels with different properties. I could make a bunch of opinionated choices of my own about how this should work, but at that point I'm adding a bunch of potentially leaky abstractions on top of a runtime that already isn't core to the language (and as the blog post indicates, there's a learning curve about how to get the most out of it).

Re: Principles for Fast Tokio Applications

Re: Principles for Fast Tokio Applications