7 ms·

Rust Is for the Engine, Not the Game

75 points by qsantos 2y ago

dmoy 2y ago
The hn thread for the article referenced in the very beginning of this article is here: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033 (1mo ago, 900+ comments)
OtomotO 2y ago
Bevy is aware of the dynamic plugin issue and solves it by removing the functionality in 0.15: ```rust /// Errors that can occur when loading a dynamic plugin #[derive(Debug, Error)] #[deprecated( since = "0.14.0", note = "The current dynamic plugin system is unsound and will be removed in 0.15." )] ``` Source: https://github.com/bevyengine/bevy/blob/main/crates/bevy_dynamic_plugin/src/loader.rs https://github.com/bevyengine/bevy/blob/main/crates/bevy_dyn...
- _flux 2y ago
  Is there going to be something to replace it?
  - SeanAnderson 2y ago
    Not at this time, no. You can read more here: https://github.com/bevyengine/bevy/issues/11969 https://github.com/bevyengine/bevy/issues/11969
- rob74 2y ago
  That sure sounds like throwing the baby out with the bathwater? If they had something better to replace it, ok, but according to other comments, there will be no replacement...
  - maxbond 2y ago
    If it is broke, and you can't fix it, then it's a loaded footgun and should be removed.
  - tbillington 2y ago
    It wasn't really used. It'll likely re-appear in a future release in a better state if people want it. Bevy is still pre-1.0.
Animats 2y ago
Ouch. I did not know that Bevy worked that way, with their very own typing system. I use Rend3/WGPU/Vulkan, which use Rust more or less correctly. My own code is 100% safe Rust. I'm not clear on why so many people have problems with working in safe Rust.
- spoiler 2y ago
  It's not as grim as the author makes it sound... I regularly read bevy code. Sure there's some custom reflection and type erasure, but that's mostly to support the highly ergonomic APIs and for optimising ECS layout and access. There are conversations (maybe even an RFC) around better supporting reflection in the language itself, which would improve the situation a lot. (Edit: some of it linked at the end of the post) Bevy is quite literally pushing Rust festures and the type system to their limits on multiple fronts, sometimes "exceeding" those limits with custom code. All with the intent of not sacrificing performance or happy path ergonomics. Of course there's going to be some unsafe.
  - Animats 2y ago
    > maybe even an RFC I really should try to pull together my proposal for back references. A big problem in Rust is that if A owns B, B can't have a static reference to A. If you want to do that, you have to make all links to A be Rc references, and have B contain a Rc::Weak reference to A. Then there's a run-time check if you try to make the weak reference into a strong reference temporarily. Usually, the program is set to panic if that fails. The question is whether a static analysis can determine that such a weak to strong raise will never fail. If that could be proven at compile time, the reference counting would be unnecessary. And Rust could have sound back-references. If all the places where a weak link is raised to a strong link are bounded by scopes, this is probably do-able. But hard.
- peterashford 2y ago
  Are you writing games?
  - Animats 2y ago
_flux 2y ago
Surely there are options other than Python, GDScript, C, C++, C# to consider before making a new language? E.g. GDScript is characterized as "GDScript has minimal tooling. Most of Rust's best lints and static analysis features are missing": well, a new language is going to miss all tooling. And how long did it take Rust to get to the point where it has its best lints and static analysis features? OCaml could have done fine in that comparison, based on the critique provided. Also, I haven't tried Zig, but based on what I've read, I do believe it would have been worth an evaluation as well.
- pjmlp 2y ago
  D for example, used by Remedy Games on some of their titles. "D: Using an Emerging Language in Quantum Break" https://www.gdcvault.com/play/1023819/D-Using-an-Emerging-Language https://www.gdcvault.com/play/1023819/D-Using-an-Emerging-La...
  - PoignardAzur 2y ago
    > used by Remedy Games on some of their titles. You're implying present tense, but from what I remember, the studio gave up on D instantly after Ethan Watson (the guy who gave that talk) left. There have been no mention of D in gamedev in years.
    - pjmlp 2y ago
      From English point of view, that sentece goes both ways. "used by" => in the past "some of their titles." => 1 or more And yes, C# was won out over D, in what concens AAA studios. But that wasn't the point, rather languages missing from OP's list.
