It's a fun Rust thing. People stand up websites to expose a high level view of Rust's ability to fit the needs of a given field and to inspire and encourage faster work.
The FAQ I wrote answers the question - "What does this website show that perf.rust-lang.org doesn't?"
- 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.
To be very pedantic: Brazil's currency is "Real", plural "Reais". There was around a century ago an older Brazilian currency also called "Real", but with plural "Réis".
I didn't even connect the domain to game development at all until I followed the link. I interpreted "game" as slang, as in "are we ready for the big time yet?"
I'll sponsor anyone on Github working on Rust blend shapes and morph targets in Bevy or Fyrox. Email me.
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.
Honest question, if the only thing missing from being on equal footing with UE is a highly specific 3d mesh manipulation, why is there a question as to whether Rust can do GUIs and games in general. Are you operating on a completely proprietary stack or am I missing something about your comment?
A bit off-topic, but is there a list of these “Are We X Yet?” sites? I think I've seen at least five by now, and most of them were somehow Mozilla- and Rust-related, but are there others?
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/
Apart from Rust's Mozilla heritage, there's no link between most of the rust based are we X yet sites and Mozilla. Mozilla doesn't operate the sites, neither do the Rust team, nor is the Rust team part of Mozilla for several years now.
The original was "arewefastyet", to track benchmarks of SpiderMonkey against V8 and JSC. It spread like wildfire and became a bit of an inside joke in Mozilla.
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.
I'm currently tinkering with Bevy, and while the experience is mostly positive, I sometimes miss the at-a-glance insight only an UI can bring. There's a few plugins that can be added to add a UI-ish inspection functionality to Bevy apps, but it's miles away from a proper UI.
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:
First impressions matter and the fact that so many Rust crates are pre-1.0.0 is hindering Rust adoption in game projects that tend to be multi-year efforts. Game devs need stable APIs to develop against.
Well, doesn't pre-1.0.0 indicate that the engine is not stable in itself? No reason to provide stable APIs or a post-1.0.0 if you know there is a lot of changes to be done.
That is true but most of the top Rust crates are still pre-1.0.0. That is not normal for a language that came out in 2015. The async-await story has been in stable since 2019 so they can't use that as an excuse.
It's a weird social phenomenon, but many 0.x crates are actually quite stable, some of them are pillars of the ecosystem at this point. I don't know the exact threshold where people are deciding to make the leap to 1.0, but it's different from what you might expect
Functionally, a lot of 0.x bumps end up just being x.0 bumps
This is to me just a post-semver and pre-semver language culture decision. Many of these crates would be on version 7 or whatever had they been developed in the early-mid 2010s, but these days people have higher expectations of complete compatibility between 1.x versions compared to projects in say Python or Ruby when those languages were 7 years old which were happy enough that 1.8 was "compatible enough" with 1.7.
Some pre-1.0.0 crates will probably forever stay there because every time a widely adopted crate "breaks" SemVer (not code breaks, just version bump) it leads to huge annoyance - suddenly many crates no longer can interop with each other and now, those crates need to update version in non-compatible manner and that leads to even more breakage.
Many have a stable API that hasn't changed in forever and are rock solid, but never reached 1.0.0
Rust and C# is not that different after all. You're gonna have to fight with some more aggressive compile checks than what you're used to, but otherwise it should be relatively smooth sailing.
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.
C# is classic object-oriented, while Rust skips polymorphism. It takes a while to grasp how to properly design using traits with no polymorphism. The transition is far from simple. I happen to like Rust's choice, a lot, but it is a very different approach.
I was thinking more about the syntax in general. Maybe I'm over-simplifying because most of my time is spent working with Clojure, but Rust and C# syntax is to me very similar to each other (together with most C-like languages). But I agree, programming patterns are different enough to make it harder to make the jump I guess.
Syntax is the easiest thing to pick up about a new programming language. Semantics, idioms, etc take far more time, and in that sense, C# and Rust are very different.
Technically traits are polymorphism (and you could argue Rust's enums are too), they just look differently than in classically object-oriented languages
What Rust really skips is inheritance (although you can get partway there with trait dependencies), which I think is generally a good thing
Specifically Rust doesn't have implementation inheritance. The fact that [u8; N] and Vec<String> are both IntoIter doesn't imply they are somehow inheriting any common elements of their implementation, just that they both provide means to convert themselves into Iterators when needed.
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.
I don't think "smart" is the right way of framing this, but there is a lot to learn.
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.
I don't know if you have to be smarter. There's just some patterns you'll probably have to unlearn.
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.
I don't think you need to be smarter, but coming from something like C#, there are some different ways of thinking that you'll need to learn. In addition to the memory management stuff, there are a number of things borrowed from the ML language family. Since you mention docs and syntax, those are more likely the things tripping you up.
You're probably capable of understanding these things, but there is a definite learning curve.
> Question: does one have to be more smart to learn and build stuff in rust than one has to be for something like C#?
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.
I agree with sibling that "smart" isn't a helpful way to frame these sorts of things
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
What's the situation with running Rust on consoles nowadays? Last I heard it was a non-starter for Playstation development, because Sony decrees which compilers you're allowed to use and they hadn't blessed rustc yet. Even if you did the legwork to add a Playstation target to Rust, using it would be grounds for failing certification.
Usually, console development comes with heavy NDAs, which makes it really hard to do any sort of FOSS development for such targets. Bit sad. It's like you have to write a game successful on PC before you could reach out to Sony/Microsoft/Nintendo and then get access to a SDK. And whatever integration code you write, you cannot publish for others.
The trouble with Sony (if what I've heard down the grapevine is accurate) is that even if you privately fork Rust and roll your own integration without breaking the terms of the NDA, or acquire such a fork from someone else who is also under NDA, they still won't let you ship with it.
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:
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).
As someone who has spent years doing game development work, I can say it's a very labor significant mistake to use anything other than C++. You could even use C, but you will end up needing to interface with C++ at some point, so at the least you'll want to write in C and use a C++ compiler for when you need things like GLM, etc.
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++.
This is what separates most humans from robots right?: The fact that I can say something without using the pedantic technical definition and for a human with normal intelligence to still know what I'm talking about.
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.
You think this is the case, but with specific implementations, new libraries aren't coming out every month or even every year.
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.
As far as physics engines go: Jolt currently seems to kinda disrupt the decades-long equilibrium, at least as far as I'm aware from my corner of the wood. I wouldn't be surprised if the physics engine landscape looks very different in 5 years compared to 5 years ago:
I wouldn't mind it being written in C++ if it had an official C API (so that it's easier to use the library from other languages than C++), but somehow physics engines are like UI frameworks, OOP seems to be more popular there than elsewhere ;)
(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 exactly what I do at Planimeter, where we use primarily ANSI C and convert compilation units to C++ when we need to interface with existing solutions.
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++.
C++ limited it's growth. I think the rate of growth for libraries in rust will be more diverse and faster.
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.
Don't get me wrong: C++ sucks. But as far as Rust goes you are way too optimistic. In the context of game development, Rust suffers from a lot of the same problems as C++. Features like fast build times and debuggability actually matter there. It's not memory safety why game dev people are starting to get fed up with C++, it's the slow build times and feature creep of modern C++. In those areas, Rust looks even worse than C++.
I tend to agree for a very specific niche of game development: AAA games. But for everything else (e.g. mobile and indie games), C# usage most likely dwarfs C++ just because Unity is so much more popular than any other engine in those specific 'niches', and there are a lot more mobile and indie games than AAA games.
In the end it's all about engines and libraries, and engines usually dictate the language.
And Godot 4 is coming up as a significant player. Either GDScript or Python or any related interfaces (Swift?) could be the next big language for game development.
> Godot 4 having two first class languages is such an odd paradigm.
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.
> If you're doing scientific computing, use Python and C++.
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.
I know a few people doing MCU firmware with Rust. I doubt it will be anywhere near as mature as the C ecosystems anytime soon, but it's come a long way. See e.g. the "cortex_m" crate and some of its reverse dependencies [1] [2].
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!
I think it would be fairer to say: "Then WINE happened and Valve build things on top of WINE and now I can ..."
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.
I am asking genuinely, without implying anything and/or being sarcastic: why is the HN community so obsessed with Rust? It seems to show up on every programming-related thread and most times mentioned as a Swiss knife of a language, suitable for every task, from UI to firmware development - a departure from the more traditional view of certain languages being best for certain tasks.
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.
Same reason they all hate blockchain and smart contracts, or many still believe that AI will be a net good for the world.
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.
You're likely getting downvoted because there is a comment like this on every Rust-related thread and people are tired of it.
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.
If that was the only premise ("C-like performance, etc.") then I can understand. What I don't is that there seems to be no use case for which Rust isn't good. That is the part that bothers me.
I'm a big fan of Rust, but I have to admit its up-front development costs are not always worth the trouble.
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.
It isn't fast (really as far as you can get from "zero cost abstractions") but you can have Rusty enums via sum types in Python, and a poor man's match expression. It's not even that bad, really. With Pylance (or possibly mypy, haven't tried) the experience of writing typed Python is quite good.
> the experience of writing typed Python is quite good.
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.)
I think there's a lot of it based in the fact that Rust was born at Mozilla and we want to see a modern language succeed that isn't tied to one of the big tech companies.
> ...then I can understand. What I don't is that there seems to be no use case for which Rust isn't good.
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".
> there seems to be no use case for which Rust isn't good
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.
Rust is a genuinely interesting language but I think part of the problem is that a lot of the posts about it lately are just not. There's been a string of "we did generic boring thing everyone has been doing for a decade+ BUT IN RUST!!!!" articles lately that are not helping to dissuade the "cult vibes"
This link, for example, is... Boring? Like why is it here? What's to discuss? Should we just link to the PIP repository, too?
Posts like this are for people interested in using Rust. It's advertising expanded functionality and access to more use cases. There are enough of those people on this site that it makes it to the front page. If you do not fall into the above class of people, then yes, this doesn't look interesting.
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.
You can write games in C++ (Unreal Engine), C# (Unity and Godot), Java (LWJGL, as seen in Minecraft), Python (using PyGame), JavaScript (DOM/canvas or something fancier). Nobody is using PyGame for anything serious, and Minecraft is probably the only serious Java game, but you can still play around with those.
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?
As far as I know, Unity uses C# as scripting language and does the heavy lifting in C++. And the usual way for making mobile builds for Unity games is converting everything to C++ with IL2CPP and then compiling that to native binary.
As far as I know, web browsers use JavaScript as a scripting language and do the heavy lifting in C++.
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#.
I’ve been working for 4 years in Rust codebases, the first 2 years were at Facebook. So from my point of view there’s a good chance I will continue to work with Rust for a very long time.
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.
If adoption is below what one thinks is appropriate then one can take it upon herself to argue for it. So that it gains the kind of adoption that one thinks it deserves.
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.)
123 comments
[ 4.8 ms ] story [ 187 ms ] threadThe name and domain are generic enough that I imagine most visits are "What is this?"
- https://areweasyncyet.rs/
- https://www.areweguiyet.com/
- https://areweideyet.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$"
1 https://en.wikipedia.org/wiki/Rio_Grande_do_Sul
My cultural bias is showing.
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.
https://wiki.mozilla.org/Areweyet
For rust
https://github.com/UgurcanAkkok/AreWeRustYet
https://github.com/UgurcanAkkok/AreWeRustYet
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/
https://arewewaylandyet.com/
https://arewep2pyet.com/
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_...
Functionally, a lot of 0.x bumps end up just being x.0 bumps
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/
Many have a stable API that hasn't changed in forever and are rock solid, but never reached 1.0.0
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?
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.
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.
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.
You're probably capable of understanding these things, but there is a definite learning curve.
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.
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
* <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).
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++.
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.
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.
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.
https://github.com/jrouwe/JoltPhysics
(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++.
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.
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.
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.
So, if your ambitions are for shipping mobile apps, Unity is probably the engine for you, that's their biggest audience.
It's Kotlin these days (your point still stands).
I've been trying to (lazily) make games for years. It's hard.
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.
[1] https://docs.rust-embedded.org/cortex-m-quickstart/cortex_m_...
[2] https://lib.rs/crates/cortex-m/rev
- 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.
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.
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.
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.
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.
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.)
There are plenty of such cases and those raised constantly here and comment threads even slightly related to Rust.
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".
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 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.
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.
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#.
> 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.
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.
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.)
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.