Hacker News Reader

Comment by f430 | Hacker News Reader

what would be the advantage of this vs established libraries written in C#? any thing Rust offers that other languages don't? website is short on details, would be great if they could display its features. There are other MMORPG/MMO frameworks that are quite mature but this looks promising too.

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.

View on HN

Where Rust really shines compared to other languages IMO is when software grows beyond a certain scale. The way the language forces and encourages you to "do it properly" really prevents a lot of lazy decisions that would come back to haunt you later in unexpected ways.

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.

You can do it non-properly in Rust as well, e.g. using unwraps, etc. but even then it's still way better than an UB-ridden component of a C++ codebase.

Using `unwrap` is not something that can come back to bite you in a long term (other than API design wise). Replacing it is dead easy, as the compiler helps you. Also, you can replace it with a call to `expect` to give a relevant message too.

That's why I said it's way better. It's usage is still not considered good practice for most scenarios.

Those .unwrap() and .clone() calls make the points for optimization or improvement very obvious.

Sure you can create these situations in Rust as well, but it makes that choice very obvious. So instead of being like: Damn, there was a case that I didn't consider at all you usually are like That case I decided against handling before must be handled now.

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.

Likely a joy for Rust and a desire to try something ambitious that hasn't really been done.

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

>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.

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.

Trust in Rust.

> 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.

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.

> It does offer nice assurances like entirely avoiding race conditions by default (when using safe Rust).

Doesn't it "just" prevent data races? I don't think it prevents all race conditions.

You are correct, yes.

Data races is what I meant; good catch.

I'm not sure this is why they did it (I doubt it is), but reading through the documentation I saw that it's playable on Linux, Mac and Windows. I don't know when I've seen an MMO that's not browser based that was playable on all three platforms. C# engines usually ship to Windows and Mac - though, in saying that, I'm not sure if that's engine enforced or developer choice.

The most likely reason they chose to do it in Rust, though, is because they wanted to and no one else had.

BSD too!

Two Rust features stand out to me: no GC, and Rust’s excellent wasm support. In the Unity games I’ve played GC doesn’t seem to be much of an issue but your code is always going to be faster in Rust.

I use C# (.NET) daily and I think it’s great for game development, but Rust certainly has its own advantages.

> In the Unity games I’ve played GC doesn’t seem to be much of an issue

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.

Unity is rewriting their C++ code in the HPC# subset and Burst compiler toolchain.

There are a couple of talks related to it.

It's very easy for it to become an issue if a game was written in Unity though. It tends to be really sluggish. E.g. Disco Elysium (amazing game) but the load screens were too much.

I don't know why but performance issues have become very common in modern games. Lots of games fail to scale to significant multiplayer populations. I still remember playing San Andreas Multiplayer/Multi Theft Auto and Just Cause 2 Multiplayer. In all three the multiplayer support is provided by a third party mod and they still managed to scale to hundreds of players per server.

To add to what others have mentioned, relevant features that come to mind (when comparing with C++):

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.

It's a game not a framework unless I'm completely misreading their website.

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.

I bet there are more platforms supporting Unity and Unreal (which also has C# support) than Rust.

C# also has all the C++ like mechanisms to do GC free allocation.

I've written a lot of high-performance code in C#, and in general I like it. What's really great about C# is that you can write maintainable, idiomatic, managed C# (using the GC etc), that is actually very performant for many cases. The you can dip into unsafe code (unmanaged memory, pointers etc) just for the really performance critical parts where managed code isn't fast enough (e.g. if you need to write/manage a lot of buffers).

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).

Well, the .NET team is the opinion that C# is becoming good enough to start rewriting the runtime in C#, which they started doing in .NET 5, with enough benchmarks to show where they are now and what might still be done in the .NET 6 timeframe.

Zesterer (a dev) answered this in depth to another comment on this thread, ctrl-f for that name ;)

Alternatively, here is a link to the in-depth comment!

https://news.ycombinator.com/item?id=26038027

Rust has an interesting way of handling memory so that you don't need a GC. GCs can cause stutters in games.

You can do a full GC between loading levels, while using a little allocation as possible during a frame rendering.

Three is really no reason to have any time "between loading levels" these days, especially in an open world game.

From experience playing Veloren, it’s one of the least buggy alphas I’ve ever played, and it runs incredibly smoothly. Not sure if that can be attributed to language choice, but I thought it was pretty remarkable when trying it out.

Rust offers more performance. There are some big 3d games written in C#, but they have also suffered from performance issues.

C# performance is quite alright when people know how to use the language.

> 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...

The goal is making these libraries in Rust. Rust is fundamentally a better language for game development than C#.

0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

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.

> 0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

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.

https://michaelfairley.com/blog/i-made-a-game-in-rust/

I think the parent means like AAA games.

Moving the goalpost

As someone replied I was talking about AAA games indeed, everyone can make a game in any language with 50 reviews on the app store after 3years.

AAA games are coming, there's at least two studios public about their in-progress Rust work. And backchannel whispers that may or may not come to fruition with more.

Time will tell.

And another one left Rust behind.

That wasn’t an AAA studio.

Ok, thanks for the correction.

What AAA games exist in C#?

Kerbal Space Program, for one

https://unity3d.com/showcase/case-stories/squad-kerbal-space...

Isn't Unity itself written in C++?

Isn't Rust itself built with a C++ based compiler, and binding to 3D system libraries written in C and C++?

There's a pretty big difference here though. In the case of Unity, most of the very hot code is C++. With a custom Rust engine, most of it is Rust.

On modern engines most of the hot code are GPGPU shaders, specially on cards modern enough to support mesh shaders.

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.

Depends on how you define “c++ based compiler.” In the sense that it uses a library written in C++, yes, but “based” is kind of a stretch. It is an important one but not irreplaceable.

Yeah, I am splitting hairs on purpose, because at the end of the way winning benchmarks on the playground is meaningless on the business side.

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?

> C# 9 is at the same level as D and Nim

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?

As of .NET 5 and C# 9 (also applies partially to F# and VB) you can:

- 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/com.unity.burst@1.5/manual...

https://youtu.be/BpwvXkoFcp8

https://youtube.com/playlist?list=PLX2vGYjWbI0QRLkvupULwSZCP...

Gotta start somewhere.

Sounds to me like those things just need to be rewritten. Or is the plan to keeping using the same language and libraries for the next 60+ years?

If you ask UNIX clones developers....

> 0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

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.

If you're waiting for some AAA title to ship, you'll be waiting a while. Big studios aren't going to be first adopters and they have expensive commercial tools for building games already. That said there are a bunch of toy project Rust games you could say are complete or "shipped" and many more games under development. There's no reason to be pessimistic about its use in the space. https://itch.io/games/made-with-rust

Reply on news.ycombinator.com