gtsnexp 2y ago
Bevy, the leading game engine for Rust, seems to have significant issues with the borrow checker and UI toolkit. Its heavy use of type erasure and runtime errors compromises Rust's safety features. These guys suggest that a new language similar to Rust, like June, could address these problems while retaining Rust's strengths. To improve Rust for game development, the community should advocate for features like compile-time reflection, better const support, and improved handling of the borrow checker. Historically, this situation reminds me of what happened with C++, where continuous fixes led to a convoluted structure that many developers abhor.
- tbillington 2y ago
  > the community should advocate for features like compile-time reflection, better const support, and improved handling of the borrow checker It's happening :)
wudangmonk 2y ago
When designing anything like a language or library you always create the use cases first and then work backwards. Any game engine not created side by side with a game will be crap. Any 'cool feature' programming language without a decently sized codebase so serve as a beacon to guide you will expose all the flaws in the language that the creators never anticipated because they never created anything sufficiently complex. Unless you are dogfooding whatever you create, it will be crap and you are better off not creating in the first place, don't waste everyone's time with stuff you yourself couldn't be bothered to actually use.
- jay-barronville 2y ago
  My take is, if you’re not dogfooding what you’ve created, you either don’t believe in it or you didn’t have a need for it (i.e., likely a solution for a nonexistent problem). The latter is okay for fun and/or research/experimentation purposes, but at least make that clear so that everyone knows what to expect (or not expect).
  - eru 2y ago
    By that heuristic, only astronauts should be making space suits?
    - suby 2y ago
      I don't think that's the proper interpretation. It isn't so much that you have to make everything you use, but rather, what you do make you should use.
      - eru 2y ago
        So the guys making spacesuits should be astronauts?
        piva00 2y ago
        They don't need to be an astronaut to wear the prototypes and check how they fit, how they allow you to move or not move, how convenient it is to access the tool belt, etc.
iTokio 2y ago
> I'm confident that June (or some derivative language) will find its way to the gamedev world in the near future The repo has been archived and now is unmaintained: https://www.sophiajt.com/following-new-paths-ahead/ https://www.sophiajt.com/following-new-paths-ahead/
frankjr 2y ago
No language fits all use cases no matter how much you want it to be true. I'm a fan of Rust and the trend to rewrite things in Rust because usually you get something much faster, safer, and something that reflects current needs (helix, ripgrep, fd, yazi, zoxide, ...) bla bla but if you want Bevy's level of dynamicness (is that a word?), Rust might not be the language to use.
xgdgsc 2y ago
Or consider julia for the game as you can start with dynamic types and JIT to get quick results and go static (even compile to cpp in the future) with https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-proprietary-julia-aot-compiler-is-now-available-for-free-use-personal-educational-license-only/114633 https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-... later. See discussions like https://discourse.julialang.org/t/rust-vs-c-and-vs-julia-and-other-at-least-relating-to-game-dev-leaving-rust-gamedev-after-3-years-and-ecs/113593/5 https://discourse.julialang.org/t/rust-vs-c-and-vs-julia-and... https://discourse.julialang.org/t/should-we-make-a-push-into-gaming-industry/98792/18?page=3 https://discourse.julialang.org/t/should-we-make-a-push-into...
- germandiago 2y ago
  In the future is always a hard path. Maybe does not fully happen.
  - xgdgsc 2y ago
    Yes. I tend to trust their team considering previous libraries they wrote. And if people in the game industry are interested, it might fully happen faster because the added incentive.
