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

971–980 of 996 posts

Re: Leaving Rust gamedev after 3 years

#971

Post by hot_gril »

zozbot234 wrote: post #919
Toutouxc wrote: post #905

Earlier quoted context omitted.

AFAIK composition, in the traditional sense, means that you put your objects/concepts together from different smaller objects or concepts. Composition would be to have a struct Car that uses another struct called Engine to handle its driving needs. A car “has a” engine. A trait that implements the “this thing has an engine” behavior isn’t composition, it’s actually much closer to [multiple] inheritance (a car “is a”…

Traits do implement interface inheritance, but that doesn't have the same general drawbacks as implementation inheritance (such as the well-known "fragile base class" problem).

I don't know the terminology. I just know that Rust does whatever the alternative is to the Java way with inheritance. You don't get stuck with the classic classification problem.

Re: Leaving Rust gamedev after 3 years

#972

Post by hot_gril »

otikik wrote: post #697
jacobgorm wrote: post #414

Earlier quoted context omitted.

C++ classes with inheritance are a pretty good match for objects in a 3D (or 2D) world, which is why C++ became popular with 3D game programmers.

This is not at all my experience. What I have experienced is that C++ classes with inheritance are good at modeling objects in a game at first , when you are just starting and the hierarchy is super simple. Afterwards, it isn’t a good match. To can try to hack around this in several ways, but the short version of it is that if your game isn’t very simple you are better off starting with an Entity Component System set…

I like the Javascript way of objects just having fully mutable keys/values like dictionaries, with no inheritance or static typing.

Re: Leaving Rust gamedev after 3 years

#973

Post by hot_gril »

vacuity wrote: post #318
the__alchemist wrote: post #237

Excellent article. Rust is my favorite language for several uses, but I'm becoming less optimistic about it as a versatile language long-term. An important point regarding the article is that it mixes rust shortfalls, and shortfalls of any language other than C++ for games. I've personally used Bevy for a 3D wave function renderer, but moved away from it in favor of a custom WGPU-engine due to Bevy's complicated ECS…

I think the async Rust shortcomings are largely solvable, but I sympathize with everyone running into the numerous problems right now.

What's bad about it? Last time I used Rust was before that feature existed.

Re: Leaving Rust gamedev after 3 years

#974

Post by cornholio »

emporas wrote: post #248
cornholio wrote: post #167

Earlier quoted context omitted.

Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in. For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it. But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the ima…

If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language? I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at tha…

I would argue that OS kernel programming is actually a very specialized niche of software engineering; it demands near iron performance, fine control down bit level granularity, perfectly deterministic memory manipulation, flawless security and maintainability, and all at the same time. These are conflicting requirements and meeting them naturally spills over into decreased productivity, which is acceptable because OSes are well engineered and evolve over decades.

If C or Rust would not be available, you could still write your kernel in a well documented assembly dialect - some people still do - and then complete your OS userland in some garbage collected/interpreted/WASM abomination. But it's unlikely you could write Microsoft Word or a modern browser in assembly.

And this I think is true for games too, since, other than the performance requirement, they don't need the other features of Rust and are quite tolerant of failure. They also tend to be unwieldy beasts hard to design cleanly because the internal world simulation would become ever more complex, imposing weird data access patterns etc. If your online play code suddenly requires access to some internal "tank fuel" state, in C you would just pass the pointer and pray to the goods of rock and roll it's still valid at access time; a garbage collected language would at least give you that; but in Rust, you are looking at a complete refactoring of the entire "tank" module to make the new access pattern fit the ownership model.

As the post explains, this will kill quick iteration, which I think is a very general need of most programmers.

Re: Leaving Rust gamedev after 3 years

#975

Post by Ygg2 »

Capricorn2481 wrote: post #865
Ygg2 wrote: post #199

Earlier quoted context omitted.

Disclaimer: I'm aware you guys are working on relaxing orphan rules, and I wish you the best of luck. But as an outsider, orphan rule doesn't seem to be going anywhere soon. And if the original poster had said that I would be ok. Instead what they said is: > It's a great example of something I'd call "muh safety", desire for perfection and complete avoidance of all problems at all costs, even if it means significantl…

> This implies the writer didn't assume what happens if you "turn-off" orphan rules It implies that the writer would prefer using a different language, not that Rust would be better if it was all the same but with the parts he doesn't like taken out

> It implies that the writer would prefer using a different language

That's not what they wrote.

> There are mostly valid reasons for wanting the orphan rule for things such as libraries uploaded to crates.io, and I am willing to concede that crates published there should obey this.

> But I have a very hard time caring about this rule for applications and libraries developed in end products. I'm explicitly not saying binary crates, because most bigger projects will be composed of more than one crate, and many will be more than one workspace.

It talks explicitly about Rust. In hindsight, the author might have been better suited by another language, but expecting Rust to suddenly become another language is weird.

Re: Leaving Rust gamedev after 3 years

#976

Post by ShinTakuya »

deepsun wrote: post #665

> being unable to just move on for now and solve my problem and fix it later Same thing about Golang "unused variable" and "unused import". So many times I just exploring a lib and trying things out with no intention to leave it as is, but no, Go forces to "write good code".

I mean, I'm no fan of Golang (I actually kinda hate it), but this is easily solved with a blank identifier (underscore `_`) or by commenting the line. Both of which makes it blindingly obvious when doing code review.

Golang falls in the camp of enabling fast iteration while also enforcing some sane basics. Letting off an unused variable/import with a warning is a recipe for insanity, anyone who has opened a badly maintained Java codebase will tell you this.

Re: Leaving Rust gamedev after 3 years

#977

Post by masfoobar »

I am happy to be honest that I have not spent much time of rust, other than browsing sample code and reading about user experience, the borrow checker, etc.

For me, I could not see myself using rust especially for game development. Some of the points raised are my concerns, especially wanting to chuck something together (to improve later) only to fight the compiler, etc.

I would be interested to know what language they choose moving forward. It seems the contenders are likely to be:-

C - because, you can,

C++ - ditto,

D - I think it is largely ignored, and there is the betterC flag

Zig - Seems interesting,

Odin - Also interesting

Anyway... going to enjoy reading the comments, now.

Re: Leaving Rust gamedev after 3 years

#978

Post by ghosty141 »

jstimpfle wrote: post #869
jandrewrogers wrote: post #861

Earlier quoted context omitted.

C++17/20 are light-years beyond C++11 in terms of ergonomics and usability. Metaprogramming in C++11 is unrecognizable from C++20 things have improved so much. I hated C++ before C++11 but now C++11 feels quite legacy compared to even C++17. The ability to write almost anything, like a logging library, without C macros is a huge improvement for maintainability and robustness. Most of the features in modern C++ are de…

Heh, mentioning metaprogramming and logging is not exactly how you convince anybody of superior ergonomics and usability.

Metaprogramming is required to get typesafe easy to use code. The problem of most template code is that the implementation gets horrendously complicated but for the user it can create A LOT of comfort. At work for example, I wrote a function that calls an rpc-method and it has a few neat features like:

An rpc call with a result looks like this:

call(, , [](Result r) {});

vs one which returns void:

call(, , []() {});

It's neat that the callback reflects that, but this wouldn't be possible without some compiletime magic.

Re: Leaving Rust gamedev after 3 years

#979

Post by ghosty141 »

flohofwoe wrote: post #804
Arech wrote: post #798

Earlier quoted context omitted.

There a whole bunch of features and fixes that each new version of the standard proclaimed, which severely affected usability, expressibility and convenience of the language. Describing many of them could easily take an hour. I'm sorry, I can only highlight a few of my particular favourites that I regularly use and let you study the rest changes. https://en.cppreference.com/w/cpp/14 - fixed constexpr, which in C++11…

Ok, I'll give you fold expressions and structured bindings as actually important language updates. The rest are mostly just tweaks that plug feature gaps which shouldn't have existed in the first place when the basic feature was introduced in C++11 or earlier. IMHO by far most things which the C++ committee accepts as stdlib updates should actually be language changes (like for instance std::tuple, std::variant or st…

He missed concepts and modules which are also c++20 features, modules are just not properly supported (yet). Concepts are a massive QoL feature and modules might help with compile times.

> IMHO by far most things which the C++ committee accepts as stdlib updates should actually be language changes

From my experience thats not how the c++ committee works. They generally decompose requested features into the smallest building blocks and just include those in the language and let the rest be handled by the stdlib.

The thing that makes C++ unreadable in my opinion is template code and the fact that the namespace system sucks and just leads to unreadably long names (std::chrono::duration_cast(.....)).

Re: Leaving Rust gamedev after 3 years

#980

Post by vacuity »

hot_gril wrote: post #973
vacuity wrote: post #318

Earlier quoted context omitted.

I think the async Rust shortcomings are largely solvable, but I sympathize with everyone running into the numerous problems right now.

What's bad about it? Last time I used Rust was before that feature existed.

High cognitive complexity, incongruity with other language features, interface virality (the bemoaned "function coloring problem"). I think much of the downsides are more a result of slow moving language design than intractable fixtures.
Post reply on HN