Rust – Are We Game Yet?
arewegameyet.rs
arewegameyet.rs
- https://store.steampowered.com/app/2198150/Tiny_Glade/ which looks AMAZING
- https://veloren.net/ which looks really cool
Good to know there are some legit non-toy things being made. I remember back in the mid 2000s pretty much the only thing you could play on Linux was TuxRacer, and the state of Rust game development (right now) kinda reminds me of that period.
Then steam happened and now I can play Civilization: Beyond Earth all I please!
People used WINE to play many games before Proton even existed for years and not just small titles. I still remember when I had to switch from Windows to GNU/Linux + WINE to play Starcraft 2 when it came out, because on Windows it would hang at some point in the campaign, with no way around it.
Do you know of any data documenting total funding over the entire lifetime of the project from all the project corporate sponsors:
* https://en.wikipedia.org/wiki/Wine_(software)#Corporate_spon...
Not to mention there's been a lot of volunteer vision & contributions over the project's nearly 30-year history.
So, I'd be reluctant to give Valve too much of the credit--as much as it may have had an impact over the most recent few years.
The name and domain are generic enough that I imagine most visits are "What is this?"
- https://www.areweguiyet.com/
- https://www.arewewebyet.org/
A whole list: https://wiki.mozilla.org/Areweyet
- perf.rust-lang.org is great for monitoring for regressions on a day to day basis, perfect for compiler devs. But arewefastyet.rs aims to answer other questions, like
- How much rustc has improved on certain workloads over a long time period.
- How rustc performance is affected by different hardware. 8 cores is better than 4, all other things being equal, but how much more? On which workloads?
- How much time in seconds it actually takes to compile common crates. Concerns about developer productivity could be allayed by seeing the number of seconds it takes to compile a complex binary like ripgrep.
But I bet most people who peruse the `rs` top-domain are Serbs and Rustaceans.
Brazil's currency is the "reais" and has the sign "R$"
My cultural bias is showing.
* <https://github.com/rust-gamedev/wg/issues/90>
* <https://github.com/EmbarkStudios/rust-ecosystem/issues/18>
I say scare quote tracking because due to the nature of console NDAs it's unlikely you'll see much if any useful details in an open public forum.
The issues aren't dissimilar to those facing Godot (although it has the benefit it's able to use existing C++ compilers) and the project has previously outlined some of the issues involved:
* <https://docs.godotengine.org/en/4.0/tutorials/platform/conso...>
* <https://godotengine.org/article/godot-consoles-all-you-need-...>
The current "solution" seems to be console-related development activity occurring via the recently established W4 Games (https://w4games.com/2023/02/28/godot-support-for-consoles-is...) but that's obviously never going to be openly developed without console platform approval (same as any other game engine).
This is literally the last thing we need so we can ditch Unreal Engine. We'd use Godot, but since the rest of our stack is Rust, we're waiting on the Rust ecosystem to catch up to our needs.
Rust + WASM + WebGPU is going to be so good.
The only non-mozilla "Are we X Yet" I know about is "Are we distributed yet?" which tracks various P2P features in the browser, many in connection with IPFS: https://arewedistributedyet.com/
Asking because everyone seems to be all in on rust but i'm fucking confused every time I start reading its docs and syntax.
Is it worth using rust for anything that isn't currently written in C? i.e. operating systems and compilers?
Possibly - it requires an understanding of memory ownership and lifetimes which is something the GC in C# takes care of for you. It IS a bit of a burden and harder, but does have pay off for some domains where you want that level of control.
> Asking because everyone seems to be all in on rust but i'm fucking confused every time I start reading its docs and syntax.
Everybody has this the first couple times they attempt Rust. :.) It is different, but once you get over the straight up initial learning curve...it is pretty smooth sailing.
> Is it worth using rust for anything that isn't currently written in C? i.e. operating systems and compilers?
I think so, but I'm a bit biased as Rust is my primary and favorite language. I like the memory control it gives me as well as its functional like nature. Since it is also roughly the same speed as compiled C/C++ it can play nicely in some of those domains but with better memory safety.
First, Rust has its unusual way of managing memory through ownership and borrow checking. There is a steep learning curve there, but it's not that hard once you "get" it. However, some programmers need to unlearn their web-of-pointers programming style and adapt to Rust's way of thinking to get it.
Then, Rust doesn't have inheritance and hates shared mutability. For game development this makes the easy "class Player extends Entity" design nearly impossible to work with. Entity-Component-System works way better with Rust, but ECS design is another big thing to learn.
IMHO Rust is worth using for most things that would be written in C usually.
For game development the jury is still out. Rust has great multi-threading support, which games don't use that much yet. Rust also focuses a lot on correctness and preventing bugs. This is a bit controversial in gamedev, since the usual way is to iterate quickly, and fix stuff later. Rust's proposition is to iterate a bit slower, but not have to fix as much later.
You're probably capable of understanding these things, but there is a definite learning curve.
I think just about any programmer has the ability to learn Rust. The basics will probably come pretty easy; the syntax and general way of writing code are designed to be familiar to anyone who's used C-like languages
Fully understanding it and learning the more advanced features may be hard, harder than other languages, but I think it's within anyone's capacity. I definitely find myself thinking harder about things when I'm writing Rust, but I don't think it's on a whole separate plane of ability
> reading its docs and syntax
I don't know which docs you started with, but just in case, I suggest you start with the Rust Book (https://doc.rust-lang.org/book/). It's designed to ease you in gradually, tutorial-style; much better than eg. starting with the reference and API docs
Some people really like Rust, but I don't think it's that big of a deal if you're already using a memory safe language. If that's the case, and you don't like Rust, I'd just say to not bother with it.
And Bevy (one Rust game engine) makes it very easy to ignore much of the problems of Rust, as the architecture (ECS) and the implementation Bevy has of it, hides a lot of "warts" that you would have to battle with otherwise.
Bevy makes it really easy to learn Rust, at least that's what I've found when I picked up Rust first.
What Rust really skips is inheritance (although you can get partway there with trait dependencies), which I think is generally a good thing
In Rust we could make a Mimic by composing a Chest, and a Monster, and then implementing any traits on the resulting composite object appropriately, passing through to an underlying object in some cases -- opening this "Chest" ought to cause its status as a Monster to be revealed right?. In languages with single inheritance we need to decide, is a Mimic a Chest? Is it a Monster? Maybe all Chests are Monsters? Maybe all Monsters are Chests? In languages with multiple inheritance we can inherit from both, but we might find that isn't what we wanted either and there are likely to be conflicts from such a web of heritability.
You are not the only one. :)
I definitely walked up to Rust & then turned around & left again during my learning process. :D (And that was with the advantage of having dealt with manual memory management previously.)
But I think the Rust community generally acknowledges the learning challenge that Rust may present at the beginning & work to reduce it over time. And also provide the reassurance that it's definitely not just you.
At the beginning I think the resource I found most helpful was this:
* <https://fasterthanli.me/articles/a-half-hour-to-learn-rust>
Primarily because it's an extremely compact overview of Rust syntax which has the benefit of (a) improve your familiarity with the syntax & meaning to enable you to read Rust code; and, (b) it's all in one page so when one inevitably forgets something they can return to the page & search and/or review it. :)
As the introduction puts it:
> In order to increase fluency in a programming language, one has to read a lot of it. But how can you read a lot of it if you don't know what it means?
> In this article, instead of focusing on one or two concepts, I'll try to go through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean.
It is also perhaps the shortest article by fasterthanlime on record. :D
> Is it worth using rust for anything that isn't currently written in C?
That's an interesting question. (FWIW C and C++ are also used for writing servers, command line & GUI applications.)
One question I'd ask would be: have you run into the limits of any language you currently use in terms of capability, performance, packaging/distribution or community?
If not, then perhaps Rust wouldn't currently be the best place to invest your learning time.
But if there's some element of Rust that intrigues you, and you're kind toward yourself during the learning journey it's likely that at a minimum you may learn something about lower level aspects of computing that might help you when you use other languages.
(One thing I've noticed with Rust is that--due to the power of the `cargo` build tooling & surrounding standardised library/crate ecosystem--once you get a relatively small way along your learning journey it can be relatively straight-forward to add a "cool"/"interesting" crate to your project & create something a bit more interesting than...a hard-coded currency exchange rate calculator or something. :)
So maybe browse <https://lib.rs/> (an alternative interface to crates.io which I find more "explorable") and see if there is a crate whose functionality makes you think "Ooo, that'd be cool to be able to use".)
Good luck!
Unlikely to ever be as supported as what Epic themselves maintain though. Same for Godot. If you want to use something that will for sure support Rust, you better use a Rust project for the games.
However the Bevy team said they'll be focusing on UI editor soon, so that's something to look forward to.
But even outside of that, I guess UE is interesting due to decades of accumulated industry wisdom (eg nanite, lumen, etc).
There's also kajiya by Embark that can be integrated with Bevy (I think there was a crate) that brings some of the virtualized geometry stuff to Rust games. Haven't used it myself though
While likely true that it's "Unlikely to ever be as supported" as the 4 officially supported languages[0] ("GDScript, C#, and, via its GDExtension technology, C and C++."), Godot's GDExtension technology is specifically intended for use in adding support for other languages.
The most relevant tracking issue for Rust is presumably:
* <https://github.com/godot-rust/gdnative/issues/824>
Which links to:
* <https://github.com/godot-rust/gdextension>
[0] https://docs.godotengine.org/en/4.0/getting_started/step_by_...
When you use non-standard languages for industry purposes where everyone else is doing their work, you will end up wanting to eventually use those tools, but not be able to, or have to write bindings for them that don't exist which means you increase your maintenance labor requirements. Worse yet, you may be deluded into thinking you can write something in your target language that will be good enough to replace the desired library--but it will more than 9 times out of 10 never have the same feature set or support or collaboration base.
If you're making games, use C++.
If you're doing scientific computing, use Python and C++.
If you're making macOS native interfaces, use Swift and Objective-C.
If you're making Android apps, use Java.
I think a lot of inexperienced developers don't get bit by these mistakes until they've spent too much time in one space and even if they're successful in their own merits, they don't understand why other factors don't continue to grow in the ways they do, like:
Hey I wrote a game in Ruby, but for some reason I can't find people who want to collaborate with me, I wonder why? It's because comparatively, no one is writing games in Ruby.
I wrote this really cool web development library that uses Elm, why don't I have broader adoption? Because no one is using Elm.
The combinatorics of every decision you make in software development have eventual consequences that sometimes take years to figure out simply because you don't have the time to ask everyone who might be a potential interactant how they feel about your decision making.
If you're making a game you plan on publishing and can insulate your decision making from the output you're trying to generate in, I'll say in less than 5 years, then go for it, but statistics are already working against you in this field, why would you make your life harder on yourself?
Almost everything about this craft sets you up for failure. Don't make it harder.
Even people who you think know what they're doing and are core maintainers of large projects you probably know of make some really questionable mistakes and sometimes by sheer dumb luck or factors they don't understand do they still stay successful.
I can tell you of one core maintainer for a multi-year run open source piece of game software doesn't believe there are significant performance characteristics between programming languages compiled to machine code versus interpreted languages when it comes to game programming.
This is a guy who maintains probably the most used scripting language based game software in his niche.
I also say this as one of the largest maintainers of Lua-based game software in the space. Lua is one of the if not the top used scripting languages for video games, and we just do not see the adoption we want for our products. It's overwhelmingly because our users want to use C++.
In the end it's all about engines and libraries, and engines usually dictate the language.
1. Learn GDScript
2. Grow frustrated with duck typing
3. Learn that you can switch to C# and still use Godot
Godot 4 having two first class languages is such an odd paradigm.
FWIW GDScript has had optional/gradual typing since Godot 3.1[1] with significant improvements implemented for Godot 4.0[2].
Also, I've seen a non-zero number of people who were used to C# comment that to their surprise they actually liked using GDScript. :)
So, you know, maybe it's C# that will be the onboarding path for GDScript developers instead. :D
[1] <https://godotengine.org/article/optional-typing-gdscript/> [2] <https://godotengine.org/article/gdscript-progress-report-fea...>
Unity used to have 3. Boo (Python inspired), UnityScript (JS inspired) and C#. I'd say for a time UnityScript was even the most popular (back in the days they still called Boo and UnityScript Python and Javascript). But over time they've whittled it down to just C# as the audience switched from hobbyists prioritising accessibility to studios prioritising performance and maintainability.
Unreal also used to have UnrealScript, dropped it, but seems to be trying again with Verse.
What a waste of time and effort when there are other categories that game developers care more about.
In terms of C#, they did get funding of $USD24,000 for implementing it: https://godotengine.org/article/introducing-csharp-godot/#ac...
And while I'm no fan of the language I do see the strategic value in potentially providing a migration path from Unity.
> GDScript is a dead end,
Do you mean in terms of it being a "single use" language?
> and they're making their own physics engine?
I think it's significant to note that in both cases--creating a new language & a "new" physics engine--it wasn't necessarily their first choice.
As they've noted[0], they first used Lua & tried Python before creating GDScript.
And for Godot 3.0 they moved to using the 3rd party Bullet Physics engine[1] but decided for 4.0 to move the focus back to the custom physics engine--in part because Bullet had "a shift of focus...away from game development".
And in both cases they're developed the support in a modular fashion so that the defaults can be replaced (e.g. by Rust/Python/Nim and Bullet/Jolt) so everyone can be unhappy...or happy if they replace it by something they like, I guess. :D
FWIW I don't think anyone particularly wants to learn a single use language but the number of comments I've seen that go "Ugh, I didn't want to learn or use GDScript but it turns out I like it" is non-zero.
And, in my case, I can't argue with the results, even in GDScript for 3.0 the differences between Python & GDScript weren't huge & via the Editor integration it's just so easy to write...for the most part. (There's a reason I've spent so much time writing/using GDScript/FFI-bindings for pre-compiled library binaries--cos I'd rather write GDScript than any compiled language. :) )
With the improvements in gradual typing, optimization & quality-of-life features that come with GDScript for 4.0 it's even better. (As languages go I see Rust & GDScript actually make a nice pairing to move between--in part due to the nice `match`-based features in both.)
Also, they did just spend four years developing a Vulkan-based renderer, which does seem like something game developers care about.
Do you have any examples of what categories you see game developers caring more about that 4.0 hasn't improved on?
Godot as an engine & a project is definitely not without its faults but I don't think "futility" and "waste of time and effort" are particularly fair/generous characterizations of the labor allocation.
[0] https://docs.godotengine.org/en/4.0/about/faq.html#what-were...
[1] https://godotengine.org/article/godot-30-switches-bullet-3-p... (See note on page re: 4.0.)
It's Kotlin these days (your point still stands).
I've been trying to (lazily) make games for years. It's hard.
But, like, it literally doesn't? The fact that it's a different language nowadays (though still the same runtime?) means that there's no One True Language for Thing X. Times change. Today it's FooLang, but in a couple of years, when the stars align just right, it may be LangBar.
Embrace-extend-extinguish is a tried and true strategy to overcome entrenched languages, I suppose.
You're ignoring the very significant codebase in Fortran. I think Fortran might even be the dominant language for supercomputers, but I don't have hard statistics on the language mix.
So, if your ambitions are for shipping mobile apps, Unity is probably the engine for you, that's their biggest audience.
We are in the midst of the beginning of a paradigm shift.
So while you're right, it's hard for a developer right now to make a hard decision given the impending explosion of growth.
As an example, for nearly 20 years, the physics library choices game developers have had has been a small handful, and of those solutions, most use one of two major codebases.
No one is displacing that tomorrow, or next month, or even, I don't know, I'll be bold and guess 5 years from now. If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
You can absolutely have exponential growth and in major categories make zero impact to the industry.
(there are a couple of externally maintained bindings though)
PS: the most serious case against C++ for game development is probably the widening gap between "modern C++" and the kind of "sane C++" that's used in the game dev world (e.g. modern C++ is moving into a direction where most new features are entirely useless/pointless for game development). That was at least the main reason why I left C++ mostly behind and moved back to C (or realistically: a mix of mostly C and some C++ where needed to talk to libraries), and I keep a very close eye on Zig to eventually replace my use of C.
This is the easiest way we can automate bindings to other programming languages without having to use larger instrumentation like SWIG.
It's definitely not the industry standard recommendation I wrote about above, but internally we have other objectives that make it sensible. And we still get to use C++.
Betting on the status quo is definitely a pretty safe bet--and particularly over the timeframes of AA-AAA game development. And particularly for someone who is wanting to pick up a job in the industry tomorrow.
> for nearly 20 years, the physics library choices game developers have had has been a small handful
Another way of looking at that is that it means there's 20 years of pent-up interest from people who want a physics library that can benefit from the past 20 years of programming language & software development methodology improvements. :)
> If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
I think it's important not to discount the impact build tooling like cargo can have on adoption of Rust libraries and the potential for developing libraries in Rust but also exposing them via C and/or C++ bindings and gain adoption via that path as well.
And, due to a combination of "starting at the same time" & build tooling, the potential for cross-industry cooperation on development is greater too. (Questions about fields of endeavour aside, I note that Rapier physics-related projects are sponsored by both game companies & a mining-related company[0].)
(And with regard to scientific computing & Python--well how many people know or care whether the "fast" library they use with Python is implemented in Rust or C++ as long as it's stable & reliable?)
> You can absolutely have exponential growth and in major categories make zero impact to the industry.
True. From my limited perspective it all comes down to whether Rust can deliver on the promises it makes & whether it can make the cost of switching compelling enough for teams to move.
But there does seem to be quite a few people who are putting in a lot of work to try make that happen.
Of course, it's entirely possible the games industry decides against such a wholesale change in which case I guess anyone who learned Rust in the interim will just have to take a less underpaid job in a different industry. :)
[0] <https://dimforge.com/blog/2023/01/22/the-year-2022-in-dimfor...>
I'm predicting we won't hit JavaScript levels of diversity (the problem space is just that much harder in gaming then in web) where the diversity itself is a hindrance but given the metrics of interest in rust and it's ease of use compared to C++ it's just a matter of time.
If I'm wrong the only think I think I would be wrong about is when this inflection point occurs. Either we hit in the future or we just passed it.
I guess by someone announcing their confusion they are also announcing the fact that they are NOT part of THAT group of humans. Or they just want to be a smart ass. Pick one.
Right now i am using unity and c# which seems ok for my needs currently.
It can potentially be great. For that, it needs tooling, but tooling is the largest problem to solve in any language anyway.
* <http://www.areweembeddedyet.com/>
It currently redirects to:
Which doesn't really contain anything other than a link to <https://github.com/rust-embedded>.
[1] https://docs.rust-embedded.org/cortex-m-quickstart/cortex_m_...
Many have a stable API that hasn't changed in forever and are rock solid, but never reached 1.0.0
There were some earlier hints of this, e.g. Flask was already the defacto Python web framework when it went 1.0 in 2018 after 8 years: https://palletsprojects.com/blog/flask-1-0-released/
Functionally, a lot of 0.x bumps end up just being x.0 bumps
I get the benefits of the language and would like to see it succeed, but real-world adoption seems to be way below what's imagined here, and the "good for every task" posts give it kind of a cultish vibe that makes me look away.
Frankly, people are excited about Rust. It promises C-like performance and utility while being more expressive and much safer. Cargo is awesome. The level of quality of its ecosystem is, in general, unlike that of most other programming languages. At the end of the day, people are just really enthusiastic about it and want its community and ecosystem to grow so they can use it for more things. Is it sometimes taken too far? Absolutely, but you could say the same thing about most popular languages at some point: JS, Python, Java, etc.
Rust isn't great for rapid prototyping, where Python excels. Python is quicker for the first few hundred LoC, but I quickly find myself reaching for Rust enums (aka ADTs or sum types), match expressions, and the assurances of static typing.
It's also a bit annoying dealing with &str vs String. I frequently find myself writing things like "foo".to_string().
It's also difficult to build Rust with Bazel, and possibly other non-Cargo build systems.
Except for all the third-party libraries that don't have type information, which was most of them last time I checked. (Maybe this has gotten better recently? I admit I haven't used Python much in about two years.)
Without knowing what specific comments you've based this observation on, I can only speak in generics but I do think there's some nuance around "Rust is good for this use case" versus "Rust can be used for this use case".
And, from my perspective, it is cool that one can use Rust for everything from "systems" software down the stack to UEFI & embedded realms and up through applications & WASM browser-based projects. (Whilst also acknowledging that one could also say the same for C or C++ or Javascript to varying degrees of integration/complexity.)
My personal experience has been approaching Rust primarily as a replacement for C/C++ where I find it compelling. For me (based on my relative usage over the past year) it's less compelling as a replacement for Python/GDScript for small/quick/hacky projects (primarily due to its compilation & analysis time/overhead) but I can see why for people who have previously worked on larger Python/Javascript projects it might be an attractive option.
One other aspect that I think affects how people relate to/talk about Rust is that there seems to be an express acknowledgement about the humanity of software developers which I'm unaware of existing to the same degree in other programming language communities/culture/history previously.
Any language choice comes with trade-offs and my impression of what you might be seeing is not so much that people think Rust is necessarily the best for all use-cases but that the trade-offs required for each use case are (or have the potential to be) worth it ("good") in exchange for what is gained.
I also respect that the Rust language development community admit they don't always get everything right, and that there's acknowledgement that Rust is neither a perfect language nor the last language and that one thing that Rust does is identify what can improved for "the next language after Rust".
To be honest, I used to feel the same way that you do about Rust posts. Then I started using it, and I got enthusiastic as well.
You should read Why Not Rust (https://matklad.github.io/2020/09/20/why-not-rust.html). It was written by someone who has written a lost of Rust and likes the language, but acknowledges that it's not always the best tool.
It's a few years old, so not all of it holds up. For example, the author criticises the IDE tooling as immature. I don't think that's true in 2023. Coincidentally, the author created the official language server for Rust.
This is particularly true with languages.
It will settle down, and Rust will become a respectable addition to the collection of useful languages. When that happens, it will have it's advocates and fans like any other language, but it all won't seem quite so over-the-top.
I've seen this same pattern play out many, many times over the years.
There are plenty of such cases and those raised constantly here and comment threads even slightly related to Rust.
C++ is popular in the game industry, because it compiles to native code and can be fast. Rust can also do both of these things, and it’s also memory-safe and saner in general, so why not try writing games with it and improve the game stability and developer experience?
...and even Minecraft was ultimately re-written in C++ to bring it to mobile and consoles
Your average Unity game developer does not do anything in C++. The engine itself is implemented in C++, but the game logic written by game developers is in C#.
This link, for example, is... Boring? Like why is it here? What's to discuss? Should we just link to the PIP repository, too?
I submitted the URL and enough people found it interesting, so it ended up on the frontpage. The same for every submission you find on the frontpage.
> What's to discuss?
The state of game development with Rust. Apparently there is a lot to discuss, as it's currently on the #1 spot on the frontpage, with 60 comments.
> Should we just link to the PIP repository, too?
You're welcome to submit whatever websites you want. If enough people find it interesting, there will discussion around then subject.
Half of which is "why/what is this" and "what's with the 'areweyet' thing?"
There's not a whole lot of discussion about game development in Rust going on, and less still about the actual content of the link.
Unless you've manually counted all the comments, it seems like you're incorrect, most of the discussions are related to the subject at hand, compared to this thread you started here :)
While I don't use or advocate for Rust in a professional capacity, I really like seeing the barrier to entry get lower and lower. In the same way that people fall back to Python for completely random tasks because it's familiar and the path forward is well mapped.
There’s nothing more to respond to your question beyond “agree to disagree”. You see the benefits of the language, want it to succeed, and get cultish vibes. Okay? There’s nothing to counter-argue here, beyond bickering about what is and what is not a cult.
Maybe criticize the language itself? That would be more fruitful.
(I see these kinds of comments on HN all the time: “I want to genuinely ask: why Thing? Why do you like Thing so much?.” And then there are a dozen replies giving stump speeches. I don’t get it.)
It’s simply a much nicer language to work with on many metrics, which are the ones that I consider important. Great developer experience, and great language.
Groupthink.
I enjoy thinking and speaking based on fundamentals, regardless of what surface ideas people at large have. In fact, besides grounding me in facts and reality, it gives me a huge advantage as an entrepreneur, to be able to see possibilities people don’t.
> I am asking genuinely, without implying anything and/or being sarcastic:
Now you’ve written:
> Sure. Does that justify it being the best option for every development task? This is what I am puzzled by.
Your strawman hyperbole leads me to believe that your line of questioning is not genuine.