It doesn’t sound too AI generated, and the stories flow well without much text that mean nothing. (Also, she’s a consultant, so writing this content is meant to signal some professional skill. There’s not much spam, just 1 blog article a month.)
Even if it had AI help to edit, the content still matches my lived experiences of people mgmt.
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.
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.
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.
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.
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’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.
I don’t know what datasets are available to these LLMs, but I’d imagine if there was training on CAD code, text, and images, a prompt steered towards that probably could get it pretty good.
I am not a mechanical engineer, so even prompting well with ME lingo probably will take some effort.
I would go even further and suggest that "fact/opinion" is just a framing that falls apart under scrutiny.
My framework is more or less that anything we might call a fact or an opinion is a statement, statements have varying degrees of veracity/falsifiability, and statements are essentially meaningless until they're processed through the lens of underlying beliefs/values/frameworks.
"The sky is blue" - What is the sky? What is blue? Who is viewing the sky, (someone who has sight, and isn't colorblind perhaps)? Isn't it sometimes gray? And so on.
reply