13 ms·

The long goodbye to C

83 points by jgrahamc 9y ago

bachmeier 9y ago
"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." Maybe, but there are projects like D's betterC[1] that are designed to remove that reason to use C as well. [1] https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/blog/2017/08/23/d-as-a-better-c/
- krylon 9y ago
  D is a sweet language, but there are lots of CPUs/Microcontrollers for which C compilers are available, but not much else (except assembly).
  - pjmlp 9y ago
    Once upon a time, C was only available in expensive UNIX workstations.
    - krylon 9y ago
      I do not work in embedded systems, so take anything I say with a grain of salt (or more!). If D became available in all of those embedded platforms, I am sure lots of people would rejoice. Or maybe they would just shrug because they would not know what hit them. But it would be their loss, because D is, in many ways, C++ "done right". Which IMHO is a remarkable achievement. Either way, I would not hold my breath for C becoming obsolete in the sense of "no one is using it any more". It is not happy, but for now it is all we've got.
      - scruple 9y ago
        > I am sure lots of people would rejoice I'm one of those people and I spent ~6 years in embedded and I still write C today (though it's no longer my primary language). Of my former co-workers, probably 50 people in total across 4 teams, exactly 0 of them were at all interested in any sort of C alternative. I'd wager less than 6 of them even knew what C alternatives were even picking up steam. If it wasn't talked about by folks like Michael Barr or Embedded magazine, they simply wouldn't have any way of finding out. > Either way, I would not hold my breath for C becoming obsolete I wouldn't either. Call it the old guard, call them greybeards, it really doesn't matter. They're the ones buying chips from vendors that supply C toolchains and compilers. Until that is addressed, none of this talk matters.
        pjmlp 9y ago
        Which is why there is the saying that progress can only be achieved by replacing generations.
- emodendroket 9y ago
  I'm guessing nobody wants to entirely rewrite all of the notable operating systems in the world today.
  - bachmeier 9y ago
    IMO the main advantage of betterC is that you can add new code/partially rewrite old code in D and then integrate it into the existing C project. The limitation (as someone else pointed out) is the possible nonexistence of a D compiler for a given platform.
jackmott 9y ago
https://rationalwiki.org/wiki/Eric_S._Raymond https://rationalwiki.org/wiki/Eric_S._Raymond
- moxious 9y ago
  This article mainly addressed his politics. Crazy or not in the political world, he's a superb software engineer.
  - erikbye 9y ago
    Which software has he engineered superbly?
  - tptacek 9y ago
    Really? Download "reposurgeon" sometime and look at that code (note that it is one of the few examples of substantial code that Raymond has both designed and implemented in the public record for the past several years --- and that Raymond promotes it diligently; for instance, he took what felt like close to 10 minutes out of an NTPsec talk to discuss it). He's _a_ software engineer, there's little question about that. But there are a great many of those.
    - jstimpfle 9y ago
      After a quick skim, looks clean to me. Can you be more precise, what are your complaints?
    - mirceal 9y ago
      13000 lines of python in one file! what could go wrong!
  - gpvos 9y ago
    Superb, I wouldn't say. He is okay though.
  - mwfunk 9y ago
    He’s someone who has written a fair amount of software in his spare time (which is all of it, since his wife’s been supporting him for decades). He’s written some (IMO, at the time) entertaining writings on software development, but I don’t know if the work he has chosen to do or the circumstances under which he does it really qualifies him as a superb engineer. Fundamentally he’s kind of a bullshitter, and it seems like every time I thought he made a good point about something he screws it up by using that point to make some other point that is totally off the rails. He’s disappointing because he seems to have talent and potential to really contribute a lot more than he has, but he just can’t stop drinking his own Kool Aid long enough to be a positive force. IMO, after observing this guy for 25+ years now, as a software developer and a writer on software development, everything he’s done has been 3 steps forward and 2-4 self-inflicted steps back. In politics it’s more like 3 steps back just for starters. I really wish he didn’t have whatever form of narcissism that drives him, because he’s clearly got some talents that could have been used in infinitely more effective and constructive ways over the last few decades. I’ve got to think that there’s some part of him that understands this, that’s always been the most frustrating thing about him. So much squandering of talent, just so he can pat himself on the back all the time. I’d say this applies just as much to his software-related work as it does to his politics. I thought he was great for like 5 years, up until the quadruple whammy of the Hitler thing, his “I’m your worst nightmare” Comdex story that he was so proud of (or maybe that was at CES?), “Thoughts on Sudden Wealth”, and the whole aggrieved shitpiece he wrote about proudly tormenting some poor random Microsoft HR person over the phone. For a lot of people, you only find out what really drives them when you see how they respond to success (or their own perception of success). He revealed A LOT in those years and has doubled down on it ever since.
