I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.

For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I’ve also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.

Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.

So, some of the reasons why I personally love Rust:

• Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
• Rust’s syntax is elegant. It’s not as elegant as Haskell, but it’s a lot more elegant than any C-based language.
• Rust is (mostly) type safe. There are (nearly) no implicit conversions.
• Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
  • This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
• The memory management model of Rust (“borrow checker”) makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn’t match them, development will become an uphill battle against the borrow checker.
• Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
• Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it’s needed, using virtual function tables.
• Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
  • This, together with the borrow checker, ensures that there are (nearly) no “weird bugs”. Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference (“oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it’s undefined behaviour”), that almost never happens in Rust.
• Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
• Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)

The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.

This brings us to the downsides. Rust isn’t perfect. Far from it, actually. Here are some of the things that aren’t great about Rust.

• No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the async keyword in the language itself.
• Unsafe Rust is hard. In my opinion even harder than C++, because of Rust’s aliasing rules. Unlike C++, Rust doesn’t allow mutable memory aliasing. That’s because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
  • Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it’s hard, and I’d generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
• Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.

However, the upsides clearly outweigh the downsides imho.

tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.

It seems I misunderstood something important here. I’d take that as proof that Unsafe Rust is rarely needed. 😜 A quick test on the Playground shows that indeed, using raw pointers does not yield the wrong result, while using references does: https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=96f80d43d71a73018f23705d74b7e21d

Conclusion: Unsafe Rust is not as difficult as I thought.

Yes and No.

In the short term the answer is a clear “yes”, as it allows players to play nearly all Windows games on Linux without modifications, and game developers to ship their games on Linux without any extra costs.

In the long term it might have a bad effect on the market, as it further helps to cement Microsoft’s control over multimedia APIs, since game developers now have little incentive now to target anything other than DirectX…

In this case it’s a bit weird though, as the game lists Linux as supported platform, but obviously just ships the Windows build with Proton instead of having a native Linux build that uses open cross-platform APIs.

Just to add this: Star Control 2 is not only free (as in free beer), it is free (as in free speech). The open source project is hosted on SourceForge (yes, that still exists), and has a website that is worth checking out: https://sc2.sf.net/

My top answers are of course Kerbal Space Program, Dwarf Fortress and Stellaris.

However, all those have been mentioned already, so, to add something new to the list: Pathfinder: Kingmaker. It is currently my favourite cRPG.

Edit: Since you mentioned “Great Linux ports”: Kingmaker has a game-breaking bug in the Linux version regarding Gamepad input. However, as long as you play it with mouse and keyboard (as the gods intended - insert PC Master Race meme), the Linux version is working perfectly fine. However, if you plan on playing it on the Steam Deck, you might want to play the Windows build.

I’ll go with “less than 100 reviews”, as with “less than 1000” my list would get really, really long. This leaves two titles in my Steam Library which I think deserve way more attention than they got:

• ComPressure: It’s a Zachtronics-like game, where you build analogue and logic circuits using steam pipes and valves instead of wires and transistors. Its UI is a bit unwieldy, but the game itself is amazing, and it really is a shame that it hasn’t gotten more attention. Also, while there is a paid version on Steam, the game’s source code is available.
• Crown of Pain: It’s a match-3 with RPG elements. That’s basically all that is to it, but it’s a lot of fun.

There is a Wikipedia article about this: https://en.wikipedia.org/wiki/List_of_open-source_video_games

It is, however, vastly incomplete, as entries without “reliable sources” get deleted. Mind that linking the source code repository, the steam page, the license file and news about a game going open source are not enough to count as “reliable source”.

Technically I’m still playing “Vagrus - The Riven Realms”, but I didn’t play much lately, since I rediscovered my love for the Lean4 programming language and am now playing around with a formally validated heap again.

Xbox Series X/S.

It isn’t even particularly bad by itself, but compared to its predesessors (Xbox One and Xbox 360) the Xbox Series X/S gamepad is a clear step back when it comest to build quality (just try pressing the D-Pad buttons without thinking “this is cheaply made”), and that comparison is what makes me hate it.

And what adds insult to injury is that the quite expensive Elite version of the controller is just as cheaply built as the regular model…

Yep. With Kingmaker it was extra annoying, because the game has Steam Deck Verified rating, and the Steam Deck defaults to the Linux build.

Thing is, you can play through the whole first chapter of the game with a gamepad without issues… However, once you unlock the Kingdom Management screen, you run into the bug, which is a soft-lock once you open said screen. The UI doesn’t properly initialize, all text fields remain at their default value, and you cannot make any inputs any more. Luckily the ESC-Menu still works, so you can save your progress…

If it weren’t for the Steam Deck, I guess very few people would have run into this bug, if any at all. Kingmaker has a different UI if played with a gamepad, and even though Kingmaker’s gamepad-UI is done really well, it is clear that it is meant for playing the game on a TV screen (think: consoles). If you are sitting right in front of your screen (PC), the UI you see when playing with mouse and keyboard is superior in each and every aspect.