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

601–610 of 799 posts

Re: Migrating away from Rust

#601

Post by pjmlp »

pornel wrote: post #416
maccard wrote: post #272

Earlier quoted context omitted.

Disagree on both points. Anyone who has shipped a game in unity has dealt with object pooling, flipping to structs instead of classes, string interpolation, and replacing idiomatic APIs with out parameters of reused collections. Similarly, anyone who has shipped a game in unreal will know that memory issues are absolutely rampant during development. But, the cure rust presents to solve these for games is worse than t…

I'm shocked that Beat Saber is written in C# & Unity. That's probably the most timing sensitive game in the world, and they've somehow pulled it off.

Devil May Cry for the Playstation 5 is written in C#, but not Unity.

Capcom has their own fork of .NET.

"RE:2023 C# 8.0 / .NET Support for Game Code, and the Future"

https://www.youtube.com/watch?v=tDUY90yIC7U

Re: Migrating away from Rust

#602

Post by Ygg2 »

scott_w wrote: post #545
Ygg2 wrote: post #494

Earlier quoted context omitted.

I don't think so. One based numbering is barring few particular (spoken) languages the default. You have to had to change your counting strategies when going from regular world to 0 based indices. Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride. My point is you forgot how hard it is because it's now muscle memory (if you need a recap of the difficulty learn a program wi…

> Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride. Given most languages since at least C have 0-based indexing... I would think most engineers picked it up early? I recall reading The C Programming Language 20 years ago, reading the reason and just following what it says. I don't think it's as complex as the descriptions people put forward of "fighting the borrow checke…

> Given most languages since at least C have 0-based indexing.

As I mentioned I started Basic on C64, and schools curriculum was in Pascal. I didn't learn about C until I got to college.

> One is "mentally add/subtract 1" and another is "gain a deep understanding of how memory management works in Rust."

In practice they are, you start writing code. At first you trip on your feet, read stuff carefully, then try again until you succeed.

Then one day, you wake up and realize I know 0 indices and/or borrow checker. You don't know how you know, you just know you don't make those mistakes anymore.

Re: Migrating away from Rust

#603

Post by 63stack »

ben-schaaf wrote: post #304
WD-42 wrote: post #250

Earlier quoted context omitted.

This argument goes only so far. Would you consider querying a database hard? Most developers would say no. But it’s actually a pretty hard problem, if you want to do it safely. In rust, that difficultly leaks into the crates. I have a project that uses diesel and to make even a single composable query is a tangle of uppercase Type soup. This just isn’t a problem in other languages I’ve used, which granted aren’t as s…

Building a proper ORM is hard. Querying a database is not. See the postgres crate for an example. Querying a database while ensuring type safety is harder, but you still don't need an OEM for that. See sqlx.

Sqlx is completely lacking in the query composability department, and leads to a very large amount of boilerplate.

You can derive FromRow for your structs to cut down the boilerplate, but if you need to join two tables that happen to have a column with the same name it stops working, unless you remember to _always_ alias one of the columns to the same name, every time you query that table from anywhere (even when the duplicate column names would not be present). If a table gets added later that happens to share a column name with another table? Hope you don't ever have to join those two together.

Doing something CRUD-y like "change ordering based on a parameter" is not supported, and you have to fall back to sprintf("%s ORDER BY %s %s") style concatenation.

Gets even worse if you have to parameterize WHERE clauses.

Re: Migrating away from Rust

#604

Post by tremon »

Ygg2 wrote: post #490
SkiFire13 wrote: post #468

Earlier quoted context omitted.

Because the math books are the ones being weird. https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

Maths books aren't being weird. They are counting in a way most people learn to count. One apple, two apples, three apples. You don't start zeroth apple, one apple, two apples, then respond the set of apple contains three apples.

But computers are not actually counting array elements, it's more accurate to compare array indexing with distance measurement. The pointer (memory address) puts you at the start of the array, so the first element is right there under your feet (i.e. index 0). The other elements are found by measuring how far away from the start they are:

  element_position = start + index*element_size

Re: Migrating away from Rust

#605

Post by whytevuhuni »

amelius wrote: post #555
superrad wrote: post #549

Earlier quoted context omitted.

For a while now Unity has an incremental garbage collector where you pay a small amount of time per frame instead of introducing large pauses every time the GC kicks in. Even without the incremental GC it's manageable and it's just part of optimising the game. It depends on the game but you can often get down to 0 allocations per frame by making using of pooling and no alloc APIs in the engine. You also have the tool…

At this point I really wonder why anyone would use Rust for anything other than low-level system tools/libraries or kernel development ... Anything with a graphical shell is probably better written in a GC'd language, but I'd love to hear some counter-arguments.

It depends on the kind of game you’re making.

If it’s a really logic-intensive game like Factorio (C++), or RollerCoaster Tycoon (Assembly), then I don’t think you can get away with something like Unity.

For simpler things that have a lot of content, I don’t think you can get away with Rust, until its ecosystem grows to match the usual game engines of today.

Re: Migrating away from Rust

#606

Post by WhyNotHugo »

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

> > The lower levels are buggy and have a lot of churn > > The stack I use is Rend3/Egui/Winit/Wgpu/Vulkan

The same is true if you try to make GUI applications in Rust. All the toolkits have lots of quirky bugs and broken features.

The barrier to contributing to toolkits is usually also pretty high too: most of them focus on supporting a variety of open source and proprietary platforms. If you want to improve on something which requires some API change, you need to understand the details of all the other platforms — you can't just make a change for a single one.

Ultimately, cross-platform toolkits always offer a lowest common denominator (or "the worst of all worlds"), so I think that this common focus in the Rust ecosystem of "make everything run everywhere" ends up being a burden for the ecosystem.

> > Back-references are difficult > > A owns B, and B can find A, is a frequently needed pattern, and one that's hard to do in Rust. It can be done with Rc and Arc, but it's a bit unwieldy to set up and adds run-time overhead.

When I code Rust, I'm always hesitant to use an Arc because it adds an overhead. But if I then go and code in Python, Java or C#, pretty much all objects have the overhead of an Arc. It's just implicit so we forget about it.

We really need to be more liberal in our usage of Arc and stop seeing it as "it has overhead". Any higher level language has the same overhead, it's just not declared explicitly.

Re: Migrating away from Rust

#607

Post by fc417fc802 »

maccard wrote: post #552
fc417fc802 wrote: post #372

Earlier quoted context omitted.

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.

You're right - I should have just said "shader" and left it at that. > There is some subset of problems that absolutely requires indexing to express efficiently. Sure. But it's almost certainly quicker to run a shader over them, and ignore the values you don't want to operate on than it is to copy the data back, modify it in a safe bounds checked array in rust, and then copy it again.

> run a shader over them, and ignore the values you don't want to operate on

Use a compute shader. Run only as many invocations as you care about. Use explicit indexing in the shader to fetch and store.

Obviously that doesn't make sense if you're targeting 90% of the slots in the array. But if you're only targeting 10% or if the offsets aren't a monotonic sequence it will probably be more efficient - and it involves explicit indexing.

Re: Migrating away from Rust

#608

Post by whstl »

WalterBright wrote: post #470
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 caveat my remarks with although I've have studed the Rust specification, I have not written a line of Rust code. I was quite intrigued with the borrow checker, and set about learning about it. While D cannot be retrofitted with a borrow checker, it can be enhanced with it. A borrow checker has nothing tying it to the Rust syntax, so it should work. So I implemented a borrow checker for D, and it is enabled by addin…

I agree with you.

For me Rust was amazing for writing things like concurrency code. But it slowed me down significantly in tasks I would do in, say, C# or even C++. It feels like the perfect language for game engines, compilers, low-level libraries... but I wasn't too happy writing more complex game code in it using Bevy.

And you make a good point, it's the same for OOP, which is amazing for e.g. writing plugins but when shoehorned into things it's not good at, it also kills my joy.

Re: Migrating away from Rust

#609

Post by willtemperley »

pjmlp wrote: post #547
willtemperley wrote: post #431

Earlier quoted context omitted.

Java is incredibly productive - it's fast and has the best tooling out there IMO. Unfortunately it's not a good gaming language. GC pauses aren't really acceptable (which C# also suffers from) and GPU support is limited. Miguel de Icaza probably has more experience than anyone building game engines on GC platforms and is very vocally moving toward reference counted languages [1] [1] https://www.youtube.com/watch?v=tz…

He would vouch as great as he might be, he has a bias, and Mono GC was never a great implementation. Also here is how great his new Swift love performs in reality against modern tracing GCs, https://github.com/ixy-languages/ixy-languages

Interesting link, but that's a nearly 7 year old version of Swift (4.2) running on Linux.

I wonder how the performance would be with Swift 6.1 which has improved support for Linux.

Re: Migrating away from Rust

#610

Post by [deleted] »

ninkendo wrote: post #435
ChadNauseam wrote: post #99

Earlier quoted context omitted.

I wish more languages would lean into having a really permissive compiler that emits a lot of warnings. I have CI so I'm never going to actually merge anything that makes warnings. But when testing, just let me do whatever I want! GHC has an -fdefer-type-errors option that lets you compile and run this code: a :: Int a = 'a' main = print "b" Which obviously doesn't typecheck since 'a' is not an Int, but will run just…

> I wish more languages would lean into having a really permissive compiler that emits a lot of warnings. I have CI so I'm never going to actually merge anything that makes warnings. But when testing, just let me do whatever I want! I’d go even further and say I wish my whole development stack had a switch I can use to say “I’m not done iterating on this idea yet, cool it with the warnings.” Unused imports, I’m looki…

[deleted]
Post reply on HN