https://without.boats/blog/let-futures-be-futures/ is a very good read. From outside rust, the only take on async that went viral enough that I read it was "what color is your function?" Although it was about the javascript world, I was exposed to it as a takedown of async/await in rust.
This post goes quite deep into another framing: if we accept that there is a "color" tradeoff, how is it justified, what do we get out of it? Quite a lot of things, I've learned. Still a significant tradeoff, but I get it now.
The entire blog is really interesting as a rust noob, because it contains a lot of "lore" about how rust's async support came to be, why it ended up in this shape rather than several potential others, and also makes connections to other language features and how they form an emergent skeleton of a first class effect system! Surprising, and cool.
(In the shadows, Haskell lets out a sinister chuckle: "Yes, good, let the typed effects flow through you!")
But also the post has a little aside about imagining a language where all functions are coroutines (i.e. all functions can yield and be resumed later), and how the language would shape itself around that core conceit. And, whoa, neat. I wish prototyping languages was in my skillset so I could run off and try it, but... not today.
@danderson I mean, simplified a bit that is more or less always the case, the question is always what facilities you let yourself have for controlling it. The options are "none" (or perhaps "explicitly drop into asm / setjmp / longjmp / hand write CPS"), some kind of library bolted to the compiler (async/await, other state machine nonsense), or explicit continuations of some kind. All require some runtime to actually get control of the machine, but that is unavoidable anyway.
@creachadair yup. The interesting part to me here is how "every function everywhere can and may yield" trickles through other design decisions. The post mentions a few, like giving a leg up for encoding effects, be the primitive for iteration constructs, support concurrency other than posix thread-alike, and so forth.
These all show up in part in many languages, I'm just intrigued by taking that one thing and pushing as far as it could possibly go, just to see what happens :)
@creachadair and, as the slightly bitter swipe at go points out, the big thing you give up is cheap FFI to all the things with a C ABI. I think that was the big insight I got from either this post or one of its neighbors on the blog, that async/await is the way it is in large part because "cheap FFI to the C ABI" was non-negotiable, and almost every move from that point on is forced, including things that I've seen claimed as the reasons why the design is like that :)
@creachadair Mostly I'm fascinated at how often the tyranny of C turns up, and how much it keeps shaping languages that seemingly have moved far beyond it. Damn legacy code 😂
@danderson zio in scala is built on the math behind the red function, there's an old paper "directing JavaScript with arrowlets" that goes into it in depth. When you do this you get some really nice compositional properties.
@danderson oo yes same I've been reading up on a lot of it, it's super interesting, though a little less magical and more frustrating when I hear other people talk about the language who then haven't read those things
@mikkel Yes, although I think that points to a legitimate problem in language design: marketing matters. To some extent, it doesn't matter how intricately designed a system is, or how many concepts it elegantly ties together, if seeing its value requires reading the scripture rather than being obvious when you use the language.
It's a fundamental tension that I think leads to a lot of PL peoples' annoyance with Go, for example. It doesn't spark joy on the inside, but it kinda doesn't need to!
@mikkel I can definitely appreciate the thought and care that went into various parts of rust's design now, much better than I could when I was trying to learn it without diving into the "associated commentaries". And I'm grateful for those insights, but also I'd argue that it's a kind of PR problem that's at the core of a lot of the "I don't get rust" crowd (myself included, until recently!)
Add comment