netburst

While elitism and ego have certainly played a role in the dialog since the beginning of computing, this perspective conflates those issues with the very real technical arguments against the listed technologies. C and other contemporary languages had their limitations; you were sacrificing flexibility and potentially speed for a more pleasant and maintainable development experience. Garbage collection dates from long before the 90s and has always been controversial, in no small part from differing tastes and opinion on whether other memory management techniques are truly more difficult. The assumption that these technologies lowered the barrier to entry may be the crux of much of the argumentation.

> ... they didn't understand the machine code that the compiler was writing ...

This is a bold assumption and inconsistent with my knowledge of history. High level languages allowed better management of complexity and reduction of tedium. The common complaint was that compilers produced less efficient (slower and/or larger) code, not that the output was more complex. It was[1] normal to read the compiler's output, which was generally assembly or another intermediate representation. After all, a compiler is merely a tool for translation from one language to another. Additionally, early compilers often were not optimizing compilers; the code they generated was simpler than handwritten programs.

1: And still is, for some of us!

It's simple: you don't. You slow down. It's essential to understand what you ship, before you ship, as there are real world consequences for not doing so, ranging from wasting the time and energy of yourself and others, up to failures which cause a great deal of harm to people and the world. To knowingly ship code you don't understand is grossly negligent, regardless of how common it becomes.

What is are the benefits of supporting extremely high churn rate in version control? What is the code doing? What problems are being solved? Are changing requirements the driving factor, and if so, why are requirement changes accelerating?

> ..., the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce.

If the goal is to write software which solves real problems, how can the demand for code grow infinitely?

A CRT doesn't display a picture, it produces a dot of photon emission which varies in color, intensity, and position over time across a 2D surface. The picture happens in your mind.

That would be inadvisable as the maintainer (?) in question's GitHub bio states:

> Emailing me about a temporary ban will result in a permanent one instead.

As far as I can tell the ban was given based on a single accidental ping to the maintainer, who then reviewed the draft PR before realizing it was not for the mainline llama.cpp repo.

3MB of "hot" RAM, stored in a cryogenic flask - a cold boot attack. He isn't selling RAM, he's selling data.

Since you mention Go, it does offer precisely the feature you describe in the form of build constraints. A file starting with

  //go:build go1.18

tells the toolchain to use Go 1.18. A slightly different syntax was used prior to Go 1.17 but the feature itself has existed since Go 1.0.