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

471–480 of 799 posts

Re: Migrating away from Rust

#471

Post by Blackcatmaxy »

frontfor wrote: post #454
bmitc wrote: post #213

Earlier quoted context omitted.

I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.

I don’t want to use a language with unknown ecosystem. If I need a library to do X, I’m confident I can find it for Go, Java, Python etc. But I don’t know about F#. I also don’t want to use a language with questionable hireability.

Haven't used F# too much myself but one of the strong points is because it shares the CLR with C# you can use any of the many packages meant for C# and it'll work because of the shared runtime.

Re: Migrating away from Rust

#472

Post by uecker »

queuebert wrote: post #429
forrestthewoods wrote: post #115

Earlier quoted context omitted.

Gameplay code is a big bag of mutable data that lives for relatively unknown amounts of time. This is the antithesis of Rust. The Unity GameObject/Component model is pretty good. It’s very simple. And clearly very successful. This architecture can not be represented in Rust. There are a dozen ECS crates but no one has replicated the worlds most popular gameplay system architecture. Because they can’t.

> ... big bag of mutable data that lives for relatively unknown amounts of time. This is the antithesis of Rust. I'm sorry, but I still don't understand. There are myriad heap collections and even fancy stuff like Rc > or RefCell . What am I missing here? Is it as simple as global void pointers in C? No, but it's way safer.

Somehow I doubt Unity uses global void pointers in C. Not that one would have to use global void pointers when using C.

Re: Migrating away from Rust

#473

Post by neonsunset »

yyyk wrote: post #452
eftychis wrote: post #157

This comment might not be liked by the usual commenters in these threads, but I think it is worth stressing: First: I have experience with Bevy and other game engine frameworks; including Unreal. And I consider myself a seasoned Rust, C etc developer. I could sympathize with what was stated by the author. I think the issue here is (mainly) Bevy. It is just not even close to the standard yet (if ever). It is hard for…

>if you are a C# developer, honestly you don't care about low level code, or not having a garbage collector. You can go low level in C#**, just like Rust can avoid the borrow checker. It's just not a good tradeoff for most code in most games. ** value types/unsafe/pointers/stackalloc etc.

Structs in C# or F# are not low-level per se, they simply are a choice and used frequently in gamedev. So is stackalloc because using it is just 'var things = (stackalloc Thing[5])' where the type of `things` is Span. The keyword is a bit niche but it's very normal to see it in code that cares about avoiding allocations.

Note that going more hands-on with these is not the same as violating memory safety - C# even has ref and byreflike struct lifetime analysis specifically to ensure this not an issue (https://em-tg.github.io/csborrow/).

Re: Migrating away from Rust

#474

Post by otikik »

mjr00 wrote: post #219
doctorpangloss wrote: post #136

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.

> 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. Generally, I've seen the exact opposite. People who code their own engines tend to get sucked into the engine and forget that they're supposed to be shipping a game. (I say this as someone who has coded their own e…

This person develops

Re: Migrating away from Rust

#475

Post by serbuvlad »

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.

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, since it gives you integers and arrays, it makes the problem fundamentally insoluble.

The memory it wants so hard to regulate access to is just an array, and a pointer is just an index.

Re: Migrating away from Rust

#476

Post by WalterBright »

Ygg2 wrote: post #439
tacitusarc wrote: post #432

Earlier quoted context omitted.

I believe it’s a practicality to simplify pointer arithmetic

Yes but why does no one talk here about fighting the 0 indices. Or how they are switching to Lua, because 0 indices are hard? Am I the only person that remembers how hard it was to wrap your head around numbers starting at 0, rather than 1?

> 0 indices are hard?

I started out with BASIC and Fortran, which use 1 based indices. Going to C was a small bump in the road getting used to that, and then it's Fortran which is the oddball.

Re: Migrating away from Rust

#477

Post by WalterBright »

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…

The advantage C has over C++ is it won't let you use templates.

Re: Migrating away from Rust

#478

Post by im3w1l »

noisy_boy wrote: post #398
internetter wrote: post #290

Earlier quoted context omitted.

I'd rather write rust than java, personally

If I have all the time in the world, sure. When I'm racing against a deadline, I don't want to wrestle with the borrow checker too. Sure, it's objections help with the long term quality of the code and reduce bugs but that's hard to justify to a manager/process driven by Agile and Sprints. Quite possible that an experienced Rust dev can be very productive but there aren't tons of those going around. Java has the stig…

I have found that the ClassFactoryGeneratorFactories sneak up on you. Even if you don't want to the ecosystem slowly but surely nudges you that way.

Re: Migrating away from Rust

#479

Post by Animats »

ycombinatrix wrote: post #460
josephg wrote: post #430

Earlier quoted context omitted.

> 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. I've gone back and forth on this, myself. I wrote a custom b-tree implementation in rust for a project I've been working on. I use my own implementation because I need it to be an order-statistic tree, and I need internal run length encoding. The original vers…

Could std::rc::Weak solve the backreference problem?

Weak is very helpful in preventing ownership loops which prevent deallocation. Weak plus RefCell lets you do back pointers cleanly. You call ".borrow()" to get access to the data protected by a RefCell. The run-time borrow panics if someone else is using the data item. This prevents two mutable pointers to the same data, which Rust requires.

Static analysis could potentially check for those potential panics at compile time. If that was implemented, the run time check, and the potential for a panic, would go away. It's not hard to check, provided that all borrows have limited scope. You just have to determine, conservatively, that no two borrow scopes for the same thing overlap.

If you had that check, it would be possible to have something that behaves like RefCell, but is checked entirely at compile time. Then you know you're free of potential double-borrow panics.

I started a discussion on this on a Rust forum. A problem is that you have to perform that check after template expansion, and the Rust compiler is not set up to do global analysis after template expansion. This idea needs further development.

This check belongs to the same set of checks which prevent deadlocking a mutex against itself. There's been some work on Rust static deadlock analysis, but it's still a research topic.

Re: Migrating away from Rust

#480

Post by somenameforme »

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 really like Rust as a replacement for C++, especially given that C++ seems to become crazier every year."

I don't understand this argument, which I've also seen it used against C#, quite frequently. When a language offers new features, you're not forced to use them. You generally don't even need to learn them if you don't want. I do think some restrictions in languages can be highly beneficial, like strong typing, but the difference is that in a weakly typed language that 'feature' is forced upon you, whereas random new feature in C++ or C# is near to always backwards compatible and opt-in only.

For instance, to take a dated example - consider move semantics in C++. If you never used it anywhere at all, you'd have 0 problems. But once you do, you get lots of neat things for free. And for these sort of features, I see no reason to ever oppose their endless introduction unless such starts to imperil the integrity/performance of the compiler, but that clearly is not happening.

Post reply on HN