No solution, but I have a similar issue with the higher crate.

There the /prelude/src/lib.rs file lets rust-analyzer lose its mind and allocate gigabytes upon gigabytes of memory, even though the file compiles just fine and nearly instantaneous…

I think this has something to do with recursive macros. Doesn’t iced also have such? I have faint memories of a column! macro?

• cargo install is for installing rust programs for your user, not for adding dependencies to your Rust project. Many cargo subcommands can be installed this way, for instance cargo bloat.
• The file you are talking about is called Cargo.toml, because it is the file you need to write in order to configure cargo for your Rust project. TOML is the name of the file format. For details, please see the introductory chapter to Cargo in the Rust book.
• Cargo recently got a new subcommand called cargo add, which allows to add dependencies directly on the command line. However, all it does is to add/edit/remove the respective lines in Cargo.toml. (Personal opinion: I have found it way easier to just edit the file directly than to learn yet another command…)

That said: You still need to edit the Cargo.toml file, even if you solely use cargo add to manage your dependencies. That’s because that file contains a lot more information about your project than just the dependencies. For instance the current version, the feature-flags, your name, a link to the public repo,…

I haven’t done much Rust coding this year yet, mainly because I am trying to learn Lean4 and spent the last couple of months writing a (partially) formally validated (but not very fast) Binary Heap in Lean4.

However, a few days ago I had an inspiration at night, that brought me back to my Rust spare time project: The visual novel engine I had started last year.

For now I only did a relatively small change, but it’s one that will save me a lot of time (and nerves) later on. I am using a Free Monad based embedded Domain Specific Language for writing the game logic. The change now was to wrap that Free Monad in a State Monad Transformer, which I use to store the game state in.

This idea seems to be working surprisingly well, and that has given me enough motivation to return to this project and to keep developing it further for now.

Long and boring explanation with way too much detail:

Sorry for going on a tangent, but there is a Rust-specific detail that makes this cool beyond the usual advantages of using a State Monad Transformer, and I cannot stop myself from sharing.

For composing a large Free Monad, do-notation is more or less a must-have. However, do-notation in Rust only works well with types that implement Copy. If you want to use any other type in do-notation, you can only access variables of it in the following two lines. An attempt to access the data later will lead to an ownership problem (explained here). I have tried to overcome this by adding additional syntax to do-notation, but that is a crutch at best.

So, this is where the State Monad Transformer comes in. It side-steps this problem by moving the state out of the do-notation block into the Free Monad’s Pure-nodes. That way it is readily available via the State Monad Transformer’s get()/put() functions, and the “use within two lines” limitation is not a big issue any more, as one can always get the value on one line, do something with it in the next line, and write the result back on the second line.

Me neither. I only (have to) use Windows at work, all my own PCs have been running Linux for decades…

I do know however, that WSL emulates most (but not all) Linux syscalls, so you can ran (nearly) all Linux programs on Windows - including WINE. There is also a driver in Mesa so that you can render 3D graphics from within WSL on any DX12 graphics card.

They will likely write their own emulator, but don’t forget about WSL. You can already run WINE on Windows, I wouldn’t be surprised if you could also run FEX+WINE on Windows for ARM.

by intercepting syscalls and executing them directly

Not only syscalls. FEX and Box64 also allow using native libraries instead of emulating them. That leaves basically only the game logic to be emulated.

Yep. The big question is if the gap will close enough that ARM chips indeed end up delivering better power efficiency with emulation than an AMD64 chip that delivers the same performance without emulation.

My bets would be on the native AMD64 chip ending up more power efficient. To be honest, I would not bet too much money though.

ARM based Deck would be a huge improvement to battery life. Don’t get your hopes up too high. You will need an emulation layer like FEX of Box64, and unlike WINE those do have quite a substantial overhead.

It is impressive how far those emulators have come, especially since they got the option to use native libraries instead of emulated ones, but the game logic itself will always need emulation…

This doesn’t mean it can’t be done, it just means that the ARM CPU needs to be pretty fast to counter the emulation overhead, and that’s why I have my doubts about the energy efficiency…

(Btw: I have tried running several AMD64 games on my A311D powered MNT Reform laptop with Box64. It’s impressive how well the emulation runs, and how many games are actually playable already. However, I also encountered a lot of games that don’t reach enjoyable FPS on that hardware. With a faster ARM chip though…)

This. There is very little need for third-party tools, as long as you don’t want to install a whole lot of games. After all, the installation process only happens once per game, and also without tools it doesn’t take very long.

As a step-by-step guide:

