[zanny]

I think a lot of it boils down to the Linux ecosystem worship of C99.

Almost everything underneath your GUI (and often times, it even is your GUI, cough Gnome...) is written in C.

C is good for micro-systems where you do not want to implement all the abstractions higher level languages require. It is good for implementing low level functionality in other languages (like Python) or for writing a first-try compiler in on a new platform because of its simplicity.

It is not appropriate for an entire OS stack including tens of millions of LOCs across thousands of projects and a hundred thousand developers. At least in the modern age when we have everything from OCaml (1996) to Rust (2015) showing how to do bare metal safe and fast. Even C++ is moving towards a safe yet fast subset of the language where you should never use new / delete anymore.

Going forward, probably the most important revelation the free software world is going to need to go through is that for your own personal projects, being a whiz C expert that can hyper-optimize pointer math is great. But as soon as you start accepting merge requests, or even worse start delegating maintenance of your codebase across multiple people, C is going to cripple you.

Like I said, it is not C's fault. It is the dogma of Unix that the community holds sacrament - you write it in C, you use pipes, raw IO buffers, and to question that holistic view is to be opposed to everything about it, even if all you take issue with is the complications imposed by using C everywhere (OpenSSL, Systemd, the kernel, udev, NetworkManager, and in personal projects I have had to contend with deep buffer overflows / pointer misalignment / offset miscalculation in things like pulseaudio, SDL, Mesa, Wine, etc).

Maybe when the systemd developers pick their next slice of userspace to bring into the collective, they might possibly consider using a higher level language to implement it in. Not because they are bad developers, but because the code they write is not just about them. Think of how many headaches new work could avoid using something safer like D, or Rust, or even a restricted subset of C++.

[digi_owl]

> I think a lot of it boils down to the Linux ecosystem worship of C99.

Hardly. If anything it stems from a dual attempt at Linux user space devs to turn Linux into a merger of OSX and Solaris, while applying copious amounts of NIH-ism and second system thinking.

They are far too willing to throw away whole generations of software and concepts over some esoteric corner case or other, and keep chasing platonic ideals that will never stand up to an encounter with actual usage.

And likely when Torvalds steps down, and thus no longer hold the kernel devs to the "do not break user space" mantra, we will see the kernel fall to the same mentality quite quickly.

its CADT cubed.

[hyperpape]

1) I'm not sure I get what your theory about C is. I could get it if his machine was segfaulting, but how does C cause these problems? 2) C trivially can't explain any decline that's happened, because old Linux was also written in C.

[zanny]

1. The complexity breakages caused by software interactions over the years only gets worse with increased complexity. This is where the overarching theme in the piece of "Linux is getting worse" comes from. More moving parts, more interactions between parts, and more errant behavior and millions of LOCs getting chugged through a CPU give you a larger surface area for problems.

2. This is just a reiteration of the main point, but old Linux was... a PITA to work with. Xorg configurations, manually activating peripherals, no common bus interface like dbus, etc.

The problem is, again, when your foundation is built on C and you used it throughout the entire construction, you get leaks and problems come through the cracks especially at the joints and especially at points of interaction (especially between multiple versions / upgrades, which is a major point of the OP). Linux has gotten bigger to do more and be more, but as long as we keep piling on unsafe, unabstracted code as the fundamental our technical debt becomes so incredibly huge that you get to the point where you pull a Debian Stable rather than an Arch because upgrades are so terrifying.

[marcosdumay]

Most of the delays, problems and incompatibilities do not happen in C code.

It happens because nobody stopped to think about an interface, or because a configuration file or shell script does not handle an error correctly, or because, since nobody wanted to create a sane error handling system, an script has no option but just keep trying and trying.

I do agree that most of the software on one's computer shouldn't be written in C, but those are not the problems this migration would solve.