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

291–300 of 799 posts

Re: Migrating away from Rust

#291

Post by elabajaba »

palata wrote: post #255
wffurr wrote: post #237

Earlier quoted context omitted.

>> a bit as if people went for C++ instead of a JVM language "because the JVM is slow" (spoiler: it is not) The OP is doing game development. It’s possible to write a performant game in Java but you end up fighting the garbage collector the whole way and can’t use much library code because it’s just not written for predictable performance.

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#.

Re: Migrating away from Rust

#292

Post by rcxdude »

Pet_Ant wrote: post #132
bunderbunder wrote: post #111

Earlier quoted context omitted.

I'm no game dev but I have had friends who do it professionally. Long story short, yes, it's very different in game dev. It's very common to pre-allocate space for all your working data as large statically sized arrays because dynamic allocation is bad for performance. Oftentimes the data gets organized in parallel arrays ( https://en.wikipedia.org/wiki/Parallel_array ) instead of in collections of structs. This can…

> Oftentimes the data gets organized in parallel arrays ( https://en.wikipedia.org/wiki/Parallel_array ) instead of in collections of structs. This can save a lot of memory (because the data gets packed more densely) be more cache-friendly, and makes it much easier to make efficient use of SIMD instructions. That seems like something that could very easily be turned into a compiler optimisation and enabled with somet…

It's not at all easy to implement as an optimisation, because it changes a lot of semantics, especially around references and pointers. It is something that you can e.g. implement using rust procedural macros, but it's far from transparent to switch between the two representations.

(It's also not always a win: it can work really well if you primarily operate on the 'columns', and on each column more or less once per update loop, but otherwise you can run into memory bandwidth limitations. For example, games with a lot of heavily interacting systems and an entity list that doesn't fit in cache will probably be better off with trying to load and update each entity exactly once per loop. Factorio is a good example of a game which is limited by this, though it is a bit of an outlier in terms of simulation size.)

Re: Migrating away from Rust

#293

Post by actuallyalys »

pcwalton wrote: post #243
Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

> Nobody has really pushed the performance issues. This is clearly false. The Bevy performance improvements that I and the rest of the team landed in 0.16 speak for themselves [1]: 3x faster rendering on our test scenes and excellent performance compared to other popular engines. It may be true that little work is being done on rend3, but please don't claim that there isn't work being done in other parts of the ecosy…

I read the original post as saying that no one has pushed the engine to the extent a completed AAA game would in order to uncover performance issues, not that performance is bad or that Bevy devs haven’t worked hard on it.

Re: Migrating away from Rust

#294

Post by maccard »

peterashford wrote: post #282
maccard wrote: post #273

Earlier quoted context omitted.

This is why game engines embedded scripting languages. Who gives a crap if the engine takes 12 hours to compile if 80% of the team are writing lua in a hot reload loop.

Yeah but no-one is recompiling the engine. This is just about gameplay code

Which is why I said

> this is why game engines embedded scripting languages

Re: Migrating away from Rust

#295

Post by jandrewrogers »

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…

> C instead of C++ because "it's faster" (spoiler: it probably doesn't matter for your project)

If your C is faster than your C++ then something has gone horribly wrong. C++ has been faster than C for a long time. C++ is about as fast as it gets for a systems language.

Re: Migrating away from Rust

#296

Post by echelon »

benwilber0 wrote: post #239
echelon wrote: post #223

Earlier quoted context omitted.

Rust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.

Tokio + Axum + SQLx has been a total game-changer for me for web dev. It's by far the most productive I've been with any backend web stack.

People that haven't tried this are downvoting with prejudice, but they just don't know.

Rust is an absolute gem at web backend. An absolute fucking gem.

Re: Migrating away from Rust

#297

Post by _bin_ »

Animats wrote: post #231

Another failed game project in Rust. This is sad. I've been writing a metaverse client in Rust for almost five years now, which is too long.[1] Someone else set out to do something similar in C#/Unity and had something going in less than two years. This is discouraging. Ecosystem problems: The Rust 3D game dev user base is tiny. Nobody ever wrote an AAA title in Rust. Nobody has really pushed the performance issues.…

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.

Re: Migrating away from Rust

#298

Post by echelon »

palata wrote: post #262
echelon wrote: post #223

Earlier quoted context omitted.

Rust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.

To me, web dev really sounds like the one place where everything works and it's more a question of what is in fashion. Java, Ruby, Python, PHP, C, C++, Go, Rust, Scala, Kotlin, probably even Swift? And of course NodeJS was made for that, right? I am absolutely convinced I can find success story of web backends built with all those languages.

Perhaps. But a comparable Rust backend stack produces a single binary deployable that can absorb 50,000 QPS with no latency caused by garbage collection. You get all of that for free.

The type system and package manager are a delight, and writing with sum types results in code that is measurably more defect free than languages with nulls.

Re: Migrating away from Rust

#299

Post by the__alchemist »

hu3 wrote: post #283
the__alchemist wrote: post #163

Earlier quoted context omitted.

The way I read about Bevy in online discussions obfuscates this. Someone who is new to game development could be confused into thinking Bevy is a fair competitor with the other engines you mentioned. And equate Bevy with Rust, or Bevy with Rust in game dev. I think stomping this out is critical to expectation management, and perhaps rust's future in game dev.

Not only Bevy. In this very thread someone is suggesting an even less mature Rust game engine: https://news.ycombinator.com/item?id=43825564 From my experience one has to take Rust discussions with a grain of salt because often shortcomings and disclosures are handwaved and/or ommited.

I've learned to do the same. I see this in the embedded world as well.

And within rust, I've learned to look beyond the most popular and hyped tools; they are often not the best ones.

Re: Migrating away from Rust

#300

Post by ajross »

palata wrote: post #262
echelon wrote: post #223

Earlier quoted context omitted.

Rust is actually quite suitable for a number of domains where it was never intended to excel. Writing web service backends is one domain where Rust absolutely kicks ass. I would choose Rust/(Actix or Axum) over Go or Flask any day. The database story is a little rough around the edges, but it's getting better and SQLx is good enough for me. edit: The downvoters are missing out.

To me, web dev really sounds like the one place where everything works and it's more a question of what is in fashion. Java, Ruby, Python, PHP, C, C++, Go, Rust, Scala, Kotlin, probably even Swift? And of course NodeJS was made for that, right? I am absolutely convinced I can find success story of web backends built with all those languages.

Yeah, "web services backend" really means "code exercising APIs pioneered by SunOS in 1988". It's easy to be rock solid if your only dependency is the bedrock.
Post reply on HN