Disagree. While it's easier to 1-shot more things now, when there's more complicated interaction of components, a good plan from plan mode can make the project a "looks good, go" and run overnight thing vs. "steering" needed.
How many thousands of dollars are you burning a month on “looks good, go” and then *letting it run overnight*?? I spend enough money on 8 human, interruptible and human-thinking hours with paused hours.
I can’t imagine how high that number would go if I got rid of the collaborative style and also the “please don’t run scary commands on random directories without permission” mode.
Write a good high level plan with functional and non-functional requirements and it works out costing less, works more efficiently, and no surprises.
It’s like this: If you know the right words to say to the LLM, you’ll likely get back the “right words” also. And the more right words up front, the less steering you need to do.
(Having 20yrs of experience writing these user stories and designs help, my “unfair” advantage)
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.
reply