abacate

> You have to be pretty hard-core nix-pilled to understand what that one is doing just reading it straight-on [..]

There is little practical difference between that example and:

    Object.keys(licenses).filter(name => licenses[name]?.spdxId?.startsWith("GPL"))

The main difference is the syntax regarding attribute set operator (`attset ? key`), the rest is easily understandable by anyone that knows at least one or two programming languages that have closures (including Javascript).

> On the other hand, the TypeScript code the author provides is reasonably straight-forward [..]

Readability-wise, the Nix code from the article wins - the TS version has annotations that make it unnecessarily verbose, like `nix.lambda`, `nix.app`, `nix.sel`; to name a few.

From the article:

> Nix is lazy, so the emitted code wraps an expression in nix.thunk(() => ...) wherever Nix would allocate a thunk. (throw-up emoji)

I concur with the feeling.

> It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality

Source?

I believe you are understanding the opposite of what was said.

I understood it as "there cannot be trust anymore" - mostly because different people are at risk of becoming a victim in different ways: from a crime itself, or from being falsely accused of committing a crime.

Individuals will act in a way that makes sense for them. Asking them to "just trust more" does not solve the problem - it needs to be addressed at the root (education, communities), which goes far beyond the individual level.

Trying to convince people usually makes any resistance worse.

Using it, solving problems with it, and building a real community around it tend to make a much greater impact in the long run.

> nix, which has its own share of problems.

Care to elaborate?

> Christoph seems not to have actually looked at the patch before rejecting it.

I had the same impression as well, in particular due to his wording:

> "No rust code in kernel/dma, please"

When, in fact, the code is in "rust/kernel/dma" not "kernel/dma".

It seems like he missed this and then doubled down on his stance when questioned.

> The reason is entirely technical and I think it has been formulated clearly [..]

He clearly expressed a technical opinion based on his own beliefs, and that’s all. There was no reasoning.

He did not even acknowledge the fact that it is going to be maintained separately from the actual generic kernel code (rust/kernel/dma vs kernel/dma).

Anyone can easily formulate a sentence that seems coherent and correct, but it can be proven completely false in 15 seconds with actual data.

IOW: just because someone calls it a technical argument it doesn’t make it one.

This is a matter of opinion - specifically, the opinion of a single person.

> If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.

Indeed there was immaturity from several individuals.

One question: if you act immaturely towards someone and they react immaturely, who's fault is it? The person who reacted or you?

I do not believe there is a widespread issue of entitlement: if you follow the discussions on the ML and observe how the R4L project has progressed so far, the only "entitlement" that individuals in the R4L project may seem to have in common is the desire to be treated with respect and for discussions to focus on technical arguments.

For me, this is the bare minimum to be expected.

There is a large difference between "I do not think this is a good idea" vs "do not do this", in particular given the position Hellwig has in the kernel as a listed maintainer of the DMA mapping helpers.

No single technical reason was given besides a non-specific opinion on the "messiness" of multi-language projects.

If you search for "concurrent hash table <language>" or "concurrent map <language>" (being <language> Rust or C++) you get a number of open source libraries written using different techniques. I consider "exotic" a matter of opinion.

You can easily write a concurrent hash table in C++ or Rust. I fail to understand your point.

I read this article and the original one.

I don't see any reasoning besides "I think it's not really needed".

The reasoning in the original article is shallow at best, and the presented alternatives are not discussed in the depth I was expecting for an article questioning the whole architectural basis of a very popular IaC stack.

On the second article, I don't see a self critique of the actual points raised during the original article.

The two articles sound much like a collection of statements based on personal opinion.

I see the value in an article like this for starting a discussion but not into taking any sort of conclusion.

I would want this over docker and docker-compose any day.

I've been using docker compose in production for a couple of years now and it adds another layer on top of systemd that is a continuous source of headache, especially during updates.

Podman gets it right: no central daemon, can automatically generate systemd services for a whole pod. Updates are seamless.

This by itself is enough of a reason to me.