We plan to have in Zig a testing `Io` implementation that will potentially use fuzzing to stress test your code under a concurrent execution model.
That said, I think a key insight is that we expect most of the library code out there to not do any calls to `io.async` or `io.asyncConcurrent`. Most database libraries for example don't need any of this and will still contain simple synchronous code. But then that code will be able to be used by application developers to express asynchrony at a higher level:
io.async(writeToDb)
io.async(doOtherThing)
Which makes things way less error prone and simpler to understand than having async/await sprinkled all over the place.
More powerful than a “fuzzing” test io would be a deterministic test io. I.e., one you can tick forward the various concurrent branches deterministically to prove that various races are safely handled. This makes it possible to capture all those “what if thread A executes this line first then B is executed” etc. Something that is missing in most concurrent frameworks.
That said, I think a key insight is that we expect most of the library code out there to not do any calls to `io.async` or `io.asyncConcurrent`. Most database libraries for example don't need any of this and will still contain simple synchronous code. But then that code will be able to be used by application developers to express asynchrony at a higher level:
Which makes things way less error prone and simpler to understand than having async/await sprinkled all over the place.