I am now at the point where I think there are two things happening.

• Actual technological progress.
• Marketing bullshit pushed by dazzlers.

Examples for the first one would be new battery tech for electric vehicles, new ways to harvest renewable energy, new tools that allow to make software more stable,... Examples for the second would be NTFs, Crypto-Currencies, "AI", e-Fuels,...

Revisionist? I am old, I was there. But if you don't believe me: https://en.wikipedia.org/wiki/Symbian

(And while I didn't own a Symbian phone myself, a good friend did. Oh, but what I owned was a tablet computer. Way back in 2002. And now you will likely call me a Revisionist again, because I owned a device before Apple invented it...)

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?

It's funny that you mention the iPhone - a device that had zero innovation compared to its competitors, and just managed to take the market because of marketing.

While Visual Novels are not my favourite genre, there are a few entries that I would like to highlight, because I enjoyed playing them quite a lot:

• Pyre: While it isn't marketed as Visual Novel, it pretty much is one. To be precise, it is a Visual Novel with sports-game elements. The world-building in this one is excellent, as is the art. The visuals alone would make this game worth playing, but there is also the soundtrack, and the gameplay of the sports events is pretty fun too. Oh, and the story. This game really requires tough choices. It's from the same studio that made Hades, Transistor and Bastion, and it shows.
• Griftlands: Again, not marketed as Visual Novel, despite very clearly being one. This one is a Visual Novel with card battles and deck-building. Just as with Pyre, the world-building in this one is outstanding. The card battles are well done. It's no Slay the Spire, but it's still pretty good. Also, it has some of the best jokes I have seen in games recently.
• Loren the Amazon Princess: Again a Visual Novel that is primarily marketed as something else - this time Role Playing Game. And to be honest, it has everything you would expect from an RPG: inventory management, character stats, JRPG-style turn-based battles, trading, a world map,... But it's still pretty much a Visual Novel with RPG elements. It has a massive scope for an indie game, and is overall pretty well done. To be blatantly honest, I played this mainly for the RPG parts, but the story isn't bad either, once one gets past the initial "I see your party has no rogue, mind if I join?" part. The setting is still being actively developed by the studio behind it, who have released several other visual novels (with and without RPG elements) set in the same world, with recurring characters.

Yes. That's why I was utterly confused when big companies dug out hat dead horse (yet) again.

And they are still trying to ride it.

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

It's not "either side". One "side" is making games, the other is screaming slurs.

You have Debian experience? Then stick to it. It may be boring, but boring is good. That means it doesn't need much maintenance, and that it just works.

They have done that already. It's called Kylin.

Yep. And the worst part is the Fear-of-Missing-Out when disabling them.

Like, there is nothing stopping you from just not doing the kingdom management mini-game, except that nagging feeling that you might actually miss out on some content...

Currently? Potionomics. I just wanted something that I can finish quickly, because of the upcoming release of House of Light, but now I am still not done with my play-through, so I kinda cannot start House of Light just yet.

But in a couple of days, as soon as I am done with Potionomics?

House of Light. And that for quite some time, I expect.

And the predecessor, Pathfinder: Kingmaker is amazing too.

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.

Oh, that just happened. We didn't have established processes for promotions for a very long time. The company was a tiny startup when I joined (quite literally in the cellar of the company founder's place), with a really flat hierarchy and no distinction in seniority.

At the point when the company started to set up a formal process for promotions, I had already been there for so long, that I was considered one of the most experienced people, and that's how I ended up being filed under "senior coders" in the employee list basically since that category existed... It also was a bit weird, as that happened to coincide with all the COVID lockdown chaos, and I never had a formal promotion talk, just an email with an amandment to my contract, which I didn't even read too carefully, so I didn't realize at first that this was not just the yearly pay increase 😉.

Oh, and believe me, the impostor syndrome is strong with me. I would not have promoted me to that role.

I am not in the position to decide which tech we use at the studio, however, as a Senior my voice is certainly heard when it comes to tech decisions.

And for Unity I can only say: No tech is worth the risk of dealing with such a shady company.

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.