20 ms·

50 years of C, the good, the bad and the ugly [video]

156 points by enduku 4y ago

fjfaase 4y ago
His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.
- jvanderbot 4y ago
  There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment. I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code. I would be perfectly happy to see many hardened C libraries become the foundation of the next gen systems/ embedded languages. It does bother me slightly when we abandon the past entirely and attempt to "rewrite it in X"
  - jacquesm 4y ago
    In part that is because once a piece of software has been part of a certification process it can be very hard to replace it by something newer, no matter how shiny or how much faster. You can see quite a bit of this in aerospace, civil engineering and so on. Nobody wants to be the one to replace the Fortran based FEA package with something novel and end up being liable for a bug.
  - fjfaase 4y ago
    No, I was not being facetious. I am not a regular user of Python, mostly have been writing/maintaining software in C++ and (in the past three years) C#. I came across it because a colleague (fluent in Python) had used scipy.interpolate in some experimentation and now the algorithm he came up with has to be implemented in C#, so I investigated whether scipy.interpolate could be called from C# and then found out that its source was in Fortran. But just like Fortran is still used for nearly every math-intense library, mostly invisible for most of the users, I suspect that C will still be around in 50 years from now. I agree, with his observation that C should be no longer your language of choice for new projects. I personally still prefer using C/C++ for my private software projects, simply because it is the language I am most fluent in. This year I used it for AoC.
    - auxym 4y ago
      Significant chunks of numpy and scipy, the "main" python packages for numerical algorithms, are wrappers around classic libraries such as BLAS, LAPACK and ARPACK, which are Fortran. Fortran was the de-facto language of scientific and numerical programming for a long time, back to the 60s even. These libraries are battle tested more than anything else out there, they literally have decades behind them, so they are industry standard and are used wherever possible.
- Decabytes 4y ago
  I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that make it annoying to program in. But since Zig 1.0 is unlikely until 2026 I'd say we wouldn't start seeing Zig majorly displace any C programs until about ten years after 1.0, which would be 2036. Rust 1.0 was in 2015 and we are just starting to see it in the Linux kernel ~ 8 years out, so that seems like a good timeline. Then just give it another 40 years and I could see a future where Zig and Rust replace all code where C is currently used. Sure there might be some ancient legacy systems that use C, but just like COBOL, would not be something that you would come across unless you wanted to.
  - keewee7 4y ago
    Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.
    - ptato 4y ago
      the self-hosted rewrite took a long time so it felt like the project had stalled for the past ~year. the team has started working on new features like the package manager, though.
  - addaon 4y ago
    Is there any other systems language that's even moving towards a mature ecosystem with a compiler like CompCert? It feels like this is still decades away for any realistic competitor to C.
  - zozbot234 4y ago
    SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.
- AstixAndBelix 4y ago
  We can replace COBOL with a Java backend to keep the enterprise feeling going, but what would C's replacement be in this case?
  - pjmlp 4y ago
    C++ for starters, would already be an improvment, provided string, array and vector classes with bounds checking, get used instead of raw C pointers. Alongside RAII for resource management.
    - youarethejoke 4y ago
      For most embedded stuff those are just extra hassle and not worth it. C and its raw pointers and are really all you need most of the time. The need to have some discipline and expertise to produce solid code with confidence is not a bad thing in the embedded domain. If the code truly is critical you need to dive deep into verification techniques anyway.
      - pjmlp 4y ago
        Sure we all know that the S in IoT stands for security.
      - timbit42 4y ago
        Rust has already begun to replace C in the embedded space.
  - timbit42 4y ago
    Rust is already replacing C and C++. Ada is too. As the importance of safety increases, more safe languages will appear that can replace C and C++.
- Sakos 4y ago
  Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.
  - nousermane 4y ago
    > Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
    - c7DJTLrn 4y ago
      Only a decade? I don't think so. AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.
      - deleted 4y ago
        [deleted]
      - michaelsshaw 4y ago
        This right here. Rust only JUST got added to the kernel in 6.0 and I doubt that it will replace 30 years of C development any time soon.
      - mustache_kimono 4y ago
        > AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C. Do you have a cite for this? I hadn't heard this at all.
        c7DJTLrn 4y ago
        Apologies, I can't find a source. I probably read it on LWN somewhere. Linus wouldn't dip both feet into the water at the same time. I'm confident he's said that the kernel needs to be buildable without Rust if need be.
