{"id":7711,"date":"2017-11-07T19:54:57","date_gmt":"2017-11-08T00:54:57","guid":{"rendered":"http:\/\/esr.ibiblio.org\/?p=7711"},"modified":"2017-11-10T16:00:16","modified_gmt":"2017-11-10T21:00:16","slug":"the-long-goodbye-to-c","status":"publish","type":"post","link":"http:\/\/esr.ibiblio.org\/?p=7711","title":{"rendered":"The long goodbye to C"},"content":{"rendered":"<p>I was thinking a couple of days ago about the new wave of systems languages now challenging C for its place at the top of the systems-programming heap &#8211; Go and Rust, in particular. I reached a startling realization &#8211; I have 35 years of experience in C. I write C code pretty much every week, but I can no longer remember when I last <em>started a new project<\/em> in C!<\/p>\n<p>If this seems completely un-startling to you, you&#8217;re not a systems programmer.  Yes, I know there are a lot of you out there beavering away at much higher-level languages.  But I spend most of my time down in the guts of things like NTPsec and GPSD and giflib.  Mastery of C has been one of the defining skills of my specialty for decades.  And now, not only do I not use C for new code, I can&#8217;t clearly remember when I stopped doing so. And&#8230;looking back, I don&#8217;t think it was in this century.<\/p>\n<p>That&#8217;s a helluva thing to have sneak up on me when &#8220;C expert&#8221; is one of the things you&#8217;d be most likely to hear if you asked me for my five most central software technical skills.  It prompts some thought, it does.  What future does C have? Could we already be living in a COBOL-like aftermath of C&#8217;s greatest days?<\/p>\n<p><!--more--><\/p>\n<p>I started to program just a few years before the explosive spread of C swamped assembler and pretty much every other compiled language out of mainstream existence. I&#8217;d put that transition between about 1982 and 1985.  Before that, there were multiple compiled languages vying for a working programmer&#8217;s attention, with no clear leader among them; after, most of the minor ones were simply wiped out. The majors (FORTRAN, Pascal, COBOL) were either confined to legacy code, retreated to single-platform fortresses, or simply ran on inertia under increasing pressure from C around the edges of their domains.<\/p>\n<p>Then it stayed that way for nearly thirty years.  Yes, there was motion in applications programming; Java, Perl, Python, and various less successful contenders.  Early on these affected what I did very little, in large part because their runtime overhead was too high for practicality on the hardware of the time.  Then, of course, there was the lock-in effect of C&#8217;s success; to link to any of the vast mass of pre-existing C you had to write new code in C (several scripting languages tried to break that barrier, but only Python would have significant success at it).<\/p>\n<p>In retrospect I should have been alert to the larger implications when I first found myself, in 1997, writing a significant application in a scripting language. It was a librarian&#8217;s assistant for an early source-code distribution hub called Sunsite; the language was Perl.<\/p>\n<p>This application was all text-bashing that only needed to respond at human speed (on the close order of 0.1s), and so was obviously silly to do in C or any other language without dynamic allocation and a real string type. But I thought of it as an experiment and would not have predicted at the time that almost never again would I type &#8220;int main(int argc, char **argv)&#8221; into the first file of a new project.<\/p>\n<p>I say &#8220;almost&#8221; mainly because of <a href=\"http:\/\/sng.sourceforge.net\/\">SNG<\/a> in 1999. I think that was my last fresh start in C; all the new C I wrote after that was for projects with a 20th-century history in C that I was contributing to or became the maintainer of &#8211; like GPSD or NTPsec.<\/p>\n<p>By the time I wrote SNG in C I really shouldn&#8217;t have. Because what was happening in the background was that the relentless cycling of Moore&#8217;s Law had driven the cost of compute cycles cheap enough to make the runtime overhead of a language like Perl a non-issue.  As little as three years later, I would have not have hesitated before writing SNG in Python rather than C.<\/p>\n<p>Learning Python in 1997 was quite the watershed event for me. It was wonderful &#8211; like having the Lisp of my earliest years back, but with good libraries! And a full POSIX binding! And an object system that didn&#8217;t suck!  Python didn&#8217;t drove C out of my toolkit, but I quickly learned to write Python when I could and C only when I must.<\/p>\n<p>(It was after this that I began to feature what I called &#8220;the harsh lesson of Perl&#8221; in my talks &#8211; that is, any new language that ships without a full POSIX binding semantically equivalent to C&#8217;s <em>will fail.<\/em>.  CS history is littered with the corpses of academic languages whose authors did not grasp this necessity.)<\/p>\n<p>It might be too obvious to need saying, but a major part of Python&#8217;s pull was simply that when writing in it I never had to worry about the memory-management problems and core-dump crashes that are such wearying regular a part of a C programmer&#8217;s life. The unobvious thing is the timing &#8211; in the late 1990s the cost-vs.risk tradeoff in applications and the kind of non-kernel system-service code I usually write definitively tilted towards paying the overhead of a language with automatic management in order to eliminate that class of defects.  Not long before that (certainly as late as 1990) that overhead was very often unaffordable; Moore&#8217;s law hadn&#8217;t cranked enough cycles yet.<\/p>\n<p>Preferring Python over C &#8211; and migrating C code to Python whenever I could get away with it  was a spectacularly successful complexity-reduction strategy. I began to apply it in GPSD and did it systematically in NTPsec.  This was a significant part of how we were able to cut the bulk of the NTP codebase by a factor of four.<\/p>\n<p>But I&#8217;m not here to talk about Python today. It didn&#8217;t have to be Python that ended my use of C in new programs by 2000; while I still think it beats its competition like a dusty carpet, any of the new-school dynamic languages of the time could have pulled me away from C.  There&#8217;s probably a nearby alternate timeline where I write a lot of Java.<\/p>\n<p>I&#8217;m writing this reminiscence in part because I don&#8217;t think I&#8217;m anything like unique.  I think the same transition was probably changing the coding habits of a lot of old C hands near the turn of the century, and very likely most of us were as unaware of it at the time as I was. <\/p>\n<p>The fact is that after 2000, though I did still the bulk of my work in C\/C++ on projects like GPSD and Battle for Wesnoth and NTPsec, all my new program starts were in Python.  <\/p>\n<p>Often these were projects that might well have been completely impractical in C. I speak of projects like <a href=\"http:\/\/www.catb.org\/esr\/reposurgeon\/\">reposurgeon<\/a> and <a href=\"http:\/\/www.catb.org\/esr\/doclifter\/\">doclifter<\/a>, in particular; trying to do these in C, with its limited data-type ontology and its extreme vulnerability to low-level data-management issues, would have been horrifying and probably doomed. <\/p>\n<p>But even for smaller stuff &#8211; things that might have been practical in C &#8211; I reached for Python, because why work harder and deal with more core-dump bugs than you have to? Until near the end of last year, when I tried to start a project in Rust and wrote my <a href=\"http:\/\/www.catb.org\/esr\/loccount\/\">first successful small project in Go.<\/a><\/p>\n<p>Again, though I&#8217;m talking about my personal experience here, I think it reflects larger trends pretty well, more anticipating than following them. I was an early Python adopter back in &#8217;98, and statistics from <a href=\"https:\/\/www.tiobe.com\/tiobe-index\/\">TIOBE<\/a> tell me I did my first Go project within months of when it broke out from being a niche language used mainly at the corporate shop that originated it.<\/p>\n<p>More generally: Only now are the first languages that directly challenge C for its traditional turf looking viable. My filter for that is pretty simple &#8211; a C challenger is only &#8220;viable&#8221; if you could propose to a old C hand like me that C programming is No Longer Allowed, here&#8217;s an automated translator that lifts C to the new language, now get <em>all your usual work done<\/em> &#8211; and the old hand would smile happily.<\/p>\n<p>Python and its kin aren&#8217;t good enough for that.  Trying to implement (for example) NTPsec on Python would be a disaster, undone by high runtime overhead and latency variations due to GC. Python is good enough for code that only has to respond to a single user at human speed, but not usually for code that has to respond at <em>machine speed<\/em> &#8211; especially under heavy multiuser loads. It&#8217;s not just my judgment saying this &#8211; Go only <em>exists<\/em> because Google, then Python&#8217;s major backer, hit the same wall.<\/p>\n<p>So Go is designed for the C-like jobs Python can&#8217;t handle. It&#8217;s too bad we don&#8217;t actually have an automatic code lifter, but the thought of doing all my systems stuff in Go doesn&#8217;t scare me. In fact I&#8217;m quite happy with the idea.  My C chops are still largely applicable and I get garbage collection and really sweet concurrency primitives too, what&#8217;s not to like?<\/p>\n<p>(There&#8217;s more about my first Go experience <a href=\"https:\/\/blog.ntpsec.org\/2017\/02\/07\/grappling-with-go.html\">here<\/a>.)<\/p>\n<p>I&#8217;d like to include Rust under &#8220;reasons C is growing obsolete&#8221;, but having studied and tried to code in the language I find <a href=\"http:\/\/esr.ibiblio.org\/?p=7303\">it&#8217;s just not ready yet.<\/a>.  Maybe in five years.<\/p>\n<p>As 2017 is drawing to a close, we have one relatively mature language that looks like a plausible C successor over most of C&#8217;s application range (I&#8217;ll be more precise about that in a bit) and an awkward youngster that might complete successfully in a few years.<\/p>\n<p>That&#8217;s actually huge.  Though it may be hard to see just how huge until you lift your head out of current events and take a longer perspective. We went <em>thirty years<\/em> &#8211; most of my time in the field &#8211; without any plausible C successor, nor any real vision of what a post-C technology platform for systems programming might look like.  Now we have two such visions&#8230;<\/p>\n<p>&#8230;and there is another. I have a friend working on a language he calls &#8220;Cx&#8221; which is C with minimal changes for type safety; the goal of his project is explicitly to produce a code lifter that, with minimal human assistance, can pull up legacy C codebases. I won&#8217;t name him so he doesn&#8217;t get stuck in a situation where he might be overpromising, but the approach looks sound to me and I&#8217;m trying to get him more funding.<\/p>\n<p>So, now I can see three plausible paths out of C.  Two years ago I couldn&#8217;t see any.  I repeat: this is huge.<\/p>\n<p>Am I predicting the imminent extinction of C?  No.  For the foreseeable future I think it will retain a pretty firm grip on OS kernels and device firmware. There, the old imperative to squeeze out maximum performance even if it means using an unsafe language still has force.<\/p>\n<p>What&#8217;s opening up now is the space just above that that I usually play in &#8211; projects like GPSD and NTPsec, system services and daemons that would historically have been written in C as a matter of course.  Other good examples of the sort of thing I mean are DNS servers and mail transport agents &#8211; system programs that need to communicate and handle transactions at at machine speed, not human speed.<\/p>\n<p>It is now possible to glimpse a future in which all that code is written in specific C replacements with strong memory-safety properties.  Go, or Rust, or Cx &#8211; any way you slice it, C&#8217;s hold is slipping.  Like, if I were clean-starting an NTP implementation today, I&#8217;d do it in Go without any hesitation at all.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I was thinking a couple of days ago about the new wave of systems languages now challenging C for its place at the top of the systems-programming heap &#8211; Go and Rust, in particular. I reached a startling realization &#8211; I have 35 years of experience in C. I write C code pretty much every&hellip; <a class=\"more-link\" href=\"http:\/\/esr.ibiblio.org\/?p=7711\">Continue reading <span class=\"screen-reader-text\">The long goodbye to C<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23,13],"tags":[],"class_list":["post-7711","post","type-post","status-publish","format-standard","hentry","category-hacker-culture","category-software","entry"],"_links":{"self":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/7711","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7711"}],"version-history":[{"count":6,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/7711\/revisions"}],"predecessor-version":[{"id":7723,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=\/wp\/v2\/posts\/7711\/revisions\/7723"}],"wp:attachment":[{"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7711"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7711"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/esr.ibiblio.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7711"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}