Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647

Live notifications was one of the big missing pieces to implement whole apps on a sqlite backend, and now there's a decent solution.

> Gofmt's style is no one's favorite, yet gofmt is everyone's favorite - Rob Pike https://go-proverbs.github.io/#:~:text=Gofmt%27s%20style%20i...

The best part about gofmt is there is no discussion about how to format Go code. The style itself is fine, skipping endless hours of pointless debate is priceless.

So where are we going? Mitchell will be deciding for Ghostty. If github's current trajectory is anything to go by, everyone else will need to decide where to go sooner rather than later.

I'm worried that it will be a Babel scattering event and this open source superpower that github catalyzed (how to describe it?) will just evaporate.

I'm also worried that wherever we go next could have the same fate as github.

So what then? Radicle is the only thing that I've seen that could theoretically 'solve' the problem, though it still needs a lot of work: https://radicle.dev/

Care to share your code? This may become a bug report.

> [SQLITE_FCNTL_DATA_VERSION] is the only mechanism to detect changes that happen either internally or externally and that are associated with a particular attached database.

Another user itt says the stat(2) approach takes less than 1 μs per call on their hardware.

I wonder how these approaches compare across compatibility & performance metrics.

Would it help if subscriber states were also stored? (read position, queue name, filters, etc) Then instead of waking all subscription threads to do their own N=1 SELECT when stat(2) changes, the polling thread could do Events INNER JOIN Subscribers and only wake the subscribers that match.