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

461–470 of 799 posts

Re: Migrating away from Rust

#461

Post by talldan »

cube2222 wrote: post #76

That's an excellent article - it's great when people share not only their victories, but mistakes, and what they learned from them. That said regarding both rapid gameplay mechanic iteration and modding - would that not generally be solved via a scripting language on top of the core engine? Or is Rust + Bevy not supposed to be engine-level development, and actually supposed to solve the gameplay development use-case…

It does solve the gameplay development use case too. Bevy encourages using lots of small 'systems' to build out logic. These are functions that can spawn entities or query for entities in the game world and modify them and there's also a way to schedule when these systems should run.

I don't think Bevy has a built-in way to integrate with other languages like Godot does, it's probably too early in the project's life for that to be on the roadmap.

Re: Migrating away from Rust

#462

Post by jandrewrogers »

delusional wrote: post #451
hedora wrote: post #418

Earlier quoted context omitted.

OO (implementation inheritance) is frowned upon in modern C++. Also, all production code bases I’ve seen pass -fno-exceptions to the compiler.

Ahh yes, now we are getting somewhere. "C++ is faster because it has all these features, no not those features nobody uses those. The STL, no, you rewrite that"

The poster you are responding to is correct. Modern C++ has established idiomatic code practices that are widely used in industry. Imagining how someone could use legacy language features in the most naive possible way, contrary to industry practice, is not a good faith argument. You can do that with any programming language.

You are arguing against what the language was 30-40 years ago. The language has undergone two pretty fundamental revisions since then.

Re: Migrating away from Rust

#463

Post by ycombinatrix »

hedora wrote: post #414
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.…

Pin and unpin handle circular references, sort of.

std::rc::Weak?

Re: Migrating away from Rust

#464

Post by otikik »

Ygg2 wrote: post #428
_bin_ wrote: post #326

Earlier quoted context omitted.

But in rust you have to fight the borrow checker a lot, and sometimes concede, with complex referential stuff. I say this as someone who writes a good bit of rust and enjoys doing so.

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

Not in Lua.

Most languages have abstractions for iterating over an array so that you don’t need to use 0 or length-1 these days

Re: Migrating away from Rust

#465

Post by ogoffart »

the__alchemist wrote: post #403
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.…

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.

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

Re: Migrating away from Rust

#466

Post by ycombinatrix »

lolinder wrote: post #267
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 have a personal-use app that has a hot loop that (after extensive optimization) runs for about a minute on a low-powered VPS to compute a result. I started in Java and then optimized the heck out of it with the JVM's (and IntelliJ's) excellent profiling tools. It took one day to eliminate all excess allocations. When I was confident I couldn't optimize the algorithm any further on the JVM I realized that what I'd b…

>I realized that what I'd boiled it down to looked an awful lot like Rust code

you're no longer writing idiomatic java at this point - probably with zero object oriented programming. so might as well write it in Rust from the get-go.

Re: Migrating away from Rust

#467

Post by demaga »

pcwalton wrote: post #312
12_throw_away wrote: post #110

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…

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

But it also doesn't have even 10% of Unity features. Bevy docs themselves warn you that you are probably better off with something like Godot, at least while Bevy is still in early development.

Re: Migrating away from Rust

#468

Post by SkiFire13 »

Ygg2 wrote: post #428
_bin_ wrote: post #326

Earlier quoted context omitted.

But in rust you have to fight the borrow checker a lot, and sometimes concede, with complex referential stuff. I say this as someone who writes a good bit of rust and enjoys doing so.

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

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

Re: Migrating away from Rust

#469

Post by SkiFire13 »

hedora wrote: post #414
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.…

Pin and unpin handle circular references, sort of.

Not really, they are just tools to expose circular references (or self-references) that are *already managed by unsafe code*.

Re: Migrating away from Rust

#470

Post by WalterBright »

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 adding the `@live` annotation for a function, which turns on the borrow checker for that function. There are no syntax or semantic changes to the language, other than laying on a borrow checker.

Yes, it does data flow analysis, has semantic scopes, yup. It issues errors in the right places, although the error messages are rather basic.

In my personal coding style, I have gravitated towards following the borrow checker rules. I like it. But it doesn't work for everything.

It reminds me of OOP. OOP was sold as the answer to every programming problem. Many OOP languages appeared. But, eventually, things died down and OOP became just another tool in the toolbox. D and C++ support OOP, too.

I predict that over time the borrow checker will become just another tool in the toolbox, and it'll be used for algorithms and data structures where it makes sense, and other methods will be used where it doesn't.

I've been around to see a lot of fashions in programming, which is most likely why D is a bit of a polyglot language :-/

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

The language can nail that down for you (D does). What's left are memory allocation errors. Garbage collection fixes that.

Post reply on HN