- sylware 4y ago
  C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-life alternative with a small team of averagely skilled devs in a reasonable amount of time. This language should build on C though: no enum/typedef/_generic/switch/etc, only 1 loop keyword (loop{}) only explicit sized types, no integer promotion, no implicit casts (except maybe void* pointers but number literal casts should be) but explicit casts (compile-time and runtime, without that horrible c++ syntax), explicit compile-time const (we have only runtime consts which could be optimized as compile-time consts), enforce extern for functions (and don't try to put the binary format, elf/coff/etc, semantics into the language syntax or worse, the OS interface semantics), etc. With enough discipline (and compiler warnings), we could get close to such language. I did not check the latest and greatest rust syntax, but is what's above its explicit goals? That said, I am a "everything in 64bits RISC-V assembly with x86_64/arm64 legacy ports kind of guy"... if RISC-V is successful (I wish). We could think of high-level language interpreters (coded in assembly, for instance a RISC-V coded python/lua/javascript/etc interpreters).
  - tristanbvk 4y ago
    These are good ideas. The simplicity here is what I am going for.
    - sylware 4y ago
      On the long run, it all depends on syntax stability which is tightly coupled with its complexity. The "benchmark" to run to evaluate syntax complexity toxicity, for a compiled language, is how long an alternative compiler written by a small teams of averagely skilled devs, or even one individual averagely skilled dev, can stay a "real life" "working" alternative. Mid-term/long-term planned obsolescence of computer language syntax is really... Oh, and in my previous post: for compile time constants we can use static consts, my bad.
  - 4y ago
- pjmlp 4y ago
  It won't go away, but just like it happens with COBOL, Fortran, and PL/I, you won't see anyone dreaming of coding C until the end of their working days. Or maybe they will, given how much consultants in those languages happen to be paid, as no one else wants to touch them.
  - pantalaimon 4y ago
    But coding C is actually fun!
    - Ygg2 4y ago
      Sure. But debugging sure isn't. Null, null terminated strings, data races, segfaults...
      - Koshkin 4y ago
        No, no - debugging is actually where all the fun is!
        Ygg2 4y ago
        I'm not masochistic enough, I guess.
  - rightbyte 4y ago
    > you won't see anyone dreaming of coding C until the end of their working days. I do dream about that. Just being able to tag along while some programmers learn their Xth framework as a language. Maybe someday I might concede and move on from C89 to C99.
    - diydsp 4y ago
      Same here. Ive got so much experience and libraries ive written i can marshall. They've been ported across small and large platforms since before github and google. Ive been maintaining them since the 5.25" disk age. New C projects aren't precarious to me. Watching a bunch of architects with no embedded experience try to make C++ happen on microcontrollers in the other hand...
- flohofwoe 4y ago
  A good bet is that a technology will be around at least as long as it has been around (I think there's also a 'named law' for it). So I fully expect C to be around in one way or another for the next 50 years, it probably won't be as important anymore, just as COBOL or Fortran are not as important as they used to be. One reason for C to disappear completely would be if computer architectures would change so much that current programming languages no longer even map to those new architectures (e.g. all the existing programming languages would need to be dumped anyway).
  - ReactiveJelly 4y ago
    https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect > The Lindy effect (also known as Lindy's Law[1]) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.
    - timbit42 4y ago
      While C and C++ have been around longer than COBOL was when building new systems it it was halted, at least COBOL does its job well while C and C++ don't due to their lack of safety. Also, COBOL is more difficult to replace than C and C++ are. I expect C and C++ code to start being seen as dangerous and money will be spent to eradicate it due to its potential to be a security risk in this online world.
- hgs3 4y ago
  C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want a safer C should design a new hardware architecture with a "safe" assembly language and a new low-level language that targets it.
  - sirsinsalot 4y ago
    Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.
    - KerrAvon 4y ago
      Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will allow you to avoid certain classes of security bugs completely. I don’t think C is even merely adequate for anything at this point; defaulting to memory safety is table stakes in any domain where C was once dominant.
      - Koshkin 4y ago
        > C.E. There.
      - fncslothouber 4y ago
        Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.
- kovac 4y ago
  Can C really completely go away as long as there's embedded programming? Are there any other alternatives for that domain?
  - Tomte 4y ago
    There are embedded devices programmed in other languages, you know, and there have been for decades. In Ada, for example. Which is an even better fit to the domain than C (better ways to describe hardware idiosyncracies).
  - Zagitta 4y ago
    Rust is rapidly picking up steam in the embedded sphere :-) Unfortunately it's an industry with a lot of stubborn old people so I don't see any major changes happening until they've retired but I'm willing to bet that async is going to revolutionize embedded development. Being able to await interrupts and doing efficient cooperative scheduling while writing straight forward code is a massive QoL improvement which is what embassy is enabling: https://embassy.dev/ https://embassy.dev/
  - pjmlp 4y ago
    Yes, compilers for C++, BASIC, Pascal, Ada are around, mostly commercial and people pay to keep those companies in business, for powerfull microcontrollers where real time GC is an option, there are Oberon, .NET and Java as well. There are surelly other factors that weight in using C, but not for lack of options (in many cases).
  - KnowOneYouNo 4y ago
    Ada is a much better and modern alternative for embedded, real-time and/or systems programming. Its mature, (although still evolving) and very scalable from very, very small to very, very large systems. It also supports interoperability with C and C++. It is a primary language in GCC. See https://ada-lang.io/ https://ada-lang.io/ and https://learn.adacore.com/ https://learn.adacore.com/ Unfortunately Ada is held back by a genuine lack of awareness and some old misinformation baggage.
    - 4y ago
- jillesvangurp 4y ago
  In a way, it's already happening. Many big tech companies are now defaulting to other languages than C and are actively discouraging the use of C or C++ for new code. They still have a big vested interest in maintaining existing code of course. That's not going to disappear overnight obviously.
  - pillefitz 4y ago
    Do you have examples? Is it all going towards Rust or are there other big tech-backed contenders?
    - timbit42 4y ago
      I read recently that parts of the code for Artemis are written in Ada. Ada is also used on the ISS. Makes me wonder who besides NASA might be using Ada due to its' safety.
- jcranmer 4y ago
  My prediction is that C will die off as a language long before Fortran and COBOL. What keeps a language like Fortran alive is that it is used in an application niche where rewriting is done at best ship-of-Theseus style, and the friction of using a new language for a component far outweighs the benefits of doing so (weather models are a good example here). For COBOL, it remains in applications where the cost of a switch or rewrite includes a low risk of catastrophic, and therefore expensive, failure (see Southwest Airlines for a very public and recent example of such a failure). C does have a similar kind of niche at first glance: systems programming is of course conservative, rewriting everything is unlikely, and of course, C is the language used for ABI. Except on closer inspection, that moat is remarkably shallow. Being the language of ABI means that every competitor language has some way to speak C guaranteed, so the friction of rewriting systems software Ship-of-Theseus-style is much lower (though still nonzero). Systems software is rewritten from scratch on a much higher cadence: in the last 20 years or so, most of the userspace system glue for Linux has been replaced (e.g., systemd, iproute2, pulseaudio, wayland). And we've learned over the past few decades that there's no practical way to fix C's fundamental unsafety issues with software engineering practices, and C's committee is too conservative to consider retrofitting the necessary features to be able to fix unsafety at a language level (to say nothing of getting people to use it). There is already a small clutch of languages that can serve C's niches that don't have the same fundamental unsafety issues, and right now, we're sort of at an experimental stage of system software trying them out. It's not unreasonable to believe that within a decade or so, one or more of these languages would be considered a standard, safe choice for implementing new systems software--and the use of C in new projects will start dropping. At some point, the proliferation of non-C systems projects will make people point out that having these components talk through C's ABI is too limited in functionality, and a system will change its ABI from C to some other language. And once it is no longer the language of ABI, C will lack its moat that keeps it alive, and it will start dying, though its death will be a slow, agonizing death.
- Wadajot 4y ago
  > that happens to be programmed in Fortran. SciPy is a highly optimized library and Fortran is faster than C for some tasks: https://stackoverflow.com/a/146186/3383640 https://stackoverflow.com/a/146186/3383640
- Tozen 4y ago
  The problem is that there isn't anything to replace C, that would be acceptable enough. C has become a quasi protocol, and used in exchanges between languages. One could argue it's better for newer languages to embrace and excel in interop with C, while providing more advantages, being safer in comparison, or greater ease of use. As is arguably the case with Vlang, Dlang, Nim, etc... If anything, C may still be going strong for another 20 to 30 years.
jacquesm 4y ago
Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.
- pjmlp 4y ago
  Most sane Borland customers were using C++ alongside Object Windows Library, not raw C alongside Win16. Even Petzold embraced C++, even if superficially, "This third edition has several changes. First, all programs are now compilable with either the Microsoft or the Borland compiler. All make files are generic and use environment variables for compiler flags, link libraries, and so forth. Second, all programs are now compilable in C++ mode. Although I don’t use any C++ specific features, compiling first in C++ mode is helpful if C++ features are to be added later to the code" -- https://archive.org/details/programming-windows-31-3rd-ed/page/n9/mode/2up https://archive.org/details/programming-windows-31-3rd-ed/pa...
  - jacquesm 4y ago
    > Most sane Borland customers Veiled insult noted ;) I used both, but TurboC was a real game changer for me. I came from the ST using MWC and ended up in very unfamiliar territory on Windows, Borland TurboC made all the difference for me. It allowed me to be productive on an unfamiliar platform, compiles were absolutely lightning fast compared to anything the competition put out and was rock solid. Edit: I just realized I still have ctrl-f9 more or less in my muscle memory. It's been decades...
  - jacquesm 4y ago
    One day later: some more thoughts on this, I think the biggest reason to pick Borland was bluntly put the price. There was simply nothing else that came even close to being that affordable and, more importantly, that would run on my relatively anemic machine. I was dirt poor back then, my computer didn't even have a case, it was essentially a motherboard and a power supply bolted to a steel frame of one of those office folder hanger carts (I don't know what those are called in English, but they were pretty common in the days of paper file folders). I just plugged cards into the top and a harddrive (a 20 MB MFM Seagate which cost as much as my car) was sitting loose on the same base with some cables to keep it connected to the motherboard. It was about as ugly as it could be but it worked and I was pretty happy with it. Happy New Year by the way, if you are still up and reading this!
