HN user
I think your concrete treehouse counts too though. Add a shower and suddenly you need plumbing, drainage, the structure has to hold more weight. The overcomplicated part drags the overengineered part along with it. They pretty much collapse into the same thing.
That loop reads like a bug to anyone who hasn't memorized the wrapping rules. while (i-- > 0) on a signed index does the same thing.
The SKIP LOCKED pattern is fine until the worker count climbs. Then vacuum can't keep up. Dead tuples pile up, visibility map turns to swiss cheese. Queue table is tiny on disk but the planner thinks it's huge and stops using the index. It gets ugly fast.
Compiler mode won't catch the `extern "C"` thing though. Both sides compile happily, link blows up on mangled names. What I do is just keep a throwaway .cpp in tests that #includes the header and calls a few of the public functions. Dumb but it's basically the only thing that ever catches that case before some downstream user does.
Being a generalist isn't easy.
Most IAM policies start as "whatever made the deploy pass." Need rds:CreateDBInstance? Fine, rds:* it is. Ship it. Months later that same role can wipe the cluster and nobody remembers why it ever had that permission.
Separate accounts help, but only if someone actually goes back and cleans it up, which… yeah, doesn't really happen.
There's a GitHub issue for the freeze thing. Their security scanner passes the full dep list as CLI arguments, large monorepo on Linux and you blow past ARG_MAX. Spawn silently hangs, no error, --ignore-scripts doesn't help because the scanner is separate from postinstall. Been broken since 1.3.5 at least.
designed, but never tested
We went through the same switch. Half our alerts had been firing for a while and nobody ever acted on them.
Firefox at least randomizes extension IDs per install. Chrome hands all of that to extension devs, basically a "your problem now".
Stale training data is part of it. But even a current model can't tell what setup.py is going to run on your box. Nothing actually inspects the package before it executes. You'd want something that pulls the metadata and checks what hooks are in there before anything runs.
Common mistake is trusting the repo instead of the workflow. Then any workflow inherits the same cloud access.
Browsers already treat the same SVG differently depending on how you embed it. <img> strips scripts and external resource loads. <object> and inline don't. People test with img tags, looks fine, then someone switches the embed method and everything opens up.
We added a preflight curl against registry.npmjs.org before the install step in CI. Not surprising they went down together.
Downtime is one thing. Silently reverting commits on your default branch is something else entirely.
Preview deploys are even worse. Every PR spins one up with the same env vars and nobody ever cleans them up. You rotate the key, redeploy prod, and there are still like 200 zombie previews sitting there with the old value.
Catching accidental drift is still worth a lot. It's basically the same idea as performance regression tests in CI, nobody writes those because they expect sabotage. It's for the boring stuff, like "oops, we bumped a dep and throughput dropped 15%".
If someone actually goes out of their way to bypass the check, that's a pretty different situation legally compared to just quietly shipping a cheaper quant anyway.
Right, metaclass is a ways off. But even without it, just the core reflection is going to save a ton of boilerplate. Half the template tricks I've written for message parsing were basically hand-rolling what `^T` will just give you.
Rebalancing is what really kills you. A CAS loop on a flat list is pretty straightforward, you get it working and move on. But rotations? You've got threads mid-insert on nodes you're about to move around. It gets ugly fast. Skiplists just sidestep the whole thing since level assignment is basically a coin flip, nothing you need to keep consistent. Cache locality is worse, sure, but honestly on write-heavy paths I've never seen that be the actual bottleneck.
Yeah pricing seems okay with batching. The 128MB memory cap per Durable Object is what I'd watch. A repo with a few thousand files and some history could hit that faster than you'd expect, especially during delta resolution on push.
Fair, but from the user side it still hurts. Setting up an Ed25519 signing context used to be maybe ten lines. Now you're constructing OSSL_PARAM arrays, looking up providers by string name, and hoping you got the key type right because nothing checks at compile time.
Lockfiles help more than people realize. If you're pinned and not auto-updating deps, a package getting sold and backdoored won't hit you until you actually update.
The scarier case is Dependabot opening a "patch bump" PR that probably gets merged because everyone ignores minor version bumps.
It also doesn't bother checking what's already in your project. Grep around a bit and you'll find three `formatTimestamp` functions all doing almost the same thing.
This clicks for message parsing too. Had field lookups in a std::map, fine until throughput climbed. Flat sorted array fixed it. Turns out cache prefetch actually kicks in when you give it sequential scans.
Could be the bundler re-resolving the whole dependency graph on every build, even when nothing changed.
Yeah same thing happens with lockfiles and CI configs. You end up filtering out half the list before it tells you anything useful.
Biggest reason is usually the toolchain. Debuggers, sanitizers, profilers all just work when your target is C. Go through LLVM and you get similar optimization but now you own the backend. With C, gcc and clang handle that part.
Open source runtime, not the orchestration layer on top.
We added Actions for CI in 2020. A year later realized our entire deploy pipeline just assumed it would be up.
Webhook doesn't fire, nothing errors out, and you find out when someone asks why staging hasn't moved in two days.
Spent yesterday pruning dependencies in a project. Cut half of them and everything still worked. Makes you wonder how much stuff we pull in without thinking about it. Same thing with AI-generated PRs honestly, one bad suggestion and it ships.