Posted by TylerJaacks 4 days ago
googled it so this becomes a PSA: https://simonwillison.net/2026/Aug/25/eve-online-move-to-pyt...
so it's neither, it's their own: https://github.com/carbonengine/scheduler
so that's interesting
Yes, it has had huge concurrency issues for the entirety of its life. Their solution to large fights has historically been "let us know in advance pls", plus "move systems to beefier hw nodes" and "tidi" which stands for time dilation, where the "tick rate" of the whole server goes down and a fight takes 10-20-100x longer than it should.
It's an amazing concept of a game, but software wise it has been a mess since forever.
edit: maybe the path to unlimited processing speed is to send a data center through space near speed of light. That's how it works right?
How much of that is down to processing time is unclear, but I think it's fair to say there is scope for improved performance.
Secondary to that, if you have general performance improvements then you can afford to run a smaller server cluster or smaller servers, reducing costs.
This is referred to as Time Dilation (TiDi) in EVE -- https://wiki.eveuniversity.org/Time_dilation -- it's an interesting engineering rathole, Fenris f/k/a CCP has been pretty open about their stack, and the challenges that have built up.
Anything that speeds up EVE lets more players cram in without experiencing TiDi, and this might let the devs escape Stackless Python, which is another interesting engineer rathole. (It's ratholes all the way down, and this is the one that got EVE on my radar, and has kept it there.)
This task would be even more challenging under such a dramatic rewrite.
Even not being in the tech space, I have long picked up on this quasi-religous aura around it.
The world is a pretty big place, so of course there are people who sometimes put their dog in the driver’s seat. Sometimes by accident, sometimes out of necessity, and sometimes because they think it’s mighty fun. Since Rust is strict about who or what gets to drive the car, these people build their cars using other languages.
Some Rust-heads, however, are pretty adamant that cars are to be driven by qualified humans only, and therefore keep nagging everyone about how all cars should be built with Rust.
As a Rust programmer I'm fine with cars driven by dogs, I just want that to be clearly acknowledged as unsafe, and if that car is be driven in public roads, I would also like a safety comment stating all the precautions taken to make that safe for others, preferably reviewed by the police as well.
C#, Go, Swift are (mostly) memory safe, but I don't think they provide this level of modularity or broader reliability. Expressive interfaces/contracts are useful for all sorts of things, you can use them for memory management but for me that's almost a by-product. I certainly don't consider it a restriction on the kinds of program you can write
Rust has lots of inertia behind it, a fantastic core library, fantastic concurrency and scalability and excellent LLM support. If someone were greenfield building a service like this today, instead of being bound by poor decisions in the past, had infinite knowledge of every toolset and language and option, there is a very good chance they would settle on Rust. They might not, but it's definitely a finalist. So not remotely surprising someone would mention it.
That this caused someone to flip out is hilarious though.
Almost three decades ago—development started in 1999 and the game was released in 2003.
Python is a fantastic "glue" programming language. A duct-tape language. It's awesome for little scripts, or for gluing together some AI scripts, where you're basically atomically gluing a series of calls to giant native C/C++ libraries like pytorch that are then doing a series of calls to giant native C/C++ libraries like CUDA. Where the overhead of python is negligible compared to some heavy lifting being done by a better language/system.
The simple fact that we're talking about a service that was stuck on Python 2 two decades after it was replaced, half a decade after it was fully deprecated, reveals this to be 100% just debt. The fact that they talk about millions of lines of Python code, and that Python 3 represents a big speedup for their operations, again betrays it to be nothing but debt. They have Python code in the critical flow, not just as a light glue over intensive code, and they have almost certainly spent untold dollars on extra hardware, delivering a worse experience for their users, because they had a "python enthusiast" in a critical position decades ago.
And yeah, using a faster but safe language could help immensely.