3 ms·

"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 any

"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.

KyeRussell 4y ago
This is precisely what abstractions are meant to solve. If you’re needing to think about something “anyway”, then it’s a leaky abstraction.
flohofwoe 4y ago
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.
- Someone 4y ago
  > 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 4y ago
    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.
- peterashford 4y ago
  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 4y ago
    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 4y ago
      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 4y ago
        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.
        peterashford 4y ago
        Oh no, I think you made a good point. I was definitely thinking about game code per se, rather than engines. The extra rigour around an engine (any library code, really) is definitely a good thing
- weinzierl 4y ago
  I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.
  - valbaca 4y ago
    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://elixir-lang.org/ https://www.phoenixframework.org/ https://www.phoenixframework.org/
  - schemescape 4y ago
    Do you mean like a scripting language that is brand new and doesn’t have a ton of historical warts?
    - flohofwoe 4y ago
      I guess AssemblyScript would fit that requirement. It's essentially TypeScript without the historical Javascript compatibility warts: https://www.assemblyscript.org/introduction.html https://www.assemblyscript.org/introduction.html
- xedrac 4y ago
  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.

KyeRussell 4y ago

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

flohofwoe 4y ago

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.

Someone 4y ago
> 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 4y ago
  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.
peterashford 4y ago
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 4y ago
  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 4y ago
    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 4y ago
      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.
      - peterashford 4y ago
        Oh no, I think you made a good point. I was definitely thinking about game code per se, rather than engines. The extra rigour around an engine (any library code, really) is definitely a good thing
weinzierl 4y ago
I wish there was a language that is to JavaScript/TypeScript/Python/Lua what Rust is to C++/C/Java.
- valbaca 4y ago
  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://elixir-lang.org/ https://www.phoenixframework.org/ https://www.phoenixframework.org/
- schemescape 4y ago
  Do you mean like a scripting language that is brand new and doesn’t have a ton of historical warts?
  - flohofwoe 4y ago
    I guess AssemblyScript would fit that requirement. It's essentially TypeScript without the historical Javascript compatibility warts: https://www.assemblyscript.org/introduction.html https://www.assemblyscript.org/introduction.html
xedrac 4y ago
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.