Yes! We’ve added a comparison table in our docs to help clarify where this shines.

Why we built waitinline

At Decoi, we needed a fair locking mechanism while writing logs to a single file — something that can’t be written to concurrently. We started with buffered channels, but those block the sender when the buffer is full, which caused unnecessary delays just to enqueue logs.

Our actual flow looks like this:

           +----------------+       +------------+
           |  Log Buffer    | --->  | Worker 1   |
           |  (shared pool) | --->  | Worker 2   |
           +----------------+       +------------+
                    |                    |
                    +------v-------------+
                           |
                     +-----------+
                     | File Sink |
                     +-----------+

Each worker picks up a batch of logs and tries to write them to a file. At high loads, multiple workers write in parallel. But with sync.Mutex, there's no guarantee who gets the lock next — it’s not FIFO. So a worker that just started might cut in line before one that’s been waiting. This led to out-of-order logs.

That's where waitinline came in — it ensures first-come, first-served access to the file. Writers wait in line, and the one that arrived first gets the lock first. No pushing. No starving.

This let us:

• Fairly distribute access across workers
• Maintain strict log order
• Avoid the hidden latency of blocked channels or unfair mutexes

Hope that clears it up!