[rootw0rm]

I've been learning Rust lately. Working on a little game. First few thousand lines of code in I was having some doubt. After being a little frustrated with borrows and lifetimes and with my strong tendency to prematurely optimize all the things I was soooo tempted to just switch to C and have full unfettered access to my sweet sweet pointers.

I'm glad I haven't switched though. Performance (which I'm measuring a ton of) is great. The situations where I wanted to bow out and take the 'easier' path were mostly bad design choices on my part and I think partly just laziness.

Rust forces me to think a little bit more, and I've really enjoyed learning about how/why the various language features were designed. Now I'm one of those damned Rust evangelists that have been annoying me for years =)

[weinzierl]

"Rust forces me to think a little bit more [..]"

My reaction to that has always been that it forces us to think about the things we would have had to think anyways if we wanted to create reasonably reliable and secure software. So in the end if saves work, even if it doesn't appear like that at first.

[flohofwoe]

The other side of the medal (especially for game development), is that in the higher level parts of game code you need quick turnaround times for experimentation and tweaking, and most of that code won't even make it into the final product (so all the upfront time you spent thinking about proper architecture and ownership details is wasted up there).

The traditional solution is to have different languages for different code layers (e.g. a compiled language for the low level parts, and an interpreted scripting language for the high level parts), but this comes with its own set of problems.

[peterashford]

This is my main reason for not thinking that rust is good for games - a quick prototype / test / reject approach is important

[Brian_K_White]

Don't games work by an engine which doesn't have a lot of rando changing user facing features, that could be rust. And the engine provides a dsl that is the high level user facing rapid change thing?

[flohofwoe]

Yeah, Rust may be a good choice for a game engine, but at the same time not a good choice for the actual game code.

[Brian_K_White]

To counter myself, I could also easily imagine that game engines are also full of dirty hacks to get things that the front end people want done, now, by hook or by crook. Ie, if a nice sane interface doesn't exist, and woukd take more than 11 minutes to add the right way, then just butcher in any kind of tight coupling and to hell with worrying about it breaking for the next game.

[Someone]

> The traditional solution is to have different languages for different code layers

Isn’t the rust solution to wrap Q&D/experimental code in “unsafe {}”? I think that’s superior for the parts where you don’t need the fast iterations of an interpreter.

[flohofwoe]

Not sure, I haven't tried Rust for gamedev stuff. But I think unsafe{} is still very picky. It just removes some borrow checker restrictions, but still requires a lot of 'correctness', and I guess it also doesn't magically improve compilation time.

One other 'modern' solution is to use a compiled language for the whole 'stack', but with a hot code reload solution, so you can change the code on the running game - which also tremendously reduces turnaround times.

[xedrac]

I really like Rust, but it feels a bit rigid for game programming. I'd probably still use it, because Bevy, but I'd definitely push a lot of logic into a scripting language.

[weinzierl]

I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.

[valbaca]

I'm not personally familiar with it, but I think you want to take a look at Elixir. I've heard it often in the same vein as Rust but for web. Not exactly the same, but in terms of a high-quality language.

https://elixir-lang.org/

https://www.phoenixframework.org/

[schemescape]

Do you mean like a scripting language that is brand new and doesn’t have a ton of historical warts?

[flohofwoe]

I guess AssemblyScript would fit that requirement. It's essentially TypeScript without the historical Javascript compatibility warts:

https://www.assemblyscript.org/introduction.html

[KyeRussell]

This is precisely what abstractions are meant to solve. If you’re needing to think about something “anyway”, then it’s a leaky abstraction.