JonChesterfield 4y ago
I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.
- rightbyte 4y ago
  I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
  - pjmlp 4y ago
    C has enough UB of its own, no need to bring C++ into the picture.
    - rightbyte 4y ago
      I meant that the shared compiler code with Cpp is the problem. At least in gcc. I don't know about Clang.
  - JonChesterfield 4y ago
    I attribute it to benchmarks. Spec and the like. Where you can indeed make the benchmarks faster by leaning into UB. No signed overflow? Branch gone from that loop. Prove these two things can't alias because the pointer provenance model says they don't and you can rearrange the loads and stores. The collateral damage from that line of work is high though.
    - rightbyte 4y ago
      Ye you might be correct. I think they are overreaching a bit in the eagerness to optimize.
- Kototama 4y ago
  Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc. C without undefined behaviors is not C anymore by the way. It would be something else.
pjmlp 4y ago
> The combination of BASED and REFER leaves the compiler to do the error prone pointer arithmetic while having the same innate efficiency as the clumsy equivalent in C. Add to this that PL/1 (like most contemporary languages) included bounds checking and the result is significantly superior to C. https://www.schneier.com/blog/archives/2007/09/the_multics_ope.html https://www.schneier.com/blog/archives/2007/09/the_multics_o... "Multics B2 Security Evaluation" https://multicians.org/b2.html https://multicians.org/b2.html But naturally ignoring it was more fun, > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html
- zozbot234 4y ago
  "Speaking as someone who has delved into the intricacies of PL/I, I am sure that only Real Men could have written such a machine-hogging, cycle-grabbing, all-encompassing monster. Allocate an array and free the middle third? Sure! Why not? Multiply a character string times a bit string and assign the result to a float decimal? Go ahead! Free a controlled variable procedure parameter and reallocate it before passing it back? Overlay three different types of variable on the same memory location? Anything you say! Write a recursive macro? Well, no, but Real Men use rescan. How could a language so obviously designed and written by Real Men not be intended for Real Man use?"
  - pjmlp 4y ago
    Well, at least the Morris worm wouldn't have happened with PL/I.
antirez 4y ago
A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.
- xigoi 4y ago
  Can you expand on that?
- nikbackm 4y ago
  C++ should be even better in those categories.
  - siftrics 4y ago
    This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.
    - AlexeyBrin 4y ago
      C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
      - wiseowise 4y ago
        C++ is a sane defaults superset of C.
      - 3836293648 4y ago
        C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other
      - kazinator 4y ago
FpUser 4y ago
He says something like >"if you want to write new program in C now think long and hard and pick something else" I would not use plain C to write enterprise backend servers. I happily use modern C++ for that. For some very low power microcontrollers however I absolutely would. Amount of high quality free tooling and libraries beats everything else. From a practical point of view: I've written enough firmware for very lowly microcontrollers like AT90USB1286. Runs like a charm (oldest for 10 years already), did not not require even single bug related update and zero complaints from customers. Changing the language in this particular case would bring no benefits but extra expense.
- Gibbon1 4y ago
  > I would not use plain C to write enterprise backend servers. I happily use modern C++ for that. I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript. But yeah, not really sure what some other language would buy me in the small embedded space that earns me my beer money. I recently had an issue where the corporate spyware was convinced make/gcc were up to no good resulting in minute and a half compile times instead of the usual 10 seconds. I spent a bunch of time with IT getting that fixed. Well that's the build time I'd get with Rust. So Rust is a big nope. C++ is not that slow but still slow. And C++ without malloc is well who are we trying to kid here.
  - FpUser 4y ago
    >"I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript." For my particular project managed language would simply not work. Way too slow. Besides the code base is relatively small and higher level language would not offer any compelling benefits. >"minute and a half compile times" Just checked. My particular project compiles under 1 second using Atmel Studio 7.
tails4e 4y ago
I often wonder why c did not deprecate the bad bits, like the dodgy string functions should at least be behind a switch to enable, like --enable-strcat or something. Even the printf bug when passing a single argument is easily fixed by requiring two arguments at a minimum, etc. Then leveling up the std library to force the use of bounds checked strings and buffers, again hiding the unsafe ones behind switches or unsafe keywords. This woukd allow backwards compatability, while making newer code safer by default.
- stephc_int13 4y ago
  The C language and the C stdlib are not the same things. You can use C without the stdlib. You simply have to build or use a different framework offering similar or better APIs.
  - tails4e 4y ago
    Yes, of course. But making the stdlib more sane would dramatically improve things. Deprecating the dangerous methods and requiring unsafe keywords to use them coukd still be done
- pjmlp 4y ago
  WG14 never cared that much about security, as simple as that.
coldcode 4y ago
I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet. I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff. I don't miss it at all. C is very low level and so easy to write bad code in if you don't have solid discipline, the language doesn't help at all, which was not really a design decision back then. The first C compiler we used didn't even support prototypes. I exclusively use Swift now.
- Koshkin 4y ago
  Only a mother could love Swift's syntax. The classic K&R C, on the other hand, was the very definition of simplicity and elegance. (Objective-C is a whole another topic, of course.)
  - KerrAvon 4y ago
    Classic K&R C? Where you declared the function arguments Pascal style out of line and had to rely on separate “lint” programs to check for typesafety in function calls? Surely you mean C89, where functions have some type safety but C’s variable declaration syntax remains a horrible inelegant kludge? Have you written much code in Swift?
  - pyth0 4y ago
    I really don't understand this take at all. Swift has fairly standard syntax as far as modern languages go.
- pjmlp 4y ago
  What about MPW, MacApp and Metrowerks PowerPlant?
