You know the feeling. You fire up your favorite tool, the one you’ve spent hundreds of hours configuring to perfection. It’s powerful. It’s deeply yours. And it takes eleven seconds to render a split screen.
Welcome to the bittersweet hell of being a power user.
Enter Neo Emacs, a shiny new project promising the holy grail of software development: modern design, multi-threaded Elisp, 10x performance, and 100% Emacs compatibility. It sounds like a dream. But it’s actually a mathematical impossibility.
You cannot build a modern engine inside a chassis designed for a horse carriage.
You’ve probably noticed this in your own work. The moment you try to add a modern, asynchronous feature to a legacy codebase, the ghost of global state comes back to haunt you. Emacs is the ultimate example of this. Its entire ecosystem, every beloved package and quirky extension, relies on shared global state. It is inherently, aggressively hostile to multithreading.
The developers of Neo Emacs are trying to have their cake and eat it too. They want the performance of a modern IDE but the backwards compatibility of a 1980s architecture. It won’t work. The comments on their own announcement prove it: “100% compatibility may be very often at odds with multi-threaded elisp.” It’s not “at odds.” It’s a death sentence.
Backward compatibility is not a feature. It is an anchor tied to your ankle in the ocean of progress.
Look at Vim. It didn’t get saved by a compatible rewrite. It got saved by Neovim, which had the guts to break things, throw out the garbage, and build a modern architecture from scratch. Emacs needs a Neovim moment, but a true one. Not a half-measure that drags the legacy baggage along.
The community already knows the answer. When one user pointed out the architectural paradox of Neo Emacs, another simply replied: “Why not… Lem?”
Lem is a ground-up alternative. It’s what happens when you accept that the old architecture is unfixable. You don’t patch the past; you write the future.
Sometimes the only way to save the spirit of a software is to let its original codebase die.
Stop clinging to the past. Whether it’s Emacs or your company’s monolithic legacy app, the math is the same. If you want 10x performance, you have to accept zero percent backward compatibility. Anything else is just coping.
FAQ
Q: But isn't backward compatibility the only reason people stay on Emacs?
A: Yes, but that's exactly why it's slow. You're choosing a 1980s ecosystem over modern performance. You can't have both.
Q: So what should I do if I'm stuck with a legacy codebase?
A: Stop trying to modernize it while maintaining 100% compatibility. Draw a line, freeze the old system, and build a new architecture in parallel.
Q: You're really saying Neo Emacs is doomed to fail?
A: Yes. Any project promising 10x performance alongside 100% legacy compatibility is either lying to you or lying to itself. The math doesn't work.