C, still?

Posted Sep 20, 2017 10:20 UTC (Wed) by k3ninho (subscriber, #50375)
In reply to: C, still? by ncm
Parent article: Building the kernel with Clang

Hey, can you let me know what you think of Some Were Meant for C: The Endurance of an Unmanageable Language (PDF), by Stephen Kell? (Via: http://chneukirchen.org/trivium/)

K3n.

C, still?

Posted Sep 20, 2017 19:46 UTC (Wed) by ncm (guest, #165) [Link] (1 responses)

Thank you for asking.

The paper cited is one in a long line of apologia. There was a time when writing apologia was a respected activity, and apologia were widely persuasive. Although reading old apologia offers a precious glimpse into a lost world, they have ceased to persuade. As well-written as they often were (and remain), too many of the facts they cited have turned out to be falsehoods, and too many of the truisms have turned out, in the fullness of time, to be mere truthiness. (This last term seems quaint now; only a year ago, truth was something even liars pretended to.) Too many of the merits claimed were, in fact, harms, or are merits we may claim without accepting the argument.

In this case, essentially all of its valid arguments apply equally well to C and C++; the author contrasts them with "managed languages". However, he presents as a truism that C is faster than other languages, where we know that well-written C++ is routinely faster than C. In general, though, the arguments are basically irrelevant to the topic of upgrading from C to C++ . Arguments over the merits of "safe" languages, in general, are suspect; the real question is where we expect to get correctness. Testing is nice, and checkers, and validators, but the place to get the pure stuff is by construction. When your language is powerful enough to present facilities (i.e., libraries) that admit only valid operations, without compromising performance, worries over invalid operations creeping in vanish.

C, still?

Posted Sep 21, 2017 5:04 UTC (Thu) by eru (subscriber, #2753) [Link]

When your language is powerful enough to present facilities (i.e., libraries) that admit only valid operations, without compromising performance, worries over invalid operations creeping in vanish.

This I can agree with. But C++ is not that language. My biggest gripe with it is that it cannot protect its abstractions. Where I work, this turns up every time the g++ compiler is upgraded, despite having warnings to the max in mandatory compiler options. The programmers has used the language or its library in a way that happened to work in the old version, but either does not compile in the new version, or crashes. (A contributing problem is also the horrid complexity of modern C++).

C, still?

Posted Sep 22, 2017 9:47 UTC (Fri) by tdz (subscriber, #58733) [Link] (2 responses)

IMHO the author is correct about the benefits of C for any kind of low-level I/O where access to raw data is required or at least beneficial. C++ is in a similar position because for raw-data I/O, it's really just a beefed-up variant of the equivalent C code. But as soon as the programming language favors or requires more I/O abstractions, it looses the advantage that 'managed' and/or 'safe' usually provide.

C, still?

Posted Sep 22, 2017 16:11 UTC (Fri) by ncm (guest, #165) [Link] (1 responses)

> usually provide

Always promise, never provide.

In every case, as noted in the cited article, the language offers some sort of escape hatch to do "unsafe" operations. In this detail they are equivalent to the "safe subset" promoted for C++, that a program steps out of at need.

The relevant difference between languages, for systems programming, is how effectively they can package user-defined abstractions to make it unnecessary for users to step outside the (safe) abstraction. Commonly, certain necessary abstractions can't be expressed as libraries, and so have to be built into the core language, and then are promoted as features "missing" from other languages.

In an otherwise powerful language like Haskell, for example, we see its weakness in resource management papered over with built-in garbage collection, causing the familiar integration problems. When you cannot abstract resource management, abstractions that need to manage resources other than memory necessarily leak, and in integration even memory management leaks.

The Rust project has chosen to provide expressive power, and in many cases better defaults than C++, while making it harder to accidentally do many (but not all) unsafe operations. In ten or twenty years, if it matures well, it may be a good choice for implementing a successor to Linux; but C++ isn't standing still, so the bar is rising.

There is really no way forward for the Linux kernel other than C++. At some point the choice to build as C++ or not will amount to choosing whether to keep or abandon relevance. It's not there yet. It would be better for the project to make the switch before that point.

C, still?

Posted Nov 17, 2017 19:39 UTC (Fri) by marcH (subscriber, #57642) [Link]

> At some point the choice to build as C++ or not will amount to choosing whether to keep or abandon relevance. It's not there yet.

Indeed the competition for the Linux kernel is unfortunately nowhere near yet. In fact I haven't really seen any at all. I bet Rust will pass C++ long before there's any credible one.