The magical part about Rust really is how accurately (compared to other languages) you know which little gear in the big machine is failing. Often you even know precisely why and how it is failing.
Precondition for this is of course that you really grok Rusts ownership and type system.
Of course you could still ignore it then, but the language made make this choice at every point consciously so it is totally your fault if it bites you later.
I e.g. tend to comment on unwraps why they cannot panic, and if they could (because I wanted to follow another strain of thought first, I use except and a message or writw a TODO comment.
Rust doesn't have the mature libraries that C# offers, but it isn't barren anymore either. It does offer nice assurances like entirely avoiding race conditions by default (when using safe Rust). Rust often leads to performant code, but it's hard to say if that's really a feature of the language or just a bias due to the kinds of people using it and the projects they work on.
If you're just looking to get into game development without any other goals in mind, then C# is a safer choice
It does make memory management much more explicit, which makes it at least easier to write performant code.
The question however is what your program is doing. If it's limited by network requests or something similar with high latency you won't be able to optimize much on the language side of performance.
If however you're processing a lot of strings, the safe borrowing mechanism can help you avoid most copying.
For example on my previous job we had a part of our CI build that would parse a huge text file and combine it with some information from an ELF's debug info in Perl. It took 45 mins for one execution. It was also impossible to read.
I rewrote it in F# which after some heavy optimization work worked through it in 2 mins.
I had just heard of Rust and rewrote it in Rust, basically transforming F# to Rust syntax and trying to eliminate as many copies as possible. Now the whole execution took 8s.
So at that point I was sold on Rust, however the library ecosystem was still lacking. Nowadays it's much better.
For what it is worth, I've had a very similar experience with the re-write of an internal tool in Rust.
I was in pure disbelief, running the next command in the toolchain this tool runs in, expecting it to fail on some empty input files but it worked. 20x speed-ups almost feel like some essential work must have been missed or skipped but when you realize that's not the case, it is a different kind of pleasure.
Doesn't it "just" prevent data races? I don't think it prevents all race conditions.
The most likely reason they chose to do it in Rust, though, is because they wanted to and no one else had.
I use C# (.NET) daily and I think it’s great for game development, but Rust certainly has its own advantages.
Remember that all of the 'hot' code is internal to Unity and is not written in C#. C# basically just takes on the role of a particularly powerful scripting language and isn't dealing with cleaning up huge amounts of data as would be the case for anything dealing with assets directly.
There are a couple of talks related to it.
a) Module system lowers the complexity overhead of using third-party libraries, which means you aren't tempted/required to reinvent as many wheels
b) Easy, reliable, monolithic build system, particularly for cross-platform builds
c) Ease of writing bug-resistant concurrent logic (my understanding is that concurrency doesn't get used much in games because it's so hard to get right)
Of course the above can mostly be said for C# too. But Rust could maybe be seen as the best of both (C++/C#) worlds
I would say its biggest disadvantage is simply that neither major engine uses it (officially). Unity and Unreal are so powerful at this point (and free for smaller projects!) that you're better off using them for nearly any game project, unless: a) you just feel like writing your engine from scratch for fun, b) you're doing something wildly novel, or c) you're a AAA studio that can afford to hand-roll an engine in order to save on licensing fees down the road. Maybe Rust will see adoption in category c one day, but there's a huge amount of institutional momentum to contend with.
The advantage vs some C# library is essentially the advantages of Rust over C#: precise control over memory layout and usage, no GC, higher performance, an ecosystem that was designed to be x-plat from the beginning instead of bolting that on after the fact.
C# also has all the C++ like mechanisms to do GC free allocation.
There is more "ceremony" involved with unsafe C# code, but things like Span<T> and Memory<T> have made high-perf code so much easier in many cases.
Still, so for something that's basically all highly performance sensitive, something like Rust would be a good choice (I don't actually use Rust yet, but am planning to learn).
> this is only a partial list of changes made to improve the GC itself, but that last bullet brings me to a topic of particular fascination for me, as it speaks to a lot of the work we’ve done in .NET in recent years. In this release, we’ve continued, and even accelerated, the process of porting native implementations in the coreclr runtime from C/C++ to instead be normal C# managed code in System.Private.Corelib. Such a move has a plethora of benefits, including making it much easier for us to share a single implementation across multiple runtimes (like coreclr and mono), and even making it easier for us to evolve API surface area, such as by reusing the same logic to handle both arrays and spans. But one thing that takes some folks by surprise is that such benefits also include performance, in multiple ways.
https://devblogs.microsoft.com/dotnet/performance-improvemen...
> In a community run benchmark of different gRPC server implementations, .NET gets the highest requests per second after Rust, and is just ahead of C++ and Go.
https://devblogs.microsoft.com/aspnet/grpc-performance-impro...
People think that a good language would make a good game, that's error #1. The ecosystem matters more than the language itself, basically using Rust is starting from scratch so you can't use all the good things that C++ / C# had for the last 15 years.
Edit: I want to clarify that I know that Rust is a good language, but as of now in 2021 it's just not ready for games, and there is no sign of change. It's fine to say "I can make games in Rust, it's going to be hard and painful but I can get something, but saying it's better than C# is definitly wrong.
That's trivially false.
> Last week, I released A Snake’s Tale on iOS, Android, Windows, Mac, and Linux.
> A Snake’s Tale was programmed entirely in Rust, and to the best of my knowledge, it is the first commercial game made in Rust to be released.
Dated 09 May 2017.
Time will tell.
https://unity3d.com/showcase/case-stories/squad-kerbal-space...
Secondly, there is the ongoing rewrite from C++ into HPC#.
Third, I still remember the days when Pascal, Basic and C compilers were deemed worthless for professional game engines, followed by similar remarks to C++, back when Abrash books were still hot of the press.
Finally, languages don't dictate how fun games are and how much they sell.
Yes, Unity uses C++ in the core engine, just like in the old days the first wave of games written in C were full of inline Assembly, while the first wave of Objective-C and C++ games were plain old C.
Yet the Switch has outsold the DS, and Unity powers more than 50% of the games sold on the platform.
C# 9 is at the same level as D and Nim, minus a couple of little things that could still be added. To the point that with .NET 5, Microsoft has started to rewrite the runtime in C#, whereas Unity is slowly porting the rendering pipeline into the HPC# subset.
So if they would decide to have Unity on D or Nim, compiled with the LLVM compilers, which kind of discussion would we be having, which compiler makes clever use of LLVM IR?
What do you mean? How does one reach D/Nim levels of performance (or did you mean expressivity) in C#? I'm experimenting with Nim for gamedev these days, I might be persuaded to take another look at C# depending on your answer.
Also, what is the HPC# subset? Any resources to read about that?
- use structs like in C
- do safe stack allocations for arrays
- use GC free heap allocations and map them to memory slices
- GC free code regions
- static lambdas
- machine numeric types
- static lambdas
- native function pointers
- native sized numeric types
- more control over structs layout and usage
- using available in any type that implements Dispose pattern even if the interface isn't adopted
- you can make use of Roslyn to ensure using is not forgotten
- unsafe and native pointers
- vector types for SIMD, NEON and AVX
- you can generate MSIL on the fly similarly to what C++/CLI compiler would have done. Naturally this trick requires unsafe Assemblies.
HPC# is a C# subset created by Unity with the long term roadmap goal to replace C++ on Unity. Although it looks like a C# subset and plain .NET types, there is a new compiler, Burst, that is aware of those special types.
There is also an ECS framework that goes alongside it, DOTS.
The founding members of the projects are ex Psygnosis employees well known in the C++ community.
https://docs.unity3d.com/Packages/[email protected]/manual...
https://youtube.com/playlist?list=PLX2vGYjWbI0QRLkvupULwSZCP...
The language is still pretty new but there is a lot of people investing in this. Embark studios and Ready at Dawn come to mind.
> People think that a good language would make a good game, that's error #1. The ecosystem matters more than the language itself, basically using Rust is starting from scratch so you can't use all the good things that C++ / C# had for the last 15 years.
It's not an error. Ecosystem matters but to a point. Like game engines are written with a particular type of game in mind. If your game doesn't fit the particular use case, it might make more sense to roll your own. Also, if you have been building your own game engines in C++, doing it in Rust should not be much of a problem.
edit: reply to one of the comments below regarding the argument Rust = good therefore great for gaming. This. Neither does a good engine. For me I stopped UE4 and went to Unity because of the sheer lack of documentation and community support behind C++ with UE4. C++ is a powerful language but man was it hard finding tutorials and documentation that was up to date.