russellthehippo

Joined 9 years ago

Karma
310
Submissions
100
Member since
Jan 11
View on Hacker News

Recent submissions

Comment · 2 months ago
Pretty cool apps! One thing i'd love to see for both is a historical view of the data - how do things change over time? Where is today relative the past five years for a given place? ten years? etc.
Comment · 3 months ago
Precisely this. Incredibly annoying headline
Comment · 3 months ago
Failures to allow faster generation/hookup rollout have suppressed supply increase relative to demand increase
Comment · 3 months ago
"VMs but it's on Hetzner so it's equally fast and 10x cheaper!" Hell yeah I also wanted to build this, good luck mate
Comment · 4 months ago
The key parts of this is how not vibecoded it is. Feels like a model of how you should do software with AI. Now that we can easily set up property testing, fuzzing, etc. there's almost no reason not to.
Comment · 4 months ago
"Welcome to the agentic substrate"

YAAS (yet another agentic substrate)

Comment · 4 months ago
There were real geographic and social tradeoffs to having status and power.
Comment · 6 months ago
Hi HN, I made this. My brother wanted to use per-tenant SQLite at his startup, but really likes Electric’s Shape model for Postgres. So I got curious to see if the same idea was feasible for SQLite.

Electrolite is “Electric-style Shapes, but for SQLite, embedded in an app.” The server defines authorized subsets of rows, the browser asks for one by name, gets an initial snapshot, then long-polls for logical changes captured by SQLite triggers.

It’s very experimental, not on npm yet, and the predicate language is intentionally small. I also wouldn’t describe it as deeply optimized yet. But in a local in-process smoke test, one SQLite write woke 1000 live Shape clients and all materialized the new row in ~100ms, so it looks promising for SQLite-first apps.

Would love your feedback and suggestions, and maybe it will even be useful for you.

Comment · 6 months ago
I'm finding in practice in using this process that you're right - it just doesn't work, even for one dev (usually). ha. But, the process of forcing plans to verify intent has worked pretty well! specifically the process of repeated adversarial review against a dual "will do, won't do" thing has been very, very useful at getting change plans to match intent.
Comment · 6 months ago
Appreciated your input on the original thread as well. Maybe I should note this recommendation in the docs or something.
Comment · 6 months ago
Author here. Yeah doesn’t depend on the underlying db if it speaks SQLite.
Comment · 6 months ago
Yup
Comment · 6 months ago
Respectfully (thanks haha) - yeah probably right. Original intent was to use inotify type thing but i avoided per-platform differences at the outset. this was definitely a for fun project that blew up unintentionally and am working to harden/improve.

Love Fly.

Comment · 6 months ago
Author here - previously posted here: https://news.ycombinator.com/item?id=47874647

Key difference vs SQL polling is that we’re touching metadata instead of data pages. I have work in process to make this work without any polling (innotify, kqueue, mmap’d shm file check) after the original stat(2) direction proved unreliable if lightweight.

Would love your feedback and or contributions in the repo - still figuring out the end shape.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton