Rust for UE ?

I’m not familiar either, but I think Rust has a “Box” (it’s literally called box) mechanism which you can use to collect C data such as complex structs and then manipulate them within an unsafe block.
I think it can also share pointer addresses with C code, but I’m not sure how that works either.

Their docs have this example, calling C function from Rust side:

extern "C" {
​​​​​​ fn abs(input: i32) -> i32;

fn main() {
    unsafe {
        println!("Absolute value of -3 according to C: {}", abs(-3));

Box is just used for managing the ownership of heap allocated data, I don’t think it’s required here (not sure how trait objects would work here, if at all).

Btw, I’ve found something very useful I didn’t know existed:

I would reconsider UE4/5 over Unity if it had Rust. Especially since Unity may never support Rust. While I could live with C#, it’s not as ideal for games as Rust because of its GC.

The thing with Rust is that it is intended to replace C/C++ in the entire industry altogether, not just in game development. And it is getting very close to that goal.

It’s voted 4 times(if I recall) in a row as the Github favorite.

It is almost as accessible as C# but as fast as C/C++.

It’s even as a “system language” a safe language. No seg faults, no dangling pointers, no nulls, no headers, and it got safe threads. Data Oriented design over the OOP non-sense.

It’s eventually going to be fully embraced by Microsoft. According to them, C/C++ is not a valid choice anymore. 70% of their security flaws could have been avoided with Rust. Security may not be an issue with games, at least offline games, but when Microsoft makes the final move to fully embrace it. Rust obviously will come to Visual Studio and the entire MS ecosystem, including DirectX. A COM Rust binding generator is already in the works by MS.

As somebody who comes from C -> C# -> F#. I got zero regrets so far with Rust. I’m still amazed that a “system language” could be designed in such an accessible way, almost as if it was something like managed code C#/F#.

As somebody who follows not too closely, bot close enough the evolution of AI these days. And witnessed the super human genius of AI. It wouldn’t come as a surprise to me if somebody like MS could come up with a AI based translator that can convert full C/C++ code to idiomatic Rust. No need to waste time on mere bindings for UE. Convert the entire engine.

For all we know UE5 could be already on a road map for such a full conversion to Rust. Like I said, Rust is meant to replace C/C++ not just to compete with it as yet another language. And so far the signs show that it does a very good job at it. Not to mention that such a converter would be a huge use outside of MS as well. There is certainly need for that.

1 Like

Unreal is 20+ years of C++; not happening.

Divisive topic, but I’m not sure I’d expect anything that innovative from Microsoft…
Its more like Facebook or Google etc would work on something in that area imo.

Interesting, I’d like to learn more, as I had thought Rust still had C++ level of complexity.
When coding with complex languages, its best to keep the problem simple - if possible.
But in game dev the API is rarely simple and neither is the problem, that’s the problem!

Ah, yes, Rust … another in a long line of languages created to replace C++. Who remembers Vala, D, Limbo, …

I’m still learning Rust myself. But in general it’s less complex compared with C++ and OOP. Though, for the record, aside C#/F#, I know way more about C than C++.

Rust is more like C, plus functional programming and polymorphism via interfaces called “traits”. When I first saw Rust I actually confused it with MS’s F#. Both are derived from ML and OCaml, etc, too. But to be clear for those who don’t know yet, rust is native code, not managed. It’s a “system language” used for anything really, game engines, embedded, and even operating systems.

All variables are immutable by default. There are no classes in Rust. You only get structs and enums. And enums can hold data. No headers.

Yes, you can define methods/member functions even with structs. Every “implementation” lets you define a bunch of methods for a struct as if it was a class. “Trait” definitions are like interfaces, and define method signatures that can be shared across structs implementations.

Yeah, it looks like the best of OOP but without the worst of OOP like inheritance. Class types may not be the worst, but they are totally useless as Rust proves it that mere structs work, too, when you “separate data from behavior”. Yes, you can do a more data oriented approach in C++, too, but Rust does that naturally.

Some say that C++ got a bad reputation not because it is so bad, but because new programmers abuse it that bad. Shows that C++ is more complex than Rust out of the box while doing the same thing. Rust wouldn’t allow you to do any other way.

And of course we use pointers as usual, but they are checked at compile time with the “borrow checker” that defines boundaries and memory owner ship that can at run time be auto freed when out of scope. It’s like a GC, but it’s at compile time GC, which makes Rust virtually as fast as C++ without the GC hiccups at run time that you can find in C#/F# yet still being at the same memory safety levels as managed code languages.

Coupled with immutable values you get thread safety, but no undefined behavior, no dangling pointers, no seg faults, no buffer overflows, no memory leaks, etc. There are no nulls in Rust. So no run time exceptions because of that either. All this is the stuff of nightmares in C/C++ no matter how hard you try or skilled you are.

But, you can still go “C” in Rust with the “unsafe” keyword code block/functions that can be inside normal Rust code anywhere. Though, it’s C when you use C APIs. Otherwise unsafe code is used to do very low, and specific hardware programming, or just some performance optimizations that allow you to use pointers in exotic ways but without the compiler throwing an error that would prevent your project form successfully building.

There are other features, too. You won’t find silly C like:

for (int i; i < 100; i++)

Instead you do this.

Rust uses also “functional programming” paradigms, but that’s not really new to C++ either. I just mention it because there is value in FP if done on a middle ground level. F# may go a bit overboard with FP. Even the signatures in F# are “->” math like single parameters that can make you wonder what the heck when you miss one parameter and the entire signatures changes as the compiler tries to infer the type. F# got the monad in its own way. And fanctors. So, F# got a bit too much of FP if you ask me. I’d rather use Rust that is more C like. But heck, F# is a very clean language. It’s just too bad that it’s also managed code like C#.

But for the record regarding managed code performance. The game Space Engineer was written fully in C#. It’s not too bad, but I’m not under the impression that Rust is much harder than C#. So, why bother with C#? I see people using C/C++ for GUI, let that sink in…

Well, ideally it should have been C/C++ that should have evolved this much, and they do evolve but so slow that it always allowed yet another language to spawn in the first place.

C++ got rid off the headers only now. And it’s still an unsafe language.

Rust got “editions”. Current is 2018, seems Rust can introduce breaking features much faster than other languages because of that. Internally it got three intermediate layers. Any binary compiled in 2015 edition can mix with 2018 and so on.

The IDE can be shallow for Rust. I use CLion with a Rust plugin, but the IDE support got better. And currently there is a lot of push for IDE support because soonish VS 2021 may be here. And the Rust language team clearly understands that it needs the support of MS because it ain’t just about the language itself. It’s also about jobs, so programmers having access to that language on a professional basis. MS got a lot of jobs internally. So, this isn’t just about VS supporting Rust either. I don’t even user VS, I use CLion.

The video below compares C++ vs Rust on Polymorphism. It’s a bit older though, it doesn’t include C++ 20.

In short, Rust is more compact and more accessible:…&index=17&t=0s

[TABLE=“align: center, border: 1, cellpadding: 1, width: 500”]





Virtual Functions
Trait Objects

Virtual Concepts
Trait Objects


C++98, C++03, C++11, C++14, C++17, C++20, C++23, C++26, …
C++ is constantly evolving, and the best of all: backwards compability.

Someone once said:

Why Rust will never replace C++? Because Rust doesn’t provide us with a slow and adaptive transition, like C -> C++.

And so, Rust will have the same fate as every other pretender.

Rust does provide an adaptive transition. Rust is very compatible with C. It’s just C++ that may need extra work (it always does, doesn’t it?). And not everything is written in C++.

Many crucial MS APIs like DirectX are under the COM interface that are language neutral. DirectX is owned by MS.

Yeah, it’s currently uncertain who is going to make Rust bindings for DirectX, whether it be MS or the Rust community again, but the COM Rust bindings generator is currently made by MS. We will know once VS 2021 is out in preview, and MS made their final choice to embrace Rust. With a giant like MS behind Rust, Rust won’t go back into its corner that fast if at all. And of course that’s important for those who already chose Rust already, too.

“We are the Rust language. Lower your shields and surrender your code. We will add your jobs and technological distinctiveness to our own. Your culture will adapt to service us. Resistance is futile!”
– At Microsoft Build 2021

Jokes aside, if Rust can’t dethrone C/C++, then no language ever will. Which is fine if it manages to evolve fast enough, but the race is on.

I’m not aware that there ever was a bigger threat to C/C++ than the Rust language. One subjective view tells me that there are a large amount of Rust presentations I came across. The more actual fact that gives that away is its 4 years long streak in being the most loved language on Github and the large code base on Add a thousand Rust jobs at MS with DirectX bindings and the Rust written game engines will be coming ringing in. Yes, there are DX bindings in the Winapi Crate already, but they are incomplete and handwritten.

I can’t tell how many companies are behind D, Limbo, Vala etc, but Rust got many of production grade users.

There has to be a more security-focused language shift at some point imo.
This may not affect non-mission-critical applications like game engines etc.


The godfather behind C++ still sees some weaknesses / room to improve.
Some of it is about simplifying programming approaches (last paragraph).
Complexity is the enemy of simplicity & absence of simplicity leaves holes.

It actually may to a large extend.

It’s just that normally a language may not be so obviously superior to another. It may be up to subjective debate whether specific features are better or worse. And all you get is a syntax war in the forums defending their religion or reasonability though, trying to avoid having to learn yet another language.

However… we are not comparing C# vs F# here. We are comparing C/C++ with Rust, both are system languages a.k.a. native code languages, but one of them isn’t a safe language.
We are not comparing the lack of a semicolon in F# vs the bracket kingdom of C#. And that’s not giving enough credit to what F# brings to the table. Just my opinion, anyways.

But we talk about: Unsafe threads, seg faults, null exceptions, dangling pointers, memory leaks, etc. That kind of stuff of nightmares that is more than just syntax inconveniences, and can be avoided fully just by switching languages.

Regarding stability Rust certainly adds a massive ton to the code. With Rust you get a measurable increase in stability. That’s why MS is willing to invest a ton of money and bring Rust to their ecosystem instead of hiring better C/C++ programmers that could have avoided their “70%” of security issues. That’s not a trivial task for a company as big as MS, it ain’t done out of shear fun. And the security issues are driven by the safety issues of C/C++, it’s an unsafe language. It’s that simple in the end.

It’s like arguing that native code is faster than managed code, uhm, duh? Rust is faster than F# in general, and especially in real time applications.
Yes, Rust is a safe language. No, C/C++ isn’t a safe language. So Rust will deliver stability out of the box while C/C++ won’t.

It’s just companies like MS who got security issues to deal with that can get into the millions/billions when exploited by a hacker. That are the first to point out that C/C++ lacks safety and needs to improve or risk getting replaced by another language that is safe. Like Rust.

But to be clear. The security issues are driven by the lack of safe code, so how C/C++ handles, or rather doesn’t handle its pointers. What ever crimes C/C++ may have committed with its syntax, or bloat, the biggest issue is safety even for non security critical applications. Getting a seg fault, undefined behaviors, memory leaks, etc, ain’t “stability” it’s a waste of productive time because you are using an inferior language.

Like I said before. It would have been obviously way more ideal for C/C++ to evolve instead. But it seems that it just does so too slowly. Otherwise MS would have waited for a better version instead of considering to ditch C/C++ all together in favor of Rust and spending a ton of money and effort on reforming their giant empire.

First of all there is no C/C++ language. Quick example: VLA is legal in C, but illegal in C++. This is the main reason why C++ is being hatred. Because it is taught as “C with classes.”

I highly recommend this video:

In modern C++ we have smart pointers and RAII. Using raw pointers (with raw new/delete) is antipattern. UE4 use raw pointers heavily.
In modern C++ we avoid macros because we have type safe constexpr and templates. UE4 uses macros heavily, UObject cannot be templated.
In modern C++ we prefer composition over inheritance and generic programming. UE4 is “inheritance-everywhere”
In modern C++ raw loops can be replaced with range-for or even better with algorithms/std::ranges.
C++20 introduce modules, so headers can gone.

OOP generally isnt bad, its simply misunderstood. Like Alan Key, considered as a father of OOP says:
“I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.”

As you can see, these are not problems of the language itself, but flaws of UE4 codebase. Introducing a new language will not make them magically disappear.

So, to what extend is modern C++ as safe language? Rust is 100% safe. Well, maybe make it a 99%…

And for the record, since you mentioned how UE4 is written in the first place. WinRT is also written in a object oriented way. It got Win32, so C in it, too. However, unlike C++/WinRT, Rust/WinRT is still 100% safe according to MS no matter what the actual underneath code is. The same with C# for Unity. Unity isn’t written in C#, but C++. Any gameplay code written still will fully or at least mostly draw from the advantages of the language that it was written in.

Any Rust game logic will be safe by default unless written in unsafe code blocks provided that the bindings are also safe and not raw bindings going directly into C++ code via C.

When I was messing around Rustlang I noticed the compiler was considerably slower than c++ compiler.
I don’t know how it is today, but there I was already thinking “-imagine this thing compiling a big project like a Unreal game, would be pain”.

If crates are more malleable now would be cool to see some experiments, but my experience those days wasn’t great.
Btw, c++ is already too slow to compile Unreal projects… Rust could be worse.

Rust compilers are slow for the same reason that C++ compilers are slow when using tons of templates. Type inference is a guided combinatorial graph search, which just takes time.
(Other “beneficiaries” of this include languages like Swift, and Haskell.)
You can write Rust that compiles faster, by making the types simpler, just like you can make C++ that compiles faster by making it look more like C. (FWIW, Unreal Engine C++ looks more like C than like modern C++, and this is probably good for the needs of the engine.)

I’m afraid I’m not well informed about the slow compile time issues, I only heard of them. I have a Ryzen 7 with 16 threads so I’m not the first who will feel this.

For what it’s worth. Rust is only 9 years old. While C/C++ are almost half a century old. C is 48, C++ is 35. Even F# is older than Rust with its 15 years. So, there is a ton of optimization that when into C/C++ compilers and run times. Rust can only get better at this point.

And depending how you use C++, the compile times also can get worse because of how modern languages aim to do more during their compile times in general these days.

I noticed it first with F# that the designers talked about wanting a very static and strong typed language because of the compile time advantages that they can gain from it. Like less bug prone code that shows its self only during run time. That’s the reason why there is no Null type a.k.a. the Billion Dollar mistake in Rust/F# for starters.

Only 9 years and it’s already rusty.

Actually, there’s also a lot of things cannot be optimized/changed in the language to keep it compatible with the past code. Actually I feel there are a lot of optimizations in the compiler to make a program run faster or safer, not necessarily faster compilation times. But this irrelevant to me, with modern CPU it’s possible to compile UE4 (nearly 3 million lines of code) in 15 minutes or less. What was most annoying: UHT running on a single thread and often taking a minute to complete its task. Thank God, it’s fixed :slight_smile:

C++ 20 modules are more interesting to me than compilation times :wink: