The time to beat a game is generally for the main story if you don't take ages doing other things. Quite often with side quests or other non essential steps like collecting things or trying to 100% a game it will take way longer then the estimated time to complete. This is epically true for more open-world type of games with lots of places to explore.

Forced price matching could be considered a abuse of their position. If a dev cannot sell on another store for less (even if that platform takes a smaller cut) then that makes reduces the need for others to use a different platform to get a cheaper deal. Devs cannot use pricing to save you some money while drawing you to a platform that gives them a larger margin. All of which means that there is less incentive for valve to reduce their cut of the sale to be more competitive. This is what some lawsuits against valve are arguing ATM I believe.

That does not stop things from stealing your data.

From what I read somewhere one time they have had the implementations done for a while now. The only blocker was the HDMI fourm refusing to let them upstream the changes. So hopefully it won't take too long to hit mainline for this or very.

Random programming certificates are generally worthless. The course to get them might teach you a lot and be worth while, but the certificate at the end is worthless. If it is free then it does not matter too much either way, might be a good way to test yourself. But I would not rely on it to get you a job at all. For that you need other ways to prove you can do the job - typically with the ability to talk about stuff and having written some real world like application. Which a course might help you do to.

Fairly sure that Matt Mullenweg has already completely undermined Wordpress.org's trust and reliability.

That's what happens when you make it expensive to import anything and don't have any domestic manufacturing for computer components.

TLDR; yes it does affect security. But quite likely not by any meaningful amount to be worth worrying about.

Any extra package you install is extra code on your system that has a chance to include vulnerabilities and thus could be an extra attack vector on your system. But the chances that they will affect you are minuscule at best. Unless you have some from of higher threat model then I would not worry about it. There are far more things you would want to tackle first to increase your security that have far larger effects than a second desktop environment being installed.

Rust however… are Arc, Box, Rc, async, etc. fine?

Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)

match or if/else?

Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple if let enough, other times a match makes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.

How should errors be handled?

This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.

Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don't care as much about the differences as you typically want to deal with them all in the same way when you are near to main).

Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper).

I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus... a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.

IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.

https://godotengine.org/ released under the MIT license and very similar to Unity in terms of their target users.

Not just rebrands, they do put coreboot and as much OSS firmware on them as they can. So do contribute quite a lot to software around this, not to mention they maintain PopOS.

But also they have released the motherboard design for their Virgo laptop recently: https://twitter.com/jeremy_soller/status/1678891840093978625

Overall I agree with what the author says, though I have a few further thoughts:

One might argue that writing types are time consuming, and the bugs are not an issue when programmer can cover those cases with automated tests.

These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.

but a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function.

This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.

Functional Programming

I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.

So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.