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

391–400 of 799 posts

Re: Migrating away from Rust

#391

Post by [deleted] »

uecker wrote: post #386
mawww wrote: post #369

Earlier quoted context omitted.

C and C++ do have very different memory models, C essentially follows the "types are a way to decode memory" model while C++ has an actual object model where accessing memory using the wrong type is UB and objects have actual lifetimes. Not that this would necessarily lead to performance differences. When people claim C++ to be faster than C, that is usually understood as C++ provides tools that makes writing fast co…

In my experience, templates usually cause a lot of bloat that slows things down. Sure, in microbenchmarks it always looks good to specialize everything at compile time, whether this is what you want in a larger project is a different question. And then, also a C compiler can specialize a sort routine for your types just fine. It just needs to be able too look into it, i.e. it does not work for qsort from the libc. I…

[deleted]

Re: Migrating away from Rust

#392

Post by milesrout »

pcwalton wrote: post #253
sapiogram wrote: post #249

Earlier quoted context omitted.

Wonderful work! ...although the fact that a 3x speed improvement was available kind of proves their point, even if it may be slightly out of date.

Most game engines other than the latest in-house AAA engines are leaving comparable levels of performance on the table on scenes that really benefit from GPU-driven rendering (that's not to say all scenes, of course). A Google search for [Unity drawcall optimization] will show how important it is. GPU-driven rendering allows developers to avoid having to do all that optimization manually, which is a huge benefit.

[dead]

Re: Migrating away from Rust

#393

Post by milesrout »

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…

[flagged]

Re: Migrating away from Rust

#394

Post by ryao »

uecker wrote: post #390
ryao wrote: post #382

Earlier quoted context omitted.

I have used the preprocessor to avoid this sort of slowdown in the past in a binary search function: https://github.com/openzfs/zfs/commit/677c6f8457943fe5b56d7a... The performance gain comes not from eliminating the function overhead, but enabling conditional move instructions to be used in the comparator, which eliminates a pipeline hazard on each loop iteration. There is some gain from eliminating the function ove…

A comparator can be inlined just fine in C. See here where the full example is folded to a constant: https://godbolt.org/z/bnsvGjrje Does not work if the compiler can not look into the function, but the same is true in C++.

That does not show the comparator being inlined since everything was folded into a constant, although I suppose it was. Neat.

Edit: It sort of works for the bsearch() standard library function:

https://godbolt.org/z/3vEYrscof

However, it optimized the binary search into a linear search. I wanted to see it implement a binary search, so I tried with a bigger array:

https://godbolt.org/z/rjbev3xGM

Now it calls bsearch instead of inlining the comparator.

Re: Migrating away from Rust

#395

Post by bionhoward »

lynndotpy wrote: post #242
Seattle3503 wrote: post #49

Earlier quoted context omitted.

What numeric types typically need conversions?

What I mean is, I want to be able to use i32/i64/u32/u64/f32/f64s interchangeably, including (and especially!) in libraries I don't own. I'm usually working with positive values, and almost always with values within the range of integers f32 can safely represent (+- 16777216.0). I want to be able to write `draw(x, y)` instead of `draw(x as u32, y as u32)`. I want to write "3" instead of "3.0". I want to stop writing…

Sounds like a good use of Num

[1] https://docs.rs/num-traits/latest/num_traits/trait.Num.html

Re: Migrating away from Rust

#396

Post by aystatic »

Charon77 wrote: post #377
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.…

A owns B, and B can find A I think you should think less like Java/C# and more like database. If you have a Comment object that has parent object, you need to store the parent as a 'reference', because you can't put the entire parent. So I'll probably use Box here to refer to the parent

?? the whole point of Box is to be an owning reference, you can’t have multiple children refer to the same parent object if you use a Box

Re: Migrating away from Rust

#397

Post by reitzensteinm »

forrestthewoods wrote: post #373
pcwalton wrote: post #337

Earlier quoted context omitted.

> No Tiny Glade doesn’t count. > And if you look at Steam there are simply zero Rust made games in the top 2000. Zero. None nada zilch. Well, sure, if you arbitrarily exclude the popular game written in Rust, then of course there are no popular games written in Rust :) > And maybe not Switch although I’m less certain. I have talked to Nintendo SDK engineers about this and been told Rust is fine. It's not an official…

Yeah in my haste I mixed up my rants. The bane of typing at work inbetween things. Tiny Glade is indeed a rust game. So there is one! I am not aware of a second. But it’s not really a Bevy game. It uses the ECS crate from Bevy. Egg on my face. Regrets.

(the) Gnorp Apologue is written in Rust and did pretty well: https://store.steampowered.com/app/1473350/the_Gnorp_Apologu...

And for something like Gnorp, Rust is probably a decent choice.

Re: Migrating away from Rust

#398

Post by noisy_boy »

internetter wrote: post #290
lolinder wrote: post #267

Earlier quoted context omitted.

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'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 stigma of ClassFactoryGeneratorFactory sticking to it like a nasty smell but that's not how the language makes you write things. I write Java professionally and it is as readable as any other language. You can write clean, straightforward and easy to reason code without much friction. It's a great general purpose language.

Re: Migrating away from Rust

#399

Post by mwcampbell »

tptacek wrote: post #348
shmerl wrote: post #327

Earlier quoted context omitted.

Because it's a discouragement of learning based on mediocrity of AI. I find such idea perpetuating the mediocrity (not just of AI itself but of whatever it's used for). It's like imagine saying, I don't want to learn how write a good story because AI always suggests me writing a bad one anyway. May be that delivers the idea better.

It's not at all clear to me what this has to do with the practical delivery of software. In languages that LLMs handle well, with a careful user (ie, not a vibe coder; someone reading every line of output and subjecting most of it to multiple cycles of prompting) the code you end up with is basically indistinguishable from the replacement-level code of an expert in the language. It won't hit that human expert's peaks…

> Why would I valorize discarding this kind of automation? Is this just a craft vs. production thing?

The strongest reason I can think of to discard this kind of automation, and do so proudly, is that it's effectively plagiarizing from all of the experts whose code was used in the training data set without their permission.

Re: Migrating away from Rust

#400

Post by iFire »

ryao wrote: post #341
promiseofbeans wrote: post #302

One of the smartest devs I know built his game from scratch in C. Pretty complex game too - 3D open-world management game. It's now successful on steam. Thing is, he didn't make the game in C. He built his game engine in C, and the game itself in Lua. The game engine is specific to this game, but there's a very clear separation where the engine ends and the game starts. This has also enabled amazing modding capabilit…

Do you know why he supports MacOS, but not Linux?

It probably supports Linux via proton. Done. Official valve recommendation a few years ago not sure if still active.
Post reply on HN