fhood 9y ago
Oddly enough C never bothered me. It has its purpose, and despite its flaws it still feels elegant. C++ however should be illegal. When do we get to say goodbye to it? Edit/Continuation: I feel like the freedom offered by C works because of it's simplicity, and as a language for embedded systems I still enjoy developing in C. As someone who recently started working primarily in C++ though I am frequently astounded by the choices that were made. And to make things worse, offering C style controllability in a complex OO language doesn't work well. I shouldn't have to feel like I need to read the designers minds to predict how a language will act.
- rwbt 9y ago
  After programming in C++ for nearly a decade, I too came to the same conclusion. I was always told to avoid C (because dangling pointers and what not) but now even though C++ has some things I like, overall I think C is a lot easier to 'think' in. Even though dangling pointers etc are an issue, you'll pick up good habits over time and avoid many usual C issues. I think what replaces C should be something like Nim, which compiles to C and also has great C interop. C++ is definitely not it.
  - qaq 9y ago
    Nim is def. a nice option
    - petre 9y ago
      So is Dlang to anyone who likes Algol style languages, with the added benefit that you can seamlessly use C/C++ code or libraries.
  - baybal2 9y ago
    >dangling pointers C has no standard language provided range checks, and pointer security, but the amount of compiler macroses that do the same/coverage tools/runtime security tools/checks provided by compilers is huge. At least part of "inherent issues" of C that Rust advocates often cite was long solved by these tools long time ago. They are not a bullet proof solutions to lack of security features in C, but neither are the built in checks of novel languages. The amount of NX breakouts, syscall hijackings, clever tricks around range checks in so called secure languages being demonstrated every year confirms that.
ravingraven 9y ago
This showing up next to "LibHTTP: Open Source HTTP Library in C" on the HN front page made me giggle. Someone should start a website a-la bitcoinobituaries for C. C will be around for as long as everything under the sun has a C compiler. If you ask yourself when was the last time you started a C project, ask yourself when was the last time you wanted to write something truly (truly, including embedded) portable instead and there is your answer.
- pjmlp 9y ago
  To kill C, we need to kill UNIX. So until we get to replace POSIX across the board, C will be around. It will take generations.
  - katastic 9y ago
    And replacing POSIX will go just like that xkcd: "There are 8 standards and they all suck. We should make ONE good one to replace them all." ... "There are 9 standards and they all suck. We ..."
  - loeg 9y ago
    We can make unix-alikes in non-C languages, so what's the point of "killing" Unix? I don't see why that's a good goal to have or how it furthers the goal of replacing C.
    - pjmlp 9y ago
      If those UNIX likes have to be compatible with POSIX, they will have to support unsafe APIs, e.g. memcpy.
      - loeg 9y ago
        memcpy is a libc API, as in, for the C language runtime. If your unix-alike does not use C, I don't see why it would need a C runtime. POSIX is clearly a standard for C unixes, but you could imagine a restricted subset of POSIX that didn't govern libc being applicable to a non-C Unix.
