Just seems kinda weird to give advice on forums when you're not speaking from actual relevant experience. I'm getting meat proxy answers and confident replies from people who've never done what they're suggesting others do.

Or did someone else do this work and you assumed it was effective? Or did you personally implement this change and then validate that the before/after metrics improved as a result?

Have you actually done this yourself for Go programs that you've deployed into production? If so, what were the circumstances? Was it your solution to latency spikes?

His reply below was presumably killed by mods for doing this: https://news.ycombinator.com/item?id=49970841

Introducing mlock is operationally annoying and trying to solve the wrong problem. It requires elevated container permissions, it's not something your SRE team is going to expect, few programs do it, and it has all kinds of technical implications and interactions with kernel OOM system, forking, the Go GC, etc.

And nothing about mlock solves the problem of having insufficient RAM for your workload.

There are very specific scenarios where mlock is exactly the right solution but the typical Go HTTP service is not one of them. The KISS principle applies.

To be more explicit about my advice: disable swap and ensure you have sufficient memory for your workload.

Your 14 MB Go binary is not the source of your memory pressure. Your memory pressure is coming from the allocated anonymous pages supporting your programs data structures on the heap.

Have sufficient memory for your workload, monitor it, and let the Go GC and kernel manage memory normally. This will work exactly as you'd hope.

"Stop doing that"

If you care about latency, disable swap. System wide or for the specific the cgroup.

In Oct 2026, if you're optimizing for productivity, then yes, you probably should just use both Claude and Codex in a GUI agent multiplexer and forget about everything else.

If you care about other things, then have fun, no one is stopping you. I'd disagree with you that using alternatives mean you take more "care" and have more "pride" in your tools, but it's hardly worth arguing over.

I usually recommend Conductor to most people. Personally, I use the one I built, but it's got a few ergonomic issues for most people which I still need to fix.

I love open source. I love the terminal. I spent the last 20+ years in a terminal w/vim every single day, and then claude/codex TUIs, and yet I care more about my own productivity so I don't use any of that now.

For example, humans will almost certainly be able to re-create the human brain in some kind of hardware+software computer. We just don't know when. It might be much sooner or much later than you'd expect.

Merely being skeptical of progress isn't a convincing answer to the AI x-risk argument.

But the AI x-risk argument is about what happens when we have "real" AI that can actually think like humans but a million times faster.

There are no real experts on this and yet it does seem worth worrying about in advance.

And it's great they did find personal connection on Stack Overflow, but it was infamous for its hostility to noobs. It's sad to say, but Stack Overflow very possibly discouraged more people than it encouraged in this way.

I'd guess that both IRC and Discord have a much better track record of personal connection and helping people, and they're still thriving.

Were StackOverflow, Google, and LLMs not all created by people who cared enough to help you?

There are much better places on the internet to find personal connection than StackOverflow ever was.

There's no arguing with someone who claims God forced them to do something, but I do wish this person good luck in whatever they do next.