stephc_int13 4y ago
The more I learn about new and less new languages (Zig, Jai, C#) the more I like C and its true simplicity. The language has a few irritating historical artefacts and the stdlib API is completely outdated and full of bad design, but there it is still versatile enough for my needs.
- matheusmoreira 4y ago
  > the stdlib API is completely outdated and full of bad design It is also completely unnecessary on Linux. I switched to freestanding C and discovered it was a much better language. Made programming fun again. All I needed was one system call function and some entry point code. It's gotten to the point that it bothers me that gcc could potentially generate calls to mem* functions even in freestanding mode.
  - JonChesterfield 4y ago
    llvm does that too. It's really tempting to assume there's a libc available for the target architecture. On the list of things to clean up that hasn't hit top of stack for anyone.
- warmwaffles 4y ago
  The simplicity is a blessing and curse. I enjoy writing C and sticking to a hard discipline of writing unit tests for all functions where possible. Abusing `assert/1` in debug mode. But concurrency is a hard thing to build. Identifying critical sections, making sure they have mutex locks where necessary. I want to love Rust but it's hard for me to get used to the syntax. I've started using it and failed multiple times because it's terse. Inevitably I will try again and hope it pans out.
- adamrezich 4y ago
  I like C89 for its simplicity too but after using the Jai beta for over a year I have a hard time seeing myself ever going back.
  - stephc_int13 4y ago
Koshkin 4y ago
C is like your wife: you love her; you are afraid of her a little; sometimes you wish she was someone else.
andsoitis 4y ago
Speaker asks: "What can and should replace it?" (i.e. if you started a new project today, what language should you pick instead of C, because C would be the wrong choice). He goes on to list the following options (and says C++ does not count), but we'll only know far in the future which would have been the right pick: - Rust - Go - Zig - V - Nim - Swift - ...
- pjmlp 4y ago
  The problem with C++, is that while it offers the language features to write safer code than C, it is also copy-paste compatible with C (most of it anyway). So while a security conscious group can write C++ code that takes advantage of those features, other group can basically compile C++ code that is hardly any different from C. So it is a better option than raw C, if it is the only viable alternative (like in HPC), but for security conscious scenarios one of the others is a better answer, if available.
- timbit42 4y ago
  None of them are the wrong pick. They're all better than C.
wheelerof4te 4y ago
The most complicated and the most simple language at the same time.
jokoon 4y ago
I'm trying to build a language that translates directly to C. I will just implement some features of the language in C, with some headers I can already find. It feels like it's the best way I want to do this. That way, a C compiler can do a lot of work I really don't want to do, C already has backends, optimizers, etc etc. All I want is a C-like language with native strings, hash map and list, tuples python indentation, vector math, and nothing else, and make it as simple as possible. I'm a bit tired of new language trying to do new things, I just want something less verbose than C, but not as powerful as C++, with the feeling of python.
- GeorgeTirebiter 4y ago
  Have you looked at Nim? https://nim-lang.org/ https://nim-lang.org/ or Zig? https://ziglang.org/ https://ziglang.org/ or D? https://dlang.org/ https://dlang.org/
  - jokoon 4y ago
    Yes I know about all of them, they're all a bit too complex for my taste. They're great languages, but they're not what I want.
    - GeorgeTirebiter 4y ago
      I understand. I wrote a language once, a while ago. To get the speed I wanted, I wrote it in assembly language - and it took over 2 years of fairly consistent effort to get something that really worked. (I would call it "Pythonic" but this was before Python existed.) So, go for it, and keep us updated on your progress. Good luck.
- Tozen 4y ago
  or Vlang (https://vlang.io/ https://vlang.io/), which can compile to C, and has a C2V transpiler.
  - jokoon 4y ago
davidhyde 4y ago
I wonder what form a “typescript for c” language would take and if it would be as revolutionary as typescript was for JavaScript applications. I would assume that all the existing c tooling could still be used.
jecel 4y ago
An important part of C history is that in the early 1980s the IBM PC and clones became the most popular computer in the world and it was not really compatible with C. You could say your program was "tiny" and limit it to 64KB or fill your code with "near" and "far" pointers (if using Microsoft tools) or use @ instead of * (if using QNX tools), but the cost was not being able to port to/from the VAX/68000 world. All this went away with the 386, but without this problem it is likely that C would have overtaken Pascal even sooner. It is not hard to say what is unique about C: it and Forth are the only high level languages with seamless access to memory. If other languages offer it at all, like PEEK and POKE and Basic, it is far more awkward and interrupts your flow. That might be a good thing - the ESPOL compiler mentioned in the talk would print a big fat warning "YOU MUST KNOW WHAT YOU ARE DOING!" after any line in your code doing C-like tricks.
vivegi 4y ago
I was in college early '90s in CS&E (Comp Sci & Engg) and we were taught Pascal first, COBOL and then C. Pascal and COBOL in the second year and C in the third year. C++ was already there, and gaining traction and I taught myself C++ (through the Annotated C++ Reference by Stroustrup). By the time I graduated most jobs were expecting C/C++ coding skills and my first job involved coding in C++. Nothing compares to the raw power and control we get with C. Around '97-98 Java was all the rage. Then Bill Gates did his internet pivot and we had .NET arriving in the '00s. The allure of being able to program in any framework language and interoperate looked like a good thing. Over the last 20+ years I had been in the .NET world and just this year I went back to writing in C and it all came back. It is quite refreshing to be completely responsible for every aspect of your code's working. While it is sometimes tedious, nothing beats the power and control of working close to the machine abstraction. Just my 2cents.

156 points by enduku 4y ago

His final conclusion is that C has to go, just like COBOL, Fortran, and PL/I. I wonder how long it will take before C will be gone totally when you realize how much COBOL and Fortran are still around. Not so long ago, I came along a module for Python 'SciPy.interpolate' that happens to be programmed in Fortran.

jvanderbot 4y ago
There are certainly some key libraries that use Fortran still. But I wouldn't say it's still "around". As a language for new projects, it's extremely niche. That's probably what "go" means in your comment. I assume you're being facetious with the "recently came across", since scipy is so common, but I will add that nearly every math-intense library is a clever wrapper for some Fortran code. I would be perfectly happy to see many hardened C libraries become the foundation of the next gen systems/ embedded languages. It does bother me slightly when we abandon the past entirely and attempt to "rewrite it in X"
- jacquesm 4y ago
  In part that is because once a piece of software has been part of a certification process it can be very hard to replace it by something newer, no matter how shiny or how much faster. You can see quite a bit of this in aerospace, civil engineering and so on. Nobody wants to be the one to replace the Fortran based FEA package with something novel and end up being liable for a bug.
- fjfaase 4y ago
  No, I was not being facetious. I am not a regular user of Python, mostly have been writing/maintaining software in C++ and (in the past three years) C#. I came across it because a colleague (fluent in Python) had used scipy.interpolate in some experimentation and now the algorithm he came up with has to be implemented in C#, so I investigated whether scipy.interpolate could be called from C# and then found out that its source was in Fortran. But just like Fortran is still used for nearly every math-intense library, mostly invisible for most of the users, I suspect that C will still be around in 50 years from now. I agree, with his observation that C should be no longer your language of choice for new projects. I personally still prefer using C/C++ for my private software projects, simply because it is the language I am most fluent in. This year I used it for AoC.
  - auxym 4y ago
    Significant chunks of numpy and scipy, the "main" python packages for numerical algorithms, are wrappers around classic libraries such as BLAS, LAPACK and ARPACK, which are Fortran. Fortran was the de-facto language of scientific and numerical programming for a long time, back to the 60s even. These libraries are battle tested more than anything else out there, they literally have decades behind them, so they are industry standard and are used wherever possible.
Decabytes 4y ago
I think it will go when we have a sufficiently popular and useful systems programming language that will replace it. It has to be a language that isn't just C with some extra bits, which is why SafeC and CheckedC aren't more popular. I actually think the closest language will be Zig. It's a much simpler language than Rust and people who like C really value that simplicity. It also removes a lot of Cs baggage that make it annoying to program in. But since Zig 1.0 is unlikely until 2026 I'd say we wouldn't start seeing Zig majorly displace any C programs until about ten years after 1.0, which would be 2036. Rust 1.0 was in 2015 and we are just starting to see it in the Linux kernel ~ 8 years out, so that seems like a good timeline. Then just give it another 40 years and I could see a future where Zig and Rust replace all code where C is currently used. Sure there might be some ancient legacy systems that use C, but just like COBOL, would not be something that you would come across unless you wanted to.
- keewee7 4y ago
  Is there a reason Zig is taking so long to go 1.0? The language itself feels mature.
  - ptato 4y ago
    the self-hosted rewrite took a long time so it felt like the project had stalled for the past ~year. the team has started working on new features like the package manager, though.
- addaon 4y ago
  Is there any other systems language that's even moving towards a mature ecosystem with a compiler like CompCert? It feels like this is still decades away for any realistic competitor to C.
- zozbot234 4y ago
  SafeC and CheckedC do nothing for temporal safety. Zig is in the same boat. There's not really a simpler alternative to Rust with the same featureset, even its direct predecessor Cyclone was in fact quite a bit harder to use. Rust itself is also improving very quickly and becoming easier to use over time.
AstixAndBelix 4y ago
We can replace COBOL with a Java backend to keep the enterprise feeling going, but what would C's replacement be in this case?
- pjmlp 4y ago
  C++ for starters, would already be an improvment, provided string, array and vector classes with bounds checking, get used instead of raw C pointers. Alongside RAII for resource management.
  - youarethejoke 4y ago
    For most embedded stuff those are just extra hassle and not worth it. C and its raw pointers and are really all you need most of the time. The need to have some discipline and expertise to produce solid code with confidence is not a bad thing in the embedded domain. If the code truly is critical you need to dive deep into verification techniques anyway.
    - pjmlp 4y ago
      Sure we all know that the S in IoT stands for security.
    - timbit42 4y ago
      Rust has already begun to replace C in the embedded space.
- timbit42 4y ago
  Rust is already replacing C and C++. Ada is too. As the importance of safety increases, more safe languages will appear that can replace C and C++.
Sakos 4y ago
Is that even possible as long as the Linux kernel is written in C? I wonder if telling people not to learn C will have a long-term effect on being able to find competent contributors to the kernel.
- nousermane 4y ago
  > Linux kernel is written in C Not exclusively in C, not anymore: https://docs.kernel.org/rust/index.html https://docs.kernel.org/rust/index.html It might take another decade for a C-free build to be possible, though.
  - c7DJTLrn 4y ago
    Only a decade? I don't think so. AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C.
    - deleted 4y ago
      [deleted]
    - michaelsshaw 4y ago
      This right here. Rust only JUST got added to the kernel in 6.0 and I doubt that it will replace 30 years of C development any time soon.
    - mustache_kimono 4y ago
      > AFAIK Torvalds has also stipulated that any Rust code needs to be mirrored in C. Do you have a cite for this? I hadn't heard this at all.
      - c7DJTLrn 4y ago
        Apologies, I can't find a source. I probably read it on LWN somewhere. Linus wouldn't dip both feet into the water at the same time. I'm confident he's said that the kernel needs to be buildable without Rust if need be.
sylware 4y ago
C syntax is already way too rich and complex, not to mention the bazillions of gcc extensions required to compile the linux kernel. Namely, if it has to be "replaced", that would be with something with a much simpler syntax, which will require a bit more of finger power. We don't want to find ourself locked-in by very few compiler vendors (open source or not), that only because it is not reasonable to code a real-life alternative with a small team of averagely skilled devs in a reasonable amount of time. This language should build on C though: no enum/typedef/_generic/switch/etc, only 1 loop keyword (loop{}) only explicit sized types, no integer promotion, no implicit casts (except maybe void* pointers but number literal casts should be) but explicit casts (compile-time and runtime, without that horrible c++ syntax), explicit compile-time const (we have only runtime consts which could be optimized as compile-time consts), enforce extern for functions (and don't try to put the binary format, elf/coff/etc, semantics into the language syntax or worse, the OS interface semantics), etc. With enough discipline (and compiler warnings), we could get close to such language. I did not check the latest and greatest rust syntax, but is what's above its explicit goals? That said, I am a "everything in 64bits RISC-V assembly with x86_64/arm64 legacy ports kind of guy"... if RISC-V is successful (I wish). We could think of high-level language interpreters (coded in assembly, for instance a RISC-V coded python/lua/javascript/etc interpreters).
- tristanbvk 4y ago
  These are good ideas. The simplicity here is what I am going for.
  - sylware 4y ago
    On the long run, it all depends on syntax stability which is tightly coupled with its complexity. The "benchmark" to run to evaluate syntax complexity toxicity, for a compiled language, is how long an alternative compiler written by a small teams of averagely skilled devs, or even one individual averagely skilled dev, can stay a "real life" "working" alternative. Mid-term/long-term planned obsolescence of computer language syntax is really... Oh, and in my previous post: for compile time constants we can use static consts, my bad.
- 4y ago
pjmlp 4y ago
It won't go away, but just like it happens with COBOL, Fortran, and PL/I, you won't see anyone dreaming of coding C until the end of their working days. Or maybe they will, given how much consultants in those languages happen to be paid, as no one else wants to touch them.
- pantalaimon 4y ago
  But coding C is actually fun!
  - Ygg2 4y ago
    Sure. But debugging sure isn't. Null, null terminated strings, data races, segfaults...
    - Koshkin 4y ago
      No, no - debugging is actually where all the fun is!
      - Ygg2 4y ago
        I'm not masochistic enough, I guess.
- rightbyte 4y ago
  > you won't see anyone dreaming of coding C until the end of their working days. I do dream about that. Just being able to tag along while some programmers learn their Xth framework as a language. Maybe someday I might concede and move on from C89 to C99.
  - diydsp 4y ago
    Same here. Ive got so much experience and libraries ive written i can marshall. They've been ported across small and large platforms since before github and google. Ive been maintaining them since the 5.25" disk age. New C projects aren't precarious to me. Watching a bunch of architects with no embedded experience try to make C++ happen on microcontrollers in the other hand...
flohofwoe 4y ago
A good bet is that a technology will be around at least as long as it has been around (I think there's also a 'named law' for it). So I fully expect C to be around in one way or another for the next 50 years, it probably won't be as important anymore, just as COBOL or Fortran are not as important as they used to be. One reason for C to disappear completely would be if computer architectures would change so much that current programming languages no longer even map to those new architectures (e.g. all the existing programming languages would need to be dumped anyway).
- ReactiveJelly 4y ago
  https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect > The Lindy effect (also known as Lindy's Law[1]) is a theorized phenomenon by which the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age. Thus, the Lindy effect proposes the longer a period something has survived to exist or be used in the present, the longer its remaining life expectancy.
  - timbit42 4y ago
    While C and C++ have been around longer than COBOL was when building new systems it it was halted, at least COBOL does its job well while C and C++ don't due to their lack of safety. Also, COBOL is more difficult to replace than C and C++ are. I expect C and C++ code to start being seen as dangerous and money will be spent to eradicate it due to its potential to be a security risk in this online world.
hgs3 4y ago
C is the best abstraction for many problem domains and that isn't going to change. I understand why folks coming from higher-level languages would dislike it, but for anyone coming from assembly it's a godsend. The speaker discourages C for new projects, but that says more about the problem domains they work in than C itself. C is what it is because the hardware and assembly language are what they are. Folks who want a safer C should design a new hardware architecture with a "safe" assembly language and a new low-level language that targets it.
- sirsinsalot 4y ago
  Anyone discouraging a particular tool without actual context of the problem being solved gets zero respect from me. It's a massive red flag that they don't know enough to be useful. C is great for the things C is great for, however small that range may or may not be now and in the future. Any other stance is reductive and misleading.
  - KerrAvon 4y ago
    Exactly what, in the year 2023 C.E., is C great for? I’ve been writing C since 1991 and I can’t think of anything where I wouldn’t start a new project in some other language. There are many interesting choices of varying maturity in the low-level systems programming space: Zig, Rust, Crystal, D, Swift (if the standard library ever gains support for system-level programming). Even the “better C” subset of C++ will allow you to avoid certain classes of security bugs completely. I don’t think C is even merely adequate for anything at this point; defaulting to memory safety is table stakes in any domain where C was once dominant.
    - Koshkin 4y ago
      > C.E. There.
    - fncslothouber 4y ago
      Memory safety / security is important for a subset of all possible applications. It is not important for _all_ applications. If I use a micro controller to control a string of leds I do not care about security/memory safety. But I do care about being as close to the metal as possible, and being able to understand the compiled code.
kovac 4y ago
Can C really completely go away as long as there's embedded programming? Are there any other alternatives for that domain?
- Tomte 4y ago
  There are embedded devices programmed in other languages, you know, and there have been for decades. In Ada, for example. Which is an even better fit to the domain than C (better ways to describe hardware idiosyncracies).
- Zagitta 4y ago
  Rust is rapidly picking up steam in the embedded sphere :-) Unfortunately it's an industry with a lot of stubborn old people so I don't see any major changes happening until they've retired but I'm willing to bet that async is going to revolutionize embedded development. Being able to await interrupts and doing efficient cooperative scheduling while writing straight forward code is a massive QoL improvement which is what embassy is enabling: https://embassy.dev/ https://embassy.dev/
- pjmlp 4y ago
  Yes, compilers for C++, BASIC, Pascal, Ada are around, mostly commercial and people pay to keep those companies in business, for powerfull microcontrollers where real time GC is an option, there are Oberon, .NET and Java as well. There are surelly other factors that weight in using C, but not for lack of options (in many cases).
- KnowOneYouNo 4y ago
  Ada is a much better and modern alternative for embedded, real-time and/or systems programming. Its mature, (although still evolving) and very scalable from very, very small to very, very large systems. It also supports interoperability with C and C++. It is a primary language in GCC. See https://ada-lang.io/ https://ada-lang.io/ and https://learn.adacore.com/ https://learn.adacore.com/ Unfortunately Ada is held back by a genuine lack of awareness and some old misinformation baggage.
  - 4y ago
jillesvangurp 4y ago
In a way, it's already happening. Many big tech companies are now defaulting to other languages than C and are actively discouraging the use of C or C++ for new code. They still have a big vested interest in maintaining existing code of course. That's not going to disappear overnight obviously.
- pillefitz 4y ago
  Do you have examples? Is it all going towards Rust or are there other big tech-backed contenders?
  - timbit42 4y ago
    I read recently that parts of the code for Artemis are written in Ada. Ada is also used on the ISS. Makes me wonder who besides NASA might be using Ada due to its' safety.
jcranmer 4y ago
My prediction is that C will die off as a language long before Fortran and COBOL. What keeps a language like Fortran alive is that it is used in an application niche where rewriting is done at best ship-of-Theseus style, and the friction of using a new language for a component far outweighs the benefits of doing so (weather models are a good example here). For COBOL, it remains in applications where the cost of a switch or rewrite includes a low risk of catastrophic, and therefore expensive, failure (see Southwest Airlines for a very public and recent example of such a failure). C does have a similar kind of niche at first glance: systems programming is of course conservative, rewriting everything is unlikely, and of course, C is the language used for ABI. Except on closer inspection, that moat is remarkably shallow. Being the language of ABI means that every competitor language has some way to speak C guaranteed, so the friction of rewriting systems software Ship-of-Theseus-style is much lower (though still nonzero). Systems software is rewritten from scratch on a much higher cadence: in the last 20 years or so, most of the userspace system glue for Linux has been replaced (e.g., systemd, iproute2, pulseaudio, wayland). And we've learned over the past few decades that there's no practical way to fix C's fundamental unsafety issues with software engineering practices, and C's committee is too conservative to consider retrofitting the necessary features to be able to fix unsafety at a language level (to say nothing of getting people to use it). There is already a small clutch of languages that can serve C's niches that don't have the same fundamental unsafety issues, and right now, we're sort of at an experimental stage of system software trying them out. It's not unreasonable to believe that within a decade or so, one or more of these languages would be considered a standard, safe choice for implementing new systems software--and the use of C in new projects will start dropping. At some point, the proliferation of non-C systems projects will make people point out that having these components talk through C's ABI is too limited in functionality, and a system will change its ABI from C to some other language. And once it is no longer the language of ABI, C will lack its moat that keeps it alive, and it will start dying, though its death will be a slow, agonizing death.
Wadajot 4y ago
> that happens to be programmed in Fortran. SciPy is a highly optimized library and Fortran is faster than C for some tasks: https://stackoverflow.com/a/146186/3383640 https://stackoverflow.com/a/146186/3383640
Tozen 4y ago
The problem is that there isn't anything to replace C, that would be acceptable enough. C has become a quasi protocol, and used in exchanges between languages. One could argue it's better for newer languages to embrace and excel in interop with C, while providing more advantages, being safer in comparison, or greater ease of use. As is arguably the case with Vlang, Dlang, Nim, etc... If anything, C may still be going strong for another 20 to 30 years.

jacquesm 4y ago

Great talk. Borland should have rated a mention though, their C compiler really popularized C development on Windows.

pjmlp 4y ago
Most sane Borland customers were using C++ alongside Object Windows Library, not raw C alongside Win16. Even Petzold embraced C++, even if superficially, "This third edition has several changes. First, all programs are now compilable with either the Microsoft or the Borland compiler. All make files are generic and use environment variables for compiler flags, link libraries, and so forth. Second, all programs are now compilable in C++ mode. Although I don’t use any C++ specific features, compiling first in C++ mode is helpful if C++ features are to be added later to the code" -- https://archive.org/details/programming-windows-31-3rd-ed/page/n9/mode/2up https://archive.org/details/programming-windows-31-3rd-ed/pa...
- jacquesm 4y ago
  > Most sane Borland customers Veiled insult noted ;) I used both, but TurboC was a real game changer for me. I came from the ST using MWC and ended up in very unfamiliar territory on Windows, Borland TurboC made all the difference for me. It allowed me to be productive on an unfamiliar platform, compiles were absolutely lightning fast compared to anything the competition put out and was rock solid. Edit: I just realized I still have ctrl-f9 more or less in my muscle memory. It's been decades...
- jacquesm 4y ago
  One day later: some more thoughts on this, I think the biggest reason to pick Borland was bluntly put the price. There was simply nothing else that came even close to being that affordable and, more importantly, that would run on my relatively anemic machine. I was dirt poor back then, my computer didn't even have a case, it was essentially a motherboard and a power supply bolted to a steel frame of one of those office folder hanger carts (I don't know what those are called in English, but they were pretty common in the days of paper file folders). I just plugged cards into the top and a harddrive (a 20 MB MFM Seagate which cost as much as my car) was sitting loose on the same base with some cables to keep it connected to the motherboard. It was about as ugly as it could be but it worked and I was pretty happy with it. Happy New Year by the way, if you are still up and reading this!

