To be fair, the Twingo mk3 even has the front passenger seat fold down. In van mode the interior is huge for a small car.

But you’d be left without volume control, or at least from the same remote you control the TV with.

I've successfully set up sound bars with toslink and used the TV's remote to run the volume up and down. Toslink doesn't have to be a fixed level.

If future-TV lacks this functionality: DACs that have remote volume controls are very nearly as inexpensive as those that don't.

It is in the UK, but I don’t think it is on the continent.

It sort of worked for me, but it was very unreliable. I tried Proton and Astrill, both of which worked much better.

Mullvad is pretty good overall though.

Good. I expect this will become a widespread practice to deal with the already widespread problem.

Some already use probabilistic methods to automatically produce proofs for specifications and code they wrote manually. It’s one of the few actually useful potential use cases for LLMs.

For now, while everything you can rent is sold at a loss.

And in China, everyone is in a union yet there’s plenty of innovation.

Unions don’t prevent innovation.

I don’t know about that, it was called a systems language when it came out. By any common usage of the term, it’s definitely not that.

By the common usage of the term, it is most definitely a systems language.

Systems are the "opposite" of scripts. Scripts are programs that perform a one-off task and then exit. Systems are programs that run indefinitely to respond to events. We have scripting languages and we have systems languages. While all languages can ultimately be used for both workloads, different feature-sets gear a language towards one or the other. Go is does not exhibit the traits you'd expect of a scripting language.

This idea that Go isn't a systems language seems to stem from "Rustacians" living in the same different world which confused sum types with enums, where they somehow dreamed up that systems are low-level programs such as kernels. To be fair, kernels are definitely systems. They run indefinitely too. But a user land server program that runs continuously to serve requests is also a system as the term has been normally used.

Long before Rust or Go existed, “systems languages” were commonly the ones you can write a whole system in to run on hardware, like C, Pascal or C++. I’m not opposed to that definition changing, but it certainly hadn’t when Go came out.

I agree that Rust enums should have been called unions, though.

While that does not match my memory, it works too. An assembly language is part of Go, so it fits among the languages you mention. The only constraint it imposes is your imagination (and what the hardware is capable of). However, it remains that "systems language" was caveated as being for network servers specifically. But no matter how you slice it, I think we can agree that Go isn't a scripting language, so it must be a systems language.

Rust does use enums under the hood in order to implement sum types, so the name as it is used within the language is perfectly valid. It's just not clear how that turned into nonsense like Go not having enums (which it does).