Comment by throwawaymaths

Comment by throwawaymaths a day ago

8 replies

> Adding either one causes it to not be callable from certain places.

you can call a function that requires an io parameter from a function that doesn't have one by passing in a global io instance?

as a trivial example the fn main entrypoint in zig will never take an io parameter... how do you suppose you'd bootstrap the io parameter that you'd eventually need. this is unlike other languages where main might or might not be async.

masklinn a day ago

You can call an async function from a function that is not async by passing in a global runtime (/ event loop).

As a trivial example the main entry point in rust is never async. How’d you suppose you’d bootstrap the runtime that you’d eventually need.

This is pretty much like every other langage.

  • throwawaymaths 19 hours ago

    and yet... there are libraries that were written twice, once for async and once for not.

    • masklinn 16 hours ago

      Which should be a pretty big hint that you've misidentified the issue.

  • almostgotcaught a day ago

    People in software really do have poor abilities to see the forest for the trees don't they lol

ginko a day ago

>you can call a function that requires an io parameter from a function that doesn't have one by passing in a global io instance?

How will that work with code mixing different Io implementations? Say a library pulled in uses a global Io instance while the calling code is using another.

I guess this can just be shot down with "don't do that" but it feels like a new kind of pitfall get get into.

  • throwawaymaths a day ago

    > Say a library pulled in uses a global Io instance while the calling code is using another.

    it'll probably carry a stigma like using unsafe does.

  • TUSF a day ago

    Zig already has an Allocator interface that gets passed around, and the convention is that libraries don't select an Allocator. Only provide APIs that accept allocators. If there's a certain process that works best with an Arena, then the API may wrap a provided function in an Arena, but not decide on their own underlying allocator for the user.

    For Zig users, adopting this same mindset for Io is not really anything new. It's just another parameter that occasionally needs to be passed into an API.

  • kristoff_it a day ago

    while not really idiomatic, as long as you let the user define the Io instance (eg with some kind of init function), then it doesn't really matter how that value is accessed within the library itself.

    that's why this isn't really the same as async "coloring"