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

371–380 of 799 posts

Re: Migrating away from Rust

#371

Post by lynndotpy »

pcwalton wrote: post #245
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…

> Just a mode to automatically coerce between numeric types would make Rust so much more ergonomic for gamedev. C# is stricter about float vs. double for literals than Rust is, and the default in C# (double) is the opposite of the one you want for gamedev. That hasn't stopped Unity from gaining enormous market share. I don't think this is remotely near the top issue.

I have written a lot of C# and I would very much not want to use it for gamedev either. I can only speak for my own personal preference.

Re: Migrating away from Rust

#372

Post by fc417fc802 »

maccard wrote: post #261
nonameiguess wrote: post #127

Earlier quoted context omitted.

I'm not a game dev, but what's a straightforward way of adjusting some channel of a pixel at coordinate X,Y without indexing the underlying raster array? Iterators are fine when you want to perform some operation on every item in a collection but that is far from the only thing you ever might want to do with a collection.

Game dev here. If you’re concerned about performance the only answer to this is a pixel shader, as anything else involves either cpu based rendering or a texture copy back and forth.

A compute shader could update some subset of pixels in a texture. It's on the programmer to prevent race conditions though. However that would again involve explicit indexing.

In general I think GP is correct. There is some subset of problems that absolutely requires indexing to express efficiently.

Re: Migrating away from Rust

#373

Post by forrestthewoods »

pcwalton wrote: post #337
forrestthewoods wrote: post #16

Rust is not good for video game gameplay logic. The ownership model of Rust can not represent the vast majority of allocations. I love Rust. It’s not for shipping video games. No Tiny Glade doesn’t count. Edit: don’t know why you’re downvoting. I love Rust. I use it at my job and look for ways to use it more. I’ve also shipped a lot of games. And if you look at Steam there are simply zero Rust made games in the top 2…

> No Tiny Glade doesn’t count. > And if you look at Steam there are simply zero Rust made games in the top 2000. Zero. None nada zilch. Well, sure, if you arbitrarily exclude the popular game written in Rust, then of course there are no popular games written in Rust :) > And maybe not Switch although I’m less certain. I have talked to Nintendo SDK engineers about this and been told Rust is fine. It's not an official…

Yeah in my haste I mixed up my rants. The bane of typing at work inbetween things.

Tiny Glade is indeed a rust game. So there is one! I am not aware of a second. But it’s not really a Bevy game. It uses the ECS crate from Bevy.

Egg on my face. Regrets.

Re: Migrating away from Rust

#374

Post by molszanski »

janalsncm wrote: post #280
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.…

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

Hmmm.. strange. Don’t have issues like that. Can you show us your package json?

Re: Migrating away from Rust

#375

Post by jokethrowaway »

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.

The bar for web services is low, so pretty much anything works as long as it's easy. I wouldn't call them a success story.

When things get complex, you start missing Rust's type system and bugs creep in.

In node.js there was a notable improvement when TS became the de-facto standard and API development improved significantly (if you ignore the poor tooling, transpiling, building, TS being too slow). It's still far from perfect because TS has too many escape hatches and you can't trust TS code; with Rust, if it compiles and there are no unsafe (which is rarely a problem in web services) you get a lot of compile time guarantees for free.

Re: Migrating away from Rust

#376

Post by fc417fc802 »

cantrecallmypwd wrote: post #330
bunderbunder wrote: post #122

Earlier quoted context omitted.

An iterator works if you're sequentially visiting every item in the collection, in the order they're stored. It's terrible if you need random access, though. Concrete example: pulling a single item out of a zip file, which supports random access, is O(1). Pulling a single item out of a *.tar.gz file, which can only be accessed by iterating it, is O(N).

History lesson for the cheap seats in the back: Compressed tars are terrible for random access because the compression occurs after the concatenation and so knows nothing about inner file metadata, but it's good for streaming and backups. Uncompressed tars are much better for random access. (Tar was a used as a backup mechanism to tape (tape archive).) Zips are terrible for streaming because their metadata is stored…

> compressing files and then taring them

Just use squashfs if that is the functionality that you need.

Re: Migrating away from Rust

#377

Post by Charon77 »

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

A owns B, and B can find A

I think you should think less like Java/C# and more like database.

If you have a Comment object that has parent object, you need to store the parent as a 'reference', because you can't put the entire parent.

So I'll probably use Box here to refer to the parent

Re: Migrating away from Rust

#378

Post by fc417fc802 »

Rohansi wrote: post #358
ryao wrote: post #341

Earlier quoted context omitted.

Do you know why he supports MacOS, but not Linux?

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.

Re: Migrating away from Rust

#379

Post by _bin_ »

charlotte-fyi wrote: post #353
pcwalton wrote: post #344

Earlier quoted context omitted.

I just don't, and even less often with game logic which tends to be rather simple in terms of the data structures needed. In my experience, the ownership and borrowing rules are in no way an impediment to game development. That doesn't invalidate your experience, of course, but it doesn't match mine.

The dependency injection framework provided by Bevy also particularly elides a lot of the problems with borrow checking that users might run into and encourages writing data oriented code that generally is favorable to borrow checking anyway.

This is a valid point. I've played a little with Bevy and liked it. I have also not written a triple-A game in Rust, with any engine, but I'm extrapolating the mess that might show up once you have to start using lots of other libraries; Bevy isn't really a batteries-included engine so this probably becomes necessary. Doubly so if e.g. you generate bindings to the C++ physics library you've already licensed and work with.

These are all solvable problems, but in reality, it's very hard to write a good business case for being the one to solve them. Most of the cost accrues to you and most of the benefit to the commons. Unless a corporate actor decides to write a major new engine in Rust or use Bevy as the base for the same, or unless a whole lot of indie devs and part-time hackers arduously work all this out, it's not worth the trouble if you're approaching it from the perspective of a studio with severe limitations on both funding and time.

Re: Migrating away from Rust

#380

Post by ryao »

mawww wrote: post #369
haberman wrote: post #328

Earlier quoted context omitted.

> C++ has been faster than C for a long time. What is your basis for this claim? C and C++ are both built on essentially the same memory and execution model. There is a significant set of programs that are valid C and C++ both -- surely you're not suggesting that merely compiling them as C++ will make them faster? There's basically no performance technique available in C++ that is not also available in C. I don't thi…

C and C++ do have very different memory models, C essentially follows the "types are a way to decode memory" model while C++ has an actual object model where accessing memory using the wrong type is UB and objects have actual lifetimes. Not that this would necessarily lead to performance differences. When people claim C++ to be faster than C, that is usually understood as C++ provides tools that makes writing fast co…

Try putting objects into two linked lists in C using sys/queue.h and in C++ using the STL. Try sorting the linked lists. You will find C outperforms C++. That is because C’s data structures are intrusive, such that you do not have external nodes pointing to the objects to cause an extra random memory access. The C++ STL requires an externally allocated node that points to the object in at least one of the data structures, since only 1 container can manage the object lifetimes to be able to concatenate its node with the object as part of the allocation. If you wish to avoid having object lifetimes managed by containers, things will become even slower, because now both data structures will have an extra random memory access for every object. This is not even considering the extra allocations and deallocations needed for the external nodes.

That said, external comparators are a weakness of generic C library functions. I once manually inlined them in some performance critical code using the C preprocessor:

https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a...

Post reply on HN