Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

Post reply on HN
Print view View original

871–880 of 996 posts

Re: Leaving Rust gamedev after 3 years

#871

Post by vacuity »

zozbot234 wrote: post #766
jeremyjh wrote: post #650

Earlier quoted context omitted.

No, actually that was just javascript. Programming environments with threading models don't have to live that way. Separate threads can communicate through channels and do quite well for themselves. See how it works is, you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your lif…

> you do something like let data = file.read(); and the it just sits there on that line until the read is done and then your data has the actual bytes in it and you just use them and go on with your life. That's exactly how async/await works, except that it translates to state machines under the hood which gives you great performance. No need to mess with threading models, at all.

Yeah, Rust's async/await and lightweight threads are functionally very similar. Function coloring is a problem with async/awaitt, though (for now?).

Re: Leaving Rust gamedev after 3 years

#872

Post by spacechild1 »

James_K wrote: post #704

There are vanishingly few reasons why anyone wouldn't use a garbage collected language in modern software. I think a lot of the people using rust haven't realised how much this limits its utility. As a result of this, the language has been presented as much more widely applicable than it actually is.

100% agree. I am amazed how Rust is constantly touted as a general purpose programming language. In theory that's true, but in practice it only makes sense for projects where you would otherwise reach for C++.

Re: Leaving Rust gamedev after 3 years

#873

Post by vacuity »

otabdeveloper4 wrote: post #724
dboreham wrote: post #486

Earlier quoted context omitted.

Disappointing to hear this after battling the same nonsense in JS for years.

Rust is a language made and used by Dunning-Kruger people who violently react to having to learn the prior art. What did you really expect?

Rust's async/await design makes a lot of sense when you consider its primary goals (C interop, low level control, zero cost abstractions, etc.). Sure, perhaps most of us should be using a language with different constraints as opposed to Rust.

Re: Leaving Rust gamedev after 3 years

#874

Post by burntsushi »

IshKebab wrote: post #840
codethief wrote: post #814

Earlier quoted context omitted.

To be fair, many (non-game dev) Rust projects I have seen/used do provide great user experience precisely because they are laser-focused on performance and have blown existing alternatives out of the water. (Think ripgrep, fzf, etc.) Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance af…

> ripgrep, fzf I think these are great examples of where prototyping and rapid iteration are really not needed at all, and hence Rust shines here. Writing a game is completely different.

The initial version of ripgrep was absolutely a rapid prototype.

I do rapid prototyping all the time.

I'm not saying Rust is good for game dev, but the idea that Rust cannot be used for rapid prototyping in any context is a myth.

Re: Leaving Rust gamedev after 3 years

#875

Post by logicprog »

cshenton wrote: post #310

My experience is that the ecosystem is a mess, have hit winit, wgpu, and countless bevy bugs, iteration times are abysmal, documentation is nonexistent. In the time it would take me to make a game in popular Rust tooling I could build the game and engine from scratch in C and also have something that would crash less.

This, and the fact that correctness and safety and stability aren't quite as important in game development, or even game engine development, as they are in other fields where rust is applicable, is why I purposefully happily use the powerful, futureful, well established, copiously documented C or C++ libraries I need, instead of tge Rust alternatives, for almost everything. It works extremely well for me because I get to leverage the power and amazing ecosystem around things like dear imgui or sdl2 or opengl or physx, while being able to use rust, which grants me essentially a cleaner, even more modern version of C++ with all of the features I love from ocaml, in a way that restricts any weird crash or memory safety errors to the places where I interface with the lower level libraries, and sometimes not even there, depending on how high level the bindings are. It's honestly pretty nice for me.

Re: Leaving Rust gamedev after 3 years

#876

Post by metaltyphoon »

baby wrote: post #803
metaltyphoon wrote: post #551

Earlier quoted context omitted.

The do it because the first one sucked ass and the second is a huge improvement but you still have to support the old way.

mod.rs is better, change my mind

Sure, open 5 tabs named mod.rs, so which mod are you in?

Re: Leaving Rust gamedev after 3 years

#877

Post by pcwalton »

afiori wrote: post #838
pcwalton wrote: post #735

Earlier quoted context omitted.

No, the original article said that you don't get parallelism from Bevy in practice: > Unfortunately, after all the work that one has to put into ordering their systems it's not like there is going to be much left to parallelize. And in practice, what little one might gain from this will amount to parallelizing a purely data driven system that could've been done trivially with data parallelism using rayon. It's not sa…

The article is not saying that Bevy does not parallelize but that the impredictability of parallelism (both in ordering and in timing) forces the developer to add enough dependency constraints that there is not much left to parallelize.

The fact that 100% of the CPU is being used, and multiple systems are executing in parallel, shows otherwise.

Re: Leaving Rust gamedev after 3 years

#878

Post by logicprog »

Klonoar wrote: post #574
cshenton wrote: post #310

My experience is that the ecosystem is a mess, have hit winit, wgpu, and countless bevy bugs, iteration times are abysmal, documentation is nonexistent. In the time it would take me to make a game in popular Rust tooling I could build the game and engine from scratch in C and also have something that would crash less.

> documentation is nonexistent You know, I think this point is important to get right: there are generally docs, Rust does a very good job of making it easy to write docs. What doesn't always exist are guides that explain how to piece things together. Sometimes you wind up needing to really know the inner platform to piece together things in Rust, and while I love the language, this is one area where the community co…

Yeah, in general with large and Powerful libraries or frameworks, I find that pure API documentation, even if very thorough and well explained on an individual function or data structure level, is just simply not enough. I also want a reference manual type experience, where that API reference is integrated with explanations of the reasoning behind how the framework was designed, and how to actually think about using it, and examples of many common things you might want to do that integrate well together. The gold standard for this in my opinion is the opengl Red Book.

Re: Leaving Rust gamedev after 3 years

#879

Post by metaltyphoon »

sullyj3 wrote: post #602
metaltyphoon wrote: post #551

Earlier quoted context omitted.

The do it because the first one sucked ass and the second is a huge improvement but you still have to support the old way.

Which is which and why?

mod.rs came first and that made creating modules verbose as hell. Not only that but imagine having many mod.rs files open, you wouldn’t know what module you are in by just looking at the filename.

Re: Leaving Rust gamedev after 3 years

#880

Post by Capricorn2481 »

dragonwriter wrote: post #851
Capricorn2481 wrote: post #847

Earlier quoted context omitted.

A type error means a type error, and nothing more. Type errors do not mean "incorrectness." Here is an example of something you can't do in rust, but can do in other statically typed languages. ```rust struct Type1 { id: u32 } struct Type2 { id: u32 } fn main() { let obj1 = Type1 { id: 1 }; let obj2: Type2 = obj1; // compile error, Type1 is not Type2 } ``` This code works perfectly fine. These two structs have the sa…

[text deleted because it was based on a incorrecf recollection of the details of Rust features.]

This was just one example of type error != logic error.

> one is for things that are structurally identitical but semantically distinct where confusing them creates a semantic error, the other is for alternate (usually, more concise) names for an existing type

This is not always true. Sometimes there are cases where you have different type aliases and want to use them interchangeably. Now you have to refactor them to inherit from some general type that didn't exist before. I also could count on one hand the amount of times this has caught a genuine bug even with diligent domain modeling (Which I would argue is overhyped).

Post reply on HN