When python started incorporating asyncio my initial reaction was fairly negative. I was behaving like a grumpy graybeard programmer ("kids these days should learn how to use concurrency instead of working on a new runtime altogether!" [0]).
But after using it for a production project I have to say I'm deeply satisfied and surprised by the maturity, quality of APIs and performance in general.
I too would love to know the answer to this question. I loved Eve as a teenager / young adult. It was a brilliant burst of nerdery, and the first time I ever met someone who wrote linux kernel modules for a living.
I sometimes think about logging in (I think I ragequit likely in a pod inside a wormhole in the middle of nullsec) and then I realise that way madness (and much sunk time) lies.
Yeah if I ever have the need to occupy an inordinate number of hours of my life again I’ll log back in, the temptation to dust of the account(s) arises sometimes. Think I managed to log off in lowsec but who knows!
Spot on. Py2 was integer division, Py3 was true division. In Py2 you could get the true division with an `from __future__ import division` (Can't recall which Py2 version this became an import). Fun fact too: In Py3 you can do a // to get back to the floor division affect (e.g. 1 // 2 --> 0)
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.
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.
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.)
> 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.
It really speaks to how great the technical team can be. As crazy as it sounds Goldman Sacks and JP Morgan both maintained 2.7 Python as a core language until just a few years ago (yes, it's still used in production).
Python is used as a kind of 'visual basic' language in a lot of banks especially in front-of-house trading software, e.g murex or frontarena. Migrations between major versions of these can take years, costs 100s of millions and involve thousands of devs. Mistakes can be _expensive_.
It is kind of 'insane' but also, meh..
There's more dragons out there than we've been led to believe :}
But after using it for a production project I have to say I'm deeply satisfied and surprised by the maturity, quality of APIs and performance in general.
I was proven wrong and I'm happy about that :)
[0] Old man yell at clouds type of meme
modern Python went in a somewhat different direction with asyncio, but with tasklet and continuation it could be a much powerful combo.
I sometimes think about logging in (I think I ragequit likely in a pod inside a wormhole in the middle of nullsec) and then I realise that way madness (and much sunk time) lies.
Can someone kindly explain this?
edit: I misread it as “In Python 2 2.1/2 is 0, while in Python 3 it is 0.5”
https://github.com/carbonengine
https://fenris.com/carbon
And yeah, using a faster but safe language could help immensely.
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.
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.
It is kind of 'insane' but also, meh..
There's more dragons out there than we've been led to believe :}
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