We are building Cherry, a tool designd to solve the "spam crisis" currently hitting open-source maintainers.
With the rise of LLMs and agents, the volume of low-quality, automated PRs is making it impossible to find the good contributions.
How we want Cherry to work:
- Connects to your repo: We monitor incoming PRs.
- Whitelists the good bots: Dependabot, Linear agent etc., get a pass.
- Verifies the humans: We intercept new/unknown contributors and ask them to verify their intent and understanding of the code before the PR alerts the maintainers.
- Silences the rest: Low-effort scripts and drive-by spam get filtered out.
We are trying to walk the line between stopping spam and remaining open to new developers. It’s a hard problem.
We’d love to hear your thoughts on how to solve this without discouraging legitimate junior developers. What kind of heuristics do you currently use manually that we could automate?
I’ve been working on Hopp (a low-latency screen sharing app) using Tauri, which means relying on WebKit on macOS. While I loved the idea of a lighter binary compared to Electron, the journey has been full of headaches.
From SVG shadow bugs and weird audio glitching to WebKitGTK lacking WebRTC support on Linux, I wrote up a retrospective on the specific technical hurdles we faced. We are now looking at moving our heavy-duty windows to a native Rust implementation to bypass browser limitations entirely.
I think the title is stating this:
"Postgres LISTEN/NOTIFY does not scale"
That means for moderate cases you do not even have to care about this. 99% of PostgreSQL instances out there are not big "scale".
As a sr. engineer is your responsibility to make a decision if you will build for "scale" from day zero or ignore this as you are mindful that this will not affect you until a certain point.
It was really enjoyable to read. And I also do not read a lot of fiction, with my last book being the Hitchhiker's guide to the galaxy series.
My verdict is that Project Hail Mary was way much more engaging in terms of story-telling. The concepts were cool, and tbh I look forward for the movie and see if the adaptation will be nice
Long story short, I didn't want to make that analysis/distinction because it would miss the point.
They excel in their respective areas based on the architectural decisions they've made for the use cases they wanted to optimize for.
PlanetScale, with their latest Metal introduction, optimized for super low latency (they act like they've reinvented the wheel, lol), but they clearly have something in mind going in this direction.
Neon offers many managed features for serverless PostgreSQL that were missing in the market, like instant branching, and with auto-scaling, you may perform better with variable workloads. From their perspective, they wanted to serve other use cases.
There's no reason to always compare apples to oranges, and no reason to hate one another when everyone is pushing the managed database industry forward.