> 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.
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
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.)
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++:
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 :}
This is fascinating, thanks for the link. I love to learn about big systems that are developed in the same room where the problem they're solving lives, so to speak.
Too few of these are revealed to the rest of us, as the piece notes. It's a shame, there's lots to learn there. Instead most will be lost to the mists of time, and some dumpster diving digital archaeologist will have to get lucky for us to hear about them.
I have run into other large (well known) financial companies on 2.x as well. They were using our old unsupported SDK and some long planned and communicated service API change broke them. They could not update to any recent SDK. I did gently point out their python version was 10+ years out of date.
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)
PEP 238 lays out the story if anyone is curious. Well into the Python 3 transition, I still had a habit of multiplying the denominator by 1.0 to ensure it was a float.
> modern Python went in a somewhat different direction with asyncio,
I'll say more, it went the wrong direction. I see async thing in Python as a step backwards. For some reason Guido heard of Twisted and deferreds and somehow got influenced by it, and here we are with "async def" and "await" sprinkled all over the place.
I mean, we had stackless, eventlet, gevent, we could have started something from that. We even had the example of Erlang and with a much better concurrency pattern. Go went with goroutines and channels and in retrospect made the right choice, not as good as Erlang/Elixir imo but still better than sprinkling async everywhere.
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!
If you ever do wish to go back, request Signal Cartel to rescue you. Rescuing people from wormholes is exactly what they do. I was with them for years.
Not a player myself, but I recall there were some articles about a player organization that helped people who were stranded, or something along these lines. It sounded quite wholesome and fun.
I started more than 15 years ago and recently got back into it. I would say that game has stagnated a lot more, character numbers may seem like it isn't that low but in reality most people who play it has around 5 accounts which they multibox with. So number of actual people who play it went really down. It is looking bleak for the future, and i can confidently say that it is all CCP's fault (called Fenris Creations now). They started aiming for short term gains and they probably realized themselves long ago it won't last so they started investing in other IP's but they were all mega failures so far.
Keep an eye out for EVE vanguard, an Eve-related extraction FPS. It might scratch the itch for many who perhaps enjoyed the universe but don't want to (or can't) spend the enormous time to ramp up again.
My comment included EVE Vanguard. I tried it. As someone who played FPS all his life starting from Quake 1 and Wolfenstein 3D, and all the AA and AAA FPS that came afterwards, EVE Vanguard feels like a money laundering scheme at this point. Nowadays a single person with access to he SOTA AI models and engines like Unreal, can make a much better and polished game in less time. It's gonna be an absolute DoA. The only reasons CCP is still able to operate is the addicts (mostly old men with no other hobby) that has spent thousands upon thousands on their accounts can't let go.
I’ve played off and on for years - even multiple accounts, lots of hours, and a very helpful org, there was too much to do, and I quickly felt overwhelmed. I just can’t imagine them getting many new players, but it’s clear the game is 20+ years of upgrades and content.
The thing I miss the most about Eve Online is the immersive free market economy. I long for a true, in-depth economic MMO more than the space veneer around the order book. Buy low, sell high. Specialize in industry, trading, transportation. Add a little bit of light PvP to inject chaos and it's more fun than playing the stock market.
(I am actually designing such a game, but I'm open to suggestions)
My main activity in the game was stealing loot from under carebears' noses to sell for profit. A true rat scouring the battlefields for scraps. That must say a lot about me.
The economy in new world was fun and different when it launched. Buy and sell orders and separate auction houses between cities. There was many unexpected ways to make money with trading and crafting. The only major source of gold was a single main story quest early in the game, so if you weren't careful you would go broke and struggle.
The crafting systems were so trivial that didn't make the economy game of New World particularly engaging. One core mechanic I seek is the division of labor; if everyone can and is expected to become a master in every skill, there is no niche to corner, and trivialises the experience.
There are very few games (actually, only EVE comes to mind with its skill system) that require you to specialize if you want to compete over everybody else.
Dune: Awakening tried this. Was kind of fun while it lasted (and before the bug stole all of my resources I was trying to sell. The support was zero help on getting that resolved. That killed it for me immediately).
I don't like how EVE is run, and the pay-to-win mechanics added over the years to entice the whales.
I'm looking at the problem with the eyes of a prospective game dev, and saying that there should be more games focused on free market economy, which is often just a half-arsed mechanic on the side, not the core game.
I played EVE for many years, and I really hated the addition of skill injectors. When I first started playing, the only way to get your skills up was to spend the time training them. Now it just takes real money cash.
There's a legitimate argument for some P2W mechanics, though. To keep a game going you need new players, and if you're looking at losing every PvP encounter for years as you skill up your character you probably won't stay.
The thing with EVE is that, even with all the ISK and SP in the game, you can't just buy your way to a win - you can't buy skill. You can have perfect skills and buy the best ship and modules and all that, but if you don't know how to fly, you're going to lose your ship immediately and it won't even be a fight.
That, coupled with your second paragraph (the new player experience being so rough) and I've never really been too upset about the stuff CCP sells.
Problem with EVE is that they did not have a solution for the problem of resource accumulation from the start. It was mitigated to some degree by great wars of old, and then wormhole space, but then they a) sold out to koreans with their interesting approach to MMOs, and b) merged the chinese shard. This did not help at all.
Now.. Py3 is nice, and I guess that move signals that at last they pay attention to engine instead of bolting on useless p2w crap, but to really revive eve this is not it.
In my opinion (joined EVE in 2006, still own a JF and few carriers there), what is needed is a massive sink for all the accumulated assets. Idk, expand the universe like tenfold. Then it would be fun again.
edit: also ditch all the nullsec sov mechanics and revert to something resembling the pre-TCU state. I can't for the life of me think of a reason why they chose to die on the hill of not adding more systems.
While I broadly disagree with much of this, I have been advocating for years that expanding the universe would indeed dispel much of the issues with the power disparity between groups, as well as encourage more involved logistics and stuff like that.
I enjoyed off world trading company but it’s a very different kind of economic simulator- much shorter and gamified loops - which isn’t a criticism, just not exactly the same itch.
I started in 2004 and played on and off until 2015 with a quick stint in 2020.
It was amazing in the early days, it felt like nothing else. I had a background in Ultima Online and Dark Age of Camelot. I liked PVP and I wanted full loot drop on kill.
EVE online has many times been referred to as the spiritual successor of UO, what made it really special however was the one server architecture (until China shard).
My name was Dieter Rams—I ganked, scammed and griefed. I probably made a lot of people quit the game; this was the appeal. I wanted to play a game where I could be the villain (successfully).
Over the years it lost its soul as the internet grew, social media became more prevalent and information disseminated more rapidly (watch madseasonshow on youtube for a great coverage on this topic) around the optimal ways to play etc.
All MMOs suffered for this, you could look everything up before doing anything and so the sense of discovery and adventure was lost. The frontier was no longer undiscovered, and once pay to win came into play everything came off the rails.
This is when I quit for real or as the EVE players say "won EVE".
A better comedic version of the video is this one by Honorable Third Party (typical EVE humor):
This is REALLY EvE
https://youtu.be/LmS9vcVNr5A
I came back in 2020 for a month but it's like that saying you can't step into the same river twice. I was older but the game had also changed so much. Other players were pressuring me to multibox (play multiple accounts), it felt terrible.
I knew a guy who played 30 characters at the same time, his setup was a technical marvel but it made me sad what gaming had become. There was a similar issue with buffbots in Dark Age of Camelot.
The fact that EVE needs a new player tutorial says everything you need to know about the state of the game (and gaming in general). Everyone needs a lot of handholding these days, in 2004 you were just thrown into the universe with nothing but the chat and other players to help you out.
Figuring things out was part of the game.
There were no YouTube guides, no tutorial and no real money to make things easier. The playing field was equal no matter who you were.
The magic was lost because of money, it's always the money in the end.
I miss the insane adrenaline rush when getting into small fights (1v1, 1v2, etc.). You go so long doing doing whatever it is you're doing- PvE, hacking data sites, transporting stuff- it's all a bit mundane.
But nothing raised my heart rate like getting into a fight. 30 seconds of terror. I would have to take a break after these, win or lose, until my HR returned to normal and my hands stopped shaking.
Same here. The thing that makes it so high stakes in EVE is you don't just respawn with all your stuff. It might have taken a couple weeks (or longer) for you to grind up the money for the ship you're using, and if the fight doesn't go well it's gone.
When I started playing (2011-ish), I suppose I was the counterparty to your playstyle. But that was the appeal: Being in actual danger and at risk for loss. Even stuff like moving an industrial with goods from highsec to npc null to sell at a markup was an exhilerating adventure. And if there is risk, sometimes you lose.
I don't know how many people felt like I did, versus how many ragequit the game.
After some years I became a wormholer though, and finally a permanent -10 lowsec pirate in the end. It's been a decade since I quit now.
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.
For me it is quite bad, but just we are now used to it.
In the same way that when you ask Windows users about all the bugs and problems they have with their system, they often say that they don't have any.
And ten seconds later, will click "ok" on a random crash popup they didn't even read the content of.
Not the OP but my impression with asyncio was that it's great for the uses case it was built for (hence the "no problems") but if you need to do something a bit different it can become an annoyance (hence the "unexpected bugs").
I see it for a specialized solution for a specific class of problems, which can lead to surprises if your problem evolves. There are always trade-offs to be made (performance, flexibility, hardware cost, etc.), asyncio just has different characteristics than the alternatives. Maybe since a upper bound of concurrent users it is always a great (the best?) solution, someone with more experience along all the design and requirements space could comment.
There are things that are quite good for other than what they were designed for.
I find it interesting when someone mentions that X is bad for something it was not designed for, as much as I am interested when someone mentions that X is good even if it was not designed for something.
There is a huge difference between "X is good/bad at something it was not designed for" and "X is bad because it's bad at something it was not designed for".
First for the syntax it is quite not good, you have to use await and async keywords plus async everything version of all that you are using.
You can't mix non async code with async. And you can easily do in some way and block your application without you noticing.
And in the end, async is not even really async, just cooperative execution.
I'm a big fan of Python since very low version. And I don't have too much difficulty using async/asyncio now I'm used to it, but in all honesty I don't think that it is really great in the grand scheme of things.
Yeah I dunno, the first time I tried to use asyncio I ran into a bug that nobody knew how to solve. Can't remember what it was but generally if I use something for the first time and immediately hit a bug... Yeah I'm not using that thing if I can help it.
I mean that's true for Python in general, but sadly these days you can't really avoid it.
asyncio has always looked interesting, but whenever I have run into a problem which could use asyncio I have always gone with multiprocesses instead. I am not sure if async would makes my code easier for others to read and debug, and none of my problems seems to be of the kind where process overhead would make a noticeable difference in performance.
Did you find readability to be improved by going async?
Lets make a specific example. You have an APIs to services with data that you want to synchronize to a cache in a local database. The providers allows a maximum of 1-3 connections for each api.
You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider.
Which will be easier to debug, and which design is easier for the next developer to read, understand and modify? Performance wise the wast majority for both designs will be on waiting at the initial connections to the apis and time spent fetching objects.
And if the there were 3000, 30000 or 300000 providers the problem would be different. The example I gave was one where I have considered async but went with multiprocessing, which is also why I asked the parent commenter above if they found any direct benefit to readability or debugging when going async.
You could generate tests that give you 100% line coverage but the real test is if the thousands of subscribing players have the same experience which doesn't have the same agent friendly testing feedback loop
> Some of you may remember upgrading to Stackless Python 2.5 in 2007, then to Stackless Python 2.7 in 2010. That was the last time EVE changed its Python version.
Yikes.
But, ignoring this - I think when the "scripting" languages can bridge the speed penalty towards C, even if not reaching it for many reasons, then they become real contenders here.
I wish there was a test instance people were allowed to play around on. I never did it but for a while the game client wasn't really secure & you could just talk to the python repl basically, and script the game. I think that would be an incredible experience all unto its own, to teach coding, to be an interesting experience. Feels like with Carbon being open source, there's need for just a little more to get back around to that halycon moment.
Not sure if it's worth it. I don't see them complaining about speed and they use specific python dependencies then they would need to translate that to rust also.
Rewriting it in Rust isn't automatically faster and more importantly Eve's gameplay is constantly being iterated on and Rust has proven to be bad for that.
Moreover, most of Eve's bottleneck isn't single server speed, it's mostly network IO and database queries and latency. The big TiDi skirnishes in particular are slow due to this.
Could I see your sources for how Rust is slower for iterations?
I've been working in JS, Python, C#, TS, and F# for about ten years. I'd guess F# and TS are tied for me for prototyping speed. I have to wonder how much the "common knowledge" that strongly typed languages are slower for prototyping is driven by unfamiliarity with the tool.
Depends on what you do. For prototyping GUIs without well-defined framerwork, Rust is terrible. TypeScript wins completely. For back-ends, not so clear, since it is easier to write the intent there and even prototype must be somewhat correct, and TS is not as explicit as Rust is.
I didn't say anything about strongly typed languages being bad for prototyping. I specifically said Rust is bad for prototyping speed. Lots of high profile cases of Rust being abandoned (Witchbrook comes to mind as an example).
I say this as a big fan of Rust. I use it for CLIs, microservice development and more. The borrow checker, traits, enums, etc. are amazing for maintainability, reliability and speed. Fast iteration where you'll want to completely redo a system at the drop of a hat? Rust is a royal pain in the behind.
Largely, proponents of Rust who push it for game development have their minds stuck in the solutions space and forget about the problem space. The fact that Rust was even proposed to fix Eve here is a huge example of solutions focused thinking (bad bad bad) because is misunderstands that Eve was never bottlenecked on processing speed of its physics or business logic.
On the iteration: I'm not sure that's the case anymore? Sure new content is added but it's largely within existing systems. The game is closing in on 25 years old at this point.
I've no insight into what specifically their bottleneck is. The database doesn't sound like it'd be a factor, though, since the slowdowns are isolated to single nodes handling the area with players and don't effect others.
>The database doesn't sound like it'd be a factor, since the slowdowns are isolated to single nodes handling the area with players
It doesn't sound like it because you haven't been paying attention. By and large, the TiDi slowdowns are because of network IO (i.e. too many players connected to a single node), but the database causes stutters when large numbers of ships are exploded at once.
DB needs to update inventory, skills, implants, and killboards which requires multiple round trips. Moreover, while these round trips to the DB happen, the core processing threads often end up yielding waiting for the SQL Server instance to respond.
But again, I only mentioned it as part of the problem. The core of the issue is definitely Network IO. Someone activates a module or weapon, you need to send that info to 1-10k players as a packet update. That's the source of delays, not processing speed. Rust won't magically speed that up, the network layer is already written in C.
I’ve been doing this on a large system I’m building. Anything that takes longer than an hour to run, processes a high rate of events (maybe >5/s averaged over a day) or has downstream gpu waiting for it.
Python + tests cross compiled to rust has huge benefits for memory footprint and secondly cpu.
It’s allowing me to achieve wonders on a small amount of hardware.
the eve client is pretty incredibly well made these days. but when the server side solution was to exponentially reduce time , i think they fundamentally lost somewhere else. maybe something good will come out of (some?) that server c++ code being released as well
172 comments
[ 1.6 ms ] story [ 62.2 ms ] threadThis task would be even more challenging under such a dramatic rewrite.
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.
https://github.com/carbonengine
https://fenris.com/carbon
When asked what the problem is with some specific software they’ll answer “It’s not written in Rust”
It’s literally a denominational tech cult - their holy trinity is Crypto, AI, and Rust.
It’s bonkers talking to these cultists.
And yeah, using a faster but safe language could help immensely.
https://github.com/carbonengine
It is kind of 'insane' but also, meh..
There's more dragons out there than we've been led to believe :}
Too few of these are revealed to the rest of us, as the piece notes. It's a shame, there's lots to learn there. Instead most will be lost to the mists of time, and some dumpster diving digital archaeologist will have to get lucky for us to hear about them.
Can someone kindly explain this?
https://peps.python.org/pep-0238/
modern Python went in a somewhat different direction with asyncio, but with tasklet and continuation it could be a much powerful combo.
I'll say more, it went the wrong direction. I see async thing in Python as a step backwards. For some reason Guido heard of Twisted and deferreds and somehow got influenced by it, and here we are with "async def" and "await" sprinkled all over the place.
I mean, we had stackless, eventlet, gevent, we could have started something from that. We even had the example of Erlang and with a much better concurrency pattern. Go went with goroutines and channels and in retrospect made the right choice, not as good as Erlang/Elixir imo but still better than sprinkling async everywhere.
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.
Basically the community ks people checking it out, bots, and the terminally addicted multi boxing 30 accounts.
(I am actually designing such a game, but I'm open to suggestions)
My main activity in the game was stealing loot from under carebears' noses to sell for profit. A true rat scouring the battlefields for scraps. That must say a lot about me.
There are very few games (actually, only EVE comes to mind with its skill system) that require you to specialize if you want to compete over everybody else.
> Buy low, sell high. Specialize in industry, trading, transportation
I did all of this, quite profitably and for quite a long time, in EVE?
I'm looking at the problem with the eyes of a prospective game dev, and saying that there should be more games focused on free market economy, which is often just a half-arsed mechanic on the side, not the core game.
There's a legitimate argument for some P2W mechanics, though. To keep a game going you need new players, and if you're looking at losing every PvP encounter for years as you skill up your character you probably won't stay.
That, coupled with your second paragraph (the new player experience being so rough) and I've never really been too upset about the stuff CCP sells.
Now.. Py3 is nice, and I guess that move signals that at last they pay attention to engine instead of bolting on useless p2w crap, but to really revive eve this is not it.
In my opinion (joined EVE in 2006, still own a JF and few carriers there), what is needed is a massive sink for all the accumulated assets. Idk, expand the universe like tenfold. Then it would be fun again.
edit: also ditch all the nullsec sov mechanics and revert to something resembling the pre-TCU state. I can't for the life of me think of a reason why they chose to die on the hill of not adding more systems.
Maybe one day :)
Can you please tell of what you disagree with?
Schwab?
https://www.protondb.com/app/2938800
(Yes I have a 23 year old toon)
It was amazing in the early days, it felt like nothing else. I had a background in Ultima Online and Dark Age of Camelot. I liked PVP and I wanted full loot drop on kill.
EVE online has many times been referred to as the spiritual successor of UO, what made it really special however was the one server architecture (until China shard).
My name was Dieter Rams—I ganked, scammed and griefed. I probably made a lot of people quit the game; this was the appeal. I wanted to play a game where I could be the villain (successfully).
This was the original trailer for the game, in my opinion the true vision: https://youtu.be/GwpgXFA3UQk
Over the years it lost its soul as the internet grew, social media became more prevalent and information disseminated more rapidly (watch madseasonshow on youtube for a great coverage on this topic) around the optimal ways to play etc.
All MMOs suffered for this, you could look everything up before doing anything and so the sense of discovery and adventure was lost. The frontier was no longer undiscovered, and once pay to win came into play everything came off the rails.
The developer made this video in 2014:
This is EVE - Uncensored https://youtu.be/AdfFnTt2UT0
This is when I quit for real or as the EVE players say "won EVE".
A better comedic version of the video is this one by Honorable Third Party (typical EVE humor): This is REALLY EvE https://youtu.be/LmS9vcVNr5A
I came back in 2020 for a month but it's like that saying you can't step into the same river twice. I was older but the game had also changed so much. Other players were pressuring me to multibox (play multiple accounts), it felt terrible.
I knew a guy who played 30 characters at the same time, his setup was a technical marvel but it made me sad what gaming had become. There was a similar issue with buffbots in Dark Age of Camelot.
The fact that EVE needs a new player tutorial says everything you need to know about the state of the game (and gaming in general). Everyone needs a lot of handholding these days, in 2004 you were just thrown into the universe with nothing but the chat and other players to help you out.
Figuring things out was part of the game.
There were no YouTube guides, no tutorial and no real money to make things easier. The playing field was equal no matter who you were.
The magic was lost because of money, it's always the money in the end.
But nothing raised my heart rate like getting into a fight. 30 seconds of terror. I would have to take a break after these, win or lose, until my HR returned to normal and my hands stopped shaking.
I've never experienced that in any other game.
I don't know how many people felt like I did, versus how many ragequit the game.
After some years I became a wormholer though, and finally a permanent -10 lowsec pirate in the end. It's been a decade since I quit now.
Learned a lot from that game.
My greatest lesson from EVE is that most people are really really dumb.
The same people also vote and drive, it's a miracle we still exist.
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
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
I see it for a specialized solution for a specific class of problems, which can lead to surprises if your problem evolves. There are always trade-offs to be made (performance, flexibility, hardware cost, etc.), asyncio just has different characteristics than the alternatives. Maybe since a upper bound of concurrent users it is always a great (the best?) solution, someone with more experience along all the design and requirements space could comment.
I find it interesting when someone mentions that X is bad for something it was not designed for, as much as I am interested when someone mentions that X is good even if it was not designed for something.
You can't mix non async code with async. And you can easily do in some way and block your application without you noticing.
And in the end, async is not even really async, just cooperative execution.
I'm a big fan of Python since very low version. And I don't have too much difficulty using async/asyncio now I'm used to it, but in all honesty I don't think that it is really great in the grand scheme of things.
I mean that's true for Python in general, but sadly these days you can't really avoid it.
Did you find readability to be improved by going async?
You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider.
Which will be easier to debug, and which design is easier for the next developer to read, understand and modify? Performance wise the wast majority for both designs will be on waiting at the initial connections to the apis and time spent fetching objects.
> Very carefully, and in multiple stages.
That answer is so 3 months ago
Is there anything similarly great around now?
Say "stackless tasklet" five times fast.
More Music, Less Nessman
https://www.wherethemusicwent.com/stream
https://www.iheart.com/live/wkrp-10724/
downvoters can take the red pill
pythonista here
zen is the only religion that can laugh at itself
i wonder when the migration was started and whether it made sense to not migrate it to another framework instead.
[1] https://github.com/stackless-dev/stackless
https://en.wikipedia.org/wiki/Allegiance_%28video_game%29
Yikes.
But, ignoring this - I think when the "scripting" languages can bridge the speed penalty towards C, even if not reaching it for many reasons, then they become real contenders here.
This hit me. Not sure when this was used and was deprecated.
I wish there was a test instance people were allowed to play around on. I never did it but for a while the game client wasn't really secure & you could just talk to the python repl basically, and script the game. I think that would be an incredible experience all unto its own, to teach coding, to be an interesting experience. Feels like with Carbon being open source, there's need for just a little more to get back around to that halycon moment.
If the outcome or outputs / test cases are known, AI is great at language translations.
The server isn't fast enough and it ends up slowing the game down to 10% speed as a workaround.
Moreover, most of Eve's bottleneck isn't single server speed, it's mostly network IO and database queries and latency. The big TiDi skirnishes in particular are slow due to this.
I've been working in JS, Python, C#, TS, and F# for about ten years. I'd guess F# and TS are tied for me for prototyping speed. I have to wonder how much the "common knowledge" that strongly typed languages are slower for prototyping is driven by unfamiliarity with the tool.
There have been lots of posts here about Rust being not the nirvana it's claimed to be for such projects. This one comes to mind https://loglog.games/blog/leaving-rust-gamedev/
I say this as a big fan of Rust. I use it for CLIs, microservice development and more. The borrow checker, traits, enums, etc. are amazing for maintainability, reliability and speed. Fast iteration where you'll want to completely redo a system at the drop of a hat? Rust is a royal pain in the behind.
Largely, proponents of Rust who push it for game development have their minds stuck in the solutions space and forget about the problem space. The fact that Rust was even proposed to fix Eve here is a huge example of solutions focused thinking (bad bad bad) because is misunderstands that Eve was never bottlenecked on processing speed of its physics or business logic.
I've no insight into what specifically their bottleneck is. The database doesn't sound like it'd be a factor, though, since the slowdowns are isolated to single nodes handling the area with players and don't effect others.
It doesn't sound like it because you haven't been paying attention. By and large, the TiDi slowdowns are because of network IO (i.e. too many players connected to a single node), but the database causes stutters when large numbers of ships are exploded at once.
DB needs to update inventory, skills, implants, and killboards which requires multiple round trips. Moreover, while these round trips to the DB happen, the core processing threads often end up yielding waiting for the SQL Server instance to respond.
But again, I only mentioned it as part of the problem. The core of the issue is definitely Network IO. Someone activates a module or weapon, you need to send that info to 1-10k players as a packet update. That's the source of delays, not processing speed. Rust won't magically speed that up, the network layer is already written in C.
Half joking.
Stackless tasklets --> Goroutines.
Python + tests cross compiled to rust has huge benefits for memory footprint and secondly cpu.
It’s allowing me to achieve wonders on a small amount of hardware.