17 ms·

Why Rust Is the Future of Game Development

157 points by adamnemecek 6y ago

RcouF1uZ4gsC 6y ago
> Way back around 2010, Mozilla was frustrated by the state of development in Firefox, a massive software project written mostly in C++. Despite best practices > Even so, manual memory manipulation is easy to get wrong, Even predating C++11, you should not have been doing manual memory management. I don’t think Mozilla was following best practices. IIRC, there were pointers everywhere. Even before C++11 best practices for C++ were to try for value semantics as much as possible. Mozilla code base was more like C with Classes than best practice C++.
- klodolph 6y ago
  I think the criticism, “But you were writing C++ wrong” falls more than a little flat. The Firefox codebase may be old, but even with teams of good, experienced C++ programmers I still see memory errors of the type that Rust is designed to prevent. Anyway, you are unlikely to avoid pointers completely in a good C++ codebase. Value semantics are very often the wrong semantics for the code you are trying to write. You can end up with dangling references as easily as you can end up with dangling pointers. If you use std::shared_ptr everywhere, then what you have is a slow & inefficient GC.
- lostcolony 6y ago
  So what in the language prevented them from doing it that way? What in the community ensured they didn't do it that way? Firefox is open source, and yet it still happened. "Best practices" is such a red herring. Best practices = don't write bugs, too; yet there are bugs. You can't evaluate a language in theory and ignore what happens in practice any more than you can with any other thing in life. It's the UX, does it do what users expect it to do, and is that the lowest friction path possible to achieve the goal. "You're not following best practices" is basically "you're holding it wrong". While arguably true, it is an attempt to excuse a bad design decision or impedance mismatch.
  - dxuh 6y ago
    > "Best practices = don't write bugs" That's absolutely not what it means. Best practices usually means "don't use these features anymore" and "use these features whenever you can". And that is very reasonable and DOES get rid of a lot of the problems (not all) that are usually associated with C++, but still people don't do it. I blame it many C++-people actually preferring "C with classes" (various code bases openly prefers this as their coding style - you won't get those people on the Rust train either) and many people just don't know or don't trust it, because some of the newer features are sadly not very easy to understand properly.
    - lostcolony 6y ago
      You clearly missed the facetious tone of that part, along with the entire rest of the post. So let me simplify - if to use a language correctly requires knowing the full history of the language, along with explicitly eschewing some of the key features of the language (except in certain cases when you need them! And they're not deprecated or issue warnings or similar by the compiler), and even extremely experienced developers using the language still make mistakes...the issue is with the language.
- sgift 6y ago
  This is not a theoretical problem, it has been researched and the results are not encouraging even for "modern" C++. Either some of the biggest software companies (Mozilla, Microsoft, Google) are all incompetent or there is a problem with C++ in the real world which still hasn't changed despite "you only need to follow best practices in C++".
Thaxll 6y ago
Let me tell you that most C++ game dev never heard of Rust, so imagine how long it's going to take for Rust to be something usable in that domain? Right now in the real world of AAA games it is nowhere, it's not even a consideration so calling it "Rust Is the Future of Game Development" right ... For those who don't work in games, the tech there move very slowly, it's not your typical SV "let's use the latest fun and cutting edge tech".
- sharpercoder 6y ago
  That's a great argument on why it is not present but the future instead.
  - emteycz 6y ago
    And also a great opportunity!
  - 0-_-0 6y ago
    These are not the only 2 options
- an_opabinia 6y ago
  Probably because what AAA game developers actually use is strictly Visual Studio, not C++. Whatever is first class for GUI users on Windows in China and Ukraine is going to impact AAA game development far more than any non-GUI technology. It's not really about tooling. I'm not saying tools. Just Visual Studio. Visual Studio decides what will appear.
  - malkia 6y ago
    Ditto. Also your debugger of choice (Windows again). I can debug C#/C++ in one app (or other .NET language). It's bit of pain for anything else (granted, Rust, I'm told should be good). Then you have the build process, vendorizing your packages (so you don't fetch them off internet), etc. Right now .sln files and MSBuild rule there (like it or not).
- Supermancho 6y ago
02020202 6y ago
...or jai :)
Google234 6y ago
What a humorous title. Looking forward to the Rust Evangelism Strikeforce presence in this thread. Anyway, just say they don’t downvote and flag me into oblivion: Rust good c++ bad
lstodd 6y ago
Let me tell you that the future of game development is in developing games, and any particular language has nothing to do with it. Does anyone care what language were any particular games that keep being replayed or remembered fondly? No. Never.
- Pfhreak 6y ago
  I agree with you, but there are plenty of poorly educated gamers who think that 'developed in Unity' or Gamemaker means the game can't possibly be good. (All evidence to the contrary.)
  - emsy 6y ago
    I have heard complaints about Unity games performing badly, which, for a lot of games, is actually the case.
- St_Alfonzo 6y ago
  Minecraft is a good example where people talk about the programming language. The portability of Java was a benefit for both Server and Client. But it was also critized because of the inefficiency of Java. I dont know if all this would have been better in Rust or other languages.
  - bigbubba 6y ago
    Microsoft now has a second parallel implementation of Minecraft in C++. They've ported this to numerous platforms, but notably not MacOS or Linux desktops. (It's also substantially faster, but comparing it to Java edition is sort of unfair because there are a myriad of differences between the two in game mechanics, with many of the differences probably being relevant to performance.)
  - gmueckl 6y ago
    I don't know for certain, but Java might be one of the reasons for Minecraft being as good as it is as a game. The comparatively minimalistic high level nature of that language leaves few possibilities to get lost in system level optimizations. And iterating in Java is a lot quicker than in C++ or Rust. It is an environment that helps focussing on game logic.
bigbubba 6y ago
I haven't worked in the games industry so please correct me if I'm wrong, but isn't game development culture one of rushing crude hacks out the door at the last minute? Rust seems like a poor 'culture fit' in this regard.
- macspoofing 6y ago
  >Rust seems like a poor 'culture fit' in this regard. How would Rust prevent "rushing crude hacks out the door at the last minute"?
  - bigbubba 6y ago
    Doesn't the borrow checker ask programmers to be a bit less crude and hacky? I thought that was the point.
  - throw_m239339 6y ago
    > How would Rust prevent "rushing crude hacks out the door at the last minute"? Because game developers would be fighting the borrow checker instead of shipping leaky code that compiles without hurdle?
- sgift 6y ago
  From what I can gather (from the outside) this has changed over the years. Games are not monoliths anymore and some parts have to work for successors or other games based on the same tools, so "things work for more than the bare minimum" has become more important over time. I'm sure there's still more than enough throwaway code, but that is probably not done in C++ currently either, but in some kind of scripting language.
- Scramblejams 6y ago
  Common game industry joke: Q: What does a game company call a teetering tower of ugly hacks on top of ugly hacks? A: Shipped! Source: 5 years in the games business. The game development process can get messy. My studio doesn't crunch, but elsewhere crunch is the norm, and does anyone think the code is gonna stay beautiful during endless crunch? The old-timers here all have their war stories they tell of last minute ugly hacks tossed in just to get a game out the door on time.
walkingolof 6y ago
For 95% of all game developer the future is a engine like Unreal or Unity and your scripting language of choice. The rest, triple A titles and engine developers may chose something else, but the inertia of C/C++ will make that a very long process.
- bluedino 6y ago
  The future - the next big game engine, being planned out or written right now, might be done in rust.
  - mrnothing_123 6y ago
    alot of critical parts of a game engine are already made in c or c++, and mono(the default stand for closs plataform for not engine user is not compatible whit rust)
