Rust programming language?

[ebola]

(not sure if this is the right subforum..)
So, serious graphics programming centres on C++ (plus shaders obviously);

Is anyone here interested in the potential of Rust? Its' shaping up really nicely IMO, although I can see why people have doubts.. C++ is a complex language to master, its understandable that (i)after such a personal investment people might not want to move away from it - and that (ii) people are skeptical that its feasible to replace the work on the language ecosystem.(IDE tools..)
But, rust leverages so much of that with an LLVM backend. Context Free Grammar & clean macros should lead to better tools in future.

In my case, I was unambiguously happy with the jump from ASM to C, but C++ has always been a double edge sword.. more that i like than dislike obviously- I have used it for years - but enough to I dislike that I went on a quest that ended up with me following the progress of Rust with great interest.
I have never really liked the whole mindset of classes.. I find them artificial. I prefer to seperate code & data. (Polymorphism itself, I like that.). I have never trusted garbage collection , so i looked on with envy at features in GC based languages - seemed a shame I had no choice until now.

the features I personally like.. the slightly more functional 'flavour' (even though its still multi-paradigm); aliasing rules (no need for 'restrict')stemming from its pointer-safety.. no header files - that might sound trivial but these really do annoy the hell out of me.
And having tasted enum/match I want to keep all that.. its' also pretty interesting they way generics & vtables are related through traits.

Some call it 'C meets haskell' but I think its more accurate to say its a 'cleaned up C++1y'

Its probably going to polarise.. I've heard people reject it out of hand because they dont like writing 'fn' or ":" before types, or they dont like "the random symbols".. but if safe pointers are supposed to be used predominantly, they deserve symbols rather than being bolt-ons IMO.

 

[Dominik D]

I tried Rust for several tiny experiments and as much as I wanted to love it, its type system was a dealbreaker fro me. It's powerful, yes, it's expressive, yes, it covers all the bases, yes. But it's insanely complex too.

http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/

 

[oeLangOetan]

I tried Rust for several tiny experiments and as much as I wanted to love it, its type system was a dealbreaker fro me. It's powerful, yes, it's expressive, yes, it covers all the bases, yes. But it's insanely complex too.

http://cosmic.mearie.org/2014/01/periodic-table-of-rust-types/

Most of this is just pretty syntax for unique_pointer and shared_pointer.
The rust typesystem is actually a lot simpler than C++.

 

[Rodéric]

Sounded interesting but I found http://chapel.cray.com is both easier to read/write and more powerful...
But YMMV.

 

[Dominik D]

Most of this is just pretty syntax for unique_pointer and shared_pointer.
The rust typesystem is actually a lot simpler than C++.

Which is precisely why I tend to write either in C or C# (depending on what I want to achieve).

 

[ebola]

"just" pretty syntax for unique_ptr ... but with extra compile time safety, and more solid concept of immutability... avoiding the need for restrict.

heh. well I guess its going to polarize people.

I'm really enjoying it - its' the liberation from C++ that I've been waiting for , i think.
perhaps its just something in my personality - impatience, intolerance for "dotting i's and crossing t's" .. header files just annoy the hell out of me.

could just be that after using C++ for *so* long something fresh is "refreshing".

 

[gwahorton]

