Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

521–530 of 799 posts

Re: Migrating away from Rust

#521

Post by palata »

somenameforme wrote: post #480
palata wrote: 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…

My experience with C++ is that it fundamentally "looks worse" and has worse tooling than more modern languages. And it feels like they keep adding new features that make it all even worse every year.

Sure, you don't have to use them, but you have to understand them when used in libraries you depend on. And in my experience in an environment of C++ developers, many times you end up having some colleagues who are very vocal about how you should love the language and use all the new features. Not that this wouldn't happen in Java or Kotlin, but the fact is that new features in those languages actually improve the experience with the language.

Re: Migrating away from Rust

#522

Post by palata »

elabajaba wrote: post #291
palata wrote: 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?

The core unity game engine is c++ that you can't access, but all unity games are written in c#.

And you could do that with any garbage collected language, right? You could reuse that C++ core with a JVM language.

Re: Migrating away from Rust

#523

Post by rounce »

fc417fc802 wrote: post #378
Rohansi wrote: post #358

Earlier quoted context omitted.

Most likely because they don't use Linux. Or because it's kind of a mine field to support with bugs that occur on different distros. Even Unity has their own struggles with Linux support. They're distributing their game on Steam too so Linux support is next to free via Proton.

> it's kind of a mine field to support with bugs that occur on different distros Non-issue. Pick a single blessed distro. Clearly state that it's the only configuration that you officially support. Let the community sort the rest out.

This is a terrible solution, you're better off just making it Windows only and ensuring it can be run via Proton/Wine.

Re: Migrating away from Rust

#524

Post by rcxdude »

im3w1l wrote: post #507
rcxdude wrote: post #301

Earlier quoted context omitted.

Indeed. Java is sufficiently dynamic/decompilable a game written in it can be heavily modded without adding specific support. C++ is much harder (depending on the game engine), though not impossible. If you do add modding support then everything is much better regardless of language, though (see Factorio, written in C++ and with a huge modding scene, because it was basically written with modding in mind. Lua is certa…

I actually disagree with that. Decompilation based mods can completely change anything and everything about the game. Scripting based mods can only change things within the boundaries allowed by the devs of the original game.

True, a limited modding API can be a problem. But in something like minecraft it's not a a free-for-all with mods either, it's just that the community writes their own modding API, but has to deal with breakage whenever the game updates.

Re: Migrating away from Rust

#526

Post by palata »

gerdesj wrote: post #318
palata wrote: post #279

Earlier quoted context omitted.

As I said, I use Gentoo already ;-).

Quite. I was a Gentoo user (daily driver) for around 15 years but the endless compilation cycles finally got to me. It is such a shame because as I started to depart, Gentoo really got its arse in gear with things like user patching etc and no doubt is even better. It has literally (lol) just occurred to me that some sort of dual partition thing could sort out my main issue with Gentoo. @system could have two partiti…

What about the binary packages now supported in Gentoo?

Re: Migrating away from Rust

#527

Post by mabster »

pornel wrote: post #316
mjr00 wrote: post #219

Earlier quoted context omitted.

> And yet, if making your own game engine makes it intellectually stimulating enough to actually make and ship a game, usually for near free, going 10x slower is still better than going at a speed of zero. Generally, I've seen the exact opposite. People who code their own engines tend to get sucked into the engine and forget that they're supposed to be shipping a game. (I say this as someone who has coded their own e…

Indeed there are people who want to make games, and there are people who think they want to make games, but want to make game engines (I'm speaking from experience, having both shipped games and keeping a junk drawer of unreleased game engines). Shipping a playable game involves so so many things beyond enjoyable programming bits that it's an entirely different challenge. I think it's telling that there are more Rust…

I'm in that camp. After shifting from commercial gamedev I've been itching to build something. I kept thinking "I wanna build a game" but couldn't really think what that came is. Then realised "Actually it's because I want to build an engine" haha

Re: Migrating away from Rust

#528

Post by stefanka »

__loam wrote: post #73
lynndotpy wrote: post #23

I love Rust, but this lines up with my experience roughly. Especially the rapid iteration. Tried things out with Bevy, but I went back to Godot. There are so many QoL things which would make Rust better for gamedev without revamping the language. Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev. But that's a really hard sell (and might be harder to implement…

I used to hate the language but statically typed GDscript feels like the perfect weight for indie development

It is indeed great for creating a prototype. After that, one can gradually migrate to Rust go benefit from faster execution times. The Rust bindings are in a pretty decent shape by now

https://godot-rust.github.io/

Re: Migrating away from Rust

#529

Post by carlmr »

nl wrote: post #491
Ygg2 wrote: post #428

Earlier quoted context omitted.

> fight the borrow checker I see this and I am reminded when I had to fight the 0 indexing, when I was cutting my teeth in C, for class. I wonder why no one complains about 0 indexing anymore. Isn't it weird how you have to go 0 to length - 1, and implement algorithm differently than in a math book?

The ground floor in lifts isn't "1", it is "G". Same thing.

Country dependent. Like there are 1-based indexing languages (Lua, Matlab, et al)

Re: Migrating away from Rust

#530

Post by palata »

mtndew4brkfst wrote: post #385
palata wrote: 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…

> generics, macros, sum types, pattern matching, Result/Option types. Many of these can't be found all together in a single managed/GC'd languages

What about e.g. Kotlin or Swift?

Post reply on HN