jayd16 6y ago
I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings. We could be changing all these C#/C++ engines into C#/Rust engines.
- suprfnk 6y ago
  > even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. Just curious; what's the tooling gap between Rust and C#, according to you? I work in C# profesionally, and dabble in Rust, and haven't really found Rust tooling lacking yet -- but maybe that's because I'm only working on small hobby projects.
  - pjmlp 6y ago
    Try to do something like WinUI in Rust, or debug a mixed code base like in C# and C++ on Studio.
  - lostmsu 6y ago
    Aren't you using refactoring tools like ReSharper? Also, what about debugging? C# does edit & continue and allows arbitrary statement execution during debugging. Does Rust debugger even allow moving the instruction pointer at will?
- Iwan-Zotow 6y ago
  Not in a game business, but I could tell you - until Rust is supported (down to debugging) in Visual Studio, there would be no C#/Rust apps, and plenty C#/C++ apps.
  - halvnykterist 6y ago
    Debugging in VS actually works pretty well already, the msvc target generates PDB files. It's what I use when need to attach a debugger to something. Actual language support would be really nice, though. Hopefully MS are already working on this.
Pfhreak 6y ago
The future of Game Development is about democratization of tools. With tools like Unity, GameMaker, and RPG maker it has become easier and easier for anyone to make a game. While Rust might be a good foundation for some performance critical code, I'd hardly say it's the "Future of Game Development". Already, games use tools like Blueprints in Unreal to make games with limited to no coding experience, and I expect those tools will continue to get better and better over time.
- centimeter 6y ago
  Not directly relevant, but the use of the phrase “democratization” to describe a process that has nothing whatsoever to do with democracy (“anarchization”?) has become a pet peeve of mine.
  - taeric 6y ago
    I'm assuming it means getting public involvement? Getting people to participate in the process. That said, I do feel most of the examples are not that. The old shareware scene was much closer to the spirit. Now that we are pushing winners only, feels more like corporate control than it does people control. :(
    - Pfhreak 6y ago
      Go visit http://itch.io/ http://itch.io/ and search around for a bit. There are thousands of games to explore here made by people from all walks of life. Most of these will see zero to minor financial success, but people are still making them because they are inspired to share some experience. Even on the major platforms, you'll find stuff like Umurangi Generation, a game about taking photographs in a surreal autocratic environment. That game is not a 'winner only', but it's fascinating and only exists because people who want to make that experience had access to tools they could understand and use. Democratic processes and tools are tools that are widely available to the public. It's not only AAA studios making games, everyone around the world is making games.
      - 6y ago
klodolph 6y ago
I think a number of companies, like mine, are working with Rust internally. But articles like these don’t provide any insight into those efforts, which are kept private. Game development at large-scale is a mix of systems programming of the kind that Rust excels at and gameplay logic programming which has loose performance requirements and may be written by people who are not primarily coders. So you see a lot of codebases split between two languages, like a C++ core with Lua bindings or something like that. If we see Rust adoption here I’m expecting it to be from a kind of skunkworks inside the company replacing specific, carefully-chosen systems with Rust code. At my company, that’s how it’s done, and it’s a very slow process. (I don’t work in the game industry, so all I hear is rumors from people that used to work in the game industry.)
haunter 6y ago
The future is game development is GaaS and putting as much as p2w/gacha elements into the title as much as you can get away with it (on top of selling the game for $70)
p0nce 6y ago
Rust builds slower than C++.
- adamnemecek 6y ago
  But rebuilding seems faster since the Rust Compiler is smarter about caching things. I think that the way the Rust module system works also makes things faster.
- mlindner 6y ago
  Not really, especially if you use a lot of templated code.
  - pjmlp 6y ago
    Really, specially if you don't use binary libraries.
macspoofing 6y ago
Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 are not as pronounced.
- FartyMcFarter 6y ago
  It's still quite easy to shoot oneself in the foot with modern C++: #include <string_view> #include <string> #include <iostream> int main() { std::string_view v = std::string("xyz"); std::cout << v << '\n'; }
  - rhodysurf 6y ago
    OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below
    - steveklabnik 6y ago
      Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.
      - rhodysurf 6y ago
        So thats what I initially thought but then I ran it and it works so IDK anything anymore.
        steveklabnik 6y ago
        UB can do anything, including something that seems like it works. Just because the memory has been deallocated doesn't mean that the bytes there were changed. The pointer may still point to them, and it may still "work."
nayuki 6y ago
This is a repost of https://news.ycombinator.com/item?id=25033247 https://news.ycombinator.com/item?id=25033247 (7 hours earlier)
whateveracct 6y ago
Personally, I'm betting on Haskell - for indie dev in particular where I want to manage huge amounts of complexity as an individual. This is partially because I've been programming Haskell professionally for 5+ years so I'm over the learning curve and well into the realm of efficiency gains. The GHC RTS is akin to the Lua layer and handles all the high-level logic. For storage and compute-intensive things, we can drop to lower-level primitives for performance and then easily hook into them in our scripting layer. I wouldn't be surprised if fleshing out this domain hints at future useful GHC extensions as well. I like Rust a lot, but I honestly think the ability to do highly-abstract programming is worth having to deal with a non-literal compilation pipeline. For gamedev at least. I honestly think it will be astounding what scale of game a single developer will be able to build in Haskell in 3-5 years once all the pioneering is out of the way. Programming a game the size Blasphemous could easily be managed by a single Haskeller I'm pretty sure - leaving resources to focus on art, sound, and storytelling. And that's an easy call - it'll be fun to see just how big and complicated of game logic we can make cheap thanks to good abstractions.
- cylon13 6y ago
  One of the problems with Haskell for game development is, because of the novelty of lazy evaluation, it's very difficult to learn what causes space leaks, and it's difficult to learn how to debug them. If you're already an expert in Haskell this might not seem like a big deal, but it certainly makes adoption a lot harder. Another related issue is the level of abstraction is so high that it makes it harder to be extremely optimal with memory usage and access, which is something game developers love doing, even sometimes when they don't strictly have to. I love programming in Haskell, but I'm highly suspect that it will ever be a widely used game programming language. It's very good at expressing computations in the abstract at the expense of being good at telling a physical computer exactly what to do. Game programmers tend to prefer languages that fall in the latter category in my experience.
  - whateveracct 6y ago
    Yeah I agree it'll never be mainstream for gamedev. Haskell is not really built to have runaway adoption. It's a strength as much as it's a weakness. But I think it'll allow me to be insanely efficient as a gamedev. So I'm a Haskeller-turned-gamedev. Not a gamedev-turned-Haskeller. Haskell performance and memory usage is kind of like JVM programming. You need a mental model of how GHC and its RTS & GC operate. Having frame-oriented code honestly makes it easier to reason about. We Do need more learning materials about this stuff, but first we need more experience! But idt it's any different than using GC for gamedev. And manual memory management is well within Haskell's capabilities. Haskell profiling IME makes space leaks very obvious. That's a too-common paper cut, but once you get cut once you don't make the mistake again :)
andrewmcwatters 6y ago
This article doesn't actually talk about "Why Rust Is the Future of Game Development." You could have taken out the game development piece, and it still doesn't talk about "Why Rust Is the Future of Development," more than talking about Rust features themselves. I should be able to complete the sentence, "Rust is the future of game development because...," but I can't in any meaningful way. Here are the highlights of the article, instead: Rust is the future of game development because Rust has the performance of C++ with the convenience of C#. Rust is the future of game development because Rust has ownership based memory. Rust is the future of game development because Rust is popular. (The article doesn't say this explicitly, but implies it is.) Rust is the future of game development because Rust is still an immature language. (This doesn't actually sell the point, and I'm not sure why the author bothers talking about this.) What's weird, too, is that the article talks about how hard networking is, but _cart has specifically said in the past, "Yup! High level and low level networking is definitely on our radar, but it also isn't our immediate priority." It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. We had modern client-side prediction roughly 20 years ago, and people still don't take multiplayer seriously.
- AsyncAwait 6y ago
  > It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.
  - andrewmcwatters 6y ago
    Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.
    - 6y ago
