Zig's new plan for asynchronous programs
1–10 of 274 posts
Re: Zig's new plan for asynchronous programs
#2I like the look of this direction. I am not a fan of the `async` keyword that has become so popular in some languages that then pollutes the codebase.
Re: Zig's new plan for asynchronous programs
#3I like the look of this direction. I am not a fan of the `async` keyword that has become so popular in some languages that then pollutes the codebase.
Async usually ends up being a coloring function that knows no bounds once it is used.
Re: Zig's new plan for asynchronous programs
#4I’m excited to see how this turns out. I work with Go every day and I think Io corrects a lot of its mistakes. One thing I am curious about is whether there is any plan for channels in Zig. In Go I often wish IO had been implemented via channels. It’s weird that there’s a select keyword in the language, but you can’t use it on sockets.
Re: Zig's new plan for asynchronous programs
#5I like the look of this direction. I am not a fan of the `async` keyword that has become so popular in some languages that then pollutes the codebase.
In JavaScript, I love the `async` keyword as it's a good indicator that something goes over the wire.
Re: Zig's new plan for asynchronous programs
#6I'm excited to see where this goes. I recently did some io_uring work in zig and it was a pain to get right.
Although, it does seem like dependency injection is becoming a popular trend in zig, first with Allocator and now with Io. I wonder if a dependency injection framework within the std could reduce the amount of boilerplate all of our functions will now require. Every struct or bare fn now needs (2) fields/parameters by default.
Re: Zig's new plan for asynchronous programs
#7I like the look of this direction. I am not a fan of the `async` keyword that has become so popular in some languages that then pollutes the codebase.
Async usually ends up being a coloring function that knows no bounds once it is used.
I’ve never really understood the issue with this. I find it quite useful to know what functions may do something async vs which ones are guaranteed to run without stopping.
In my current job, I mostly write (non-async) python, and I find it to be a performance footgun that you cannot trivially tell when a method call will trigger I/O, which makes it incredibly easy for our devs to end up with N+1-style queries without realizing it.
With async/await, devs are always forced into awareness of where these operations do and don’t occur, and are much more likely to manage them effectively.
FWIW: The zig approach also seems great here, as the explicit Io function argument seems likely to force a similar acknowledgement from the developer. And without introducing new syntax at that! Am excited to see how well it works in practice.
Re: Zig's new plan for asynchronous programs
#8I'm excited to see where this goes. I recently did some io_uring work in zig and it was a pain to get right. Although, it does seem like dependency injection is becoming a popular trend in zig, first with Allocator and now with Io. I wonder if a dependency injection framework within the std could reduce the amount of boilerplate all of our functions will now require. Every struct or bare fn now needs (2) fields/param…
I think and hope that they don’t do that. As far as I remember their mantra was „no magic, you can see everything which is happening“. They wanted to be a simple and obvious language.
Re: Zig's new plan for asynchronous programs
#9Earlier quoted context omitted.
Async usually ends up being a coloring function that knows no bounds once it is used.
I’ve never really understood the issue with this. I find it quite useful to know what functions may do something async vs which ones are guaranteed to run without stopping. In my current job, I mostly write (non-async) python, and I find it to be a performance footgun that you cannot trivially tell when a method call will trigger I/O, which makes it incredibly easy for our devs to end up with N+1-style queries withou…
In my (Rust-colored) opinion, the async keyword has two main problems:
1) It tracks code property which is usually omitted in sync code (i.e. most languages do not mark functions with "does IO"). Why IO is more important than "may panic", "uses bounded stack", "may perform allocations", etc.?
2) It implements an ad-hoc problem-specific effect system with various warts. And working around those warts requires re-implementation of half of the language.
Re: Zig's new plan for asynchronous programs
#10Earlier quoted context omitted.
Async usually ends up being a coloring function that knows no bounds once it is used.
I’ve never really understood the issue with this. I find it quite useful to know what functions may do something async vs which ones are guaranteed to run without stopping. In my current job, I mostly write (non-async) python, and I find it to be a performance footgun that you cannot trivially tell when a method call will trigger I/O, which makes it incredibly easy for our devs to end up with N+1-style queries withou…
Is this Django? I could maybe see that argument there. Some frameworks and ORMs can muddy that distinction. But most the code ive written its really clear if something will lead to io or not.