majewsky

I agree. AI skeptics are widely met with disbelief when describing the atrocities that LLM operators are inflicting on society right now.

That may very well be true, but as you're describing it, I think of all my fellow engineers, all of them very talented, who moved up into management, arguing exactly the same point of thinking at higher abstraction levels. And after one or two years go by, they will come to me with requests or opinions that are literally the dumbest shit I've ever heard. Like arguing that we (holding most of our data on MariaDB and Postgres) should move everything into Kubernetes custom resources because "the Kubernetes resource model is the best database ever". That's a real thing that I've had an engineering lead say to me. When I asked how you're gonna do an efficient table join on Kubernetes resources, I just got a blank stare.

Will you though? I like the adage: "We used to write software like hardware will get twice as fast every 2 years. Now we should write software like hardware will get twice as expensive every 2 years."

Yes, because GTK2 is so difficult to upgrade to new versions, whereas Qt4 to Qt5 usually only involved replacing a few identifiers (cannot speak to Qt6 since I don't do Qt anymore). That's why distros need to drag GTK2 along even though we are already at GTK4.

Try living without a Google or Apple account in a country where most bank accounts or other services (incl. in some cases government services) require a smartphone app only delivered through the monopolists' app stores and (in the case of Android, where installing degoogled Android images is technically possible) requiring Google Play Integrity to pass.

"It does not make sense to call him a murderer because then there would be a ton of murderers."

???

> Understand human nature, incentives, and complex systems like markets and how they produce incentives.

We do. "Class war" is just the succinct phrasing for "people who earn money through capital returns have vastly different incentives than people who earn money from their labor, and they also have the means to turn those interests into political leverage".

> Hello 911, our auth service is down following a malformed config deployment.

"Emergency" is not the same as "emergency services".

"Disclaimer" means "don't take this seriously because I'm not an expert". You mean "disclosure".

Not for me.

Static analysis does not help if the type comes from a library and is _meant_ to be initialized using a literal.

And then upstream adds new fields where the zero value is different from the previous behavior, causing users to silently drift away from the intended behavior. I had this happen to me with a type from std, and had to add a specific test to guard against it with future std upgrades: https://github.com/sapcc/go-bits/pull/309/changes#diff-f5721...

> for instance by setting MaxIdleConns in Transport to 0

Which a lot of libraries are doing because they wrote an http.Transport{...} literal in an earlier version, and then std added new fields to the type in a way that silently breaks existing users. The zero value should have matched the previous default behavior.

Case in point: https://github.com/prometheus/client_golang/pull/1885/change...

We had the same in our own library, and now have a testcase checking if our own custom instantiation of http.Transport matches http.DefaultTransport, so that the tests scream loudly when upstream pulls this shit again: https://github.com/sapcc/go-bits/pull/309/changes

It's almost as if the choices that make languages "look like this" are the ones that are generally associated with a more productive development workflow.

But you would still have to deal with the mental load associated with having templates in your stack. I don't know if C++ is still as bad as it was back in my day about vomiting 20-line error messages at you because "std::vector<std::string>" or something has a billion implied template arguments. That was definitely a cost that one had to bear even if one never used the "template" keyword.

I'm not necessarily disagreeing, but I'm following the single-letter convention because "TIn" or "InputType" looks too much like an exported symbol. Whenever I tried to write type arguments like that, this threw me off, so I reverted to single letters.

> "Box" isn't really a useful type.

It is very close to one. My Option[T] type [1] cannot have a Map method in stable Go because of the type system restriction in question. Instead, I have a separate package with freestanding functions with the same purpose, including Map [2].

[1] https://pkg.go.dev/go.xyrillian.de/gg/option#Option [2] https://pkg.go.dev/go.xyrillian.de/gg/options#Map

Access to a well-established set of tools for operating on unstructured text (coreutils, grep, sed, awk, etc.).

> It is literally, the absence of a desire to participate.

I agree with this position, and yet I would argue that, by taking the time to write out this comment, you are acting inconsistenly with your own statement.

I have old repos with "master" and new repos with "main". If someone were to approach me about one of the old repos and ask about the default branch, I would immediately change it to "main" without any hesitation, because it is all but certain that trying to get into an argument will waste more of my time than just doing the change would.

> If your revenue is 25 billion

It isn't. They had a one-month period around February that, if every month ran like taht, would constitute a yearly revenue of 25 billion. The fact that they appear to not have published a new annualized revenue number since then suggests that the trend is not upwards, which would make sense with the growing number of companies that are asking questions about ROI on AI expenses and cutting their token spend.

The fact that one of the orgs that you're a member of is flipping the switch is not newsworthy.

> But to force these beliefs on others through laws is crossing a line you will regret at some point in your life.

Where did they argue for a policy solution?

If this is a thing you need to beware of, you should more importantly beware of using a version of Go that's been outdated for over 1.5 years and EOL for nearly a year.

Context: https://github.com/golang/go/issues/70000 fixed in 1.23.3 (released 2024-11-06), EOL for 1.23.x was 2025-08-06

Go and try to create 40000 VMs on Hetzner. The cloud may look infinitely big, until it suddenly isn't.

If the system cannot adjust its answers to the role it's currently serving, then it would evidently be significantly less intelligent than a human.

Of course the degree doesn't help with that. What helps is accountability. When a bridge collapses, and it turns out the engineer who drew the plans made a mistake, they can be and often are held criminally liable.

When's the last time you saw a software engineer prosecuted for criminal negligence after a design error took down Cloudflare or whatever? Attitudes in software development will not change until that becomes a viable scenario that people anticipate when making design and implementation decisions.

Also, regardless of what you think of LLMs, it makes tech support for Linux a whole lot more accessible to the average person. There is going to be less of an expectation now that you need to have a Linux guru on speed dial for the occasional weird edge case situation.

That's assuming that each fix can only introduce at most one additional defect, which is obviously untrue.

Well, about the free-software part, anyway.

> But in my cause we're still on 1.24.13 which was released by the Go team less than two months ago.

Yes, and then one week later the entire 1.24 branch entered EOL: https://endoflife.date/go

I still saw the same bug just now (Firefox on macOS).