adamnemecek 6y ago
If you re interested in Rust game dev, check out the rg3d engine https://github.com/mrDIMAS/rg3d https://github.com/mrDIMAS/rg3d. Join the rg3d discord channel https://discord.gg/xENF5Uh https://discord.gg/xENF5Uh
aphextron 6y ago
>Ownership based memory Is this not just ARC?
- adamnemecek 6y ago
  It is not, no, although you can choose to have some types to be Arc. By default the compiler can reason about whether a value is accessed mutably in only one place.
- steveklabnik 6y ago
  Fundamentally different. ARC involves reference counting, and so is a run-time strategy. Ownership in Rust is at compile-time, instead. Now, it is true that languages that use ARC can do compile-time analysis to remove some refcount traffic, and that you can use run-time ownership tracking in Rust if you'd like. The difference is what's built into the languages, what is the default vs what is not, and the kinds of patterns those tend to enable.
hvasilev 6y ago
Two weeks ago Rust was the future of embedded systems (it is not) and now it is the future of Game Development (it is not). I'm starting to think that people's opinion shouldn't be taken seriously unless they have like at least 20 years of experience in a particular field.
- Iwan-Zotow 6y ago
  Rust is the future of humanity!
- adamnemecek 6y ago
  I mean C and CPP are used in both fields so it's not hard to imagine that since Rust is trying to replace both languages, that it would become popular in the two fields as well.
  - cylon13 6y ago
    You do usually find the C preprocessor where you find C, yes.
- a-nikolaev 6y ago
  Hey, Rust is the future of bitcoin and vice versa.
  - SomeoneFromCA 6y ago
    Rust is future of self-driving cars.
- cambalache 6y ago
  The future is now young man : https://www.arewewebyet.org/ https://www.arewewebyet.org/ > Can I replace my Rails/Django/Flask already? > Yup! Rust has mature and production ready frameworks in Actix Web and Rocket, and newer ones like Warp and Tide. These provide everything you’d expect from a web framework, from routing and middleware, to templating, and JSON/form handling. There are crates for everything, and more! I would pay for a reality show where a big Rails application needs to be replaced by Rust by the same engineers who built it.
HelloNurse 6y ago
The article sorely misses code examples: any demonstration of something that can be done better, or at least differently, in Rust than in C++. Without concrete details, only worthless hype remains.
dimes 6y ago
Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefits of using Rust over C++ for game development are unclear in these regards.
- gameswithgo 6y ago
  Rust over C++ for single player games is definitely of questionable benefit right now. For multiplayer games I think a much more compelling case can be made, certainly on the server if not both server and client.
- gtaylor 6y ago
  What makes games more likely to lean on global state than other kinds of applications?
  - Animats 6y ago
    Classic webcrap is near-stateless, with state in the database only. That way, any server in the farm can handle the next client request. Games have a consistent world to maintain in memory. Sometimes a really big consistent world.
    - moth-fuzz 6y ago
      I feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless. But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.
jeff-davis 6y ago
I have never made a serious attempt to develop a game, but it has always seemed to me like a problem that inherently breaks a lot of software engineering concepts. A lot of what makes games fun are the exceptions to the rules. An extra game mechanic in a special circumstance that allows you to do something that the basic rules don't. Or just a mechanic that stops something un-fun from happening (getting stuck, or it being too easy to trick an enemy). But clean code always follows the rules, and makes it harder to introduce special cases. I'm not saying software engineering has no place in a game, nor that rust would be bad it it. Just that it's less clear how software engineering will help a game, or if the game will be nudged toward a different style by the language somehow.
axegon_ 6y ago
Full disclosure: game development beyond the cli-based games and some simple asteroids-like games are the most I've ever done with games. I find them incredibly boring, both to make and play(kind of ironic considering up untilrecently I was working as a developer for a company that made games and I worked there for 8 and a half years). But 3 weeks ago I switched jobs and I am using rust in my current workplace, again, not for gaming but for data processing. I have no idea if rust will ever go deep inside the game development business but if it does, I feel like it will be in the very distant future. The main problem being the limited ecosystem compared to the big players. I do however believe it has the potential to give C++ a run for it's money should the ecosystem ever catch up. For starters it sits on top of llvm, so out of the box you have windows, linux, mac, ios and android covered and the tooling is the most batteries-included beast I've ever seen(namely cargo). I guess only time will tell but my bet is it won't happen in the next 5-10 years.
- adamnemecek 6y ago
  Rust is progressing at a faster pace than C++.
  - axegon_ 6y ago
    Indeed, but that's also it's Achilles' heel at this point: it is progressing incredibly fast and most people will have a second thought about using something that might change drastically six months down the line. As I said I love rust and I'm incredibly happy to be using it on daily basis and the company has voted enough confidence in the project but if I were to start something on my own, I will most likely have this fact lurking at the back of my mind.
    - adamnemecek 6y ago
      Rust will not change drastically in the next six months. The ecosystem is moving fast.
na85 6y ago
When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future. By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just to avoid garbage collection. Plus, now that Mozilla has gutted the Rust team, one wonders what future Rust has, if any.
- tormeh 6y ago
  GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.
  - na85 6y ago
    >GC is a no-go, as it causes unacceptable frame-rate dips. Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.
    - pirocks 6y ago
      I play a lot of minecraft and GC related framerate issues are usually not a problem, but when they are a problem they can be quite annoying. You tune gc performance for your gameplay workload to a certain extent but obviously most players don't.
    - Scramblejams 6y ago
      Those games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.
      - pjmlp 6y ago
        Just like you have to avoid malloc() in C written games.
tormeh 6y ago
If you want to play a 3D, multiplayer, open source game written in Rust right now, check out Veloren: https://veloren.net/ https://veloren.net/
slezyr 6y ago
I don't think so. You need a load of libraries to make a simple 3D: Model loader(Assimp), some GUI(imgui), input/window manager(glfw/SDL), image loader(OpenImageIO), animation engine(OZZ Animation), some interface to the GPU API like OpenGL/Vulkan(bgfx), physics engine(Bullet Physics), sound library, etc. Rust is not even on the table even in the future.
jeff-davis 6y ago
"It's also garnered interest up and down the entire stack, from bare-metal microcontrollers to web applications deployed via web assembly" This is, by far, the most credible argument in the piece. Access and tooling for new platforms is a critical factor for games.
Animats 6y ago
I'm ambivalent on this. Right now, I'm writing something 3D game related. It needs considerable parallelism. The existing tool in this area is mostly single threaded, it's a mess internally, and everyone who looks at it is scared to try to parallelize it. So I'm writing in Rust. Safe concurrency is a plus. There are some other wins. You can be bolder about not copying things. When decoding an incoming packet with a lot of structure, I'm creating linked data structures where most of the big byte array stuff is borrowed from a packet buffer that went into the structure creator. No allocations; it's all on stack. There's no risk of someone using an item from one of those structures and keeping a reference to data that's going to go away. Wouldn't dare do that in C++. I get along with the borrow checker just fine. Once you realize that single ownership is a tree, it makes sense. It's the type inference system that causes headaches. Rust has type inference in both directions. There are places where the result type influences what goes in. When the inference system guesses right, it's great. When it can't solve the problem on its own, trying to figure out what it wants is annoying. Go and C++ only have forward type inference; result types are computed by the compiler. Rust is really a single assignment language, not a functional one. There's a lot of "let foo =", and not much "let mut foo =". After a while, you get the idea that if you write "let mut", you're doing it wrong. Single assignment has most of the benefits of functional, but without multi-line expressions that go on to infinity. Plus you're not limited to a tree of results; you can have directed acyclic graphs, because you can usually re-use the value from a "let". The type of error objects is still a mess. Rust needs something like Python's exception type hierarchy and a consistent way to convert special error types into more general ones. I notice there's a Rust working group on error handling, again. Rust needs a good book. Not "The Rust Programming Language". That's too hard for an introductory book and not detailed enough for a reference manual. A book by someone who didn't develop the language is needed. The library situation has improved quite a bit since the last time I tried Rust, a few years ago. Back then, finding a library to do HTTP was "No, the one you're using is obsolete, use ...". Now I'm finding usable libraries for obscure things like analyzing files from "tcpdump". They missed a chance on something important to 3D work. Each library which uses 3D vectors has its own structure for them. There's a proposal for a common format, "mint", but it's not getting traction. This is an old headache in 3D programs with components from different sources. Back when I was developing ragdoll physics, I had four 3D vector types in one C++ program.
thom 6y ago
Realistically, do current practices even work for game development? Obviously many games are wildly profitable, but the amount of human suffering and crunch time that goes into the release of an AAA title, and indeed into its day zero multi-gigabyte patch to make it actually playable, seems to imply that we should at least be open minded. But also I suspect many of the issues aren't just your choice of language.
- iphorde 6y ago
  Crunch time has nothing to do with the language. We're not fighting the language. We're fighting last minute requirements, design changes, etc. My favorite that always happens, a complete change to the UI. I've never been on a project were it didn't happen.
