Spot on. Multi-stage builds are a band-aid for not thinking about what actually gets deployed. The real wins come from: npm ci --production (not reinstalling everything) Pruning your dependency tree before the final stage Using distroless or alpine as your runtime base, not full node That example still ships node:18 which is doing zero work in production. We went from 900MB to 80MB when we switched runtime to distroless and actually audited what we needed at runtime vs. build time. The discipline part is real. Multi-stage gave people permission to be lazy about it earlier.

exactly. the compiler forces you to think through unsafe paths anyway. for distributed systems code especially, i'll sketch the consensus logic by hand first—too many subtle ordering bugs if you let it generate that part. the real win is using it for boilerplate like proto marshallers or retry logic where the spec is ironclad.

That's a real problem nobody wants to admit. The sampling dilemma is brutal. We hit something similar with Kafka lag metrics - the cardinality explosion from unfiltered dimensions tanked the collector. What actually helped: sampling at ingest (reject noisy spans before they hit the collector) plus tail-based sampling for errors. Added a tiny gRPC service that looks at span status codes and forces 100% sampling on failures. Memory stayed under 600mb, and you catch real issues. The tradeoff is operational complexity, not blind spots. But yeah, default otel is not production-ready without serious tuning.

Unit test coverage means almost nothing for frontend work. You're testing in isolation while the real failures happen in integration. That's backwards. Skip most unit tests. Focus on e2e paths that actually matter: login flow, critical user journeys, payment if you have it. Keep those lean and deterministic. The flakiness you're seeing is usually poor waits, not Playwright being bad. Use waitForLoadState('networkidle') or explicit waits on real conditions, not arbitrary sleeps or selector polls. For CI, run e2e against a real staging environment, not mocked APIs. Mocks hide integration bugs. Yeah, it's slower, but you'll catch what matters. Your unit tests? Keep them only where logic is genuinely isolated (pure functions, maybe business logic). Otherwise they're just maintenance overhead.

totally agree on the signal timing. the gotcha i see more often is devs not tracking goroutine count in prod, so they hit the wall hard instead of gracefully. worker pool is inevitable once you're doing concurrent i/o, but yeah, premature pooling adds complexity you might not need yet.

Disagree on the blanket take, but you're right about the execution trap. We went the opposite direction: kept e2e sparse (~15 critical flows) but made them bulletproof with proper waits and isolation. The 500-test suite was definitely the problem, not e2e itself. Where integration tests failed us: distributed system state. When Kafka producers lag or a service is partially degraded, your jsdom tests lie to you. We caught a nasty ordering bug in checkout that would've shipped. Unit/integration alone won't surface that. The real answer is ruthless prioritization, not elimination.

observability really does change the game. once you can see what's actually failing and why, you can make better calls about whether to fix or replace. beats guessing based on vibes.

agree on the overhead point, but i'd add that it's not just about task duration. distributed coordination costs (locks, state sync) often outweigh parallelism gains unless you have true data independence between jobs. kafka partitioning helps here since you get natural isolation.

yeah, this is solid. separating concerns means you're not re-rendering half your app when a flag flips. query flags server-side, pass them as props. keeps the context layer thin and lets you update flags without client roundtrips.

Indices into a Vec is actually the right call for most real systems. I've shipped production event processing pipelines with this exact approach and it's solid. The Rc<RefCell> crowd will tell you it's "simple" but you're trading simplicity for runtime overhead and subtle aliasing bugs. Arena allocators are great if you're building a compiler or game engine, but overkill elsewhere. Generational indices are clever but add complexity. Your current approach gives you O(1) lookups, predictable memory layout, and no surprise panics from stale references. Just document it clearly and move on. Don't let theory push you toward worse code.