And all of this due to the mistaken design decision to stick with the obsolete readiness-based model instead of going with the superior completion-based model.

(You can build a readiness-based API on top of a completion-based API, but not the other way around.)

git worktree is just so much easier to work with if you want to work on multiple versions or branches of some code.

It allows having multiple IDE instances open, all fully functional and indexed, and handing over commits from one worktree to another without having to fetch constantly in between.

Trying to emulate this with multiple clones feels like trying to do OOP in C -- sure one can do it, but it's pointless hassle compared to a fleshed-out solution that works right out of the box.

Not to mention it's so much faster and more efficient than git clone.

What a confused post.

There is not much to learn, so just do it? It's not a relevant investment that would require much thought.

Yeah, avoids pointless debates whether they should be lined up in matches or not. :-)

Many languages' Option and Result types suffer from an organically-grown and therefore inconsistently named set of functions that operate on them.

We can do better! The article demonstrates how a full set of useful methods with predictable names can be derived from few, simple rules.

Absolutely delusional.

code that is readable, auditable, and easy to port

Yeah C is the language that comes to everybody's mind reading that. /s

C's simplicity ...

Is that simplicity currently in the room with us?

... and widespread adoption make it the best choice for this philosophy.

Ah, the asbestos argument.

If people want to run the latest kernels on hardware that isn't maintained anymore, they need to toughen up and send patches ...

... or they stick to an old kernel for their unmaintained hardware.

Both is fine to me, but that entitled Boomer attitude of "nobody should have nice things, because that would challenge status quo" needs to die.

Studying at a university is not a fancy job training.

Do whatever pays your bills, and learn what interests you. Sometimes the latter will help with the former, but it would be silly to depend on that.

I think the article suffers a bit from not being up to date in regard to the work Java has done with virtual threads.

There quite a few assumptions being made in the article that would not have been questioned a few years ago, but now these assumptions feel quite unfounded and all the conclusions based on them stand on shaky ground.

Some functions also don’t have any parentheses, like field access or infix operators.

You call things the way they were defined. Problem solved.

I'm kinda confused, because this is the second time now where your attempt at making a counter argument is actively supporting my point. Is this intentional at your part?

We could follow this line of thinking further ...

No we don't. If your point relies on Turing-tarpitting the whole discussion ... then you have no point.

Thankfully, registration fees do not differ by length of the domain. (As it should be.)

It cost a larger 3 digit amount of currency to buy it, though. (Which was fine for me.)

Packages are usually provided by distribution packagers, not by the developers of the code itself.