jokoon 6y ago
Sorry, but the learning curve of a programming language matters a lot. It's already hard enough for people to read and write code, so to learn another hard language like rust is not something you do lightly. Rust is a cool language, but it's a cool tool, nothing more. I'd rather see the ownership process implemented in some C/C++ dialect. I'm not entirely sure, but I think that C++ concepts, in a way, have the same goals than ownership. Safety doesn't always matter. It matters for a company like Mozilla and anything that's network/system related, that's for sure, but for games, I'm not so sure. Also, statically typed languages that compiles to machine code are a niche now, new languages in that area don't really matter. You either have kernel code, or interpreted languages. A big quantity of C/C++ userspace code is fossilized code. Computers are quite fast for a lot of interpreted languages.
- shrimp_emoji 6y ago
  I think Rust is actually much easier to use than C/C++. Sure, the borrow checker can be a pain, but the tooling and design is light years ahead. Moreover, C++ is actually one of the most difficult languages to use.
  - iphorde 6y ago
    "C++ is actually one of the most difficult languages to use" That is your opinion, and one shown time and time again is not true.
- pjmlp 6y ago
  > I'd rather see the ownership process implemented in some C/C++ dialect. Here you go, https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Implementing_the_C++_Core_Guidelines_Lifetime.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl... https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...
stunt 6y ago
It really depends on which part of "Game Development" you are talking about. What most of the people agree is that Rust can deliver value to the core and to the performance focused components in the game engine. I assume that's what this article is talking about too. But beyond that it's hard to see it eating the market in other areas. You really want to have some easy to find average coders that can pretty much script your game on top of an engine and framework, and you don't want to spend way too much on them. It could be a different story for some multiplayer AAA games since they have enough lifetime to become mature and start to take every optimization opportunity.
k__ 6y ago
Rust is in an interesting place right now. It's something that can compete with C/C++, but has a community as good as Ruby. No other programming language has both. With the diaspora of Rust engineers from Mozilla, I'd guess things only to improve even further.
- dxuh 6y ago
  I think Rust is actually pretty cool and I have tried it myself for a few small things, but it's definitely the most obnoxious programming language community out there (which does not mean, at all, that everyone that is a part of that community is obnoxious). Remember that "Rewrite it in rust" is a meme.
  - k__ 6y ago
    Rewrite it in JS was a meme too, so what? I really liked the community chat of Rust. For all beginner questions there is someone standing by to answer it in under 10 minutes. Sure, Rust is hard but having people explain everything to you in a chat when you're stuck is worth gold.
skadamat 6y ago
I'm more skeptical to be honest. Jonathan Blow discusses the unique programming & design challenges that most (not all) video games face in this great podcast episode: https://oxide.computer/podcast/on-the-metal-9-jonathan-blow/ https://oxide.computer/podcast/on-the-metal-9-jonathan-blow/
- polytely 6y ago
  This is such a good episode, would highly recommend this to any hackernews reader.
iphorde 6y ago
Yea, don't count on it. I spent 3 months getting a game up on Ogre3D, and no thank you. I'll stick with C++.
- sgift 6y ago
  Ogre3d is written in C++? What do you want to tell us?
  - iphorde 6y ago
    Crating is horrible. How about that to start with. String -> Str() -> String. Macros? Really Macros? Bindgen doesn't work, exceptions are not handled properly, creating a thin layer between Rust and Ogre3D was seriously inconvienant. I heard all of the hype, and I completely fell for it. This is not a language for game developers (35 years experience in game development here). Oh, how about some simple data structures you need. Like developing dynamic graphs with pointers needed to and fro. What a serious PIA.
blackrock 6y ago
I can’t imagine programmers wanting to use Rust for games development, especially when there are plenty of alternative languages. And remember that Rust must go through an LLVM layer. Instead, what about Nim? Any hopes for this language to become a mainstream games programming language instead? Since it does transpile down to C code.
smokey_circles 6y ago
Wonderfully written, completely baseless. Not meant as a criticism of Rust, but you will unseat COBOL from the finance sector LONG before you get the gaming houses onto rust. Not impossible, highly improbable though
jonnypotty 6y ago
I suggest this person writes a game in rust and then writes this article, otherwise what's the point? Is the main issue in game development memory safety? Cos if it isn't then why would rust be better? Whenever I see people programming in rust they are usually having to work around the borrow checker, which arguably makes them reason in a better way about their programs and also arguably wastes loads of their time doing something they know is correct but the rust compiler can't reason about. I don't think rust has "fixed" reliability or performance issues in Firefox has it?
rafaelvasco 6y ago
> The performance of C++ with the convenience of C# Convenience is a relative term. Convenience to what ? Personally, I find that far from the truth. Rust is very powerful, offers lots of flexibility in memory managing and allocation, which makes a difference in gamedev, but overall it's far slower to code in, because of that. And that is very bad for gamedev, in which fast iteration times is crucial. You code something, test it. Scratch it. Fix it. Test it. And so on.

157 points by adamnemecek 6y ago

> Way back around 2010, Mozilla was frustrated by the state of development in Firefox, a massive software project written mostly in C++. Despite best practices > Even so, manual memory manipulation is easy to get wrong, Even predating C++11, you should not have been doing manual memory management. I don’t think Mozilla was following best practices. IIRC, there were pointers everywhere. Even before C++11 best practices for C++ were to try for value semantics as much as possible. Mozilla code base was more like C with Classes than best practice C++.