JonChesterfield 4y ago

I maintain that C is fine and optimising compilers converting 'bad' C into dangerously broken binaries is not fine. We don't need to replace C to make it safe, we need to take the edge off undefined behaviour justified compiler rewrites.

rightbyte 4y ago
I believe the main culprit is that the compiler guys want to optimize away Cpp templates, where programmer intent is not as explicit as in C.
- pjmlp 4y ago
  C has enough UB of its own, no need to bring C++ into the picture.
  - rightbyte 4y ago
    I meant that the shared compiler code with Cpp is the problem. At least in gcc. I don't know about Clang.
- JonChesterfield 4y ago
  I attribute it to benchmarks. Spec and the like. Where you can indeed make the benchmarks faster by leaning into UB. No signed overflow? Branch gone from that loop. Prove these two things can't alias because the pointer provenance model says they don't and you can rearrange the loads and stores. The collateral damage from that line of work is high though.
  - rightbyte 4y ago
    Ye you might be correct. I think they are overreaching a bit in the eagerness to optimize.
Kototama 4y ago
Saying C is fine, does not make it fine though. The facts speak for themselves: even the best programmers in this world which are extremely conscious about security have vulnerabilities in the software they wrote because of C. There were two remotes vulnerabilities in OpenBSD since it's creation, more recently there was a vulnerability in the ping utility of FreeBSD, etc. C without undefined behaviors is not C anymore by the way. It would be something else.

