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.
Switching away from Python would not fix this. EVE Online runs its world without instancing or shards, meaning you cannot scale out the simulation when a single zone is overcrowded. Pretty much every other online game avoids this problem by making it impossible to have thousands of players in the same area because networking every players' actions to thousands of players is always problematic
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.
Oh my yes. EVE Online can experience issues when a conflict in a solar system exceeds a certain number of players. Each system in EVE is a monolithic process, so, if a conflict gets out of hand, things get slow.
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.)
My understanding is that the performance issues it has are more big-O issues of the problem space than issues that would meaningfully be resolved by the multiplicative speedup of moving to a more efficient language (the point at which they start to bite would shift a bit, though.)
> Every character, every skill point, every asset in every hangar, every ISK in every wallet was written in Python 2 code, and all of it must read back under Python 3 exactly as it was.
This task would be even more challenging under such a dramatic rewrite.
Rust is a tool that allows one to build cars for humans to drive, in order to avoid certain accidents. If you try to put your dog in the driver’s seat of a Rust-powered car, Rust will stop you and ask you to produce proof that the dog is a qualified human driver.
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.
I for one don't care about memory safety. Rust makes it easier to compose software by expressing everything in your function/module signature. This is what OOP aimed to do, but was quite prescriptive (a datatype often isn't the natural unit of encapsulation). It maximizes local reasoning, so you can make changes to a large codebase with less understanding of uses elsewhere, and reuse functionality in new ways without changes.
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
before rust, if you wanted to use a "fast" programming language you had to use C or C++, which are fraught with sharp edges. Rust gives you all the performance benefits of a compiled language, with barely any sharp edges.
Using python for a purpose like this is extremely strange -- it clearly is just technology debt they've been carrying around from a silly decision over a decade ago -- so someone mentioned a contemporary, more acceptable alternative. I don't really see why this threatens some people, much less the incredibly stupid "religious" nonsense.
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.
This is a weird conversation. Python was a strange choice back then, but is now probably the most popular programming language in existence. If anything the choice of Python (and C++) was remarkable foresight / luck.
If Eve were green-fielded today, there is a 0% chance they would choose Python anywhere in the service layer for an online game. Zero chance.
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.
Python is very strange programming language for a MMORPG. I'd imagine they would write it in C++ or something. They don't quite explain what they use it for.
And yeah, using a faster but safe language could help immensely.
Python is just a part of the tech stack, there's also a lot of C/C++ code. How much Python vs C/C++ is hard to say from the outside though, but the parts that have been open-sourced are pretty much all C/C++:
Some parts are in C++ and they even made it open source recently:
https://github.com/carbonengine
https://fenris.com/carbon
Does the game have performance issues? I don't see the need to rewrite unless there is a problem with it
> Does the game have performance issues?
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.
Switching away from Python would not fix this. EVE Online runs its world without instancing or shards, meaning you cannot scale out the simulation when a single zone is overcrowded. Pretty much every other online game avoids this problem by making it impossible to have thousands of players in the same area because networking every players' actions to thousands of players is always problematic
But one of EVE’s biggest selling points is specifically the 1000s of players in one area.
Yes, I am saying time dilation is a necessary compromise because of that.
I have to remember the "time dilation" excuse for the next production issue lol
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?
Universe must run on same software... since stuff since to slow down near black holes too
They have to slow down the game tick-rate to accommodate, something they call "Time Dilation": https://wiki.eveuniversity.org/Time_dilation
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.
Oh my yes. EVE Online can experience issues when a conflict in a solar system exceeds a certain number of players. Each system in EVE is a monolithic process, so, if a conflict gets out of hand, things get slow.
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.)
My understanding is that the performance issues it has are more big-O issues of the problem space than issues that would meaningfully be resolved by the multiplicative speedup of moving to a more efficient language (the point at which they start to bite would shift a bit, though.)
> Every character, every skill point, every asset in every hangar, every ISK in every wallet was written in Python 2 code, and all of it must read back under Python 3 exactly as it was.
This task would be even more challenging under such a dramatic rewrite.
Python 3 will likely be faster by itself.
[flagged]
The Jehovah's Witnesses of programming
Can someone explain to my non-programmer self what the deal is with Rust?
Even not being in the tech space, I have long picked up on this quasi-religous aura around it.
Rust is a tool that allows one to build cars for humans to drive, in order to avoid certain accidents. If you try to put your dog in the driver’s seat of a Rust-powered car, Rust will stop you and ask you to produce proof that the dog is a qualified human driver.
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.
> cars are to be driven by qualified humans only
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.
I for one don't care about memory safety. Rust makes it easier to compose software by expressing everything in your function/module signature. This is what OOP aimed to do, but was quite prescriptive (a datatype often isn't the natural unit of encapsulation). It maximizes local reasoning, so you can make changes to a large codebase with less understanding of uses elsewhere, and reuse functionality in new ways without changes.
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
before rust, if you wanted to use a "fast" programming language you had to use C or C++, which are fraught with sharp edges. Rust gives you all the performance benefits of a compiled language, with barely any sharp edges.
Using python for a purpose like this is extremely strange -- it clearly is just technology debt they've been carrying around from a silly decision over a decade ago -- so someone mentioned a contemporary, more acceptable alternative. I don't really see why this threatens some people, much less the incredibly stupid "religious" nonsense.
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.
> it clearly is just technology debt they've been carrying around from a silly decision over a decade ago
Almost three decades ago—development started in 1999 and the game was released in 2003.
This is a weird conversation. Python was a strange choice back then, but is now probably the most popular programming language in existence. If anything the choice of Python (and C++) was remarkable foresight / luck.
If Eve were green-fielded today, there is a 0% chance they would choose Python anywhere in the service layer for an online game. Zero chance.
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.
i-use-arch-btw
That's totally ok. "It works on my machine" with no info on what that machine looks like, is much worse
skill issue
Python is very strange programming language for a MMORPG. I'd imagine they would write it in C++ or something. They don't quite explain what they use it for.
And yeah, using a faster but safe language could help immensely.
Python is just a part of the tech stack, there's also a lot of C/C++ code. How much Python vs C/C++ is hard to say from the outside though, but the parts that have been open-sourced are pretty much all C/C++:
https://github.com/carbonengine
[flagged]
Will you poor contributors ever shut up?
Very aggressive. "Will you $FAVORITE_LANG people ever shut up?"