klodolph 6y ago
I think the criticism, “But you were writing C++ wrong” falls more than a little flat. The Firefox codebase may be old, but even with teams of good, experienced C++ programmers I still see memory errors of the type that Rust is designed to prevent. Anyway, you are unlikely to avoid pointers completely in a good C++ codebase. Value semantics are very often the wrong semantics for the code you are trying to write. You can end up with dangling references as easily as you can end up with dangling pointers. If you use std::shared_ptr everywhere, then what you have is a slow & inefficient GC.
lostcolony 6y ago
So what in the language prevented them from doing it that way? What in the community ensured they didn't do it that way? Firefox is open source, and yet it still happened. "Best practices" is such a red herring. Best practices = don't write bugs, too; yet there are bugs. You can't evaluate a language in theory and ignore what happens in practice any more than you can with any other thing in life. It's the UX, does it do what users expect it to do, and is that the lowest friction path possible to achieve the goal. "You're not following best practices" is basically "you're holding it wrong". While arguably true, it is an attempt to excuse a bad design decision or impedance mismatch.
- dxuh 6y ago
  > "Best practices = don't write bugs" That's absolutely not what it means. Best practices usually means "don't use these features anymore" and "use these features whenever you can". And that is very reasonable and DOES get rid of a lot of the problems (not all) that are usually associated with C++, but still people don't do it. I blame it many C++-people actually preferring "C with classes" (various code bases openly prefers this as their coding style - you won't get those people on the Rust train either) and many people just don't know or don't trust it, because some of the newer features are sadly not very easy to understand properly.
  - lostcolony 6y ago
    You clearly missed the facetious tone of that part, along with the entire rest of the post. So let me simplify - if to use a language correctly requires knowing the full history of the language, along with explicitly eschewing some of the key features of the language (except in certain cases when you need them! And they're not deprecated or issue warnings or similar by the compiler), and even extremely experienced developers using the language still make mistakes...the issue is with the language.
sgift 6y ago
This is not a theoretical problem, it has been researched and the results are not encouraging even for "modern" C++. Either some of the biggest software companies (Mozilla, Microsoft, Google) are all incompetent or there is a problem with C++ in the real world which still hasn't changed despite "you only need to follow best practices in C++".

Thaxll 6y ago

Let me tell you that most C++ game dev never heard of Rust, so imagine how long it's going to take for Rust to be something usable in that domain? Right now in the real world of AAA games it is nowhere, it's not even a consideration so calling it "Rust Is the Future of Game Development" right ... For those who don't work in games, the tech there move very slowly, it's not your typical SV "let's use the latest fun and cutting edge tech".

sharpercoder 6y ago
That's a great argument on why it is not present but the future instead.
- emteycz 6y ago
  And also a great opportunity!
- 0-_-0 6y ago
  These are not the only 2 options
an_opabinia 6y ago
Probably because what AAA game developers actually use is strictly Visual Studio, not C++. Whatever is first class for GUI users on Windows in China and Ukraine is going to impact AAA game development far more than any non-GUI technology. It's not really about tooling. I'm not saying tools. Just Visual Studio. Visual Studio decides what will appear.
- malkia 6y ago
  Ditto. Also your debugger of choice (Windows again). I can debug C#/C++ in one app (or other .NET language). It's bit of pain for anything else (granted, Rust, I'm told should be good). Then you have the build process, vendorizing your packages (so you don't fetch them off internet), etc. Right now .sln files and MSBuild rule there (like it or not).
Supermancho 6y ago

02020202 6y ago

...or jai :)

Google234 6y ago

What a humorous title. Looking forward to the Rust Evangelism Strikeforce presence in this thread. Anyway, just say they don’t downvote and flag me into oblivion: Rust good c++ bad

lstodd 6y ago

Let me tell you that the future of game development is in developing games, and any particular language has nothing to do with it. Does anyone care what language were any particular games that keep being replayed or remembered fondly? No. Never.

Pfhreak 6y ago
I agree with you, but there are plenty of poorly educated gamers who think that 'developed in Unity' or Gamemaker means the game can't possibly be good. (All evidence to the contrary.)
- emsy 6y ago
  I have heard complaints about Unity games performing badly, which, for a lot of games, is actually the case.
St_Alfonzo 6y ago
Minecraft is a good example where people talk about the programming language. The portability of Java was a benefit for both Server and Client. But it was also critized because of the inefficiency of Java. I dont know if all this would have been better in Rust or other languages.
- bigbubba 6y ago
  Microsoft now has a second parallel implementation of Minecraft in C++. They've ported this to numerous platforms, but notably not MacOS or Linux desktops. (It's also substantially faster, but comparing it to Java edition is sort of unfair because there are a myriad of differences between the two in game mechanics, with many of the differences probably being relevant to performance.)
- gmueckl 6y ago
  I don't know for certain, but Java might be one of the reasons for Minecraft being as good as it is as a game. The comparatively minimalistic high level nature of that language leaves few possibilities to get lost in system level optimizations. And iterating in Java is a lot quicker than in C++ or Rust. It is an environment that helps focussing on game logic.

bigbubba 6y ago

I haven't worked in the games industry so please correct me if I'm wrong, but isn't game development culture one of rushing crude hacks out the door at the last minute? Rust seems like a poor 'culture fit' in this regard.

macspoofing 6y ago
>Rust seems like a poor 'culture fit' in this regard. How would Rust prevent "rushing crude hacks out the door at the last minute"?
- bigbubba 6y ago
  Doesn't the borrow checker ask programmers to be a bit less crude and hacky? I thought that was the point.
- throw_m239339 6y ago
  > How would Rust prevent "rushing crude hacks out the door at the last minute"? Because game developers would be fighting the borrow checker instead of shipping leaky code that compiles without hurdle?
sgift 6y ago
From what I can gather (from the outside) this has changed over the years. Games are not monoliths anymore and some parts have to work for successors or other games based on the same tools, so "things work for more than the bare minimum" has become more important over time. I'm sure there's still more than enough throwaway code, but that is probably not done in C++ currently either, but in some kind of scripting language.
Scramblejams 6y ago
Common game industry joke: Q: What does a game company call a teetering tower of ugly hacks on top of ugly hacks? A: Shipped! Source: 5 years in the games business. The game development process can get messy. My studio doesn't crunch, but elsewhere crunch is the norm, and does anyone think the code is gonna stay beautiful during endless crunch? The old-timers here all have their war stories they tell of last minute ugly hacks tossed in just to get a game out the door on time.

walkingolof 6y ago

For 95% of all game developer the future is a engine like Unreal or Unity and your scripting language of choice. The rest, triple A titles and engine developers may chose something else, but the inertia of C/C++ will make that a very long process.

bluedino 6y ago
The future - the next big game engine, being planned out or written right now, might be done in rust.
- mrnothing_123 6y ago
  alot of critical parts of a game engine are already made in c or c++, and mono(the default stand for closs plataform for not engine user is not compatible whit rust)

jayd16 6y ago

I think Rust would eat into C++ more than C#. Microsoft is pushing C# and the tooling fairly hard right now. Performance is pretty good and even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. I don't think the population of studios that chose C#'s performance and convenience over C++ but would now choose Rust is all that large. But hey, lets start talking about bindings. We could be changing all these C#/C++ engines into C#/Rust engines.

suprfnk 6y ago
> even though Rust seems like a rising star, it won't reach C# levels of tooling for quite some time. Just curious; what's the tooling gap between Rust and C#, according to you? I work in C# profesionally, and dabble in Rust, and haven't really found Rust tooling lacking yet -- but maybe that's because I'm only working on small hobby projects.
- pjmlp 6y ago
  Try to do something like WinUI in Rust, or debug a mixed code base like in C# and C++ on Studio.
- lostmsu 6y ago
  Aren't you using refactoring tools like ReSharper? Also, what about debugging? C# does edit & continue and allows arbitrary statement execution during debugging. Does Rust debugger even allow moving the instruction pointer at will?
Iwan-Zotow 6y ago
Not in a game business, but I could tell you - until Rust is supported (down to debugging) in Visual Studio, there would be no C#/Rust apps, and plenty C#/C++ apps.
- halvnykterist 6y ago
  Debugging in VS actually works pretty well already, the msvc target generates PDB files. It's what I use when need to attach a debugger to something. Actual language support would be really nice, though. Hopefully MS are already working on this.