• Download the games from the GoG website. You can find them if you hover the site’s header bar, where your user-name is displayed. There’s a “Games” button which brings you to the list of games, where you can download the installers directly. The downloads are listed under “Download Offline Backup Game Installers”.
• Unpack the game installer.
  • Innoextract is your friend here. No need to run the installer, just unpack the files. Works with both, Windows and Linux games.
  • Alternatively, if it’s a native Linux game, you can just run the installer directly on the Steam Deck.
    • For Windows games you can theoretically also use Proton directly on the deck. However, the process is annoying, so I won’t go into details.
  • Alternatively, you can run the installer on your desktop PC and copy the files to the Deck via sftp.
• Add the game to Steam Library. This can be done in Desktop Mode. There’s a menu entry in Steam’s “Games” menu for that.
  • In the File Browser, you need to disable the file filter, as it (iirc) only shows .desktop files by default. You’ll want the game’s executable though.
• If it’s a Windows game, go to the game’s properties page in Steam, and force a specific compatibility tool for it, namely some recent version of Proton.
  • For native Linux games this step is usually not needed, but some very old games need to set the Steam Linux Runtime here.
  • For DOS games, check out my blog post about DOSBox on the Deck.
    • I don’t know how well it works on the Deck (never tried it, as I don’t feel it’s necessary), but there would also be boxtron.
• Last, but not least, use sgdboop to set some artwork.

I would be very surprised if they wouldn’t fix all 50 filesystems.

In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.

Behind all the negative tone there is a valid concern though.

If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.

This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?

I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.

I only use my Steam Deck while I am away from my gaming (Linux-)PC. The reasons for this are that for me a big screen wins compared to the small (and relatively low-res) display of the Steam Deck, and also the games I usually play play way better with mouse and keyboard than with gamepad input… Also, the Steam Deck is relatively heavy, so gaming in bed or stuff like that also isn’t that enjoyable…

That said, the Steam Deck absolutely shines in situations where I cannot access my gaming PC. I usually take it with me when I go for a longer train ride, and also brought it along for vacation.

Compatibility wise I am in the situation that all the games I ever tried are working on the Steam Deck, but that’s mostly because I have been using Linux exclusively for decades, and have made it a habit to check if a game is going to work before buying it. Though, in recent years that habit slightly changed, thanks to the work Valve has put into WINE development. While back when I switched to Linux most Windows games would not run via WINE, nowadays one can expect that almost all games do. It is still a good idea to check protondb first, of course. Also, there are still a few games that need tinkering to get them to run, and protondb usually has some info on how to do that.

One negative point I have to mention is battery runtime. It strongly depends on what one is playing, but very demanding 3D games can drain the battery in 1.5 hours. However, I am talking about the old LCD model here, the newer OLED models run longer with one charge (though I don’t know how long actually).

Another negative is the display resolution. Most games don’t mind running on 1280x800, but some do. This can lead to illegible text, broken UI, or, as is the case with Stellaris, a different UI that is less convenient to use.

And last, but not least, performance. The Steam Deck GPU is just enough for the built-in display’s resolution, and also only under the assumption that games are reasonably optimized. I have not yet been in the situation that I would have gotten unplayable FPS, but I have heard a lot about games only running with 20 FPS, and needing upscaling… So, basically don’t expect it to run Crysis (yes, I know that joke is old, and that the Steam Deck can run Crysis just fine).

No. Or rather, not yet. Valve has not released SteamOS 3 for anything other than the Steam Deck, but is planning to do so at some point in the future.

I honestly wouldn’t recommend SteamOS for anything other than a dedicated gaming device though. It excels at its use case of launching games via Steam, but for everything else it is quite cumbersome… I would much rather install a general purpose Linux distribution and run Steam on it.

I would rather trust GamingOnLinux here:

While it is not in any way officially supported by Valve, they have now released Windows drivers for the newer Steam Deck OLED model.

(emphasis mine)

Points that I would gladly agree upon - but it seems the Wikipedia authors don’t.

I am not knowledgeable enough to draw a definite line what counts as functional and what doesn’t - so I chose to go with whatever Wikipedia says… Even though I dislike it.

I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.

Truth has been spoken.

Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,…). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven’t checked out Lean4, I can recommend it, great fun).

(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)

And for it to be a worthwhile saving in low memory or storage situations, further constraints need to be met too. For instance, you would need to compile your own standard library, or go fully no-std…

To answer your question: I use an Xbox Series X gamepad. However I cannot recommend this cheaply built piece of junk.

I also tried to use the DualShock 4, but with that I had the problem that it interfered with my WIFI connection. I’m not sure if this is a general problem, or only happens with my WIFI base station though. Also, the DualShock controller has a severe drawback, and that is its short battery runtime, compared with the issue that you cannot easily switch batteries…

So, my recommendation: An Xbox One gamepad. While I don’t own one, I am using them regularly at work, and they basically have all the advantages of the Xbox Series X gamepads, and have a way better build quality.

I would also recommend Xbox 360 gamepads, but they need a dedicated base station, which is very expensive.