Takeaway message here: Beko support person does everything they can to recommend not buying from Beko.

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

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.

Acquisitions felt kinda cool when Microsoft was dishing them out like nobody’s business prior to the pandemic.

No, it did not. Consolidation usually is bad for employees and customers, and anyone who hasn't been living under a rock for the last 150 years has had plenty of opportunities to observe this.

Controversial opinion: There are only 2 kinds of people that think Rust will not become a widely used language:

• Those who don't bother to learn it, and only argue about it without any hands-on experience, and
• those who don't understand which niche Rust tries to fill.

For me it was funny, btw. I started out as basically a Rust fanboy, back when the "First Edition of The Rust Book" was still just called "The Book"...

Then I learned a bit of Haskell, and was immediately disappointed that Rust doesn't offer the same convenience when it comes to working with Traits (cough Higher Kinded Types cough). So, while I never considered myself part of the first group, I definitely was part of the second for some time.

However, the more I've been trying to abuse Rust for stuff that would be better done in a higher level language (like Haskell), the better I understood why Rust doesn't offer those abstractions: They often can't be zero-cost, and using them in a language that tries to be very explicit about performance costs becomes very verbose... In other words, I learned the hard way what "systems programming" means in the case of Rust, and which languages it competes with, and which it doesn't.

A geh, is doch iagendwie liab, oda?

Übahaupt, jetzt wo si Hochdeutsch imma mea duachsetzt, und vü junge Leit übahaupt nimma richtig östareichisch^1^ redn leanan, missn ma doch schaun, dass unsa Sproch net oafoch ausstiabt, oda?

Mia hom a a longe Tradition, wonns um Mundoatdichtung geht. Da Dichta von da obaöstareichischn Hymne zum Beispü, da Stelzhamer Franz, hot gonz vü in Mundoat gschribn.

Und weis ma grod eifoit: Es gibt a a eigene Wikipedia in unsam Dialekt: https://bar.wikipedia.org/ Oba do dua i ma söm schwah, dass i des vasteh. De is scho in da äagstn von de oagn Mundoatn gschribm.

(So, jetzt woas i net, wöcha Sproch i im Dropdown do untn auswöhn soid... Wei wirklich Deitsch is des jo net...)

[^1^] I am fully aware that the dialect I'm writing in is not called "Austrian". The two big dialects spoken in Austria are "Alemannic" and "Bavarian", and the one I'm writing is the Bavarian dialect. I'm only using the word "östareichisch" here, because that's what I expect most people to use in spoken conversation.

Even before Proton Valve was heavily invested in Linux gaming.

SteamOS has been around way longer than Proton, and the Steam Client had a native Linux version for such a long time, I don't even remember when it was published. Also, the Steam Linux Runtime is something worth mentioning - it is a common base that game developers can target instead of the various different distributions.

If you want your module to contain submodules, it needs to go into a folder. That folder needs to be named like the module.

It's explained pretty well in the book, imho: https://doc.rust-lang.org/stable/book/ch07-02-defining-modules-to-control-scope-and-privacy.html

So, for your example, the file structure could for instance be
src/main.rs
src/separate_file1.rs
src/separate_file1/separate_file2.rs

An alternative layout that I think is more common would be
src/main.rs
src/separate_file1/mod.rs
src/separate_file1/separate_file2.rs

Or, if you think separate_file2 could contain submodules at some point, maybe
src/main.rs
src/separate_file1/mod.rs
src/separate_file1/separate_file2/mod.rs

Relevant xkcd: https://xkcd.com/1356/

Some games, like the Pathfinder games by Owlcat, use that initial input to determine if you are playing with mouse/keyboard or a gamepad. Depending on that, you get presented with a different UI in the main menu.

Another reason for such a screen could also be Xbox support. Nowadays it's no longer necessary, because user-handling has been vastly improved with the GDK, but before the GDK was released a splash screen was the most user-friendly way to do user-handling in a single-player or online-multiplayer game on Xbox.

As a gamedev: Early Access was useful for devs, back when it was real Early Access. Think: Kerbal Space Program (the first, not the second).

Nowadays it's mostly a marketing tool, that allows to generate the hype for launch twice... Publishers and players expect "Early Access" games to be feature complete and polished before the "Early Access" launch...

I'd also suggest a Steam Deck, but for a different reason. My experiences with switchable graphics (both, nVidia and AMD) have been extremely disappointing. It's quite frustrating to spend €1500 on a gaming laptop, and then constantly facing driver issues, tearing,...

If I were to buy a laptop, I'd therefore also go with an AMD integrated graphics unit, and no switchable graphics. Performance would be comparably bad, but at least an integrated (non-switchable) card works... And now we are at the point of having a dedicated gaming device like the Deck, which lets you have both: A performant enough gaming device, and a laptop that isn't burdened by the price and issues of switchable graphics.