Pfhreak 6y ago

The future of Game Development is about democratization of tools. With tools like Unity, GameMaker, and RPG maker it has become easier and easier for anyone to make a game. While Rust might be a good foundation for some performance critical code, I'd hardly say it's the "Future of Game Development". Already, games use tools like Blueprints in Unreal to make games with limited to no coding experience, and I expect those tools will continue to get better and better over time.

centimeter 6y ago
Not directly relevant, but the use of the phrase “democratization” to describe a process that has nothing whatsoever to do with democracy (“anarchization”?) has become a pet peeve of mine.
- taeric 6y ago
  I'm assuming it means getting public involvement? Getting people to participate in the process. That said, I do feel most of the examples are not that. The old shareware scene was much closer to the spirit. Now that we are pushing winners only, feels more like corporate control than it does people control. :(
  - Pfhreak 6y ago
    Go visit http://itch.io/ http://itch.io/ and search around for a bit. There are thousands of games to explore here made by people from all walks of life. Most of these will see zero to minor financial success, but people are still making them because they are inspired to share some experience. Even on the major platforms, you'll find stuff like Umurangi Generation, a game about taking photographs in a surreal autocratic environment. That game is not a 'winner only', but it's fascinating and only exists because people who want to make that experience had access to tools they could understand and use. Democratic processes and tools are tools that are widely available to the public. It's not only AAA studios making games, everyone around the world is making games.
    - 6y ago

klodolph 6y ago

I think a number of companies, like mine, are working with Rust internally. But articles like these don’t provide any insight into those efforts, which are kept private. Game development at large-scale is a mix of systems programming of the kind that Rust excels at and gameplay logic programming which has loose performance requirements and may be written by people who are not primarily coders. So you see a lot of codebases split between two languages, like a C++ core with Lua bindings or something like that. If we see Rust adoption here I’m expecting it to be from a kind of skunkworks inside the company replacing specific, carefully-chosen systems with Rust code. At my company, that’s how it’s done, and it’s a very slow process. (I don’t work in the game industry, so all I hear is rumors from people that used to work in the game industry.)

haunter 6y ago

The future is game development is GaaS and putting as much as p2w/gacha elements into the title as much as you can get away with it (on top of selling the game for $70)

p0nce 6y ago

Rust builds slower than C++.

adamnemecek 6y ago
But rebuilding seems faster since the Rust Compiler is smarter about caching things. I think that the way the Rust module system works also makes things faster.
mlindner 6y ago
Not really, especially if you use a lot of templated code.
- pjmlp 6y ago
  Really, specially if you don't use binary libraries.

macspoofing 6y ago

Is it though? I feel like most people compare Rust to C++98 and if you do that, certainly Rust looks really good. The benefits of Rust compared to, say, C++17 are not as pronounced.

FartyMcFarter 6y ago
It's still quite easy to shoot oneself in the foot with modern C++: #include <string_view> #include <string> #include <iostream> int main() { std::string_view v = std::string("xyz"); std::cout << v << '\n'; }
- rhodysurf 6y ago
  OK i'll bite. What's wrong with this? It functions as expected or am I missing something. Edit: NVM, for those wondering the std::string constructor copies the string when it doesnt have to. But the solution here is to just initialize the string_view with the char data instead of the std::string instance Edit: Ignore me see below
  - steveklabnik 6y ago
    Isn't it a use-after free? (I haven't had time to compile and run it) You have a temporary std::string, pointed to by a string_view, which means that it's freed, and the view is dangling, and then used when printing things out.
    - rhodysurf 6y ago
      So thats what I initially thought but then I ran it and it works so IDK anything anymore.
      - steveklabnik 6y ago
        UB can do anything, including something that seems like it works. Just because the memory has been deallocated doesn't mean that the bytes there were changed. The pointer may still point to them, and it may still "work."

nayuki 6y ago

This is a repost of https://news.ycombinator.com/item?id=25033247 https://news.ycombinator.com/item?id=25033247 (7 hours earlier)

whateveracct 6y ago

Personally, I'm betting on Haskell - for indie dev in particular where I want to manage huge amounts of complexity as an individual. This is partially because I've been programming Haskell professionally for 5+ years so I'm over the learning curve and well into the realm of efficiency gains. The GHC RTS is akin to the Lua layer and handles all the high-level logic. For storage and compute-intensive things, we can drop to lower-level primitives for performance and then easily hook into them in our scripting layer. I wouldn't be surprised if fleshing out this domain hints at future useful GHC extensions as well. I like Rust a lot, but I honestly think the ability to do highly-abstract programming is worth having to deal with a non-literal compilation pipeline. For gamedev at least. I honestly think it will be astounding what scale of game a single developer will be able to build in Haskell in 3-5 years once all the pioneering is out of the way. Programming a game the size Blasphemous could easily be managed by a single Haskeller I'm pretty sure - leaving resources to focus on art, sound, and storytelling. And that's an easy call - it'll be fun to see just how big and complicated of game logic we can make cheap thanks to good abstractions.

cylon13 6y ago
One of the problems with Haskell for game development is, because of the novelty of lazy evaluation, it's very difficult to learn what causes space leaks, and it's difficult to learn how to debug them. If you're already an expert in Haskell this might not seem like a big deal, but it certainly makes adoption a lot harder. Another related issue is the level of abstraction is so high that it makes it harder to be extremely optimal with memory usage and access, which is something game developers love doing, even sometimes when they don't strictly have to. I love programming in Haskell, but I'm highly suspect that it will ever be a widely used game programming language. It's very good at expressing computations in the abstract at the expense of being good at telling a physical computer exactly what to do. Game programmers tend to prefer languages that fall in the latter category in my experience.
- whateveracct 6y ago
  Yeah I agree it'll never be mainstream for gamedev. Haskell is not really built to have runaway adoption. It's a strength as much as it's a weakness. But I think it'll allow me to be insanely efficient as a gamedev. So I'm a Haskeller-turned-gamedev. Not a gamedev-turned-Haskeller. Haskell performance and memory usage is kind of like JVM programming. You need a mental model of how GHC and its RTS & GC operate. Having frame-oriented code honestly makes it easier to reason about. We Do need more learning materials about this stuff, but first we need more experience! But idt it's any different than using GC for gamedev. And manual memory management is well within Haskell's capabilities. Haskell profiling IME makes space leaks very obvious. That's a too-common paper cut, but once you get cut once you don't make the mistake again :)

andrewmcwatters 6y ago

This article doesn't actually talk about "Why Rust Is the Future of Game Development." You could have taken out the game development piece, and it still doesn't talk about "Why Rust Is the Future of Development," more than talking about Rust features themselves. I should be able to complete the sentence, "Rust is the future of game development because...," but I can't in any meaningful way. Here are the highlights of the article, instead: Rust is the future of game development because Rust has the performance of C++ with the convenience of C#. Rust is the future of game development because Rust has ownership based memory. Rust is the future of game development because Rust is popular. (The article doesn't say this explicitly, but implies it is.) Rust is the future of game development because Rust is still an immature language. (This doesn't actually sell the point, and I'm not sure why the author bothers talking about this.) What's weird, too, is that the article talks about how hard networking is, but _cart has specifically said in the past, "Yup! High level and low level networking is definitely on our radar, but it also isn't our immediate priority." It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. We had modern client-side prediction roughly 20 years ago, and people still don't take multiplayer seriously.

