Unreal is 20+ years of C++; not happening.
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: https://www.youtube.com/watch?v=VSlBâŚ&index=17&t=0s
[TABLE=âalign: center, border: 1, cellpadding: 1, width: 500â]
C++
Rust
Overloading
Traits
Templates
Traits
Concepts
Traits
Virtual Functions
Trait Objects
Virtual Concepts
Trait Objects
Variants
Enums
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 Crate.io. 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.
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: https://youtube.com/watch?v=YnWhqhNdYyk
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 
C++ 20 modules are more interesting to me than compilation times 
I only referred to the most frequently mentioned problems:
What are these problems arising from? Because you have a multitude of interconnected classes and itâs simply hard to remember who owns what and how long they exists. Raw pointers dont provide any information about ownership, even worse if the ownership is blurred, because it is managed by GC âfrom the back seatâ.
Seg faults/dangling pointers/mem leaks are not a problem if you use smart pointers, because you clearly see which resource is shared/unique or can be null(weak).
I am not against Rust at all, but I do not see any positives of introducing it, if there is still a mess âunder the hoodâ and any work going beyond the âmainstreamâ framework forces me to mentally go back to the '90s.
How many pointers does C++ even have now? There is a normal/raw, shared, auto, weak, and smart pointer? Why is it that for anything you do in C++ you need to pull a 1000 pages sized book out of a shelve? Iâm afraid thatâs the part where C++ isnât only toughed badly, but is just badly designed in its own very nature.
Rust got only one pointer and itâs a safe language. C++ still isnât exactly a âsafeâ language. Yeah, I know, you can also make a game with assembly language. And you can make it âsafeâ, too. And you maybe donât need a 1000 pages sized book, but 1000 years instead. Still Iâm not going to battle with a dull sword unless I have no other choice. Chop, chop, now. Not later.
So, C++ ainât a productivity king either because of this. While Rust is as fast as C++ while being virtually as productive as C#. Though, for the record, Rust always feels at least a half a notch more low level than C# since Rust always uses pointers and never a GC. You donât do dereferencing in C# really.
Well, bottom line, if C++ wonât get any simpler for doing the same, or actually even less, than at some point when MS and other companies created enough jobs, C++ may get its death sentence. Because schools wonât put up with a language thatâs hard/confusing to teach either, nor new programmers.
Although itâs only 9 years old. Rust is having an effect on other languages. Like its editions system. That said, I think C++ got modules now only because of Rust. 
You get used to the name. But I would have called it Mozilla. Yes, Rust is made by Mozilla.
Now imagine a terrified Japanese uttering(maybe Ken Watanabe from the 2014 Godzilla movie): To restore balance, Mozilla must face Cong++. Let them fight!
IMHO it would be a more productive conversation if you would exaggerate so much. You donât a 1000 pages book to write a game with Unreal C++.
Thereâs a raw pointer in C++ and Unreal brings its smart pointer - in 4 flavors, all quite similar in usage. Usually, weak pointer needed in the gameplay logic. Using itâs straightforward.
Rust is quite an interesting language and I would try at home just for sake trying something new if time would allow.
Although I keep hearing from other programmers that Rust is more focused on safety than performance, ensuring ownership of objects. It seems tailored for web-related things, but still didnât any convincing explanation why need it so much for video games? I mean, UE4 provides what I need and itâs good enough. It could be a bit different to talk about writing a new engine from scratch and Iâm curious about Rust-based engines
Whatâs wrong with GC? I mean, it just works for me in UE4. Why I should need another language without it? Why isnât just another fad? Itâs not sarcasm, Iâm honestly curious.
People would have to learn both Rust and C++ - since latter itâs not going anywhere, the engine wouldnât be magically rewritten to Rust. Itâs exactly the same issue with every language which wouldnât be a scripting language designed to be something between Unreal C++ and blueprints.
The Rust language itself ainât tailored really for any kind of specific domain, itâs a system language. However, it had to start somewhere, and itâs Mozilla who makes Rust, so since they are already in the web field, they started there by rewriting internals for the Fire Fox browser in Rust. Some ditched their old languages and rewrote in Rust to gain massive performance boosts and smaller memory foot prints.
And regarding performance, itâs only safe rust that may be slower than C++. You can write anytime anywhere inside safe Rust code so called unsafe blocks/functions for performance critical parts if needed. Itâs very hard to pin point the performance loss. it really depends on the performance intensive code, but the worst number I saw was 15% in safe Rust.
A small price to pay for a clean, maintainable, and very stable code base that allows the programmers to be productive. Time is money these days more than ever. Thatâs the edge you get with Rust over C++ as Rust gives move than just the language itself. Itâs the Cargo/Crate system, the documentation, and code formatting system. Itâs this kind of consistency, wholeness, that make companies eventually choose Rust in addition to it safe and clean code. Plus, plus(see what I did here?), itâs simpler to teach to new employees.
Oh, and 15% compared to a 100FPS C++ code, doesnât translate to 15FPS loss in Rust. Itâs less than 15FPS. Hence a small price to pay. And safe Rust is always faster than managed code C#/F# in general.
Yeah, I know, it depends on your project. But, yeah, managed code has come a long way and got a ton of performance improvements. There are C# written game engines, Space Engineer is one of them, itâs not that bad. But heck, I got a Ryzen 7 3700x 16 threads, and the GC hiccups are just there. Only Unity games can get away with it, because itâs only the game logic that is written in C#, and Unity/UE games tend to be simple. Seems Cities Skyline had to use native code even with Unity.
Anyways, Rust isnât meant to compete with C/C++, it is mean to replace it. However, it can compete with C# in my opinion. C#, or any managed code in general, looses FPS even with the boundary transition between managed/native alone. Epic Games pointed that out, and they are not happy about that. Itâs sub optimal obviously. Yet, Rust is to my opinion only half a notch âharderâ than C#. Yet virtually comes with the performance of C/C++.
MS made C#, and itâs part of VS, Eventually MS will add Rust to VS, too. Thatâs the perfect ground for competing. MS is already working Rust/WinRT just like it does on C#/WinRT. Except, Rust is still not Dot Net based, which may be off putting to some, but in general thatâs better because even with cross platform .Net you got the closed platform smell of MS all over it. Unlike with Rust that is cross platform just like C/C++ and many of its APIs.
For game logic only, itâs more like learning Rust and C#, not C++. If UE supported Rust it still would support C++ of course. And Unity devs absolutely wouldnât care about learning C++.
With game logic you actually can get away with not learning C/C++ much easier these days, than with say, trying to make a game engine.
Trying to make the UE community except Rust is a notch likelier than Unity devs. Because Unity already got C#. Yes, many actually want F# because C# is messy to work with, but anywaysâŚ
It depends on the type of engine, but for 3D itâs not pretty. Rust will suffer like Linux if MS doesnât help out with APIs. But Rust/WinRT is on the way and is made by MS itself.
Donât hold your breath on that present moment fact. There are translation tools already for some languages. There could be a translator in the future for Rust. This may largely erase C/C++'s ability to hide behind its established domain any longer to maker infinite excuses for being crap as a language itself.
I prefer Rust over C/C++ obviously. But I wouldnât want to be a Rust language dev. Iâm constantly wondering why Rust lang devs even really try. Because although C/C++ may evolve very slowly, at some point when Rust hunts it down, and it does already, and then C/C++ would evolve faster trying to defend its domain. And it does. So, maybe itâs those translators that is Mozillaâs Atomic Breath to beat Cong++.
Adding Rust now, can start a transition to an UE version that is fully written in Rust by letting dev learning and getting used to it now.
If Rust has it role in Firefox ârebootâ some time age and Firefox cut memory usage to 1/3 less than Chrome⌠it gains some respect now
Well, 15% lost on the language itself and even just 10 fps lost? Itâs huge and unacceptable.
Maybe if it would allow for some multithreading code written easier to get some performance back, then it could be interesting. With next-gen consoles better utilization of high CPU core count would be very appreciated.
Great point!
Although even a simple Unity game could suffer from bad performance, no way to manage memory. I heart that Unity being entirely rewritten to ECS itâs more about optimizing memory management with C# projects (and large chunks of the engine itself) than solving issues with OOP specifically.
In this light, Rust actually sounds tasty in comparison to C# which simply âcostsâ too much for its simplicity
When I wrote âa small price to payâ, I actually quoted somebody. I just didnât say so because I canât find the source now. But if I recall it was a AAA dev testing out Rust, and it was also more engine related and nightmare grade bugs that delay projects and cost major project issues. AnywaysâŚ
Also I didnât say game logic, so to clarify, because when I use metrics like âFPSâ it sounds like a game. The scenario I was thinking of would be pure software code, no hardware acceleration. If you make an actual game engine with game logic written in Rust. You would have a ton of graphics code running on the GPU, not CPU. It would be way smaller than 10FPS loss in real world. With code that doesnât show GC issues because of their small size, those small size codes you wouldnât notice any FPS drop compared to C++, I think.
Disclaimer, Iâm still learning Rust. Thinks can be worse, but also better. Iâm not a web expert at all either, but I noticed benchmarks that show Rust competing with C++ code speed wise: https://www.techempower.com/benchmarâŚh&test=fortune
Notice how in the linked benchmarks above there is C++ code that canât even got faster than Java and C#⌠clearly those source codes need better algorithms⌠having to bother less about the language short comings of C++, could give more time on algorithm speed ups.
I havenât tried it yet, but it should be simpler. Rust is a safe language. That mans itâs also thread safe.