I don't know enough about Rust to criticise it, but are actors its only tool for concurrency? Tim Sweeney, like language theorist Peter van Roy, seems to think transactional memory's also essential for games (and Intel's new Transactional Synchronization Extensions should finally make it fast). It might be handy to have dataflow programming via single-assignment variables or E-style vats too, to keep concurrency declarative where possible.

Sweeney, whose 2006 POPL presentation is still very interesting, coauthored a (hardcore type theory paper) last year, so it looks like he's still working on this stuff.

 

[gwahorton]

OK, so Rust does have dataflow programming via sync::Future.

 

[Cyan]

it is a great language, and it looks like one, but it turns out it's not well suited for games despite its performance, 'cos of refactorization times, unlike C++ or C# -Unity, Godot..., etc-.

Leaving Rust gamedev after 3 years​

 

[Dominik D]

The counterargument to that is that refactoring is pretty safe. If it builds, you're probably at the state similar to one before refactoring. But author is right that writing Rust actually mandates a lot of refactoring at various point. It's because you can't just "wing it" like you'd do in C/C++ and then live with tech debt. Whether this is the price you want to pay obviously depends on the use case.

A lot of the complaints in that blog post are not really Rust-imposed. Generalized systems aren't instrumental for fun gameplay, regardless of language used. ECS solves certain problems for certain people. I think that by now it's fairly clear to most people that ECS works when you have a lot of something and need to actuate it on a tight budget. Most of the gameplay doesn't map that well to ECS. It was probably a mistake for bevy to go all in on ECS but it's neither here nor there now.

It's also very much true that a lot of use cases that Rust could be great for - gamedev being one such example - aren't mature enough (or as author puts it: live on hype). This is also true for gui, another valid complaint from the post. And yeah, hot reload is important and underappreciated.

People who use Rust in "correct" use cases typically don't spend a lot of time online evangelizing. There are a lot of great tools built in Rust: package managers, CLI tools, automation, OS code. So there's a significant discrepancy between use cases people should be advocating for vs. what is talked about online. The armchair expert community did some damage to Rust too - "have you considered rewriting it in rust" is a meme at this point. But some projects did - fish shell for instance - and it was the right call for them.

One thing I found eyeopening reading through the fish rewrite PR and blogs is that one of the reasons they switched to Rust (switched again even: they previously switched from C to C++) was to attract contributors. There are very few people excited to contribute to a C++ project and it's much easier to find community when you develop something in Rust. They did see a spike in contributions mid- and post-rewrite so they may be onto something. If your OSS project needs community, Rust might be the answer. This is also why there are quite a few undercooked game engines in Rust.

 

[digitalwanderer]

For the ignorant here like me what is "tech debt"? Performance hit due to under optimizing?

 

[pcchen]

For the ignorant here like me what is "tech debt"? Performance hit due to under optimizing?

"Tech debt" generally means some decisions that was made because of time/resource/market constraints instead of technical merits.

 

[digitalwanderer]

Thanks!

 

[Dominik D]

Just to be clear - there's a 10 year gap between my old and recent posts in this thread and I've had the opportunity to not only write some (uninspiring) code in Rust but also work with people who use Rust full-time in a commercial context. It's extremely uneven what is and isn't well supported by Rust at this point. If you're depending on a crate (whatever that crate will be) there are three possible outcomes: 1) it's a mature piece of software and you'll be happy to use it, 2) it's very much in progress and it's implied that you should improve it and contribute your improvements back, 3) it works fine but clashes with some other dependencies that you've got (e.g. one crate requires nightly, another only works with stable).

The first case above is ideal and happens 25% of the time (absolutely unscientific number). The second case is pretty common if you want to do something that hasn't been done already in Rust and happens 50% of the time (ditto). The last one is PITA and invalidates a lot of great things about the Rust ecosystem. Cargo is a godsend but if I have to fork one library and patch it to work with nightly so that it doesn't collide with other dependencies I have - there's nothing cargo can do about it.

It is marginally better with C/C++ but only because I've dealt with the same type of problems in the C-ish ecosystem for years and I find it much easier to integrate libraries with clashing requirements in C++ than I do in Rust. But that's me. I worked with 20-somethings who don't come with the same baggage I carry and they found working around some of the Rust deficiencies much easier than they did in C++. And they are probably a much better measuring stick than I am.

There's also one thing I found really cool: one day, on a whim, I tried integrating Rust into an Xbox project. I was pleasantly surprised that things just worked. It helps that I wrote a piece of no-std code so I had literally zero dependencies, but I'm sure it wouldn't be much harder with the std. So in the gamedev context at least, using Rust is not an unreasonable proposition.

 

[tuna]

Cargo is a godsend but if I have to fork one library and patch it to work with nightly so that it doesn't collide with other dependencies I have - there's nothing cargo can do about it.

What is stopping you from just forking the library you want to use? Is it problematic because all the APIs "bubble up" and you might have to change a lot of code?

 

[Dominik D]

What is stopping you from just forking the library you want to use?

Nothing, except that I may not have the time or willingness to do it. Things like these come at a cost. If I want to whip out a dedicated console tool with "nice" UI and I have a day to do it, I may either invest in forking a crate or doing it in another language altogether.

For instance less than 2 years back I needed a simple console-based telemetry tool. My options were tui-rs or ratatui. One didn't have the controls I needed (so I'd have to write them) and the other clashed with another crate I had dependency on. It became clear I can't do what I want in Rust in the time I can spend on it. At the same time I could get the output I needed from some abandoned (but still functional) python package and my networking needs were met by a bunch of packages too. I'm pretty sure if I had more time I could get great results in Rust but that wasn't the reality in which I operated.

When you're writing code, especially in co-development or when you want to test something *right now* and can't play around for too long, you have to make tactical decisions like these all the time.

 

[tuna]

It became clear I can't do what I want in Rust in the time I can spend on it. At the same time I could get the output I needed from some abandoned (but still functional) python package and my networking needs were met by a bunch of packages too. I'm pretty sure if I had more time I could get great results in Rust but that wasn't the reality in which I operated.

If you have enough resources (memory, run-time etc) to run Python there is little point to using Rust. Normally you compare Rust to C and C++ and in some cases even Go.

 

[Dominik D]

If you have enough resources (memory, run-time etc) to run Python there is little point to using Rust. Normally you compare Rust to C and C++ and in some cases even Go.

Not everything is a game, not everything is about resources. One-off tools can be written in pretty much anything. What matters most is the fun you have creating them (and perspective of maintaining it).

 

[tuna]

Not everything is a game, not everything is about resources. One-off tools can be written in pretty much anything. What matters most is the fun you have creating them (and perspective of maintaining it).

If you are just going to throw together something in 2025 it is hard to imagine something more productive than Python.

 

[Dominik D]

If you are just going to throw together something in 2025 it is hard to imagine something more productive than Python.

Productivity is not just a function of language but also (I'd say primarily) familiarity with it. My Python is OK at best and there are definitely cases where I'd be able to produce some throw-away code in C, C#, or even Rust faster.