Comment by ecshafer
Comment by ecshafer 21 hours ago
I 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.
Comment by ecshafer 21 hours ago
I 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.
Why? Asynchrony has nothing to do with multiple threads. In fact you can have async with only a single thread!
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.
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.
I've watched many changes over time where the non async function uses an async call, then the function eventually becomes marked as async. Once majority of functions get marked as async, what was the point of that boilerplate?
In JavaScript, I love the `async` keyword as it's a good indicator that something goes over the wire.