3 ms·
This is basically what zig does "async", though it's not coordination so much as "context switching control flow points" that are made explicit. It's very low
by throwawaymaths 4y ago
This is basically what zig does "async", though it's not coordination so much as "context switching control flow points" that are made explicit. It's very low to the metal and if you think about what the machine is "actually doing" it makes a ton of sense, and it's kind of a "shift" in the way of thinking about things in the same way that pointers are. I rather dislike how it's called "async" though. I feel like "reentrant" or "detached" makes more sense, because that's what it feels like to me but if you write your own scheduler you basically have what everyone else calls async.
Iirc rust takes an async function and turns it into a abstract state machine, and I feel like this is a surprisingly high level concept for a systems programming language
- 2fast4you 4y agoI'll say. That's how C# handles async too
- throwawaymaths 4y agoC# is in a highly managed VM, so I can't see how it would be the same as zig. The alternative (high level) way to have "nice" async, which, if c# is similar to zig I think they made "the wrong choice" is to layer async over green threads/cooperative multithreading + message passing/channels. Elixir's Task.async function is I think very well done, leveraging the isolation of erlang's VM and doing a whole ton of things "just right" (a future is process id + unique reference, monitoring the task when you await, e.g)
- 2fast4you 4y agoI was talking just about a sync functions being compiled to a state machine. It’s been awhile but I’m pretty sure C# does the same thing
- throwawaymaths 4y agoGot it. Thanks for clarifying. That seems like a not- unreasonable choice for a HLL like c#, though I'm still baffled they didn't go with something like Task.async