AsyncAwait 6y ago
> It may come as a surprise, but you basically have to bake networking into the engine. It's not easy as an afterthought. Rust doesn't help with this. In fact, multiplayer and all its challenges have nothing to do with Rust. I think multiplayer is an area where you'd want "fearless concurrency". Rust could do well here.
- andrewmcwatters 6y ago
  Not really, a tremendous amount of game code doesn't benefit from multithreading. So, this also doesn't have anything to do with Rust. A better argument might be Rust and Vulcan, though. Even still, you can get very far with just using OpenGL.
  - 6y ago

adamnemecek 6y ago

If you re interested in Rust game dev, check out the rg3d engine https://github.com/mrDIMAS/rg3d https://github.com/mrDIMAS/rg3d. Join the rg3d discord channel https://discord.gg/xENF5Uh https://discord.gg/xENF5Uh

aphextron 6y ago

>Ownership based memory Is this not just ARC?

adamnemecek 6y ago
It is not, no, although you can choose to have some types to be Arc. By default the compiler can reason about whether a value is accessed mutably in only one place.
steveklabnik 6y ago
Fundamentally different. ARC involves reference counting, and so is a run-time strategy. Ownership in Rust is at compile-time, instead. Now, it is true that languages that use ARC can do compile-time analysis to remove some refcount traffic, and that you can use run-time ownership tracking in Rust if you'd like. The difference is what's built into the languages, what is the default vs what is not, and the kinds of patterns those tend to enable.

hvasilev 6y ago

Two weeks ago Rust was the future of embedded systems (it is not) and now it is the future of Game Development (it is not). I'm starting to think that people's opinion shouldn't be taken seriously unless they have like at least 20 years of experience in a particular field.

Iwan-Zotow 6y ago
Rust is the future of humanity!
adamnemecek 6y ago
I mean C and CPP are used in both fields so it's not hard to imagine that since Rust is trying to replace both languages, that it would become popular in the two fields as well.
- cylon13 6y ago
  You do usually find the C preprocessor where you find C, yes.
a-nikolaev 6y ago
Hey, Rust is the future of bitcoin and vice versa.
- SomeoneFromCA 6y ago
  Rust is future of self-driving cars.
cambalache 6y ago
The future is now young man : https://www.arewewebyet.org/ https://www.arewewebyet.org/ > Can I replace my Rails/Django/Flask already? > Yup! Rust has mature and production ready frameworks in Actix Web and Rocket, and newer ones like Warp and Tide. These provide everything you’d expect from a web framework, from routing and middleware, to templating, and JSON/form handling. There are crates for everything, and more! I would pay for a reality show where a big Rails application needs to be replaced by Rust by the same engineers who built it.

HelloNurse 6y ago

The article sorely misses code examples: any demonstration of something that can be done better, or at least differently, in Rust than in C++. Without concrete details, only worthless hype remains.

dimes 6y ago

Having tried writing a game engine in Rust, I can't imagine that Rust would become the future of game development. Lack of safety is a feature in game development, because the optimizations required are typically unorthodox and a super strict language slows development down. Additionally, object ownership can be unclear in a game development setting, which typically makes use of global variables for state. The benefits of using Rust over C++ for game development are unclear in these regards.

gameswithgo 6y ago
Rust over C++ for single player games is definitely of questionable benefit right now. For multiplayer games I think a much more compelling case can be made, certainly on the server if not both server and client.
gtaylor 6y ago
What makes games more likely to lean on global state than other kinds of applications?
- Animats 6y ago
  Classic webcrap is near-stateless, with state in the database only. That way, any server in the farm can handle the next client request. Games have a consistent world to maintain in memory. Sometimes a really big consistent world.
  - moth-fuzz 6y ago
    I feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless. But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.

jeff-davis 6y ago

I have never made a serious attempt to develop a game, but it has always seemed to me like a problem that inherently breaks a lot of software engineering concepts. A lot of what makes games fun are the exceptions to the rules. An extra game mechanic in a special circumstance that allows you to do something that the basic rules don't. Or just a mechanic that stops something un-fun from happening (getting stuck, or it being too easy to trick an enemy). But clean code always follows the rules, and makes it harder to introduce special cases. I'm not saying software engineering has no place in a game, nor that rust would be bad it it. Just that it's less clear how software engineering will help a game, or if the game will be nudged toward a different style by the language somehow.

axegon_ 6y ago

Full disclosure: game development beyond the cli-based games and some simple asteroids-like games are the most I've ever done with games. I find them incredibly boring, both to make and play(kind of ironic considering up untilrecently I was working as a developer for a company that made games and I worked there for 8 and a half years). But 3 weeks ago I switched jobs and I am using rust in my current workplace, again, not for gaming but for data processing. I have no idea if rust will ever go deep inside the game development business but if it does, I feel like it will be in the very distant future. The main problem being the limited ecosystem compared to the big players. I do however believe it has the potential to give C++ a run for it's money should the ecosystem ever catch up. For starters it sits on top of llvm, so out of the box you have windows, linux, mac, ios and android covered and the tooling is the most batteries-included beast I've ever seen(namely cargo). I guess only time will tell but my bet is it won't happen in the next 5-10 years.

adamnemecek 6y ago
Rust is progressing at a faster pace than C++.
- axegon_ 6y ago
  Indeed, but that's also it's Achilles' heel at this point: it is progressing incredibly fast and most people will have a second thought about using something that might change drastically six months down the line. As I said I love rust and I'm incredibly happy to be using it on daily basis and the company has voted enough confidence in the project but if I were to start something on my own, I will most likely have this fact lurking at the back of my mind.
  - adamnemecek 6y ago
    Rust will not change drastically in the next six months. The ecosystem is moving fast.

na85 6y ago

When discussing games, where players demand excellent performance but are tolerant of initial startup times (i.e. launching the game from Steam or the Start Menu) being long, then I question why Java isn't the future. By all accounts Java has the most sophisticated runtime out there, it has all the safety features of Rust without fucking around with the borrow checker which seems like a huge piece of complexity just to avoid garbage collection. Plus, now that Mozilla has gutted the Rust team, one wonders what future Rust has, if any.

tormeh 6y ago
GC is a no-go, as it causes unacceptable frame-rate dips. The kind of people who buy 120Hz screens are unlikely to be impressed. Even Shenandoah etc. are very unlikely to fix that.
- na85 6y ago
  >GC is a no-go, as it causes unacceptable frame-rate dips. Does it, though? I've played titles written in Java and achieved smooth 60 fps back in 2008.
  - pirocks 6y ago
    I play a lot of minecraft and GC related framerate issues are usually not a problem, but when they are a problem they can be quite annoying. You tune gc performance for your gameplay workload to a certain extent but obviously most players don't.
  - Scramblejams 6y ago
    Those games will have been written in such a way as to avoid allocations like the plague, giving the GC very little to do. Sometimes your game can be written that way -- sometimes it can't.
    - pjmlp 6y ago
      Just like you have to avoid malloc() in C written games.

tormeh 6y ago

If you want to play a 3D, multiplayer, open source game written in Rust right now, check out Veloren: https://veloren.net/ https://veloren.net/

slezyr 6y ago

I don't think so. You need a load of libraries to make a simple 3D: Model loader(Assimp), some GUI(imgui), input/window manager(glfw/SDL), image loader(OpenImageIO), animation engine(OZZ Animation), some interface to the GPU API like OpenGL/Vulkan(bgfx), physics engine(Bullet Physics), sound library, etc. Rust is not even on the table even in the future.

jeff-davis 6y ago

"It's also garnered interest up and down the entire stack, from bare-metal microcontrollers to web applications deployed via web assembly" This is, by far, the most credible argument in the piece. Access and tooling for new platforms is a critical factor for games.

Animats 6y ago

