3 ms·

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

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&edition=2024&gist=8abf9e00ef6039d9cd5f8fd7adc6bab0 https://play.rust-lang.org/?version=stable&mode=debug&editio...

tcfhgj 10mo ago
just pass around handles like you do in zig, alright? also: spawn_blocking for blocking code
- whytevuhuni 10mo ago
  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 10mo ago
    > 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 10mo ago
      > 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.
dwattttt 10mo ago
Fixed it for you https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a11c9acd1296c416b9bf330f9d2d2f87 https://play.rust-lang.org/?version=stable&mode=debug&editio...
thinkharderdev 10mo ago
Right, because this would deadlock. But it seems like Zig would have the same issue. If I am running something in a evented IO system and then I try and do some blocking IO inside it then I will get a deadlock. The idea that you can write libraries that are agnostic to the asynchronous runtime seems fanciful to me beyond trivial examples.

tcfhgj 10mo ago

just pass around handles like you do in zig, alright? also: spawn_blocking for blocking code

whytevuhuni 10mo ago
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 10mo ago
  > 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 10mo ago
    > 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.

dwattttt 10mo ago

Fixed it for you https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a11c9acd1296c416b9bf330f9d2d2f87 https://play.rust-lang.org/?version=stable&mode=debug&editio...

thinkharderdev 10mo ago

Right, because this would deadlock. But it seems like Zig would have the same issue. If I am running something in a evented IO system and then I try and do some blocking IO inside it then I will get a deadlock. The idea that you can write libraries that are agnostic to the asynchronous runtime seems fanciful to me beyond trivial examples.