Live data from Hacker News

Migrating away from Rust

deadmoney.gg

611–620 of 799 posts

Re: Migrating away from Rust

#611

Earlier quoted context omitted.

If you're looking for a stable GUI toolkit, there is Slint

Unless you would like to have a tree view widget.

You can have a tree view Slint. There is one example in https://github.com/slint-ui/cargo-ui And also in https://github.com/LibrePCB/LibrePCB/pull/1504

Re: Migrating away from Rust

#612
post #457

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…

> GC pauses aren't really acceptable Java has made great progress with low-pause (~1 ms) garbage collectors like ZGC and Shenandoah since ~5 years ago.

Yes and it's impressive.

For the competitive Minecraft player, I suspect starting their VM with XX:+UnlockExperimentalVMOptions is normal.

A casual gamer is however not going to enjoy that.

Re: Migrating away from Rust

#613

Earlier quoted context omitted.

Great write-up. I do the array indexing, and get runtime errors by misindexing these more often than I'd like to admit! I also hear you on the winit/wgpu/egui breaking changes. I appreciate that the ecosystem is evolving, but keeping up is a pain. Especially when making them work together across versions.

I've always thought about this. In my mind there are two ways a language can guarantee memory safety: * Simply check all array accesses and pointer de references and panic if we are out of bounds and panic/throw an exception/etc. if we are doing something wrong. * Guarantee at compile-time that we are always accessing valid memory, to prevent even those panics. Rust makes a lot of effort to reach the second goal, but…

Rust has plenty of constructs that do runtime checks in part to get around the fact that not everything can be expressed in a manner that the borrow checker can understand at compile time. IMO Rust should treat the array/index case in the same manner as these and provide a standard interface that prevents "use after free" and so on.

Re: Migrating away from Rust

#614
Man, they seems kinda cracked. He migrated each of the subsystem experiments in about one day each having never used Unity before?

I've ported code between engines, and that makes my productivity feel very... leisurely.

Also, it's endearing that he builds things with his brother including that TF2 map that he linked from years ago.

Re: Migrating away from Rust

#615

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 can also say confidently that the #1 method to combat memory safety errors is array bounds checking. The #2 method is guaranteed initialization of variables. The #3 is stop doing pointer arithmetic (use arrays and ref's instead).

#4 safer union/enum, I do hope D gets tagged-union/pattern-matching sometimes in the future, I know about std.sumtype, but that's nowhere close to what Rust offer

Re: Migrating away from Rust

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

About 15 hours ago. I was switching between RustRover and VS Code + Rust Analyzer. Not quite mature is an understatement. All said above applies to RustRover.

Re: Migrating away from Rust

#617

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

Objects are cheaper than Arc. Otherwise using GC would suck a lot more than it does today (for certain types of data structures like trees accessed concurrently it is also a massive optimization).

Python also has incomparably worse performance than Java or C#, both of which can do many object-based optimizations and optimize away their allocation.

Re: Migrating away from Rust

#618

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

Arc is a very slow and primitive tool compared to a GC. If you are writing Arc everywhere, you would probably have better performance switching to a JVM language, C#, or Go.

Re: Migrating away from Rust

#619

More than anything else, this sounds like a good lesson in why commercial game engines have taken over most of game dev. There are so many things you have to do to make a game, but they're mostly quite common and have lots of off-the-shelf solutions. That is, any sufficiently mature indie game project will end up implementing an informally specified, ad hoc, bug-ridden implementation of Unity (... or just use the inf…

I think this has less to do with Rust and commercial game engines being better and more of a fetish that game programmers seem to have for entity component systems. One does not have to look far to see similar projects repeated in C++ years prior.

Re: Migrating away from Rust

#620

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.

I would bet that if you want to build a game engine and not the game, the game itself is probably not that compelling. Could still break out, like Minecraft, but if someone has an amazing game idea I would think they would want to ship it as fast as possible.

It is orders of magnitude easier to write an game engine for yourself than it is to create a monster like unity or unreal that needs to appeal to everyone and support every kind of game.

If we are talking 2d, it can be months to hack together a basic engine. 3d can be a bit harder but far from decades.

Thing is, if you designed your engine well and implemented great tooling, it should make it faster to implement the actual content of the game.

So upfront cost to be faster later. At least in theory. Obviously you might end up with subpar tooling that is worse than what a commercial could offers. But if you do something like an RPG with a lot of contend, every bit of extra efficiency in creating that content can help a lot.

Now, obviously from a purely commercial standpoint, not using an established engine makes nearly never sense. Super risky. Hard to hire outside talent. You are only justified when you have very, very specific needs that are hard to implement in a generic engine.

Also for us with an ADHD brain, hard things tend to be easier and easy things very hard, so yes the extra mental stimulation of writing an engine can help.

Post reply on HN