moxious 9y ago
It's going to be a loooooooooooooooong goodbye. COBOL is still around for what it's worth. The dominant OS (Linux) is written in C. I'd assert that any language used to implement a widely deployed operating system has at least that operating system's lifetime + 20 years, assuming the OS isn't rewritten. "Re-write Linux in Go" I think would be a massive but classic folly
- pjmlp 9y ago
  Which is why, although I deslike C, I am also very realist than until we get rid of UNIX clones, C will stick around.
  - greenhouse_gas 9y ago
    What does C have to do with Unix? You can write a Unix-like OS in Rust and a Non-Unix like OS in C (or C++[1], like Windows). It happens to be a trope that C would have died if not for Unix[2], but to the best of my memory of reading programming books of the eighties, C's un-safety was a _feature_, not a bug (I remember Java books were _so_ apologetic that Java didn't have points arithmetic). In the days before optimizing compilers and slow computers, the ability to write unsafely manipulate arrays was actually useful when one needed speed (and if one wanted to be a "real hacker", one needed to optimize every byte and instruction.) Now it's true that not every program needed that speed, and quite a few would be willing to trade speed for safety, but no "self respecting real programmer" would allow himself to write in _anything_ that wouldn't let him be that "uber-hacker" (sounds familiar? I guess Resume oriented programming is an old problem). [1]. Before I get the pedants that C++ isn't C, I'd like to remind them that the Windows NT codebase started in the late eighties and early nineties, when C++ _was_ almost like C with classes. [2]. In reality, quite a few languages took off which were not the same language as their OS (for example, Java, Python, C#). If anything, I'd say it's more important that the compiler vendor be the same company as the OS vendor (see Borland's history), but even that seems like a more modern problem (again, see Borland's history)
    - pjmlp 9y ago
      Using C++ with Turbo Vision, OWL, VCL, MFC was hardly C with Classes. I never did manually resource management with them. RAII was already a thing in MS-DOS. Java and C# were pushed by OS vendors.
vortico 9y ago
C is really great for writing format encoders/decoders that easily bind with any scripting or compiled language in existence. The ease of compiling it on all platforms and producing binaries that export simple "function_name" symbols make it still the best choice for delivering a format implementation as widely as possible.
- erik_seaberg 9y ago
  Most decoders are in a position to be attacked with malicious input, which makes C a disastrous choice.
  - vortico 9y ago
    In my experience, most applications of C libraries are used in places where security is irrelevant, but even if it mattered, there are of course ways to write C without carelessly throwing around pointers. For example, an AIFF to WAV converter likely doesn't need to allocate any memory at all, it just takes a buffer with a length and writes to a buffer with a length. It's very easy to prove correctness of a large number of library decoders/encoders, but of course there are others which may be difficult.
shmerl 9y ago
I agree with the sentiment, but not with the idea that Go is a suitable general replacement for C. Rust on the other hand fits that role.
- stmw 9y ago
  And the issue is mostly the garbage collector, not any other language features or compiler optimization improvements. You just can't have GC in a systems language.
  - shmerl 9y ago
    Mostly. Rust also tends to provide explicit control, which makes it more complicated, but aligns more with the approach of C to that. As someone explained to me, it's the reason Rust doesn't have a nice initializer syntax like C++11 for example[1]. 1. http://en.cppreference.com/w/cpp/language/list_initialization http://en.cppreference.com/w/cpp/language/list_initializatio...
    - stmw 9y ago
      But Rust doesn't have a GC, which is why it's in a different class from Go or Java.
    - slavik81 9y ago
      I'm not sure I would call it a nice syntax. std::initializer_list was a questionable addition to C++ because its syntax clashes with other forms of initialization. It ends up creating special cases and complicating generic code. They fixed some of its problems in C++14, and we might see more improvements in C++20, but the entire idea of that syntax creating a special object feels like a mistake.
tptacek 9y ago
I'm not sure there's really much to learn from this post. Raymond is not in fact in a good vantage point to judge the suitability of Go or Rust as "systems languages". His claims to authority in this post are "NTPsec" and GPSD†, but Raymond neither designed nor implemented either of those programs: NTPsec is a hostile fork of ntpd, and GPSD --- which is probably not a good example of a program that makes particularly strenuous demands on its programming language runtime --- was maintained by Russell Nelson, after being written by a different team --- before Raymond claimed it for his resume. In this middle of this article, Raymond claims that Python is suitable largely for single-user applications operating "at human speed". This is so far outside the reality of how Python is used in industry as to call pretty much everything else Raymond writes in the article into question. Surely, somebody else has to have written something better on the trend towards next-generation systems languages. † These are the examples he provides, in this article, by the way.
- dreamcompiler 9y ago
  > Raymond claims that Python is suitable largely for single-user applications operating "at human speed". This is so far outside the reality of how Python is used in industry as to call pretty much everything else Raymond writes in the article into question. Could you elaborate? Are you talking about e.g. numpy and scipy? Python is good at calling C libraries but that doesn't make it good for writing an IP stack or a device driver or an OS. Are you arguing against the "single-user" point or the "human speed" point?
  - tptacek 9y ago
    He didn't say "Python doesn't work well for IP stacks" (although: for special-purpose userspace IP stacks, people have done it). He said "Python only works for single-user human-speed use cases". Which, obviously, ignores the fact that every 3rd west coast SaaS tech company has Python at the core of their stack.
- emodendroket 9y ago
  Isn't that just his typical MO? It's always seemed to me he was more of a hanger-on looking for glory (or perhaps an essayist and advocate, if we want to be a charitable) than a really significant contributor.
sytelus 9y ago
Go isn't systems programming language. As soon as you enforce gc built-in to language, it seizes to be systems programming language.
- pjmlp 9y ago
  Tell that to Niklaus Wirth, Alan Kay, Joe Duffy, Luca Cardelli and quite a few other industry luminaries.
  - sytelus 9y ago
    Go being paddled by industry hot shots doesn't change the facts. A language designed for systems programming must have precise control on everything that goes on. When you are dealing with thousand threads on 100s of cores, every microsecond counts. When you are designing control software for aerial vehicles on embedded devices doing stuff in ISRs, every thing needs to be predictable. No one in their right mind will rely on gc in that kind of systems programming world.
    - abiox 9y ago
      this is a narrow and arbitrary definition of "systems programming". you seem to be describing something closer to hard realtime computing, which is not the same thing.
      - dboreham 9y ago
        Seriously? He's using the term in exactly the way everyone uses it, even Wikipedia : https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
        abiox 9y ago
        if you read your link, even the wikipedia article authors do not restrict the notion to hard realtime computing. it's not really how "everyone" uses it. it's a narrowing that a subset of vocal people have been trying to push, i can only presume for ideological purposes.
deleted 9y ago
[deleted]
gpvos 9y ago
Not sure why he promotes Cx instead of D.
Santosh83 9y ago
> 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. Rust is well suited for OS code if not for the inertia that most OS devs are experts at C and not so in Rust and compiler support. Those two factors are going to become less important going forward, so Rust (with generous 'unsafe') could replace C in its last stronghold too.
- muricula 9y ago
  I don’t believe Rust is ready for OS kernels yet. People have written OS kernels but they really stretch the language to do it. For instance, the default heap allocation API panics on failure, which isn’t something I want my kernel to do. There’s work on a new API which doesn’t do this in nightly rust, but they could completely change all that tomorrow. Additionally, alignment constraints are also really important at that level, but rust doesn’t have a mature way to align structures or arrays. Rust isn’t ready for this space yet.
  - steveklabnik 9y ago
    When you're writing a kernel in Rust, you aren't using the default heap allocation API; you aren't using the allocation API at all. You could then build any sort of allocation strategy you want. You don't need to wait for the new traits, though of course, using them eventually helps with interoperability. You're certainly right about "mature way" wrt alignment, but it's something that can be worked around until then.
  - tetromino_ 9y ago
    Well, C's default heap allocation API is not suitable for kernel mode either. Compare libc's malloc and the kernel's kmalloc, with the fine-grained control [1] over what kind of allocation to perform. [1] https://github.com/spotify/linux/blob/master/include/linux/gfp.h https://github.com/spotify/linux/blob/master/include/linux/g...
throwaway2016a 9y ago
I think it is easy to overestimate the importance of a managed language. Having to manage memory yourself is not that big a burden in many applications. In many cases it is a help. For instance, I had a ETL program I was writing to process 100+ GB files. I pre-allocated all the memory I needed for exactly one row of data and immediately printed out the data when it finished that row (stream style). The entire program processed 100 GB with lightning speed in less than 1K of memory. Maxing out the performance of the disk. Best of all, I only had to free my memory at the end. Completely safe. No danger of double freeing and no extra memory allocation at all. Literally a dozen mallocs at the start and a dozen frees at the end. Could I do that in Go? Sure. Would it have as optimized memory access? Maybe... but probably not. And C my entire program was 200 lines of code and absurdly fast. Don't get me wrong, I love Go. I write programs in Go often. But for simple apps where the code can fit in a single file nothing can beat C. No bloat, no extra memory operations, and a code optimizer that has been being optimized for 30+ years. Go's code optimizer is not even close yet from what I can tell.
- deleted 9y ago
  [deleted]
- isaiahg 9y ago
  Just out of curiosity from someone who started with languages like JavaScript and other languages. But what makes C special for this case? For instance couldn't I achieve the same thing with typed arrays in JavaScript? Sorry if it's a naive question. My experience with C is limited.
  - btrask 9y ago
    If you used Node, you would have IIRC around 40MB (edit: 24MB on my system) of memory overhead before your code even started running. If you are CPU-bound, multiply that by the number of cores you want to use.
  - vvanders 9y ago
    Nope, the main advantage of C/Rust/D/etc is explicit control of memory allocation and placement. 90% of your program performance is going to be dominated by cache usage(unless you're doing something really dumb). With C you can place things next to each other explicitly so that your prefetcher/etc is automatically pulling in the data you need to the L1 cache. Any ref'd/GC'd language is going to make that really hard(not impossible, but you have to jump through a million hoops like sun.misc.unsafe in Java). Look up Data Oriented Design if you're interested in this stuff, Mike Acton does a great job covering it.
clw8 9y ago
I went to a "Public Ivy" about ten years ago and at the time both CE and CS students started with C, CE students sticking with it and CS students moving on to Java. Is this still true for the average public school? Learning C and various Assembly languages and using them to program micros is where everything finally clicked for me. Rust is lovely but I don't ever see it being the CS101 language because of elegant but difficult concepts like lifetimes.
- loeg 9y ago
  UW does Java for both CS and CE and has done since the 00's. There was one optional C and unix class while I was there. Also one mandatory "programming languages" class that introduced functional languages and lisp.
  - djjfjiwe888 9y ago
    Wisconsin or Washington?
- majewsky 9y ago
  > at the time both CE and CS students started with C I was confused there for a second because both "CE" and "CS" literally start with C. By the way, to add another datapoint, I completed a bachelor degree in CS from 2012-2017 (part-time) at a German university, and we used: - C in the first-semester "algorithms and datastructures" course - Haskell in the second-semester "programming" course - Java in the third-semester "software design" course and accompanying fourth-semester lab course - Python (very briefly) in the fifth-semester "information retrieval" course
- pjmlp 9y ago
  My university back in the mid-90's taught Pascal, C++, Smalltalk, Prolog, x86 and MIPS Assembly, Caml Light, PL/SQL, and started doing Java on last year there. Those picking up the optional compiler related lectures, also got an overview around Lisp, Algol, Fortran, Concurrent C, Objective-C, ML, Cobol, Oberon, Modula-2. Nowhere C was taught as such, we were expected to know about it from the C++ lectures.
nice_byte 9y ago
C++ >= 11 is your answer
- deleted 9y ago
  [deleted]
chx 9y ago
There's another thing slowly but inexorably gaining ground: you need to write concurrent code. From your CPU to your cloud, parallel is the new king, much more than before. Any language where two parallel running pieces of code can alter the same variable is not usable for parallel purposes as debugging becomes a special hell. Hail to Erlang and even more, Elixir.
- AstralStorm 9y ago
  The "unsafe" threading has to be available though. Simone primitives like barriers as well. Otherwise you pay the cost when you really do not need to. Just ask people involved in actual places where microseconds matter, such as real time control or high frequency trading. Erlang does not provide these primitives enforcing unnecessary copies in a bunch of places.
Aloha 9y ago
I strongly suspect that even in 50 years, we will still be writing systems and software in a dialect of C - so long as UNIX lives on, C will too. There will probably always be a need in computering for 'Portable Assembly' too, which is another reason C (or C like languages) will never disappear.
baybal2 9y ago
Death of C is like a commercial fusion power. Every 5 years, some specialist comes forward and predicts that C will be obsoleted in the next 5 years. And I think it is even more true for FORTRAN
DmitryOlshansky 9y ago
You should absolutely checkout D language (dlang.org). It’s less stringent compared to Rust’s borrow checker, but also has meta programming capabilities of similar power to macroses. The default is GC manged memory like in Go. However it’s super flexible in that you can go from 100% simple GC-based programming with dynamic arrays and maps to hardcore low-level stuff with manual memory or anything in between (e.g. Ref-Counting as in C++).
AndyKelley 9y ago
Go has a garbage collector and writing code in Rust can be extremely difficult. A third competitor is Zig, which does not guarantee safety, but is designed to make safety much easier. This is explained in more detail in this wiki article, "Why Zig When There is Already C++, D, and Rust?": https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-A...

83 points by jgrahamc 9y ago

"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." Maybe, but there are projects like D's betterC[1] that are designed to remove that reason to use C as well. [1] https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/blog/2017/08/23/d-as-a-better-c/

krylon 9y ago
D is a sweet language, but there are lots of CPUs/Microcontrollers for which C compilers are available, but not much else (except assembly).
- pjmlp 9y ago
  Once upon a time, C was only available in expensive UNIX workstations.
  - krylon 9y ago
    I do not work in embedded systems, so take anything I say with a grain of salt (or more!). If D became available in all of those embedded platforms, I am sure lots of people would rejoice. Or maybe they would just shrug because they would not know what hit them. But it would be their loss, because D is, in many ways, C++ "done right". Which IMHO is a remarkable achievement. Either way, I would not hold my breath for C becoming obsolete in the sense of "no one is using it any more". It is not happy, but for now it is all we've got.
    - scruple 9y ago
      > I am sure lots of people would rejoice I'm one of those people and I spent ~6 years in embedded and I still write C today (though it's no longer my primary language). Of my former co-workers, probably 50 people in total across 4 teams, exactly 0 of them were at all interested in any sort of C alternative. I'd wager less than 6 of them even knew what C alternatives were even picking up steam. If it wasn't talked about by folks like Michael Barr or Embedded magazine, they simply wouldn't have any way of finding out. > Either way, I would not hold my breath for C becoming obsolete I wouldn't either. Call it the old guard, call them greybeards, it really doesn't matter. They're the ones buying chips from vendors that supply C toolchains and compilers. Until that is addressed, none of this talk matters.
      - pjmlp 9y ago
        Which is why there is the saying that progress can only be achieved by replacing generations.
emodendroket 9y ago
I'm guessing nobody wants to entirely rewrite all of the notable operating systems in the world today.
- bachmeier 9y ago
  IMO the main advantage of betterC is that you can add new code/partially rewrite old code in D and then integrate it into the existing C project. The limitation (as someone else pointed out) is the possible nonexistence of a D compiler for a given platform.

jackmott 9y ago

https://rationalwiki.org/wiki/Eric_S._Raymond https://rationalwiki.org/wiki/Eric_S._Raymond

moxious 9y ago
This article mainly addressed his politics. Crazy or not in the political world, he's a superb software engineer.
- erikbye 9y ago
  Which software has he engineered superbly?
- tptacek 9y ago
  Really? Download "reposurgeon" sometime and look at that code (note that it is one of the few examples of substantial code that Raymond has both designed and implemented in the public record for the past several years --- and that Raymond promotes it diligently; for instance, he took what felt like close to 10 minutes out of an NTPsec talk to discuss it). He's _a_ software engineer, there's little question about that. But there are a great many of those.
  - jstimpfle 9y ago
    After a quick skim, looks clean to me. Can you be more precise, what are your complaints?
  - mirceal 9y ago
    13000 lines of python in one file! what could go wrong!
- gpvos 9y ago
  Superb, I wouldn't say. He is okay though.
- mwfunk 9y ago
  He’s someone who has written a fair amount of software in his spare time (which is all of it, since his wife’s been supporting him for decades). He’s written some (IMO, at the time) entertaining writings on software development, but I don’t know if the work he has chosen to do or the circumstances under which he does it really qualifies him as a superb engineer. Fundamentally he’s kind of a bullshitter, and it seems like every time I thought he made a good point about something he screws it up by using that point to make some other point that is totally off the rails. He’s disappointing because he seems to have talent and potential to really contribute a lot more than he has, but he just can’t stop drinking his own Kool Aid long enough to be a positive force. IMO, after observing this guy for 25+ years now, as a software developer and a writer on software development, everything he’s done has been 3 steps forward and 2-4 self-inflicted steps back. In politics it’s more like 3 steps back just for starters. I really wish he didn’t have whatever form of narcissism that drives him, because he’s clearly got some talents that could have been used in infinitely more effective and constructive ways over the last few decades. I’ve got to think that there’s some part of him that understands this, that’s always been the most frustrating thing about him. So much squandering of talent, just so he can pat himself on the back all the time. I’d say this applies just as much to his software-related work as it does to his politics. I thought he was great for like 5 years, up until the quadruple whammy of the Hitler thing, his “I’m your worst nightmare” Comdex story that he was so proud of (or maybe that was at CES?), “Thoughts on Sudden Wealth”, and the whole aggrieved shitpiece he wrote about proudly tormenting some poor random Microsoft HR person over the phone. For a lot of people, you only find out what really drives them when you see how they respond to success (or their own perception of success). He revealed A LOT in those years and has doubled down on it ever since.

fhood 9y ago

Oddly enough C never bothered me. It has its purpose, and despite its flaws it still feels elegant. C++ however should be illegal. When do we get to say goodbye to it? Edit/Continuation: I feel like the freedom offered by C works because of it's simplicity, and as a language for embedded systems I still enjoy developing in C. As someone who recently started working primarily in C++ though I am frequently astounded by the choices that were made. And to make things worse, offering C style controllability in a complex OO language doesn't work well. I shouldn't have to feel like I need to read the designers minds to predict how a language will act.

rwbt 9y ago
After programming in C++ for nearly a decade, I too came to the same conclusion. I was always told to avoid C (because dangling pointers and what not) but now even though C++ has some things I like, overall I think C is a lot easier to 'think' in. Even though dangling pointers etc are an issue, you'll pick up good habits over time and avoid many usual C issues. I think what replaces C should be something like Nim, which compiles to C and also has great C interop. C++ is definitely not it.
- qaq 9y ago
  Nim is def. a nice option
  - petre 9y ago
    So is Dlang to anyone who likes Algol style languages, with the added benefit that you can seamlessly use C/C++ code or libraries.
- baybal2 9y ago
  >dangling pointers C has no standard language provided range checks, and pointer security, but the amount of compiler macroses that do the same/coverage tools/runtime security tools/checks provided by compilers is huge. At least part of "inherent issues" of C that Rust advocates often cite was long solved by these tools long time ago. They are not a bullet proof solutions to lack of security features in C, but neither are the built in checks of novel languages. The amount of NX breakouts, syscall hijackings, clever tricks around range checks in so called secure languages being demonstrated every year confirms that.

ravingraven 9y ago

This showing up next to "LibHTTP: Open Source HTTP Library in C" on the HN front page made me giggle. Someone should start a website a-la bitcoinobituaries for C. C will be around for as long as everything under the sun has a C compiler. If you ask yourself when was the last time you started a C project, ask yourself when was the last time you wanted to write something truly (truly, including embedded) portable instead and there is your answer.

pjmlp 9y ago
To kill C, we need to kill UNIX. So until we get to replace POSIX across the board, C will be around. It will take generations.
- katastic 9y ago
  And replacing POSIX will go just like that xkcd: "There are 8 standards and they all suck. We should make ONE good one to replace them all." ... "There are 9 standards and they all suck. We ..."
- loeg 9y ago
  We can make unix-alikes in non-C languages, so what's the point of "killing" Unix? I don't see why that's a good goal to have or how it furthers the goal of replacing C.
  - pjmlp 9y ago
    If those UNIX likes have to be compatible with POSIX, they will have to support unsafe APIs, e.g. memcpy.
    - loeg 9y ago
      memcpy is a libc API, as in, for the C language runtime. If your unix-alike does not use C, I don't see why it would need a C runtime. POSIX is clearly a standard for C unixes, but you could imagine a restricted subset of POSIX that didn't govern libc being applicable to a non-C Unix.

moxious 9y ago

It's going to be a loooooooooooooooong goodbye. COBOL is still around for what it's worth. The dominant OS (Linux) is written in C. I'd assert that any language used to implement a widely deployed operating system has at least that operating system's lifetime + 20 years, assuming the OS isn't rewritten. "Re-write Linux in Go" I think would be a massive but classic folly

pjmlp 9y ago
Which is why, although I deslike C, I am also very realist than until we get rid of UNIX clones, C will stick around.
- greenhouse_gas 9y ago
  What does C have to do with Unix? You can write a Unix-like OS in Rust and a Non-Unix like OS in C (or C++[1], like Windows). It happens to be a trope that C would have died if not for Unix[2], but to the best of my memory of reading programming books of the eighties, C's un-safety was a _feature_, not a bug (I remember Java books were _so_ apologetic that Java didn't have points arithmetic). In the days before optimizing compilers and slow computers, the ability to write unsafely manipulate arrays was actually useful when one needed speed (and if one wanted to be a "real hacker", one needed to optimize every byte and instruction.) Now it's true that not every program needed that speed, and quite a few would be willing to trade speed for safety, but no "self respecting real programmer" would allow himself to write in _anything_ that wouldn't let him be that "uber-hacker" (sounds familiar? I guess Resume oriented programming is an old problem). [1]. Before I get the pedants that C++ isn't C, I'd like to remind them that the Windows NT codebase started in the late eighties and early nineties, when C++ _was_ almost like C with classes. [2]. In reality, quite a few languages took off which were not the same language as their OS (for example, Java, Python, C#). If anything, I'd say it's more important that the compiler vendor be the same company as the OS vendor (see Borland's history), but even that seems like a more modern problem (again, see Borland's history)
  - pjmlp 9y ago
    Using C++ with Turbo Vision, OWL, VCL, MFC was hardly C with Classes. I never did manually resource management with them. RAII was already a thing in MS-DOS. Java and C# were pushed by OS vendors.

vortico 9y ago

C is really great for writing format encoders/decoders that easily bind with any scripting or compiled language in existence. The ease of compiling it on all platforms and producing binaries that export simple "function_name" symbols make it still the best choice for delivering a format implementation as widely as possible.

erik_seaberg 9y ago
Most decoders are in a position to be attacked with malicious input, which makes C a disastrous choice.
- vortico 9y ago
  In my experience, most applications of C libraries are used in places where security is irrelevant, but even if it mattered, there are of course ways to write C without carelessly throwing around pointers. For example, an AIFF to WAV converter likely doesn't need to allocate any memory at all, it just takes a buffer with a length and writes to a buffer with a length. It's very easy to prove correctness of a large number of library decoders/encoders, but of course there are others which may be difficult.

shmerl 9y ago

I agree with the sentiment, but not with the idea that Go is a suitable general replacement for C. Rust on the other hand fits that role.

stmw 9y ago
And the issue is mostly the garbage collector, not any other language features or compiler optimization improvements. You just can't have GC in a systems language.
- shmerl 9y ago
  Mostly. Rust also tends to provide explicit control, which makes it more complicated, but aligns more with the approach of C to that. As someone explained to me, it's the reason Rust doesn't have a nice initializer syntax like C++11 for example[1]. 1. http://en.cppreference.com/w/cpp/language/list_initialization http://en.cppreference.com/w/cpp/language/list_initializatio...
  - stmw 9y ago
    But Rust doesn't have a GC, which is why it's in a different class from Go or Java.
  - slavik81 9y ago
    I'm not sure I would call it a nice syntax. std::initializer_list was a questionable addition to C++ because its syntax clashes with other forms of initialization. It ends up creating special cases and complicating generic code. They fixed some of its problems in C++14, and we might see more improvements in C++20, but the entire idea of that syntax creating a special object feels like a mistake.

tptacek 9y ago

I'm not sure there's really much to learn from this post. Raymond is not in fact in a good vantage point to judge the suitability of Go or Rust as "systems languages". His claims to authority in this post are "NTPsec" and GPSD†, but Raymond neither designed nor implemented either of those programs: NTPsec is a hostile fork of ntpd, and GPSD --- which is probably not a good example of a program that makes particularly strenuous demands on its programming language runtime --- was maintained by Russell Nelson, after being written by a different team --- before Raymond claimed it for his resume. In this middle of this article, Raymond claims that Python is suitable largely for single-user applications operating "at human speed". This is so far outside the reality of how Python is used in industry as to call pretty much everything else Raymond writes in the article into question. Surely, somebody else has to have written something better on the trend towards next-generation systems languages. † These are the examples he provides, in this article, by the way.

dreamcompiler 9y ago
> Raymond claims that Python is suitable largely for single-user applications operating "at human speed". This is so far outside the reality of how Python is used in industry as to call pretty much everything else Raymond writes in the article into question. Could you elaborate? Are you talking about e.g. numpy and scipy? Python is good at calling C libraries but that doesn't make it good for writing an IP stack or a device driver or an OS. Are you arguing against the "single-user" point or the "human speed" point?
- tptacek 9y ago
  He didn't say "Python doesn't work well for IP stacks" (although: for special-purpose userspace IP stacks, people have done it). He said "Python only works for single-user human-speed use cases". Which, obviously, ignores the fact that every 3rd west coast SaaS tech company has Python at the core of their stack.
emodendroket 9y ago
Isn't that just his typical MO? It's always seemed to me he was more of a hanger-on looking for glory (or perhaps an essayist and advocate, if we want to be a charitable) than a really significant contributor.

sytelus 9y ago

Go isn't systems programming language. As soon as you enforce gc built-in to language, it seizes to be systems programming language.

pjmlp 9y ago
Tell that to Niklaus Wirth, Alan Kay, Joe Duffy, Luca Cardelli and quite a few other industry luminaries.
- sytelus 9y ago
  Go being paddled by industry hot shots doesn't change the facts. A language designed for systems programming must have precise control on everything that goes on. When you are dealing with thousand threads on 100s of cores, every microsecond counts. When you are designing control software for aerial vehicles on embedded devices doing stuff in ISRs, every thing needs to be predictable. No one in their right mind will rely on gc in that kind of systems programming world.
  - abiox 9y ago
    this is a narrow and arbitrary definition of "systems programming". you seem to be describing something closer to hard realtime computing, which is not the same thing.
    - dboreham 9y ago
      Seriously? He's using the term in exactly the way everyone uses it, even Wikipedia : https://en.wikipedia.org/wiki/System_programming https://en.wikipedia.org/wiki/System_programming
      - abiox 9y ago
        if you read your link, even the wikipedia article authors do not restrict the notion to hard realtime computing. it's not really how "everyone" uses it. it's a narrowing that a subset of vocal people have been trying to push, i can only presume for ideological purposes.

deleted 9y ago

[deleted]

gpvos 9y ago

Not sure why he promotes Cx instead of D.

Santosh83 9y ago

> 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. Rust is well suited for OS code if not for the inertia that most OS devs are experts at C and not so in Rust and compiler support. Those two factors are going to become less important going forward, so Rust (with generous 'unsafe') could replace C in its last stronghold too.

muricula 9y ago
I don’t believe Rust is ready for OS kernels yet. People have written OS kernels but they really stretch the language to do it. For instance, the default heap allocation API panics on failure, which isn’t something I want my kernel to do. There’s work on a new API which doesn’t do this in nightly rust, but they could completely change all that tomorrow. Additionally, alignment constraints are also really important at that level, but rust doesn’t have a mature way to align structures or arrays. Rust isn’t ready for this space yet.
- steveklabnik 9y ago
  When you're writing a kernel in Rust, you aren't using the default heap allocation API; you aren't using the allocation API at all. You could then build any sort of allocation strategy you want. You don't need to wait for the new traits, though of course, using them eventually helps with interoperability. You're certainly right about "mature way" wrt alignment, but it's something that can be worked around until then.
- tetromino_ 9y ago
  Well, C's default heap allocation API is not suitable for kernel mode either. Compare libc's malloc and the kernel's kmalloc, with the fine-grained control [1] over what kind of allocation to perform. [1] https://github.com/spotify/linux/blob/master/include/linux/gfp.h https://github.com/spotify/linux/blob/master/include/linux/g...

throwaway2016a 9y ago

I think it is easy to overestimate the importance of a managed language. Having to manage memory yourself is not that big a burden in many applications. In many cases it is a help. For instance, I had a ETL program I was writing to process 100+ GB files. I pre-allocated all the memory I needed for exactly one row of data and immediately printed out the data when it finished that row (stream style). The entire program processed 100 GB with lightning speed in less than 1K of memory. Maxing out the performance of the disk. Best of all, I only had to free my memory at the end. Completely safe. No danger of double freeing and no extra memory allocation at all. Literally a dozen mallocs at the start and a dozen frees at the end. Could I do that in Go? Sure. Would it have as optimized memory access? Maybe... but probably not. And C my entire program was 200 lines of code and absurdly fast. Don't get me wrong, I love Go. I write programs in Go often. But for simple apps where the code can fit in a single file nothing can beat C. No bloat, no extra memory operations, and a code optimizer that has been being optimized for 30+ years. Go's code optimizer is not even close yet from what I can tell.

deleted 9y ago
[deleted]
isaiahg 9y ago
Just out of curiosity from someone who started with languages like JavaScript and other languages. But what makes C special for this case? For instance couldn't I achieve the same thing with typed arrays in JavaScript? Sorry if it's a naive question. My experience with C is limited.
- btrask 9y ago
  If you used Node, you would have IIRC around 40MB (edit: 24MB on my system) of memory overhead before your code even started running. If you are CPU-bound, multiply that by the number of cores you want to use.
- vvanders 9y ago
  Nope, the main advantage of C/Rust/D/etc is explicit control of memory allocation and placement. 90% of your program performance is going to be dominated by cache usage(unless you're doing something really dumb). With C you can place things next to each other explicitly so that your prefetcher/etc is automatically pulling in the data you need to the L1 cache. Any ref'd/GC'd language is going to make that really hard(not impossible, but you have to jump through a million hoops like sun.misc.unsafe in Java). Look up Data Oriented Design if you're interested in this stuff, Mike Acton does a great job covering it.

clw8 9y ago

I went to a "Public Ivy" about ten years ago and at the time both CE and CS students started with C, CE students sticking with it and CS students moving on to Java. Is this still true for the average public school? Learning C and various Assembly languages and using them to program micros is where everything finally clicked for me. Rust is lovely but I don't ever see it being the CS101 language because of elegant but difficult concepts like lifetimes.

loeg 9y ago
UW does Java for both CS and CE and has done since the 00's. There was one optional C and unix class while I was there. Also one mandatory "programming languages" class that introduced functional languages and lisp.
- djjfjiwe888 9y ago
  Wisconsin or Washington?
majewsky 9y ago
> at the time both CE and CS students started with C I was confused there for a second because both "CE" and "CS" literally start with C. By the way, to add another datapoint, I completed a bachelor degree in CS from 2012-2017 (part-time) at a German university, and we used: - C in the first-semester "algorithms and datastructures" course - Haskell in the second-semester "programming" course - Java in the third-semester "software design" course and accompanying fourth-semester lab course - Python (very briefly) in the fifth-semester "information retrieval" course
pjmlp 9y ago
My university back in the mid-90's taught Pascal, C++, Smalltalk, Prolog, x86 and MIPS Assembly, Caml Light, PL/SQL, and started doing Java on last year there. Those picking up the optional compiler related lectures, also got an overview around Lisp, Algol, Fortran, Concurrent C, Objective-C, ML, Cobol, Oberon, Modula-2. Nowhere C was taught as such, we were expected to know about it from the C++ lectures.

nice_byte 9y ago

C++ >= 11 is your answer

deleted 9y ago
[deleted]

chx 9y ago

There's another thing slowly but inexorably gaining ground: you need to write concurrent code. From your CPU to your cloud, parallel is the new king, much more than before. Any language where two parallel running pieces of code can alter the same variable is not usable for parallel purposes as debugging becomes a special hell. Hail to Erlang and even more, Elixir.

AstralStorm 9y ago
The "unsafe" threading has to be available though. Simone primitives like barriers as well. Otherwise you pay the cost when you really do not need to. Just ask people involved in actual places where microseconds matter, such as real time control or high frequency trading. Erlang does not provide these primitives enforcing unnecessary copies in a bunch of places.

Aloha 9y ago

I strongly suspect that even in 50 years, we will still be writing systems and software in a dialect of C - so long as UNIX lives on, C will too. There will probably always be a need in computering for 'Portable Assembly' too, which is another reason C (or C like languages) will never disappear.

baybal2 9y ago

Death of C is like a commercial fusion power. Every 5 years, some specialist comes forward and predicts that C will be obsoleted in the next 5 years. And I think it is even more true for FORTRAN

DmitryOlshansky 9y ago

You should absolutely checkout D language (dlang.org). It’s less stringent compared to Rust’s borrow checker, but also has meta programming capabilities of similar power to macroses. The default is GC manged memory like in Go. However it’s super flexible in that you can go from 100% simple GC-based programming with dynamic arrays and maps to hardcore low-level stuff with manual memory or anything in between (e.g. Ref-Counting as in C++).

AndyKelley 9y ago

Go has a garbage collector and writing code in Rust can be extremely difficult. A third competitor is Zig, which does not guarantee safety, but is designed to make safety much easier. This is explained in more detail in this wiki article, "Why Zig When There is Already C++, D, and Rust?": https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-Already-CPP%2C-D%2C-and-Rust%3F https://github.com/zig-lang/zig/wiki/Why-Zig-When-There-is-A...