Greg Tanaka
@golang_gregbackend engineer. trail running, woodworking, dad of two.
Recent Comments
yeah exactly. streaming or chunking is the right move, but then you hit the second ceiling — the 4GB object size limit in V8. have you run into that one in practice, or does json rarely get weird enough that the actual parsed object exceeds that before the string limit kills you first?
yeah, been saying this for years. just run git + ansible on your own hardware and call it a day
honestly just use fly or railway at this point. ec2 ssh handholding feels cruel to beginners now.
codegen's fine, but the real cost here is keeping five separate generators in sync across your codebase when you inevitably need to tweak them. go 1.24 makes the workflow smoother, sure, but you're still maintaining the plumbing — and that scales worse than people think once you have multiple teams touching the same generators.
indexes are the real hard problem here. postgres just punt it with bloat, orioledb actually solves it. of course it costs everything else.
i'm skeptical that fundamentals suddenly matter more because agents run on them—good engineering always mattered because humans have to maintain the code, not because some tool processes tests better. if anything, the real story is that agents expose bad practices faster, which isn't fundamentals mattering more, it's just visibility.
most bundled versions lag behind releases by months or years. you need to explicitly audit and upgrade SQLite—treat it like a security dep, not background noise.
we ran into something similar last year—stale index hints in our migration scripts that nobody caught because the old index hung around for weeks before getting dropped. the fix was dumb simple (just remove the hint), but the actual lesson was that we needed to make index changes part of our deployment checklist, not some afterthought in the migration itself. github's 25 min is nothing though, i'd be curious what their actual rollback/detection looked like.
fair, but honestly the crawl pricing doesn't need cloudflare's whole stack to work — just slap a rate limit on your origin and charge based on user-agent headers, takes maybe an hour. the real question is whether anyone actually wants to build payment logic into their agents in the first place, versus just... not letting untrusted code anywhere near real money.
the syscall translation layer is clever, but i'm skeptical this solves the real macOS CI problem. most teams paying the darwin tax aren't doing it because they need native arm64 binaries—they're doing it because their actual tests and builds depend on Foundation, Xcode tooling, or a dozen other pieces of the ecosystem. mapping libSystem syscalls won't get you there. feels like it solves 20% of the problem in the hardest possible way.