soulsource

Who knew electing fascists would lead to fundamental freedoms being removed?

FIFY

I don't know that particular system, so I can't give any hardware-specific suggestions. However, it might be worth checking out the games that previously were included in Humble Mobile Bundles, especially the very first ones. Sorry, I don't have a nice to browse list, but this site seems usable enough: https://barter.vg/bundles/3/76/

That said, OpenTTD is available on F-Droid. That should keep you busy for a while 😉

Yes, it's pretty neat. Though I must confess that I stopped playing at some point and rather continued playing Hades instead.

Ubuntu was pretty good, until 2010 or so. People who still recommend it probably haven't used it in the last 10 years.

"PPA" is Ubuntu's branding for third party repositories. So, of course you will have a hard time adding a Ubuntu-specific third-party repository to anything that isn't the Ubuntu version it's made for...

Debian of course supports third party repos, just like Ubuntu. On Debian they just aren't called "PPA".

---

For more information on how to add third party repos to Debian (or Ubuntu, if you don't use Canonical's weird tooling), check out the Debian Wiki page on UseThirdParty or SourcesList. There's also an (incomplete) list of third party repositories on the wiki: Unofficial. And just like with PPAs, anyone can host a Debian repo.

Some cool SD verified games nobody mentioned yet:

• Hades
• Cult of the Lamb
• Potion Craft (really great gamepad support)
• Against the Storm (though the controls take a while to get used to)
• Griftlands
• Terraformers

I wouldn't call Monads a "language feature" of Rust.

There are some types in the standard library that have Monad properties (Option, Result, Vec,...), but there is no Monad trait that would allow to be generic over them.

There have been attempts to introduce such a trait, the most well known probably being the higher crate. However, even with that crate, it's not easy to work with Monads.

For instance, in the stable tool-chain, it's currently (to my knowledge) not possible to express a Free Monad without using macros. If you care for the details, I've written a blog post about my Adventures with Free Monads and higher. With the Nightly toolchain it is possible to write a generic Free Monad, by the way, thanks to non-lifetime-binders.

Other Monads, like State, Reader and Writer, are also challenging to implement in Rust. I did get them to work, however I failed to implement Applicative for them, so, while they are mathematically Monads, they do not have higher's Monad trait. Here a possible future improvement of non-lifetime-binders could help. Again, a blog post: Writer and State Monad in Rust, based on higher.

Oh, and last, but not least, do-notation in Rust is a bit inconvenient, because of lifetime rules and lambda captures. For instance, using non-copy types is messy. I've added explicit clone support to higher, but that's a crutch, and overly verbose.

It's basically what the Steam Deck does, and for a gaming device it makes a lot of sense. The vast majority of games will probably be installed to the user's home folder anyhow...

It might be that some games require additional libraries that don't come with the immutable base OS, but you can always install them in a custom folder (like, the game's install dir), or just install Steam and use the Steam Runtime for everything.

And, as you said, a lot of open source tools and games (DosBox for instance) are available as Flatpaks too.

Technically not free, but rather pay what you want. You can still grab the original version from the official website.

Iirc the Plus version was originally made because of consoles. The original game was very PC specific, as you needed to

Spoiler

touch the files in the game's install folder

to be able to complete it, and to find some otherwise hidden content. That's of course not possible on consoles...

I haven't played the Plus version, because I think that having an in-game

Spoiler

computer desktop

is a massive spoiler. Also, I think it changes the perspective a lot, as there's an intermediate layer in-between that you don't have if you

Spoiler

directly interact with the game, and have the game running on your own PC instead of a simulated interface.

But, as said, I haven't played it, so it might not actually feel as different to the original game than I fear it does.

After finishing my second playthrough of Loren the Amazon Princess, I've now started Tales of Aravorn: An Elven Marriage. And I must say, it is pretty good. From what I can tell up to now, I like Elven Marriage more than Loren, so it's a bit sad, that it didn't sell that well...

Apart from that I'm playing way too much Against the Storm. It's a pretty fun city builder rogue-like. Basically Settlers, but only the fun parts, with a bit of random challenges sprinkled in.

I also tried to play Albion (the DOS game) again, but I died in my second battle and hadn't saved from the beginning... 90s games were something different, when it comes to difficulty. I will definitely start over again soon, this time actually saving frequently.

There is also the y-combinator thread that discusses async as implemented in Rust compared to using Monads to represent async computations: https://news.ycombinator.com/item?id=17536441

The arguments that withoutboats presented in that thread convinced me that Rust's async is the better of these alternatives for a language like Rust.

Another thing that helped to convince me of that is that I tried playing around with Free Monads and the Writer and State Monad in Rust, and found them to be very un-ergonomic. Rust is very explicit about heap allocations, and when using basically any Monad that's more complex than Option/Result I found myself typing Rc::new() way more often than I would have liked... If you add do-notation to the mix, things get even more verbose (aka: annoying): https://github.com/bodil/higher/issues/6

So, yeah. Rust async isn't perfect, but it's probably better to have it than not.

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.