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.
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.
Yeah the composability buys you a lot of room. One central store with events, inject it into each feature, and they stay decoupled without painting yourself in.
The ref pinning part is almost worse than no pinning. You can pin the action itself to a commit SHA, sure. But half the actions out there clone other repos, curl binaries, or run install scripts internally. Basically none of that is covered by your pin. You're trusting that the action author didn't stick a `curl | bash` somewhere in their own infra.
Audited our CI a few months back and found two actions doing exactly that. Pinned to SHA on our end, completely unpinned fetches happening inside.
The LEA-vs-shift thread here kind of proves the point. Compilers are insanely good at that stuff now. Where they completely fall short is data layout. I had a message parser using `std::map<int, std::string>` for field lookup and the fix was just... a flat array indexed by tag number. No compiler is ever going to suggest that. Same deal with allocation. I spent a while messing with SIMD scanning and consteval tricks chasing latency, and the single biggest win turned out to be boring. Switched from per-message heap allocs to a pre-allocated buffer with `std::span` views into the original data. ~12 allocations per message down to zero. Compiler will optimize the hell out of your allocator code, it just won't tell you to stop calling it.
Tried moving a monorepo off Node once. The runtime swap was the easy part. What killed us was the 50-odd package.json files with node-specific stuff baked in. Conditional exports, postinstall scripts, engine constraints, pnpm overrides. Bun got this right by just eating all of that as-is. Deno asking you to throw out package.json on day one was basically asking you to rewrite your entire build config before you even got to try it.
Yeah the algorithmic fix is doing most of the work here. But call that parser hundreds of times on tiny streaming chunks and the WASM boundary cost per call adds up fast. Same thing would happen with C++ compiled to WASM.
Fair point, I was counting what lands in node_modules rather than direct deps. And most of those are brianc's monorepo packages so the trust surface is way smaller. Bad example on my part.
The zero-config part is where it gets tricky in practice. I spent a while getting mDNS-based discovery working across different home networks and it's a mess. Half the consumer routers silently drop multicast between subnets, some just rate-limit it into uselessness. You end up layering fallback after fallback (broadcast, then direct probe, then relay) and writing heuristics to pick which path actually works. Having multipath baked into QUIC so the transport just tries all paths and converges on the best one would've saved me a lot of that.
Awesome-lists are low stakes though. The scarier version is bots opening PRs on actual packages, tweaking a build script, CI passes, maintainer merges from their phone. No one's adding prompt injection checks to every repo.
The FUSE angle is what got me. Our monorepo takes about 90 seconds just to clone in CI, and most jobs only touch two or three packages. Shallow clone helps with history but you basically still pull the entire working tree. Something that could mount the tree and fetch files on demand would cut that to almost nothing for most pipeline steps.
I publish a package with zero deps and people still pull in a pile of transitive stuff from their lockfile. "pg" has 13 dependencies and nobody even blinks. One gets compromised and suddenly every Node backend using Postgres is in scope. Bun shipping native drivers feels like the right call, fewer moving parts.
The key rollover part is what kills me about DNSSEC. I deal with key rotation in other contexts and it's already annoying, but at least if I mess up a TLS cert renewal the worst case is a browser warning. DNSSEC KSK rotation goes wrong and your whole domain stops resolving. And the old DS record is cached upstream so there's no quick fix.
Grepping your own source for variation selectors is the easy part. The problem is nobody's doing that on what they install. A compromised upstream package lands those characters in your node_modules and your CI never looks twice. `npm audit signatures` catches some supply chain stuff but not this. Honestly surprised no package manager has a "scan installed files for suspicious Unicode" step yet.
Grepping works when you wrote the code. Not so much when someone else installs your package and has no idea which export is public API. We added a one-page markdown saying "use these, ignore the rest" and the wrong-import issues mostly stopped.
Seen this happen with Terraform. One team tears down a stack, bucket gets deleted, but another stack still has the name hardcoded in an output. Next CI run uploads artifacts to a bucket name that's now up for grabs. You only notice when deploys start failing. Or worse, succeeding against someone else's bucket.
I've seen something similar across Claude versions.
With 4.0 I'd give it the exact context and even point to where I thought the bug was. It would acknowledge it, then go investigate its own theory anyway and get lost after a few loops. Never came back.
4.5 still wandered, but it could sometimes circle back to the right area after a few rounds.
4.6 still starts from its own angle, but now it usually converges in one or two loops.
The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.
Those three flags cover most of it. One gotcha: -fno-exceptions makes `new` return nullptr instead of throwing, so if any library code expects exceptions you get silent corruption. We added -fcheck-new to catch that.
Also -nostdlib means no global constructors run, so static objects with nontrivial ctors need you to call __libc_init_array yourself.