pjmlp 4y ago

> The combination of BASED and REFER leaves the compiler to do the error prone pointer arithmetic while having the same innate efficiency as the clumsy equivalent in C. Add to this that PL/1 (like most contemporary languages) included bounds checking and the result is significantly superior to C. https://www.schneier.com/blog/archives/2007/09/the_multics_ope.html https://www.schneier.com/blog/archives/2007/09/the_multics_o... "Multics B2 Security Evaluation" https://multicians.org/b2.html https://multicians.org/b2.html But naturally ignoring it was more fun, > Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own. https://www.bell-labs.com/usr/dmr/www/chist.html https://www.bell-labs.com/usr/dmr/www/chist.html

zozbot234 4y ago
"Speaking as someone who has delved into the intricacies of PL/I, I am sure that only Real Men could have written such a machine-hogging, cycle-grabbing, all-encompassing monster. Allocate an array and free the middle third? Sure! Why not? Multiply a character string times a bit string and assign the result to a float decimal? Go ahead! Free a controlled variable procedure parameter and reallocate it before passing it back? Overlay three different types of variable on the same memory location? Anything you say! Write a recursive macro? Well, no, but Real Men use rescan. How could a language so obviously designed and written by Real Men not be intended for Real Man use?"
- pjmlp 4y ago
  Well, at least the Morris worm wouldn't have happened with PL/I.

