Sorry badly worded on my part. They can use other platforms alongside steam. I really meant they cannot use them instead of steam without losing a massive audience. And likely making their game unprofitable. At least if they are not a very large game studio already.
And then if steam is pushing restrictions on what they can do on other stores then that is edging into the relms of abusing their monopoly.
You cannot eliminate X11/wayland overhead. You need a display manager of some sort. I suspect most games/proton will require X11 or at least xwayland and a wayland compositor. You probably do want to use a window manager of some sort as well or you do lose out on a lot of controls like window placement and sizing. Some games might do weird things if they dont directly launch in full screen mode. And steam itself would probably want to be run in big picture mode to make it go full screen. If you want something designed for gaming then you might try gamescope which is what the steamdeck uses as its window manager in the game mode.
There are probably other areas with a higher impact that you can optimize more before really worrying about a lack of window manager though.
You panic a lot on errors in functions where you return a result. Almost all of these are due to input problems not programming logic errors. These really should be return from the functions as errors so higher up functions can handle them how they might need to rather than just imminently crashing the program. Really panics should only be used when the situation should never occur and if it does that indicates a bug in the program - or you are being lazy with small/test code/one off scripts (but in this case why return any errors at all, you might as well just .unwrap() on everything instead of ?.
You are right. You cannot onboard a new job before you leave your old one. Accepting an offer is not part of the onboarding process though. It happens before.
After an interview process the company makes an offer. The candidate can then accept or reject it. But that is really all informal. You can then negotiate with them for an official start date and contract. You just need to ensure you can hand in your notice and work the rest of your notice period before the start date of your new contract.
I don't know anyone that would hand in their notice before accepting the initial offer of a company. At least here in the UK.
Or the RFID chips on their spools.
They do quite a lot of things that are fine atm but are gateways to giving them a huge amount of control if they every want to flip that switch - like if they get brought out or their investors start wanting to squeezing them for all they are worth.
Or your example, how would we have processed ore into metal without coal (on any significant scale).
We have been processing ore into metal with coal for thousands of years. It sounds like you are arguing that the industrial revolution has been happening for thousands of years. Which it has not.
We also made bread in the industrial revolution which is needed to feed the workers. Without feeding the workforce we could not access certain advancements. Is bread a corner stone technology of the industrial revolution? No it is not. It in no way defines what the industrial revolution was. Just like coal or oil.
You can run a steam engine off of coal, wood, oil, nuclear, basically anything that creates a lot of heat. Coal is more convenient in a lot of ways but it did not unlock anything special. If not for coal we could use wood or charcoal. That was the steam engine, not the fuel it runs on.
And if the advancements were because of these fuels that why did it not happen 1000s of years ago when we had access to them?
You don't share code between monorepos, the whole point of a monorepo is you only have one repo where all code goes. Want to share a library, just start using it as it is just in a different directory.
Submodules are a poor way to share code between lots of small separate repos. IMO they should never be used as I have never seen them work well.
If you don't want a mono repo then have your repos publish code to artifact stores/registries that can be reused by other projects. But IMO that just adds more complexities and problems then having everything in a single repo does.
A system us bloated when I feel it is bloated. It is highly subjective and there is no real line to cross. It is just more of a sliding scale, at one end there is no code on your system that you never use and at the other there is nothing on it that you ever want to use.
The former can likely on be reached on small microcontrollers where you have written everything exactly how you want it, and you would never even consider using the latter.
Realistically every system has things younever use, even the kernel has modules you will never load. And every non tiny program has features you never use. All of that is technically bloat but each instance I don't think makes your system or even an application feel bloated.
So really the question is when does the bloat bother you or get in your way. If you are trying to install an OS on a tiny embedded device where space is a premiumthenn you are going to draw that line at a different point to on the latest desktop with multi terabytes of storages and oodles of ram.
Anyone that claims there system has no bloat is technically lying to themselves. But if it makes them happy who cares? If your system has every package installed and it does not bother you at all thenitt does not matter at all.
As far as I understand it Arc<> is just the Async version of RC<>.
Not quite right. Arc is the atomic RC, aka the one that is thread safe and can thus can be sent to other threads. Rc is single threaded only. async is agnostic of threading and there exists runtimes that are both multithreaded and single threaded.
Although tokio, the most common async runtime, is multi threaded and so tasks you create need to be multi-threaded safe thus you likely need to use Arc for most things in tokio. But that is due to the multithreaded nature of tokio, not the fact it is async.
I’m not entirely sure about Box<> and a lot of its API’s are still unstable but I believe it’s primarily used as an owner for unsafe things.
Box is the single ownership heap allocated datastucture of rust. It is a core type that is used for a lot of things. It is not just for unsafe things and mostly safe things are put in a Boxes. It is basically used whenever you want something on the heap rather than the stack At least when the type in question is not already heap based (like Strings, Vec, Arcs etc).
It is used a lot for trait objects (when the type is only known at runtime, not compile time, aka Box<dyn Trait>/&dyn Trait) when you need ownership of the object (aka reference trait objects are not suitable). Or when you have a large type that needs to be moved around a lot and you don't want expensive stack copies when a cheap copy of a pointer to some heap data will do instead. Or you have a type that is not Sized (aka the size is not known at compile time and needs to be tracked at runtime) but need it to be owned (such as a slice, trait objects etc).
I use only free VPSs
So probably not entitled to anything from them.
The way I read it, he wasn’t suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.
Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.
Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.
But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.
Though I mostly abhor OOP, it taken in small doses can be good
Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.
You can choose to buy new things on other platforms. But you lose access to everything you bought on steam if you choose not to use them anymore. That is a form of locking to their platform. You cannot just move you library to another platform.