Live data from Hacker News

Leaving Rust gamedev after 3 years

loglog.games

571–580 of 996 posts

Re: Leaving Rust gamedev after 3 years

#571
post #394

Earlier quoted context omitted.

Many tried c++ in early 90s, but wasnt it too slow/memory intensive? You had to implement lots of inline c/assembly to have a bit of performance. Nowadays everything is heavily optimized, but back then not.

If you’re referring to game dev specifically, there have been (and continue to be) concerns around the weight of C++ exception handling, which is deeply-embedded in the STL. This proliferated in libraries like the EASTL. C++ itself however is intended to have as many zero-cost abstractions as possible/reasonable. The cost of exception handling is less of a concern these days though.

Exception handling is easy enough to disable. Luckily, or C would probably still be the game developers go to.

Re: Leaving Rust gamedev after 3 years

#572
post #459

Earlier quoted context omitted.

Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually. https://en.wikipedia.org/wiki/Crash-only_software https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...

A crash of an actor in BEAM is incomparable to a crash of a video game.

Is it? Is there no reasonable case where you have a subsystem in a game crash, then restart itself? Unless I'm mistaken, I've experienced this myself in video games more than once. Anything beats a full crash with a pointless error message.

Re: Leaving Rust gamedev after 3 years

#573

Starting by saying I fundamentally agree wrt iteration speed. This is ultimately why [C/C++]/Lua was such a thing for a while, and it seems quite plausible that you could benefit from a core engine in rust bound to a scripting language. But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature o…

Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language…

> I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.

That's why, the first time I saw Bevy and Amathyst, I had an immediate "they're doing it wront$ reaction. IMHO, to be a true game engine in the modern sense, instead of merely a game framework, your engine needs to be a precompiled, standalone executable in a systems language that picks up, loads, and executes game scripts, data files, and assets that are totally separate from the engine itself and written in higher level languages. You don't want to be writing everything in a rigid systems language and especially don't want to have to compile your game logic and your engine together and then link them as if the engine were a library. That's why I'm (very slowly) feeling out what a proper game engine in Rust might be like with https://github.com/alexispurslane/embryo-engine. It will take me some time, since I have to learn real time computer graphics and a lot about game engines, but I've got the books, I've made a lot of progress in learning them, and the engine design and architecture is coming together very well in my big black notebook, so if you're interested, give the repo a watch ;)

I'm debating between embeddable common lisp (to satisfy my hacker impulses) or C# for the scripting language. I have figured out, I think, how I'll embed C# in Rust down to some pretty detailed steps, involving a two stage process, but .NET is so heavy I'm worried if it'll be worth it. I'd love input!

Re: Leaving Rust gamedev after 3 years

#574

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

Re: Leaving Rust gamedev after 3 years

#575
post #507

Earlier quoted context omitted.

> The main reason is that you can't ship that Rust code on PS5 in a sensible manner. Really - why’s that?

Sony requires that you use their tooling, which you can only get under NDA.

If there was significant pressure from developers Sony would allow Rust. I doubt there is any.

Re: Leaving Rust gamedev after 3 years

#576

I also had the same bad experience with Rust outside of Gamedev. Probably a lot of other people too, but people don't talk about it much, because the Rust community is the most religious programming language community I've ever seen in my life. Before Rust, the Scala community was also pretty bizarre (Java too for a while), but nothing was on Rust's level. The worst part about Rust isn't technical, it's the crazy com…

I mean, your comment is actually contributing to the problem. You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that.

It's fanning the flames and just doesn't really help.

Re: Leaving Rust gamedev after 3 years

#577

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.

Yeah, OOP makes sense for games. The language will matter a bit for which one takes off, but anything will work given enough support. Like, Python doesn't inherently make a lot of sense for data processing or AI, but it's good enough.

Python makes sense because of accessibility and general comfort for relatively small code bases with big data sets.

Those data scientists at least from my experience are more into math/business than interested in most efficient programming.

Or at least that was the situation at first and it sticked.

Re: Leaving Rust gamedev after 3 years

#578

Allan Blomquist's tooling demo they mention is incredible, go watch it: https://www.youtube.com/watch?v=72y2EC5fkcE Really sells the value of having a tight developer feedback loop: it shows hot reloading for code and graphics, a reversible debugger, live profiling with flame graphs, a data inspector with data breakpoints, time travel inspection with a scrub bar, session sharing and replay with the same scrub bar and…

Yeah, this is the bit that stood out for me, too. Does anyone knowledgeable here have a sense for whether there are any insurmountable roadblocks to bringing hot reload to Godot?

Godot 4 already has hot reloading.

Re: Leaving Rust gamedev after 3 years

#579
post #566

Earlier quoted context omitted.

Had to look up ECS to be honest, and it's pretty much what I already do in general dev. I don't care to classify things, I care what I can do with something. Which is Rust's model.

Sorry I got lost in that sentence. What is Rust's model?

Rust has traits on structs instead of using inheritance. Aka composition.

Re: Leaving Rust gamedev after 3 years

#580

Earlier quoted context omitted.

There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing. The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest. [0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large…

Let me introduce you to `-fdefer-type-errors` in GHC Haskell: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe...

That's pretty cool! Wouldn't have guessed that Haskell would has had this feature since 2015.
Post reply on HN