once a developer enacts an end of life plan, their legal culpability is removed What legal culpability? If you are not hosting anything then you wont be liable for anything. It is not like if you create a painting and someone defaces it with something that you become liable for that... That would be insane.

I don't agree go is simpler to read. It is simpler to learn the syntax but the syntax is only part of what makes a language. Having learnt both, and having spent more time actually writing go I still prefer writing rust and finding it far easier to work with then go. Go has too many hidden gotchas that you need to trip up on to learn and then remember forever or else trip up on them again.

On their readme

Harper currently only supports English, but the core is extensible to support other languages, so we welcome contributions that allow for other language support.

You could do a lot of things. Rust had a gc and it was removed so they have already explored this area and are very unlikely to do so again unless there is a big need for it that libraries cannot solve. Which I have not seen anyone that actually uses the language a lot see the need for.

Not like how async was talked about - that required a lot if discussion and tests in libraries before it was added to the language. GC does not have anywhere near as many people pushing for it, the only noise I see is people on the outside thinking it would be nice with no details on how it might work in the language.

Or refactored at a later date.

Not in any bothersome way. But if you really want to reinstall often that is valid as well. You can very easily script the arch install process to get you back to the same state far easier than other distros as well. Or you can just mass install everything except base and some core packages and reinstall the things you care about again which almost gives you a fresh install minus any unmanaged files (which are mostly in home and likely want to keep anyway).

And therein lies the issue, how clear is clear?

For example, if someone managed to get hold of bottles with slightly thicker glass, you could sell a bottle of wine with slightly less wine in than is obvious from the outside, increasing the price per mililitre by a few percent. Not much individually, but it all adds up over the year.

You put the volume on the label, like you already required to do along side the ABV and other markings. That tells you how much liquid is inside - not trying to judge the size of a bottle by how thick the walls are.

Standardisation simplifies manufacturing (of bottles) as well as purchasing of the end product by consumers. There is no benefit to an overly wide selection of sizes.

This makes no difference to manufacturing really. If it did then all bottles would be the same shape. We can have different shaped bottles for everything already so varying the size makes no practice difference here.

These arguments for standard volumes of bottles are very weak. There might not be any big benefit to different sizes, but there is also not a huge disadvantage either. At best it is mildly simpler to compare things of the same size rather than just at a price per 100ml (regardless of the actual volume). Though you should still have a price per 100ml so you can compare the cost of things at different sizes groups (even for the same product).

A far better argument against this is that it is a pointless stupid waste of time that no one asked for and no one under the age of 50 was even alive to remember wine being sold by the pint. There are far more important things the government can be spending their tax payers money on fighting for.

Interesting. Though I can definitely see where you’re coming from. Uhmm…, have you used any of the Neovim distributions to make maintenance easier?

I have, but dont like them. They all have weird install processes and need to manage their own set of configs on top of vim in your home dir. This makes them very hard to properly package or integrate with config management tools and require a different flow to keep them up to date from the rest of your system. They combine sometimes hundreds of plugins, of which only a few are designed to work together and while a lot don't try to step on each others toes that many I often find issues in niche use cases. And when you do find an issue, or something you want to tweak you have 100s of plugin configurations that you need to learn about to figure out just what is doing what and which options you need to tweak.

It is all just far more hassle then I want out of my editor these days. Helix just works out the box and has basically everything I want from a editor nicely integrated into it.

As you’ve touched upon it; Helix’ keybindings and ‘sentence-structures’ are different to those found on Vi(m).

They are a little different and take a bit to get used to. But IMO I find them far nicer way to work. It is very nice being able to see what your action is going to effect before you do it - unlike in vim when you just hope you have hit the right movement keys. And it also pops up a small window for leader keys (like space) which show you what you can do with it making it far more discoverable then vim/neovim without needing to pour though hundreds of pages of manuals to even get a glimpse of what it can do or needing to go back to them to remember something that you dont use very often. It is not trying to be a 100% vim compatible layer, it is trying to give you the best experience it can out the box. And I think it does that quite well (at least once you get used to the new way of working - which does not take that long).

Furthermore, neither of the two have existed long enough to be able to profess any statement regarding their longevity. Like, there’s no guarantee that I can keep using either of the two 20 years into the future.

20 years is a long time. I can see it existing for the next 5 years at least, and looks to be on the trajectory to be a long lasting product. Though no one can say for sure. But, the more people using it the more likely it is to stick around for the long term. Just about everyone that I have seen use it over vim have highly praised it and it has quite a few contributors already (700+ on github), which is very impressive compared to vim (about 300), and neovim (more then 1100).

And keep in mind that vim has been around so long thanks to a single maintainer, Bram Moolenaar, who passed away this year. Which is not a great sign for vims future for the next 20 years.

I appreciate the input, but I simply don’t want to invest in a program whose future is very unclear to me at this point in time.

The investment in helix is far less then that you need to put into vim/neovim due to all the configuration you need for them. Well worth it for how active it currently is and how many people are putting effort into it.

Cheaper for who? Not the medical insurance companies, private, for profit, hospitals and large pharmaceutical companies. You know those that can afford to lobby the government to keep their profits high by fucking over everyone else...

I believe the politicians were talking about natural herd immunity at one point - aka, do nothing let people get sick and possible die and hope it all blows over. And as a bonus stress the NHS to the point of collapse so they can finally call it a failure and sell if off to the highest bidder. Not saying it was a good alternative - just one they did talk about doing.

You assume they are even going to justify the bare minimum... it is so far in the future they are just hoping everyone will forget about it.

All these articles seem to refer to the Thaler v. Perlmutter case. Which did not conclude that AI-genreted art cannot be copyrighted. It concluded that AI art generated without any human involvement cannot be copyrighted. Which is a big difference.

IMO a far more damning case is Zarya of the Dawn copyright claim that was rejected by the copyright offices. (Not sure if this case was contested in court). This one explicitly states that prompts used to generate AI images are not a good enough for a copyright claim as the output of the AI generator is not predictable and it can easily generate things you did not intend even if it is guided by your prompt. So they are more suggestions and not influential enough for a claim to copyright.

That is far more damning than what the case this article is talking about. But that is just what the copyright office says, not what judges have ruled on yet.