But that can already be done using async await. If you write an async function in Rust for example you are free to call it with any async runtime you want.

▲ messe 7 hours ago | parent [-]

But you can't call it from synchronous rust. Zig is moving toward all sync code also using the Io interface.

▲ tcfhgj 6 hours ago | parent [-]

yes, you can:

    runtime.block_on(async { })

https://play.rust-lang.org/?version=stable&mode=debug&editio...

▲ messe 5 hours ago | parent | next [-]

Let me rephrase, you can't call it like any other function.

In Zig, a function that does IO can be called the same way whether or not it performs async operations or not. And if those async operations don't need concurrency (which Zig expresses separately to asynchronicity), then they'll run equally well on a sync Io runtime.

▲ tcfhgj 5 hours ago | parent [-]

> In Zig, a function that does IO can be called the same way whether or not it performs async operations or not.

no, you can't, you need to pass a IO parameter

▲ messe 4 hours ago | parent [-]

You will need to pass that for synchronous IO as well. All IO in the standard library is moving to the Io interface. Sync and async.

If I want to call a function that does asynchronous IO, I'll use:

   foo(io, ...);

If I want to call one that does synchronous IO, I'll write:

    foo(io, ...);

If I want to express that either one of the above can be run asynchronously if possible, I'll write:

    io.async(foo, .{ io, ... });

If I want to express that it must be run concurrently, then I'll write:

    try io.concurrent(foo, .{ io, ... });

Nowhere in the above do I distinguish whether or not foo does synchronous or asynchronous IO. I only mark that it does IO, by passing in a parameter of type std.Io.

▲

tcfhgj 4 hours ago | parent [-]

what about non-io code?

▲

messe 4 hours ago | parent [-]

What about it? It gets called without an Io parameter. Same way that a function that doesn't allocate doesn't get an allocator.

I feel like you're trying to set me up for a gotcha "see, zig does color functions because it distinguishes functions that do io and those that don't!".

And yes, that's true. Zig, at least Zig code using std, will mark functions that do Io with an Io parameter. But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust?

▲

torginus an hour ago | parent | next [-]

This creates the drill-down issue we see with React props where we have to pass objects around in the call chain just so that somewhere down the line we can use it.

React gets around this with the context hook and which you can access implicitly if it has been injected at a higher level.

Do you know if Zig supports something of the sort?

	▲	messe an hour ago \| parent [-]
		It doesn't and likely never will. This has been a non-issue for years with Allocator. I fail to see why it will be a problem with IO.

▲

tcfhgj 4 hours ago | parent | prev [-]

> But surely you can see how that will lead to less of a split in the ecosystem compared to sync and async rust?

not yet

▲ whytevuhuni 5 hours ago | parent | prev [-]

Here's a problem with that:

    Cannot start a runtime from within a runtime. This happens because a function (like `block_on`) attempted to block the current thread while the thread is being used to drive asynchronous tasks.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

▲

tcfhgj 4 hours ago | parent [-]

just pass around handles like you do in zig, alright?

also: spawn_blocking for blocking code

▲

whytevuhuni 3 hours ago | parent [-]

But that's the thing, idiomatic Rust sync code almost never passes around handles, even when they need to do I/O.

You might be different, and you might start doing that in your code, but almost none of either std or 3rd party libraries will cooperate with you.

The difference with Zig is not in its capabilities, but rather in how the ecosystem around its stdlib is built.

The equivalent in Rust would be if almost all I/O functions in std would be async; granted that would be far too expensive and disruptive given how async works.

▲

tcfhgj an hour ago | parent [-]

> But that's the thing, idiomatic Rust sync code almost never passes around handles, even when they need to do I/O.

Because they don't use async inside.

Zig code is passing around handles in code without io?

	▲	whytevuhuni an hour ago \| parent [-]
		> Because they don't use async inside. But they use I/O inside, and we arrive at this issue: I'm writing async, and I need to call std::fs::read. I can't, because it blocks the thread; I could use spawn_blocking but that defeats the purpose of async. So instead I have to go look for a similar function but of the other color, probably from tokio. In Zig, if you're writing sync, you call the standard library function for reading files. If you're writing async, you call the same library function for reading files. Then, the creator of the `io` object decides whether the whole thing will be sync or async.