Give a task ownership of some state, communicate through channels and suddenly a lot of locking just disappears from the design

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 worth it over writing a bunch of manual tasks wrapping private structs that have a bunch of channels in them. I feel like I've tried everything I could think of in terms of API design to make this work in a way that doesn't require users either having to learn a bunch of bespoke rules for the implementation or spend a lot of extra effort on manual boilerplate, including some very wacky things (like a macro where you pass a name and a function and it defines you a new macro with that name for spawning the actor task), but nothing ends up like I'd want.

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 minimal runtime (and runtime transparency). Both languages accept that there is a runtime that the developer cannot fully control as part of the deal for their concurrency models.

For Rust to have this, you have to break assumptions Rust developers have about writing Rust code. You would effectively be writing a runtime in Rust and then code that uses this Actor library would essentially run on it. But it wouldn't feel right because it would look like Rust code but feel like something else. That sort of heavy framework stuff doesn't mesh super well with Rust even if the language is capable of it.

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).

I think channels deserve more emphasis here too, especially because they change the architecture rather than just swapping synchronization primitives

One thing I appreciate here is treating scheduler fairness as something you spend, not something you get for free

For a programmer, deriving intervals and chords and then hearing the code produce them is a pretty effective bridge

I don't think the article needs to get you all the way from A to S to be useful. A Fourier transform doesn't tell you why a song is good either, but understanding harmonics can still improve your mental model of sound. Same with temperament, intervals or why a keyboard is laid out the way it is.

Yeah, this is the advice I wish showed up more often in "learn music theory" discussions

I'm sort of the opposite - when I can name something, then play it, then I can hear it. E.g., going from minor third to major third to root. I can't "unhear" that in blues-based music now. But before it had a "name" it was just an interesting sounding "thing" that didn't pop out to me in any specific way.

I think there's still a pedagogical niche for what the article is doing. For someone coming from programming, "here's why these conventions aren't completely arbitrary" can be the thing that gets them interested enough to later learn harmony properly

I like this less as "music theory from first principles" and more as "why some of the machinery of Western music looks the way it does"

There’s a night-and-day difference between frontier and budget models, no question. But the issue isn't the tooling at all : if you put someone who doesn't know the rules of the road on a $15k carbon road bike, they're just gonna slam into a telephone pole at 30 mph instead of 6 mph

Just let him take down prod on a friday night once and leave him to deal with the PagerDuty alerts solo. Cures the urge to vibe-code infrastructure real fast

People like that are usually pretty good at deflecting onto other people. Likely you will end up being blamed in some way.