And yet, most of the world still runs on the same five languages: C, Java, C++, C#, JavaScript.

Did you just assume that those languages exists since the dawn of computing? Or they run the world as long as they came to existence and were never "the new thing"? You are just contradicting yourself at this point to defend yourself from anything you don't want to accept.

mindlessly chanting “tools”

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".

Currently it's a long chain from an early version of GCC to the latest one, then mrustc (in C++) which can compile rustc 1.54.0.

I assume that you do know that tools improve objectively in the cycle and are making a joke on purpose.

Did they fixed the kernel panic problem that persisted in the last two versions? I don't dare to try it, last month their proprietary driver has almost destroyed my machine.

Because it gives the wrong impression that it is not proprietary, just like how you are making this exact mistake.

You can use Nix on Guix System and vice versa, but it's like installing them as a package manager on a foreign system. The store and packages currently are completely isolated between the two, although there's a very early plan for a common store interface.

No, monadic interface is used to programmatically access the store instead of being used to define packages. Packages are pure in Guix.

Guix uses Guile everywhere. Nix uses string interpolated Bash and Perl for anything impure.

Now what do you think?

Fyi, it's now available on nixos.

Nobody has mentioned that Guix is readily available on NixOS right now? Add a line to your config and it's ready to go. Compatible with everything else.

Typst. Much easier to setup and learn than TeX based solutions with similar capabilities.

I think there's no need to stick with one particular language. It benefits to learn more languages and bring the "good parts" of their design into your code whatever you are writing it in.

Btw It happens that I've learned a bit of RISC-V, with Rust.

I'd say no. Programming safely requires non-trivial transformation in code and a radical change in style, which afaik cannot be easily done automated.

Do you think that there's any chance to convert from this to this? It requires understanding of the algorithm and a thorough rewrite. Automated tools can only generate the former one because it must not change C's crooked semantics.

Well, they are not going to release in between, but their rewrite still "works" at each commit being a hybrid of Rust and C++.

1. breaks compatibility
2. breaks compatibility
3. breaks compatibility
4. 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.

Yeah, I literally learnt how nix works through guix documentations.

I believe that I'm already using it on NixOS. Working without visible problems since half a year ago.

It kinda fills a niche.

I use fish for simple command pipelines as well. But traditional shells are not as good when I need to do anything "structured", because they treats almost any value as a string and don't have anonymous functions. The first problem means that you have to parse a string again and again to do anything useful, the second means that when both pipe and xargs fails you are doomed.
Nu solves both of the big problems that matters when you want to do rather complex but ad-hoc processing of data. And with a rather principled design, nu is very easy to learn (fish is already way better than something POSIX like bash though).

Personally another important reason is that I have a Windows machine at work and nushell is much easier than pwsh.

Btw fish is also going to be a "tool in rust" soon :)

A git server don't need to know email to work, and it is not required to have a git server. Email in this workflow is an alternative to a PR: contributor submit a set of commits to the maintainer (or anyone interested). Then the maintainer is free to apply or merge the commits. After that the code can be pushed to any servers.

I've tried it and I think it's easier than a natural language to learn. Modulo the speaking part.

Difference is that YOU CAN BE THE ADMIN whenever you want while still being able to talk to others. Over.

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.

Kent just made a reply on this.

TL;DR: Fast on his machine. The reason of the difference is unclear though.

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.

There is a pre built distribution, you need to configure binary cache to get it. Refer to the "Substitute for nonguix" section: https://gitlab.com/nonguix/nonguix

Guile and Guix is way better documented than Nix. The language have more features, so you don't have to use a hack to load packages, can actually know what is accepted in a function instead of blindly copying what others do, and it comes with a formatter.

You can swap it with the standard one. It's on another non-official channel called nonguix.

Note that skim performs worse than fzf. There's a new matcher in Rust called nucleo which is faster, but it currently doesn't have a cli and can only be used inside Helix editor (hx)

nu is probably the best shell for ad-hoc data processing, handling all my daily needs in one expression.

fd and rg have another thing in common, that they're both 50% shorter than their traditional alternatives /s

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.

I've tried Joplin, Logseq, and Obsidian. The best one was Obsidian but it's not FOSS and is getting bloated over time.

I'm settling on zk now. This small command line utility solves almost all of the note managing needs for me.
Double links and tags make me forget about these "infinite free board" functionalities in OneNote: turns out they tend to be used inefficiently. Graphical sketches can be embedded in markdown or linked to a drawn picture.

The best thing about zk is that its notes consist of plain text and no extra tracking data is required outside of the file (unlike any others above), which means it's absolutely free to pair it with / move on to other tools when needed, or working temporarily without the support of it.

I think most window managers have the functionality to avoid windows occupying the space for custom bars. maybe you can make use of this.

Definitely OT, but at this point you may want to checkout NixOS.

Datalog. Basically relational, but have much simpler syntax and semantics,and is able to convey more complicated queries in a composable manner. Mainly used in Clojure-based databases where actual programs instead of strings are used.

They don't choose. Choice is something to make when people have enough time and resource. Instead they use what they are familiar with and have little time to grab and learn a new thing.
Free software comes with an implicit cost while pirated Windows doesn't, ironically.

It does not work like that. $ is required in shell languages because they have quoteless strings and need to be super concise when calling commands. # and // are valid identifiers in many languages and all of them are well beyond the point of no return. My suggestion is to make use of your editor's "turn this line into line comment" function and stop remembering them by yourself.