I assume that you do know that tools improve objectively in the cycle and are making a joke on purpose.
- breaks compatibility
- breaks compatibility
- breaks compatibility
- hard to add without breaking compatibility
Then we arrive at Rust as a natural outcome.
And it's of course possible to migrate to Rust from C or C++ progressively, fish has almost got it done.
Honestly I'm surprised that so many people don't know how git can be used without those repository hosting sites. That's one way to use it, not the only way. And it's not even the way it was originally designed for.
Checkout git format-patch.
Git and Email are not mutually exclusive. In order to collaborate with git, you need and only need a way to send your commits to others. Commits can be formatted as plain-text files and sent through emails. That is how git has been used by its author from literally the first release of it.
This reminds me of a similar experience.
The first release of WSL(2) 1.0 (this versioning alone is worth another post here, but let's not talk about it) have its CLI --help
message machine translated in some languages.
That's already evil enough, but the real problem is that they've blindly fed the whole message into the translator, so every line and word is translated, including the command's flag names.
So if you're Chinese, Japanese or French, you will have to guess what's the corresponding flag names in English in order to get anything working.
And as I've said it's machine translated so every word is. darn. inaccurate. How am I supposed to know that "--分布" is actually "--distribution"? It's "发行版" in Chinese and "ディストリビューション" in Japanese.
At last I had to switch my system language to English to set a WSL instance up. From then on I never use any display language other than English for Microsoft products. Sometimes "translated" is worse than raw text in its original language.
Related links if you like to see people suffer:
https://github.com/microsoft/WSL/issues/7868
https://github.com/microsoft/WSL/issues/4111
PS: for the original post, my stance is "please don't make your software interface different for different languages". It's the exact opposite of the author has claimed: it breaks the already formed connection by making people's commands different.
It's the CLI equivalence of scrambling every button to make sure they are placed differently in different languages in GUI. I hope this sounds stupid enough so that no one will try it.
A not-so-stupid way that I can think of is to add a "translation" subcommand to the app that given any supported flags in any language it converts them to the user's language. Which is still not so useful and is not any better than a properly translated documentation, anyway.
Compared to btrfs it's claimed to be faster and having working RAID support. Its unique feature is using a fast device as cache to speed up access to slower, larger disks, I think.
Some have better ux, some support more platforms out of the box. I don't find it a good idea trying to replace everything though.
So why not just use the lean and maintainable wlroots
wlroots can't be used (comfortably and idiomatically) in Rust because it's too hard (if not impossible) to provide a memory-safe interface for it.
we can move to another implementation of the Wayland protocols.
So unfortunately this has already happened.
the developer chooses to work with these publishers beforehand
What kind of paradise are you living in?
Any stream content. Any subscription. Anything that I can't access because of my nationality.
I'd pay for other things.
KDE Plasma 6 for the resolution of so many issues; COSMIC DE as a brand new choice in the future; Guix System to have KDE and more packages shipped because it's literally the best designed distro as of now.
That's what you were doing in the first place. Instead of evaluating and trying new things, you are putting them in an imaginary cycle, ignoring any actual value that they brings.
Also Rust has been on your "stage 2" for 10 years. It's now widely used in multiple mainstream operating systems for both components and drivers, driving part of the world's internet stack, and is used to build many of those "shiny and new tools".