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

551–560 of 799 posts

Re: Migrating away from Rust

#551

Post by pjmlp »

palata wrote: post #519
BigJono wrote: post #495

Earlier quoted context omitted.

People have 240hz monitors these days, you have a bit over 4ms to render a frame. If that 1ms can be eliminated or amortised over a few frames it's still a big deal, and that's assuming 1ms is the worst case scenario and not the best.

What about the C# garbage collector? Is it much better? Because Unity is in C#, right?

Unity uses aginging Mono runtime, because of politics with Xamarin, before its acquisition by Microsoft, migration to .NET Core is still in process.

Additionally they have HPC#, which is a C# subset for high performance code, used by the DOTS subsystem.

Many people mistake their C# experience in Unity, with what the state of the art in .NET world is.

Read the great deep dive blog posts from Stephen Toub on Microsoft DevBlogs on each .NET Core release since version 5.0.

Re: Migrating away from Rust

#552

Post by maccard »

fc417fc802 wrote: post #372
maccard wrote: post #261

Earlier quoted context omitted.

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.

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.

Re: Migrating away from Rust

#553

Post by wolvesechoes »

christophilus wrote: post #332
janalsncm wrote: post #280

Earlier quoted context omitted.

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

I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use. I’ve got a number of vanilla Bun projects that only depend on TypeScript (and that is only a dev dependency). It’s not always possible to be so minimal, but I view every dependency as lugging around a huge lurking liability, so the benefit it brings had better far outweigh that big liability. So far, I’ve only had one painful…

"I’ve found the key to the JS ecosystem is to be very picky about what dependencies you use"

Well, I always thought it is the key in every kind of development, JS or else.

Re: Migrating away from Rust

#554

Post by pjmlp »

im3w1l wrote: post #478
noisy_boy wrote: post #398

Earlier quoted context omitted.

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.

It is ironic how Java got that stigma and other systems that are just as bad, or worse, like Objective-C, have not.

Re: Migrating away from Rust

#555

Post by amelius »

superrad wrote: post #549
amelius wrote: post #512

Earlier quoted context omitted.

> Someone else set out to do something similar in C#/Unity and had something going in less than two years. But in that case doesn't the garbage collector ruin the experience for the user? Because that's the argument I always hear in favor of Rust.

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.

Re: Migrating away from Rust

#556

Post by DarkmSparks »

Rohansi wrote: post #363
DarkmSparks wrote: post #350

The best language for game logic is lua, switching to C# probably isnt going to help any.... IMHO.

What makes Lua the best for game logic? You don't even have types to help you out with Lua.

Stuff that hooked me:

you integrate it tightly with the engine so it only does game logic, making files small and very quick and easy to read.

platform independent, no compiling, so can modify it in place on a release build of the game.

the "everything is a table" approach is very easy to concept mentally means even very inexperienced coders can get up and running quickly.

great exception handling, which makes most release time bugs very easy to diagnose and fix.

All of which means you spend far more time building game logic and much, much less time fighting the programming language.

Heres my example of a 744 flight data recorder (the rest of the 744 logic is in the containing folders)

https://github.com/mSparks43/747-400/blob/master/plugins/xtl...

All asynchronously multithreaded, 100% OS independent.

Re: Migrating away from Rust

#557

Post by tmtvl »

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?

I sometimes work on creating my own programming language (because there aren't enough of those already) and one of the things I want to do in it is 1-based indexing. Just so I can do:

  (defvar names (Vector String)
    #("Alex" "Kim" "Robin" "Sam"))
  (elt names 1)
...and get "Alex" instead of "Kim".

Re: Migrating away from Rust

#558

Post by maccard »

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.

GC isn't something to be afraid of, it's a tool like any other tool. It can be used well or poorly. The defaults are just that - defaults. If I was going to write a rhythm game in Unity, I would use some of the options to control when GC happens [0], and play around with the idea of running a GC before and after a song but having it disabled during the actual interactive part (as an example).

[0] https://docs.unity3d.com/6000.0/Documentation/Manual/perform...

Re: Migrating away from Rust

#559

Post by wolvesechoes »

schneems wrote: post #329
janalsncm wrote: post #280

Earlier quoted context omitted.

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

I wish for ecosystems that would let maintainers ship deprecations with auto-fixing lint rules.

Modelica, which is a DSL for modelling DAE systems, has a facility of automated conversions. You can provide a script that automatically modifies user's code then they upgrade to newer version of your lib, or prints the message if automatic migration is not possible.

It is very strange that more mainstream languages do not have such features (and I am not talking about 3rd party tools; in Modelica conversions are part of the language spec).

Re: Migrating away from Rust

#560

Post by pjmlp »

vips7L wrote: post #359
internetter wrote: post #290

Earlier quoted context omitted.

I'd rather write rust than java, personally

I’d rather write Java than Rust, personally

Same here, and if I get bored with Java, there is also Scala, Kotlin and Clojure to chose from.

However, I would still prefer C# or F#.

Hence why I enjoy both stacks, lots of goodies to chose from, with great tooling.

Post reply on HN