vilunov

Linux is a kernel, it doesn't have a stable and rich enough set of userspace services to be considered an operating system on its own.

Scala 2 is a dying language, and Scala 3 is an immature one. The ecosystem and community are also very messy, with fragmentation and witch hunts running rampant. OCaml provides same advantages, but without all the drama.

> I wonder if this will wind up being a category of problems and the solution is a separate "system" set of effects (effectively `({user}, {system})`) or if this one-off extension is all that will be needed.

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.

A properly secured Linux machine is a unicorn. The Linux desktop ecosystem is struggling a lot with putting software in namespaces. People still install software with their package managers outside Flatpak, there is no isolation of data, not to say many workflows depend on the whole user directory being available to access.

Usually FE and BE are developed by different people or even teams. It's helpful to decouple release cycles of both components, or else a bug on one component could block deployment of a different component. It's important not to decouple deployments of two components when doing so would save up significant resources, but here decoupling could be achieved by deploying a separate nginx server with static files – this is incredibly cheap, as there is very little static overhead, and performance is comparable.

Are there any approaches which implement server-side rendered SPAs with Rust? In that case Rust would render the HTML for the first load and server JSON APIs for changes in the SPA. Rendering the HTML is performance-intensive in my experience, using Rust could save up quite some computational resources.

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.

This is beautiful. Deterministic, bootstrapped, and doesn't break the established Linux conventions! Shame it's musl-only, I would love to use something like that to build glibc-based apps for future redistribution as proper Linux binaries.

> how awful of a language Dutch is to learn

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.

Kubernetes is absolutely not an accidental complexity. Microservices are not an accidental complexity, and they are not a replacement for a proper repository.

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.

Is it possible to specify locked glibc and cc/linking toolchain in your Bazel project?

That's not usually the issue. Glibc is used by 90% of main distros, notable exception is alpine used in docker images.

The problem is Linux ecosystem's fixation on "build environment = runtime environment" idea, making it incredibly difficult to build against older versions of glibc (e.g. Ubuntu 22.04) if you're using something new such as latest Arch. This is not a problem on macOS, you can use an SDK for a particular OS version on any other recent version.

Unfortunately, my predecessors had plenty of time. Now I'm left with a burning project and half my time spent on clicking "go to implementation" of the next interface and hoping the first one will be the real one (actually full-text searching for it because Scala has no working IDEs).

I'm sorry, but depending on abstract classes does not "free the domain model of an application of low level details". The details are always there, but they could be tucked away inside other classes (structs/types) that higher ones depend on. These low level classes need not to be abstract, it will just make discovering code harder and provides nothing to improve separation of concerns.

> Updating the minimum supported Rust version is a breaking change that should not be done lightly.

Why? As I see, requiring a higher minor version of your dependency including the compiler is not a breaking change (and does not warrant a major version bump wrt semver), as there should be no problem in bumping the minor version of any dependency, even if it's used for different packages.