> It might not be obvious how much effort it takes to manage bugfixes in dependencies where every few weeks there's a new breaking API change in egui/winit/wgpu, and while these probably seem extremely minor to those who spend all their time building an engine on top of said libraries, sinking a day or two in figuring things out and fixing stuff on every release is a gigantic waste of time in my view.
That's insane. For comparison SDL does breaking API changes every ~10 years (and they implement the previous version's API as a wrapper around the current version's API to support legacy software). Maybe the egui/winit/wgpu devs just expect that every end-user will just pin their package versions for the duration of a project, but it seems like a real burden for devs of libraries like Comfy that depend on them.
The entire Rust ecosystem for gamedev is kind of like that - it was only recently that people really started writing games entirely in Rust, and even now there are very few actual released commercial games out there. I think there's a bit of a loop happening where it's like, until Rust is considered "stable" for serious gamedev work, libraries will be developed in this kind of "unstable" way where breaking changes should be expected at any time, but at the same time, that instability is making it less of a serious contender for gamedev work.
Forget about gamedev. An anecdote: a friend wrote a personal Rust project which purely works with website's APIs and some minor file operations (basically a scraper).
And I, as his only user, have to constantly update my local Rust installation to newest dev to be able to compile his newest code base.
I understand it's more about him being on edge than the language itself alone -- but it still feels insane for me. In most of other languages, you can't make your code so backwards incompatible even if you actively try.
On the flip side of this, when libraries in rust do reach 1.0, they often are just done. The serialization/deserialization library serde which has become the de-facto standard has been on 1.0.xxx for the past seven years.https://crates.io/crates/serde/versions
I think this speaks to rust's strengths in that if you know your spec, you can write a rock-solid version of it - and its weakness, where if you don't know your spec you'll be making breaking changes a lot.
I'm always puzzled with people saying that things move too quickly and that they fail to keep up, in any language. Why do you guys even try to keep up in the first place? Unless there's a bug in a dependency you're using, if version 0.4 works, you don't have to use 0.5 or 0.6. Or maybe there's a new feature that you need in the newer version, then you can afford to spend time doing the migration but in this case you should also be happy the the pace of development is fast because that's how the feature ended up landing in the first place.
For most use-cases, it's fine to stay on out of date libraries for years, and that's what the Linux distros do all the time (mostly patching crippling bugs and security vulnerabilities).
I cannot find the article right now, but it was a wonderful piece on why a language like Rust is by design incompatible with the whole idea/process of making games. (I hope it rings a bell for someone who can find it.)
It went something like this: you start with a nice little tidy spec for basic arithmetic; how "a + b" must be the same as "b + a", etc. Then the designer comes back to you and asks for the ability to make numbers blue. You're like wtf but ok, when you add a blue "a" to a non-blue "b", the result becomes blue; you must remove half of your tests (because they no longer even apply) and rewrite the other half to match the spec, and a week of work later the result somehow still makes some mathematical sense. Then the designer comes back to you with the request to make even numbers shoot sparks on death, and to remove all fives...
And it's just how it goes. Games need to be iterated on quickly and efficiently, with a tight feedback loop on what ends up being fun during playtesting, and what doesn't. Rust might be great for writing low-level code / engines, but it will constantly get in your way where you need to respond quickly.
Interesting because there was a rust keynote by kyren arguing the exact same thing for why games were a poor fit for OOP/C++. Arguing for data oriented which rust does well. ... or C I suppose.
It might be that rust ecosystem this dev was dealing with was itself draining with continually shifting APIs, but that's not the same as the language itself.
wgpu only got the first non-0 release this July and started 4-ish years ago. They didn't even have a chance of taking 10 years. I'm sure SDL wasn't very API stable in 1998.
4 years after starting SDL was already deep into 1.2, which is the API that's still supported today via sdl12-compat (and the original codebase as well, which is still maintained even though it's deprecated).
For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible.
We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.
I sat down one weekend to try and make a demo in Bevy. The ECS system was cool, it's almost like querying a database. However every tutorial I found, even the most recent ones, were already outdated. They had just moved from 0.14 to 0.15 which broke a ton of things. I opted to mess around in Godot instead.
Exactly, this is poor SWE. If you need a new feature from a latest rustc or an upstream, and can stomach losing users, then perhaps you mark things #[deprecated] for a release or two (which should be months, not days).
AND don't bundle bugfixes with API breaks if it can be avoided.
I'm by no means a Rust fanatic, but I've had quite a different experience to many of the other commenters (especially around libraries etc) and I thought I ought to share it.
My background is as a generalist full stack developer using Node, Python and similar things. I have used C but only deployed one very small thing in production. I have managed devs using C++ but I took the view that I wasn't up to coding C++ for production (more or less Pit of Failure vs Pit of Success thinking).
I started a commercial project some time ago which required one application (think data ingestion) to be high performance. I decided to try Rust and these are my observations:
1. I was able to learn Rust while writing a daemon/service application which performs well and is robustly handling millions of "objects" per day for the last 6 months. I don't think I would have managed this with C++ without blowing my own foot off several times.
2. Library support for everything I needed was excellent. I have yet to experience a breaking change since starting the work more than a year ago.
3. Library devs have been very responsive and chatty about problems etc...
4. Really enjoyed working a strongly typed and compiled language. Bugs are bugs, but I realize that I've had a habit of just spotting problems in production after the fact and fixing them for things that just shouldn't happen. It's like DB integrity once you get used to it, it makes you feel a lot better.
5. Syntax is ugly as all hell.
6. Async / Tokio stuff makes you feel like you have no idea what's going on.
I think somewhere between the "Rebuild it in Rust" and "Rust is a horrible Deadend" there is a real opportunity to have a solid language which can allow devs of my level build decent software.
For certain things, Rust is painfully slow with no real benefits. We are starting to learn where we should and should not use Rust. If you ask me, Rust is becoming the new Ada.
Update: when I wrote slow, I meant development pace, not runtime performance
The author has one major issue with Rust in gamedev: they can't easily try out new game feature ideas or gameplay tweaks by writing quick and dirty code.
Such unfinished code can be obviously buggy and unsafe, but in game dev it matters more to have short feedback loop to try how things feel, than to have a perfectly correct code all the time.
Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
This is a substantially different situation from other domains like application and services development, where it's easier to plan what you're going to implement, correctness is more important, and you don't need to try out 20 different JSON parsers to see which one has the most satisfying feel.
C++ doesn't do quick and dirty either. That's why experienced game developers combine a core engine written in a high-performance language (C++, Rust, C#), with a scripting language (Lua, Python, hand-rolled).
That approach gives you the best of both worlds: high-performance core with high-velocity iterations for gameplay. Don't use Rust or C++ for scripting... madness lies that way.
> Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
The problem might just be an aversion to using quick and dirty solutions. Rust does a good job of making it feel wrong to write code that's not production ready, but there's nothing stopping you from using unsafe wherever you want.
I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major "downside" you need to account for is that the type system will try to prote you from crashes. Which can be a bit of a chore since youknow it won't crash with the values you've given it. But if you're comfortable with .unwrap and the occasional unsafe while prototyping, it's honestly fine (at least within Bevy).
Alternatively, they could try "scripting" behaviour first before implementing it in Rust, although from what I understand bevy's scripting support (I don't think it's explicitly supported, but bevy is very extensible) is still very early in development
A lot of big expectations were placed on Rust; plenty will have turned away and decided the trade-off on development velocity wasn't worth the guarantees of memory safety or the promise of zero cost functional abstractions; not to mention it still requires expertise to write something performant. I've certainly done it myself, dipping my toes in the water out of curiosity and realising it wasn't what I needed.
Many people here say that languages like Ruby or frameworks like Rails are dying, or some such, but in reality these languages just carve out their space, settle into it, and become the go-to choice because there's nothing surprising about them any more. If Rust can be considered stable or boring in this way then it will have succeeded where a lot of new and novel languages tend to fade into obscurity.
Thing is, if one can tolerate automatic memory management (regarless of the form), than the guarantees of safety are already there, with faster compile times.
It is already great that it managed to bring affine types into mainstream, making many programing languages designers consider how to integrate similar capabilities into existing languages, and maybe put some pressure on WG21 to take security more seriously (I remain a dreamer).
Outside very specific use cases, we already have Ada like safety on programing languages with automatic memory management.
Build times are a bit slow, but runtime is just as fast as what you'd get doing the same thing in C or C++.
Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic.
My Productivity tanked when using Rust but I have not written 20k Loc yet. Ownership gets messy when you have a complex mutable application model (worse: oop written according to SOLID principles). At that Point,Just give Up and use ref counting (which you would use in c++ anyway..).
I still like to believe that the upfront cost will be offset by the lower long term maintenance cost for some types of software. Except, that that is not always the case for gamedev where shitty code can still make good and successful games. You may miss a deadline, but if you are not going to maintain the code base for 20 years, so why spend the effort on quality code?
Every time someone on Reddit or someplace asks "What's the appeal of Ada anyway?" I say "Think of Ada as boomer Rust."
It turns out that when you need to get the details right and be safe in a systems level language, development can be slow. This is a good thing. Studies with Ada projects compared to C have shown that time and money is saved in the long run due to fewer bugs and less maintenance. You just have to embrace that particular suck because it pays off in the end.
The first time I saw a package described with "blazingly", I thought it was a joke! It seems to have caught on now, but it still sounds ironic when I read it.
> Comfy is now archived until further notice... After abandoning Rust for gamedev [1] ... I just don't have the energy to constantly play catchup to the Rust ecosystem
There's a good amount of different compatibility layers that you can use. There are a few vulkan implementations, there is Angle, and Webgl is still working... Depending on what you are doing you can still do a lot with OpenGL, you don't have to rely on the implementation in Nvidia drivers or whatever. I think most people using it are just really comfortable with it's shader language.
It's a standard, not a feature from some company that is ending support. There is a governing body.
"The Khronos Group, Inc. is an open, non-profit, member-driven consortium of 170 organizations developing, publishing and maintaining royalty-free interoperability standards for 3D graphics, virtual reality, augmented reality, parallel computation, vision acceleration and machine learning.[1][2] "
Because it's much simpler that the alternatives and will remain supported forever in practice (either directly or through things like ANGLE or MoltenGL) even if it's deprecated.
If you don't need the features of the newer APIs it makes perfect sense to keep using it.
Then tell me what is a better alternative then: human-friendly API (which Vulkan isn't) but still low level enough to do some serious graphics programming?
I have noticed a trend for Rust game development to revolve around developing engines that are "high-performance," particularly with a focus on entity component systems. This is development for the sake of optimisation and premature is putting it lightly.
Let me say this loud and clear for anyone who dares to hear a fool: don't even think about performance until it becomes a problem and even then you could still probably stand to ignore it. Ergonomics are infinitely more important for an engine. If you can't develop and iterate quickly you can't prove your ideas and make something fun. These are two things Rust is very bad at.
Rust is good at many things, but game development is really not one of them. C++ is still okay. If you want to try something new, Odin[1] is shaping up nicely.
Probably never, or maybe much much farther in the future. Cooperative tasks aren't really a priority from what I've heard. It's still a low-level language like C with high level ergonomics.
Isn't the whole point of Rust is to be safely compiled to machine code, and not have built in garbage collection. So as was suggested in the article, if someone was open to using C#, then that would be the way to go. C# has all the features and safety and easier than C++. If C# is on the table as an option, then neither Rust nor C++ is also really needed.
This was the reason I stopped using Rust for hobby projects, there was always something breaking when going back to the project after a month. A library wouldn't compile or I had to fix things. So in the end, every time I had to spend 30min fixing things or forking libraries. Some things needed the latest stable, some the latest dev, some that version from 245 days ago. It was really a maintenance nightmare.
While I generally agree with most of what is here (and in the linked post on not using rust for gamedev), moving to C++ seems like it's a incomprehensible choice to me.
> At this point I've fully switched to developing games in C++, and I'm very happy with this choice.
Hm.
Well, I hope that works out for them, but if iterating speed and quick prototypes with hot reloading that doesn't crash is what people are looking for, I don't think anyone who hasn't spent 20 years programming in C++ is going to find it there (or possibly, anyone at all...).
I feel like as a small-moderate sized team, you really REALLY need a compelling reason not to pick UE / Unity / Godot.
The choice of language probably is less significant than the decision to use an existing engine rather than rolling your own.
For all the talk about prototyping and iteration speeds, and given they have:
> released a game on Steam in Unity, Unreal Engine 4, and Godot
I'm astonished that they haven't prioritized 'stick with one technology and ship more often' over 'try new things'.
Readit News
That's insane. For comparison SDL does breaking API changes every ~10 years (and they implement the previous version's API as a wrapper around the current version's API to support legacy software). Maybe the egui/winit/wgpu devs just expect that every end-user will just pin their package versions for the duration of a project, but it seems like a real burden for devs of libraries like Comfy that depend on them.
And I, as his only user, have to constantly update my local Rust installation to newest dev to be able to compile his newest code base.
I understand it's more about him being on edge than the language itself alone -- but it still feels insane for me. In most of other languages, you can't make your code so backwards incompatible even if you actively try.
Basing any serious project on 0.x libraries is always subject to this issue.
I think this speaks to rust's strengths in that if you know your spec, you can write a rock-solid version of it - and its weakness, where if you don't know your spec you'll be making breaking changes a lot.
So I guess I'll hold off on having random numbers in Rust then [1].
[1] - https://docs.rs/rand/latest/rand/
For most use-cases, it's fine to stay on out of date libraries for years, and that's what the Linux distros do all the time (mostly patching crippling bugs and security vulnerabilities).
It went something like this: you start with a nice little tidy spec for basic arithmetic; how "a + b" must be the same as "b + a", etc. Then the designer comes back to you and asks for the ability to make numbers blue. You're like wtf but ok, when you add a blue "a" to a non-blue "b", the result becomes blue; you must remove half of your tests (because they no longer even apply) and rewrite the other half to match the spec, and a week of work later the result somehow still makes some mathematical sense. Then the designer comes back to you with the request to make even numbers shoot sparks on death, and to remove all fives...
And it's just how it goes. Games need to be iterated on quickly and efficiently, with a tight feedback loop on what ends up being fun during playtesting, and what doesn't. Rust might be great for writing low-level code / engines, but it will constantly get in your way where you need to respond quickly.
It might be that rust ecosystem this dev was dealing with was itself draining with continually shifting APIs, but that's not the same as the language itself.
https://kyren.github.io/2018/09/14/rustconf-talk.html
For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible. We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.
AND don't bundle bugfixes with API breaks if it can be avoided.
Otherwise, just don't bother!
This is hype-driven development at its worst.
My background is as a generalist full stack developer using Node, Python and similar things. I have used C but only deployed one very small thing in production. I have managed devs using C++ but I took the view that I wasn't up to coding C++ for production (more or less Pit of Failure vs Pit of Success thinking).
I started a commercial project some time ago which required one application (think data ingestion) to be high performance. I decided to try Rust and these are my observations:
1. I was able to learn Rust while writing a daemon/service application which performs well and is robustly handling millions of "objects" per day for the last 6 months. I don't think I would have managed this with C++ without blowing my own foot off several times.
2. Library support for everything I needed was excellent. I have yet to experience a breaking change since starting the work more than a year ago.
3. Library devs have been very responsive and chatty about problems etc...
4. Really enjoyed working a strongly typed and compiled language. Bugs are bugs, but I realize that I've had a habit of just spotting problems in production after the fact and fixing them for things that just shouldn't happen. It's like DB integrity once you get used to it, it makes you feel a lot better.
5. Syntax is ugly as all hell.
6. Async / Tokio stuff makes you feel like you have no idea what's going on.
I think somewhere between the "Rebuild it in Rust" and "Rust is a horrible Deadend" there is a real opportunity to have a solid language which can allow devs of my level build decent software.
Update: when I wrote slow, I meant development pace, not runtime performance
Such unfinished code can be obviously buggy and unsafe, but in game dev it matters more to have short feedback loop to try how things feel, than to have a perfectly correct code all the time.
Rust doesn't do quick and dirty, and will complain about code quality even when game devs don't even plan to keep the code.
This is a substantially different situation from other domains like application and services development, where it's easier to plan what you're going to implement, correctness is more important, and you don't need to try out 20 different JSON parsers to see which one has the most satisfying feel.
That approach gives you the best of both worlds: high-performance core with high-velocity iterations for gameplay. Don't use Rust or C++ for scripting... madness lies that way.
The problem might just be an aversion to using quick and dirty solutions. Rust does a good job of making it feel wrong to write code that's not production ready, but there's nothing stopping you from using unsafe wherever you want.
I've worked with Bevy, and there's it's incredibly easy to write "quick and dirty" to test stuff. I guess the major "downside" you need to account for is that the type system will try to prote you from crashes. Which can be a bit of a chore since youknow it won't crash with the values you've given it. But if you're comfortable with .unwrap and the occasional unsafe while prototyping, it's honestly fine (at least within Bevy).
Alternatively, they could try "scripting" behaviour first before implementing it in Rust, although from what I understand bevy's scripting support (I don't think it's explicitly supported, but bevy is very extensible) is still very early in development
Many people here say that languages like Ruby or frameworks like Rails are dying, or some such, but in reality these languages just carve out their space, settle into it, and become the go-to choice because there's nothing surprising about them any more. If Rust can be considered stable or boring in this way then it will have succeeded where a lot of new and novel languages tend to fade into obscurity.
Outside very specific use cases, we already have Ada like safety on programing languages with automatic memory management.
Development time is absurdly faster, though, since you don't spend much time debugging annoying language-design bugs, and can focus entirely in your code's logic.
It turns out that when you need to get the details right and be safe in a systems level language, development can be slow. This is a good thing. Studies with Ada projects compared to C have shown that time and money is saved in the long run due to fewer bugs and less maintenance. You just have to embrace that particular suck because it pays off in the end.
Dead Comment
> Comfy is now archived until further notice... After abandoning Rust for gamedev [1] ... I just don't have the energy to constantly play catchup to the Rust ecosystem
[1] (April 2024) https://loglog.games/blog/leaving-rust-gamedev/
I don't get why somebody would start a new project based on OpenGL these days.
Depreciated by 'who'?
It's a standard, not a feature from some company that is ending support. There is a governing body.
"The Khronos Group, Inc. is an open, non-profit, member-driven consortium of 170 organizations developing, publishing and maintaining royalty-free interoperability standards for 3D graphics, virtual reality, augmented reality, parallel computation, vision acceleration and machine learning.[1][2] "
If you don't need the features of the newer APIs it makes perfect sense to keep using it.
Let me say this loud and clear for anyone who dares to hear a fool: don't even think about performance until it becomes a problem and even then you could still probably stand to ignore it. Ergonomics are infinitely more important for an engine. If you can't develop and iterate quickly you can't prove your ideas and make something fun. These are two things Rust is very bad at.
Rust is good at many things, but game development is really not one of them. C++ is still okay. If you want to try something new, Odin[1] is shaping up nicely.
[1] https://odin-lang.org/
> At this point I've fully switched to developing games in C++, and I'm very happy with this choice.
Hm.
Well, I hope that works out for them, but if iterating speed and quick prototypes with hot reloading that doesn't crash is what people are looking for, I don't think anyone who hasn't spent 20 years programming in C++ is going to find it there (or possibly, anyone at all...).
I feel like as a small-moderate sized team, you really REALLY need a compelling reason not to pick UE / Unity / Godot.
The choice of language probably is less significant than the decision to use an existing engine rather than rolling your own.
For all the talk about prototyping and iteration speeds, and given they have:
> released a game on Steam in Unity, Unreal Engine 4, and Godot
I'm astonished that they haven't prioritized 'stick with one technology and ship more often' over 'try new things'.