Live data from Hacker News

Migrating away from Rust

deadmoney.gg

571–580 of 799 posts

Re: Migrating away from Rust

#571
Are scripting languages not a thing in gamedev anymore?

I feel most of the things mentioned (rapid prototyping, ease of use for new programmers, modability) would be more easily accomplished by embedding a Lua interpreter in the rust project.

Glad C# is working out for them though, but if anyone else finds themselves in this situaton in Rust, or C, C++, Zig, whatever - embedding lua might be something else to consider, that requires less re-writing.

Re: Migrating away from Rust

#572

Related: just tried to switch to Rust when starting a new project. The main motivation was the combination of fearless concurrency and exhaustive error handling - things that were very painful in the more mature endeavor. Gave up after 3 days for 3 reasons: 1. Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling and a few astronomical units away from Visual Studio. Extract function…

Refactoring and IDE tooling in general are still lightyears away from JetBrains tooling

How long ago was this and did you try JetBrains RustRover? While not quite as mature as some other JetBrains tools, I've found the latest version really quite good.

Re: Migrating away from Rust

#573

Earlier quoted context omitted.

I think it's a good point and I experienced the same thing when playing with SDL3 the other day. So even established languages with new API's can be problematic. However, I had a different takeaway when playing with Rust+AI. Having a language that has strict compile-time checks gave me more confidence in the code the AI was producing. I did see Cursor get in an infinite loop where it couldn't solve a borrow checker p…

I had the same issue a few months ago when I was trying to ask LLMs about Box2D 3.0. I kept getting answers that were either for Box2D 2.x, or some horrific mashup of 2.x and 3.0. Now Box2D 3.1 has been released and there's zero chance any of the LLMs are going to emit any useful answers that integrate the newly introduced features and changes.

Almost every time I've run into similar problems with LLMs I've mostly managed to solve them by uploading the documentation to the version of the library I'm using to the LLM and instructing it do use that documentation when answering questions about the library.

Re: Migrating away from Rust

#574
post #208

I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year. When reasonable, nowadays I always use Rust instead of C++. But for the vast majority of projects, I believe that C++ is not the right language, meaning that Rust isn't, either. I feel like many people choose Rust because is sounds like it's more efficient, a bit as if people went for C++ instead of a JVM langua…

> "I really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year." I don't understand this argument, which I've also seen it used against C#, quite frequently. When a language offers new features, you're not forced to use them. You generally don't even need to learn them if you don't want. I do think some restrictions in languages can be highly beneficial, like strong typin…

Then better be quite picky of what libraries one choses, because that is the thing, while we may not use them, the libraries migth impose them on us.

Same applies having to deal with old features, replaced by modern ways, old codebases don't get magically rewritten, and someone has to understand modern and old ways.

Likewise I am not a big fan of C and Go, as visible by my comment history, yet I know them well enough, because in theory I am not forced to use them, in practice, there are business contexts where I do have to use them.

Re: Migrating away from Rust

#575
post #258
post #255

Earlier quoted context omitted.

I didn't mean that the OP should use Java. BTW the OP does not use C++, but Rust. This said, they moved to Unity, which is C#, which is garbage collected, right?

C# also has "Value Types" which can be stack allocated and passed by value. They're used extensively in game dev.

You can already get halfway there with Java, by making use of Panama, even if not exposed at language level.

And lets be real, how many devs manage to sell as many copies as Minecraft?

Too much discussion about what language to use, instead of what game to make.

Re: Migrating away from Rust

#576
post #340
post #265

Earlier quoted context omitted.

My point is that there are situations where C++ (or Rust) is required because the JVM wouldn't work, but those are niche. In my experience, most people who don't want a JVM language "because it is slow" tend to take this as a principle, and when you ask why their first answer is "because it's interpreted". I would say they are stuck in the 90s, but probably they just don't know and repeat something they have heard. S…

The JVM is excellent for throughput, once the program has warmed up, but it always has much more jitter than a more systemsy language like C++ or Rust. There are definitely use cases where you need to consistently react fast, where Java is not a good choice. It also struggles with numeric work involving large matrices, because there isn't good support for that built into the language or standard library, and there is…

Yet it made Notch rich, because he had the right idea for a game, and compeling gameplay.

Re: Migrating away from Rust

#577

Earlier quoted context omitted.

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.

Kotlin has some limited support for that:

    @Deprecated(replaceWith = "new expression")
Only works for simple cases but better than nothing. For more, there's OpenRewrite.

Re: Migrating away from Rust

#578

Earlier quoted context omitted.

Yeah this is my absolute dream language. Something that lets you prototype as easily as Python but then compile as efficiently and safely as Rust. I thought Rust might actually fit the bill here and it is quite good but it's still far from easy to prototype in - lots of sharp edges with say modifying arrays while iterating, complex types, concurrency. Maybe Rust can be something like this with enough unsafe but I hav…

You should give Julia a shot. That’s basically that. You can start with super dynamic code in a REPL and gradually hammer it into stricter and hyper efficient code. It doesn’t have a borrow checker, but it’s expressive enough that you can write something similar as a package (see BorrowChecker.jl).

Unless you would like to AOT-deploy your code, then good luck with using this 3rd party package with scarce documentation.

Or even enums, which are a joke in Julia.

Julia had so much potential, and such poor implementation.

Re: Migrating away from Rust

#579
post #257

Earlier quoted context omitted.

If you use Rust with `.clone()` and Arc/Mutex, why not just using one of the myriad of other modern and memory safe languages like Go, Scala/Kotlin/Java, C#, Swift? The whole point of Rust is to bring memory safety with zero cost abstraction . It's essentially bringing memory safety to the use-cases that require C/C++. If you don't require that, then a whole world of modern languages becomes available :-).

For me personally, doing the clone-everything style of Rust for a first pass means I still have a graceful incremental path to go pursue the harder optimizations that are possible with more thoughtful memory management. The distinction is that I can do this optimization pass continuing to work in Rust rather than considering, and probably discarding, a potential rewrite to a net-new language if I had started in somet…

Yeah only in Scala, Kotlin, F#, Standard ML, OCaml, Haskell, and all others that derive from them.

Re: Migrating away from Rust

#580
post #297

Earlier quoted context omitted.

I saw a good talk, though I don't remember the name, that went over the array-index approach. It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide.

> It correctly pointed out that by then, you're basically recreating your own pointers without any of the guarantees rust, or even C++ smart pointers, provide. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

Having gone full-in on this approach before, with some good success, it still feels wrong to me today. Contiguous storage may work for reasonable numbers of elements, but it's potentially blocking a huge contiguous chunk of address space especially for large numbers of elements.

I probably say this because I still have to main 32-bit binaries (only 2G of address space), but it can potentially be problematic even on 64-bit machines (typically 256 TB of address space), especially if the data structure should be a reusable container with unknown number of instances. If you don't know a reasonable upper bound of elements beforehand, you have to reallocate later, or drastically over-reserve from the start. The former removes a pointer stability guarantee, the later is uneconomical, it may even be uneconomical on 64-bit depending on how many instances of the data structures you plan to have. And having to reallocate when overflowing the preallocated space makes operations less deterministic with regards to execution time.

Post reply on HN