That's a good article. He's right about many things.
I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust.
Notes:
* There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
* He's right about the pain of refactoring and the difficulties of interconnecting different parts of the program. It's quite common for some change to require extensive plumbing work. If the client that talks to the servers needs to talk to the 2D GUI, it has to queue an event.
* The rendering situation is almost adequate, but the stack isn't finished and reliable yet. The 2D GUI systems are weak and require too much code per dialog box.
* I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it.
* I have less trouble with compile times than he does, because the metaverse client has no built-in "gameplay". A metaverse client is more like a 3D web browser than a game.
All the objects and their behaviors come from the server.
I can edit my part of the world from inside the live world. If the color or behavior or model of something needs to be changed, that's not something that requires a client recompile.
The people using C# and Unity on the same problem are making much faster progress.
> I'd expected some AAA title to be written in Rust by now.
I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until the turn of the millenium, in the wake of Quake 3 (buoyed by the new features of C++98).
I really hope that C++ evolves with gamedev and they become more and more symbiotic.
Maybe adoption of rust by gamedev community isn't the best thing to wish to happen to language. Maybe it is better to let other crowd to steer evolution of rust, letting system programming and gamedev drift apart
I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems.
Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services.
Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf rust for small projects with tough performance guarantees - I haven't seen the “we manage 1-10 MM sloc of complex code using rust” type projects.
> and didn't become popular for gamedev until the turn of the millenium
Wasn't this also because Microsoft had terrible support for C?
Since the mid-90's, a number of gamedevs moved to C++ but were unhappy with the results.. how OOP works, exception handling, the STL, etc.
My understanding is.. by late 90's.. many game developers, despite using C++, we still coding more inline with C programming than (proper) C++.
Mostly C code but using some features of C++ like, functions inside a struct, or using namespaces, that did not sacrifice compilation and runtime speed.
Yeah, gaming industry has become mature enough to build up its own inertia so it will take some time for new technologies to take off. C# has become a mainstream gamedev language thanks to Unity, but this also took more than a decade.
Comparing the time it takes for a prog language to spread from the 80s to today is a bad vantage point. Stuff took much longer to bake back then -- but even so the point is moot, as other commentors pointed out, it took off roughly the same amount of time between 2015 and today.
The concept of AAA games didn't even exist back in 1985, very few people were developing games at that era, and even fewer were writing "complex" games that would need C++.
The SNES came on 1990 and even then it had it's own architecture and most games were written in pure assembly. The PlayStation had a MIPS CPU and was one of the first to popularize 3D graphics, the biggest complexity leap.
I believe your are seeing causation were only correlation should be given. C++ and more complex OOP languages just joined the scene when the games themselves became complex, because of hardware and market natural evolution
Many tried c++ in early 90s, but wasnt it too slow/memory intensive? You had to implement lots of inline c/assembly to have a bit of performance. Nowadays everything is heavily optimized, but back then not.
> I'd expected some AAA title to be written in Rust by now.
Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite.
I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn't even have support for animation blending yet (I landed that for 0.14).
It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed".
While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is true.
It seems like unless you are someone like John Carmack or most of Nintendo, game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It is a business after all.
"I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it."
100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on the whole crates for one async runtime are not even compatible with those of another, and so it's all really just about tokio.
Which sucks, if you're doing, y'know, systems programming or embedded (or games). Because tokio has no business in those domains.
It does in my domain of systems programming with async data handling. Tokio works like a dream - slipping into the background and just working so I can concentrate on the business logic.
> I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.
> I tend to agree about the "async contamination" problem.
Argh I have the same issue. Sure if you write JS or Python you probably need async. My current Java back end that has like 5 concurrent users does not need async everything making 10x the complexity.
> I'd expected some AAA titles to be written in Rust by now.
"AAA" titles are huge and/or high dev budgets. Even if a game is "starting from scratch" the engine development team are still likely taking code from previous projects to get started. Of course there are other factors. It could be a BIG RISK to move to another programming language when the team, despite frustrations, are already familiar with something else... like the perks C++ brings (you learn from trial-and-error)
Could you imagine learning Rust as-you-go... building a AAA title... and fighting the compiler? To me it is a huge risk!
That is my opinion.. but I am sure others will disagree. If there is anyone on (or did) a AAA title with Rust... I would be happy to hear more about it.
I am not saying it will never happen. Maybe a AAA title is currently in development in Rust. I honestly dont know. However, game developers... if they are looking into Rust... are also looking at Odin, Jai, or Zig. For gaming, I think they are better alternatives than Rust but (again) that is my opinion.
Now for smaller, indie games - the possibility of moving to Rust (or another language) is more likely. Likely a fair percentage have moved away from C++ now.
> * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
At one point the studio behind the Finals was writing game server code in Rust with an Unreal engine client. Not sure if that's true still
The studio you're talking about is Embark studios, and is openly pretty big on Rust [1]
I think it was rumored that their next project will use a Rust game engine, but I am not sure how it's going now.
> The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests.
Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?
A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale."
Putting aside that not all of use are building web applications (heterodox here in HN, I know)...
Most people in the real world with real applications will not hit the limits of what is possible and efficient and totally fine with thread-based architectures.
Plus the kernel has gotten more efficient with threads over the years.
Plus hardware has gotten way better, and better at handling concurrent access.
Plus async involves other trade-offs -- running a state machine behind the scenes that's doing the kinds of context switching the kernel & hardware already potentially does for threads, but in user space. If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.
That overhead is fine if you're sitting there blocking on your database server, or some HTTP socket, or some filesystem.
It's ... probably... not what you want if you're building a game or an operating system or an embedded device of some kind.
An additional problem with async in Rust right now is that it involves bringing in an async runtime, and giving it control over execution of async functions... but various things like thread spawning, channels, async locks, etc. are not standardized, and are specific per runtime. Which in the real world is always tokio.
So some piece of code you bring in in a crate, uses async, now you're having to fire up a tokio runtime. Even though you were potentially not building something that has anything to do with the kinds of things that tokio is targeted for ("scalable" network services.)
So even if you find an async runtime that's optimized in some other domain, etc (like glommio or smol or whatever) -- you're unlikely to even be able to use it with whatever famous upstream crate you want, which will have explicit dependencies into tokio.
There's a lot going on. Someone is doing a new third party viewer, Crystal Frost, in Unity. Linden Lab has a mobile viewer in alpha test. Rendering is PBR now for new objects. There are mirrors! Content upload is moving to glTF, to be compatible with everybody else.
Voice is switching from Vivox to WebRTC. Game controller support is in test. New users get better avatars. The dev staff is larger.
None of this is yet increasing Second Life usership much, but it remains the best metaverse around.
I thought the metaverse thing was going to be bigger. Meta spent so much money to produce so little.
As a game developer for about two decades, I've never considered Rust to be a good programming language choice.
My priorities are reasonable performances and the fastest iteration time possible.
Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games.
Compilation time is very important, but also a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.
We almost never have specifications, almost nothing is set until the game is done.
It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.
Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.
> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.
But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on.
C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.
I'm surprised no one has made such a language that is designed from the ground up to be used as such for rust. Nim/coffeescript come to mind, but they target non-rust languages. Lua would be close enough if it weren't so alien to everything people like about rust.
As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.
Often in the past Lua has been used and in my experience it's been quite nice. It's very easy to bind, there's some nice editors out there and the performance is decent.
There's some other game-specific scripting languages that have popped up (angelscript and wren come to mind but there's more). I've not used them in full production products though. Mostly just kicked the tires.
Now that I think about it though, it's been almost 6 years since I've worked on an engine with lua support. Mainly because in the last few years I've been working with unity or unreal.
| Go because the iteration and compile times are very fast
Safety is important and for certain applications, Rust is unrivaled.
But for games, like web apps, where time to market and innovation can be just as if not more important than being free of runtime errors, Go is more suited to rapid development than Rust on compile times alone.
Of course, the libraries and support for both aren't quite there yet, so at this point neither is well suited to game dev.
> Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#
If you're starting from scratch, then maybe. Having had to crash learn games dev (ex VFX systems person) Unity + c# is just so nice to use. most of the easiness of python, but with proper strict typing. (which you can turn off, if you want)
plus the wealth of documentation, its great. I imagine unreal is quite good in that regard too.
I had similar thoughts, about Rust being a good match for game engines but not games. Maybe it suggests Rust game engines might want to include an interpreter for some higher level language to actually do the gamedev in.
Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.
I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too.
There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.
> a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.
That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
(Whether Rust tooling is actually at a level to take advantage of that is another question)
> That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
I don't think this is true. Rust makes it easy to get the refactor right (generally speaking 100% right). But that's not what they're describing. They're describing where the ability to make the refactor fast, even if it doesn't work correctly (in the formal sense of correctly). That is to say, memory leaks and race conditions and all sorts of horrible nastiness may be tolerable during the dev process in exchange for trying out an idea more quickly.
This is, of course, significantly more work at the end to patch up all of the things you did, but if you don't have to do the full work on 99/100 iterations, or got to try out more iterations because of the quick turnaround time, that would be considered a win here.
Pretty much every compiled language with a static typesystem has that "large-scale refactoring support" though. That's not Rust's USP, on the contrary: a too strongly typed language can make refactoring actually harder than it needs be. The sweet spot is somewhere in the middle (where exactly is up for discussion of course).
>Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
To be fair, they need to be able to make large changes with confidence because what would be small changes in other languages tend to end up being very large changes in rust like languages.
> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.
Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase.
That game (currently) has 88% positive reviews on steam and a 77 metacritic score with over 15.5k people playing the game right now (according to steamcharts.com)
I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was experienced by even 1% of the users.
The criteria by which something is decided to mention in the patch notes is not always purely because the users care. Sometimes it's because the developers want to signal effort to user and/or upper management.
Maybe Mount and Blade was super boggy in the past and is still super buggy now so all the crashes fixed are just an indicator of how large the problem is for them and how bad the code still is. I dunno, you didn't really give any information to help on that front.
With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.
I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.
Photoshop does crash. Trust me if you do enough image editing you'll know it's not even a super rare event. They're generally doing a poor job handling the situations where you have no enough storage or RAM.
Hard to know what TaleWorlds are actually optimising for because half the features of Bannerlord feel like they’ve never been played by a dev let alone iterated on.
My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot.
My experience was instantly terrible. Slow compile times and iterations, huge package downloads (my project folder was roughly 1gb for a simple 2D project), and of course Rust itself was difficult to get into with lifetimes and having to wrap and unwrap my variables constantly and getting into wrestling matches with the borrow checker.
I kept telling myself that everyone loves Rust and the community loves to rave about anything Rust-related and maybe I just don't get it, but it took some time to realize that no... It's just a terrible choice for it. I even tried to make UI with eGUI and was still miserable. Rust is a systems programming language but the community is trying to convince everyone should be used for general purpose stuff.
And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.
I am curious about Bevy when it becomes mature and has its own editor, but for now I'm just not convinced gamedev with Rust will ever take off.
> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.
Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.
> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal
Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood.
I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.
It's a good feature, but still a niche one. It's a bit like choosing Unity only because of DOTS. For a few projects perhaps it make sense. But just a few ones.
I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).
Agreed. Multiple languages exist. They can be part of {your, your team's} toolbox for different specific purposes. Some languages are set by other tools or by team members' backgrounds. Popularity also lends itself to greater availability of tools and Q&A forums. In the end, it's a better decision-making process to select what is most likely to be long-term productive for a specific project and team.
This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc.
I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.
> Rust game development feels like a solution looking for a problem to fix.
The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.
This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools.
As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better).
Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).
The godot-rust project crates take a minor amount of adaptation to understand how it exposes the Godot object system in Rust but it's also pretty well developed.
Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.
We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++.
I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires.
> my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust
Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.
Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization.
If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.
Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;)
Perhaps learn another language like Haskell, Swift, or Kotlin before Rust.
Get cargo-bloat, cargo-cache, and cargo-outdated.
Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location.
Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.
> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial.
So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?
Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?
> So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?
Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.
As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here.
Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful.
This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development.
I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.
I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#.
It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year.
Also for ECS... one thing I tended to realize is that when developing a game, pigeonholing everything into an ECS can seriously tend to get in the way. A lot of (efficiently written) game code is best handled in an infrequent event-driven way.
An ECS backed game engine like Bevy can make big mobs more efficient, but few games will actually leverage this effectively for fun gameplay and at the same time modern PCs are fast as hell.
I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun. Now should a gamedev today, 26 years later, making a 2d isometric game for the PC be worried about performant multithreading????
> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.
Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.
The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...
EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).
These are definitely things that enhance gameplay for custom scenarios.
https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)
Complete distraction of a question -- for that video clip, what is the song playing at the time stamp you selected? Is that in-game music? I figure not.
Likewise - I've been learning Rust for four years now (significant C/C++/Python/Lua experience), and have written some reasonably complex apps in it, but I really just didn't get the Bevy / ECS "hype"...
I've tried to write several different types of games using it (with Bevy) in the past three years, and it just feels like shoe-horning something in.
But the biggest complaint I have with Bevy is that with all the refactoring that's been needed with the Bevy version upgrades: getting the code to compile again after the version upgrades has normally been fairly easy - but it then often didn't work correctly, and I'd have to spend time debugging the ECS system to work out what was wrong.
i.e. the "if it compiles, it'll almost certainly work" bonus of generic Rust code totally seems to fall down within Bevy.
I obviously understand that it's an in-development framework, in its early days, so some of that's on me for choosing it, but still, it's been a very painful experience, and I feel I've wasted a fairly significant amount of time over the past few years attempting it.
CPUs are way way faster, but RAM latency has barely improved in the past couple decades. That's why cache-optimized systems like ECS can still be a dramatic improvement when you're simulating a lot of stuff. Like, thousands of active objects.
They can be improvements, but you can do Data-Oriented Programming without ECS systems, i.e. Structure Of Arrays, which is what we often using in Rendering/Simulation for VFX for SIMD/GPU compute...
But similarly, ECSs can be slower, if they don't have some optimisations, i.e. spatial data structure lookups: just using a generic ECS "database" system without any first-class spatial knowledge / acceleration structure lookup ability, is likely going to be slower.
> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.
That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation and successors were a lot more fun, and a big part of that was not having arbitrary unit caps in a way that affected gameplay; expanding the limit from 500 to 1500 did genuinely make the game more fun.
supreme commanders very high unit cap leads to crazy end games. it allows your economy to grow exponentially for the entire game. which has a big impact on late game strategy
Many people are choosing Rust because they want to use Rust. Rust has the reputation being "the best" programming language: Fast, safe, reliable, modern. I can rely on that very much. Who wouldn't like the feeling of using the best tech for their project.
What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.
Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.
Really sells the value of having a tight developer feedback loop: it shows hot reloading for code and graphics, a reversible debugger, live profiling with flame graphs, a data inspector with data breakpoints, time travel inspection with a scrub bar, session sharing and replay with the same scrub bar and direct links from the call stack to a breakpoint, and more.
Above the many niggles they had with Rust itself, this greatly helps me understand why Rust left them wanting more from their working environment. They say they've switched back to Unity with https://hotreload.net/ to try to capture some of that, and now I see why. (It's a shame that hot reloading tooling in Rust wasn't ready for them yet, but I see why they've moved on instead of waiting/contributing.)
My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors sounds extremely obnoxious to deal with.
I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection. I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.
> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.
Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.
Rust's safety is designed more for normal dynamic memory applications.
This isn't even close to being true. I think memory safety isn't as important for games as it is for most software (though it is still quite important for multiplayer games!). But even if you write the most modern C++ possible I guarantee you are going to spend some of your time debugging segfaults, memory corruption and heisenbugs. Don't try and claim "I don't write bugs". Everyone does.
This kind of extends to embedded/low level systems programming as well - the assumption that memory can only change as an effect of program execution just does not hold true there. What's the value of tracking mutability and data ownership when a DMA engine can just decide to overwrite the memory you supposedly have exclusive access to?
> I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection.
I agree so much that I've been working on this for a whole year.
There is a sweet spot : non-GC, with pointers (but bounded), inference, basic OOP + tacking, and all the comforts of scripts. All in a good looking syntax without semi-colons.
For me, this is Odin-Lang, it doesn't meet all the requirements you have listed, but it's ergonomic, fast, and comes with extensive core and vendor libraries. It's all just fun and reasonable.
IMO it’s not opinionated enough. Golang for example doesn’t let you customize go fmt, while Rust does. Rust also has many ways to do things in general (mod.rs vs name_of_folder.rs for example) and seems to not want to provide a useful baseline for most projects via its standard library (unlike Golang).
But to go back to our subject: Rust is a great language and that’s all you need. I wish I could use it with unity.
Most modern languages are memory safe and they don't get called out for emphasizing that or being opinionated. I think with Rust that attention results from its choice of memory management model which gets in the way a lot in ways described in the article.
> My impression of Rust is that it's a very opinionated language
It's not though. There's only one thing Rust is opinionated about.
> that wants everybody to program in a specific way that emphasizes memory safety above everything.
Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory.
> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games
As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.
Rust also is opinionated that you don't want to write shared libraries or plugins. You can do both, but only if you drop down to memory unsafe C interfaces. The default is statically compile all applications into one program. Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.
Sort of, although Zig certainly pushes itself towards the embedded world. I have tried Zig a bit and like it a lot, and I am sure it would be better for game dev than Rust, but I don't want to pass allocators around all day to all the objects in my game.
> I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns
Sounds like Common Lisp or OCaml would work well. With Ocaml I find myself being able to iterate extremely quickly because of the inferred types and extremely fast compilation times. You also have the ability to tweak the GC to your needs and the assembly is easy to read.
> Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important. This doesn't mean "ship crap games", it means focusing on the game being a good game, not on the code being good code.
I think this can be easily extrapolated to projects outside of game development as well.
User experience is ultimately all that matters. If you're in prototyping stages of whatever it is you're building, and games spend a lot of time in this phase, then your focus should always be on testing what the user experience will be like, rather than absolute code correctness, maintainability, and everything else that makes a long-term project successful.
The fact Rust seemingly can't deliver this rapid prototyping workflow should be a large factor when deciding which language to use.
I've been using Go as my main language for the better part of a decade now, and I think it strikes the perfect balance of code quality and rapid prototyping. It's far from the side of absolute freedom of a language like Python, which becomes a nightmare to work with after the prototyping phase is over (though this might have improved in the past few years), but it's also far from languages like Rust, and allows me to be very productive, very quickly, while also being easy to pick up for newcomers. I probably wouldn't pick it for GUI or game development either, though, but for things like CLI, network and web tooling, it's perfect.
To be fair, many (non-game dev) Rust projects I have seen/used do provide great user experience precisely because they are laser-focused on performance and have blown existing alternatives out of the water. (Think ripgrep, fzf, etc.)
Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance after the fact, which web development frameworks, and in particular shitty "web" applications like MS Teams are a testament to.
Starting by saying I fundamentally agree wrt iteration speed. This is ultimately why [C/C++]/Lua was such a thing for a while, and it seems quite plausible that you could benefit from a core engine in rust bound to a scripting language.
But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature optimisation, but also with a sense of misplaced religious purity regarding the evils of state and the merits of functional programming. There never was any OOP law that your inheritance hierarchy had to be insane, or that you had to create classes for absolutely every last thing. Now we have people hitting the opposite extreme where everything has to go through the same function switched on a pattern matched enum. One of the core problems with Rust is it lacks the mechanisms to allow moving adequately out of this tarpit.
I still think Rust might have a place at the lowest level core where it is all about shuffling arrays of things through compute units, but for the higher level pieces it is clearly the wrong thing to be using.
> but also with a sense of misplaced religious purity regarding the evils of state
To clarify, Rust isn't against state at all. Rust bends over backwards to make mutation possible, when it would have been far easier (and slower, and less usable) to have a fully-immutable language. What Rust is against is global mutable state, and an aversion to global mutable state isn't a religious position, it's a pragmatic position, because global mutable state makes concurrency (and reasoning about your code in general) completely intractable.
1000%, and this is something gamedevs (and, for quite some time, webdevs) are guilty of in the name of speed for quite some time. In both web and game dev, it's come back to bite when it's time to debug.
Concurrency is hard, and anything with a ton of user interaction or communication across multiple parties induces concurrency (never block the main thread and all).
I've been playing around with an idea about OOP for awhile, not sure if it'll ring true or not but I'll run it up the flagpole for feedback.
I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is. But when you're creating models of the world it's usually really convenient and even accurate to use nested inheritance models. Maybe the original system for this is the flora/fauna taxonomy but it applies to a lot of things; like GUI elements or game models.
If this is correct, it might explain why the discourse is so polarized. Whether OOP is a blessing or a curse probably depends on whether you're using a programming language as a modelling language or as a logic/execution language.
It's not hard/fast but I would tend to agree with an approximation of this.
Back when I worked properly on big games the UI libs would often be trees of widgets with injectable functions for modifying the rendering, which is actually one of the points in this blog the writer would like. (The UI lib of classic Sims was exactly like that). These days the stuff I've done, although entirely in JS, at https://luduxia.com/ follows that pattern for the 3D components at least. The world is defined in an almost classic scene graph and then behaviour is added by attaching functions to pieces, which can be composed functionally.
Much of the anti-OOP noise is the result of people that have suffered from others creating hierarchies of the world too literally. Quite why it proves so difficult for developers to slow down and think about the right course of action is beyond me. They're also staggeringly resistant to changing afterwards.
Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language landscape and broader development ecosystem were completely different.
And now, the most popular generally available game engines right now are:
Unity - C++ in the engine, C# for game code
Godot - C++ in the engine code, GDScript or C# for game code
Unreal - C++ in the engine code, somewhat mangled C++ for game code BUT with also one of the most capable and widely used visual programming setups I have ever seen
I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.
> I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.
That's why, the first time I saw Bevy and Amathyst, I had an immediate "they're doing it wront$ reaction. IMHO, to be a true game engine in the modern sense, instead of merely a game framework, your engine needs to be a precompiled, standalone executable in a systems language that picks up, loads, and executes game scripts, data files, and assets that are totally separate from the engine itself and written in higher level languages. You don't want to be writing everything in a rigid systems language and especially don't want to have to compile your game logic and your engine together and then link them as if the engine were a library. That's why I'm (very slowly) feeling out what a proper game engine in Rust might be like with https://github.com/alexispurslane/embryo-engine. It will take me some time, since I have to learn real time computer graphics and a lot about game engines, but I've got the books, I've made a lot of progress in learning them, and the engine design and architecture is coming together very well in my big black notebook, so if you're interested, give the repo a watch ;)
I'm debating between embeddable common lisp (to satisfy my hacker impulses) or C# for the scripting language. I have figured out, I think, how I'll embed C# in Rust down to some pretty detailed steps, involving a two stage process, but .NET is so heavy I'm worried if it'll be worth it. I'd love input!
Obviously that is the intention, but the absence of libraries that manage to replicate what people manage fairly easily in other paradigms does show it's not sufficient.
golang is similar in this regard - it has interfaces and you can compose type structs, but the results become an unwieldy mess unless the developers are staggeringly disciplined, in which case they'll have a better time in something else anyway.
This makes a lot of sense. Wonder if Bevy will add support for GDScript or C# or something. I think it's generally opposed in the interest of ensuring the Rust devex is as good as possible, but it's coming eventually, I think.
A general bevy scripting crate has already been in the works, they were waiting on various things like be y reflect and other such features to be able to work properly and so forth. In other words it's already planned and there's a lot of work being done on it with a whole lot of dependent functionality coming out in every single release.
I only skimmed this article, but, despite it being very negative about Rust, I almost 100% agree with it: Rust is a HORRIBLE choice for game dev. I might quibble with how they outline the costs and benefits of some of the design patterns that rust forces you into, for instance I think command lists are actually incredibly useful and perfectly fine as a game development thing and not the huge problem they consider them to be, and generational arenas basically solve any pointer ownership problems in game development in my opinion, but they are right in the main.
I know, because I've tried it. Once. I would #never* recommend Rust to game developers, especially not indie ones. In fact I'd recommend against it strenuously!
And this is precisely because Rust is explicitly and knowingly focused on correctness, safety, perfectly clean code, etc at the cost of iteration speed and flexibility and dynamicism, and that's bad for designing game mechanics and even just getting a game done — games have an inherently short life span and development cycle, so safety and correctness and code quality don't matter a whole lot. It's okay if they crash, etc, as long as they work enough to play. It's okay if the code is ugly, you probably won't be working on it for very long. This is even moreso the case, as the author says, because in writing a game you really want to be able to iterate quickly and just. Do shit as an experiment, even if it's temporary, to see how it feels.
On the other hand, who I would recommend Rust to is the people writing game engines, where you really will probably be working on that code for years to come, where stability and correctness is pretty important, and so where Rust's strengths will really shine — but crucially, even then, I'd tell them to make it a real engine, not a game framework like Bevy, by adding a highly flexible, dynamic scripting language like Lua or even C#, and a data format for specifying scenes and entities, and an editor. That way you don't write your game in Rust at all!
I'm disabled so I don't have a lot of energy to work on it often, but, especially once I nail down the last few design issues, I'd really love help, or even just a few eyes on the project to encourage me ;)
I like it, I read the Design Document. Do you have any game concepts you are building with it? It seems like the kind of project that would be built with a game side-by-side.
> Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
I found this to be true of C after many, many years coding in C. I noticed that the first selection of data layout stayed throughout the life of the code (with a lot of tweaks, additions, etc.). But didn't really think that much about it.
Until I started writing code in D. It was easy to change the data layout, and I did for experimenting. For example, changing a reference type to a value type, and vice versa. This was easy in D. It's just too much work in C, so it didn't happen.
The reason is simple:
p->b
v.b
To switch between a ref and a value type, you've got to search/replace the -> into ., and the . into ->, and not disturb the dots and arrows of the other types. When dealing with 100,000 lines of code, this is a non-starter.
But with D, both reference and value types are used as:
p.b
v.b
making it easy to switch between the two, and also switching function parameters from values back and forth with references.
I agree, and D with the GC lets me prototype quickly. Its type system gets progressively stricter with constraints, for code that survives. I wouldn't want all the type system to apply to prototype code or a nascent program.
The power of attributes and get/set in languages like C# is similar. It's easy to turn value types into functions. Or to move a value into a subclass and you don't need to do a.b.c (moved c into b) because you can add c => b.c to the a class.
That's a good example. I actually think dot syntax is really under-utilized sometimes. Although personally, I'd prefer that if v was a reference/pointer to a struct, that v.b simply performs a pointer offset, instead of auto-dereferencing like ->.
I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable.
I only make some comments from my professional (audio) perspective:
We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.
Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol [2] recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.
All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.
I think the crux is this heading: Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
Jon Blow said that in one of his talks: Rust treats all code as production code. For most of the duration of a project, that's counterproductive, because it introduces a significant amount of unnecessary friction.
For most of a game's development, you're trying to figure out what the game's supposed to be. Only later does it crystallize. Rust doesn't recognize the non-crystalline phase, or rather explicitly rejects it as invalid.
As much as I love Rust I sometimes wonder if I'd be more productive in a simpler language. If I wrote it every day I'm not sure that would be true, but as a hobbyist coming back to Rust sometimes takes me a bit to get back in the zone. Also, still not a fan of async, as it is woefully incomplete and fairly complicated in some use cases. That said, I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either. I long for the "in between" language, but with an amazing 3rd party ecosystem as both Rust/Go have.
Maybe people will make fun of me, but I've been very happy with Kotlin and Dart.
Null-safe, good ergonomics, very fast.
I've tried Rust, sometimes play with C, D, Deno/TS, Nim, Java (actually I still write lots of it) and even some more cutting-edge stuff, like Unison. While they're cool, what I want is a language with really good tooling that gets out of my way without letting me write patently dumb code (like Java lets me use any object without checking for null, when it can be null but the language just doesn't give a shit to help me).
I use Dart when I want to compile to binary executable or use Flutter, and Kotlin for stuff I think the JVM has more to offer, like a server. The two languages are just a pleasure to use, pretty similar but having completely different ecosystems (which is great, you can use the best one for the job!).
I'm glad you found tools/languages that work for you. Kotlin felt a little too much like Java to me. If I stuck with a JVM lang. I'd probably go back to Scala 3, but I just don't like the JVM as a user (just sucks too many resources).
(Judging is still ongoing and votes would really be appreciated! It would help me to get more resources to work on the underlying package).
This was my first ever “game” (tech demo, really), and I’m not a game dev, so take this with a grain of salt - but I do think there’s a lot of potential for Flutter/Dart as a game framework. Hot reload makes iterating on game logic very fast, you obviously get the UI toolkit and cross-platform support straight out of the box, and the language itself is (relatively) concise, so it lends itself well to gameplay programming. When you need to get your hands dirty at a lower level, you just drop down to C++ (or whatever engine you can expose via FFI).
I think Google believe that Flutter can nab market share from Unity in casual 2D games (hence their official sponsored competition), but I think it has even more potential than that. In fact, I’ve seen at least two game companies (Supercell and another whose name I’ve forgotten) hiring for people to work on embedding the Flutter engine in various platform games.
I like Kotlin but I find the fact that it lacks a good way to detect and handle possible errors very frustrating. If some function can fail on sane-looking input I'd like to know about it
I’m not convinced that ecosystem is so important for game dev. Once you have a simple graphics library, bindings to BulletPhyiscs etc most of the code is custom simulation code with no integrations needed.
I can echo OCaml. It is probably the most underrated language imo. It has great compilation times, macros, type inference, good tooling. With few exceptions, the library ecosystem doesn’t suffer from the same overengineering issues as Haskell and types are kept relatively simple. It has simple runtime characteristics making it easy to optimize performance when needed, although it tends to be very fast in general.
> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either.
Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone something but seems that is not always the case.
Having worked with Go for about a decade now, I largely agree that nil is a pain in the ass to work with, and the language has largely done nothing to make it better. However, Go (mostly) doesn't have exceptions. Ordinary problems are represented by non-nil errors, which are values. Panics exist but really are reserved for exceptional situations (with the number 1 cause being, of course, dereferencing nil).
I ran into these issues all the time with Java, C++, and Python projects.
But it's just not the experience of running Go in production, which I've been doing for over 10 years now, across many projects with many devs.
In practice, nil checks are just not very difficult to include everywhere. And experienced Go programmers don't use exceptions (panic/recover) almost ever.
I've been hoping to see more languages that compile to Go, it might be the most practical way to arrive at what you want. For example, see Borgo: https://news.ycombinator.com/item?id=36847594
As much as I dislike many of the legacy issues with JavaScript I find TypeScript to be the best language to iterate with. If Rust had GC without need for wrappers like RC though I think that would be my preferred iteration language.
I mostly try to write my TS in a manner that would translate to Rust, but that's hard to do sometimes when it comes to memory management.
It doesn't occupy the same space, but the simplicity of Gleam has been very enjoyable to me. It's still quite a young language though, but worth keeping an eye on.
The open-source ecosystem is not as massive as Go's or the JVM's, but it's not niche either. F# runs on .NET and works with all .NET packages (C#, F#, ...). If the .NET ecosystem can work out for you, I recommend taking a closer look at F#.
F# allows for simple code, which is "functional" by default, but you're still free to write imperative, "side-effectful" code, too.
I find this pragmatic approach works extremely well in practice. Most of my code ends up in a functional style. However, once projects grow more complex, I might need to place a mutable counter or a logging call in an otherwise pure function. Sometimes, I run into cases where the most straightforward and easy to reason about solution is imperative.
If I were confined to what is often described as a "pure functional" approach, I'd have to refactor, so that these side-effects would be fully represented in the function signature.
F# ticks the enums/ADTs/pattern box but also has its own interesting features like computation expressions [0].
I would describe them as a language extension mechanism that provides a common grammar (let!, do!, ...) that extension writers can target.
Because of this, the language doesn't have await, async or any other operators for working with async (like C# or TS). There's an async {} (and task {}) computation expression which is implemented using open library methods. But nothing is preventing you from rolling your own, or extending the language with other computation expressions.
In practice, async code looks like this:
let fetchAndDownload url =
async {
let! data = downloadData url // similar to C#: var data = await downloadData(url);
let processedData = processData data
return processedData
}
I often use taskResult{}/asyncResult{}[1] which combine the above with unwrapping Result<>(Ok or Error).
Metaprogramming is somewhat limited in comparison to Scala or Haskell; but still possible using various mechanisms. I find that this isn't a big issue in my work.
IDE-wise, JetBrains Rider is a breeze to work with and it has native F# support. There is also Visual Studio and VS Code with Ionide, which are better in some areas.
You can run F# in Jypiter via .NET Interactive Notebooks (now called "Polyglot Notebooks" [2]). I haven't seen this mentioned often, but this is very practical. I have a combination of Notebooks for one-off data tasks which I run from VS Code. These notebooks can even reuse code from my regular F# projects' code base.
Over the past years, this has almost eliminated my usage of Python notebooks except for ML work.
The problem with languages is they don't compose. Iow, one missing feature needed automatically invalidates the language entirely. Swift is targeted at Apple platforms and cross platform is an after thought. Kotlin targets JVM and while it is cool in concept, I hate it as a user (and Kotlin native isn't near as mature). If were considering something else at this stage I'd probably put my time into F#, but even it has its cons.
NOTE: By "compose" I mean that if I want feature A, B and C from lang X (has A and B), Y (has B and C) and Z (has A and C), but there is no way to get A, B and C in one language without creating a brand new one. I cannot mix and match features from different languages.
Rust is in a separate class of go and swift and kotlin and etc. The class it competes on is pretty C, C++, and itself.
Yes it's easier to write trivial code in python than Rust. Yes it's harder to manage memory manually than it is to let a gc handle it. I don't see the point.
Rust is a systems programming language. It's hard to write a server in it than it is to hack something in node, but it will also be faster and more reliable. Conversely, it's easier than writing it in C++ or C, while still being more reliable. That's the whole value proposition.
For Apple, Swift is their Rust, regardless of the world outside Apple's ecosystem thinks about it.
It is clearly stated on Swift's documentation, they already hold a couple of talks at C++ conferences about code migration, and is one of the reasons why nowadays they mostly focus on LLVM contributions instead of clang.
Oh my, this has to be my favorite quote in a blog in a long long time.
"... many if not most of the problems don't go away if one isn't willing to constantly refactor their code and treat programming as a puzzle solving process, rather than just a tool to get things done."
I have thought it was just me for a long time, but many of the popular styles of programming that we push definitely seem to require constant refactors in the pursuit of a solution. And I definitely see more tire spinning for the sake of the build than I do for whatever it was folks were building.
I think multiple refactors in pursuit of a solution can be a good thing. As your thinking/design evolves, so does the shape of the solution.
The main problem, I think, is that this goes against specifically gamedev. In gamedev whether the solution is the best or more resilient is secondary to extremely fast iteration and delivering something. Like the author says, sometimes "clunky but good enough for now" is what you need to get it over with (for the moment) an iterate rapidly over the gameplay elements you should spend most of your time on. Gameplay, not correctness or reliability or maintainability, is the most important thing in a game.
When I set out to learn Rust about a decade ago, I chose to write a game - a clone of "Empire" that I call Umpire.
It's a different task to re-implement an already-designed language rather than designing and implementing at the same time. Nevertheless I have run into a number of the difficulties mentioned in the article, and arrived at my own solutions - foremost passing around global UUIDs rather than actual `&` references, and enforcing existence constraints at runtime.
I've experienced the protracted pain of major refactors when assumptions baked into my data model proved false.
In some regards these refactors wore some of the shine off of Rust for me as well. BUT I'm still glad the game is implemented in Rust, exactly because of Rust's dual emphasis on safety and performance.
The AI I'm developing requires generation of massive quantities of self-play data. That the engine is as fast as it is helps greatly.
Rust's strength in ML means my AI training and game code can share important types, ensuring consistency.
The effectiveness of Rust for writing CLI tools (mentioned in the article) has lent itself to a number of game-specific command-line interfaces that are of high quality.
Rust's memory safety became critical once I decided to network the game. I don't want `umpired` to be any more exploitable than it needs to be.
My constraints have been very different than the OP's; obviously it makes sense for their studio given their experience to move away from Rust. But I think Rust still has a place in games.
Most of ML frameworks that I know are implemented in Python and C++. I tried looking at ML in Rust a few years ago and didn't find anything useful. Has it changed?
You can use libtorch directly via `tch-rs`, and at present I'm porting over to Burn (see https://burn.dev) which appears incredibly promising. My impression is it's in a good place, if of course not close to the ecosystem of Python/C++. At very least I've gotten my nn models training and running without too much difficulty. (I'm moving to Burn for the thread safety - their `Tensor` impl is `Sync` - libtorch doesn't have such a guarantee.)
Burn has Candle as one of its backends, which I understand is also quite popular.
I agree with a lot here, but I think the author is overplaying "get things done fast" or underplaying "stable, performant code". I like indie games, but I've played enough games that crashed if I look at them wrong or chug despite being low poly early 2000s things that I now hesitate to buy indie games. Some of the examples seemed like maybe rust was preventing a weird unexpected feedback or clobbering iteration state or whatever.
I don't think the author disagrees here and is mostly talking about awful runtime alternatives (refcell, etc) but I just wanted to say it for balance.
People should get more into integration tests. If you start out thinking you need to separate everything for unit testability, you instantly get architecture astronaut-ism, where your architecture is entirely based on fake testability instead of the thing it's actually meant to do in production.
> wait I can't add this new thing because things will no longer compile, and there's no workaround other than code restructuring
I definitely think that's a great feature. I want to learn on day 2 that the design is a dead end, not on day 101 when I ship on day 100 and there was a race condition on day 2 I never noticed.
But the thing about gamedev (I guess - I'm not a game developer) is that the code being great and doing what you hope it will do isn't 100% of the job as it is in other disciplines. In gamedev you may want to run the code, and the way it runs (fun, feel, whatever) might be bad even though it compiles, works according to a spec and so on. So while I'm usually happy to write code for a week and never run it - game development feels like it's all about the iteration.
That said, game development is also game engine development. And Rust seems absolutely perfect for engine development (you need "fearless" concurrency and performance and there are zero mainstream languages that will do that other than rust). For people who feel it's too rigid or hard to iterate with perhaps hybrid could work. Like Rust + Lua or something sounds like it could be worth trying.
I think the point is that there are few "code related" dead ends in game code with good game play that can't be dealt with using enough effort. There are plenty of "game play related" dead ends that no amount of clean code can help out.
To that end, whatever can help you explore the game play the fastest is what you want.
Quick iteration perhaps isn't the biggest strength of C++ either. Rust does have some friction when it comes to "I'll try this with a dirty impl and if it flies, then I cam make a clean one later". I guess if that friction is worth it will depend on how much faster you get on other things, e.g. refactoring without spending a lot of effort worrying about introducing hard-to-spot bugs like races, or - worse - having to spend valuable time fixing those bugs instead of adding fun to the game.
> game development is also game engine development
not necessarily. Loads of games and game developers do not engage in any engine development at all, they just use an off the shelf engine and make their game, treating engine developing about as close as web devs treat database development.
I've become wary of commenting on articles that mention the pros and cons of various languages, but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on. When it should be the other way around.
The joke he mentioned about having 50 engines written but only 5 games certainly rings true and I don't think the language is the main problem preventing people from getting their projects done..
The hardest part of a project is finishing it. I think the main issue is the fun problems to solve happen very early in the project and once those are done it becomes incredibly tedius and boring and I usually lose focus until the project dies. Its difficult to maintain motivation.
Interesting, I almost find it the opposite right now. Learning the engine is a pain in the ass -- it's not particularly hard, just tedious to learn all the APIs and quirks -- and then when you're initially building the thing, "it's not fun yet" for a quite a while. But then once you have the fundamentals down, you can add more abilities and characters and other features, that's the fun shit.
I was working on the AI last night, and since I already had one functioning AI agent, it was pretty easy to spin up variations that behaved in moderately different ways, which was very fun!
I've only been dabbling though, and still sort of in the prototype stage, not quite a full game yet but getting there. Maybe I'll feel more like you suggest deeper into development.
Right. If someone could come up with a pill or something to maintain motivation and make all the bugs and hairy annoying details feel fresh again, just like the feeling of starting over, I would certainly part with my money. But there's no such thing unfortunately.
IMO one language can sidetrack you more than another. It might not be the main problem but a language that gets in the way for your usecase causes you to focus on the wrong problem. Making a good game is really hard and really needs you to focus outside the tech.
>but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on.
Yes, if they are so convinced of that, why are they not back in the office or at home, working busy as a beaver on their project, using that great programming language, the benefits of which they extol?
I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?
The author maybe somewhat hit on the reason for this in the article, where they mentioned that they're already seeing some of the rabid, toxic, Rust proponents already moving onto the next "hot" thing and doing their thing there. So maybe after a few years of Rust we've arrived at the turning point now where enough of those types of people have finally moved on and the Rust community has significantly changed.
Perhaps because the article is about how Rust isn't the magic bullet to everything, and a few people have commented agreeing with the article, others feel more willing to comment their own Rust isn't perfect opinion as well.
If you go into the comment section of a pro-Rust article, where the first few top-level comments are also pro-Rust, the responses to people expressing a negative attitude about Rust tend to (in my experience) be different.
This phenomenon certainly isn't exclusive to Rust (or HN). It happens all the time, especially when a prolific commenter is among the first few comments. It can set the tone for the entire comment section.
I assure you it happens, but the people targetted this way usually quickly learn what is ok and what isn't to say, especially on rust's reddit. If you wanna see examples, look at my reddit profile (same username). I dared to say bevy was full of hype and false promises and tat the money they get would be better spent elsewhere. And look at the hate i received.
One way i've seen to reduce this is prefixing any posts with "I am not criticizing any engine in particular" even if it's blatantly obvious because the criticism only applies to one.
Based on what I've seen, various forms of censorship and suppression are often employed in such cases, rather than outright "flaming" or other discussion-based approaches.
It really depends on where and how the discussion is taking place, and what censorship methods the website/platform/medium involved offers.
Sometimes users are just outright banned or shadow-banned, if those happen to be options.
Sometimes forum threads, bug reports, or comments are deleted.
Sometimes the discussion remains accessible, but is stifled in some way. This includes closing/locking forum threads or bug reports, or otherwise severely limiting participation in such discussions to a very small and isolated group of people. If down-voting/reporting systems are present, sometimes they're used to limit the visibility or prominence of such discussion.
I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community.
Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.
This is a textbook example of poisoning the well. [0] We see it used in every discussion about pros and cons of a language on HN.
It's some variation of "People who like this language can't handle criticism/are part of a cult/etc." The idea being that this will preclude anyone from responding to a criticism, because that would confirm the comment.
I find that Jonathan Blow ranting about Rust game development here https://www.youtube.com/watch?v=4t1K66dMhWk. He adds interesting perspectives to the discussio, how the language makes the Rust game developer resort to arrays and their so called Rust point of views.
The blog post reminded me of a quote from Jonathan Blow as well. I forgot the exact wording, but basically he said that Rust makes you treat every state of the project to be production ready (e.g. free of memory safety bugs), but in game development, most of the time the project needs not to be production ready, and for a good reason (rapid prototyping). You just have to fix the really bad things (crushing bugs) before shipping.
Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games.
So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade…
(But he already shipped his masterpiece and he's a millionaire so he gets to chose his full time hobby as he wishes)
>spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games.
I wish. As far as I can tell he made a single hour long video shitting on rust and now he's the enemy of the cult. That's hardly spending the last decade sitting being mad over rust.
I mean, he does like a good rant lol. But this seems like a bad take. The witness came out ~8 years ago, and Braid came out ~8 years before that. Braid Anniversary is launching next week, he's actively developing his language and next game (occasionally streams).
"he's just resting on his laurels now" I think is clearly wrong
Interesting read! If I had not picked Elixir + Godot for the multiplayer game I'm making, then I would've gone with Rust for the whole thing. The old naive version of me would've tried doing it in C++ + Unreal but I knew better this time around.
I think multiplayer game devs are sleeping on Elixir! It has made the network side of things so much easier and intuitive with fast prototyping and built in monitoring - so many lifetime issues are easily found and addressed. I'm pairing Elixir with Godot, Godot is used for the frontend game client. And its crazy because I thought the game client part would be the "hard" part as it would be a new skillset to learn, but Godot makes the actual game part very easy. GDScript is easy to learn, and the way Godot uses "signals" is very similar to the backend code in Elixir with message passing so its not a huge cognitive shift to switch between server/client code.
I get that BEAM doesn't lend well to highly computational tasks, but I just don't see how thats an issue for many types of multiplayer games? If you aren't making some crazy simulation game, then most of the backend computation is more around managing client state and doing "accounting" every tick as inputs are processed. The most computational task I've had is server-side NPC Pathfinding, which I was able to quickly offload onto seperate processes that chug along at their own rhythm.
No blog unfortunately, the notes are all on paper. I have github page for the game where I ramble a bit: https://github.com/mikhmha/SWARMMO
But I'm planning to release the game for testing next month! Its a browser "MMO" game too so its going to be easy to try out. And then I'll have time to write some more detailed technical notes online.
> The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them "write good code", but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean that this is a desirable way to write code. I've often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.
The latter part of this is true for any strongly statically typed language (with Rust expanding this to lifetimes), which negates the beginning of this paragraph -- once you get things compiled, you won't need to refactor, unless you are changing major parts of your interfaces. There are plenty of languages that do not have this problem because it is a design choice, hardly something Rust can "fix", it's what makes it Rust.
This is the opposite of my experience with other strongly typed languages. They're easier to refactor, because when you change the types, say you delete a field, everywhere that field was used is a compile error. Clean them up and on your way.
The borrow checker is an entirely different beast. People forget that safe Rust allows a subset of programs. Finding the subset which does what you want can range from easy, to hair-pullingly gnarly, to provably impossible.
The author is asking for a "give me a break" feature. I would say that in a strongly typed functional language, this is akin to mutating objects. The author seems to wish for an unsafe option to locally turn off the borrower check. Is it something Rust could not offer?
You can always dip into raw pointers and come back up for a reference, or eg. do a transmute to a static lifetime. Absolutely not okay according to the language rules but it will compile and will probably also run without an issue if you're not doing something wrong in your code (eg. Wanting to keep a reference to a string while you also mutate it.)
I'm actually surprised that the author didn't seem to consider this much of an option.
My experience is that the ecosystem is a mess, have hit winit, wgpu, and countless bevy bugs, iteration times are abysmal, documentation is nonexistent. In the time it would take me to make a game in popular Rust tooling I could build the game and engine from scratch in C and also have something that would crash less.
You know, I think this point is important to get right: there are generally docs, Rust does a very good job of making it easy to write docs.
What doesn't always exist are guides that explain how to piece things together. Sometimes you wind up needing to really know the inner platform to piece together things in Rust, and while I love the language, this is one area where the community could improve.
Yeah, in general with large and Powerful libraries or frameworks, I find that pure API documentation, even if very thorough and well explained on an individual function or data structure level, is just simply not enough. I also want a reference manual type experience, where that API reference is integrated with explanations of the reasoning behind how the framework was designed, and how to actually think about using it, and examples of many common things you might want to do that integrate well together. The gold standard for this in my opinion is the opengl Red Book.
This, and the fact that correctness and safety and stability aren't quite as important in game development, or even game engine development, as they are in other fields where rust is applicable, is why I purposefully happily use the powerful, futureful, well established, copiously documented C or C++ libraries I need, instead of tge Rust alternatives, for almost everything. It works extremely well for me because I get to leverage the power and amazing ecosystem around things like dear imgui or sdl2 or opengl or physx, while being able to use rust, which grants me essentially a cleaner, even more modern version of C++ with all of the features I love from ocaml, in a way that restricts any weird crash or memory safety errors to the places where I interface with the lower level libraries, and sometimes not even there, depending on how high level the bindings are. It's honestly pretty nice for me.
By the time the Rust developer is finished with their refactoring, the C++/C#/Java/JavaScript developer has implemented many different gameplay features, played the game a bunch and tried them all out, and has a better understanding of which direction should their game be taking.
In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things:
1. I am using technology in order to build this thing.
2. I am building this thing in order to use this technology.
Developers often fall in the (2) camp but don't admit it. There's an allure to using the new, sexy tech that will solve all their problems, whether that's Rust, Kubernetes, LLMs, etc.
If you're in the (1) camp, you should stick with what you know; and if you know that what you know isn't enough to build the thing, you should use whatever is most common and straightforward, not something off the beaten path.
Games seem to be the biggest trap, because solo devs often end up building a game engine when they set out to build a game. If you really want to build a game, just use Unity/Unreal/Godot, I promise it'll go better for you.
I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript).
So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore wrong.
* For the sake of argument, we can pretend I only know rust. In reality I know a fair number of other languages as well, but the list doesn't happen to include C# or "random game engine specific scripting language", which seems to be the options if we're going with an established engine for big 3d games.
This falls in the "you know that what you know isn't enough to build the thing" bucket, presumably. Even if you're a Rust expert, do you know how to manage game asset content pipelines? Sound and music? Have you done graphics programming at all in Rust? How are you going to store levels in your game, and how are you going to make them? How are you doing multiplayer? etc...
You're going to have to learn something new, and it's a bit of a judgment call, but picking up C# or gdscript given that you already know programming should be straightforward compared to re-implementing all of those things yourself in Rust.
Unless, of course, you do know a bunch of great Rust game development libraries that solve all those problems--in which case yeah, building a game in Rust might be the best choice. It's not impossible!
Perhaps the more appropriate advice is : Use the right tool for the job.
Use C++ for writing a high performance library or a database engine.
Use Go or Java for writing a server.
Use C for writing a kernel module.
Use shell scripts for automation.
Use python for trying out ML ideas or heavier duty scripts.
Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right tool for all of the above and not succeeding much in practice.
Learning a new language is basically trivial relative to the effort of bootstrapping everything yourself to compensate for a lacking ecosystem, or the effort of banging your head against the fundamental unsuitability of a tool for a job.
Anyone who's learned one or two languages should be able to pick up the basics of any of the standard ones pretty much instantaneously.
When all you have is a hammer, everything looks like a nail. When all you have is programming expertise, all your game production obstacles look like programming problems.
I think everyone in games has met an “engine person” who spends a lot of time iterating on tech, but never quite getting to the creative expression that got them in the game. I think part of it comes a bit from mythologizing breakthrough games like DOOM, where cool technology made something completely fresh. We begin to think that emulating id Software is how you make compelling art, ignoring the latter half of Kushner’s novel.
Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
It wasn't just once or twice when I've picked some very promising library or tool only to learn something isn't exactly as I hoped (or as it was advertised - docs can lie, too) after I've already spent some non-negligible time implementing something with it. Save for some teenage keyboard mashing some decades ago I'm not a game developer, but I suspect this is universal experience no matter the niche.
> Developers often fall in the (2) camp but don't admit it.
There's also a mixed approach, where people admit "I want to build this thing and use this technology, and I suspect they're a potential good match so I'm gonna try both at the same time". Any even slightly creative person must have an urge to learn and explore new things, even if they aren't exactly necessary for a task at hand. Checking on the promise, if it holds true - sometimes it does and you get a new tech you love, quite frequently it doesn't and you have a bad day.
> Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
Exactly. You need to make some choices up front about program design despite rarely having enough information to make the correct decision, nor enough time to evaluate alternatives in detail. If we had known 15 years ago what we know now our then green field project wouldn't have been done this way - but we are still discovering things that the decisions we made 15 years ago are making hard to do today. That is on top of all the existing things we know are wrong that we often cannot feasibly correct.
You have to make choices. Some of those choices will be impossible to undo without starting over after a while. Some of the negatives will take a decade to figure out. There is no way anyone sane will give you enough time to figure out what those negatives are for each choice - even if the did you will be dead before you finish.
I'm in the 1 camp. After several decades of C++ I know it very well. Well enough to find some of the things that those Rust and Ada people are saying about their respective languages intriguing. I'm at the point where I need to spend some time with each to see how/if they work with my problems in the real world. Because eventually you have to admit that while you can drive a screw with a hammer there are other ways and maybe it is time to learn how to use a screwdriver.
This is what I like to call the artist vs engineer dilemma.
1. An engineer solves problems, learning and using tools.
2. And artist learns and uses tools, for the sake of it.
Neither is wrong, and some times they benefit each other. I believe much of academia and research is heavy on the artist side. You just have to be clear on which one you are at any given point.
I'm not gonna use assembly for my $JOB where we need some basic web backend. That's not gonna stop me from trying on my free time tho.
How about "I'm building this thing and I want it to enjoy the unique combination of performance and memory safety offered by this technology"?
It's certainly close to (1), but also a perfectly rational way to be a The Rust Way fundamentalist avoiding refcounting and unsafe who appears suspiciously (2).
The "rewrite in Rust" meme surely does not come from thin air and there is certainly some skill honing and challenge seeking involved. But perhaps a rewrite ever couple of decades isn't all that bad? And if it isn't, could there be a better time for it than "in Rust"?
It's not easy to find an employer that'll agree with your preferences. I chose to find fun and value in the way I collaborate and reach end goals, not the tools. If the tooling in my dept sucks, I just treat it like a challenge and deal with it.
I think these comments are fair. It's true that Rust is rigid.
I've had great success with Rust, but on projects where I knew exactly what I needed to build. Rust's focus on code correctness is great for maintenance of projects, where the priority is in keeping them stable and not causing regressions.
So while I'd say Rust is pretty quick for refactoring of something like a device driver, it's far away from the hot-reloaded time traveling live tinkering IDE.
I respectfully disagree with the author's title choice.
My first impression is, of course, that the issue is there is no production Game or GUI framework around.
The author seems to complain mainly about the choices of frameworks and how bad or opinionated they are. I agree. Even Egui is too opinionated, but it makes sense on some level.
It is no problem to use bindings to some software written in C++. Rust was created to solve this exact problem: rewrite big projects that were written in C++, by slow mutation in Rust.
Honestly, I would add further that until the Unreal Engine uses Rust, we should not expect widespread Rust adoption. It will likely start with a company creating its own really custom game engine, the game becoming a bestseller, and it will spread iteratively over the years from there.
Or maybe there will be a better option beyond Rust at that point.
Beyond that: One should see Rust as writing C with someone watching over you to remind you that you need to know the writer for each memory value. It picks up work off you. Or it should. If it doesn't, yes that is a problem, and we/you are doing it wrong.
But yes, if you are doing something that the borrow checker complains about, in other languages, either that semantic difference would have been hidden, or you would be paying for it later.
There, the author makes a point that he wants the code to work now. That is possible, and you can hotwire bad code in Rust, too. But I am sure that code is why we end up with games like Jedi Survivor.
There is no fundamental inability of Rust to do the things the author demands.
If you want dynamic loading, use https://crates.io/crates/libloading (And you don't need to use the library).
Do you want a global state? I will disagree with you, but take a look at, e.g., how the Dioxus project is doing it. Again I think that is always a terrible mistake, and people are thinking really of using an arena or a registry really.
As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Using Rust instead of C++ is just one part of that. Bevy has a more modern design throughout: for instance, it has a relatively straightforward path to GPU-driven rendering in an integrated system, without having to deal with three incompatible render pipelines (BiRP, HDRP, URP).
What I find more interesting is the parts of the article that boil down to "Rust isn't the best language for rapid development and iteration speed". And that may well be true! I've long thought that the future of Bevy is an integrated Lua scripting layer [1]. You don't even need to get into arguments about the suitability of the borrow checker: it's clear that artists and designers aren't going to be learning Rust anytime soon. I'd like to see a world in which Rust is there for the low-to-mid-level parts that need performance and reliability, and Lua is there for the high-level logic that needs fast iteration, and it's all a nicely integrated whole.
Long-term, I think this world would actually put Bevy in a better place than the existing engines. Unity forces you into C# for basically everything, which is both too low-level for non-programmers to use and too high-level for performance-critical code (unless you have a source license, which no indie developer has). Unreal requires C++, which is even more difficult than Rust (IMO), or Blueprints, which as a visual programming language is way too high-level for anything but the simplest logic. Godot favors GDScript, which is idiosyncratic for questionable gain. I think Rust and Lua (or something similar) would put Bevy in a Goldilocks spot of having two languages that cover all the low-, mid-, and high-level needs well.
As for the other parts of the article, I disagree with the ECS criticism; ECS has some downsides, but the upsides outweigh the downsides in my view. I do agree that Bevy not having an official editor is an ongoing problem that desperately needs fixing. Personally, I would have prioritized the editor way higher earlier in Bevy's development. There is space_editor [2] now, which is something.
As for ECS, it's not really about upsides or downsides.
It's about the fact that Rust effectively forces You to use ECS everywhere, because 'normal' game objects interacting won't fly under borrow checker.
And no matter how many upsides ECS can have, being forced to use it everywhere, rather when You want to, is the painfully part.
Would it be possible to create a generic way to script Bevy? I'm sure there are a lot of people who are going to want to use C#, C++, or something else. I could imagine running a runtime in-process and Bevy communicating with it over a socket.
I mean, if you agree that the ideal for bevy would be lua integration, you are kinda agree with the author that Rust itself is suboptimal (at least in layer of game scropting), don't You?
I think whether you prefer Rust or a scripting language like Lua for high-level game logic comes down to what your needs are and personal preference. There are reasonable arguments on both sides.
Gaming is C++ first and foremost. All other languages suck, except when used to script game engines (C# in Unity, etc.). There's no practical reason to choose Rust or anything else. I don't think Rust is particularly bad or good here. There's decades of work to catch up on. I don't see Rust becoming a truly great language for games unless it's blessed by Epic or Unity.
First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Linux and Mac support. Start over with Vulkan/Metal.
Exactly. Bevy has the advantage of being built using the "right way" from the start. This makes an enormous difference in the ease of hacking on rendering code.
Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.
Has there been any progress towards shipping Rust on consoles? I know the specifics are all under NDA, but to my knowledge nobody has even hinted that they've done it yet, even among the studios which are openly using Rust for backend or tooling stuff (e.g. Embark and Treyarch).
OP only appears to release their games on PC so it's not a concern for them, but for the majority of developers not being able to fit into console toolchains would be an immediate dealbreaker. I have no first hand information but what I've heard from hanging around people who would know is that Sony insists that developers only use their official LLVM/Clang fork which is customised for their weird ABI.
Rust has had tier 3 support for the Switch since 1.64, I believe. Someone had actually done it even before that but IIRC NDAs mucked up any movement on making that public.
Yeah, that Switch support was added by the homebrew side of the fence though so I don't know if it's something that developers would be able to use in an officially licensed game. Nintendo might not care so much as long as the game works, as mentioned it's Sony in particular that I've heard is picky about which compilers their developers use.
I've been working in gamedev since 2007 and toyed with Rust since 2014. I simply don't think that majority of games, especially indie games, have performance requirements high enough to justify using anything other than a high-level, garbage collected language.
Of course, some titles like Factorio are outliers. But for majority of games time you would spend to work with manual memory management in C or borrow checker in Rust would better be spent on other things.
I have a simple question that maybe someone smarter than me can answer confidently:
If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?
Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.
I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.
Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev, and I'm new to Rust/Bevy/ECS/gamedev, and rationalized my effort by noting there's not a lot of complex simulation games running in browser (that I'm aware of).
It's not clear to me that I've made the right decision, and just need to take the good with the bad, in order to develop the type of game I want in the type of environment I want.
If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need.
I'm aware of Phaser and evaluated it, but didn't try prototyping something out using it.
My primary concerns were: lack of any coherent plan towards supporting WebGPU, TS bindings being best effort rather than being written natively in TS, and, crucially, Phaser4 being stuck in development hell.
Phaser 4 was announced in 2019, https://www.patreon.com/posts/28467752, and hasn't shipped. Current version on GitHub is v3.8. It made me deeply uncomfortable planning to build ontop of an engine that's stalled out for 5 years. I would not reasonably expect to be given support for WebGPU ever and I strongly feel that WebGPU is going to be the defining way web games are written in the coming year(s).
I also wasn't able to find any super compelling games written using Phaser. Since I evaluated it, it appears that Vampire Survivors was written using it, but then they abandoned Phaser and adopted Unity in v1.6.
> because the thing you might need to do is not available in the place where you're doing the thing
I noticed this with Rust. That sometimes Rust forces you to pull some things up the call stack in order to access them. Even if the semantics of what you do is the same Rust doesn't let you have things in arbitrary places.
It's super weird and possibly annoying when you hit it for the first time but if you stop and think about it, the place where Rust forces you to put it is a really good place from architectural standpoint.
It basically prevents you from taking parts of a thing and delegating responsibility for them to some children, which seems restrictive, but it provides you with consistent structure of where to look for things that are responsible for something.
Rust is restrictive in so many subtle ways (and some obvious ones) but I haven't seen one where it leads to worse outcomes. Maybe I have too little experience.
There are vanishingly few reasons why anyone wouldn't use a garbage collected language in modern software. I think a lot of the people using rust haven't realised how much this limits its utility. As a result of this, the language has been presented as much more widely applicable than it actually is.
100% agree. I am amazed how Rust is constantly touted as a general purpose programming language. In theory that's true, but in practice it only makes sense for projects where you would otherwise reach for C++.
I'd be interested to hear the author's take on Nim [1], which seems to be better suited for game development than Rust by staying out of the dev's way [2], and supports hot-reloading (at least in Unreal Engine 5) [3]?
I decided that Rust wasn't for me after a week long side project. But I doubted myself for a long time, as Rust seemed like such a great idea for so many reasons and it seemed like a bunch of other people were using it successfully. So I'm glad to see this article and know that it wasn't just me.
The Rust community is one of the top arguments against rust.
I've never before been so condescended to as when attempting to ask questions there. Their lack of care for perf also drives me up a wall. Anytime they propose adding an extra layer of indirection to get around the borrow checker, I have to explain yet again that with the way modern CPUs work, extra layers of indirection have serious cache-related perf costs. Then I get told that I am yet again doing it wrong, computers are fast enough, and I am worrying about the wrong thing.
Could you please give an indication of which venues you've encountered this kind of condescension in? I don't tend to see this in the spaces I frequent, but I know it is happening, and I wish it weren't. We try, sometimes, to provide some official messaging discouraging this kind of condescension, but perhaps there's something more we can do.
I don't do this usually because it's not constructive and incites flamewars, but since it was asked, this is whats 5 minutes of browsing comments got me.
More handwaving of Rusts shortcomings. Plus contradiction on the same sentence:
> "Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style."
Many of us have probably heard that all the dumb programmers use Javascript, but even if that's true, that's a reason for me to use it. Even though I'm capable of using galaxy-brained language ecosystems, I don't need that mental overhead. And if it'll be cheaper to hire JS programmers onto the team, great.
> ECS in Rust has this tendency of turning from something that is considered a tool in other language to become almost a religious belief.
I think bevy ui is the best example to give, it's like nobody ever did a ui framework with a pure ECS before. You can conclude either that's because it makes no sense to do that or that's because nobody has ever came up with the right way to do that. The bevy community thinks it's the latter.
It's especially concerning because they constantly talk about the editor, even though they don't even have any of the fundamental pieces for a gui framework in place. In bevy ui there is no way to create a reusable ui component, there are ways to do it but they all suck. So it's not even a matter of a lack of widgets or something, the problem is you can't even write a reusable widget, there is no foundation for a ui framework, and there isn't even a real plan to change it because nobody knows how to write a gui framework with a pure ECS.
But even if they figured that out, things like text input fields can't be properly implemented because there is no proper text rendering engine in bevy so they have to rewrite that first. Except that all rust text render/layout solutions in rust (it has to be pure rust because wasm/because it's rust) are still very experimental and immature.
It's a huge pain in the ass, people write games in rust because they want to write rust, not because they want to write games.
Just waiting for someone to write a 5000 word essay on why they are moving from Rust to do data science stuff. Totally puzzled by everyone trying to get on to the Rust bandwagon on DS/DE, when being able to iterate and make changes fast is why Python rules even though it is dog slow.
Why do you think it is dog slow? Most of the ds/de libraries are in C/C++, with python just calling.
I personally checked JSON parsing with Go/Rust/Python. Guess who won.
I would love to make it possible to bypass the orphan rule in general, including for crates published on crates.io. This is an important issue for ecosystem scaling, in many different ways.
It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrapper. Usually, whichever library is less popular ends up adding optional support for the more popular library. This is, for instance, one reason why it's really really hard to write a replacement for serde: you'd have to get every crate currently providing optional serde support to provide optional support for your library as well.
In other ecosystems, you'd either add quick-and-dirty support in your application, or you'd write (and perhaps publish) an A-B crate that implements support for using A and B together. This should be possible in Rust.
Is the orphan rule a result of some technical limitation? Or just the idea that it's "unclean" to implement someone elses traits for someone elses types?
Unity is so good and quite affordable, basically there’s zero upfront risk of using it. Similar for Unreal Engine. And then there are tons of other open-source engines like Godot that are also quite good.
Rust is great from lots of stuff but game development or building UIs isn’t among that (yet).
Unity learned that they have to turn the temperature up slower. They kept the new license that everyone was mad about but just made it so you can keep your current license if it's cheaper for you. No doubt they'll be tweaking these values over time.
To be fair, building UIs with iced-rs is getting better by the minute. My favorite showcase for using that library is this IRC client called halloy: https://github.com/squidowl/halloy
I wonder if Rust is just much better suited for making game engines than it is for making games.
The relative abundance of game engines made in Rust compared to actual games is a bit of a meme, but I think there's something to it. Maybe Rust's feature set is just not the best fit for gamedev, for reasons outlined in TFA. Maybe it means that game engines built in Rust (which I do feel Rust is well suited for) should try to integrate an interpreter for some higher level language, IDK.
Absolutely agree with the comments on ECS and Bevy in particular. I tried getting to grips with it for some time, doing things the Bevy way, and it just felt like a big step backwards because it’s not suitable for most things. The renderer was really slow at the time too, although I imagine that has improved. Switched to plain rust + vulkan (via ash) + dear imgui and haven’t looked back.
Some of those issues with Bevy might have more to do with its immaturity. It still needs at least a few years to be a solid choice for all sorts of games, in my opinion. I do think the hype should be toned down; people shouldn't feel pressured to worship Bevy or Rust or whatever is the hot new thing.
Can you please give an example of that? Rust is very much advertised as a systems programming language. Can't really blame people for using it and going "oh it's harder than go and python"...
I would think a modern systems language such as Rust wouldn't require a systems development methodology from the 1970's. There's no inherent reason you shouldn't be able to rapidly prototype a system and then refactor the prototype into your actual implementation.
Yeah, I rather like the pattern of embedding a more rapid iteration scripting language on top for game stuff like Lua or stripped down Python variants, using Rust as the core and hot loop code. That said, there is a lot of folks wanting to do it all in Rust, and the article touches pretty well on that not being the pleasant case for a lot of valid gamedev approaches.
This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, the language has to be designed with this property from the beginning. Yes, you should always enforce complete checking in CI. But you should also be able to try half-baked ideas.
There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing.
The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest.
[0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program."
> Type checkers shouldn't get in the way of your code compiling.
I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed.
I understand (and have used in production) optionally/gradually typed languages, and without fail codebases will opt for using types up front and not ignoring type check failure because they are always incorrect.
A type error is the compiler/run time telling you "I don't understand what you told me" so why do you want to ignore that?
And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with. It should be easy to pull in what you need and play with it without affecting everything else if you haven't done a bad job of architecting the codebase.
Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good.
Sometimes, it's useful to bypass these things for a prototype and you don't care if it crashes on any edge case. This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code
>I don't get it, what's the point of type checking if not to reject invalid programs
It can take longer to think about how to properly type instead of just writing some code, testing it out, and immediately seeing if something is wrong. You also often get into a situation where linters who like to act like type-systems give you arcane errors (looking at you TypeScript).
In the moment I just want to move some data around and quickly try out an idea, I don't need it to be resilient or perfect.
>And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with.
The article addresses this, multiple times. In brief, the "poor structure" isn't the problem.
It's also pointless to care about types in fine-scoped code. Like if your language forces me to assert that i is an integer like this, something is wrong...
for (int i = 0; i < n; i++)
And when I'm writing backends, usually there will be no types anywhere except at the API layer, i.e. OpenAPI spec or protocol buffers. Not once have I encountered a bug related to accidental wrong types that wasn't caught at this outermost layer.
Great article, but on ECS I thought the primary point of using it was locality of memory so that you don't get cache misses during iteration of elements. Yes you are preferring composition over inheritance but I thought that was more of a side-benefit to the main thing ECS was trying to solve.
> being unable to just move on for now and solve my problem and fix it later
Same thing about Golang "unused variable" and "unused import". So many times I just exploring a lib and trying things out with no intention to leave it as is, but no, Go forces to "write good code".
I mean, I'm no fan of Golang (I actually kinda hate it), but this is easily solved with a blank identifier (underscore `_`) or by commenting the line. Both of which makes it blindingly obvious when doing code review.
Golang falls in the camp of enabling fast iteration while also enforcing some sane basics. Letting off an unused variable/import with a warning is a recipe for insanity, anyone who has opened a badly maintained Java codebase will tell you this.
I use Nim at work. It is a joy. I replaced a prototype Rust application which was confirmedly not a joy. None of Rust's highly opinionated safety semantics necessarily imply a better end product, and often make delivering an end product much more difficult. Rust has use cases, but it is a specialized hammer for a specific domain of nails. It is not the cure-all everyone wants it to be.
If you're asking if you should use Rust and you don't have a highly specific embedded use case, you should probably just use a language with decent RC or GC. As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all. Business logic, clean and bare.
> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all.
This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pass to ignore hardware limitations.
Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.
My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.
Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.
I don't use Rust for game dev but I do for low level libraries and find it easier than C++ to get started. I have enjoyed it more than Java and like it for different reasons than Go, but it feels good to program in.
As for the design patterns that a complex game requires, if you are considering Rust for game dev and ecs design patterns it might be useful to check out projects that are Rust centric like https://spacetimedb.com/.
I had this same pain point though when using Rust that was meant to run in the browser (compiles to WASM), i.e. guaranteed to be single-threaded.
Still had to pay the very high price of accessing global state in Rust.
Ended up moving that code to JS instead just to avoid that!
As someone in a similar position (also ~3 years doing gamedev in Rust but only free time + open source), I feel very similarly.
There's low hanging fruit i've been complaining about for years where Rust is protecting us from ourselves - orphan rules, global state, ... Look, we're adults, we can make decisions with tredeoffs.
Compile times are a tougher one, I understand that Rust does analysis that is more complex than many langs and i feel ungrateful to people who spend their free time improving Rust. But also i don't think the complexity justifies all of it. Make dynamic linking easier, reduce how much needs to be recompiled, compile generics to dynamic dispatch in debug builds, etc. - there's gotta be a ton of stuff that can investigated.
ECS just plain sucks. People use it because what they want at first is some way to have relationships between entities. References/pointers are the obvious solution in most langs but in rust, they're obviously out. The second option is Vec and indices but that falls apart as soon as you start removing entities. The next step up the ladder of complexity should be generational arenas but for some reason people immediately reach for the big guns - ECS. And it infests their game with two things that make gamedev a slog - dynamic typing and boilerplate.
Boilerplate is obvious to anyone who has done gamedev the "obvious" way before. What could be projectile.shooter.score += 1 is multiple lines which (depending on your particular choice of ECS) usually involve generics. You shift your focus from tweaking your game logic and tuning the experience to typing out boiletplate.
Dynamic typing means entities are no longer structs with fields where you can understand how they relate to each other at a glance but instead any component can be anywhere, entities are no longer real, refactoring always causes silent bugs.
However, by far the biggest issue is the community's handling of criticism.
There are practically no experienced gamedevs coming to Rust from other langs so there's nobody to give Rustaceans a reality check. Rust gamedevs are almost always writing their first game (or, yes, engine). And there's nothing wrong with that, i was writing my first game at one point too. But their attitude is that they chose Rust because they heard it's the best and they got invested in the language because it's hard(er) to learn and now with all this investment if they hear rust or their particular favorite engine might not be that great, it feels like wasted effort so they get emotional and defensive.
I've personally chatted with over half a dozen other gamedevs who came to rust with years of experience under their belt and a common pattern is that they avoid the rust (gamedev) community because they're beat down by the negativity heaped upon them every time they try to discuss the negatives. It doesn't matter they take every effort to offer constructive criticism, it becomes a social instead of technical topic.
I came to Rust because i care about code correctness and, well, quality (of tooling, docs, testing). And Rust delivers there on a lot of that. But i also wanted to write games of a larger scale than can be done in one person. My hope was that there'd be other people with the same values who wanna build cool games together. Instead there's a low single digit number of serious open source projects and a bunch of small one man games and a a whole lot of loud people who seem to think gamedev is about hyping up an engine like it's a sports team.
Myself, I apparently chose the wrong engines for my games in both cases. Not because they're bad technically. In fact, having 5 years of gamedev experience before Rust, i think my choices are better from a technical perspective but there's just not the critical mass to build a serious open source game around them.
This article hits every note of frustration I've gotten with rust.
It honestly feels that if you want a somewhat memory safe language for more general purpose use cases good'ol fashion Ada or maybe ziggs (or if carbon ever become a thing) seem 100% more approachable than rust for gamedev or gui.
The only way I see rust becoming dominant in gamedev/ui is by sheer brute force.
I'm a Rust enthusiast and really surprised to discover so many people are apparently trying make games in pure Rust.
I think Rust is an amazing language for building a generic game engine, but a pretty crappy one for actually implementing a finished game.
Isn't it basically standard practice to have an engine written in a systems-level language with generality, reliability and performance as the top objectives, and the game itself written in a scripting/interpreted language that allows very quick iteration?
And it can even in many cases be a pretty horrendous home-brewed language. Despite having people without the computer-science knowledge to create a good language (and yes, inventing a new language is one of these things that leads to horrible results if you just learn on the job). This structure will still get you there easier and faster than trying to implement the whole game in a systems language.
I've always been fascinated by games and I've always loved programming but except for the beginning I've never combined the two. And the issue with game dev and functional languages not seeming to jive with each other always seemed (from the outside) to mostly be one of established norms conflicting with each other on both sides. I'd love to have time to explore this; for example one complaint the author makes is about passing around the game state but then also needing to pass around sub-parts of it and Rust complaining; this would be trivial or a non-problem in Elixir, but I know that's because there's no mutable state and in Rust's case it must deal with mutable state regions because all of game dev assumes that's available (or it must be by necessity for performance reasons).
I see some of those things could perhaps be solved by implementing parts of the game in a sandbox. I know that's work: I'm doing it myself. But all the work with the host-guest boundary (let's not call it bindings, please), is worth it in the end.
I have a C++ game client, a C++ game server, and a shared C++ game script that is transferred to all clients, running in a RISC-V emulator. That means the script will fundamentally execute the same way on all clients, and the server. I have no idea what everyone else is doing. This is what I'm doing now, and the more fleshed out it's becoming, the more I actually like it this way. I don't think I could easily "go back" to other solutions.
Rust being the best alternative to C++ is why I'm wildly rooting for Mojo. This language sacrifices a lot in ergonomics and UX to the alter of safety. And the Rust community never fails to interject with "Well, Akshually..." whenever you complain.
Rust is good for software following a strict spec and design doc. A lot of what I do is exploratory in nature. Rust sucks there, fighting me. Best kind of languages in those cases are Lisp, Python and (unironically) C with Visual Studio debugger.
I don't have nearly the same amount of experience with Rust (just a few months of hobby coding), but whenever people looked at me, all surprised, that I don't like Rust that much I always just said "Safety is not the most important thing for everything. For the stuff I am doing I'd rather be quick", but this article is the most thorough way of explaining that I have seen with lots of extra stuff I had no idea about before. Also the extra random gamedev links in the middle were great, but it took me well over a full, focused hour to read. It is thorough, but some more brevity might have helped, I think.
Like the author states, the "written in Rust" bonus many projects get does not apply to games. Most of the games I consider to be the most fun are built on an absolute rats nest dumpster fire of code (see: https://www.youtube.com/watch?v=k238XpMMn38). Sometimes bugs even expand game mechanics and make them more fun and expressive. That being said I'll definitely check out Unrelaxing Quacks, it looks great.
I tried to get Jonathan Blow engaged in the Rust RFC process to improve productivity for gamedevs. However, he thought it was a better idea to start working on his own language (Jai).
When I did some research for the Piston project, I learned that there was a productivity technique called "meta parsing" which was used in late 60s to develop the first modern computer. This was before C. The language was Tree-Meta. Viewpoint Research Institute upgraded it to OMeta.
I thought OMeta was too complex, so I developed Piston-Meta, an alternative for Rust using a simple data structure: Start node, end node, text, bool and f64.
My favorite thing about rust is when rust devs say that the slow compile things aren't a big deal and then show how that just by dropping a few dependencies you can get hello world down from 90 seconds to 30 seconds.
Thank you for this. I have been having some engine indecision. I am more of a programmer, so I was thinking that learning rust and bevy would be superior to learning godot, but it seemed like a really deep rabbit hole to go down, and I was concerned from the lack of actual games that were coming out of it.
Your blog post really explained the reason why quite clearly, thus eliminating a journey that would be fraught with difficulty and seemingly with little return.
I am going to go with godot and hopefully that works out for me. Thank you again for sharing your experience.
I am happy to be honest that I have not spent much time of rust, other than browsing sample code and reading about user experience, the borrow checker, etc.
For me, I could not see myself using rust especially for game development. Some of the points raised are my concerns, especially wanting to chuck something together (to improve later) only to fight the compiler, etc.
I would be interested to know what language they choose moving forward. It seems the contenders are likely to be:-
C - because, you can,
C++ - ditto,
D - I think it is largely ignored, and there is the betterC flag
Zig - Seems interesting,
Odin - Also interesting
Anyway... going to enjoy reading the comments, now.
It's possible to abuse 'transmute' but .clone(), .unwrap(), Arc<> are full-blown language features, so using them is not 'abuse' of any kind. They're part of how Rust supports quick iterative development, along with Any (for dynamic objects with downcast) and still others.
Interesting to me to have [iteration speed] <--> [maintainability] spelled out as opposite ends of a spectrum... and that sometimes [iteration speed] is the right thing to optimize for.
All low-level languages (by which I mean languages that offer control over all/most memory allocation) inherently suffer from low abstraction, i.e. there are fewer implementations of a particular interface or, conversely, more changes to the implementation require changes to the interface itself or to its client [1]. This is why even though writing a program in many low-level languages can be not much more expensive than writing the program in a high-level language (one where memory management is entirely or largely automatic), costs accrue in maintenance.
Now, a language like Rust makes some aspects better because it ensures that the maintenance (refactoring) is done correctly -- reducing the risk of mistakes -- but it comes at a cost: you must explain your handling of memory (before and after the refactor) to the compiler (plus, the compiler doesn't understand all patterns). I think it's too soon to empirically compare this cost to the gain in reduced risk and determine when each option is more or less advantageous (and perhaps it is also a matter of personal programmer preference), the fact remains that maintenance of programs in all low-level languages is always more costly than maintenance of programs written in high-level languages because of the low abstraction inherent to all low-level languages.
When writing in a low-level language some may prefer the Rust approach while others may prefer less restrictive ones [2], but people choosing any low-level language should be aware of the added maintenance cost they're invariably signing up for. Sadly, this cost only becomes apparent at later stages of the project.
[1]: Some people claim that memory is just like any other resource (e.g. file descriptors), but this is incorrect. Memory and processing are fundamental to the very nature of abstract algorithms, and differences in how memory is handled change the available range of algorithms. E.g. finite state machines, queue automata, and Turing machines differ only in how memory is handled and accessed. In short -- memory and processing are special resources and are not the same as IO resources.
[2]: I'm personally not a big fan of Rust's approach -- and I particularly dislike C++'s and Rust's "zero-cost abstraction", which is the attempt to make the low abstraction ability invisible in the final code without changing its fundamental aspects -- but I recognise that people's opinions differ on this matter. I also reject the claim that there's no middle ground between Rust and C that offers an intermediate tradeoff between them, i.e. that there is no safety premium to a language that offers some of Rust's safety guarantees but not all of them, such as Zig, or offers better and effective assurance of some properties without a sound guarantee.
They should open source their game engine. That way we can learn from their mistakes. How can we be sure this is a shortcoming of the language and not the APIs the author is working with?
Anyway - no one is going to ship a game written in Rust with this attitude. To the other folks out there happily writing their games in Rust - don't be distracted! All it takes is one success story to prove the concept :)
Personally, I found using Godot with some parts in Rust via gdext quite enjoyable.
You can avoid dealing with GDScript for important parts of the code and have access to OS threads if you want them, etc. - but can also prototype features in GDScript and write the UI, etc. there for fast testing, and keep a good separation of UI and graphics presentation vs. the actual game logic.
I don't think it holds them back. Rust is just not an amazing special tool for game dev it seems, doesn't matter how the community behaves. It's still a solid choice for systems.
Reading the part about global state reminds me of some of my thoughts building backend web apps. Not having global namespace pollution is fine, but not having any global registry of some sort can make things far harder for the size that most things are going to be.
Author here, sorry about that, I just deployed a fix, should be readable now. If it's not, here's the first few points
- Once you get good at Rust all of these problems will go away
- Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker
- Indirection only solves some problems, and always at the cost of dev ergonomics
- ECS solves the wrong kind problem
- Generalized systems don't lead to fun gameplay
- Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
- Procedural macros are not even "we have reflection at home"
- ...
the list corresponds to the titles of sections in the article.
Can you not curate an opinionated subset of C that enforces all of Rust's rules so that you can have a safe variant of C, just by removing flexibility and enforcing some programming patterns?
I also had the same bad experience with Rust outside of Gamedev. Probably a lot of other people too, but people don't talk about it much, because the Rust community is the most religious programming language community I've ever seen in my life. Before Rust, the Scala community was also pretty bizarre (Java too for a while), but nothing was on Rust's level. The worst part about Rust isn't technical, it's the crazy community. You can see in the article that the author tries to explain everything at every point, trying to escape the problem "If you don't understand something in Rust, you're holding Rust wrong."
Of course, there are many people in the Rust community who are not religious and try to improve the language, but my general feeling after reading a lot about Rust is to stay very far from the church of Rust.
I mean, your comment is actually contributing to the problem. You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that.
It's fanning the flames and just doesn't really help.
I've been writing Rust professionally (and predominantly) for ~5+ years now, with brief detours in game dev. I'll defer to others who are dedicated game devs, but overall I think this article is well written and a healthy thing for Rust overall. We need this kind of breakdown if things are going to continue to improve.
I'd say I only have two somewhat arbitrary comments on this piece:
> Rust on the other hand often feels like when you talk to a teenager about their preference about anything. What comes out are often very strong opinions and not a lot of nuance.
This is a rabbit hole of a topic so I don't want to go too deep into it, but this isn't a Rust-specific issue (though it may be a current Rust issue). I've seen this same pattern play out across so many languages over the years, from Lisp to Rust to everything in between.
A very unscientific and definitely not charitable way I've thought about this over the years is that programming, by nature, is an OCD person's dream. We wind up with a pretty large chunk of people who seemingly move language to language in the hype cycles in search of some weird nirvana level that is likely just unobtainable. I feel like Rust has slowly started shedding this as the community has grown/matured and some people have moved on to the next hype cycle but I often find myself wishing it'd happen faster.
I write Rust because when I sleep at night, I just don't get woken up by being paged for nearly as many weird edge cases. The Rust I write often has a litany of compromises because I want to just get shit done and move on with my life, and the remaining guarantees are still good enough. The number of times I've had to tell people to leave it be is definitely higher than it should be.
> I know that just by saying "global state" I'm immediately triggering many people who have strong opinions on this being wrong. I feel this is one of those things where the Rust community has created a really harmful and unpractical rules to put on projects/people.
This isn't really a Rust-specific thing, though I can't fault the author for including it. People have been beating the drum of "no globals" for as long as I can remember... and simultaneously, as long as I can remember, game devs have come out of the woodwork to politely explain that the programming they do is often under very different constraints.
I still periodically use global state for things because it's just faster at points, and no, I've never cared if people get annoyed by it.
Anyway, here's to hoping this leads to positives for the community.
Very interesting article but I feel the need to question some things.
- The very first thing that comes to mind is why actually use Rust for gamedev. From the article it seems like the author got into Rust through Godot, but that does not explain why commit to use Rust for a full game. What was the reasoning behind picking Rust?
- It feels to me that there's a mix of criticism to Rust as a language, Rust as a community and libraries/frameworks written in Rust (in particular Bevy). Personally I think these are completely separated matters so I would like to know why the author treats them all as a unit.
- I've always got the impression that gamedevs try to have their cake and eat it too which is almost always impossible: they want to have quick iterations and write "simple code" while having low level control of everything (ex. manual memory management, usage of pointers, etc.). For example, the author mentions wanting access to methods like "play_sound()" but at the same time mentions that some patterns are unacceptable given the "overhead [...] due to memory locality". I've never heard of an ecosystem where you can have everything without any compromises.
- In particular, I get the impression that the author has a lot of troubles with ECS and instead it tries to bend it to work in a OOP fashion (for example, through the usage of "fat components" as he calls them or preferring virtual dispatch over `match` statements). He claims that he has put in a "lot of time" in trying to make it work but I get the impression that this effort was mostly wasted in trying to bend the language and libraries into something that just won't work out. It's like trying to use a circular saw to polish mechanical watch pieces: an exercise in frustration. At some point in time I'm sure he asked himself why to keep on pushing on, and I would like to know why he continued to be committed to such process.
- The author claims multiple times that they work in a single threaded environment where they should not care about concurrent access so they should not pay the price in the type system. I agree that this should be the case but then it proceeds to list examples that show a different situation. One of them is the claim that they cannot use a "god" context to pass down every dependency due to the borrow checker, listing code that tries to hold a reference to a "camera" system while passing the context to the "player" system. In particular this does not make sense because: 1) If you're in a single threaded environment you don't have two systems using the same context at the same time (because there is no "at the same time"); 2) if the "player" system does not need the camera then it won't change it, and if it does not change it then there is no need to take a reference to it earlier, you can just take it after the "player" system has finished. I know that coming up with brief examples is extremely difficult but either the example does not properly represent the reality, or the author is actually working in a multi threaded environment (maybe without actually knowing about it).
As an observation, the author mentions multiple times that Rust pushes you to write "good code" and I fundamentally disagree. "Good code" is very contextual, just like the idea of "simple code" where he checks for all collisions and plays a sound in 3 lines (is this actually "simple"?), so instead I would say that Rust forces you to write "correct code", that is, code that won't (or is unlikely to) fail at runtime. I believe this is a very important distinction that you always need to keep in mind when evaluating a tool such as a programming language.
Finally, I do believe though that Rust is a bad choice if what you're interested in is to build games quickly without consideration for performance (and you most likely don't need to care in 2d games) and their decision is very reasonable: C# and Unity are just aligned better with what the author is actually interested in doing.
I’ve only done a few toy projects using ECS, but the author seems to be struggling with ECS on a basic conceptual level. E.g.,
---quote---
For example, modelling Health as a general purpose mechanism might be useful in a simple simulation, but in every game I end up wanting very different logic for player health and enemy health. I also often end up wanting different logic for different types of non-player entities, e.g. wall health and mob health. If anything I've found that trying to generalize this as "one health" leads to unclear code full of if player { ... } else if wall { ... } inside my health system, instead of having those just be part of the big fat player or wall systems.
---end quote---
The solution here is to have a Health component but not a generic Health system (actually, a generic Health system sounds like a code smell for another reason, because systems map to actions, while components map to attributes; systems that interact with a Health component would be things like a damage or healing system) -- but if you need something to work different for player health and wall health and enemy health, you can just have three systems, which, respectively, do Query<Player, Health>, Query<Enemy, Health>, Query<Wall, Health>.
Excellent article. Rust is my favorite language for several uses, but I'm becoming less optimistic about it as a versatile language long-term. An important point regarding the article is that it mixes rust shortfalls, and shortfalls of any language other than C++ for games. I've personally used Bevy for a 3D wave function renderer, but moved away from it in favor of a custom WGPU-engine due to Bevy's complicated ECS DSL.
I am worried because:
- Games seem like a no-go, as articulated in the article
- Web usage has been dominated by Async, with no signs of reversing. I have no interest in this. And, there is no promising Django analog or ORM.
- Emebedded support on Cortex-M, and to a lesser extend RISC-V is good at its core, but the supporting libraries have a mix of A: the game failures listed in the article (Driven by hype, mostly makers, serious companies are not using it), and B: Also being taken over by Async.
This is disappointing to me, because IMO the syntax, tooling, and general language experience of Rust is far better than C and C++.
Someone who has experienced real problems as a result of a specific mechanism is not required to solve every single problem with alternatives to that mechanism before saying "this mechanism has caused me real problems and it'd be nice if there were a better alternative that didn't cause those problems".
> The moment you allow this, you have to find a way to pick between several implementation - and they don't always have sane names.
There are other possible solutions that don't involve that.
For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.
A slightly more sophisticated rule would be "Identical implementations are allowed and treated as a single implementation". This would be really convenient in combination with some kind of "standalone deriving" mechanism, which would generate identical implementations wherever it was used.
Disclaimer: I'm aware you guys are working on relaxing orphan rules, and I wish you the best of luck. But as an outsider, orphan rule doesn't seem to be going anywhere soon.
And if the original poster had said that I would be ok. Instead what they said is:
> It's a great example of something I'd call "muh safety", desire for perfection and complete avoidance of all problems at all costs, even if it means significantly worse developer ergonomics.
This implies the writer didn't assume what happens if you "turn-off" orphan rules. I.e. you don't trade perfection for developer ergonomics, you trade one set of developer (ability to write any trait for any type) ergonomics for another (having to battle two incompatible trait implementations from crates you don't own).
Either you have to manually specify how nearly every implementation is pulled (horrible developer ergonomics) or, even worse, you go into monkey patching territory.
> For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.
Ok. But you still need a resolution mechanism to fix the error. Which implies manually solving ambiguity. And how do you solve it for blanket implementations?
Yup. Rust is too complicated. You don't think about getting the job done, you think about language specific crap that is just overhead. And it's ugly to look at.
I tried to like it, but I can't. It doesn't align with my way of thinking.
I've been thinking of embarking on a Rust/GUI/Game. Guess, this will save some grief. Is Rust the future? Will this situation improve? I've been wanting to like Rust, but this seems to be indictment.
On the "hot reloading" remark: I believe that, to some extent, compiled languages that lean into metaprogramming are innately at odds with the concept of hot reloading. You're spitting out a (mostly) monolithic binary - rewriting that on the fly just isn't going to be reliable beyond an extremely basic level, and shoving it all into some kind of VM for the purposes of hot reloading introduces variance and general performance overhead that both mean that the "hot reload" environment is no longer an accurate depiction of the real application's behavior.
You do need memory safety for multiplayer games, though. Either that or you should use a GC language, which frankly is good enough for most indie games.
This is missing a few useful ones, like Box<str>, Arc<str>, Cow<'a, str>, SmallVec<u8>, transmuted newtype references like &UserId, and of course the string type you implemented yourself because the previous ones were not good enough.
I think there's a certain type of mind that can truly appreciate Rust as a language and enjoy developing with it. When I see quotes like,
> I wasn't thinking "what's the right way to get a random generator in here" or "can I assume this being single threaded" or "am I in a nested query and what if my archetypes overlap", and I also didn't get a compiler error afterwards, and I also didn't get a runtime borrow checker crash. I used a dumb language in a dumb engine and just thought about the game the whole time I was writing the code.
and,
> The prevalence of perfectionism and obsession with "the correct way" in the Rust ecosystem often makes me feel that the language attracts people who are newer to programming, and are easily impressionable.
I see someone who simply does not think about those kinds of things when writing code. And that's completely, entirely fair. Rust is not for them, then.
But they seem to act like it's an issue with the language that it does not serve them specifically, and their way of thinking in particular, not even pertaining to game development.
Because the thing is, I don't suffer from the issue they're describing. I don't find it difficult or distracting to think of edge cases and implementation details when I am writing out a solution. In fact, I can't help it. I love Rust, because its strong typing and strict static analysis actually support and justify my way of thinking. They're not obstacles for me to overcome, certainly not like how it's described here.
When I use a language like JavaScript, people tell me that I care too much about details or that I don't need static type information because I can just assume. JavaScript is not for me, because it doesn't support my way of thinking. It is terrible and sloppy and completely unchecked. It's absolutely great for banging things out without giving a care in the world about a single implementation detail that isn't relevant to the actual problem at hand. It's terrible if you actually do care about those implementation details, because nobody else who writes JavaScript does. Everything you interact with is going to be just as shoddy as the language itself.
(I have a job writing JavaScript, so this doesn't mean that I can't use the language. It just means I do not like it. I do like TypeScript.)
So this might just be a fit issue. I haven't read the rest of the article yet, because this stuck out to me. I see some other HN comments talking about async code and GUI libraries, and those are all completely valid concerns, but in the article these valid shortcomings are seemingly mixed with what I'm going to call "neurotype issues". In other words, I suppose the author just isn't autistic enough. It has nothing to do with being new to programming or not.
And that's fine. It's just not an issue with the language that it doesn't serve you as well as it serves others. After all, Haskell is the same way. I'd say most programming languages are the same way.
The TLDR I got from that: Normal coding has two concerns:
1. What behavior do I want?
2. How am I implementing that behavior?
Experimenting with #1 is slowed down by the current end point of #2. Sometimes not at all, sometimes a lot, depending on luck and how #2 anticipated the class of experiment I am trying.
Rust adds:
3. How can the implementation code be organized so its stringent safety checks are validated?
Now experimenting with #1 is complicated by two dimensions of design history instead of one. And the latter dimension being two steps of abstraction/design-dependency away from concern #1, is going to be very brittle.
> The problem you're having is only a problem because you haven't tried hard enough.
You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.
> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
Not only this, but they openly mock other language communities for not drinking the koolaid.
I like Rust, and the Rust community, and fasterthanlime, for what it's worth. But I think these points raised in the article are very much valid.
Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Some of these communities/forums are just inhabited by people who thrive on dunking on noobs all day long. The good news is that they tend to get bored and move on when the next new thing comes out.
I'm already seeing this in my local Rust community as the chronically online people are moving on to Zig now. They even use one of the Rust discords to advertise their Zig meetups and proselytize about Zig at every opportunity. Eventually they'll get bored and move on.
> > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
I don't fully agree with this assessment. In my experience, Rust community members who arrive with well thought out complaints or suggestions are welcomed by the people who like working on programming language fundamentals. You can nerd snipe a lot of Rust enthusiasts by showing up with a difficult problem involving tricky parts of Rust, which will often result in some creative solutions and discussions.
On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language. I've spent a lot of time trying to get people to unlearn habits from other languages and try to adopt the Rust way of doing things. Some people refuse to let go of paradigms once they've used them for years, so doing things the Rust way isn't going to work for them. I've worked with enough people who spent more time fighting against Rust than trying to adopt Rust ways of doing things that I've also reached the point where I don't engage once I see the conversation going that way. Can't please everyone.
"On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language."
This is perfectly understandable if you view languages as tools. If the new tool can't do something the old one did, then you'll have questions about using it. A great example is inheritance - if inheritance is missing, that's a negative for me. I don't care about the philosophy, I just want to use the tool to produce programs better and faster. If it's missing features, that's a negative point.
> What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
Yeah. I think there’s also a weird way that newcomers get treated when they join a community. When you’re a newcomer to Rust, you probably have some preconceptions about how Rust should work based on the other languages you know, and you’re probably running into a lot of the same problems with Rust that everyone else has (e.g. borrow checker).
Most of the community is just kinda tired of the discussion and tired of answering the same questions, so they don’t interact with the noobs at all. That means that the people who, as you say, “thrive on dunking on noobs all day long”, are the primary point of contact for noobs.
Finding a decent programming community these days is a pain in the ass. The cool people, i.e., the people working on cool projects and getting shit done, are mostly busy and not hanging out with anybody.
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
I would say that in general, this type of attitude permeates a lot of software engineering, and even engineering and science as a whole. When I speak with people in other fields, particularly more creative ones, the discussions are so much more improvisational and flowing. Discussions with software developers, engineers, and scientists have this very jerky, start and stop "flow" to them as you meet resistance at each step. I honest to god have had people telling me no or shaking their head no before I ever finished my question or statement, much less before they even understood it.
> There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
You're spot on about the coupling of someone's identity with it. Rust especially seems to also have this never-ending gold rush to be the next framework and library everyone uses, which creates a very competitive landscape. And it seems most frameworks and libraries get 80% of the way and then fizzle out once people realize Rust isn't a magical language that solves all your problems.
Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in.
For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it.
But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the imagination.
If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language?
I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at that, or just inconvenient as the article points out.
That means, it should be used for general stuff, and for programming games should be used a niche language, like Lua, Python etc. Especially for fast iteration and experimentation, break things and move lightning fast, typed languages are in disadvantage for sure, compared to untyped/weakly typed.
>> The problem you're having is only a problem because you haven't tried hard enough.
And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say
Num t => (t -> b) -> [t] -> [b]
is really pretty powerful, and being able to search for functions by type signature is just plain convenient.
But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.
> being able to search for functions by type signature is just plain convenient.
It's certainly not all the way there, but now that we are over the mostly empty promises of encapsulation and (worse) trying to model the world with classes, but grouping by that implicit first argument type for discoverability is exactly what OOP is, in this age of post-OOP.
The "you're not trying hard enough" position reminds me a lot of the Scala community's disdain for java-in-scala-syntax: if you don't use it like an almost-Haskell you're on your own (1). Here, I think Rust is actually more open: I don't read too much of the community, but most of what I saw seemed to be quite welcoming to the idea of placating the borrow checker with refcounting when "the rust way" fails to sufficiently click.
((1) but with Kotlin having taken over the entire not-almost-Haskell part of scala it's not an issue anymore: is has its niche and it fills it well, no more taking over the entire JVM while also magically converting everybody into an almost-Haskellian)
He mentions Common Lisp as something he did a game in, and you can see the link he praises https://www.youtube.com/watch?v=72y2EC5fkcE as basically a very well-developed Lisp image approach with timetravel debugging etc aimed at game dev. So the implicit comparison to Lisps is sort of a big undercurrent to this whole article.
That’s sort of different, right? Rust is just another systems language. Lisp is the language that nobody knows but everybody secretly believes is better than their language of choice.
This was my biggest problem with rust, the community is, at a surface level friendly, but the moment you try to say something against the grain you get met with some of the most insufferable people ever. I tried to mention a problem with a lint on the official forms and the replies were so condescending (from regulars at that too). And at no point did they try to understand the issue, they just assumed I was dumb/new/doing something wrong.
> I'd argue as far as maintainability being the wrong value for indie games, as what we should strive for is iteration speed.
That seems to be the crucial point. Rust is optimized for writing complex systems software in large teams. That’s not a great fit for a small team hacking on something that is at least in part an art project. You wouldn’t choose something like Ada for that either.
I've ended up with similar thoughts about automated testing in games too.
I really enjoy having automated tests and automated tests solve problems. Like, I absolutely love our molecule test suite for our infrastructure code and it gives us huge value. The smoke tests we have for the infrastructure running after deployments are amazing. It's liberating in an environment of rapid and chaotic changes everywhere, complex interdependencies, as well as pressure on top.
However, if I try to transfer that kinda approach to a game it just... fails?
But the realization is: In games, many behaviors and systems are actually far simpler and less intertwined in arcane ways, and code changes actually less frequently and dramatically than at work.
I could see structured testing in e.g. turn based strategy games and such, so you can test that the culture per turn is correctly calculated based off of many different situations and such.
But in many smaller projects I've had, you write some janky code, make sure the enemy behaves as expected... and never touch or change that piece of code ever again. And it just doesn't break, because no fundamental part below it ever changes, because then the entire house of card would fall apart.
It feels dang weird, but it works very well for smaller projects.
I copied this exact same snippet and was going to comment the exact same thing.
Why choose Rust if you don’t care about maintainability and long term stability? Those are core values of the language!
The language choice was wrong from the start. C++ is king for games so if you care more about delivering features and fast prototyping why not go with that?
Maybe Rust is not a good language for rapid iteration in the game industry. And that’s ok I think.
Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style. The flip side of that is once the 'iteration'/'prototyping' phase is over, you can actually refactor the prototype into high-quality production code, instead of either throwing it away altogether and rewriting it from scratch (spoiler alert: this doesn't really happen most of the time, because it's viewed as pointless waste) or just putting it in production as-is (which is what people actually do, even though it's obviously a disaster in the longer run).
No, Rust is pretty antithetical to iteration-based programming. The language basically requires you to plan for the ownership model from the beginning, and it can be quite difficult to retrofit a changed ownership model into an existing program.
I've run into this in a side project I'm working on, where my indecision over which ownership models are actually workable in the API to satisfy the needs I have means almost all of the coding is spent just proving I can get an ownership model working over having a skeleton code that can do something. And still, even as lacking as functionality as this codebase is, swapping to a new ownership model takes several minutes of coding. Trying to do this kind of exploration on a codebase that has real functionality would mean spending hours of change just to move some property from here to there.
Surely there's better choices if the primary desire is iteration speed, and a secondary or maybe even tertiary desire is maintainability/refactorability
Rust gets in the way a lot, as it's supposed to for safety. Maybe it'd be a lot faster to iterate on if some AI could auto fix your code to make the compiler happy.
tl;dr -- Rust is not the language for startups who want fast iterations and are still finding it's pmf. It is perfect for rewrites of popular system software which already has millions of users and running in production because once a software becomes mature and at million user scale, safety and security becomes paramount
> for rewrites of popular system software which already has millions of users and running in production
Hopefully, it's perfect for more than that.
Rewriting a system that's already acheived that scale is a contentious decision, to say the least. Many of our colleagues have been lost to and scarred by well-meaning attempts to rewrite those systems in the past, including many who were sure it was the right choice for "safety and security" themselves. For every conceptual safeguard new tooling might give you, you invite countless and sometimes catastrophic regressions in actual application logic in writing new implementations. It can work out, but no tool can expect to live only on that kind of work.
I'm sure Rust has much broader applicability than that. Or I hope so at least.
At million user scale, feature parity and compatibility is truly paramount and, `rg` aside, Rust utils don't have a great story to tell there. Such software has evolved in the course of decades and its (usually despair-inducing) code is tailored for dealing with a tremendous number of edge cases, platforms and architectures. Rewrites in Rust tend to write "the cool parts" and indeed write them better and faster, but that is just not good enough for replacing the standard tools.
Rust is the "frontend wave" of the backends. All the woke kids gravitate towards it. A suffix of "Written in Rust" is a thing here so I'm throwing away my internet points now.
I work fulltime in Rust (embedded stuff) but actually think the "everything else" influence into Rust is stronger than the systems stuff, and it's harming the ecosystem.
Just try finding e.g. an MQTT or WebSocket or etc library that doesn't drag the whole mammoth tokio ecosystem (which is really geared for Web Scale! projects) in with it.
Rust is becoming the language that tokio ate, and Cargo/Crates.io the new NPM.
That is, Rust is the systems language that a wave of non-systems developers insist on using, leaving behind a trail of non-systems-appropriate crates and projects.
Parent commenter's comment was crap by HN's commenting standards... but the underlying point about trendiness I think is in fact accurate.
It can be though. You should be able to express low-level details but also implement high-level constructs effortlessly should you so choose.
Look at C++, which can both dick with move semantics but also offer multiple inheritance. Even better, look at C#, which has pointer fiddling but also offers the best reflection of any language today.
You're right that Rust is only really good for kernel development but it didn't have to be that way.
I do not complain. I've seen this trend multiple times by now. First time was with Ruby on Rails I think [1], then the cancer that led us to write JS to output HTML and all the good stuff that came and still manages to pour from npm. Every now and then you can spot the "fashion" out of these things.
Rust is good and has earned its place. I just despise cult-like followings for these languages and technologies.
This is a decent article, but although the points themselves are valid, I think there's a core "issue" with (indie) gamedev itself.
The vibe that I'm getting is that it's filled with people that don't particularly care about programming, they just want to get stuff done(TM), this is also highlighted by the fact that they are willing to write completely inadequate code just to see things working. Rust is not that, and that's a good thing.
More generally, I'd say that in gamedev anything goes, as long as it's fun and isn't too buggy. Rust is not, and never will be able to accomodate that mindset, which again, is a good thing if you think for 2 seconds and consider what Rust is actually aimed at, which is safe systems programming.
You can have the core engine written in Rust and have a scriptable language on top of it, there aren't any major pain points in this regard. The scriptable language will be able to provide all of this hot-reloading-anything-goes-yes-sir bullshit that we all know and love.
tl;dr: Use the right tool for the job. A language designed for safe systems programming can't do non-safe non-systems programming very well. Who knew!
Virtually all of the points outlined in the article stem from the above.
It's a weird concept to "care about programming". Same as "inadequate code". I find this statement really condescending and completely confirms some of the cliché quotes that the author write in this article
By "care about programming" I basically mean writing maintainable code.
By "inadequate code" I mean code that does what the author wants at this point in time, but is completely unmaintainable and just bad. Sloppy practices, etc
It's said that software is never finished, only abandoned, but games actually do get finished. And at that point any maintainability is absolutely irrelevant. It's just very different to web programming.
Some software (other than games) can actually be fully finished, provided that it's scope is narrow enough.
It's really a question of differentiating between "finished" and "abandoned". Finished usually means that no new features are added, the only changes are bugfixes or minor improvements. Abandoned means no changes at all.
> And at that point any maintainability is absolutely irrelevant
This goes in line with my point though. The fact that Rust encourages writing maintainable code makes it unsuitable for gamedev, where speed of development and flexibility (even where it's bad) trumps everything else. That's why you need to have a scriptable layer on top of the core engine anyway.
Rust... what is it good for?
"Systems programming" ...
Rust is not good for raw performance.
Neither for prototyping and iteration.
Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades.
Anyone really unhappy with Linux/BSD/Windows/macOS performance?
What systems are we talking about that benefits from Rust?
Advanced weapon systems that should absolutely not fail?
Controllers for air planes? Traffic controllers? Radar?
Power grid?
Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.
Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything. This is silly.
"Syzbot and the Tale of a Thousand Kernel Bugs" [1] is my favorite talk on this subject. The Linux kernel is adding security bugs faster than they can be fixed. This is an unsustainable situation--it is not "good enough"--and nobody really has any ideas to significantly improve things beyond adoption of memory safety.
> Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything.
No, not at all, that's not what I meant. I think it's forte for now is better security at the cost of some performance and productivity (iteration speed).
> Anyone really unhappy with Linux/BSD/Windows/macOS performance?
I wasn't unhappy with Windows' performance in the 90s until I saw BeOS. This is the kind of thing we're in the dark about what could be because the faster, rewritten fron scratch, free from API baggage systems are nowhere to be found.
Haven't used BeOS, but to clarify, I do have issues with Windows and performance, especially general input latency and responsiveness when compared to Linux, as I use both daily. But overall I think it's decent, and at the very least, not the fault of the language used, but more about legacy issues and technical debt. Anyone having worked with winapi and mfc knows the codebase is a mess.
Well, as far as I can tell, in the big language shootout (which is still the only decent language benchmark I know, but if you have others, I'd be happy to read them), in all the individual benchmarks I've looked at Rust is either first or within 3% performance of being first. So, this suggests that Rust is actually pretty good for raw performance.
In addition, I know that I'm way more productive for prototyping and iteration in Rust than in C, C++ (and I used to write C++ code professionally for a while), JavaScript, Go, Python (and I've been writing professionally in these three languages for a while now) etc. I _might_ be more productive in Java or OCaml. Yes, this is entirely anecdotal and it depends heavily on the kind of problems you're dealing with. I tend to focus on problems that have complicated invariants, and for which reproducing/pinpointing the issue in a debugger is a big annoyance.
> Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.
Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.
> Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.
I feel most large companies and some smaller ones are interested in trying out Rust, it's trendy. But time will show for which parts the switch was advantageous; and I'm very interested in the findings. The premise of the language is indeed convincing a lot of people. People do however, choose the wrong tool for the wrong job all the time, OP's article in point.
> Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades.
If that how you want your OS, that's fair enough. But I think a lot of people are happy to trade (to some degree, at least) performance for security, and would prefer that their OSs are as secure as possible first, and as performant as they can be second.
No, I'm not concerned with Linux/BSD/macOS performance, it's pretty good (I took Windows out because it does have performance issues [0]!). What I am concerned about is security bugs, memory errors, buffer overflows etc, all of the things Rust attempts to solve [1].
I think for weapons & flight control, ATC systems, we already have Ada that's designed for "can't fail systems".
I agree, operating systems should have less out-of-bounds memory issues. Is that Rust's place? Replacing the parts of OS code where it's OK to sacrifice some performance?
Ada has a foothold for sure, but there's a surprising amount of C++ in military planes and weapon systems.
I didn't read [0], but the parts of Windows that's poorly performing is not the fault of the language.
That's a good article. He's right about many things.
I've been writing a metaverse client in Rust for several years now. Works with Second Life and Open Simulator servers. Here's some video.[1] It's about 45,000 lines of safe Rust.
Notes:
* There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
* He's right about the pain of refactoring and the difficulties of interconnecting different parts of the program. It's quite common for some change to require extensive plumbing work. If the client that talks to the servers needs to talk to the 2D GUI, it has to queue an event.
* The rendering situation is almost adequate, but the stack isn't finished and reliable yet. The 2D GUI systems are weak and require too much code per dialog box.
* I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it.
* I have less trouble with compile times than he does, because the metaverse client has no built-in "gameplay". A metaverse client is more like a 3D web browser than a game. All the objects and their behaviors come from the server. I can edit my part of the world from inside the live world. If the color or behavior or model of something needs to be changed, that's not something that requires a client recompile.
The people using C# and Unity on the same problem are making much faster progress.
[1] https://video.hardlimit.com/w/7usCE3v2RrWK6nuoSr4NHJ
> I'd expected some AAA title to be written in Rust by now.
I'm disinclined to believe that any AAA game will be written in Rust (one is free to insert "because Rust's gamedev ecosystem is immature" or "because AAA game development is increasingly conservative and risk-averse" at their discretion), yet I'm curious what led you to believe this. C++ became available in 1985, and didn't become popular for gamedev until the turn of the millenium, in the wake of Quake 3 (buoyed by the new features of C++98).
Lamothe's Black Art book came out in '95. Abrash's black book came out in '97.
Borland C++ was pretty common and popular in 93 and we even had some not-so-great C++ compilers on Amiga in 92/93 that had some use in gamedev.
SimCity 2000 was written in C++, way back in '93 (although they started with Cfront)
An absolute fuckton of shareware games I was playing in the 90s were built with Turbo C++.
6 replies →
I really hope that C++ evolves with gamedev and they become more and more symbiotic.
Maybe adoption of rust by gamedev community isn't the best thing to wish to happen to language. Maybe it is better to let other crowd to steer evolution of rust, letting system programming and gamedev drift apart
17 replies →
I sometimes wonder if the problem with rust is that we have not yet had a major set of projects which drive solutions to common dev problems.
Go had google driving adoption, which in turn drove open source efforts. The language had to remain grounded to not interfere with the doing of building back-end services.
Rust had mozilla/servo which was ultimately unsuccessful. While there are more than a few companies uinf rust for small projects with tough performance guarantees - I haven't seen the “we manage 1-10 MM sloc of complex code using rust” type projects.
28 replies →
Exactly, it's all about the ecosystem and very little about the language features
68 replies →
> and didn't become popular for gamedev until the turn of the millenium
Wasn't this also because Microsoft had terrible support for C?
Since the mid-90's, a number of gamedevs moved to C++ but were unhappy with the results.. how OOP works, exception handling, the STL, etc.
My understanding is.. by late 90's.. many game developers, despite using C++, we still coding more inline with C programming than (proper) C++.
Mostly C code but using some features of C++ like, functions inside a struct, or using namespaces, that did not sacrifice compilation and runtime speed.
We wrote this in C++ (and assembler), but used only the most obvious language features. We laid down the first code in '95 or '96:
https://www.youtube.com/watch?v=9UOYps_3eM0
Yeah, gaming industry has become mature enough to build up its own inertia so it will take some time for new technologies to take off. C# has become a mainstream gamedev language thanks to Unity, but this also took more than a decade.
Comparing the time it takes for a prog language to spread from the 80s to today is a bad vantage point. Stuff took much longer to bake back then -- but even so the point is moot, as other commentors pointed out, it took off roughly the same amount of time between 2015 and today.
1 reply →
The concept of AAA games didn't even exist back in 1985, very few people were developing games at that era, and even fewer were writing "complex" games that would need C++.
The SNES came on 1990 and even then it had it's own architecture and most games were written in pure assembly. The PlayStation had a MIPS CPU and was one of the first to popularize 3D graphics, the biggest complexity leap.
I believe your are seeing causation were only correlation should be given. C++ and more complex OOP languages just joined the scene when the games themselves became complex, because of hardware and market natural evolution
Many tried c++ in early 90s, but wasnt it too slow/memory intensive? You had to implement lots of inline c/assembly to have a bit of performance. Nowadays everything is heavily optimized, but back then not.
2 replies →
Seems like a few contradictory ideas here. Rust is supposed to be a better safer C/C++.
Then lot of comments here that games are best done in C++.
So why can't Rust be used for games?
What is really missing beyond an improved ecosystem of tools. All also built on Rust.
> I'd expected some AAA title to be written in Rust by now.
Why? Those kinds of game engines are enormous amounts of code, and there's little incentive to rewrite.
I do strongly disagree that we aren't ever going to see large-scale game development in Rust; it just takes time. Whether games adopt an engine is largely about that engine's maturity rather than anything about the language. Bevy is quite young; 0.13 doesn't even have support for animation blending yet (I landed that for 0.14).
It was a few years back that the question came up to the developers of a Call of Duty title. "Is there still code from Quake 3 in COD?". They dodge around it by saying something like "we cannot deny this but e use the most appropriate tech where needed".
While not confirmation, I wouldn't be surprised if there is a few nuggets of Q3 in that code base still doing some of the basics. That would be really cool if it is true.
It seems like unless you are someone like John Carmack or most of Nintendo, game dev tools are about what can get the best results quickest rather than any sort of technical specifics. It is a business after all.
10 replies →
"I tend to agree about the "async contamination" problem. The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests. I've been pushing back against it creeping into areas that don't really need it."
100% this. As I say elsewhere in these threads: Rust is the language that Tokio ate. It isn't even just async viral-chain-effect, it's that on the whole crates for one async runtime are not even compatible with those of another, and so it's all really just about tokio.
Which sucks, if you're doing, y'know, systems programming or embedded (or games). Because tokio has no business in those domains.
It does in my domain of systems programming with async data handling. Tokio works like a dream - slipping into the background and just working so I can concentrate on the business logic.
3 replies →
Disappointing to hear this after battling the same nonsense in JS for years.
3 replies →
> The "async" system is optimized for someone who needs to run a very large web server,
Even there it's very problematic at scale unless you know what you're doing. async/await isn't zero cost, regardless of what people will tell you.
Absolutely. Async/await typically improves headroom (scalability) at the cost of latency and throughput. It may also make code easier to reason about.
26 replies →
> I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
The main reason is that you can't ship that Rust code on PS5 in a sensible manner. People have tried, got useless toys to compile, but in the end even Embark gave up. I remember seeing something from them that they had moved Rust to server-only.
> The main reason is that you can't ship that Rust code on PS5 in a sensible manner.
Really - why’s that?
5 replies →
> I tend to agree about the "async contamination" problem.
Argh I have the same issue. Sure if you write JS or Python you probably need async. My current Java back end that has like 5 concurrent users does not need async everything making 10x the complexity.
> I'd expected some AAA titles to be written in Rust by now.
"AAA" titles are huge and/or high dev budgets. Even if a game is "starting from scratch" the engine development team are still likely taking code from previous projects to get started. Of course there are other factors. It could be a BIG RISK to move to another programming language when the team, despite frustrations, are already familiar with something else... like the perks C++ brings (you learn from trial-and-error)
Could you imagine learning Rust as-you-go... building a AAA title... and fighting the compiler? To me it is a huge risk!
That is my opinion.. but I am sure others will disagree. If there is anyone on (or did) a AAA title with Rust... I would be happy to hear more about it.
I am not saying it will never happen. Maybe a AAA title is currently in development in Rust. I honestly dont know. However, game developers... if they are looking into Rust... are also looking at Odin, Jai, or Zig. For gaming, I think they are better alternatives than Rust but (again) that is my opinion.
Now for smaller, indie games - the possibility of moving to Rust (or another language) is more likely. Likely a fair percentage have moved away from C++ now.
> * There are very few people doing serious 3D game work in Rust. There's Veloren, and my stuff, and maybe a few others. No big, popular titles. I'd expected some AAA title to be written in Rust by now. That hasn't happened, and it's probably not going to happen, for the reasons the author gives.
At one point the studio behind the Finals was writing game server code in Rust with an Unreal engine client. Not sure if that's true still
The studio you're talking about is Embark studios, and is openly pretty big on Rust [1] I think it was rumored that their next project will use a Rust game engine, but I am not sure how it's going now.
[1] https://github.com/EmbarkStudios/rust-ecosystem
1 reply →
Backend 3d code?
8 replies →
> The "async" system is optimized for someone who needs to run a very large web server, with a huge number of clients sending in requests.
Can you please elaborate on this? I see a lot of similar concerns in other contexts too. Linux kernel's scheduler for example. Is it a throughput/latency tradeoff?
The current popularity of the async stuff has its roots in the classic "c10k" problem. (https://en.wikipedia.org/wiki/C10k_problem)
A perception among some that threads are expensive, especially when "wasted" on blocking I/O. And that using them in that domain "won't scale."
Putting aside that not all of use are building web applications (heterodox here in HN, I know)...
Most people in the real world with real applications will not hit the limits of what is possible and efficient and totally fine with thread-based architectures.
Plus the kernel has gotten more efficient with threads over the years.
Plus hardware has gotten way better, and better at handling concurrent access.
Plus async involves other trade-offs -- running a state machine behind the scenes that's doing the kinds of context switching the kernel & hardware already potentially does for threads, but in user space. If you ever pull up a debugger and step through an async Rust/tokio codebase, you'll get a good sense for what the overhead here we're talking about is.
That overhead is fine if you're sitting there blocking on your database server, or some HTTP socket, or some filesystem.
It's ... probably... not what you want if you're building a game or an operating system or an embedded device of some kind.
An additional problem with async in Rust right now is that it involves bringing in an async runtime, and giving it control over execution of async functions... but various things like thread spawning, channels, async locks, etc. are not standardized, and are specific per runtime. Which in the real world is always tokio.
So some piece of code you bring in in a crate, uses async, now you're having to fire up a tokio runtime. Even though you were potentially not building something that has anything to do with the kinds of things that tokio is targeted for ("scalable" network services.)
So even if you find an async runtime that's optimized in some other domain, etc (like glommio or smol or whatever) -- you're unlikely to even be able to use it with whatever famous upstream crate you want, which will have explicit dependencies into tokio.
13 replies →
I'm happy to see someone still doing some work in second life.
There's a lot going on. Someone is doing a new third party viewer, Crystal Frost, in Unity. Linden Lab has a mobile viewer in alpha test. Rendering is PBR now for new objects. There are mirrors! Content upload is moving to glTF, to be compatible with everybody else. Voice is switching from Vivox to WebRTC. Game controller support is in test. New users get better avatars. The dev staff is larger.
None of this is yet increasing Second Life usership much, but it remains the best metaverse around.
I thought the metaverse thing was going to be bigger. Meta spent so much money to produce so little.
2 replies →
As a game developer for about two decades, I've never considered Rust to be a good programming language choice.
My priorities are reasonable performances and the fastest iteration time possible.
Gameplay code should be flexible, we have tons and tons of edge cases _by design_ because this is the best way to create interesting games.
Compilation time is very important, but also a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.
We almost never have specifications, almost nothing is set until the game is done.
It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.
Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.
> It is a different story for game engines, renderers, physics, audio, asset loaders etc. those are much closer to system programming but this is also not where we usually spend the most time, as a professional you're supposed to either use off-the-shelf engines or already made frameworks and libraries.
But this is where industry interest (the little there is) lies for Rust, is it not? This is what the AAA studios that are researching and prototyping are working on.
C++ is not a popular language to implement the actual game in for all the reasons you list. It is too slow to compile and too rigid. The people who actually build the games, make them tick, are all working in visual scripting languages.
Visual scripting languages are easy to use and practical for low-complexity code, but they scale very poorly once the complexity increases.
Gameplay code is still better written with code, C# or C++ or sometimes Lua.
> visual scripting languages
I'm surprised no one has made such a language that is designed from the ground up to be used as such for rust. Nim/coffeescript come to mind, but they target non-rust languages. Lua would be close enough if it weren't so alien to everything people like about rust.
1 reply →
As a non-game dev who uses Rust and Elixir, Rust wouldn't be my first pick for a large gamedev studio for multiple reasons. As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#. Maybe even Go because the iteration and compile times are very fast, and the learning curve is very low.
Often in the past Lua has been used and in my experience it's been quite nice. It's very easy to bind, there's some nice editors out there and the performance is decent.
There's some other game-specific scripting languages that have popped up (angelscript and wren come to mind but there's more). I've not used them in full production products though. Mostly just kicked the tires.
Now that I think about it though, it's been almost 6 years since I've worked on an engine with lua support. Mainly because in the last few years I've been working with unity or unreal.
| Go because the iteration and compile times are very fast
Safety is important and for certain applications, Rust is unrivaled.
But for games, like web apps, where time to market and innovation can be just as if not more important than being free of runtime errors, Go is more suited to rapid development than Rust on compile times alone.
Of course, the libraries and support for both aren't quite there yet, so at this point neither is well suited to game dev.
1 reply →
> Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#
If you're starting from scratch, then maybe. Having had to crash learn games dev (ex VFX systems person) Unity + c# is just so nice to use. most of the easiness of python, but with proper strict typing. (which you can turn off, if you want)
plus the wealth of documentation, its great. I imagine unreal is quite good in that regard too.
>As for alternatives worth evaluating: Crystal, Cython (compiled Python), or Nim could result in increased gamedev productivity over C++ or C#.
I read on a recent HN thread that Crystal compilation is slow due to its type inference, IIRC.
Does Crystal support Hot Reloading? The slow compilation speed is a non-starter for me.
8 replies →
Go is infamous for its gc latency spikes, which is the thing that games cannot tolerate.
Though 1.18 helped a lot, you'd have to do some major persuasion to game devs that Go's gc is the kind of thing they'd want in their game.
---
EDIT: Not sure the downvote, Go is know for its (historically at least) unsuitability for RTC or game dev.
7 replies →
I had similar thoughts, about Rust being a good match for game engines but not games. Maybe it suggests Rust game engines might want to include an interpreter for some higher level language to actually do the gamedev in.
Rust is pretty good for writing PL interpreters (and similar tooling) too, actually.
I know you're not asking for recommendations, but Lisp, particularly SBCL, really seems to check all your boxes. I say this as someone who generally reaches for Scheme when it comes to Lisps too.
There are a few game engines[0] for CL, but most of them seem to be catered specifically to 2D games.
[0] https://github.com/CodyReichert/awesome-cl?tab=readme-ov-fil...
> a flexible enough programming structure, moving things around and changing your mind about the most desirable approach several times a day is common during heavy development phases.
That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
(Whether Rust tooling is actually at a level to take advantage of that is another question)
> That's the kind of code for which Rust-like languages shine. Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
I don't think this is true. Rust makes it easy to get the refactor right (generally speaking 100% right). But that's not what they're describing. They're describing where the ability to make the refactor fast, even if it doesn't work correctly (in the formal sense of correctly). That is to say, memory leaks and race conditions and all sorts of horrible nastiness may be tolerable during the dev process in exchange for trying out an idea more quickly.
This is, of course, significantly more work at the end to patch up all of the things you did, but if you don't have to do the full work on 99/100 iterations, or got to try out more iterations because of the quick turnaround time, that would be considered a win here.
Pretty much every compiled language with a static typesystem has that "large-scale refactoring support" though. That's not Rust's USP, on the contrary: a too strongly typed language can make refactoring actually harder than it needs be. The sweet spot is somewhere in the middle (where exactly is up for discussion of course).
>Rich type systems make it easy to change your mind about things and make large changes to your code with confidence.
To be fair, they need to be able to make large changes with confidence because what would be small changes in other languages tend to end up being very large changes in rust like languages.
> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.
Not a game developer, but each time I tried to make one not using ECS(or something at least similar in spirit) I quickly found myself not being able to proceed due to the sheer mess in the codebase.
How does one normally avoid that?
> Also, ECS is, IMHO, a useful pattern for some systems, but it is a pain in the butt to use with gameplay or UI code.
I'd love to see a language built around ECS. I wonder how nice it can be in a language syntax where ECS is the easiest thing you can do.
> My priorities are reasonable performances and the fastest iteration time possible.
I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on...
Maybe feeling like you're iterating fast isn't the same as getting to the destination faster.
Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs:
Does your C++ not crash, just theirs?
That game (currently) has 88% positive reviews on steam and a 77 metacritic score with over 15.5k people playing the game right now (according to steamcharts.com)
Thats a lot of happy customers.
I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was experienced by even 1% of the users.
The criteria by which something is decided to mention in the patch notes is not always purely because the users care. Sometimes it's because the developers want to signal effort to user and/or upper management.
Maybe Mount and Blade was super boggy in the past and is still super buggy now so all the crashes fixed are just an indicator of how large the problem is for them and how bad the code still is. I dunno, you didn't really give any information to help on that front.
3 replies →
With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.
2 replies →
I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.
25 replies →
Photoshop does crash. Trust me if you do enough image editing you'll know it's not even a super rare event. They're generally doing a poor job handling the situations where you have no enough storage or RAM.
It didn't stop Adobe from being worth 200B.
Hard to know what TaleWorlds are actually optimising for because half the features of Bannerlord feel like they’ve never been played by a dev let alone iterated on.
How many of those crashes were caused by memory safety issues though?
A lot of those crashes might simply be called a "panic" in Rust.
And yet the fact that Bannerlord game logic is entirely in C# makes this possible:
https://github.com/int19h/Bannerlord.CSharp.Scripting
which in turn makes it a lot easier and more convenient to mod. Try that with Rust...
Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.
9 replies →
This comment is nonsense
My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
10 replies →
> Rust gamedev ecosystem lives on hype
I've been saying this for years. I've tried to get into Rust multiple times the past few years and one of the things I've tried was gamedev with Rust (specifically the library ggez when it was still being worked on, and a little bit of Bevy). I admittedly never got far, but I gave it a solid shot.
My experience was instantly terrible. Slow compile times and iterations, huge package downloads (my project folder was roughly 1gb for a simple 2D project), and of course Rust itself was difficult to get into with lifetimes and having to wrap and unwrap my variables constantly and getting into wrestling matches with the borrow checker.
I kept telling myself that everyone loves Rust and the community loves to rave about anything Rust-related and maybe I just don't get it, but it took some time to realize that no... It's just a terrible choice for it. I even tried to make UI with eGUI and was still miserable. Rust is a systems programming language but the community is trying to convince everyone should be used for general purpose stuff.
And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.
I am curious about Bevy when it becomes mature and has its own editor, but for now I'm just not convinced gamedev with Rust will ever take off.
> And my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust. "It's not memory safe" is the biggest one thrown around, but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial. Rust game development feels like a solution looking for a problem to fix.
Memory safety may or may not be important in games, but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal. Job queuing systems have been popular in gamedev for a very long time, and Rust's insistence on explicit declaration of mutability is a big part of the reason that "just works" in Bevy.
> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal
Is it? The article addresses that, and basically calls it a pointless feature that is almost never used and when it is the benefits are mostly lost because of real world needs and constraints, and that the problems it solves are easier solved through other solutions and add-on systems that are well understood.
I think this might be a case where explaining the real-world benefit instead of the theoretical benefit is needed, if only to counter what are very pointed criticisms that are definitely deeper than at the theoretical level.
16 replies →
It's a good feature, but still a niche one. It's a bit like choosing Unity only because of DOTS. For a few projects perhaps it make sense. But just a few ones.
2 replies →
> automatically scale to multiple CPUs
We've been promised automatic CPU scaling in programming languages since at least 2001, and I've yet to see any practical version of it.
I'm a Rust fan (mostly for embedded firmware with minimal deps), but even after 10 years of playing with the language it's not clear to me that advanced GUI or gamedev fits well with the borrow checker. It requires a significant paradigm shift in architecture, and I'm not convinced it's worth making that shift, especially if your application can tolerate a garbage collector (which many games and most UI apps can).
https://dioxuslabs.com/blog/release-050
Seems promising, very React-esque with little boilerplate
5 replies →
Agreed. Multiple languages exist. They can be part of {your, your team's} toolbox for different specific purposes. Some languages are set by other tools or by team members' backgrounds. Popularity also lends itself to greater availability of tools and Q&A forums. In the end, it's a better decision-making process to select what is most likely to be long-term productive for a specific project and team.
This might be controversial, but "Safety" and "Speed", in the same ecosystem, are not free. The cost is heavy syntax and heavy cognitive climbs. Why Rust was ever sold as a language for the masses is beyond me. A safe, fast, hard language is something you use for operating systems, aircraft, etc.
I adore Rust because it does all the things I remember being told to do in C, but without me remembering to do them: Error codes from all functions, Ownership models, etc. But those are not good reasons for me to use it for anything I wouldn't use C for.
It's possible to write unsafe and slow code in Rust.
> Rust game development feels like a solution looking for a problem to fix.
The same can be said for ordinary CRUD backends. Java, C#, Go and Typescript (Node, Deno or Bun) are all memory safe with good type systems and more than good enough performance. Evangelism around Rust is unfortunately still a thing. A good example is the latest hype in the community because some Google Manager said at a Rust conference that writing Rust is as fast as writing Go. Anyone having done more than a toy program in Rust and Go knows how wrong this statement is. The reasons are given in the article.
When single bug may cost millions of dollars, then Rust is cheaper and faster than Go. Google manager is not a liar.
This is not necessarily a bad thing. Especially given that Rust is an immediate upgrade with no downsides when moving away from C or C++. It is easy to see with people never wanting to go back, which also involves getting companies and products to adopt it as you would otherwise be forced by the market to work with inferior tools.
As a counterexample, .NET suffers a lot from the lack of evangelism - big chunk of community that started out back in .net framework days still thinks of it as poorly as people outside the ecosystem because they never bothered to drop old and obsolete tools and targets and give new versions a proper try (as the code is often vastly simplified and performance is vastly better).
Other programming languages, not only Rust, also do better at self promotion - take for example Go that managed to convince everyone to put it in the same bucket as Rust (which, personally, I find absolutely insulting as C# is a much closer alternative to Rust both in performance, features and access to low-level bits).
4 replies →
Just a small addition: Godot also has great C# support. It is a real charm to work with.
The godot-rust project crates take a minor amount of adaptation to understand how it exposes the Godot object system in Rust but it's also pretty well developed.
1 reply →
Last time I tried Godot with C# in Visual studio, when I debugged I could not see the console output, and when I ran with the console output I could not debug (the breakpoints weren't hit). A Google search later and turns out it wasn't just me.
2 replies →
We're doing more and more of our back-end work with Rust. The main reason is the performance it provides. It's not just great for our end-users it's also so much cheaper in the modern world where we pay per mileage in the cloud. Part of what we really like about Rust, however, is actually exactly the variable ownership because it makes it very straight forward to enforce and control data-integrity and avoid race conditions. Even for programmers who would struggle to do so in C or C++.
I'm not sure whether or not that's even useful in game development. I've never done any form of game development beyond some Chess game I programmed in my first year of CS 30 years ago. But I'm actually really curious as to why you've struggled with variable ownership, because I'd frankly like to improve our on-boarding processes even more for new hires.
> my other biggest problem is that they keep painting other non-Rust things as being fundamentally flawed for not being Rust
Rust has a cult and it's best not to pay too much attention to it. Don't get me wrong, we're seeing great benefit in not just using Rust over C/C++ but also replacing more and more of our C# and Python services with it, but it's a very immature language and like any other programming language it's still just a tool. If it works for you, use it, if not... Well, use something that does.
> C/C++
is not something that exists in the real world.
Now I'm wondering how far people could go a hypothetical Rustscript* that transpiles to Rust (or hooks into rustc?), introduces extra features such as reflection, removes lifetimes, and changes the defaults around things like monomorphization.
* name intentionally made to make people angry
If you're removing lifetimes from the script, I'm not sure how you're then transpiling to Rust, unless you wrap everything with reference counting, at which point you're better off using a language with GC.
2 replies →
There’s [Rune](https://github.com/rune-rs/rune/).
Rust ain't Go but anything Go has can be used as an argument that Rust should try to do better in certain areas. ;)
Perhaps learn another language like Haskell, Swift, or Kotlin before Rust.
Get cargo-bloat, cargo-cache, and cargo-outdated.
Setup a memcache server and use sccache to accelerate Rust, C, and C++ compilations. It's not 100% but it's pretty awesome for things compiled at a stable build location.
Just like any platform, avoid dependencies wherever possible and use minimal crate features. Some Rust crates have an npm-like problem of dragging in zillions of dependencies.
> but when was the last time memory safety was actually a big problem in games? Unity uses C# which is garbage collected, Godot uses its own scripting language which makes it nigh impossible to leak memory, Unreal AFAIK has its own tools that makes memory management trivial.
So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?
Yeah, Rust definitely is not the only solution, or perhaps not even a good solution to this problem in the context of game development. But let's not pretend the problem itself doesn't exist?
> So.... Sounds like memory safety is indeed a problem? Otherwise why do so many solutions exist for it?
Memory safety and memory management are different things. Scripting languages remove the burden of manual memory management; as a side effect, they also tend to be memory safe, but that hasn't been the main motivation.
As I said in my own comment down thread, despite being a huge rust advocate, I sincerely agree with you here.
Rust is not a good language for actually writing games, and the fact that it is being sold as such is really detrimental to it in my opinion, because it is holding the ecosystem back. Rust is being pushed as a language for game logic, so people try out and realize it isn't very good at that, and so they just give up on Rust in the game development industry at all and leave, understandably! If Rust were more strategically positioned, it could get a lot farther. Where it should be focusing in the games industry is on game engines, where flexibility and quick iteration and easy prototyping and being able to just reach out and directly touch and control things isn't as important, but where concerns like the clarity and maintainability of the code base, stability of the software, resource ownership and management, and eeking out every ounce of performance all become important, and so the type system and static analysis guarantees of Rust are actually useful.
This is where, I'm disappointed to say, I think things like Bevy and Amethyst have severely hurt the Rust game development ecosystem. They aren't really game engines in the traditional sense, they are more like game frameworks like Love2D except written in Rust: they force you to statically link your game code to the engine code, and write your game logic in the same language your engine is written in. This means that game developers who just want to quickly prototype game mechanics and want to be able to iterate on them in order to refine them are forced to use a language that is far too focused on correctness, safety, static verifiability, and concerns like that to actually be usable as a programming language, and worse, it forces them to compile their game logic and the entire engine together and link them together in order to build their actual game and test it, massively increasing the weight of the process and basically ruling out hot reloading or making your game independent of any specific version of the engine, or its license. It puts them between a rock and a hard place, between using some other ecosystem, or using a language that simply unsuitable for a game development.
I think the far better solution (one which I plan to very slowly feel out with my embryo engine project, which is born out of my frustration of looking at the existing rust game engines and feeling like they are all kind of lying about what they are) would be to stop with the vaporware and the hype with Bevy and Amethyst and such, and actually build a proper game engine, like they are promising to be but are not, that is its own separate pre-compiled executable that game developers don't even need to mess with at all, that picks up game assets and game code written in a more flexible, dynamic, language that's better for prototyping, and runs them, something like what Unity or Godot or even Gamebryo do. Only then will the rust game development ecosystem take off, because it will no longer be forcing a language that just isn't good for that on to people.
But people want to write Rust and a game seems like a fun way to do it. They can already use Godot or Unity with this approach.
Garbage collection causes performance issues.
I've done hobby gamedev in Bevy/Rust, Godot/C#, and Unity C#.
It's honestly somewhat baffling to me that folks will choose Rust for gamedev right now. The state of the open sourced tools are just not there yet, especially when compared to Godot, and at the same time these games are running on PC hardware which tends to get faster every year.
Also for ECS... one thing I tended to realize is that when developing a game, pigeonholing everything into an ECS can seriously tend to get in the way. A lot of (efficiently written) game code is best handled in an infrequent event-driven way.
An ECS backed game engine like Bevy can make big mobs more efficient, but few games will actually leverage this effectively for fun gameplay and at the same time modern PCs are fast as hell.
I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun. Now should a gamedev today, 26 years later, making a 2d isometric game for the PC be worried about performant multithreading????
> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.
Ah... Starcraft. It's 200 supply per player (hero units take 0 supply, zerglings are 0.5, and the supply cost goes up to 8 for battlecruisers for example). The limit is enforced when building a unit from a building. Map triggers can grant units and you can exceed the 200 supply limit.
The technical unit limit for the map was 1700, and was later in fact extended to 3400 by Blizzard. The EUD emulator (part of the official SC Remastered) allows for online custom games to be played without any third party tools on the player's part. Certain limits like sprites can be bypassed with this tool (for map makers) https://github.com/phu54321/euddraft/blob/master/plugins/unl...
EUD started out as a buffer overflow exploit which allowed custom maps to patch the game client's code. It was later fixed by blizzard but re-implemented as an emulator (with some restrictions).
These are definitely things that enhance gameplay for custom scenarios. https://youtu.be/HEv_U9WV4PA?t=1541 (yes, that is a battlecruiser shooting nukes)
Complete distraction of a question -- for that video clip, what is the song playing at the time stamp you selected? Is that in-game music? I figure not.
2 replies →
Likewise - I've been learning Rust for four years now (significant C/C++/Python/Lua experience), and have written some reasonably complex apps in it, but I really just didn't get the Bevy / ECS "hype"...
I've tried to write several different types of games using it (with Bevy) in the past three years, and it just feels like shoe-horning something in.
But the biggest complaint I have with Bevy is that with all the refactoring that's been needed with the Bevy version upgrades: getting the code to compile again after the version upgrades has normally been fairly easy - but it then often didn't work correctly, and I'd have to spend time debugging the ECS system to work out what was wrong.
i.e. the "if it compiles, it'll almost certainly work" bonus of generic Rust code totally seems to fall down within Bevy.
I obviously understand that it's an in-development framework, in its early days, so some of that's on me for choosing it, but still, it's been a very painful experience, and I feel I've wasted a fairly significant amount of time over the past few years attempting it.
CPUs are way way faster, but RAM latency has barely improved in the past couple decades. That's why cache-optimized systems like ECS can still be a dramatic improvement when you're simulating a lot of stuff. Like, thousands of active objects.
They can be improvements, but you can do Data-Oriented Programming without ECS systems, i.e. Structure Of Arrays, which is what we often using in Rendering/Simulation for VFX for SIMD/GPU compute...
But similarly, ECSs can be slower, if they don't have some optimisations, i.e. spatial data structure lookups: just using a generic ECS "database" system without any first-class spatial knowledge / acceleration structure lookup ability, is likely going to be slower.
> I think about Starcraft from 1998, created when virtually all PCs only had one core, and its 200 unit per faction cap. Blizzard hasn't increased this cap because it doesn't necessarily make the game more fun.
That small scale was exactly why the game ends up being so much about micro, and while that may make it more competitive or interesting for spectators it makes it a lot less fun to play IMO. Total Annihilation and successors were a lot more fun, and a big part of that was not having arbitrary unit caps in a way that affected gameplay; expanding the limit from 500 to 1500 did genuinely make the game more fun.
Agreed. Truly exponential economy makes late-game Total Annihilation/Supreme Commander/Beyond All Reason far more fun than Starcraft.
Starcraft late-game is hoarding resources and running out your opponent's patience while looking for a slip up.
supreme commanders very high unit cap leads to crazy end games. it allows your economy to grow exponentially for the entire game. which has a big impact on late game strategy
Many people are choosing Rust because they want to use Rust. Rust has the reputation being "the best" programming language: Fast, safe, reliable, modern. I can rely on that very much. Who wouldn't like the feeling of using the best tech for their project.
What many overlook is that using Rust has very high costs, but the edge over alternative languages is often only marginally - depending on the use case of course.
Those costs of Rust get in the way of developing the actual product. You loose speed, efficiency, but potentially gain no benefit to the users of your product.
>but few games will actually leverage this effectively for fun gameplay
In my opinion this is a result of big mobs having poor performance. When players get to choose they seem to like having more mobs thrown at them.
This can also be limiting for interactable objects.
Allan Blomquist's tooling demo they mention is incredible, go watch it:
https://www.youtube.com/watch?v=72y2EC5fkcE
Really sells the value of having a tight developer feedback loop: it shows hot reloading for code and graphics, a reversible debugger, live profiling with flame graphs, a data inspector with data breakpoints, time travel inspection with a scrub bar, session sharing and replay with the same scrub bar and direct links from the call stack to a breakpoint, and more.
Above the many niggles they had with Rust itself, this greatly helps me understand why Rust left them wanting more from their working environment. They say they've switched back to Unity with https://hotreload.net/ to try to capture some of that, and now I see why. (It's a shame that hot reloading tooling in Rust wasn't ready for them yet, but I see why they've moved on instead of waiting/contributing.)
Yeah, this is the bit that stood out for me, too.
Does anyone knowledgeable here have a sense for whether there are any insurmountable roadblocks to bringing hot reload to Godot?
Godot 4 already has hot reloading.
3 replies →
My impression of Rust is that it's a very opinionated language that wants everybody to program in a specific way that emphasizes memory safety above everything. That's a good idea, I think, for the systems programming use cases that it was intended for. I don't see that as a particularly useful thing to value for game development. The part in the article about the Rust borrow checker constantly forcing refactors sounds extremely obnoxious to deal with.
I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns. Basically a better version of C such as a selective subset of C++ or a Golang without garbage collection. I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.
> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games but they would be for a web site or an enterprise database.
Even for database engines specifically, modern C++ is essentially as safe as Rust and significantly more ergonomic. Rust's safety features can't reason about the case when all of your runtime objects live in explicitly paged memory with indefinite lifetimes and no fixed memory address, which is the norm in database kernels. You have to write the same code to make handling these objects safe and correct in Rust that you have to write in C++. You can't use normal pointers and allocators for this even if you wanted to.
Rust's safety is designed more for normal dynamic memory applications.
> modern C++ is essentially as safe as Rust
This isn't even close to being true. I think memory safety isn't as important for games as it is for most software (though it is still quite important for multiplayer games!). But even if you write the most modern C++ possible I guarantee you are going to spend some of your time debugging segfaults, memory corruption and heisenbugs. Don't try and claim "I don't write bugs". Everyone does.
7 replies →
This kind of extends to embedded/low level systems programming as well - the assumption that memory can only change as an effect of program execution just does not hold true there. What's the value of tracking mutability and data ownership when a DMA engine can just decide to overwrite the memory you supposedly have exclusive access to?
I agree so much that I've been working on this for a whole year.
There is a sweet spot : non-GC, with pointers (but bounded), inference, basic OOP + tacking, and all the comforts of scripts. All in a good looking syntax without semi-colons.
So you can program fast and get a fast program.
For me, this is Odin-Lang, it doesn't meet all the requirements you have listed, but it's ergonomic, fast, and comes with extensive core and vendor libraries. It's all just fun and reasonable.
https://odin-lang.org/
1 reply →
Seeing presence/absence of semicolons in the list of primary features makes me wary.
And it takes a lot of people to make good tooling.
1 reply →
IMO it’s not opinionated enough. Golang for example doesn’t let you customize go fmt, while Rust does. Rust also has many ways to do things in general (mod.rs vs name_of_folder.rs for example) and seems to not want to provide a useful baseline for most projects via its standard library (unlike Golang).
But to go back to our subject: Rust is a great language and that’s all you need. I wish I could use it with unity.
The mod vs folder rs stuff is just embarrassing for Rust. I have no idea why they support more then 1 method.
10 replies →
Golang is indeed much more opinionated. To quote @bcantril, "Go is like steampunk for programming."
Most modern languages are memory safe and they don't get called out for emphasizing that or being opinionated. I think with Rust that attention results from its choice of memory management model which gets in the way a lot in ways described in the article.
> My impression of Rust is that it's a very opinionated language
It's not though. There's only one thing Rust is opinionated about.
> that wants everybody to program in a specific way that emphasizes memory safety above everything.
Well yes, that is literally the core proposition and purpose of the language. That's like saying java is opinionated because it wants to manage the memory.
> I just don't think the kinds of security bugs you get from C/C++ "unsafe" code are that big of a deal for games
As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.
Rust also is opinionated that you don't want to write shared libraries or plugins. You can do both, but only if you drop down to memory unsafe C interfaces. The default is statically compile all applications into one program. Rust also really wants you do to use their build system and package manager, you can avoid both but everything will fight you.
2 replies →
> As soon as games are networked it starts being a problem, and these days non-networked games are pretty rare.
So have your network protocol parser in Rust and the entire rest of your game in whatever the hell you want.
All the practical safety you could desire without any language constraints for the other 99% of the code
You more or less described Zig
Sort of, although Zig certainly pushes itself towards the embedded world. I have tried Zig a bit and like it a lot, and I am sure it would be better for game dev than Rust, but I don't want to pass allocators around all day to all the objects in my game.
Go without GC is more like a Go and Zig baby.
4 replies →
> I'd think that an ideal game dev language would be programmer time efficient, reasonably performant and designed for skilled programmers who can handle a language filled with footguns
Sounds like Common Lisp or OCaml would work well. With Ocaml I find myself being able to iterate extremely quickly because of the inferred types and extremely fast compilation times. You also have the ability to tweak the GC to your needs and the assembly is easy to read.
Lisp is well… built for interactive development
This is a sobering read. Thank you for sharing.
This sums it up for me:
> Rust as both language and community is so preoccupied with avoiding problems at all cost that it completely loses sight of what matters, delivering an experience that is so good that whatever problems are there aren't really important. This doesn't mean "ship crap games", it means focusing on the game being a good game, not on the code being good code.
I think this can be easily extrapolated to projects outside of game development as well.
User experience is ultimately all that matters. If you're in prototyping stages of whatever it is you're building, and games spend a lot of time in this phase, then your focus should always be on testing what the user experience will be like, rather than absolute code correctness, maintainability, and everything else that makes a long-term project successful.
The fact Rust seemingly can't deliver this rapid prototyping workflow should be a large factor when deciding which language to use.
I've been using Go as my main language for the better part of a decade now, and I think it strikes the perfect balance of code quality and rapid prototyping. It's far from the side of absolute freedom of a language like Python, which becomes a nightmare to work with after the prototyping phase is over (though this might have improved in the past few years), but it's also far from languages like Rust, and allows me to be very productive, very quickly, while also being easy to pick up for newcomers. I probably wouldn't pick it for GUI or game development either, though, but for things like CLI, network and web tooling, it's perfect.
To be fair, many (non-game dev) Rust projects I have seen/used do provide great user experience precisely because they are laser-focused on performance and have blown existing alternatives out of the water. (Think ripgrep, fzf, etc.)
Prototyping is certainly necessary but it shouldn't be at the cost of runtime performance – at least not too much –, because it will typically be very difficult to improve performance after the fact, which web development frameworks, and in particular shitty "web" applications like MS Teams are a testament to.
As always, it's about balance.
> ripgrep, fzf
I think these are great examples of where prototyping and rapid iteration are really not needed at all, and hence Rust shines here.
Writing a game is completely different.
4 replies →
Fzf is written in go fwiw
2 replies →
> User experience is ultimately all that matters.
It should be but current state of web will show you that it is often not.
Really? Why web?
1 reply →
Starting by saying I fundamentally agree wrt iteration speed. This is ultimately why [C/C++]/Lua was such a thing for a while, and it seems quite plausible that you could benefit from a core engine in rust bound to a scripting language.
But ultimately I sense the subtext here is much the same as with other Rust problems: the object oriented baby has been thrown out with the bathwater, often in the name of premature optimisation, but also with a sense of misplaced religious purity regarding the evils of state and the merits of functional programming. There never was any OOP law that your inheritance hierarchy had to be insane, or that you had to create classes for absolutely every last thing. Now we have people hitting the opposite extreme where everything has to go through the same function switched on a pattern matched enum. One of the core problems with Rust is it lacks the mechanisms to allow moving adequately out of this tarpit.
I still think Rust might have a place at the lowest level core where it is all about shuffling arrays of things through compute units, but for the higher level pieces it is clearly the wrong thing to be using.
> but also with a sense of misplaced religious purity regarding the evils of state
To clarify, Rust isn't against state at all. Rust bends over backwards to make mutation possible, when it would have been far easier (and slower, and less usable) to have a fully-immutable language. What Rust is against is global mutable state, and an aversion to global mutable state isn't a religious position, it's a pragmatic position, because global mutable state makes concurrency (and reasoning about your code in general) completely intractable.
1000%, and this is something gamedevs (and, for quite some time, webdevs) are guilty of in the name of speed for quite some time. In both web and game dev, it's come back to bite when it's time to debug.
Concurrency is hard, and anything with a ton of user interaction or communication across multiple parties induces concurrency (never block the main thread and all).
YMMV, but I find C# and TypeScript to have a "Goldilocks" mix of OOP and FP that you can take advantage of the strengths of each where it makes sense.
You’re absolutely right, they are incredibly pragmatic.
I've been playing around with an idea about OOP for awhile, not sure if it'll ring true or not but I'll run it up the flagpole for feedback.
I think FP is a great way to program actions and agency but OOP is a great way to model the world. I like Rust's trait system because the polymorphism is based on what you want an object to do not what it is. But when you're creating models of the world it's usually really convenient and even accurate to use nested inheritance models. Maybe the original system for this is the flora/fauna taxonomy but it applies to a lot of things; like GUI elements or game models.
If this is correct, it might explain why the discourse is so polarized. Whether OOP is a blessing or a curse probably depends on whether you're using a programming language as a modelling language or as a logic/execution language.
It's not hard/fast but I would tend to agree with an approximation of this.
Back when I worked properly on big games the UI libs would often be trees of widgets with injectable functions for modifying the rendering, which is actually one of the points in this blog the writer would like. (The UI lib of classic Sims was exactly like that). These days the stuff I've done, although entirely in JS, at https://luduxia.com/ follows that pattern for the 3D components at least. The world is defined in an almost classic scene graph and then behaviour is added by attaching functions to pieces, which can be composed functionally.
Much of the anti-OOP noise is the result of people that have suffered from others creating hierarchies of the world too literally. Quite why it proves so difficult for developers to slow down and think about the right course of action is beyond me. They're also staggeringly resistant to changing afterwards.
1 reply →
I shall recommend this talk for you https://www.youtube.com/watch?v=rX0ItVEVjHc
4 replies →
> OOP is a great way to model the world
There's a reason Simula was the first OOP language.
https://en.m.wikipedia.org/wiki/Simula
Absolutely agree. I think people saw that a lot of games are written in C++ and got confused into thinking that the right thing to do is to build your entire game in a systems language. The fact that we have games written entirely in C++ is mostly just due to the enormous amount of inertia that game engines have, and the fact that many of them have origins that go back decades to a time when the programming language landscape and broader development ecosystem were completely different.
And now, the most popular generally available game engines right now are: Unity - C++ in the engine, C# for game code Godot - C++ in the engine code, GDScript or C# for game code Unreal - C++ in the engine code, somewhat mangled C++ for game code BUT with also one of the most capable and widely used visual programming setups I have ever seen
I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.
> I wouldn't be surprised if the "next great game engine" had a Rust core and some other language- I mean why not C# at this point?- for game code.
That's why, the first time I saw Bevy and Amathyst, I had an immediate "they're doing it wront$ reaction. IMHO, to be a true game engine in the modern sense, instead of merely a game framework, your engine needs to be a precompiled, standalone executable in a systems language that picks up, loads, and executes game scripts, data files, and assets that are totally separate from the engine itself and written in higher level languages. You don't want to be writing everything in a rigid systems language and especially don't want to have to compile your game logic and your engine together and then link them as if the engine were a library. That's why I'm (very slowly) feeling out what a proper game engine in Rust might be like with https://github.com/alexispurslane/embryo-engine. It will take me some time, since I have to learn real time computer graphics and a lot about game engines, but I've got the books, I've made a lot of progress in learning them, and the engine design and architecture is coming together very well in my big black notebook, so if you're interested, give the repo a watch ;)
I'm debating between embeddable common lisp (to satisfy my hacker impulses) or C# for the scripting language. I have figured out, I think, how I'll embed C# in Rust down to some pretty detailed steps, involving a two stage process, but .NET is so heavy I'm worried if it'll be worth it. I'd love input!
2 replies →
Isn’t the trait system exactly the way out of this tar pit?
Obviously that is the intention, but the absence of libraries that manage to replicate what people manage fairly easily in other paradigms does show it's not sufficient.
golang is similar in this regard - it has interfaces and you can compose type structs, but the results become an unwieldy mess unless the developers are staggeringly disciplined, in which case they'll have a better time in something else anyway.
This makes a lot of sense. Wonder if Bevy will add support for GDScript or C# or something. I think it's generally opposed in the interest of ensuring the Rust devex is as good as possible, but it's coming eventually, I think.
A general bevy scripting crate has already been in the works, they were waiting on various things like be y reflect and other such features to be able to work properly and so forth. In other words it's already planned and there's a lot of work being done on it with a whole lot of dependent functionality coming out in every single release.
I only skimmed this article, but, despite it being very negative about Rust, I almost 100% agree with it: Rust is a HORRIBLE choice for game dev. I might quibble with how they outline the costs and benefits of some of the design patterns that rust forces you into, for instance I think command lists are actually incredibly useful and perfectly fine as a game development thing and not the huge problem they consider them to be, and generational arenas basically solve any pointer ownership problems in game development in my opinion, but they are right in the main.
I know, because I've tried it. Once. I would #never* recommend Rust to game developers, especially not indie ones. In fact I'd recommend against it strenuously!
And this is precisely because Rust is explicitly and knowingly focused on correctness, safety, perfectly clean code, etc at the cost of iteration speed and flexibility and dynamicism, and that's bad for designing game mechanics and even just getting a game done — games have an inherently short life span and development cycle, so safety and correctness and code quality don't matter a whole lot. It's okay if they crash, etc, as long as they work enough to play. It's okay if the code is ugly, you probably won't be working on it for very long. This is even moreso the case, as the author says, because in writing a game you really want to be able to iterate quickly and just. Do shit as an experiment, even if it's temporary, to see how it feels.
On the other hand, who I would recommend Rust to is the people writing game engines, where you really will probably be working on that code for years to come, where stability and correctness is pretty important, and so where Rust's strengths will really shine — but crucially, even then, I'd tell them to make it a real engine, not a game framework like Bevy, by adding a highly flexible, dynamic scripting language like Lua or even C#, and a data format for specifying scenes and entities, and an editor. That way you don't write your game in Rust at all!
Quick note: I'm actually very slowly prototyping something like this here: https://github.com/alexispurslane/embryo-engine/
I'm disabled so I don't have a lot of energy to work on it often, but, especially once I nail down the last few design issues, I'd really love help, or even just a few eyes on the project to encourage me ;)
I like it, I read the Design Document. Do you have any game concepts you are building with it? It seems like the kind of project that would be built with a game side-by-side.
1 reply →
> Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
I found this to be true of C after many, many years coding in C. I noticed that the first selection of data layout stayed throughout the life of the code (with a lot of tweaks, additions, etc.). But didn't really think that much about it.
Until I started writing code in D. It was easy to change the data layout, and I did for experimenting. For example, changing a reference type to a value type, and vice versa. This was easy in D. It's just too much work in C, so it didn't happen.
The reason is simple:
To switch between a ref and a value type, you've got to search/replace the -> into ., and the . into ->, and not disturb the dots and arrows of the other types. When dealing with 100,000 lines of code, this is a non-starter.
But with D, both reference and value types are used as:
making it easy to switch between the two, and also switching function parameters from values back and forth with references.
I agree, and D with the GC lets me prototype quickly. Its type system gets progressively stricter with constraints, for code that survives. I wouldn't want all the type system to apply to prototype code or a nascent program.
I tend to add in the constraints only after the code works. Two different parts of my brain.
The power of attributes and get/set in languages like C# is similar. It's easy to turn value types into functions. Or to move a value into a subclass and you don't need to do a.b.c (moved c into b) because you can add c => b.c to the a class.
You could hack the C compiler!
https://github.com/tsoding/tic-tac-toe-auto-deref
https://www.youtube.com/watch?v=yKI-VOBBFu8
That's a good example. I actually think dot syntax is really under-utilized sometimes. Although personally, I'd prefer that if v was a reference/pointer to a struct, that v.b simply performs a pointer offset, instead of auto-dereferencing like ->.
In the same idea in Eiffel in a.b, b can be either a member or a function to allow easy replacement.
On the opposite other languages want to have no hidden function call, no hidden pointer dereferencing..
When ever I watch someone coding C(++) all they do is compile and then add remove * and & or change between -> and . when the compiler complains.
Multiply that by all the C(++) coders on the planet and we have lost a billion man hours...
I've worked on Ambient Engine and now on the Bevy engine. I totally agree with these points, very valuable.
I only make some comments from my professional (audio) perspective:
We need the highlight author's affirmation of cli. Rust's tui (ratatui) is great. I used it to make Glicol-cli [1]. If you are a Linux user, you are welcome to test the music production of the code.
Speaking of game audio, I actually think rust is perfect for audio. I have also continued to develop Glicol [2] recently, and my recent goal (starting tomorrow) is the bevy_glicol plug-in. I want to solve bevy's audio problem on the browser.
All in all, even though I've had my share of pain with ecs, I still think rust is very valuable for game and app development, maybe not multiplayer AAA, maybe practical apps.
[1] https://github.com/glicol/glicol-cli
[2] https://github.com/chaosprint/glicol
This looks very cool. Are there more videos of glicol being used live?
https://youtube.com/playlist?list=PLT4REhRBWaOOrLQxCg5Uw97gE...
I think the crux is this heading: Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
Jon Blow said that in one of his talks: Rust treats all code as production code. For most of the duration of a project, that's counterproductive, because it introduces a significant amount of unnecessary friction.
For most of a game's development, you're trying to figure out what the game's supposed to be. Only later does it crystallize. Rust doesn't recognize the non-crystalline phase, or rather explicitly rejects it as invalid.
As much as I love Rust I sometimes wonder if I'd be more productive in a simpler language. If I wrote it every day I'm not sure that would be true, but as a hobbyist coming back to Rust sometimes takes me a bit to get back in the zone. Also, still not a fan of async, as it is woefully incomplete and fairly complicated in some use cases. That said, I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either. I long for the "in between" language, but with an amazing 3rd party ecosystem as both Rust/Go have.
NOTE: I'm not a game dev
Maybe people will make fun of me, but I've been very happy with Kotlin and Dart. Null-safe, good ergonomics, very fast.
I've tried Rust, sometimes play with C, D, Deno/TS, Nim, Java (actually I still write lots of it) and even some more cutting-edge stuff, like Unison. While they're cool, what I want is a language with really good tooling that gets out of my way without letting me write patently dumb code (like Java lets me use any object without checking for null, when it can be null but the language just doesn't give a shit to help me).
I use Dart when I want to compile to binary executable or use Flutter, and Kotlin for stuff I think the JVM has more to offer, like a server. The two languages are just a pleasure to use, pretty similar but having completely different ecosystems (which is great, you can use the best one for the job!).
I'm glad you found tools/languages that work for you. Kotlin felt a little too much like Java to me. If I stuck with a JVM lang. I'd probably go back to Scala 3, but I just don't like the JVM as a user (just sucks too many resources).
I wrote a Flutter package[0] that wraps the Filament 3D renderer, which I used to make a mini game for a Flutter game competition:
https://devpost.com/software/escape-from-heat-island
(Judging is still ongoing and votes would really be appreciated! It would help me to get more resources to work on the underlying package).
This was my first ever “game” (tech demo, really), and I’m not a game dev, so take this with a grain of salt - but I do think there’s a lot of potential for Flutter/Dart as a game framework. Hot reload makes iterating on game logic very fast, you obviously get the UI toolkit and cross-platform support straight out of the box, and the language itself is (relatively) concise, so it lends itself well to gameplay programming. When you need to get your hands dirty at a lower level, you just drop down to C++ (or whatever engine you can expose via FFI).
I think Google believe that Flutter can nab market share from Unity in casual 2D games (hence their official sponsored competition), but I think it has even more potential than that. In fact, I’ve seen at least two game companies (Supercell and another whose name I’ve forgotten) hiring for people to work on embedding the Flutter engine in various platform games.
[0] https://github.com/nmfisher/flutter_filament.git
I like Kotlin but I find the fact that it lacks a good way to detect and handle possible errors very frustrating. If some function can fail on sane-looking input I'd like to know about it
Flutter sounds so awesome but really want something like OpenGL for it.
OCaml could be that language.
I’m not convinced that ecosystem is so important for game dev. Once you have a simple graphics library, bindings to BulletPhyiscs etc most of the code is custom simulation code with no integrations needed.
I can echo OCaml. It is probably the most underrated language imo. It has great compilation times, macros, type inference, good tooling. With few exceptions, the library ecosystem doesn’t suffer from the same overengineering issues as Haskell and types are kept relatively simple. It has simple runtime characteristics making it easy to optimize performance when needed, although it tends to be very fast in general.
1 reply →
> I just can't go back to Go with nil pointers and lack of decent enums/ADTs/pattern matching either.
Go is simply a badly designed language where the idea of "simplicity" has been maligned and proven bad ideas likes nil/null, exceptions and such have been introduced in a seemingly modern language. One would think that decades of Java, Javascript, etc. code blowing up because of this issues would teach someone something but seems that is not always the case.
Having worked with Go for about a decade now, I largely agree that nil is a pain in the ass to work with, and the language has largely done nothing to make it better. However, Go (mostly) doesn't have exceptions. Ordinary problems are represented by non-nil errors, which are values. Panics exist but really are reserved for exceptional situations (with the number 1 cause being, of course, dereferencing nil).
2 replies →
"code blowing up because of this issues"
I ran into these issues all the time with Java, C++, and Python projects.
But it's just not the experience of running Go in production, which I've been doing for over 10 years now, across many projects with many devs.
In practice, nil checks are just not very difficult to include everywhere. And experienced Go programmers don't use exceptions (panic/recover) almost ever.
1 reply →
And yet it is incredibly productive. The poster that contrasted engineers with artists got it right I think. Go is an engineer’s language.
5 replies →
Go is great
I've been hoping to see more languages that compile to Go, it might be the most practical way to arrive at what you want. For example, see Borgo: https://news.ycombinator.com/item?id=36847594
> I've been hoping to see more languages that compile to Go
One could also use Go-Assembler as a cross-platform assembly target: https://go.dev/doc/asm
I keep toying with the idea of creating one. :-)
Borgo looks neat - hadn't seen it before.
As much as I dislike many of the legacy issues with JavaScript I find TypeScript to be the best language to iterate with. If Rust had GC without need for wrappers like RC though I think that would be my preferred iteration language. I mostly try to write my TS in a manner that would translate to Rust, but that's hard to do sometimes when it comes to memory management.
It doesn't occupy the same space, but the simplicity of Gleam has been very enjoyable to me. It's still quite a young language though, but worth keeping an eye on.
For me, the closest language currently is F#.
The open-source ecosystem is not as massive as Go's or the JVM's, but it's not niche either. F# runs on .NET and works with all .NET packages (C#, F#, ...). If the .NET ecosystem can work out for you, I recommend taking a closer look at F#.
F# allows for simple code, which is "functional" by default, but you're still free to write imperative, "side-effectful" code, too.
I find this pragmatic approach works extremely well in practice. Most of my code ends up in a functional style. However, once projects grow more complex, I might need to place a mutable counter or a logging call in an otherwise pure function. Sometimes, I run into cases where the most straightforward and easy to reason about solution is imperative.
If I were confined to what is often described as a "pure functional" approach, I'd have to refactor, so that these side-effects would be fully represented in the function signature.
F# ticks the enums/ADTs/pattern box but also has its own interesting features like computation expressions [0]. I would describe them as a language extension mechanism that provides a common grammar (let!, do!, ...) that extension writers can target.
Because of this, the language doesn't have await, async or any other operators for working with async (like C# or TS). There's an async {} (and task {}) computation expression which is implemented using open library methods. But nothing is preventing you from rolling your own, or extending the language with other computation expressions.
In practice, async code looks like this:
I often use taskResult{}/asyncResult{}[1] which combine the above with unwrapping Result<>(Ok or Error).
Metaprogramming is somewhat limited in comparison to Scala or Haskell; but still possible using various mechanisms. I find that this isn't a big issue in my work.
IDE-wise, JetBrains Rider is a breeze to work with and it has native F# support. There is also Visual Studio and VS Code with Ionide, which are better in some areas.
You can run F# in Jypiter via .NET Interactive Notebooks (now called "Polyglot Notebooks" [2]). I haven't seen this mentioned often, but this is very practical. I have a combination of Notebooks for one-off data tasks which I run from VS Code. These notebooks can even reuse code from my regular F# projects' code base. Over the past years, this has almost eliminated my usage of Python notebooks except for ML work.
[0]: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
[1]: https://github.com/demystifyfp/FsToolkit.ErrorHandling?tab=r...
[2]: https://marketplace.visualstudio.com/items?itemName=ms-dotne...
Do you know of or have any shareable (sample) projects implemented in your way of doing F#? It sounds very intriguing to me
4 replies →
Isn't that just Swift/Kotlin?
The problem with languages is they don't compose. Iow, one missing feature needed automatically invalidates the language entirely. Swift is targeted at Apple platforms and cross platform is an after thought. Kotlin targets JVM and while it is cool in concept, I hate it as a user (and Kotlin native isn't near as mature). If were considering something else at this stage I'd probably put my time into F#, but even it has its cons.
NOTE: By "compose" I mean that if I want feature A, B and C from lang X (has A and B), Y (has B and C) and Z (has A and C), but there is no way to get A, B and C in one language without creating a brand new one. I cannot mix and match features from different languages.
3 replies →
It's any of:
Rust + (garbage collector)
Swift + (cross platform support)
Kotlin + (proper pattern matching)
Unfortunately, none quite hit that central sweet spot, IMO
3 replies →
And Zig maybe?
Yeah I long for a language that has rust enums and pattern matching but none of the async or borrow checker.
Maybe I should just unsafe rust and see how I go....
Have a look at Scala.
I mean.. Java is there. Java 23 is really interesting.
When is Java getting value types? It has been talked about forever now.
6 replies →
Rust is in a separate class of go and swift and kotlin and etc. The class it competes on is pretty C, C++, and itself.
Yes it's easier to write trivial code in python than Rust. Yes it's harder to manage memory manually than it is to let a gc handle it. I don't see the point.
Rust is a systems programming language. It's hard to write a server in it than it is to hack something in node, but it will also be faster and more reliable. Conversely, it's easier than writing it in C++ or C, while still being more reliable. That's the whole value proposition.
Swift has a systems programming subset, and an even smaller embedded programming subset.
Of course "smaller" is significant here; it has less features and you might not like using it anymore.
For Apple, Swift is their Rust, regardless of the world outside Apple's ecosystem thinks about it.
It is clearly stated on Swift's documentation, they already hold a couple of talks at C++ conferences about code migration, and is one of the reasons why nowadays they mostly focus on LLVM contributions instead of clang.
Oh my, this has to be my favorite quote in a blog in a long long time.
"... many if not most of the problems don't go away if one isn't willing to constantly refactor their code and treat programming as a puzzle solving process, rather than just a tool to get things done."
I have thought it was just me for a long time, but many of the popular styles of programming that we push definitely seem to require constant refactors in the pursuit of a solution. And I definitely see more tire spinning for the sake of the build than I do for whatever it was folks were building.
Great quote.
It is a great quote!
I think multiple refactors in pursuit of a solution can be a good thing. As your thinking/design evolves, so does the shape of the solution.
The main problem, I think, is that this goes against specifically gamedev. In gamedev whether the solution is the best or more resilient is secondary to extremely fast iteration and delivering something. Like the author says, sometimes "clunky but good enough for now" is what you need to get it over with (for the moment) an iterate rapidly over the gameplay elements you should spend most of your time on. Gameplay, not correctness or reliability or maintainability, is the most important thing in a game.
When I set out to learn Rust about a decade ago, I chose to write a game - a clone of "Empire" that I call Umpire.
It's a different task to re-implement an already-designed language rather than designing and implementing at the same time. Nevertheless I have run into a number of the difficulties mentioned in the article, and arrived at my own solutions - foremost passing around global UUIDs rather than actual `&` references, and enforcing existence constraints at runtime.
I've experienced the protracted pain of major refactors when assumptions baked into my data model proved false.
In some regards these refactors wore some of the shine off of Rust for me as well. BUT I'm still glad the game is implemented in Rust, exactly because of Rust's dual emphasis on safety and performance.
The AI I'm developing requires generation of massive quantities of self-play data. That the engine is as fast as it is helps greatly.
Rust's strength in ML means my AI training and game code can share important types, ensuring consistency.
The effectiveness of Rust for writing CLI tools (mentioned in the article) has lent itself to a number of game-specific command-line interfaces that are of high quality.
Rust's memory safety became critical once I decided to network the game. I don't want `umpired` to be any more exploitable than it needs to be.
My constraints have been very different than the OP's; obviously it makes sense for their studio given their experience to move away from Rust. But I think Rust still has a place in games.
* https://en.wikipedia.org/wiki/Empire:_Wargame_of_the_Century * https://github.com/joshhansen/Umpire
> Rust's strength in ML
Most of ML frameworks that I know are implemented in Python and C++. I tried looking at ML in Rust a few years ago and didn't find anything useful. Has it changed?
You can use libtorch directly via `tch-rs`, and at present I'm porting over to Burn (see https://burn.dev) which appears incredibly promising. My impression is it's in a good place, if of course not close to the ecosystem of Python/C++. At very least I've gotten my nn models training and running without too much difficulty. (I'm moving to Burn for the thread safety - their `Tensor` impl is `Sync` - libtorch doesn't have such a guarantee.)
Burn has Candle as one of its backends, which I understand is also quite popular.
I agree with a lot here, but I think the author is overplaying "get things done fast" or underplaying "stable, performant code". I like indie games, but I've played enough games that crashed if I look at them wrong or chug despite being low poly early 2000s things that I now hesitate to buy indie games. Some of the examples seemed like maybe rust was preventing a weird unexpected feedback or clobbering iteration state or whatever.
I don't think the author disagrees here and is mostly talking about awful runtime alternatives (refcell, etc) but I just wanted to say it for balance.
> As far as a game is concerned, there is only one audio system, one input system, one physics world, one deltaTime, one renderer, one asset loader.
I thought this way when I was doing Java dev around 10 years ago. I thought it excused the singleton pattern. I was wrong!
You should always be able to construct an object by explicitly passing dependencies to it. Especially for testing.
It really is no fun if your renderer starts talking to your asset loader and timer directly.
People should get more into integration tests. If you start out thinking you need to separate everything for unit testability, you instantly get architecture astronaut-ism, where your architecture is entirely based on fake testability instead of the thing it's actually meant to do in production.
All praise our almighty lord that is dependency injection
No. You don't need ability to DI every single functionality. And you can still do DI with global state, just with less granularity.
Unit testing in Game dev is largely useless.
> wait I can't add this new thing because things will no longer compile, and there's no workaround other than code restructuring
I definitely think that's a great feature. I want to learn on day 2 that the design is a dead end, not on day 101 when I ship on day 100 and there was a race condition on day 2 I never noticed.
But the thing about gamedev (I guess - I'm not a game developer) is that the code being great and doing what you hope it will do isn't 100% of the job as it is in other disciplines. In gamedev you may want to run the code, and the way it runs (fun, feel, whatever) might be bad even though it compiles, works according to a spec and so on. So while I'm usually happy to write code for a week and never run it - game development feels like it's all about the iteration.
That said, game development is also game engine development. And Rust seems absolutely perfect for engine development (you need "fearless" concurrency and performance and there are zero mainstream languages that will do that other than rust). For people who feel it's too rigid or hard to iterate with perhaps hybrid could work. Like Rust + Lua or something sounds like it could be worth trying.
I think the point is that there are few "code related" dead ends in game code with good game play that can't be dealt with using enough effort. There are plenty of "game play related" dead ends that no amount of clean code can help out.
To that end, whatever can help you explore the game play the fastest is what you want.
Quick iteration perhaps isn't the biggest strength of C++ either. Rust does have some friction when it comes to "I'll try this with a dirty impl and if it flies, then I cam make a clean one later". I guess if that friction is worth it will depend on how much faster you get on other things, e.g. refactoring without spending a lot of effort worrying about introducing hard-to-spot bugs like races, or - worse - having to spend valuable time fixing those bugs instead of adding fun to the game.
1 reply →
> game development is also game engine development
not necessarily. Loads of games and game developers do not engage in any engine development at all, they just use an off the shelf engine and make their game, treating engine developing about as close as web devs treat database development.
I've become wary of commenting on articles that mention the pros and cons of various languages, but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on. When it should be the other way around.
The joke he mentioned about having 50 engines written but only 5 games certainly rings true and I don't think the language is the main problem preventing people from getting their projects done..
The hardest part of a project is finishing it. I think the main issue is the fun problems to solve happen very early in the project and once those are done it becomes incredibly tedius and boring and I usually lose focus until the project dies. Its difficult to maintain motivation.
Interesting, I almost find it the opposite right now. Learning the engine is a pain in the ass -- it's not particularly hard, just tedious to learn all the APIs and quirks -- and then when you're initially building the thing, "it's not fun yet" for a quite a while. But then once you have the fundamentals down, you can add more abilities and characters and other features, that's the fun shit.
I was working on the AI last night, and since I already had one functioning AI agent, it was pretty easy to spin up variations that behaved in moderately different ways, which was very fun!
I've only been dabbling though, and still sort of in the prototype stage, not quite a full game yet but getting there. Maybe I'll feel more like you suggest deeper into development.
2 replies →
Right. If someone could come up with a pill or something to maintain motivation and make all the bugs and hairy annoying details feel fresh again, just like the feeling of starting over, I would certainly part with my money. But there's no such thing unfortunately.
1 reply →
IMO one language can sidetrack you more than another. It might not be the main problem but a language that gets in the way for your usecase causes you to focus on the wrong problem. Making a good game is really hard and really needs you to focus outside the tech.
Totally agree
My unpopular programming opinion: languages aren't that interesting to me
I'm much more interested in the problem being solved and algorithms in the abstract sense
Yep.
Bikeshedding, how many angels can dance on the head of a pin, and https://xkcd.com/927/ are some ways of loosely describing what you said.
https://en.m.wikipedia.org/wiki/How_many_angels_can_dance_on...
>but I still find it strange that so many people are so strongly focused on what their favourite language can do (usually better than others), instead of the project they're working on.
Yes, if they are so convinced of that, why are they not back in the office or at home, working busy as a beaver on their project, using that great programming language, the benefits of which they extol?
Smells fishy to me.
Oops.
Do people see what I did there? ;)
This is a very brave post to write given how incendiary responses to rust criticism can be, but this matches my experience entirely.
I think I just read about 10 versions of this comment on this page, and definitely not a single response to the criticism that could be described as incendiary. I don't think I even saw a single comment just now that fundamentally pushed back on the premise of this article, let alone in an incendiary way. It's early yet, and maybe this thread will look very different in a few hours though?
The author maybe somewhat hit on the reason for this in the article, where they mentioned that they're already seeing some of the rabid, toxic, Rust proponents already moving onto the next "hot" thing and doing their thing there. So maybe after a few years of Rust we've arrived at the turning point now where enough of those types of people have finally moved on and the Rust community has significantly changed.
1 reply →
Perhaps because the article is about how Rust isn't the magic bullet to everything, and a few people have commented agreeing with the article, others feel more willing to comment their own Rust isn't perfect opinion as well.
If you go into the comment section of a pro-Rust article, where the first few top-level comments are also pro-Rust, the responses to people expressing a negative attitude about Rust tend to (in my experience) be different.
This phenomenon certainly isn't exclusive to Rust (or HN). It happens all the time, especially when a prolific commenter is among the first few comments. It can set the tone for the entire comment section.
1 reply →
I assure you it happens, but the people targetted this way usually quickly learn what is ok and what isn't to say, especially on rust's reddit. If you wanna see examples, look at my reddit profile (same username). I dared to say bevy was full of hype and false promises and tat the money they get would be better spent elsewhere. And look at the hate i received.
One way i've seen to reduce this is prefixing any posts with "I am not criticizing any engine in particular" even if it's blatantly obvious because the criticism only applies to one.
1 reply →
> incendiary responses to rust criticism can be
I've not experienced this. Do you have examples of the rust community flaming someone for having negative opinions about the language?
Based on what I've seen, various forms of censorship and suppression are often employed in such cases, rather than outright "flaming" or other discussion-based approaches.
It really depends on where and how the discussion is taking place, and what censorship methods the website/platform/medium involved offers.
Sometimes users are just outright banned or shadow-banned, if those happen to be options.
Sometimes forum threads, bug reports, or comments are deleted.
Sometimes the discussion remains accessible, but is stifled in some way. This includes closing/locking forum threads or bug reports, or otherwise severely limiting participation in such discussions to a very small and isolated group of people. If down-voting/reporting systems are present, sometimes they're used to limit the visibility or prominence of such discussion.
4 replies →
Not parent, but take a look at these:
https://news.ycombinator.com/item?id=39641552
These threads are absolutely painful to read. The Rust community/leadership would not do anything about it because Rust thrives on such "devotion".
1 reply →
Check this response to the article within these HN comments: https://news.ycombinator.com/item?id=40177534
Not actually flaming but quite condescending towards the article writer. Not even properly reading the article and coming to conclusions.
This is on HN which is generally more neutral towards Rust. I imagine in Rust circles these types of responses would come out a lot more.
I'd go read their mailing list and Reddit forms; especially when people run into issues doing stuff that's very simple in other languages. Never seen a more toxic programming community.
Hopefully they calm down, or really get drown out, once there are a real number of jobs for people using Rust. Right now the evangelists outnumber the rank and file who are just using a language to get work done.
12 replies →
[flagged]
3 replies →
This is a textbook example of poisoning the well. [0] We see it used in every discussion about pros and cons of a language on HN.
It's some variation of "People who like this language can't handle criticism/are part of a cult/etc." The idea being that this will preclude anyone from responding to a criticism, because that would confirm the comment.
[0] https://www.logicallyfallacious.com/logicalfallacies/Poisoni...
I find that Jonathan Blow ranting about Rust game development here https://www.youtube.com/watch?v=4t1K66dMhWk. He adds interesting perspectives to the discussio, how the language makes the Rust game developer resort to arrays and their so called Rust point of views.
The blog post reminded me of a quote from Jonathan Blow as well. I forgot the exact wording, but basically he said that Rust makes you treat every state of the project to be production ready (e.g. free of memory safety bugs), but in game development, most of the time the project needs not to be production ready, and for a good reason (rapid prototyping). You just have to fix the really bad things (crushing bugs) before shipping.
There is a better, more recent clip of him where he explain 'would we haven chosen rust, the witness would never been finished'.
Well the problem with Jonathan's argument here is that he's spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games.
So it turn out that even if he's opinion on Rust is correct, he would still have been much more productive using it than trying to build his own language for a decade…
(But he already shipped his masterpiece and he's a millionaire so he gets to chose his full time hobby as he wishes)
He is actively developing his new game in parallel to creating the language.
Not to mention smaller projects like 'Braid- anniversary edition'.
6 replies →
>spent the past decade mostly ranting about Rust and working to make a perfect game programming language, instead of making games.
I wish. As far as I can tell he made a single hour long video shitting on rust and now he's the enemy of the cult. That's hardly spending the last decade sitting being mad over rust.
Why should he be making more games, instead of building his vision of a perfect language?
A machinist who retires from running lathes and goes into the lathe-making business has reached the pinnacle of that profession.
Writing games in C++ feels horrible which is a large part of he wrote the language.
I mean, he does like a good rant lol. But this seems like a bad take. The witness came out ~8 years ago, and Braid came out ~8 years before that. Braid Anniversary is launching next week, he's actively developing his language and next game (occasionally streams). "he's just resting on his laurels now" I think is clearly wrong
Interesting read! If I had not picked Elixir + Godot for the multiplayer game I'm making, then I would've gone with Rust for the whole thing. The old naive version of me would've tried doing it in C++ + Unreal but I knew better this time around.
I think multiplayer game devs are sleeping on Elixir! It has made the network side of things so much easier and intuitive with fast prototyping and built in monitoring - so many lifetime issues are easily found and addressed. I'm pairing Elixir with Godot, Godot is used for the frontend game client. And its crazy because I thought the game client part would be the "hard" part as it would be a new skillset to learn, but Godot makes the actual game part very easy. GDScript is easy to learn, and the way Godot uses "signals" is very similar to the backend code in Elixir with message passing so its not a huge cognitive shift to switch between server/client code.
I get that BEAM doesn't lend well to highly computational tasks, but I just don't see how thats an issue for many types of multiplayer games? If you aren't making some crazy simulation game, then most of the backend computation is more around managing client state and doing "accounting" every tick as inputs are processed. The most computational task I've had is server-side NPC Pathfinding, which I was able to quickly offload onto seperate processes that chug along at their own rhythm.
I would love to read more about these Godot/Elixir adventures. Do you have a blog or a repo I could look through?
No blog unfortunately, the notes are all on paper. I have github page for the game where I ramble a bit: https://github.com/mikhmha/SWARMMO
But I'm planning to release the game for testing next month! Its a browser "MMO" game too so its going to be easy to try out. And then I'll have time to write some more detailed technical notes online.
> The most fundamental issue is that the borrow checker forces a refactor at the most inconvenient times. Rust users consider this to be a positive, because it makes them "write good code", but the more time I spend with the language the more I doubt how much of this is true. Good code is written by iterating on an idea and trying things out, and while the borrow checker can force more iterations, that does not mean that this is a desirable way to write code. I've often found that being unable to just move on for now and solve my problem and fix it later was what was truly hurting my ability to write good code.
The latter part of this is true for any strongly statically typed language (with Rust expanding this to lifetimes), which negates the beginning of this paragraph -- once you get things compiled, you won't need to refactor, unless you are changing major parts of your interfaces. There are plenty of languages that do not have this problem because it is a design choice, hardly something Rust can "fix", it's what makes it Rust.
This is the opposite of my experience with other strongly typed languages. They're easier to refactor, because when you change the types, say you delete a field, everywhere that field was used is a compile error. Clean them up and on your way.
The borrow checker is an entirely different beast. People forget that safe Rust allows a subset of programs. Finding the subset which does what you want can range from easy, to hair-pullingly gnarly, to provably impossible.
The author is asking for a "give me a break" feature. I would say that in a strongly typed functional language, this is akin to mutating objects. The author seems to wish for an unsafe option to locally turn off the borrower check. Is it something Rust could not offer?
You can always dip into raw pointers and come back up for a reference, or eg. do a transmute to a static lifetime. Absolutely not okay according to the language rules but it will compile and will probably also run without an issue if you're not doing something wrong in your code (eg. Wanting to keep a reference to a string while you also mutate it.)
I'm actually surprised that the author didn't seem to consider this much of an option.
My experience is that the ecosystem is a mess, have hit winit, wgpu, and countless bevy bugs, iteration times are abysmal, documentation is nonexistent. In the time it would take me to make a game in popular Rust tooling I could build the game and engine from scratch in C and also have something that would crash less.
> documentation is nonexistent
You know, I think this point is important to get right: there are generally docs, Rust does a very good job of making it easy to write docs.
What doesn't always exist are guides that explain how to piece things together. Sometimes you wind up needing to really know the inner platform to piece together things in Rust, and while I love the language, this is one area where the community could improve.
Yeah, in general with large and Powerful libraries or frameworks, I find that pure API documentation, even if very thorough and well explained on an individual function or data structure level, is just simply not enough. I also want a reference manual type experience, where that API reference is integrated with explanations of the reasoning behind how the framework was designed, and how to actually think about using it, and examples of many common things you might want to do that integrate well together. The gold standard for this in my opinion is the opengl Red Book.
This, and the fact that correctness and safety and stability aren't quite as important in game development, or even game engine development, as they are in other fields where rust is applicable, is why I purposefully happily use the powerful, futureful, well established, copiously documented C or C++ libraries I need, instead of tge Rust alternatives, for almost everything. It works extremely well for me because I get to leverage the power and amazing ecosystem around things like dear imgui or sdl2 or opengl or physx, while being able to use rust, which grants me essentially a cleaner, even more modern version of C++ with all of the features I love from ocaml, in a way that restricts any weird crash or memory safety errors to the places where I interface with the lower level libraries, and sometimes not even there, depending on how high level the bindings are. It's honestly pretty nice for me.
Man, slower than C++, that's pretty damning.
In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things:
1. I am using technology in order to build this thing.
2. I am building this thing in order to use this technology.
Developers often fall in the (2) camp but don't admit it. There's an allure to using the new, sexy tech that will solve all their problems, whether that's Rust, Kubernetes, LLMs, etc.
If you're in the (1) camp, you should stick with what you know; and if you know that what you know isn't enough to build the thing, you should use whatever is most common and straightforward, not something off the beaten path.
Games seem to be the biggest trap, because solo devs often end up building a game engine when they set out to build a game. If you really want to build a game, just use Unity/Unreal/Godot, I promise it'll go better for you.
I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript).
So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore wrong.
* For the sake of argument, we can pretend I only know rust. In reality I know a fair number of other languages as well, but the list doesn't happen to include C# or "random game engine specific scripting language", which seems to be the options if we're going with an established engine for big 3d games.
This falls in the "you know that what you know isn't enough to build the thing" bucket, presumably. Even if you're a Rust expert, do you know how to manage game asset content pipelines? Sound and music? Have you done graphics programming at all in Rust? How are you going to store levels in your game, and how are you going to make them? How are you doing multiplayer? etc...
You're going to have to learn something new, and it's a bit of a judgment call, but picking up C# or gdscript given that you already know programming should be straightforward compared to re-implementing all of those things yourself in Rust.
Unless, of course, you do know a bunch of great Rust game development libraries that solve all those problems--in which case yeah, building a game in Rust might be the best choice. It's not impossible!
1 reply →
Perhaps the more appropriate advice is : Use the right tool for the job.
Use C++ for writing a high performance library or a database engine.
Use Go or Java for writing a server.
Use C for writing a kernel module.
Use shell scripts for automation.
Use python for trying out ML ideas or heavier duty scripts.
Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right tool for all of the above and not succeeding much in practice.
12 replies →
Learning a new language is basically trivial relative to the effort of bootstrapping everything yourself to compensate for a lacking ecosystem, or the effort of banging your head against the fundamental unsuitability of a tool for a job.
Anyone who's learned one or two languages should be able to pick up the basics of any of the standard ones pretty much instantaneously.
1 reply →
When all you have is a hammer, everything looks like a nail. When all you have is programming expertise, all your game production obstacles look like programming problems.
I think everyone in games has met an “engine person” who spends a lot of time iterating on tech, but never quite getting to the creative expression that got them in the game. I think part of it comes a bit from mythologizing breakthrough games like DOOM, where cool technology made something completely fresh. We begin to think that emulating id Software is how you make compelling art, ignoring the latter half of Kushner’s novel.
Well said, I am weary of all the 'game' programmers that just fetishize working on the tech and particularly rendering.
1 reply →
> you need to make a strong up-front decision
Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
It wasn't just once or twice when I've picked some very promising library or tool only to learn something isn't exactly as I hoped (or as it was advertised - docs can lie, too) after I've already spent some non-negligible time implementing something with it. Save for some teenage keyboard mashing some decades ago I'm not a game developer, but I suspect this is universal experience no matter the niche.
> Developers often fall in the (2) camp but don't admit it.
There's also a mixed approach, where people admit "I want to build this thing and use this technology, and I suspect they're a potential good match so I'm gonna try both at the same time". Any even slightly creative person must have an urge to learn and explore new things, even if they aren't exactly necessary for a task at hand. Checking on the promise, if it holds true - sometimes it does and you get a new tech you love, quite frequently it doesn't and you have a bad day.
> Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
Exactly. You need to make some choices up front about program design despite rarely having enough information to make the correct decision, nor enough time to evaluate alternatives in detail. If we had known 15 years ago what we know now our then green field project wouldn't have been done this way - but we are still discovering things that the decisions we made 15 years ago are making hard to do today. That is on top of all the existing things we know are wrong that we often cannot feasibly correct.
You have to make choices. Some of those choices will be impossible to undo without starting over after a while. Some of the negatives will take a decade to figure out. There is no way anyone sane will give you enough time to figure out what those negatives are for each choice - even if the did you will be dead before you finish.
I'm in the 1 camp. After several decades of C++ I know it very well. Well enough to find some of the things that those Rust and Ada people are saying about their respective languages intriguing. I'm at the point where I need to spend some time with each to see how/if they work with my problems in the real world. Because eventually you have to admit that while you can drive a screw with a hammer there are other ways and maybe it is time to learn how to use a screwdriver.
This is what I like to call the artist vs engineer dilemma.
1. An engineer solves problems, learning and using tools. 2. And artist learns and uses tools, for the sake of it.
Neither is wrong, and some times they benefit each other. I believe much of academia and research is heavy on the artist side. You just have to be clear on which one you are at any given point.
I'm not gonna use assembly for my $JOB where we need some basic web backend. That's not gonna stop me from trying on my free time tho.
How about "I'm building this thing and I want it to enjoy the unique combination of performance and memory safety offered by this technology"?
It's certainly close to (1), but also a perfectly rational way to be a The Rust Way fundamentalist avoiding refcounting and unsafe who appears suspiciously (2).
The "rewrite in Rust" meme surely does not come from thin air and there is certainly some skill honing and challenge seeking involved. But perhaps a rewrite ever couple of decades isn't all that bad? And if it isn't, could there be a better time for it than "in Rust"?
Advice should be - you should do what you like and try to align it with your client (employer) - otherwise you'll burnout rather quickly.
It's not easy to find an employer that'll agree with your preferences. I chose to find fun and value in the way I collaborate and reach end goals, not the tools. If the tooling in my dept sucks, I just treat it like a challenge and deal with it.
1 reply →
I've found Rust very pleasant for building little games. I've mostly been using SDL + a my own little shim so I can target web through wasm & canvas.
I had professionally worked with C++ for a long time so getting comfortable with Rust wasn't too bad.
https://www.bittwiddlegames.com/ You can see a web build at https://www.bittwiddlegames.com/lambda-spellcrafting-academy...
I think these comments are fair. It's true that Rust is rigid.
I've had great success with Rust, but on projects where I knew exactly what I needed to build. Rust's focus on code correctness is great for maintenance of projects, where the priority is in keeping them stable and not causing regressions.
So while I'd say Rust is pretty quick for refactoring of something like a device driver, it's far away from the hot-reloaded time traveling live tinkering IDE.
You can feel the paranoia of the author stating 20000 times it's his opinion, giving context, etc just cause he knows the langstans reaction.
I respectfully disagree with the author's title choice.
My first impression is, of course, that the issue is there is no production Game or GUI framework around.
The author seems to complain mainly about the choices of frameworks and how bad or opinionated they are. I agree. Even Egui is too opinionated, but it makes sense on some level.
It is no problem to use bindings to some software written in C++. Rust was created to solve this exact problem: rewrite big projects that were written in C++, by slow mutation in Rust.
Honestly, I would add further that until the Unreal Engine uses Rust, we should not expect widespread Rust adoption. It will likely start with a company creating its own really custom game engine, the game becoming a bestseller, and it will spread iteratively over the years from there. Or maybe there will be a better option beyond Rust at that point.
This is the status quo: https://www.youtube.com/shorts/_zwKHgtQpc8 Let us be realistic.
Beyond that: One should see Rust as writing C with someone watching over you to remind you that you need to know the writer for each memory value. It picks up work off you. Or it should. If it doesn't, yes that is a problem, and we/you are doing it wrong.
But yes, if you are doing something that the borrow checker complains about, in other languages, either that semantic difference would have been hidden, or you would be paying for it later.
There, the author makes a point that he wants the code to work now. That is possible, and you can hotwire bad code in Rust, too. But I am sure that code is why we end up with games like Jedi Survivor.
There is no fundamental inability of Rust to do the things the author demands. If you want dynamic loading, use https://crates.io/crates/libloading (And you don't need to use the library). Do you want a global state? I will disagree with you, but take a look at, e.g., how the Dioxus project is doing it. Again I think that is always a terrible mistake, and people are thinking really of using an arena or a registry really.
As someone who's become a core contributor to Bevy lately, while also doing contract work in Unity on the side, I obviously disagree with the idea that Rust isn't up to the task of game dev. The grass isn't greener on the Unity side, with a mountain of technical debt holding the engine back. (They're still using Boehm GC in 2024!) Bevy is a breath of fresh air just because it's relatively new and free of legacy. Using Rust instead of C++ is just one part of that. Bevy has a more modern design throughout: for instance, it has a relatively straightforward path to GPU-driven rendering in an integrated system, without having to deal with three incompatible render pipelines (BiRP, HDRP, URP).
What I find more interesting is the parts of the article that boil down to "Rust isn't the best language for rapid development and iteration speed". And that may well be true! I've long thought that the future of Bevy is an integrated Lua scripting layer [1]. You don't even need to get into arguments about the suitability of the borrow checker: it's clear that artists and designers aren't going to be learning Rust anytime soon. I'd like to see a world in which Rust is there for the low-to-mid-level parts that need performance and reliability, and Lua is there for the high-level logic that needs fast iteration, and it's all a nicely integrated whole.
Long-term, I think this world would actually put Bevy in a better place than the existing engines. Unity forces you into C# for basically everything, which is both too low-level for non-programmers to use and too high-level for performance-critical code (unless you have a source license, which no indie developer has). Unreal requires C++, which is even more difficult than Rust (IMO), or Blueprints, which as a visual programming language is way too high-level for anything but the simplest logic. Godot favors GDScript, which is idiosyncratic for questionable gain. I think Rust and Lua (or something similar) would put Bevy in a Goldilocks spot of having two languages that cover all the low-, mid-, and high-level needs well.
As for the other parts of the article, I disagree with the ECS criticism; ECS has some downsides, but the upsides outweigh the downsides in my view. I do agree that Bevy not having an official editor is an ongoing problem that desperately needs fixing. Personally, I would have prioritized the editor way higher earlier in Bevy's development. There is space_editor [2] now, which is something.
[1]: https://github.com/makspll/bevy_mod_scripting
[2]: https://github.com/rewin123/space_editor
As for ECS, it's not really about upsides or downsides. It's about the fact that Rust effectively forces You to use ECS everywhere, because 'normal' game objects interacting won't fly under borrow checker.
And no matter how many upsides ECS can have, being forced to use it everywhere, rather when You want to, is the painfully part.
When will an editor be added?
That’s what’s holding me back from jumping into Bevy.
I actually think Rust is really hard, but I also think it would be beneficial to my career.
Right now it's blocked on cart rewriting the scene format.
Would it be possible to create a generic way to script Bevy? I'm sure there are a lot of people who are going to want to use C#, C++, or something else. I could imagine running a runtime in-process and Bevy communicating with it over a socket.
I mean, if you agree that the ideal for bevy would be lua integration, you are kinda agree with the author that Rust itself is suboptimal (at least in layer of game scropting), don't You?
I think whether you prefer Rust or a scripting language like Lua for high-level game logic comes down to what your needs are and personal preference. There are reasonable arguments on both sides.
2 replies →
Gaming is C++ first and foremost. All other languages suck, except when used to script game engines (C# in Unity, etc.). There's no practical reason to choose Rust or anything else. I don't think Rust is particularly bad or good here. There's decades of work to catch up on. I don't see Rust becoming a truly great language for games unless it's blessed by Epic or Unity.
> There's decades of work to catch up on
First you gotta get OpenGL going, with its horrible stateful API, give up on it and go to DirectX9. Do a complete rewrite when DirectX10 comes out. Get your real-time lighting happening with shadow volumes, run into patent issues and get strong-armed into putting Creative sound into your game. Cycle between GLSL, HLSL, and Cg. End up switching to shadow mapping anyway. Drop Linux and Mac support. Start over with Vulkan/Metal.
I don't think Rust needs to relive most of that.
Exactly. Bevy has the advantage of being built using the "right way" from the start. This makes an enormous difference in the ease of hacking on rendering code.
Ironically, the main thing holding Bevy back is the bickering at the W3C. WebGPU is still not widely supported, so we have to support WebGL 2 (with reduced functionality in some cases), and that adds a lot of complexity.
8 replies →
> * I don't see Rust becoming a truly great language for games unless it's blessed by Epic or Unity.
Which will never happen
Has there been any progress towards shipping Rust on consoles? I know the specifics are all under NDA, but to my knowledge nobody has even hinted that they've done it yet, even among the studios which are openly using Rust for backend or tooling stuff (e.g. Embark and Treyarch).
OP only appears to release their games on PC so it's not a concern for them, but for the majority of developers not being able to fit into console toolchains would be an immediate dealbreaker. I have no first hand information but what I've heard from hanging around people who would know is that Sony insists that developers only use their official LLVM/Clang fork which is customised for their weird ABI.
Rust has had tier 3 support for the Switch since 1.64, I believe. Someone had actually done it even before that but IIRC NDAs mucked up any movement on making that public.
Yeah, that Switch support was added by the homebrew side of the fence though so I don't know if it's something that developers would be able to use in an officially licensed game. Nintendo might not care so much as long as the game works, as mentioned it's Sony in particular that I've heard is picky about which compilers their developers use.
1 reply →
I've been working in gamedev since 2007 and toyed with Rust since 2014. I simply don't think that majority of games, especially indie games, have performance requirements high enough to justify using anything other than a high-level, garbage collected language.
Of course, some titles like Factorio are outliers. But for majority of games time you would spend to work with manual memory management in C or borrow checker in Rust would better be spent on other things.
I've experienced a lot of these concerns while building https://github.com/MeoMix/symbiants
I have a simple question that maybe someone smarter than me can answer confidently:
If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?
Originally, I prototyped something out using React, PixiJS, and ReactPixi (https://github.com/MeoMix/antfarm). The two main issues I ran into were the performance of React's reconciler processing tens of thousands of entities when most weren't changing (despite heavy memoization) and GC lurching due to excess object allocations. My takeaway was that if I wanted to continue writing in JS/TS that I would need to write non-idiomatic code to avoid excess allocations and abandon React. This approach would result in me effectively creating my own engine to manage state.
I decided to not go that direction. I chose Rust because no GC is a language feature (especially good since GCs in WASM are heavy) and I chose Bevy because it seemed like a fairly structured way to mutate a large amount of code.
Progress has been slow for a lot of the reasons listed in this article. I've written a lot of this off to WASM being a new frontier for game dev, and I'm new to Rust/Bevy/ECS/gamedev, and rationalized my effort by noting there's not a lot of complex simulation games running in browser (that I'm aware of).
It's not clear to me that I've made the right decision, and just need to take the good with the bad, in order to develop the type of game I want in the type of environment I want.
I personally would use C++ with SDL2, but I use c++ a lot already so I'm biased. Emscripten would allow you to target WASM.
If you're targeting the browser first why not use a browser first library like PhaserJS [0]?. I don't see a reason to work around with WASM; HTML5 canvas might be everything that you need.
[0] https://phaser.io/
I'm aware of Phaser and evaluated it, but didn't try prototyping something out using it.
My primary concerns were: lack of any coherent plan towards supporting WebGPU, TS bindings being best effort rather than being written natively in TS, and, crucially, Phaser4 being stuck in development hell.
Phaser 4 was announced in 2019, https://www.patreon.com/posts/28467752, and hasn't shipped. Current version on GitHub is v3.8. It made me deeply uncomfortable planning to build ontop of an engine that's stalled out for 5 years. I would not reasonably expect to be given support for WebGPU ever and I strongly feel that WebGPU is going to be the defining way web games are written in the coming year(s).
I also wasn't able to find any super compelling games written using Phaser. Since I evaluated it, it appears that Vampire Survivors was written using it, but then they abandoned Phaser and adopted Unity in v1.6.
>If I want to build something akin to Dwarf Fortress (in terms of simulation complexity) as a browser-first experience - what stack should I choose?
I'd suggest Haxe with OpenFL or HaxeFlixel.
> because the thing you might need to do is not available in the place where you're doing the thing
I noticed this with Rust. That sometimes Rust forces you to pull some things up the call stack in order to access them. Even if the semantics of what you do is the same Rust doesn't let you have things in arbitrary places.
It's super weird and possibly annoying when you hit it for the first time but if you stop and think about it, the place where Rust forces you to put it is a really good place from architectural standpoint.
It basically prevents you from taking parts of a thing and delegating responsibility for them to some children, which seems restrictive, but it provides you with consistent structure of where to look for things that are responsible for something.
Rust is restrictive in so many subtle ways (and some obvious ones) but I haven't seen one where it leads to worse outcomes. Maybe I have too little experience.
There are vanishingly few reasons why anyone wouldn't use a garbage collected language in modern software. I think a lot of the people using rust haven't realised how much this limits its utility. As a result of this, the language has been presented as much more widely applicable than it actually is.
100% agree. I am amazed how Rust is constantly touted as a general purpose programming language. In theory that's true, but in practice it only makes sense for projects where you would otherwise reach for C++.
Tried Rust for a very simple game, it didn't just feel right. It's like the language itself is begging you not to use it for game dev. Lol
Do they say what they replaced Rust with? I scanned through a few times and couldn't figure it out.
I assume from comments like "This is actually the #1 reason we're moving back to Unity" they're back in C# using unity
They mention that they're moving (back) to Unity/C#.
Ah, missed that. Thanks!
I'd be interested to hear the author's take on Nim [1], which seems to be better suited for game development than Rust by staying out of the dev's way [2], and supports hot-reloading (at least in Unreal Engine 5) [3]?
[1] https://nim-lang.org/
[2] https://youtu.be/d2VRuZo2pdA?si=E3N62oUJ-clXozCg
[3] https://www.youtube.com/watch?v=Cdr4-cOsAWA
I decided that Rust wasn't for me after a week long side project. But I doubted myself for a long time, as Rust seemed like such a great idea for so many reasons and it seemed like a bunch of other people were using it successfully. So I'm glad to see this article and know that it wasn't just me.
The Rust community is one of the top arguments against rust.
I've never before been so condescended to as when attempting to ask questions there. Their lack of care for perf also drives me up a wall. Anytime they propose adding an extra layer of indirection to get around the borrow checker, I have to explain yet again that with the way modern CPUs work, extra layers of indirection have serious cache-related perf costs. Then I get told that I am yet again doing it wrong, computers are fast enough, and I am worrying about the wrong thing.
> when attempting to ask questions there
Could you please give an indication of which venues you've encountered this kind of condescension in? I don't tend to see this in the spaces I frequent, but I know it is happening, and I wish it weren't. We try, sometimes, to provide some official messaging discouraging this kind of condescension, but perhaps there's something more we can do.
I don't do this usually because it's not constructive and incites flamewars, but since it was asked, this is whats 5 minutes of browsing comments got me.
1) https://news.ycombinator.com/item?id=40172883
More handwaving of Rusts shortcomings. Plus contradiction on the same sentence:
> "Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style."
In my view, here's an example from this HN comment section: https://news.ycombinator.com/item?id=40177534
If this is the kind of attitude I would get from using Rust and having to be part of the Rust community, then I think I will pass.
I think I found it:
>> Their lack of care for perf
>> I have to explain yet again
1 reply →
Many of us have probably heard that all the dumb programmers use Javascript, but even if that's true, that's a reason for me to use it. Even though I'm capable of using galaxy-brained language ecosystems, I don't need that mental overhead. And if it'll be cheaper to hire JS programmers onto the team, great.
> ECS in Rust has this tendency of turning from something that is considered a tool in other language to become almost a religious belief.
I think bevy ui is the best example to give, it's like nobody ever did a ui framework with a pure ECS before. You can conclude either that's because it makes no sense to do that or that's because nobody has ever came up with the right way to do that. The bevy community thinks it's the latter.
It's especially concerning because they constantly talk about the editor, even though they don't even have any of the fundamental pieces for a gui framework in place. In bevy ui there is no way to create a reusable ui component, there are ways to do it but they all suck. So it's not even a matter of a lack of widgets or something, the problem is you can't even write a reusable widget, there is no foundation for a ui framework, and there isn't even a real plan to change it because nobody knows how to write a gui framework with a pure ECS.
But even if they figured that out, things like text input fields can't be properly implemented because there is no proper text rendering engine in bevy so they have to rewrite that first. Except that all rust text render/layout solutions in rust (it has to be pure rust because wasm/because it's rust) are still very experimental and immature.
It's a huge pain in the ass, people write games in rust because they want to write rust, not because they want to write games.
Just waiting for someone to write a 5000 word essay on why they are moving from Rust to do data science stuff. Totally puzzled by everyone trying to get on to the Rust bandwagon on DS/DE, when being able to iterate and make changes fast is why Python rules even though it is dog slow.
I'd expect a move from Rust to Julia over a move to Python.
Why do you think it is dog slow? Most of the ds/de libraries are in C/C++, with python just calling. I personally checked JSON parsing with Go/Rust/Python. Guess who won.
So, python is not slow if you don't use python and depend on C/C++. Got it. LOL.
I would love to be able to bypass the orphan rule for internal crates.
I would love to make it possible to bypass the orphan rule in general, including for crates published on crates.io. This is an important issue for ecosystem scaling, in many different ways.
It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrapper. Usually, whichever library is less popular ends up adding optional support for the more popular library. This is, for instance, one reason why it's really really hard to write a replacement for serde: you'd have to get every crate currently providing optional serde support to provide optional support for your library as well.
In other ecosystems, you'd either add quick-and-dirty support in your application, or you'd write (and perhaps publish) an A-B crate that implements support for using A and B together. This should be possible in Rust.
Oh, 100%, I'd be happy with that too.
Is the orphan rule a result of some technical limitation? Or just the idea that it's "unclean" to implement someone elses traits for someone elses types?
1 reply →
Unity is so good and quite affordable, basically there’s zero upfront risk of using it. Similar for Unreal Engine. And then there are tons of other open-source engines like Godot that are also quite good.
Rust is great from lots of stuff but game development or building UIs isn’t among that (yet).
> Unity is so good and quite affordable, basically there’s zero upfront risk of using it.
Other than the absurd license changing shenanigans they tried to shove through recently. Hopefully they learned their lesson.
Unity learned that they have to turn the temperature up slower. They kept the new license that everyone was mad about but just made it so you can keep your current license if it's cheaper for you. No doubt they'll be tweaking these values over time.
2 replies →
To be fair, building UIs with iced-rs is getting better by the minute. My favorite showcase for using that library is this IRC client called halloy: https://github.com/squidowl/halloy
I wonder if Rust is just much better suited for making game engines than it is for making games.
The relative abundance of game engines made in Rust compared to actual games is a bit of a meme, but I think there's something to it. Maybe Rust's feature set is just not the best fit for gamedev, for reasons outlined in TFA. Maybe it means that game engines built in Rust (which I do feel Rust is well suited for) should try to integrate an interpreter for some higher level language, IDK.
Absolutely agree with the comments on ECS and Bevy in particular. I tried getting to grips with it for some time, doing things the Bevy way, and it just felt like a big step backwards because it’s not suitable for most things. The renderer was really slow at the time too, although I imagine that has improved. Switched to plain rust + vulkan (via ash) + dear imgui and haven’t looked back.
Some of those issues with Bevy might have more to do with its immaturity. It still needs at least a few years to be a solid choice for all sorts of games, in my opinion. I do think the hype should be toned down; people shouldn't feel pressured to worship Bevy or Rust or whatever is the hot new thing.
> Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that
I feel like this is the core of the author's frustration.
Rust is a systems language. It's for writing tight fast C-like code but safely and with a much more powerful type system.
The facilities you need to do this are somewhat at odds with what you want for rapid iteration.
Seems like Rust was the wrong tool for the job.
> Seems like Rust was the wrong tool for the job.
Sure, but the problem is when you have a community around that tool that insists otherwise.
Can you please give an example of that? Rust is very much advertised as a systems programming language. Can't really blame people for using it and going "oh it's harder than go and python"...
4 replies →
I would think a modern systems language such as Rust wouldn't require a systems development methodology from the 1970's. There's no inherent reason you shouldn't be able to rapidly prototype a system and then refactor the prototype into your actual implementation.
Exactly!
C/C++ -> move fast and break things
Rust -> move slowly and don't break anything
3 replies →
Yeah, I rather like the pattern of embedding a more rapid iteration scripting language on top for game stuff like Lua or stripped down Python variants, using Rust as the core and hot loop code. That said, there is a lot of folks wanting to do it all in Rust, and the article touches pretty well on that not being the pleasant case for a lot of valid gamedev approaches.
Lua is often used for this in gaming.
1 reply →
This article describes almost exactly why I think gradual typing is actually a good thing. Type checkers shouldn't get in the way of your code compiling. Yes, the language has to be designed with this property from the beginning. Yes, you should always enforce complete checking in CI. But you should also be able to try half-baked ideas.
There are at least a few nascent statically typed languages (as in, full static typing rather than gradual) which nevertheless let code with type errors compile for the sake of testing.
The two that I know of are Darklang [0] and Roc [1] which aim to let you compile code with type errors for the same reason you suggest.
[0] "Dark is designed for continuous delivery. As such, we don’t like requiring you to make large scale changes across your program, like changing a type everywhere. Instead, we want you to quickly discover that bad ideas won’t work, without first requiring you to propagate the type changes throughout your program."
https://blog.darklang.com/real-problems-with-functional-lang...
[1] "If you like, you can run a program that has compile-time errors like this. (If the program reaches the error at runtime, it will crash.)"
https://www.roc-lang.org/friendly
Let me introduce you to `-fdefer-type-errors` in GHC Haskell:
https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defe...
1 reply →
> Type checkers shouldn't get in the way of your code compiling.
I don't get it, what's the point of type checking if not to reject invalid programs? The point of a type system isn't simply to add annotations to a programmer (and some type systems can omit them entirely) but to define the subset of programs that are correct within the set of all the programs that can be expressed.
I understand (and have used in production) optionally/gradually typed languages, and without fail codebases will opt for using types up front and not ignoring type check failure because they are always incorrect.
A type error is the compiler/run time telling you "I don't understand what you told me" so why do you want to ignore that?
And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with. It should be easy to pull in what you need and play with it without affecting everything else if you haven't done a bad job of architecting the codebase.
Because often, and especially with heavily interactive programs like games or UIs (any web page), you don't know if something will be good or not until you build some working version of it. The more barriers there are (type checkers, compiler errors, etc), the longer it will take you to prototype something usable to check if what you're building is good.
Sometimes, it's useful to bypass these things for a prototype and you don't care if it crashes on any edge case. This is why typescript is so popular on the web - you can quickly prototype something with JS, then once you find the right solution, add types and productionize the code
7 replies →
>I don't get it, what's the point of type checking if not to reject invalid programs
It can take longer to think about how to properly type instead of just writing some code, testing it out, and immediately seeing if something is wrong. You also often get into a situation where linters who like to act like type-systems give you arcane errors (looking at you TypeScript).
In the moment I just want to move some data around and quickly try out an idea, I don't need it to be resilient or perfect.
>I don't get it, what's the point of type checking if not to reject invalid programs?
Because not every program that doesn't compile is necessarily invalid.
1 reply →
>And if the point is that you want to be able to change the type signature of something without having to refactor giant chunks of code, then that suggests your code is structured poorly to begin with.
The article addresses this, multiple times. In brief, the "poor structure" isn't the problem.
It's also pointless to care about types in fine-scoped code. Like if your language forces me to assert that i is an integer like this, something is wrong...
And when I'm writing backends, usually there will be no types anywhere except at the API layer, i.e. OpenAPI spec or protocol buffers. Not once have I encountered a bug related to accidental wrong types that wasn't caught at this outermost layer.
Great article, but on ECS I thought the primary point of using it was locality of memory so that you don't get cache misses during iteration of elements. Yes you are preferring composition over inheritance but I thought that was more of a side-benefit to the main thing ECS was trying to solve.
> being unable to just move on for now and solve my problem and fix it later
Same thing about Golang "unused variable" and "unused import". So many times I just exploring a lib and trying things out with no intention to leave it as is, but no, Go forces to "write good code".
I mean, I'm no fan of Golang (I actually kinda hate it), but this is easily solved with a blank identifier (underscore `_`) or by commenting the line. Both of which makes it blindingly obvious when doing code review.
Golang falls in the camp of enabling fast iteration while also enforcing some sane basics. Letting off an unused variable/import with a warning is a recipe for insanity, anyone who has opened a badly maintained Java codebase will tell you this.
I use Nim at work. It is a joy. I replaced a prototype Rust application which was confirmedly not a joy. None of Rust's highly opinionated safety semantics necessarily imply a better end product, and often make delivering an end product much more difficult. Rust has use cases, but it is a specialized hammer for a specific domain of nails. It is not the cure-all everyone wants it to be.
If you're asking if you should use Rust and you don't have a highly specific embedded use case, you should probably just use a language with decent RC or GC. As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all. Business logic, clean and bare.
> As an additional bonus, 99.9% of the code you write in a GC language never has to be about memory at all.
This is a bit of an oversimplification. If you are sloppy with "memory management" (unnecessary object lifetimes, unnecessary duplication, etc) even in a GC language, it is possible to have noticeable performance impacts. I'm not saying these languages aren't the right tool for the job, but it is not a free pass to ignore hardware limitations.
Yes, but that's only true for long-running applications. Most gigantic monolithic web server applications, for example, do not need to be gigantic monolithic web server applications.
My Nim CLI application does a subset of common tasks, outputs to stdout, and is invoked by our PHP server for each task. It (and the Rust and C programs it replaced) can barely blip a fraction of a percent amount of system memory in the worst case. Why did it need to be in C or Rust? It was never necessary, and I've been able to load it with features they never had but always wanted, in astoundingly short order.
Architecting these sorts of services properly can assist in making tool choices that drastically boost maintainability and feature delivery, especially for small teams; meanwhile, entire classes of problems melt away.
3 replies →
Oh we’re at that point of the hype cycle are we?
We've always been here. People just didn't listen.
894 comments here. similar in several posts on reddit. and only 1 review of his game on steam. shit's brutal.
I don't use Rust for game dev but I do for low level libraries and find it easier than C++ to get started. I have enjoyed it more than Java and like it for different reasons than Go, but it feels good to program in.
As for the design patterns that a complex game requires, if you are considering Rust for game dev and ecs design patterns it might be useful to check out projects that are Rust centric like https://spacetimedb.com/.
Clearly he needs a framework for making games in Rust instead of iterating through rust primitives.
> games are single threaded.
Huh. Not games like Cyberpunk 2077 and it's good that they are not.
I had this same pain point though when using Rust that was meant to run in the browser (compiles to WASM), i.e. guaranteed to be single-threaded. Still had to pay the very high price of accessing global state in Rust. Ended up moving that code to JS instead just to avoid that!
Did you read the part where they said that they're a two-person indie game studio with a development cycle of 3-12 months max?
That's not an argument against parallelism in game design in general.
4 replies →
As someone in a similar position (also ~3 years doing gamedev in Rust but only free time + open source), I feel very similarly.
There's low hanging fruit i've been complaining about for years where Rust is protecting us from ourselves - orphan rules, global state, ... Look, we're adults, we can make decisions with tredeoffs.
Compile times are a tougher one, I understand that Rust does analysis that is more complex than many langs and i feel ungrateful to people who spend their free time improving Rust. But also i don't think the complexity justifies all of it. Make dynamic linking easier, reduce how much needs to be recompiled, compile generics to dynamic dispatch in debug builds, etc. - there's gotta be a ton of stuff that can investigated.
ECS just plain sucks. People use it because what they want at first is some way to have relationships between entities. References/pointers are the obvious solution in most langs but in rust, they're obviously out. The second option is Vec and indices but that falls apart as soon as you start removing entities. The next step up the ladder of complexity should be generational arenas but for some reason people immediately reach for the big guns - ECS. And it infests their game with two things that make gamedev a slog - dynamic typing and boilerplate.
Boilerplate is obvious to anyone who has done gamedev the "obvious" way before. What could be projectile.shooter.score += 1 is multiple lines which (depending on your particular choice of ECS) usually involve generics. You shift your focus from tweaking your game logic and tuning the experience to typing out boiletplate.
Dynamic typing means entities are no longer structs with fields where you can understand how they relate to each other at a glance but instead any component can be anywhere, entities are no longer real, refactoring always causes silent bugs.
However, by far the biggest issue is the community's handling of criticism.
There are practically no experienced gamedevs coming to Rust from other langs so there's nobody to give Rustaceans a reality check. Rust gamedevs are almost always writing their first game (or, yes, engine). And there's nothing wrong with that, i was writing my first game at one point too. But their attitude is that they chose Rust because they heard it's the best and they got invested in the language because it's hard(er) to learn and now with all this investment if they hear rust or their particular favorite engine might not be that great, it feels like wasted effort so they get emotional and defensive.
I've personally chatted with over half a dozen other gamedevs who came to rust with years of experience under their belt and a common pattern is that they avoid the rust (gamedev) community because they're beat down by the negativity heaped upon them every time they try to discuss the negatives. It doesn't matter they take every effort to offer constructive criticism, it becomes a social instead of technical topic.
I came to Rust because i care about code correctness and, well, quality (of tooling, docs, testing). And Rust delivers there on a lot of that. But i also wanted to write games of a larger scale than can be done in one person. My hope was that there'd be other people with the same values who wanna build cool games together. Instead there's a low single digit number of serious open source projects and a bunch of small one man games and a a whole lot of loud people who seem to think gamedev is about hyping up an engine like it's a sports team.
Myself, I apparently chose the wrong engines for my games in both cases. Not because they're bad technically. In fact, having 5 years of gamedev experience before Rust, i think my choices are better from a technical perspective but there's just not the critical mass to build a serious open source game around them.
This article hits every note of frustration I've gotten with rust.
It honestly feels that if you want a somewhat memory safe language for more general purpose use cases good'ol fashion Ada or maybe ziggs (or if carbon ever become a thing) seem 100% more approachable than rust for gamedev or gui.
The only way I see rust becoming dominant in gamedev/ui is by sheer brute force.
I'm a Rust enthusiast and really surprised to discover so many people are apparently trying make games in pure Rust.
I think Rust is an amazing language for building a generic game engine, but a pretty crappy one for actually implementing a finished game.
Isn't it basically standard practice to have an engine written in a systems-level language with generality, reliability and performance as the top objectives, and the game itself written in a scripting/interpreted language that allows very quick iteration?
And it can even in many cases be a pretty horrendous home-brewed language. Despite having people without the computer-science knowledge to create a good language (and yes, inventing a new language is one of these things that leads to horrible results if you just learn on the job). This structure will still get you there easier and faster than trying to implement the whole game in a systems language.
I've always been fascinated by games and I've always loved programming but except for the beginning I've never combined the two. And the issue with game dev and functional languages not seeming to jive with each other always seemed (from the outside) to mostly be one of established norms conflicting with each other on both sides. I'd love to have time to explore this; for example one complaint the author makes is about passing around the game state but then also needing to pass around sub-parts of it and Rust complaining; this would be trivial or a non-problem in Elixir, but I know that's because there's no mutable state and in Rust's case it must deal with mutable state regions because all of game dev assumes that's available (or it must be by necessity for performance reasons).
I see some of those things could perhaps be solved by implementing parts of the game in a sandbox. I know that's work: I'm doing it myself. But all the work with the host-guest boundary (let's not call it bindings, please), is worth it in the end.
I have a C++ game client, a C++ game server, and a shared C++ game script that is transferred to all clients, running in a RISC-V emulator. That means the script will fundamentally execute the same way on all clients, and the server. I have no idea what everyone else is doing. This is what I'm doing now, and the more fleshed out it's becoming, the more I actually like it this way. I don't think I could easily "go back" to other solutions.
Rust being the best alternative to C++ is why I'm wildly rooting for Mojo. This language sacrifices a lot in ergonomics and UX to the alter of safety. And the Rust community never fails to interject with "Well, Akshually..." whenever you complain.
Rust is good for software following a strict spec and design doc. A lot of what I do is exploratory in nature. Rust sucks there, fighting me. Best kind of languages in those cases are Lisp, Python and (unironically) C with Visual Studio debugger.
I don't have nearly the same amount of experience with Rust (just a few months of hobby coding), but whenever people looked at me, all surprised, that I don't like Rust that much I always just said "Safety is not the most important thing for everything. For the stuff I am doing I'd rather be quick", but this article is the most thorough way of explaining that I have seen with lots of extra stuff I had no idea about before. Also the extra random gamedev links in the middle were great, but it took me well over a full, focused hour to read. It is thorough, but some more brevity might have helped, I think.
Like the author states, the "written in Rust" bonus many projects get does not apply to games. Most of the games I consider to be the most fun are built on an absolute rats nest dumpster fire of code (see: https://www.youtube.com/watch?v=k238XpMMn38). Sometimes bugs even expand game mechanics and make them more fun and expressive. That being said I'll definitely check out Unrelaxing Quacks, it looks great.
I'm amazed that we still willingly put heavy compute into compile steps
The trade off is always reload ability
We have CI, we have LSP places we can put heavy checks without sacrificing our ability to hot reload fast
In some checkers you can put in your own custom checks too
I tried to get Jonathan Blow engaged in the Rust RFC process to improve productivity for gamedevs. However, he thought it was a better idea to start working on his own language (Jai).
When I did some research for the Piston project, I learned that there was a productivity technique called "meta parsing" which was used in late 60s to develop the first modern computer. This was before C. The language was Tree-Meta. Viewpoint Research Institute upgraded it to OMeta.
I thought OMeta was too complex, so I developed Piston-Meta, an alternative for Rust using a simple data structure: Start node, end node, text, bool and f64.
My favorite thing about rust is when rust devs say that the slow compile things aren't a big deal and then show how that just by dropping a few dependencies you can get hello world down from 90 seconds to 30 seconds.
Thank you for this. I have been having some engine indecision. I am more of a programmer, so I was thinking that learning rust and bevy would be superior to learning godot, but it seemed like a really deep rabbit hole to go down, and I was concerned from the lack of actual games that were coming out of it.
Your blog post really explained the reason why quite clearly, thus eliminating a journey that would be fraught with difficulty and seemingly with little return.
I am going to go with godot and hopefully that works out for me. Thank you again for sharing your experience.
I am happy to be honest that I have not spent much time of rust, other than browsing sample code and reading about user experience, the borrow checker, etc.
For me, I could not see myself using rust especially for game development. Some of the points raised are my concerns, especially wanting to chuck something together (to improve later) only to fight the compiler, etc.
I would be interested to know what language they choose moving forward. It seems the contenders are likely to be:-
C - because, you can,
C++ - ditto,
D - I think it is largely ignored, and there is the betterC flag
Zig - Seems interesting,
Odin - Also interesting
Anyway... going to enjoy reading the comments, now.
This author is done more serious Rust code than I have, but I wonder: why not just abuse `clone`, `unwrap`, `Arc`, or even `transmute`?
Rust does try to force you to refactor sometimes, but you have the option to fight back.
It's possible to abuse 'transmute' but .clone(), .unwrap(), Arc<> are full-blown language features, so using them is not 'abuse' of any kind. They're part of how Rust supports quick iterative development, along with Any (for dynamic objects with downcast) and still others.
Interesting to me to have [iteration speed] <--> [maintainability] spelled out as opposite ends of a spectrum... and that sometimes [iteration speed] is the right thing to optimize for.
It's not news though? Favoring iteration speed at the cost of future maintainability is a common argument for dynamically typed languages.
Certainly--just having it spelled out like this was new to me?
Other languages allow much easier workarounds for immediate problems without necessarily sacrificing code quality.
I really wish the author had followed this with a list and an explanation.
All low-level languages (by which I mean languages that offer control over all/most memory allocation) inherently suffer from low abstraction, i.e. there are fewer implementations of a particular interface or, conversely, more changes to the implementation require changes to the interface itself or to its client [1]. This is why even though writing a program in many low-level languages can be not much more expensive than writing the program in a high-level language (one where memory management is entirely or largely automatic), costs accrue in maintenance.
Now, a language like Rust makes some aspects better because it ensures that the maintenance (refactoring) is done correctly -- reducing the risk of mistakes -- but it comes at a cost: you must explain your handling of memory (before and after the refactor) to the compiler (plus, the compiler doesn't understand all patterns). I think it's too soon to empirically compare this cost to the gain in reduced risk and determine when each option is more or less advantageous (and perhaps it is also a matter of personal programmer preference), the fact remains that maintenance of programs in all low-level languages is always more costly than maintenance of programs written in high-level languages because of the low abstraction inherent to all low-level languages.
When writing in a low-level language some may prefer the Rust approach while others may prefer less restrictive ones [2], but people choosing any low-level language should be aware of the added maintenance cost they're invariably signing up for. Sadly, this cost only becomes apparent at later stages of the project.
[1]: Some people claim that memory is just like any other resource (e.g. file descriptors), but this is incorrect. Memory and processing are fundamental to the very nature of abstract algorithms, and differences in how memory is handled change the available range of algorithms. E.g. finite state machines, queue automata, and Turing machines differ only in how memory is handled and accessed. In short -- memory and processing are special resources and are not the same as IO resources.
[2]: I'm personally not a big fan of Rust's approach -- and I particularly dislike C++'s and Rust's "zero-cost abstraction", which is the attempt to make the low abstraction ability invisible in the final code without changing its fundamental aspects -- but I recognise that people's opinions differ on this matter. I also reject the claim that there's no middle ground between Rust and C that offers an intermediate tradeoff between them, i.e. that there is no safety premium to a language that offers some of Rust's safety guarantees but not all of them, such as Zig, or offers better and effective assurance of some properties without a sound guarantee.
They should open source their game engine. That way we can learn from their mistakes. How can we be sure this is a shortcoming of the language and not the APIs the author is working with?
Anyway - no one is going to ship a game written in Rust with this attitude. To the other folks out there happily writing their games in Rust - don't be distracted! All it takes is one success story to prove the concept :)
OP should give D a try, my game fully recompile in less than 1sec, and i can consume most of the C gamedev ecosystem without effort and seamlessly
This is a fantastic article.
Personally, I found using Godot with some parts in Rust via gdext quite enjoyable.
You can avoid dealing with GDScript for important parts of the code and have access to OS threads if you want them, etc. - but can also prototype features in GDScript and write the UI, etc. there for fast testing, and keep a good separation of UI and graphics presentation vs. the actual game logic.
Is rust becoming like react where there was a ton of hype around it and then years later it's falling by the wayside?
The thing that the Rust community thinks sets them apart (their community), is really the thing holding them back.
I don't think it holds them back. Rust is just not an amazing special tool for game dev it seems, doesn't matter how the community behaves. It's still a solid choice for systems.
Reading the part about global state reminds me of some of my thoughts building backend web apps. Not having global namespace pollution is fine, but not having any global registry of some sort can make things far harder for the size that most things are going to be.
I've been leaning into Rust almost purely to escape from the mess that is C/C++ tooling which always makes considering a new dependency a time sink.
Can someone explain the obsession with combining ECS with generational arenas?
Seems like a few contradictory ideas here.
Rust is supposed to be a better safer C/C++.
Then lot of comments here that games are best done in C++.
So why can't Rust be used for games?
What is really missing beyond an improved ecosystem of tools. All also built on Rust.
This is not a matter of tools though, did you read the article? The main pain point is that Rust semantically makes fast iteration impossible
Did I read the article? You?.
But the conversation in the thread is making point that Rust does lack tooling, libraries, that would make lacking fast iteration a valid trade off.
And a common theme is that C++ is better, and last I checked it is also not great at fast iteration.
That logo is huge on mobile so I can't read the first few bullet points.
Author here, sorry about that, I just deployed a fix, should be readable now. If it's not, here's the first few points
- Once you get good at Rust all of these problems will go away - Rust being great at big refactorings solves a largely self-inflicted issues with the borrow checker - Indirection only solves some problems, and always at the cost of dev ergonomics - ECS solves the wrong kind problem - Generalized systems don't lead to fun gameplay - Making a fun & interesting games is about rapid prototyping and iteration, Rust's values are everything but that - Procedural macros are not even "we have reflection at home" - ...
the list corresponds to the titles of sections in the article.
Can you not curate an opinionated subset of C that enforces all of Rust's rules so that you can have a safe variant of C, just by removing flexibility and enforcing some programming patterns?
Rust is a terrible language for everything except a few niche tools.
I also had the same bad experience with Rust outside of Gamedev. Probably a lot of other people too, but people don't talk about it much, because the Rust community is the most religious programming language community I've ever seen in my life. Before Rust, the Scala community was also pretty bizarre (Java too for a while), but nothing was on Rust's level. The worst part about Rust isn't technical, it's the crazy community. You can see in the article that the author tries to explain everything at every point, trying to escape the problem "If you don't understand something in Rust, you're holding Rust wrong."
Of course, there are many people in the Rust community who are not religious and try to improve the language, but my general feeling after reading a lot about Rust is to stay very far from the church of Rust.
The best response to this type of community is humor, like this video about a Rust Senior developer https://www.youtube.com/watch?v=TGfQu0bQTKc
I mean, your comment is actually contributing to the problem. You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that.
It's fanning the flames and just doesn't really help.
> You can 100% criticize the community - and thus push them to clean up that shit - without straying into characterizing it like that
Like what? To criticize a community, you have to characterize it. And of course they didn't say everyone was like this.
> Of course, there are many people in the Rust community who are not religious and try to improve the language
1 reply →
I've been writing Rust professionally (and predominantly) for ~5+ years now, with brief detours in game dev. I'll defer to others who are dedicated game devs, but overall I think this article is well written and a healthy thing for Rust overall. We need this kind of breakdown if things are going to continue to improve.
I'd say I only have two somewhat arbitrary comments on this piece:
> Rust on the other hand often feels like when you talk to a teenager about their preference about anything. What comes out are often very strong opinions and not a lot of nuance.
This is a rabbit hole of a topic so I don't want to go too deep into it, but this isn't a Rust-specific issue (though it may be a current Rust issue). I've seen this same pattern play out across so many languages over the years, from Lisp to Rust to everything in between.
A very unscientific and definitely not charitable way I've thought about this over the years is that programming, by nature, is an OCD person's dream. We wind up with a pretty large chunk of people who seemingly move language to language in the hype cycles in search of some weird nirvana level that is likely just unobtainable. I feel like Rust has slowly started shedding this as the community has grown/matured and some people have moved on to the next hype cycle but I often find myself wishing it'd happen faster.
I write Rust because when I sleep at night, I just don't get woken up by being paged for nearly as many weird edge cases. The Rust I write often has a litany of compromises because I want to just get shit done and move on with my life, and the remaining guarantees are still good enough. The number of times I've had to tell people to leave it be is definitely higher than it should be.
> I know that just by saying "global state" I'm immediately triggering many people who have strong opinions on this being wrong. I feel this is one of those things where the Rust community has created a really harmful and unpractical rules to put on projects/people.
This isn't really a Rust-specific thing, though I can't fault the author for including it. People have been beating the drum of "no globals" for as long as I can remember... and simultaneously, as long as I can remember, game devs have come out of the woodwork to politely explain that the programming they do is often under very different constraints.
I still periodically use global state for things because it's just faster at points, and no, I've never cared if people get annoyed by it.
Anyway, here's to hoping this leads to positives for the community.
Wonder if Mojo will become a good option as it matures
> Secondly, procedural macros are incredibly difficult to write, and most people end up using very heavy helper crates
lisp lisp lisp lisp lisp lisp lisp lisp
That's Rust for you - as much language-level derangement as people hated about 90s Java, but without the memory safety benefits of Java.
Very interesting article but I feel the need to question some things.
- The very first thing that comes to mind is why actually use Rust for gamedev. From the article it seems like the author got into Rust through Godot, but that does not explain why commit to use Rust for a full game. What was the reasoning behind picking Rust?
- It feels to me that there's a mix of criticism to Rust as a language, Rust as a community and libraries/frameworks written in Rust (in particular Bevy). Personally I think these are completely separated matters so I would like to know why the author treats them all as a unit.
- I've always got the impression that gamedevs try to have their cake and eat it too which is almost always impossible: they want to have quick iterations and write "simple code" while having low level control of everything (ex. manual memory management, usage of pointers, etc.). For example, the author mentions wanting access to methods like "play_sound()" but at the same time mentions that some patterns are unacceptable given the "overhead [...] due to memory locality". I've never heard of an ecosystem where you can have everything without any compromises.
- In particular, I get the impression that the author has a lot of troubles with ECS and instead it tries to bend it to work in a OOP fashion (for example, through the usage of "fat components" as he calls them or preferring virtual dispatch over `match` statements). He claims that he has put in a "lot of time" in trying to make it work but I get the impression that this effort was mostly wasted in trying to bend the language and libraries into something that just won't work out. It's like trying to use a circular saw to polish mechanical watch pieces: an exercise in frustration. At some point in time I'm sure he asked himself why to keep on pushing on, and I would like to know why he continued to be committed to such process.
- The author claims multiple times that they work in a single threaded environment where they should not care about concurrent access so they should not pay the price in the type system. I agree that this should be the case but then it proceeds to list examples that show a different situation. One of them is the claim that they cannot use a "god" context to pass down every dependency due to the borrow checker, listing code that tries to hold a reference to a "camera" system while passing the context to the "player" system. In particular this does not make sense because: 1) If you're in a single threaded environment you don't have two systems using the same context at the same time (because there is no "at the same time"); 2) if the "player" system does not need the camera then it won't change it, and if it does not change it then there is no need to take a reference to it earlier, you can just take it after the "player" system has finished. I know that coming up with brief examples is extremely difficult but either the example does not properly represent the reality, or the author is actually working in a multi threaded environment (maybe without actually knowing about it).
As an observation, the author mentions multiple times that Rust pushes you to write "good code" and I fundamentally disagree. "Good code" is very contextual, just like the idea of "simple code" where he checks for all collisions and plays a sound in 3 lines (is this actually "simple"?), so instead I would say that Rust forces you to write "correct code", that is, code that won't (or is unlikely to) fail at runtime. I believe this is a very important distinction that you always need to keep in mind when evaluating a tool such as a programming language.
Finally, I do believe though that Rust is a bad choice if what you're interested in is to build games quickly without consideration for performance (and you most likely don't need to care in 2d games) and their decision is very reasonable: C# and Unity are just aligned better with what the author is actually interested in doing.
I’ve only done a few toy projects using ECS, but the author seems to be struggling with ECS on a basic conceptual level. E.g.,
---quote---
For example, modelling Health as a general purpose mechanism might be useful in a simple simulation, but in every game I end up wanting very different logic for player health and enemy health. I also often end up wanting different logic for different types of non-player entities, e.g. wall health and mob health. If anything I've found that trying to generalize this as "one health" leads to unclear code full of if player { ... } else if wall { ... } inside my health system, instead of having those just be part of the big fat player or wall systems.
---end quote---
The solution here is to have a Health component but not a generic Health system (actually, a generic Health system sounds like a code smell for another reason, because systems map to actions, while components map to attributes; systems that interact with a Health component would be things like a damage or healing system) -- but if you need something to work different for player health and wall health and enemy health, you can just have three systems, which, respectively, do Query<Player, Health>, Query<Enemy, Health>, Query<Wall, Health>.
Excellent article. Rust is my favorite language for several uses, but I'm becoming less optimistic about it as a versatile language long-term. An important point regarding the article is that it mixes rust shortfalls, and shortfalls of any language other than C++ for games. I've personally used Bevy for a 3D wave function renderer, but moved away from it in favor of a custom WGPU-engine due to Bevy's complicated ECS DSL.
I am worried because:
This is disappointing to me, because IMO the syntax, tooling, and general language experience of Rust is far better than C and C++.
Why is async such a dealbreaker for this guy? Especially for web dev.
I think the async Rust shortcomings are largely solvable, but I sympathize with everyone running into the numerous problems right now.
What's bad about it? Last time I used Rust was before that feature existed.
1 reply →
This is a fantastic article. Thorough, nuanced, well-articulated, and rooted in lots of real experience
> Orphan rule should be optional
That has got to be the most "I didn't think this through" take ever.
While it's a known pain in the ass. Not having it is a bigger pain.
The moment you allow this, you have to find a way to pick between several implementation - and they don't always have sane names.
Orphan rules prevent this from happening.
Someone who has experienced real problems as a result of a specific mechanism is not required to solve every single problem with alternatives to that mechanism before saying "this mechanism has caused me real problems and it'd be nice if there were a better alternative that didn't cause those problems".
> The moment you allow this, you have to find a way to pick between several implementation - and they don't always have sane names.
There are other possible solutions that don't involve that.
For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.
A slightly more sophisticated rule would be "Identical implementations are allowed and treated as a single implementation". This would be really convenient in combination with some kind of "standalone deriving" mechanism, which would generate identical implementations wherever it was used.
Disclaimer: I'm aware you guys are working on relaxing orphan rules, and I wish you the best of luck. But as an outsider, orphan rule doesn't seem to be going anywhere soon.
And if the original poster had said that I would be ok. Instead what they said is:
> It's a great example of something I'd call "muh safety", desire for perfection and complete avoidance of all problems at all costs, even if it means significantly worse developer ergonomics.
This implies the writer didn't assume what happens if you "turn-off" orphan rules. I.e. you don't trade perfection for developer ergonomics, you trade one set of developer (ability to write any trait for any type) ergonomics for another (having to battle two incompatible trait implementations from crates you don't own).
Either you have to manually specify how nearly every implementation is pulled (horrible developer ergonomics) or, even worse, you go into monkey patching territory.
> For instance, many applications would be quite happy with "There can be only one implementation", giving a compiler error if there's more than one.
Ok. But you still need a resolution mechanism to fix the error. Which implies manually solving ambiguity. And how do you solve it for blanket implementations?
6 replies →
C minus minus is needed to strip away as much as possible from C++
Yup. Rust is too complicated. You don't think about getting the job done, you think about language specific crap that is just overhead. And it's ugly to look at.
I tried to like it, but I can't. It doesn't align with my way of thinking.
I've been thinking of embarking on a Rust/GUI/Game. Guess, this will save some grief. Is Rust the future? Will this situation improve? I've been wanting to like Rust, but this seems to be indictment.
It’s unlikely to improve anytime soon, and there are no indications that Rust will be the future of game programming.
> Is Rust the future? Will this situation improve?
I don't follow this too closely, but I have not seen any indications that any of the frustrations expressed in the article are on a Rust roadmap.
IOW, just about everything in that article is a `WONTFIX` or `NOTABUG` for the Rust maintainers.
Really well written, and well explained without any bait
Jesus, now that's what I call comprehensive.
On the "hot reloading" remark: I believe that, to some extent, compiled languages that lean into metaprogramming are innately at odds with the concept of hot reloading. You're spitting out a (mostly) monolithic binary - rewriting that on the fly just isn't going to be reliable beyond an extremely basic level, and shoving it all into some kind of VM for the purposes of hot reloading introduces variance and general performance overhead that both mean that the "hot reload" environment is no longer an accurate depiction of the real application's behavior.
the hype is starting to come down
You might not need memory safety.
You do need memory safety for multiplayer games, though. Either that or you should use a GC language, which frankly is good enough for most indie games.
&str vs String. Oh boy.
https://raw.githubusercontent.com/lesterli/blockchain/master...
This is missing a few useful ones, like Box<str>, Arc<str>, Cow<'a, str>, SmallVec<u8>, transmuted newtype references like &UserId, and of course the string type you implemented yourself because the previous ones were not good enough.
Yeah, if std::string vs std::string_view is "a major hurdle"... I don't know what so say
Where did you see "a major hurdle" written?
You are doing exactly what is being criticized in the Rust community. Bad faith reads of someone who spent significant time getting into the language.
I think there's a certain type of mind that can truly appreciate Rust as a language and enjoy developing with it. When I see quotes like,
> I wasn't thinking "what's the right way to get a random generator in here" or "can I assume this being single threaded" or "am I in a nested query and what if my archetypes overlap", and I also didn't get a compiler error afterwards, and I also didn't get a runtime borrow checker crash. I used a dumb language in a dumb engine and just thought about the game the whole time I was writing the code.
and,
> The prevalence of perfectionism and obsession with "the correct way" in the Rust ecosystem often makes me feel that the language attracts people who are newer to programming, and are easily impressionable.
I see someone who simply does not think about those kinds of things when writing code. And that's completely, entirely fair. Rust is not for them, then.
But they seem to act like it's an issue with the language that it does not serve them specifically, and their way of thinking in particular, not even pertaining to game development.
Because the thing is, I don't suffer from the issue they're describing. I don't find it difficult or distracting to think of edge cases and implementation details when I am writing out a solution. In fact, I can't help it. I love Rust, because its strong typing and strict static analysis actually support and justify my way of thinking. They're not obstacles for me to overcome, certainly not like how it's described here.
When I use a language like JavaScript, people tell me that I care too much about details or that I don't need static type information because I can just assume. JavaScript is not for me, because it doesn't support my way of thinking. It is terrible and sloppy and completely unchecked. It's absolutely great for banging things out without giving a care in the world about a single implementation detail that isn't relevant to the actual problem at hand. It's terrible if you actually do care about those implementation details, because nobody else who writes JavaScript does. Everything you interact with is going to be just as shoddy as the language itself.
(I have a job writing JavaScript, so this doesn't mean that I can't use the language. It just means I do not like it. I do like TypeScript.)
So this might just be a fit issue. I haven't read the rest of the article yet, because this stuck out to me. I see some other HN comments talking about async code and GUI libraries, and those are all completely valid concerns, but in the article these valid shortcomings are seemingly mixed with what I'm going to call "neurotype issues". In other words, I suppose the author just isn't autistic enough. It has nothing to do with being new to programming or not.
And that's fine. It's just not an issue with the language that it doesn't serve you as well as it serves others. After all, Haskell is the same way. I'd say most programming languages are the same way.
Honestly I have not read all the article. What language they are going to use instead of Rust?
C# with Unity.
The TLDR I got from that: Normal coding has two concerns:
1. What behavior do I want?
2. How am I implementing that behavior?
Experimenting with #1 is slowed down by the current end point of #2. Sometimes not at all, sometimes a lot, depending on luck and how #2 anticipated the class of experiment I am trying.
Rust adds:
3. How can the implementation code be organized so its stringent safety checks are validated?
Now experimenting with #1 is complicated by two dimensions of design history instead of one. And the latter dimension being two steps of abstraction/design-dependency away from concern #1, is going to be very brittle.
Never used Rust, but that sounds painful.
Well, I needed something to do while I wait for the next Vampire Survivors addon. Purchased the full bundle. Good luck, game devs.
I forgot, when you say anything remotely negative about Rust or Ruby on HN, the idiots get butthurt
> The problem you're having is only a problem because you haven't tried hard enough.
You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.
> That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
Not only this, but they openly mock other language communities for not drinking the koolaid.
I like Rust, and the Rust community, and fasterthanlime, for what it's worth. But I think these points raised in the article are very much valid.
Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Some of these communities/forums are just inhabited by people who thrive on dunking on noobs all day long. The good news is that they tend to get bored and move on when the next new thing comes out.
I'm already seeing this in my local Rust community as the chronically online people are moving on to Zig now. They even use one of the Rust discords to advertise their Zig meetups and proselytize about Zig at every opportunity. Eventually they'll get bored and move on.
> > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense".
I don't fully agree with this assessment. In my experience, Rust community members who arrive with well thought out complaints or suggestions are welcomed by the people who like working on programming language fundamentals. You can nerd snipe a lot of Rust enthusiasts by showing up with a difficult problem involving tricky parts of Rust, which will often result in some creative solutions and discussions.
On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language. I've spent a lot of time trying to get people to unlearn habits from other languages and try to adopt the Rust way of doing things. Some people refuse to let go of paradigms once they've used them for years, so doing things the Rust way isn't going to work for them. I've worked with enough people who spent more time fighting against Rust than trying to adopt Rust ways of doing things that I've also reached the point where I don't engage once I see the conversation going that way. Can't please everyone.
"On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language."
This is perfectly understandable if you view languages as tools. If the new tool can't do something the old one did, then you'll have questions about using it. A great example is inheritance - if inheritance is missing, that's a negative for me. I don't care about the philosophy, I just want to use the tool to produce programs better and faster. If it's missing features, that's a negative point.
> What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too.
Go was released in 2012, Rust in 2015. Are you saying we are still in the early days of Rust?
7 replies →
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
Yeah. I think there’s also a weird way that newcomers get treated when they join a community. When you’re a newcomer to Rust, you probably have some preconceptions about how Rust should work based on the other languages you know, and you’re probably running into a lot of the same problems with Rust that everyone else has (e.g. borrow checker).
Most of the community is just kinda tired of the discussion and tired of answering the same questions, so they don’t interact with the noobs at all. That means that the people who, as you say, “thrive on dunking on noobs all day long”, are the primary point of contact for noobs.
Finding a decent programming community these days is a pain in the ass. The cool people, i.e., the people working on cool projects and getting shit done, are mostly busy and not hanging out with anybody.
> Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase.
I would say that in general, this type of attitude permeates a lot of software engineering, and even engineering and science as a whole. When I speak with people in other fields, particularly more creative ones, the discussions are so much more improvisational and flowing. Discussions with software developers, engineers, and scientists have this very jerky, start and stop "flow" to them as you meet resistance at each step. I honest to god have had people telling me no or shaking their head no before I ever finished my question or statement, much less before they even understood it.
> There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively.
You're spot on about the coupling of someone's identity with it. Rust especially seems to also have this never-ending gold rush to be the next framework and library everyone uses, which creates a very competitive landscape. And it seems most frameworks and libraries get 80% of the way and then fizzle out once people realize Rust isn't a magical language that solves all your problems.
3 replies →
unrelated: the word "toxic" is meaningless nowadays e.g., "dunking on noobs" is more specific.
Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in.
For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it.
But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the imagination.
If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language?
I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at that, or just inconvenient as the article points out.
That means, it should be used for general stuff, and for programming games should be used a niche language, like Lua, Python etc. Especially for fast iteration and experimentation, break things and move lightning fast, typed languages are in disadvantage for sure, compared to untyped/weakly typed.
1 reply →
>> The problem you're having is only a problem because you haven't tried hard enough.
And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say
is really pretty powerful, and being able to search for functions by type signature is just plain convenient.
But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.
> being able to search for functions by type signature is just plain convenient.
It's certainly not all the way there, but now that we are over the mostly empty promises of encapsulation and (worse) trying to model the world with classes, but grouping by that implicit first argument type for discoverability is exactly what OOP is, in this age of post-OOP.
The "you're not trying hard enough" position reminds me a lot of the Scala community's disdain for java-in-scala-syntax: if you don't use it like an almost-Haskell you're on your own (1). Here, I think Rust is actually more open: I don't read too much of the community, but most of what I saw seemed to be quite welcoming to the idea of placating the borrow checker with refcounting when "the rust way" fails to sufficiently click.
((1) but with Kotlin having taken over the entire not-almost-Haskell part of scala it's not an issue anymore: is has its niche and it fills it well, no more taking over the entire JVM while also magically converting everybody into an almost-Haskellian)
Maybe https://dev.epicgames.com/documentation/en-us/uefn/verse-lan... is as close as we're going to get to game dev Haskell.
Agree. Some languages like Haskell have a steep learning curve, until you grok it. Then you have a big productivity gain.
But this article is seeming about someone that has put in the time, has written a lot of Rust, and now says, it wasn't really worth it.
What does this after do with the topic?
1 reply →
this reminds me of Lispen of ye olde.. wait untill it clicks, man!
He mentions Common Lisp as something he did a game in, and you can see the link he praises https://www.youtube.com/watch?v=72y2EC5fkcE as basically a very well-developed Lisp image approach with timetravel debugging etc aimed at game dev. So the implicit comparison to Lisps is sort of a big undercurrent to this whole article.
1 reply →
Lisp is pretty normal if you're accustomed to, like, Python: It's a GC'd procedural language.
12 replies →
Yeah, this hits hard. Despite being proficient in a bunch of languages in college, I could just never wrap my poor brain around Lisp.
That’s sort of different, right? Rust is just another systems language. Lisp is the language that nobody knows but everybody secretly believes is better than their language of choice.
This was my biggest problem with rust, the community is, at a surface level friendly, but the moment you try to say something against the grain you get met with some of the most insufferable people ever. I tried to mention a problem with a lint on the official forms and the replies were so condescending (from regulars at that too). And at no point did they try to understand the issue, they just assumed I was dumb/new/doing something wrong.
The attitude is perhaps not surprising from a community whose unofficial tagline is "Rewrite it in Rust".
Sounds like a no-true-Scottsman fallacy
[dead]
>> The problem you're having is only a problem because you haven't tried hard enough.
>You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more.
I'm reminded of a line from Hachiman in Oregairu: "Something is only a problem when someone makes it a problem."
> I'd argue as far as maintainability being the wrong value for indie games, as what we should strive for is iteration speed.
That seems to be the crucial point. Rust is optimized for writing complex systems software in large teams. That’s not a great fit for a small team hacking on something that is at least in part an art project. You wouldn’t choose something like Ada for that either.
I've ended up with similar thoughts about automated testing in games too.
I really enjoy having automated tests and automated tests solve problems. Like, I absolutely love our molecule test suite for our infrastructure code and it gives us huge value. The smoke tests we have for the infrastructure running after deployments are amazing. It's liberating in an environment of rapid and chaotic changes everywhere, complex interdependencies, as well as pressure on top.
However, if I try to transfer that kinda approach to a game it just... fails?
But the realization is: In games, many behaviors and systems are actually far simpler and less intertwined in arcane ways, and code changes actually less frequently and dramatically than at work.
I could see structured testing in e.g. turn based strategy games and such, so you can test that the culture per turn is correctly calculated based off of many different situations and such.
But in many smaller projects I've had, you write some janky code, make sure the enemy behaves as expected... and never touch or change that piece of code ever again. And it just doesn't break, because no fundamental part below it ever changes, because then the entire house of card would fall apart.
It feels dang weird, but it works very well for smaller projects.
I copied this exact same snippet and was going to comment the exact same thing.
Why choose Rust if you don’t care about maintainability and long term stability? Those are core values of the language!
The language choice was wrong from the start. C++ is king for games so if you care more about delivering features and fast prototyping why not go with that?
Maybe Rust is not a good language for rapid iteration in the game industry. And that’s ok I think.
C++ is king for game engines, but many games opt for languages like Lua or Unreal Blueprints because C++ is to those as Rust is to C++
Personally I like Javascript
1 reply →
Rust is not antithetical to iteration-based programming, it just makes you write a lot of heavy boilerplate to explicitly support that kind of style. The flip side of that is once the 'iteration'/'prototyping' phase is over, you can actually refactor the prototype into high-quality production code, instead of either throwing it away altogether and rewriting it from scratch (spoiler alert: this doesn't really happen most of the time, because it's viewed as pointless waste) or just putting it in production as-is (which is what people actually do, even though it's obviously a disaster in the longer run).
No, Rust is pretty antithetical to iteration-based programming. The language basically requires you to plan for the ownership model from the beginning, and it can be quite difficult to retrofit a changed ownership model into an existing program.
I've run into this in a side project I'm working on, where my indecision over which ownership models are actually workable in the API to satisfy the needs I have means almost all of the coding is spent just proving I can get an ownership model working over having a skeleton code that can do something. And still, even as lacking as functionality as this codebase is, swapping to a new ownership model takes several minutes of coding. Trying to do this kind of exploration on a codebase that has real functionality would mean spending hours of change just to move some property from here to there.
1 reply →
Surely there's better choices if the primary desire is iteration speed, and a secondary or maybe even tertiary desire is maintainability/refactorability
Rust gets in the way a lot, as it's supposed to for safety. Maybe it'd be a lot faster to iterate on if some AI could auto fix your code to make the compiler happy.
[dead]
tl;dr -- Rust is not the language for startups who want fast iterations and are still finding it's pmf. It is perfect for rewrites of popular system software which already has millions of users and running in production because once a software becomes mature and at million user scale, safety and security becomes paramount
> for rewrites of popular system software which already has millions of users and running in production
Hopefully, it's perfect for more than that.
Rewriting a system that's already acheived that scale is a contentious decision, to say the least. Many of our colleagues have been lost to and scarred by well-meaning attempts to rewrite those systems in the past, including many who were sure it was the right choice for "safety and security" themselves. For every conceptual safeguard new tooling might give you, you invite countless and sometimes catastrophic regressions in actual application logic in writing new implementations. It can work out, but no tool can expect to live only on that kind of work.
I'm sure Rust has much broader applicability than that. Or I hope so at least.
At million user scale, feature parity and compatibility is truly paramount and, `rg` aside, Rust utils don't have a great story to tell there. Such software has evolved in the course of decades and its (usually despair-inducing) code is tailored for dealing with a tremendous number of edge cases, platforms and architectures. Rewrites in Rust tend to write "the cool parts" and indeed write them better and faster, but that is just not good enough for replacing the standard tools.
Rust is the "frontend wave" of the backends. All the woke kids gravitate towards it. A suffix of "Written in Rust" is a thing here so I'm throwing away my internet points now.
I think most people here understand that a language that is great for kernel development isn't necessarily great for everything else.
I work fulltime in Rust (embedded stuff) but actually think the "everything else" influence into Rust is stronger than the systems stuff, and it's harming the ecosystem.
Just try finding e.g. an MQTT or WebSocket or etc library that doesn't drag the whole mammoth tokio ecosystem (which is really geared for Web Scale! projects) in with it.
Rust is becoming the language that tokio ate, and Cargo/Crates.io the new NPM.
That is, Rust is the systems language that a wave of non-systems developers insist on using, leaving behind a trail of non-systems-appropriate crates and projects.
Parent commenter's comment was crap by HN's commenting standards... but the underlying point about trendiness I think is in fact accurate.
3 replies →
It can be though. You should be able to express low-level details but also implement high-level constructs effortlessly should you so choose.
Look at C++, which can both dick with move semantics but also offer multiple inheritance. Even better, look at C#, which has pointer fiddling but also offers the best reflection of any language today.
You're right that Rust is only really good for kernel development but it didn't have to be that way.
Oh the language is good, it's the people. Cult-like.
2 replies →
... complains about people using tropes and tired cliches in posts while using the worst of them, themself
I do not complain. I've seen this trend multiple times by now. First time was with Ruby on Rails I think [1], then the cancer that led us to write JS to output HTML and all the good stuff that came and still manages to pour from npm. Every now and then you can spot the "fashion" out of these things.
Rust is good and has earned its place. I just despise cult-like followings for these languages and technologies.
[1] https://www.youtube.com/watch?v=YZeZsZEEpno&themeRefresh=1
5 replies →
[flagged]
Now they need to try blockchain :)
hah Rust didn't get gamedev (success at all costs) and it's a disaster
Zig zig zig zig zig :D
Congrats on the game launch. Funny way to promote it. Good luck, hope you get some sales!
This is a decent article, but although the points themselves are valid, I think there's a core "issue" with (indie) gamedev itself.
The vibe that I'm getting is that it's filled with people that don't particularly care about programming, they just want to get stuff done(TM), this is also highlighted by the fact that they are willing to write completely inadequate code just to see things working. Rust is not that, and that's a good thing.
More generally, I'd say that in gamedev anything goes, as long as it's fun and isn't too buggy. Rust is not, and never will be able to accomodate that mindset, which again, is a good thing if you think for 2 seconds and consider what Rust is actually aimed at, which is safe systems programming.
You can have the core engine written in Rust and have a scriptable language on top of it, there aren't any major pain points in this regard. The scriptable language will be able to provide all of this hot-reloading-anything-goes-yes-sir bullshit that we all know and love.
tl;dr: Use the right tool for the job. A language designed for safe systems programming can't do non-safe non-systems programming very well. Who knew!
Virtually all of the points outlined in the article stem from the above.
It's a weird concept to "care about programming". Same as "inadequate code". I find this statement really condescending and completely confirms some of the cliché quotes that the author write in this article
By "care about programming" I basically mean writing maintainable code.
By "inadequate code" I mean code that does what the author wants at this point in time, but is completely unmaintainable and just bad. Sloppy practices, etc
4 replies →
It's said that software is never finished, only abandoned, but games actually do get finished. And at that point any maintainability is absolutely irrelevant. It's just very different to web programming.
Some software (other than games) can actually be fully finished, provided that it's scope is narrow enough.
It's really a question of differentiating between "finished" and "abandoned". Finished usually means that no new features are added, the only changes are bugfixes or minor improvements. Abandoned means no changes at all.
> And at that point any maintainability is absolutely irrelevant
This goes in line with my point though. The fact that Rust encourages writing maintainable code makes it unsuitable for gamedev, where speed of development and flexibility (even where it's bad) trumps everything else. That's why you need to have a scriptable layer on top of the core engine anyway.
Rust... what is it good for? "Systems programming" ...
Rust is not good for raw performance. Neither for prototyping and iteration.
Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades.
Anyone really unhappy with Linux/BSD/Windows/macOS performance?
What systems are we talking about that benefits from Rust? Advanced weapon systems that should absolutely not fail? Controllers for air planes? Traffic controllers? Radar? Power grid?
Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.
Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything. This is silly.
"Syzbot and the Tale of a Thousand Kernel Bugs" [1] is my favorite talk on this subject. The Linux kernel is adding security bugs faster than they can be fixed. This is an unsustainable situation--it is not "good enough"--and nobody really has any ideas to significantly improve things beyond adoption of memory safety.
[1]: https://www.youtube.com/watch?v=qrBVXxZDVQY
> Ok, we're going from a bunch of complaints about Rust being bad for fast prototypes for indie development to the idea that Rust is bad at everything.
No, not at all, that's not what I meant. I think it's forte for now is better security at the cost of some performance and productivity (iteration speed).
> Anyone really unhappy with Linux/BSD/Windows/macOS performance?
I wasn't unhappy with Windows' performance in the 90s until I saw BeOS. This is the kind of thing we're in the dark about what could be because the faster, rewritten fron scratch, free from API baggage systems are nowhere to be found.
Haven't used BeOS, but to clarify, I do have issues with Windows and performance, especially general input latency and responsiveness when compared to Linux, as I use both daily. But overall I think it's decent, and at the very least, not the fault of the language used, but more about legacy issues and technical debt. Anyone having worked with winapi and mfc knows the codebase is a mess.
Well, as far as I can tell, in the big language shootout (which is still the only decent language benchmark I know, but if you have others, I'd be happy to read them), in all the individual benchmarks I've looked at Rust is either first or within 3% performance of being first. So, this suggests that Rust is actually pretty good for raw performance.
In addition, I know that I'm way more productive for prototyping and iteration in Rust than in C, C++ (and I used to write C++ code professionally for a while), JavaScript, Go, Python (and I've been writing professionally in these three languages for a while now) etc. I _might_ be more productive in Java or OCaml. Yes, this is entirely anecdotal and it depends heavily on the kind of problems you're dealing with. I tend to focus on problems that have complicated invariants, and for which reproducing/pinpointing the issue in a debugger is a big annoyance.
> Google, fb, amazon, etc. use C/C++ to squeeze the most performance out of anything I/O heavy, and security is not an issue that deep in the stack, that's not the exploitation layer.
Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.
> Interestingly, all these companies are migrating some of their systems to Rust. This suggests that they find the language convincing enough.
I feel most large companies and some smaller ones are interested in trying out Rust, it's trendy. But time will show for which parts the switch was advantageous; and I'm very interested in the findings. The premise of the language is indeed convincing a lot of people. People do however, choose the wrong tool for the wrong job all the time, OP's article in point.
1 reply →
> Personally I think operating systems (kernels) should be as performant as possible, and C/C++ has been good enough for decades.
If that how you want your OS, that's fair enough. But I think a lot of people are happy to trade (to some degree, at least) performance for security, and would prefer that their OSs are as secure as possible first, and as performant as they can be second.
No, I'm not concerned with Linux/BSD/macOS performance, it's pretty good (I took Windows out because it does have performance issues [0]!). What I am concerned about is security bugs, memory errors, buffer overflows etc, all of the things Rust attempts to solve [1].
I think for weapons & flight control, ATC systems, we already have Ada that's designed for "can't fail systems".
[0] https://www.blobstreaming.org/former-microsoft-developer-say...
[1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
I agree, operating systems should have less out-of-bounds memory issues. Is that Rust's place? Replacing the parts of OS code where it's OK to sacrifice some performance?
Ada has a foothold for sure, but there's a surprising amount of C++ in military planes and weapon systems.
I didn't read [0], but the parts of Windows that's poorly performing is not the fault of the language.
Rust is already in Windows: https://www.reddit.com/r/rust/comments/12yg3cp/microsoft_rew...
Linux added Rust support: https://docs.kernel.org/rust/
Well aware, and it affects none of my points.
2 replies →
[flagged]