Comment by t43562 | Hacker News Reader

Comment by t43562 | Hacker News Reader

I think it's a great idea to not have to have two libraries - so its a "tick" from me for any idea that permits it.

The thing that bothers me in general about asynchronous code is how you test it so that you know with some confidence that if it passes the tests today you have replicated all the scenarios/orderings that might happen in production.

You have this same problem with threads of course and I've always found multithreaded programs to be much harder to write and debug....such that I personally use threading only when I feel I have to.

The actual problem with it is that caution is communicating it to developers. I recently had to work on a python system where the developers were obviously doing Javascript half the time. So ... hooray.... they put out a huge changeset to make the thing async....and threaded. Oddly enough none of them had ever heard of the GIL and I got the feeling of being seen as an irritating old bastard as I explained it to their blank stares. Didn't matter. Threading is good. Then I pointed out that their tests were now always passing no matter if they broke the code. Blank stares. They didn't realise that mangum forced all background tasks and async things to finish at the end of an HTTP request so their efforts to shift processing to speed up the response were for nothing.

Knowing things doesn't always matter if you cannot get other people to see them.

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 resonates. Testing asynchronous and multithreaded code for all possible interleavings is notoriously difficult. Even with advanced fuzzers or concurrency testing frameworks, you rarely gain full confidence without painful production learnings.

In distributed systems, it gets worse. For example, when designing webhook delivery infrastructure, you’re not just dealing with async code within your service but also network retries, timeouts, and partial failures across systems. We ran into this when building reliable webhook pipelines; ensuring retries, deduplication, and idempotency under high concurrency became a full engineering problem in itself.

That’s why many teams now offload this to specialized services like Vartiq.com (I’m working here), which handles guaranteed webhook delivery with automatic retries and observability out of the box. It doesn’t eliminate the async testing problem within your own code, but it reduces the blast radius by abstracting away a chunk of operational concurrency complexity.

Totally agree though – async, threading, and distributed concurrency all amplify each other’s risks. Communication and system design caution matter more than any syntax or library choice.

> That’s why many teams now offload this to specialized services like Vartiq.com

It would be nice to add a disclaimer that this is a system you're working on.

Thanks for pointing out. Edited. :)

Reply on news.ycombinator.com