antirez 4y ago

A different take on the matter: I write code mainly artistically, and I found that C is one of the best languages available to code as a form of art. It allows to be both brutal and honest, or abstract and deceiving. Not many languages are so semantically powerful.

xigoi 4y ago
Can you expand on that?
nikbackm 4y ago
C++ should be even better in those categories.
- siftrics 4y ago
  This shouldn't be downvoted. C++ is a superset of C; it must be capable of being at least as "brutal and honest" and "abstract and deceiving" as C. I would argue that C++ can be dramatically more deceiving than C --- see inheritance and operator overloading, just to name two.
  - AlexeyBrin 4y ago
    C++ is not a superset of C, there are plenty of legal C constructs that will trigger errors when compiled with a C++ compiler.
    - wiseowise 4y ago
      C++ is a sane defaults superset of C.
    - 3836293648 4y ago
      C is not a superset of C either. C++ is a superset of a C version, even if they then went on to add stuff that wasn't added to the other
    - kazinator 4y ago

FpUser 4y ago

He says something like >"if you want to write new program in C now think long and hard and pick something else" I would not use plain C to write enterprise backend servers. I happily use modern C++ for that. For some very low power microcontrollers however I absolutely would. Amount of high quality free tooling and libraries beats everything else. From a practical point of view: I've written enough firmware for very lowly microcontrollers like AT90USB1286. Runs like a charm (oldest for 10 years already), did not not require even single bug related update and zero complaints from customers. Changing the language in this particular case would bring no benefits but extra expense.

Gibbon1 4y ago
> I would not use plain C to write enterprise backend servers. I happily use modern C++ for that. I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript. But yeah, not really sure what some other language would buy me in the small embedded space that earns me my beer money. I recently had an issue where the corporate spyware was convinced make/gcc were up to no good resulting in minute and a half compile times instead of the usual 10 seconds. I spent a bunch of time with IT getting that fixed. Well that's the build time I'd get with Rust. So Rust is a big nope. C++ is not that slow but still slow. And C++ without malloc is well who are we trying to kid here.
- FpUser 4y ago
  >"I tend to think unless perform/$ is really important one should use a managed language for that, that isn't Javascript." For my particular project managed language would simply not work. Way too slow. Besides the code base is relatively small and higher level language would not offer any compelling benefits. >"minute and a half compile times" Just checked. My particular project compiles under 1 second using Atmel Studio 7.

tails4e 4y ago

I often wonder why c did not deprecate the bad bits, like the dodgy string functions should at least be behind a switch to enable, like --enable-strcat or something. Even the printf bug when passing a single argument is easily fixed by requiring two arguments at a minimum, etc. Then leveling up the std library to force the use of bounds checked strings and buffers, again hiding the unsafe ones behind switches or unsafe keywords. This woukd allow backwards compatability, while making newer code safer by default.

