Readit NewsEither way, extremely well explained both in motivate and implementation!
It already is, kinda. In my practice very often you have global singleton values that are either defined as static variables, or passed as arguments to nearly all functions in a module. Since implicit presence of `Debug` effect is already a compilation parameter, it could be generalized to support any sets of implicit effects. Thus you might design a module that has implicit Logger and Database effects in all its functions.
Real life software is much more than just downloading a game and running it.
Real life software outside of Linux is pretty much just downloading and running it. Only in Linux we don't have a single stable OS ABI, forcing us to find the correct package for our specific distro, or to package the software ourselves.
Not on any properly secured Linux machine. But yes, it's generally a bad idea to install software you don't trust, a category that anticheats slot nicely into, given their resistantance to auditing and analysis.
Just serving static files from Rust is not that interesting. It definitely does not sound easier to me, since you are coupling deployment of both BE and FE with no resource optimization to get. Also, since built SPAs are essentially static files, their deployment could be just uploading these files to your CDN.
Can make a bootable OS with just a containerfile, for example:
https://git.distrust.co/public/airgap/src/branch/main/Contai...
https://git.distrust.co/public/enclaveos/src/branch/master/C...
Unfortunately I don't know if there's an English equivalent, and considering how awful of a language Dutch is to learn it may be easier to learn Japanese, read the originals, and look up all the references yourself.
Curious, why do you think so? As a Russian I found Dutch to be much easier to learn than Japanese, and English knowledge helps. The largest problem by far is Dutch speakers falling back to English almost always.
I don't really see Kubernetes as being a game changer. The biggest pro, it makes it easier to onboard both development and operations personnel having a quasi-standard for how a lot of things like scheduling and application networking work.
But it also seems to come with a magnitude of accidental and ornamental complexity. I would imply the same about microservices versus, say, figuring out your repository, language, and deployment pipelines to provide a smooth developer and operator experience. Too much of this industry is fashion and navel gazing instead of thinking about the core problems and standing behind a methodology that works for the business. Unless google moves its own infrastructure to Kubernetes, then maybe there's something to be had that couldn't reasonably be done otherwise :)
Kubernetes solves administration of a cluster of Linux machines, as opposed to administering a single Linux machine. It abstracts away the concept of a machine, because it automates application scheduling, scaling across different machines, rolling updates of applications, adding/removing machines to the cluster all at the same time. There are no instruments like that for applications, the closest to them are something like Spark and Hadoop for data engineering tasks (not general applications).
Microservices are also used to solve a very specific problem – independent deployments of parts of the system. You can dance with your repository and your code directories as much as you want, if you're not in a very specific runtime (e.g. BEAM VM), you will not achieve independent deployments of parts of your service. The ability to "scale independently" (which tbh is mostly bullshit) is an accidental consequence of using HTTP RPC for microservice communication, which is also not the only way, but it allows reuse of the HTTP ecosystem.
The one fault perhaps is saying "operating system" when it's a distro. Linux is the operating system