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 ■■■■ 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.
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.
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.
IMHO Rust is a 1000x better than C#; but FII still presents a whole lot of challenges if one is willing to integrate with Unreal because of the many custom types that only exist in Unreal and are built using the many tricks C++ provides. Translating these types to Rust and back, I don’t think would be easy.
Yeah, that’s the problem with having a bazillion languages on this planet, at some point I just loose count and track.
The only thing that I know about Swift is that it was also feature suggestion on the old page for Unity. But F# was leading. As a matter of fact, aside of the black UI skin, F# was quite on the top of the most asked features. Swift was lagging behind a lot last I checked a long time ago until Unity took its page down for stupid reasons.
I’m currently working on my custom game engine in Rust, to learn Rust, and maybe to keep the engine if I shouldn’t go for UE/Unity/Godot.
Thing is that a lot is changing. I’m not sure when it’s the right time for making Rust bindings for UE4. For all we know UE5 could support Rust out of the Box. We may need to wait until 2021.
Rust managed to convince MS to adopt it. MS made it clear that they don’t view C++ as a valid choice for safe code anymore.
MS makes a COM binding generator for Rust and Rust/WinRT already. Dot Net 5 will be merging with Dot Net Core soonish. According to MS this merge is the reason why they make C#/WinRT by lifting the Dot Net Library out of the compiler/run time, and keep Windows exclusive features separated as WinRT. Looks like WinRT is the future. All of Windows 10 SDK may get deprecated and replaced with “language projections” for WinRT. So, there is C++/WinRT, C#/WinRT, and Rust/WinRT. Rust in its WinRT is safe idiomatic Rust code unlike the bindings on crate.io.
According to one Github user, XInput will get deprecated like Direct Input already is for a long time. Instead we will use a non UWP bound feature in WinRT under name space Game.Input or something. With 2021, also Visual Studio and actually Rust Edition 2021 should come soon if Rust sticks to their 3 year release period, and VS to its 2 year period. There is already some plugin for VS Rust. This is that kind of working environment that UE5 would require for adopting a new language. Jet Brains also supports Rust.
I’m afraid, personally, I would be far more inclined to stick with my own custom engine all together, if MS finally brought more DX features to WinRT, like DX Ultimate. Well, actual DX11/12 in the first place… Maybe only DX Ultimate will come to WinRT as their new OS Windows 10X, and Office Ultimate pave the way for their unification of their empire at long last so that it could last for 1000 years.
If I understand you correctly. You are saying that you don’t want to learn yet another language? Well, welcome to the club, nobody wants to learn yet another language.
However, in my case, it’s C++ that is the yet another language. I have learned already C, C#, F#, and of course now Rust(In progress). Also it’s 2020 and not 1997, C++ isn’t that dominated anymore at all, not even in the game industry, and certainly not for game logic. Nobody really can predict the winner of this race, but my money is on Rust. All of it. Because the worst case is only to have to make my own engine instead.
If UE5 can’t do it, and I’m not here for UE4, because the latter ■■■■ still got an editor that can break your entire project just by moving around assets. Yeah, I actually managed to break a template project already just recently… However, editor extensions are written in C++, too. Or Python now? Yet another language for that what Unity can use C# for all. Or in my case, with my own engine I just could use Rust for all.
Anyways, there is actually one big flaw with Rust, at least if you want to use it with UE4/5. Rust doesn’t have hot reload yet, at least not officially. But, if the Rust lang devs are serious, and according to their Are We Game Yet web page, they are having their eyes on gaming, too. There could be such a feature for it soonish. It’s Rust’s design philosophy to be one packages for all your needs, hence the Cargo, documentation, and formatting systems. They made surveys already, they know how to prioritize regarding game dev.
Rust has a fine foreign function API, and has pretty reasonable interoperability with C/C++.
Thus, you could write your own Rust binding, and it would probably be pretty good, once you started out with the unreal reflection tools and made them bind the UCLASS() and friends to a Rust FFI.
its not just that i dont want to leanr another , it shtat if its already based on C++ and your adding a layer over it that cant be efficient as in emulation , it cant be faster better and safer either your adding more vectors for attack, and more chances of some bug that leads to exploits or crashes
the fact is KISS means you got C++ unless they rewrite the engine from scratch in rust. then its differant story and while ya learn if it has a blue print system some stuff can then still get done
First of all, Epic already said that there is going to be another language. It’s just the question of which one. They don’t want to make such a decision lightly. So, the argument of the bug issues introduced by the bindings is out of the way. You will have them with any language.
Obviously my personal choice would be Rust. Rust is a good middle ground between safe and fast. Virtually this: Rust = C/C++ + C# + F#
Secondly, Rust is native, so regarding interface speed it certainly beats any managed code or interpreted language like C#/F#/Python/Lua, etc. Obviously regarding run time speed it’s faster than them, too.
The only issue I see is that Rust needs to be learned. C# for instance, a ton of people already know it, especially Unity devs to whom Epic may want to appeal with UE5. And to make things worse, Rust is indeed a notch harder to use than C#, it’s still a native code/system language and not the typical managed code. You have to handle the pointers, because although in safe code Rust there won’t be issues during run time, there will be issues during compile time. Yes, Rust is very famous for its very user friendly compiler that is quite informative with is suggestions to fix its errors and warnings. New comers like me would know…
I’m afraid that there is zero doubt that C# is the community favorite. And because of that eventually will make it into UE5, and not Rust.
For sure the business side of Epic is probably screaming go with C#, because it will definitely grab attention from Unity devs. But what about Sweeney’s original critique here (C# in UE4 will never be Unity componentized C#)… Meantime Epic acquired the SkookumScript team, who might be working on something great and innovative. Plus there were some vague hints about building a middle-ware layer / interface that could possibly allow any kind of scripting to hook into the engine. So its so tricky to call…
I think WebAssembly is an excellent addition to Rust.
I’m not a web guy. Seems it may chance though. Because I like to make small tools for myself once in a while. I just finished Rusty Savings that computes from my bank account’s transactions how much money I didn’t spend for a month, so how much I “saved” for that month and the entire year. I’m not under the impression that a managed code language could write those 206 lines of code much faster.
Of course one doesn’t need a system language for such non performance driven tasks, but doing it with another language gets you to have to learn yet another language, and worse, you may have to learn yet another set of APIs, too, a huge waste of time. Side note, F# can use ALL C# code/bindings just like that since it also supports OOP and .Net. But unlike F#, not even Rust is that lucky with C. Because Rust is safe by default, while C isn’t. You may have to create safe wrappers yourself.
Anyways, I never thought that managed code could outlive its usefulness. And now try to do the same thing with C/C++. You will get slowed down not by one notch, but by at least two, writing the same code.
WebAssembly seems to be another step towards making the programming world more universal by allowing it to run compiled binaries from virtually any language. If you game’s GUI is solid enough. You can use it not only for the game itself, and the usual tooling/editor or even game launcher task, but also your web site, so forum, so everything else. This is another case where sticking to one language gives you benefits. You won’t have to make bindings either or give up on an API. And with Rust no matter how small, or how big the code is, or how fasts it needs to be, with Rust you can write it all with a descent production speed and quality.
At least that’s my opinion judged by what I could learn from my Rusty Savings tool and the current game engine that I write to also learn Rust in the first place.