stephc_int13 4y ago
The C language and the C stdlib are not the same things. You can use C without the stdlib. You simply have to build or use a different framework offering similar or better APIs.
- tails4e 4y ago
  Yes, of course. But making the stdlib more sane would dramatically improve things. Deprecating the dangerous methods and requiring unsafe keywords to use them coukd still be done
pjmlp 4y ago
WG14 never cared that much about security, as simple as that.

coldcode 4y ago

I bought a C compiler at my job in 1984 because I thought it was the future, then spent nearly a decade writing MacOS apps in C. I even added object extensions to it (for our use) in 1989 because C++ was not an option yet. I worked with Objective-C in the late 90s and again in the 2010s, which is basically C with funky object stuff. I don't miss it at all. C is very low level and so easy to write bad code in if you don't have solid discipline, the language doesn't help at all, which was not really a design decision back then. The first C compiler we used didn't even support prototypes. I exclusively use Swift now.

Koshkin 4y ago
Only a mother could love Swift's syntax. The classic K&R C, on the other hand, was the very definition of simplicity and elegance. (Objective-C is a whole another topic, of course.)
- KerrAvon 4y ago
  Classic K&R C? Where you declared the function arguments Pascal style out of line and had to rely on separate “lint” programs to check for typesafety in function calls? Surely you mean C89, where functions have some type safety but C’s variable declaration syntax remains a horrible inelegant kludge? Have you written much code in Swift?
- pyth0 4y ago
  I really don't understand this take at all. Swift has fairly standard syntax as far as modern languages go.
pjmlp 4y ago
What about MPW, MacApp and Metrowerks PowerPlant?

stephc_int13 4y ago

The more I learn about new and less new languages (Zig, Jai, C#) the more I like C and its true simplicity. The language has a few irritating historical artefacts and the stdlib API is completely outdated and full of bad design, but there it is still versatile enough for my needs.

matheusmoreira 4y ago
> the stdlib API is completely outdated and full of bad design It is also completely unnecessary on Linux. I switched to freestanding C and discovered it was a much better language. Made programming fun again. All I needed was one system call function and some entry point code. It's gotten to the point that it bothers me that gcc could potentially generate calls to mem* functions even in freestanding mode.
- JonChesterfield 4y ago
  llvm does that too. It's really tempting to assume there's a libc available for the target architecture. On the list of things to clean up that hasn't hit top of stack for anyone.
warmwaffles 4y ago
The simplicity is a blessing and curse. I enjoy writing C and sticking to a hard discipline of writing unit tests for all functions where possible. Abusing `assert/1` in debug mode. But concurrency is a hard thing to build. Identifying critical sections, making sure they have mutex locks where necessary. I want to love Rust but it's hard for me to get used to the syntax. I've started using it and failed multiple times because it's terse. Inevitably I will try again and hope it pans out.
adamrezich 4y ago
I like C89 for its simplicity too but after using the Jai beta for over a year I have a hard time seeing myself ever going back.
- stephc_int13 4y ago

Koshkin 4y ago

C is like your wife: you love her; you are afraid of her a little; sometimes you wish she was someone else.

andsoitis 4y ago

Speaker asks: "What can and should replace it?" (i.e. if you started a new project today, what language should you pick instead of C, because C would be the wrong choice). He goes on to list the following options (and says C++ does not count), but we'll only know far in the future which would have been the right pick: - Rust - Go - Zig - V - Nim - Swift - ...

pjmlp 4y ago
The problem with C++, is that while it offers the language features to write safer code than C, it is also copy-paste compatible with C (most of it anyway). So while a security conscious group can write C++ code that takes advantage of those features, other group can basically compile C++ code that is hardly any different from C. So it is a better option than raw C, if it is the only viable alternative (like in HPC), but for security conscious scenarios one of the others is a better answer, if available.
timbit42 4y ago
None of them are the wrong pick. They're all better than C.

wheelerof4te 4y ago

The most complicated and the most simple language at the same time.

jokoon 4y ago

I'm trying to build a language that translates directly to C. I will just implement some features of the language in C, with some headers I can already find. It feels like it's the best way I want to do this. That way, a C compiler can do a lot of work I really don't want to do, C already has backends, optimizers, etc etc. All I want is a C-like language with native strings, hash map and list, tuples python indentation, vector math, and nothing else, and make it as simple as possible. I'm a bit tired of new language trying to do new things, I just want something less verbose than C, but not as powerful as C++, with the feeling of python.

GeorgeTirebiter 4y ago
Have you looked at Nim? https://nim-lang.org/ https://nim-lang.org/ or Zig? https://ziglang.org/ https://ziglang.org/ or D? https://dlang.org/ https://dlang.org/
- jokoon 4y ago
  Yes I know about all of them, they're all a bit too complex for my taste. They're great languages, but they're not what I want.
  - GeorgeTirebiter 4y ago
    I understand. I wrote a language once, a while ago. To get the speed I wanted, I wrote it in assembly language - and it took over 2 years of fairly consistent effort to get something that really worked. (I would call it "Pythonic" but this was before Python existed.) So, go for it, and keep us updated on your progress. Good luck.
Tozen 4y ago
or Vlang (https://vlang.io/ https://vlang.io/), which can compile to C, and has a C2V transpiler.
- jokoon 4y ago

davidhyde 4y ago

I wonder what form a “typescript for c” language would take and if it would be as revolutionary as typescript was for JavaScript applications. I would assume that all the existing c tooling could still be used.

jecel 4y ago

An important part of C history is that in the early 1980s the IBM PC and clones became the most popular computer in the world and it was not really compatible with C. You could say your program was "tiny" and limit it to 64KB or fill your code with "near" and "far" pointers (if using Microsoft tools) or use @ instead of * (if using QNX tools), but the cost was not being able to port to/from the VAX/68000 world. All this went away with the 386, but without this problem it is likely that C would have overtaken Pascal even sooner. It is not hard to say what is unique about C: it and Forth are the only high level languages with seamless access to memory. If other languages offer it at all, like PEEK and POKE and Basic, it is far more awkward and interrupts your flow. That might be a good thing - the ESPOL compiler mentioned in the talk would print a big fat warning "YOU MUST KNOW WHAT YOU ARE DOING!" after any line in your code doing C-like tricks.

vivegi 4y ago

I was in college early '90s in CS&E (Comp Sci & Engg) and we were taught Pascal first, COBOL and then C. Pascal and COBOL in the second year and C in the third year. C++ was already there, and gaining traction and I taught myself C++ (through the Annotated C++ Reference by Stroustrup). By the time I graduated most jobs were expecting C/C++ coding skills and my first job involved coding in C++. Nothing compares to the raw power and control we get with C. Around '97-98 Java was all the rage. Then Bill Gates did his internet pivot and we had .NET arriving in the '00s. The allure of being able to program in any framework language and interoperate looked like a good thing. Over the last 20+ years I had been in the .NET world and just this year I went back to writing in C and it all came back. It is quite refreshing to be completely responsible for every aspect of your code's working. While it is sometimes tedious, nothing beats the power and control of working close to the machine abstraction. Just my 2cents.