Coroutines went through the same cycle. Standardized in C++20, and I still hit compiler-specific differences in how symmetric transfer gets lowered.

Scanners catch most of these within hours. The cooldown just buys them time to run, not waiting for some other dev to get hit first.

Switch is fine until you hit five or six states with cleanup in each branch. Then it's just a worse version of what coroutines give you for free.

Operating at -40 is one thing, charging at -40 is another.

I have no idea how true this is, but the press releases claimed that both most of the capacity is retained down to -40 and that the charging speed is proportionally retain down to -40, and that this is the meaning of the operational range.

Right, good to know.

When you're at a charger you can easily spare the 3-4% of battery capacity it takes to heat the pack by 40C. Less if you use a heat pump.

How many people let their ICE engine block get that cold?

For -40, the anecdote for combustion engines used to be that in Siberia you turn on the car's engine in november and off in march.

For -20 though, it can happen each year in 4 season temperate climates and north of that.

i would have imagined that charging at -40 is easier than operating at -40.

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.

In this case I'm talking about what the Action did internally. The git clone inside was not pinned, but is now.

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.

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.

Is your project public?

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.