I'm ambivalent on this. Right now, I'm writing something 3D game related. It needs considerable parallelism. The existing tool in this area is mostly single threaded, it's a mess internally, and everyone who looks at it is scared to try to parallelize it. So I'm writing in Rust. Safe concurrency is a plus. There are some other wins. You can be bolder about not copying things. When decoding an incoming packet with a lot of structure, I'm creating linked data structures where most of the big byte array stuff is borrowed from a packet buffer that went into the structure creator. No allocations; it's all on stack. There's no risk of someone using an item from one of those structures and keeping a reference to data that's going to go away. Wouldn't dare do that in C++. I get along with the borrow checker just fine. Once you realize that single ownership is a tree, it makes sense. It's the type inference system that causes headaches. Rust has type inference in both directions. There are places where the result type influences what goes in. When the inference system guesses right, it's great. When it can't solve the problem on its own, trying to figure out what it wants is annoying. Go and C++ only have forward type inference; result types are computed by the compiler. Rust is really a single assignment language, not a functional one. There's a lot of "let foo =", and not much "let mut foo =". After a while, you get the idea that if you write "let mut", you're doing it wrong. Single assignment has most of the benefits of functional, but without multi-line expressions that go on to infinity. Plus you're not limited to a tree of results; you can have directed acyclic graphs, because you can usually re-use the value from a "let". The type of error objects is still a mess. Rust needs something like Python's exception type hierarchy and a consistent way to convert special error types into more general ones. I notice there's a Rust working group on error handling, again. Rust needs a good book. Not "The Rust Programming Language". That's too hard for an introductory book and not detailed enough for a reference manual. A book by someone who didn't develop the language is needed. The library situation has improved quite a bit since the last time I tried Rust, a few years ago. Back then, finding a library to do HTTP was "No, the one you're using is obsolete, use ...". Now I'm finding usable libraries for obscure things like analyzing files from "tcpdump". They missed a chance on something important to 3D work. Each library which uses 3D vectors has its own structure for them. There's a proposal for a common format, "mint", but it's not getting traction. This is an old headache in 3D programs with components from different sources. Back when I was developing ragdoll physics, I had four 3D vector types in one C++ program.

thom 6y ago

Realistically, do current practices even work for game development? Obviously many games are wildly profitable, but the amount of human suffering and crunch time that goes into the release of an AAA title, and indeed into its day zero multi-gigabyte patch to make it actually playable, seems to imply that we should at least be open minded. But also I suspect many of the issues aren't just your choice of language.

iphorde 6y ago
Crunch time has nothing to do with the language. We're not fighting the language. We're fighting last minute requirements, design changes, etc. My favorite that always happens, a complete change to the UI. I've never been on a project were it didn't happen.

jokoon 6y ago

Sorry, but the learning curve of a programming language matters a lot. It's already hard enough for people to read and write code, so to learn another hard language like rust is not something you do lightly. Rust is a cool language, but it's a cool tool, nothing more. I'd rather see the ownership process implemented in some C/C++ dialect. I'm not entirely sure, but I think that C++ concepts, in a way, have the same goals than ownership. Safety doesn't always matter. It matters for a company like Mozilla and anything that's network/system related, that's for sure, but for games, I'm not so sure. Also, statically typed languages that compiles to machine code are a niche now, new languages in that area don't really matter. You either have kernel code, or interpreted languages. A big quantity of C/C++ userspace code is fossilized code. Computers are quite fast for a lot of interpreted languages.

shrimp_emoji 6y ago
I think Rust is actually much easier to use than C/C++. Sure, the borrow checker can be a pain, but the tooling and design is light years ahead. Moreover, C++ is actually one of the most difficult languages to use.
- iphorde 6y ago
  "C++ is actually one of the most difficult languages to use" That is your opinion, and one shown time and time again is not true.
pjmlp 6y ago
> I'd rather see the ownership process implemented in some C/C++ dialect. Here you go, https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Implementing_the_C++_Core_Guidelines_Lifetime.pdf https://llvm.org/devmtg/2019-04/slides/TechTalk-Horvath-Impl... https://devblogs.microsoft.com/cppblog/lifetime-profile-update-in-visual-studio-2019-preview-2/ https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

stunt 6y ago

It really depends on which part of "Game Development" you are talking about. What most of the people agree is that Rust can deliver value to the core and to the performance focused components in the game engine. I assume that's what this article is talking about too. But beyond that it's hard to see it eating the market in other areas. You really want to have some easy to find average coders that can pretty much script your game on top of an engine and framework, and you don't want to spend way too much on them. It could be a different story for some multiplayer AAA games since they have enough lifetime to become mature and start to take every optimization opportunity.

k__ 6y ago

Rust is in an interesting place right now. It's something that can compete with C/C++, but has a community as good as Ruby. No other programming language has both. With the diaspora of Rust engineers from Mozilla, I'd guess things only to improve even further.

dxuh 6y ago
I think Rust is actually pretty cool and I have tried it myself for a few small things, but it's definitely the most obnoxious programming language community out there (which does not mean, at all, that everyone that is a part of that community is obnoxious). Remember that "Rewrite it in rust" is a meme.
- k__ 6y ago
  Rewrite it in JS was a meme too, so what? I really liked the community chat of Rust. For all beginner questions there is someone standing by to answer it in under 10 minutes. Sure, Rust is hard but having people explain everything to you in a chat when you're stuck is worth gold.

skadamat 6y ago

I'm more skeptical to be honest. Jonathan Blow discusses the unique programming & design challenges that most (not all) video games face in this great podcast episode: https://oxide.computer/podcast/on-the-metal-9-jonathan-blow/ https://oxide.computer/podcast/on-the-metal-9-jonathan-blow/

polytely 6y ago
This is such a good episode, would highly recommend this to any hackernews reader.

iphorde 6y ago

Yea, don't count on it. I spent 3 months getting a game up on Ogre3D, and no thank you. I'll stick with C++.

sgift 6y ago
Ogre3d is written in C++? What do you want to tell us?
- iphorde 6y ago
  Crating is horrible. How about that to start with. String -> Str() -> String. Macros? Really Macros? Bindgen doesn't work, exceptions are not handled properly, creating a thin layer between Rust and Ogre3D was seriously inconvienant. I heard all of the hype, and I completely fell for it. This is not a language for game developers (35 years experience in game development here). Oh, how about some simple data structures you need. Like developing dynamic graphs with pointers needed to and fro. What a serious PIA.

blackrock 6y ago

I can’t imagine programmers wanting to use Rust for games development, especially when there are plenty of alternative languages. And remember that Rust must go through an LLVM layer. Instead, what about Nim? Any hopes for this language to become a mainstream games programming language instead? Since it does transpile down to C code.

smokey_circles 6y ago

Wonderfully written, completely baseless. Not meant as a criticism of Rust, but you will unseat COBOL from the finance sector LONG before you get the gaming houses onto rust. Not impossible, highly improbable though

jonnypotty 6y ago

I suggest this person writes a game in rust and then writes this article, otherwise what's the point? Is the main issue in game development memory safety? Cos if it isn't then why would rust be better? Whenever I see people programming in rust they are usually having to work around the borrow checker, which arguably makes them reason in a better way about their programs and also arguably wastes loads of their time doing something they know is correct but the rust compiler can't reason about. I don't think rust has "fixed" reliability or performance issues in Firefox has it?

rafaelvasco 6y ago

> The performance of C++ with the convenience of C# Convenience is a relative term. Convenience to what ? Personally, I find that far from the truth. Rust is very powerful, offers lots of flexibility in memory managing and allocation, which makes a difference in gamedev, but overall it's far slower to code in, because of that. And that is very bad for gamedev, in which fast iteration times is crucial. You code something, test it. Scratch it. Fix it. Test it. And so on.