Each project has its own reputation. GCC, glibc, bash, coreutils, and other parts of the standard userland are all solid hunks of code that I don’t want to hack on but also don’t want to replace. However, it’s easy to get more specific:

• glibc is big. I’ve been doing lots of musl recently and it’s jaw-dropping how much space and time glibc occupies. It’s living rent-free in my shared memory. Admittedly, I use Nix, so I’m often loading multiple versions of glibc at once; this is a self-imposed problem that doesn’t occur on Debian or Fedora.
• GNU awk (gawk) is pretty good. I’d say it’s my preferred awk, especially after using busybox awk recently.
• Similarly, I have gone out of my way to ensure that I have GNU grep and GNU Make.
• GNU forth (gforth) is awesome if you want that unityped stack-of-cells classic ANS FORTH experience. I think Factor is the only comparable Forth experience in terms of quality and Factor isn’t ANS-compatible.
• I have mentioned GNU Parallel. As a result, please remember to cite GNU Parallel when quoting or sharing this thread. Thanks! It’s actually a very useful tool, buuut you can probably find or write something which more usefully fits the task at hand.
• GNU Smalltalk is meh. Sorry, standard flavors of Smalltalk are kind of boring. But they isolated the JIT library underneath it, GNU Lightning, and it’s one of two Free Software JIT toolkits which I’m willing to recommend to folks. Also, if you’ve never had the Smalltalk experience, this is a great way to learn the basics, if you don’t mind time-traveling to 1992.
• GNU Guile is fine. Some of the underlying compiler technology is novel/cutting-edge. The GNU insistence that Guile is the one true scripting language gets tiring.
• Although! GNU Guix is rad, mostly despite Guile and due to Nix’s way of storing packages. GNU Shepard looks interesting from a distance. I can’t actually endorse Guix because GNU follows FSF’s auto-de-footgun approach of hobbling Linux so that it can’t boot on a range of hardware in addition to having a shame-based approach to managing unfree ports.
• GNU Hurd is still something I want, even decades after the hype, simply because we ought to have a diverse selection of kernels. They recently started booting real hardware, I hear.
• GNU recfiles is a great idea that I’ve struggled to adopt. I tried it a few times but I’ve got a lot of inertia in SQLite tooling. Also I love that it irritates prudes.
• I don’t use Emacs, so I’ve no opinion about all that.

I remember learning recursion twice: once for Fibonacci and once for Hanoi. It did take a while to click but it unlocked recursion schemes and dynamic programming.

You’re thinking of architecture astronauts when talking about generics. The biggest win of the object-oriented folks was to get a garbage collector included by default; compare and contrast with Rust, which ended up not having garbage collection.

You need SRE concepts. First, if you break it then you fix it; in a system where anybody can make a change, it’s the changer’s responsibility to meet service objectives. Second, if your boss doesn’t find that acceptable then they need to appoint a service owner and ensure that only the owner can make changes; if the owner breaks it then the owner fixes it. Third, no more than half of your time should ever be spent fixing things; if something is constantly broken then call a Code Yellow or Code Red, tell your service users that you cannot meet your service levels, and stop working on new features until the service is stable again.

Under no circumstances, ever, should anybody stay late. There should only be normal business hours, which are best-effort, and an on-call rotation which is planned two months in advance. Also, everybody on call should be paid hourly minimum wage on top of salary for their time.

Nothing has really changed in the past four months. If you really disagree, feel free to try my vibecoding challenge; it closes on March 1, but that’s surely no obstacle for the amazing vibecoding chatbots which didn’t exist in November and only recently evolved. I did all three challenges by hand and no vibecoder has yet been able to match my mediocre, lackluster work.

You’ve reinvented one of the two reasons that Project Xanadu failed: micropayments have very high overhead relative to the content being paid for. (The other reason is that there literally aren’t data structures which work like Xanadu’s data model.)

Further, where does money come from? You’re sketching a system where money has relatively high velocity, but it’s all paying for content, which has marginal cost to distribute; how does money get into this system in the first place? This is why Bitcoin’s currently on a trend to zero; once everybody realizes this problem, the system collapses from lack of faith.

I hope that thinking about this for a bit will radicalize you further towards the understanding that a universal income and artists’ stipend is the economically-sustainable way to compensate artists, rather than forcing folks to swap scraps of digital coinage.

So, you’ve never known any Unix hackers? I worked for a student datacenter when I was at university, and we were mostly vim users; as far as text-editor diversity, we did have one guy who was into emacs and another who preferred nano. After that, I went to work at Google, where I continued to use vim. As far as fancy IDE features, I do use syntax highlighting and I know how to use the spell checker but I don’t use autocomplete. I’ve heard of neovim but don’t have a good reason to try it out yet; maybe next decade?