cyber_kinetist 2y ago
What I want for gamedev is not another systems programming language (C++ is good enough for low-level engine code even with all its warts, and it doesn't seem Rust/Zig/etc will replace this easily). What I really want is something like a lightweight embeddable C# without the GC: - A strongly-typed scripting language that's easy to bind with a C++-based game engine core (or Rust/Zig/whatever) - Guarantees sufficient-enough performance while achieving fast compilation for development builds (very important for gamedev iteration). A possible solution for this would be a bytecode VM, but with the option for AOT compilation when exporting your game. - Comes without a GC. Options could be to just use plain old reference counting, but also something like what Inko does with runtime-checked dangling references or alternatively what Vale does with with generational references. - [EDIT] Support for value types (like structs in C#)! Really indispensible when you write any "mathy" gamedev code or trying to bind to C++ data structures efficiently.
- The_Colonel 2y ago
  What is the showstopper for GC? There has been a lot of development in the area, e.g. Java's ZGC has maximum pause faster than 1 millisecond (while the typical pause is much shorter). Wouldn't that be good enough for game scripting?
  - cyber_kinetist 2y ago
    The problem with GC for a game engine is not just plain performance... but it's when you're trying to bind engine objects to the scripting language. From the scripting side you're dealing with GC-like semantics (where object deletion can be deferred indefinitely), but the C++-engine side objects need to adhere to C++ object semantics (whether that be manual / RAII / reference counting). This gap between the two can lead to some "interesting" engine decisions: for example in Unity they have a separate UnityEngine.Object base type separate from the C# runtime System.Object type, which have very different semantics and thus lead to some funny headaches! Note that Godot's scripting language (GDScript) doesn't use GC and instead just uses reference counting implemented in plain C++, and thus were able to unify the object behavior between C++ and the scripting layer. An alternative approach for supporting GC in your game engine, would be to extend C++ on the engine-side to support GC with some black magic (aka Unreal's approach with UObject). But that requires adding an additional hacky transpiler / reflection system on top of C++... which I think has been mostly a net negative in terms of usability (if you've tried using Unreal you'll quickly get what I mean...)
dangmale 2y ago
[flagged]
- shzhdbi09gv8ioi 2y ago
  This kind of comment does not belong on HN.
PoignardAzur 2y ago
> Compile-time reflection would help a lot with almost all crates. That's both for their compile times and feature set. (goodnight, sweet prince) It's silly that people uncritically accept the narrative that all hopes of getting reflection implemented were lost when JeanHeyd quit the project. As far as I'm aware, the only thing JeanHeyd posted was an initial design exploration. Not a formal RFC, not code, just some design theory-crafting. That's good, that's something people need to do to advance the language, but it's a little off-putting how some people are treating that writeup like some Graal lost and not like one design exploration among many of its kind. Especially since that design work would likely have stayed purely theoretical for a while, given that the compiler's team reaction to a similar proposal, variadic generics, was "We won't have the bandwidth to even evaluate the proposal for at least a year".
emigrantdd 2y ago
someone got a Rust error in console when tried to run Rust game?
germandiago 2y ago
C++ is for the engine IMHO. It can do a lot of things without as many twists as Rust.
James_K 2y ago
It really shocked me that it took people so long to figure this out. When I used Rust, I found it really quite unpleasant for prototyping, which if I understand it correctly is essentially all you are doing during game development. I imagine someone who stuck at it for a long time would learn a lot of strange lessons very quickly and eventually start churning out a lot of very odd code, I know I started to do that after a while. Indeed some of the stuff in this article reminds me of the stuff I used to make. When you want to make a programming language work in ways it just isn't designed for, you end up making a lot of smelly code. I see this in C++, so I'm not entirely surprised it shows up in Rust also. Rust is designed by C++ programmers to service their needs so it logically also replicates the shortcomings of C++. Use a high level language for your logic, and a low level one to optimise your hot loop. Have we not learned this lesson already? It is almost always easier to design something at a high level and migrate parts of it downwards as necessary.
- selfmodruntime 2y ago
  I kind of agree. It is pleasant to use for prototyping in "simpler" use cases where you want correctness from the start. I use Rust daily for implementation of IETF standards and drafts and rust helps me a lot in figuring out undefined cases or things that are still unclear. I would never use Rust for game design or reactive UI and I don't understand why people are trying to shoehorn Rust into these use cases. They both benefit immensely from global shared state and object-oriented patterns and Rust's correctness makes workarounds harder if not impossible.
- einpoklum 2y ago
  > When you want to make a programming language work in ways it just isn't designed for, you end up making a lot of smelly code. That depends on the language. If your language is flexible/multi-paradigmatic, it was designed for you to make it work in all sorts of ways, so there is at least a potential of the code not eing smelly. > Rust is designed by C++ programmers to service their needs Rust was originally written in OCaml for someone who wanted to work on a browser engine. So, I'm not quite sure about your characterization. Remember also that different (C++) programmers have vastly different needs. https://en.wikipedia.org/wiki/Rust_(programming_language) https://en.wikipedia.org/wiki/Rust_(programming_language)
pornel 2y ago
This makes sense, and explains why there's more Rust game engines than Rust games :) Rust adds friction to quick prototyping, but OTOH it is particularly good at providing robust, safe library APIs (with machine-checked memory management, lifetimes, sharing across threads, and strong patterns for error handling). It's one of the reasons why Rust applications can easily use so many dependencies. Rust intentionally makes it difficult to cut corners, and by default enforces all of its best practices around immutability, thread-safety, etc. This is annoying for quickly trying things out for gameplay purposes (central point of the "Leaving Rust gamedev" post), because exploration of gameplay ideas doesn't need bug-free code, it needs to iterate quickly. But this focus on correctness is the right trade-off when building foundational components and libraries. Applications need to have a stable and reliable platform to build on, and to actually ship they can't have a "prototype-quality" engine.

75 points by qsantos 2y ago

dmoy 2y ago

The hn thread for the article referenced in the very beginning of this article is here: https://news.ycombinator.com/item?id=40172033 https://news.ycombinator.com/item?id=40172033 (1mo ago, 900+ comments)

OtomotO 2y ago

Bevy is aware of the dynamic plugin issue and solves it by removing the functionality in 0.15: ```rust /// Errors that can occur when loading a dynamic plugin #[derive(Debug, Error)] #[deprecated( since = "0.14.0", note = "The current dynamic plugin system is unsound and will be removed in 0.15." )] ``` Source: https://github.com/bevyengine/bevy/blob/main/crates/bevy_dynamic_plugin/src/loader.rs https://github.com/bevyengine/bevy/blob/main/crates/bevy_dyn...

_flux 2y ago
Is there going to be something to replace it?
- SeanAnderson 2y ago
  Not at this time, no. You can read more here: https://github.com/bevyengine/bevy/issues/11969 https://github.com/bevyengine/bevy/issues/11969
rob74 2y ago
That sure sounds like throwing the baby out with the bathwater? If they had something better to replace it, ok, but according to other comments, there will be no replacement...
- maxbond 2y ago
  If it is broke, and you can't fix it, then it's a loaded footgun and should be removed.
- tbillington 2y ago
  It wasn't really used. It'll likely re-appear in a future release in a better state if people want it. Bevy is still pre-1.0.

Animats 2y ago

Ouch. I did not know that Bevy worked that way, with their very own typing system. I use Rend3/WGPU/Vulkan, which use Rust more or less correctly. My own code is 100% safe Rust. I'm not clear on why so many people have problems with working in safe Rust.

spoiler 2y ago
It's not as grim as the author makes it sound... I regularly read bevy code. Sure there's some custom reflection and type erasure, but that's mostly to support the highly ergonomic APIs and for optimising ECS layout and access. There are conversations (maybe even an RFC) around better supporting reflection in the language itself, which would improve the situation a lot. (Edit: some of it linked at the end of the post) Bevy is quite literally pushing Rust festures and the type system to their limits on multiple fronts, sometimes "exceeding" those limits with custom code. All with the intent of not sacrificing performance or happy path ergonomics. Of course there's going to be some unsafe.
- Animats 2y ago
  > maybe even an RFC I really should try to pull together my proposal for back references. A big problem in Rust is that if A owns B, B can't have a static reference to A. If you want to do that, you have to make all links to A be Rc references, and have B contain a Rc::Weak reference to A. Then there's a run-time check if you try to make the weak reference into a strong reference temporarily. Usually, the program is set to panic if that fails. The question is whether a static analysis can determine that such a weak to strong raise will never fail. If that could be proven at compile time, the reference counting would be unnecessary. And Rust could have sound back-references. If all the places where a weak link is raised to a strong link are bounded by scopes, this is probably do-able. But hard.
peterashford 2y ago
Are you writing games?
- Animats 2y ago

_flux 2y ago

Surely there are options other than Python, GDScript, C, C++, C# to consider before making a new language? E.g. GDScript is characterized as "GDScript has minimal tooling. Most of Rust's best lints and static analysis features are missing": well, a new language is going to miss all tooling. And how long did it take Rust to get to the point where it has its best lints and static analysis features? OCaml could have done fine in that comparison, based on the critique provided. Also, I haven't tried Zig, but based on what I've read, I do believe it would have been worth an evaluation as well.

pjmlp 2y ago
D for example, used by Remedy Games on some of their titles. "D: Using an Emerging Language in Quantum Break" https://www.gdcvault.com/play/1023819/D-Using-an-Emerging-Language https://www.gdcvault.com/play/1023819/D-Using-an-Emerging-La...
- PoignardAzur 2y ago
  > used by Remedy Games on some of their titles. You're implying present tense, but from what I remember, the studio gave up on D instantly after Ethan Watson (the guy who gave that talk) left. There have been no mention of D in gamedev in years.
  - pjmlp 2y ago
    From English point of view, that sentece goes both ways. "used by" => in the past "some of their titles." => 1 or more And yes, C# was won out over D, in what concens AAA studios. But that wasn't the point, rather languages missing from OP's list.

gtsnexp 2y ago

Bevy, the leading game engine for Rust, seems to have significant issues with the borrow checker and UI toolkit. Its heavy use of type erasure and runtime errors compromises Rust's safety features. These guys suggest that a new language similar to Rust, like June, could address these problems while retaining Rust's strengths. To improve Rust for game development, the community should advocate for features like compile-time reflection, better const support, and improved handling of the borrow checker. Historically, this situation reminds me of what happened with C++, where continuous fixes led to a convoluted structure that many developers abhor.

tbillington 2y ago
> the community should advocate for features like compile-time reflection, better const support, and improved handling of the borrow checker It's happening :)

wudangmonk 2y ago

When designing anything like a language or library you always create the use cases first and then work backwards. Any game engine not created side by side with a game will be crap. Any 'cool feature' programming language without a decently sized codebase so serve as a beacon to guide you will expose all the flaws in the language that the creators never anticipated because they never created anything sufficiently complex. Unless you are dogfooding whatever you create, it will be crap and you are better off not creating in the first place, don't waste everyone's time with stuff you yourself couldn't be bothered to actually use.

jay-barronville 2y ago
My take is, if you’re not dogfooding what you’ve created, you either don’t believe in it or you didn’t have a need for it (i.e., likely a solution for a nonexistent problem). The latter is okay for fun and/or research/experimentation purposes, but at least make that clear so that everyone knows what to expect (or not expect).
- eru 2y ago
  By that heuristic, only astronauts should be making space suits?
  - suby 2y ago
    I don't think that's the proper interpretation. It isn't so much that you have to make everything you use, but rather, what you do make you should use.
    - eru 2y ago
      So the guys making spacesuits should be astronauts?
      - piva00 2y ago
        They don't need to be an astronaut to wear the prototypes and check how they fit, how they allow you to move or not move, how convenient it is to access the tool belt, etc.

iTokio 2y ago

> I'm confident that June (or some derivative language) will find its way to the gamedev world in the near future The repo has been archived and now is unmaintained: https://www.sophiajt.com/following-new-paths-ahead/ https://www.sophiajt.com/following-new-paths-ahead/

frankjr 2y ago

No language fits all use cases no matter how much you want it to be true. I'm a fan of Rust and the trend to rewrite things in Rust because usually you get something much faster, safer, and something that reflects current needs (helix, ripgrep, fd, yazi, zoxide, ...) bla bla but if you want Bevy's level of dynamicness (is that a word?), Rust might not be the language to use.

xgdgsc 2y ago

Or consider julia for the game as you can start with dynamic types and JIT to get quick results and go static (even compile to cpp in the future) with https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-proprietary-julia-aot-compiler-is-now-available-for-free-use-personal-educational-license-only/114633 https://discourse.julialang.org/t/syslabcc-suzhou-tongyuans-... later. See discussions like https://discourse.julialang.org/t/rust-vs-c-and-vs-julia-and-other-at-least-relating-to-game-dev-leaving-rust-gamedev-after-3-years-and-ecs/113593/5 https://discourse.julialang.org/t/rust-vs-c-and-vs-julia-and... https://discourse.julialang.org/t/should-we-make-a-push-into-gaming-industry/98792/18?page=3 https://discourse.julialang.org/t/should-we-make-a-push-into...

germandiago 2y ago
In the future is always a hard path. Maybe does not fully happen.
- xgdgsc 2y ago
  Yes. I tend to trust their team considering previous libraries they wrote. And if people in the game industry are interested, it might fully happen faster because the added incentive.

cyber_kinetist 2y ago

What I want for gamedev is not another systems programming language (C++ is good enough for low-level engine code even with all its warts, and it doesn't seem Rust/Zig/etc will replace this easily). What I really want is something like a lightweight embeddable C# without the GC: - A strongly-typed scripting language that's easy to bind with a C++-based game engine core (or Rust/Zig/whatever) - Guarantees sufficient-enough performance while achieving fast compilation for development builds (very important for gamedev iteration). A possible solution for this would be a bytecode VM, but with the option for AOT compilation when exporting your game. - Comes without a GC. Options could be to just use plain old reference counting, but also something like what Inko does with runtime-checked dangling references or alternatively what Vale does with with generational references. - [EDIT] Support for value types (like structs in C#)! Really indispensible when you write any "mathy" gamedev code or trying to bind to C++ data structures efficiently.

The_Colonel 2y ago
What is the showstopper for GC? There has been a lot of development in the area, e.g. Java's ZGC has maximum pause faster than 1 millisecond (while the typical pause is much shorter). Wouldn't that be good enough for game scripting?
- cyber_kinetist 2y ago
  The problem with GC for a game engine is not just plain performance... but it's when you're trying to bind engine objects to the scripting language. From the scripting side you're dealing with GC-like semantics (where object deletion can be deferred indefinitely), but the C++-engine side objects need to adhere to C++ object semantics (whether that be manual / RAII / reference counting). This gap between the two can lead to some "interesting" engine decisions: for example in Unity they have a separate UnityEngine.Object base type separate from the C# runtime System.Object type, which have very different semantics and thus lead to some funny headaches! Note that Godot's scripting language (GDScript) doesn't use GC and instead just uses reference counting implemented in plain C++, and thus were able to unify the object behavior between C++ and the scripting layer. An alternative approach for supporting GC in your game engine, would be to extend C++ on the engine-side to support GC with some black magic (aka Unreal's approach with UObject). But that requires adding an additional hacky transpiler / reflection system on top of C++... which I think has been mostly a net negative in terms of usability (if you've tried using Unreal you'll quickly get what I mean...)

dangmale 2y ago

[flagged]

shzhdbi09gv8ioi 2y ago
This kind of comment does not belong on HN.

PoignardAzur 2y ago

> Compile-time reflection would help a lot with almost all crates. That's both for their compile times and feature set. (goodnight, sweet prince) It's silly that people uncritically accept the narrative that all hopes of getting reflection implemented were lost when JeanHeyd quit the project. As far as I'm aware, the only thing JeanHeyd posted was an initial design exploration. Not a formal RFC, not code, just some design theory-crafting. That's good, that's something people need to do to advance the language, but it's a little off-putting how some people are treating that writeup like some Graal lost and not like one design exploration among many of its kind. Especially since that design work would likely have stayed purely theoretical for a while, given that the compiler's team reaction to a similar proposal, variadic generics, was "We won't have the bandwidth to even evaluate the proposal for at least a year".

emigrantdd 2y ago

someone got a Rust error in console when tried to run Rust game?

germandiago 2y ago

C++ is for the engine IMHO. It can do a lot of things without as many twists as Rust.

James_K 2y ago

It really shocked me that it took people so long to figure this out. When I used Rust, I found it really quite unpleasant for prototyping, which if I understand it correctly is essentially all you are doing during game development. I imagine someone who stuck at it for a long time would learn a lot of strange lessons very quickly and eventually start churning out a lot of very odd code, I know I started to do that after a while. Indeed some of the stuff in this article reminds me of the stuff I used to make. When you want to make a programming language work in ways it just isn't designed for, you end up making a lot of smelly code. I see this in C++, so I'm not entirely surprised it shows up in Rust also. Rust is designed by C++ programmers to service their needs so it logically also replicates the shortcomings of C++. Use a high level language for your logic, and a low level one to optimise your hot loop. Have we not learned this lesson already? It is almost always easier to design something at a high level and migrate parts of it downwards as necessary.

selfmodruntime 2y ago
I kind of agree. It is pleasant to use for prototyping in "simpler" use cases where you want correctness from the start. I use Rust daily for implementation of IETF standards and drafts and rust helps me a lot in figuring out undefined cases or things that are still unclear. I would never use Rust for game design or reactive UI and I don't understand why people are trying to shoehorn Rust into these use cases. They both benefit immensely from global shared state and object-oriented patterns and Rust's correctness makes workarounds harder if not impossible.
einpoklum 2y ago
> When you want to make a programming language work in ways it just isn't designed for, you end up making a lot of smelly code. That depends on the language. If your language is flexible/multi-paradigmatic, it was designed for you to make it work in all sorts of ways, so there is at least a potential of the code not eing smelly. > Rust is designed by C++ programmers to service their needs Rust was originally written in OCaml for someone who wanted to work on a browser engine. So, I'm not quite sure about your characterization. Remember also that different (C++) programmers have vastly different needs. https://en.wikipedia.org/wiki/Rust_(programming_language) https://en.wikipedia.org/wiki/Rust_(programming_language)

pornel 2y ago

This makes sense, and explains why there's more Rust game engines than Rust games :) Rust adds friction to quick prototyping, but OTOH it is particularly good at providing robust, safe library APIs (with machine-checked memory management, lifetimes, sharing across threads, and strong patterns for error handling). It's one of the reasons why Rust applications can easily use so many dependencies. Rust intentionally makes it difficult to cut corners, and by default enforces all of its best practices around immutability, thread-safety, etc. This is annoying for quickly trying things out for gameplay purposes (central point of the "Leaving Rust gamedev" post), because exploration of gameplay ideas doesn't need bug-free code, it needs to iterate quickly. But this focus on correctness is the right trade-off when building foundational components and libraries. Applications need to have a stable and reliable platform to build on, and to actually ship they can't have a "prototype-quality" engine.