jacobgold

Can't complain too much about 86 years but I'll miss him. I worry how it'll feel to watch him now.

Whether they can compete on decision models or not, TypeSafe showed that a lot of the market had missed something important. With this much money, they have a lot more chances to discover other important things that are missing.

Alright, so you didn't implement it. And you're describing a "pacemaker task on an event loop"? That doesn't sound like a Go program at all, where we don't have a single event loop to measure and we have built-in runtime metrics.

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.

Your Go binary was being swapped out due to memory pressure, causing latency, and using mlock was your fix for this problem?

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?

I didn't claim it was hard or risky.

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?

I see that you've rewritten your AI generated reply there. So when have you used mlock in production for Go services, the way you're advising others to do? What were the circumstances?

We're trying to solve a problem: we don't want huge latency spikes caused by swapping memory to disk. The only good solution to that is to have sufficient RAM. It's that simple.

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.

No, do not try to use mlock to avoid swapping, except in very specific scenarios. That way lies madness.

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.

"It hurts when I do this"

"Stop doing that"

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

You're inferring things I did not actually imply.

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.

The important thing is just to a GUI agent multiplexer, they're all mostly doing the same kind of thing. IMHO it's very important to have the official claude and codex harnesses (not just models). I also like having each session in a isolated container (or VM) so the agent can go wild and run in yolo mode.

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.