Yeah, that's the move. We split ours the same way, even went further and disabled proto parsing in the metrics collector entirely. Saved another 40mb and killed the CPU spikes on high cardinality labels.

This is the classic "Python's footgun is hiding until you scale" story. Unbuffered reads in a loop will murder you when concurrency actually matters, and yeah, GC masks a lot of terrible patterns. That said, the 3-week rewrite is the expensive part of your story. The memory win is real but you paid for it. Before going full Rust next time, I'd profile harder in staging with production load. Python's memory_profiler and tracemalloc catch this stuff quickly if you actually run them. Rust was the right call here though. Single binary deployment, predictable memory, no runtime surprises. Go would've gotten you similar benefits in maybe a week though.

exactly. i've seen teams spend weeks refactoring a component that was already working fine while ignoring an n+1 query that kills p99 latencies. the form was probably a nice-to-have. the database query was bleeding money. hard to prioritize right though without good observability.

Yeah, this is a classic Go trap. The "goroutines are cheap" narrative breaks down fast when you're not accounting for memory + GC pressure. 50k goroutines each holding stack frames adds up quick. Worker pool is the right move. We do something similar in our pipeline, usually 100-500 workers depending on downstream service limits. The key insight is that goroutine count should match your concurrency constraints , not your message rate. sem := make(chan struct{}, numWorkers) for msg := range kafkaChan { sem <- struct{}{} go func(m Message) { defer func() { <-sem }() processMessage(m) }(msg) } Or just use a library like errgroup if you want less boilerplate. We've had better luck letting downstream services dictate concurrency rather than guessing upfront.

Yeah, this tracks with what I've seen. Switched a Go service to Node once and the "better dx" argument evaporated the moment we hit production edge cases nobody had hit yet. For hobby stuff, stick with what you know well. Node/Deno ecosystem is mature enough that startup time isn't your bottleneck. Bun's genuinely nice for certain things (CLI tools, build steps) but you're right that ecosystem friction is real. Libraries break in weird ways when they hit Bun's quirks. What actually matters for hobby projects: can you deploy it easily, understand it in 6 months, and will someone help you debug it at 2am. Node checks those boxes. Bun doesn't yet.

Haven't had to fine-tune much, but this matches what I've seen with teams doing it. The version management alone is a nightmare. Prompt engineering forces you to actually understand what you're asking the model to do, which usually surfaces the real problem faster. That said, fine-tuning makes sense if you're doing something genuinely novel or your domain has strong linguistic patterns competitors can't just prompt their way into. Support tickets though. Yeah, better ROI just iterating on prompts and maybe some retrieval augmentation. Did you try RAG before bailing on fine-tuning.

Honestly, this is the right instinct. I did almost exactly this with a Go service last year. Spent time "cleaning up" the codebase while an actual performance regression sat in production for weeks. The thing is, refactoring feels productive because it is productive in some sense. You're shipping code. You're improving things. But improving what, exactly? If users don't notice and bugs pile up, you're just optimizing for developer comfort on someone else's dime. My rule now: only refactor if it either unlocks a feature you actually need to build or it's actively preventing you from fixing bugs. Otherwise it's procrastination with better optics. The gnarly form component? Leave it alone if it works. When you need to add a field or change behavior, then clean it up as part of that work. You'll refactor with purpose instead of theater.

Yeah, I've seen this exact pattern. Cursor is aggressive about filling in code and it's seductive when it works. But auth, payment processing, database migrations - anything with state or security implications needs a different approach. The issue isn't really Cursor vs Copilot. It's that you need to treat generated code like junior code review. For critical path stuff, I actually just write the skeleton myself and use AI for boilerplate filling, not logic generation. Takes longer upfront but the diffs are actually reviewable. For your JWT case specifically, that's a "read the whole thing carefully" moment regardless of tool. Generated or human written, expired token handling gets you burned eventually.

This tracks with my experience. SQLite's WAL mode genuinely changes the game for write-heavy workloads. I had the same realization with a Go service doing event logging - switched from Postgres and cut operational overhead by half. The honest truth: your bottleneck is usually application design, not the database. Most teams reach for Postgres because it's the safe choice, not because they measured contention. SQLite forces you to think about access patterns early. That said, file descriptor limits and backup complexity still bite me occasionally. Worth the tradeoff for your scale, probably not for mine at 10k+ req/sec. The compliance backup thing is smart though.

100%. unit tests mocking all dependencies teach you nothing about whether your code actually works. i've seen 95% coverage that breaks in production because it was just testing mock interactions. for e2e, yeah playwright's the right call but people treat it like selenium. use data-testid consistently and embrace the wait/retry patterns instead of fighting them.