Comment by rowanG077

Comment by rowanG077 a day ago

6 replies

Sure it is a function coloring. Just in a different form. `async` in other languages is something like an implicit parameter. In zig they made this implicit parameter explicit. Is that more better/more ergonomic? I don't know yet. The sugar is different, but the end result the same. Unless you can show me concrete example of things that the approach zig has taken can do that is not possible in say, rust. Than I don't buy that it's not just another form of function coloring.

throwawaymaths a day ago

> Unless you can show me concrete example

add io to a struct and let the struct keep track of its own io.

  • rowanG077 a day ago

    You can also carry around a runtime and dispatch async function in non-async functions.

  • gfaster a day ago

    Unless I'm misunderstanding, that's effectively implementing Future for the struct

    • masklinn a day ago

      It’s more like adding a runtime handle to the struct.

      Modulo that I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations. So a library can’t take a runtime for a caller and get whatever implementation the caller decided to use.

      • dwattttt a day ago

        > I’m not sure any langage with a sync/async split has an “async” runtime built entirely out of sync operations.

        You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.

        I've implemented Future (Rust) on a struct for a Windows operation based only on C calls into the OS. The struct maintains everything needed to know the state of the IO, and while I coupled the impl to the runtime for efficiency (I've written it too), it's not strictly necessary from memory.

        • masklinn a day ago

          > You get into hairy problems of definition, but you can definitely create an "async" runtime out of "sync" operations: implement an async runtime with calls to C. C doesn't have a concept of "async", and more or less all async runtime end up like this.

          While C doesn't have async OS generally provide APIs which are non-blocking, and that is what async runtimes are implemented on top of.

          By sync operations I mean implementing an "async" runtime entirely atop blocking operations, without bouncing them through any sort of worker threads or anything.