Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area. Maybe I'm the rain man of bit-twiddling?
What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse.
Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop).
I think an iterative tightening of the language would be of greater utility to everyday computing than a rush to re-do everything in something "better."
I always felt that Objective-C was a great take on a "better C"... Definitely not conceptually better in the ways that Rust is, but simply better for a lot of the practical things where C suffers the worst.
Obj-C was an appealingly simple extension to C from the compiler point of view, but for a long time it was hobbled by the runtime/framework situation, as the NeXT/Apple runtime wasn't open source.
Just as that compatibility hurdle was getting fixed by open source efforts around 10 years ago, the iPhone happened and Apple went nuts with extensions to the language... It used to be that Objective-C proponents would brag that you can learn the syntax in 5 minutes if you know C. Now the language is filled with uncountable double-underscored keyword warts and @ declarations. Today's Obj-C looks more like an intermediate format for a Swift->C compiler rather than an evolution of Obj-C 1.0.
I understand completely why that happened. I just wish that Obj-C had gained more of an open source foothold when the opportunity was there, so it wouldn't have been so dependent on Apple's stewardship which eventually killed it as an independent language.
Back in 1986 or so, there were two languages based on C: C++ and ObjectiveC. I was casting around looking for an edge with my C compiler, and investigated the two.
On usenet, there was about the same amount of traffic in the C++ and O-C newsgroups, the respective communities were about the same size.
Which should I choose? ObjectiveC was produced by Stepstone, and they wanted a royalty. C++ was produced by AT&T, and I phoned up their lawyer who said no royalty was required.
So I picked C++ based on that.
In 1987 I shipped the Zortech C++, the first native C++ compiler, and the popularity of C++ promptly zoomed. (Yes, I do think ZTC++ had a lot to do with the crucial early surge of C++ adoption, because the PC was where the programming action was at the time, not Unix.) The traffic in the C++ newsgroup exploded, and the ObjectiveC traffic crashed.
O-C was dead until Apple picked it up again later.
And then I watch something like Gary Bernhard's "Boundaries" talk[1], which isn't bad, mind you, and think "maybe this Brad Cox guy with his Software ICs really knew what he was talking about?"
Where Apple went off the rails with Objective-C was trying to make it into an OO language like Java. It isn't. It is a deliberate hybrid, with a component implementation language ("C") married to a component connection language ("Objective").
My own approach is to take this distinction seriously, and instead of doubling down on the "better Java" part like Swift does (which in Software-IC terms is focusing on the less interesting and mostly solved component implementation part) and instead expand on the ways we can connect components (dataflow, constraints, storage composition, etc.).[2]
Minor correction: GNUStep, libFoundation etc. happened around 20 years ago, not 10.
Objective-C is just an idiosyncratic COM-like system with first-class language support (something that COM desperately needed). There's a performance ceiling with Objective-C that C++ doesn't have, due to some key decisions early on that make it much more like COM than C++—pervasive atomic reference counting everywhere, mandatory heap allocation, virtual dispatch requiring (caching) hash table lookups, and so forth.
I think if Objective-C had caught on and C++ hadn't, the performance-critical world would look very different: you'd probably just see those domains stick to C.
The NeXT/Apple Objective-C runtime has been Open Source since the late 1990s, the API and ABI have been documented since the late 1980s so anyone could create a compatible runtime, and GCC has had a portable runtime almost since Objective-C was taken into its mainline.
I can agree about the nullability annotations & generics additions, but having properties, ARC, & blocks made writing Objective-C programs so much nicer, IMO.
Objective-C will slowly move to where it belongs - the dustbin of programming language history.
Merging C with a higher-level language could only make sense in the 80s, where people didn't know better and invited all the dreadful problems of C code into application development.
Swift is the proof that one can have a safe, powerful language that can also be fast. It's not yet fully mature, but it will get there, the speed at which it's replacing Obj-C in iOS and macOS development is impressive.
I agree with you. I've been a C and C++ programmer for decades, and nothing to do with memory safety or leaks has ever risen to the level of prohibitive or even annoying. Ironically, I've had infinitely more grief from fighting hostile garbage collectors, but that's because I'm a game programmer. I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.
I'm always met with strawman arguments about how I can't possibly write "correct" code. It's a strawman because I don't claim to write correct code. I don't care if Herb Sutter can find 1000 "bugs" in my C++. I care that my users and myself are happy.
I've heard this criticism from several game developers at this point. Contrary to some other voices here, I do think it's legitimate: if safety isn't important to you, then I can't argue with that.
At the same time, I think that Rust made the right choice for most domains. For most software, memory safety problems that hostile attackers find have consequences. Games are an exception, not the rule. It would be irresponsible for us to target servers or network-facing client software without memory safety.
It's also of course true that we have many game developers in the Rust community. A lot of people, including me, see safety as a productivity booster, especially combined with all the other features in Rust. I've advanced suggestions in the past for making unsafe Rust easier to program in, effectively turning off some of the safety checks, specifically for game developers who would prefer not to have the restrictions. These suggestions have been very unpopular in the Rust community, including from the game devs, and so they haven't gone further.
The real problem with C (and to a lesser extent C++) nowadays is not just memory leaks or segfaults, but all the security vulnerabilities you get from the lack of memory safety.
Your code might work 100% correctly for your users, but it may also put their system into risk when processing arbitrary and potentially malicious data. When your system needs to handle data that may come from anywhere - and almost every system does - writing Herb Sutter-correct code is no longer just a nice-to-have.
As a game programmer, exploitability is fairly low on your list of priorities, but for other systems it's quite important. If hackers can find 1000 bugs in your C++ that get them remote access to your computer through the browser, ... well, this is why people hate Adobe.
> I don't care if Herb Sutter can find 1000 "bugs" in my C++.
Until the new release of GCC improve its performance by 10% by optimizing more cleverly an Undefined Behaviour but OOPS it now breaks your code …
> I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.
Rust isn't only about safety, it's also a «C++ on steroid from 2015» with a ton of cool features : Modern type system, no null pointer, parallel code without fear, package manager …
> In 20+ years of C, I've never had a (self-inflicted) problem in that area. Maybe I'm the rain man of bit-twiddling?
Have people been actively looking for mistakes in your code to find exploits?
I just wrote a simple throwaway .otf parser in C, which I've been coding in for a decade and a half. After trying to think about all the places overflow due to malicious input could occur, I just gave up and wrote "FIXME: Insecure" over it, pending a rewrite in something better.
In general, I don't see how you can deny that memory safety problems exist. Pwn2Own is a thing.
> What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse.
> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop).
You just explained exactly why all those inconsistencies and ambiguities exist. And we will keep suffering from them as an industry until we decide to move beyond a language from 1978.
Dude, I never denied that those problems exist, and I have no beef with your language.
My primary points are:
1. Memory management has never presented itself as public enemy #1 in my personal career. Other things have always been far more troublesome.
2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea.
FWIW, for new stuff, Rust is a good choice.
Also, being at Mozilla, I can understand why memory management seems like priority #1. You are a platform!
The rest of us are building on the shifting sands that the west coast creates. Keeping up with Microsoft changing this and Google changing that is WAAAAY more trouble than pointer arithmetic (for me anyway).
> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop).
I agree with that, and most people do even in the Rust community. I don't expect people to rewrite their software in Rust, but if people could stop writing new C code[1], the world would become a better place in the next decades …
> Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area.
In 20+ years of C, you never faced a single segfault ?! I'm sorry but I don't trust you. You're basically pretending being the One True God of programming.
[1]: even in a full C project, it's straightforward to write you new code in Rust in separate files, thanks to Rust really good interop with C. Example: https://bawk.space/2016/10/06/c-to-rust.html
It's just not that difficult to avoid segfaults, signed integer overflow, all the usual Mr. Hyde aspects of C.
There's nothing godlike about it - it's just practice. He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo.
My claim is that the particular class of bugs relating to memory/overflows have not been an issue in my career, while bugs arising from API and language ambiguities have caused considerable headaches.
The new spirit of C can be summarized in phrases like:
(a) Trust the programmer.
(b) Don't prevent the programmer from doing what needs to be done.
(c) Keep the language small and simple.
(d) Provide only one way to do an operation.
(e) Make it fast, even if it is not guaranteed to be portable.
(f) Make support for safety and security demonstrable.
That's the thing; programmers are NOT TRUSTWORTHY. This is a "humans are fallible" thing, not a "you can't trust stupid programmers" thing.
This is why C and Unix are irredeemably flawed designs; they trust the individual programmer/sysadmin to get things right and disaster happens when they don't. In the case of Unix, it can be demolished with a single fat-fingered rm command as root. VMS made a different call: in VMS it is assumed that the sysadmin is tired and hasn't had their coffee. This affects everything from how permissions are assigned to the notorious verbosity -- and extensive help system -- of the VMS shell. Properly configured, VMS was darn-near impregnable; it had also never fallen to the sort of buffer vulnerability common under Unix.
That's Modula-2. Maybe they just need to change the syntax a bit to look more like C, built an IDE plugin, and reboot the Modula-2-to-C compiler to leverage optimizing compilers.
Also, there is the risk of re-doing everything and getting worse results: e.g. executable/library bloat, code harder to read/understand, interoperability/binding issues, etc.
From a security perspective, if you think C is inadequate, try taking a look at the instruction set docs for one of Intel or AMD's semi-modern chips. ;-)
The implication here being that Rust is adequate, I take it? Let us not circle around the issue!
You could assert the same for assembler, and yet, assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security?
I could think of no language more adequate to push the electronics to their limit, and beyond, as Commodore 64 teaches us over and over again, even in 2016.
All I want to say is that your argument rings hollow. Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust.
And finally, a Zen koan: I was troubleshooting some code today, which I wrote in AWK. Now the code transformed the data exactly as I had coded it, and the code was 100% correct, the transformed data was exactly as expected, yet no output was coming out.
Everything which was in the program was 100% correct. The problem wasn't in that which was in the program, but that which was not: there was no clause to output the transformed data. There is enlightment to be had from this tale, specifically about security, and even more specifically about Rust the programming language and its compiler.
YES: Because you're right. Small more iterative changes in terms of tightening up the language to allow for more predictable software (and environment like the kernel) can get us a long way ahead.
NO: Because even though you're very correct, there comes a point in any software stack where the expenses of rewriting the whole thing are vastly smaller than the expenses of iteratively reworking it.
I have drifted away from C/C++ a long time ago -- around 10 years. I personally got sick and tired of per-compiler quirks, different precompiler policies, and writing sed scripts to fix messed up preprocessed files, to name only 3 generic problems.
IMO I believe if something between Golang and Rust comes along and brings only their positives to the table, it'll be very worth to rewrite (or make richer version of) a huge amount of legacy tools in them -- especially if they bring extremely easy cross-compiling and strong runtime guarantees.
I don't know enough to claim either way but in my eyes C has been around for a very long time and a good chunk of the complaints are still in place. I'm tempted to think the community had its chance and that it's time something [somewhat] better must replace it.
In the commercial space, devs already have to rework their apps frequently to handle the curve-balls MS/Apple/Google etc. throw at them. If we had a C compiler with webkit-level dominance, and we made just one fix to it every cycle, that would be a big thing, and it would be manageable!
It's like, "Oh, to be C-2016 compliant I've got to get rid of all my calls to unsafe string functions." Search, replace, and some elbow-grease later, and I've improved my program with a much lower likelihood of breaking functionality.
How do you define problem? In terms of consequences or mere presence of a bug? If it's consequences, is it plausible that you have had no problems because not enough people are interested in attacking your code? If you say you have never produced a memory/pointer related bug that got past you, then you probably are the rain man.
I mean that through strict valgrind and fuzzers, I've never had it find anything in my own code. I've also never had a hard-crash from anything in my own code. I attribute this to personal paranoia about input and indices.
Worst experiences I've had in that domain were due to inconsistencies in things like the Win32 API across different OS versions that were allegedly supposed to behave the same way.
Sometimes I think better API and language documentation would improve programs more than better languages.
I have seen memory errors in large C codebases produced by larger teams. I think C requires a certain level of discipline and a lot people working at large companies simply don't care enough.
From my experience using a simple subset of C++ using things like shared_ptr reduces problems a lot.
"(Self-inflicted)" is an important disclaimer, because it implies that you work mostly on your own from the metal up?
(Also a meta-note about HN discussion: we have years of people saying "there's a problem here" and one guy saying "it's not a problem for me", seemingly unable to see why anyone else has a problem. "Works for me" is not a mission statement.)
Nah. I have had to deal with memory issues in 3rd-party dependencies, so I'm not saying it never happens. I'm just saying I have much bigger problems in other areas that are mostly unaffected by "better" languages.
Maybe I missed it in the article, but it alludes to this: C is the least common denominator. It's not a great language, but it works everywhere and will work in the most restricted of environments.
As the article states, it's resurgence is bc of restricted small devices, but that's not because it's a great language. Debugging memory issues is horrible, having strange things happen because of randomness between compilers, no fun.
I had a recent desire to get back to baremetal, but I didn't go back to C; I have too many battle scars. I went to Rust, and have never looked back or regretted it. The FFI between Rust and C is pretty easy too for any cases where I need it.
It seems that a few years ago several big name tech companies found themselves at the limit of what they could do with the c#/java style languages. But they weren't willing to go back to c/c++. Facebook started experimenting with D, apple created swift, google created go, Mozilla created rust, Microsoft had a rumored system language that never seemed to materialise, and even c++ is trying to get away from itself.
It is sort of looking like the industry as a whole is starting to see if there isn't a better way to do things and I think we will see how things shake out in the next five years or so.
For new projects on hardware that supports the Rust compiler, there are few reasons to choose C over Rust.
That said, take the kind of lifelong momentum that PHP has, and multiply it by a few orders of magnitude, and you have C. It will be a very long time before C is replaced by anything.
Yes. But if people choose to , like me, go to a safer language that reduces congnitive load around bugs etc, it's easy enough to use the FFI of Rust to utilize any existing C libraries out there.
The other big advantage of C is that multiple compilers for it exist that are good enough to use in real life, for a wide variety of toolchains, and it's simple enough that it's possible to write a compiler for it (if not necessarily a very good one) as a hobby project. We can be reasonably sure that C will continue to exist.
By comparison, C++ has precisely two working open source compilers --- clang and gcc --- and Rust has one: if you commit to using Rust, you're also committing yourself to an LLVM-based monoculture. The chances of the entire Rust team being simultaneously hit by a bus is low... but it's something that needs to be factored into a product assessment.
> Rust has one: if you commit to using Rust, you're also committing yourself to an LLVM-based monoculture
rust currently has only one backend, which is LLVM, but their is a working project to build an alternative one for the Cretonne compiler[1] for the «debug» builds, and there might also be a GCC backend for rustc one day if people are interested enough to build it. I'm not aware of any fundamental difficulties that would prevent it.
Many popular languages nowadays essentially have just one viable open source toolchain: Go has the Go toolchain (gccgo being niche), Python 3 has CPython (Jython and IronPython only support Python 2.7, and PyPy is not up-to-date), Swift has the apple toolchain, Haskell has GHC (none of the other compilers is widely used).
That's not necessarily a bad thing since the compilers are all open source and you can port them to whatever platform you want anyway. C managed to spawn a lot of adequate compilers, but the language itself has seen very few changes since it was standardized (27 years ago), while all the other contenders (including C++!) see a major release at least every 2-3 years, and up to several times a year (for Rust).
You can't have that pace of changes and still maintain compatibility between all the different implementations.
> As the article states, it's resurgence is bc of restricted small devices, but that's not because it's a great language.
To be fair, it's an amazing language, but if you're coding to get things done with a deadline (or with an unknown set of specs), of course you should go for the nailgun instead of making custom hammers.
I have also been looking to get back into bare metal programming professionally (I miss the torture). Did you see an immediate switch to rust or is this a rare unicorn project in a sea of C/ASM code for embedded devices?
I've been writing my own ground up stuff. Nothing really on the hardware side for me to publish, but I have been writing a few articles on my DNS project which I have some plans for in the small device realm at some point (not free of allocations yet though).
There are many articles by others out there for getting going with Rust on baremetal, and with Rustup it's now easy to cross compile from your Dev computer to the tartget device.
I am new to programing (well new in the sense that I have been doing it sparsely for years) and only have written code for microcontrollers, is rust a good replacement for C in that domain?
I don't know much about other languages, but it seems C is pretty well tailored for doing all bit-level stuff. Is rust the same way?
"All" modern compiled languages will have bit-manipulation. As long as a language can compile for your microcontroller, you're golden to use something higher level.
I love C, I really don't see what the fuss is about about 'replacing' it really. It's a sharp tool, requiring care and attention.
I did C++ for about 20 years, and gradually reverted to C, simply because of the footprint and the ease of maintaining a C codebase compared to a C++ codebase. C++ codebase's footprint will /explode/ very quickly, while it's really, really hard to do that with C.
You can't have 'shockwave' effects in C codebases; you can't have an intern adding a subtle 2 liner to your codebase in an obscure base class and make the footprint of your application explode. (been there...). It's a lot easier to review, test and maintain over a number of years.
Also, I've grown up considerably since I believed object oriented programming is THE way to solve everything related to programming problems, I've seen a lot of cases where you'd have a spaggetti plate of classes to solve a problem while you in fact could have solved that problem in a 15 line static function.
C -- especially C99 with it's extensions -- is nice, lightweight, hard to mess around with. it's actually a sharp tool but at least it's a straight sharp tool. You know where it's going and how it can hurt you. It's not the case for many of the other solutions who just add bloat to try to hide the fact that they are about as sharp cutting, but it'll get you at the back of the head, later :-)
I keep a keen eye on what's going on with Rust and Go in particular, but it'll be a long time still for me to commit to any of the new kids on the block. Right at this minute I imagine myself easily having to rage-recode it in C at some critical point because of some unforeseen effect.
My only regret with C is that the C committee is completely out there. C11 doesn't solve any of the problems that would be useful for 99% of C programming. Like, rolling in some of the GNU extensions that have been around for 25+ years (case X...Y comes to mind!)
The C/C++ toolchain has been working to add guards and guides to their sharp tools. Things like the various sanitizers in the llvm toolset have already meant that a lot of bugs that would have been released are instead fixed beforehand. You also have things like OpenBSD's implementation of malloc which also helps in the software feedback loop in finding logic errors that allow for things like use after free errors. C still requires attention, but there are a lot of places where it's harder to cut yourself.
Maybe we need to use your sharp tools point with that video. It drives the point home with even experienced people losing fingers to their tools followed by tech modified to prevent it. The demo also never gets old. Just too badass.
That thing looks like it could kill a man if dropped from sufficient height. On the other hand, if I envision it without a case, I'm still not seeing a terribly dangerous object.
> This design is an evolution of planes over centuries of use
How did early ones look like then? Was getting hurt by them a problem, at all?
I'm not debating that main point, that in many cases, safety and usefulness are orthogonal. But that example is kind of worse than none.
It's correct to say that C is a more explicit programming language than C++, where each line of code won't have large side-effects in performance or code size.
The consequence is having to painstakingly code everything at a low level of detail though, with only macros and its limited functions to rely on for code reuse.
This would be fine for low-level embedded work, but anything other than that is simply painful, unproductive and in my opinion not fun at all. I shudder at the thought of having to manually free resources, to use the embarrassing C strings and arrays or having to write dozens or hundreds of line of code to do one simple thing that C++ can do more safely and also in a highly-reusable way.
C is inadequate and has been for a long time. Its status of mythical, hardcore programming language continues to protect it, but slowly people are becoming more outraged at its inadequacies, as they should be. That's what the fuss is about.
Indeed. It's certainly possible to make a language with safety checks that could be turned off in the final version which then has the same performance, but has built in help during development, as well as less cryptic notation. As stated elsewhere, Pascal/Modula (for example) has some very nice features and is written at about the same level.
As for small devices in this day and age, it's not like we can't use cross compilers hosted on desktop computers, since that what phone/tablet systems already do.
> I love C, I really don't see what the fuss is about about 'replacing' it really. It's a sharp tool, requiring care and attention.
You just answered your own question: most people don't apply sufficient care and attention. So should we leave sharp tools lying around and encourage their use knowing they're going to be abused and cause serious problems?
I don't know, if my large, commercial application suddenly starts taking twice the memory, or takes twice the time it used to take to start, can I 'have it'?
And if I can 'have' that, where do I stop?
That was my principal problem with C++ in the end; you'd get some people in the codebase, and then it was endless fear of someone screwing it up, or deciding that it was such a good idea to add 'boost' thingies to the application because it was SO much nicer. And added 20MB to the installer size (let alone memory footprint).
I remember one day when I investigated why the new version of our commercial application was taking about a minute to startup while it used to take about 15 seconds...
After a long time, pain and effort, it turned out that someone had decided that one of the String class accessors would take it's String parameter as a value, and not as a reference. ONE character source code difference, but it made the millions of Strings created at startup being duplicated, converted back forth from UTF16 to UTF8, destructed etc etc etc.
Given that clock speeds are pooping out, this makes total sense. Things already seem to be moving to an even lower level when performance really matters (shaders, FPGAs, etc). C looks fairly forgiving after implementing things in verilog.
For the "why not X" crowd, the problem is that there are very few Xs out there with 30+ years of code to build off of. That, and it's almost a psychosis among us CS grads to overestimate the magic that "better" languages are capable of.
Not everyone has the same usage case. For general user applications, yeah, performance isn't that big of a deal. That's not the entirety of computing though.
Some people do things where performance is crucial. This is probably why Intel is moving into the FPGA space and Google is making their own accelerators for machine learning.
You don't hear about it because one can't "patch things in haste" to fix performance issues caused by choosing the wrong programming language for the problem at hand.
Instead one hears complaints about Python's GIL, hears about people moving to golang, about this new thing called Rust, about a C and C++ resurgence and so on.
"Guess what language are the patches usually in." Patches are most likely to be in the languages used most in the most popular projects. That's just the rational prior.
I loved my junior days programming in C & C++. It was really fun writing your own logging framework, container classes etc. OTOH spending weeks looking for root causes of memory problems was fun the first few years then became an annoyance.
Higher level languages are much more productive - which was initially great, but now I feel more like a sysadmin than a programmer. Its a lot of researching, wiring up and configuring libraries. Probably results in better results but not as fun as hitting the metal.
So sometimes I wish I could go back to the old days but my nostalgia is probably rose tinted. I'd love to do it, but I don't think its commercially productive enough, so I'm skeptical of talk of a resurgence.
I find myself doing most of my hobby programming in C. I think it kind of evokes the same thing other hobbyists(like wood working) get by building something from scratch even though there are easier ways to get close to the same end result. There's just something fulfilling about building something with your own two hands as it were and seeing it work.
That being said, I don't think I'd like to do C professionally and I'll happily stick with languages the manage my memory and have all kinds of libraries that give me "free" stuff.
Agreed. My first choice for a project on *nix is usually in C: it feels like real coding rather than including half the packages/modules from 'pick your glue language here' where the opacity is blinding. But many times I'll stop after working through the first data structures and IPC elements and decide to go higher level in the interest of time and energy (and for other (younger) people being able to maintain it).
I love the analogy to woodworking. When I am working on game dev, I prefer to use a old SDL based engine I developed in C++ instead of some of the new popular frameworks which are more productive and powerful. I just like tinkering and that "built from scratch" feeling for my hobby projects.
It has a different learning curve from C, as initially you'll be having a hard time getting programs to compile at all, but from that point the ergonomics are much better and you don't ever have to deal memory bugs unless you're developing a low-level library.
I second this notion. I'm quite productive in Rust now and can string together web services quickly. (To date I've written a text to speech engine, a laser projector renderer, and some image processing stuff.)
Rust is so awesome. Unlike Python or Ruby it's typesafe at compile time. Unlike Java and Go, it has no dumb GC, and unlike C and C++ it's memory safe. At compile time!
Programs can be distributed as a single binary, which makes deployment a breeze.
If that weren't enough, Rust innovates beyond every language I know of with its compile time threadsafety and fucking sweet package manager. (Cargo is seriously the best package manager I've ever used--perhaps the best in existence right now.)
Give Rust a try. It's freaking awesome.
(I'll buy you a coffee if you do and don't like it!)
> So sometimes I wish I could go back to the old days but my nostalgia is probably rose tinted.
It seems like nostalgia is a big thing over the past few years. Old game emulators, people getting back into C64 or whatever. I guess it's fun for some people. I've considered playing with such stuff, but I know I'd miss some of the real advances we've made since then.
But my major projects at work are in C. My previous job was about 50% C, 50% scripting languages. For all C's deficiencies it's a known quantity and does its job well enough. And knowing C well is a rare enough skill to be valuable, apparently.
When I don't need C I'd much rather reach for something like ocaml/haskell, a lisp, erlang/elixir, or something. Basically I ignore all the "C replacement" languages because I can either use C or pick something way better.
The tools and stdlib improved ton too. I had address sanitizer and undefined sanitizer default on for a while and that helped a lot on memory issues. Things such as int32_t, intptr_t, ptrdiff_t made it is easier to be confident about your pointer math as well.
Well, C and C++ are very different languages. But going forward, this long time C programmer is writing in Rust unless required by exigencies beyond my control. A gun pointed at my head or writing an LLVM backend qualify. Not much else.
C has this mystique of being hardcore, but it's not really that hard. I actually think languages like Ruby are more difficult because they hide so many (important) details from you. I would agree that C can be inconvenient, but its not hard.
C's syntax is simple, sure. But there's so many little things that can bite you in the ass very easily, which is why most people think it's hard. For production code, if you don't have a copy of whatever standard, and aren't able to use that to find your answers, you shouldn't be working on that code.
Think of it like this: In python you could be a beginner, and still write effective code to accomplish your goal. And while it might be slow, you also avoid having deal with a great many subtleties, which in C, to write code for a similar function, you could very well need to be high-intermediate to write the same bug-free code.
Faster? Most likely, but if it's error-prone, does speed really matter?
If you need a "copy of whatever relevant standard", then you're in some fairly deep trouble. Use the 10-40% of the language that works all the time, and you'll have no such trouble. Use the language such that constraints are available to be checked against ( i.e. , no blind pointers ) and you'll be healthier.
At least for some, "C is hard" translates into "pointers and their syntax are difficult to grok, especially around arrays and structs".
The other I've commonly seen is transitioning from a language that allows arbitrary data in a "string" variable. Null-terminated strings are no fun in comparison, and passing buffers around is more work.
Interestingly, one can substitute Ada/SPARK for C in a lot of this article on "C's benefits" with huge boost on safety & maintenance side. For cutting-edge, one project on 8-bit micro's used ATS language for its combo of safety & performance. OcaPIC let's tinkerers use Ocaml subset for algorithms if performance doesn't preclude it. People are also getting a combo of high-level and C benefits by using DSL's embedded in eg Haskell that output C. The Atom, Ivory, and Tower languages are examples of this.
The only thing that's uniquely an advantage of C in the article is understanding legacy code in popular projects. It's mostly in C for historical & social reasons. Mastering C is a great help there. Although, one could still use Ada (Ada-to-C compiler) or DSL approaches above with better results when writing code. Maintainers won't accept that in popular projects, though. So, back to knowing & writing good C for this sort of thing.
>The only thing that's uniquely an advantage of C in the article is understanding legacy code in popular projects.
As much as I love C (despite its flaws), I have to agree here: Like drinking, C is only fun if you do it socially. If you do it nonsocially at all hours, your friends might begin to distance themselves from you. Or hold an intervention.
There was recently a discussion about Ada here and it seemed real nice with an obvious question - if it's so nice, why no one is using it outside of scope of people already using it. So, I gave it a try. Ada is a wonderful, WONDERFUL, language. Albeit a bit verbose. Here comes the catch though. Everything related to Ada seems to be tied to Adacore and proprietary toolings. There's a path for you to do it without (still tied to Adacore though), but not as obvious and not as widespread. Kind of like Common Lisp in ye olde Franz days.
Only thing I would add to C as a language or in standard libraries is some kind of (better) string and UTF handling. ICU4C is coolio, but too much. Antirez's SDS looks cool, but I haven't used it, so I don't know from practice how/if it works with UTF and if it's great in production.
The point is that many benefits ascribed to C to justify use of C arent unique to C and therefore dont immediately justify it. Then I corroborate that with several examples including Ada. You got that much right.
The nobody does part seems off given amount of customers companies like AdaCore have and how much is recurring business. Safety-critical industries like tools that help software work correctly from the start. A significant chunk, esp in aerospace, use Ada.
C was designed in a time when codebases were much, much smaller than codebases today; when your project got big enough that it was unwieldy for C you embedded a lisp or TCL interpreter and used that to string together small C utilities.
As I Get Older™, I'm starting to agree with the Suckless[1] people that the small-project way is better, and that one of the reasons it's better is that C still works for it. Projects that are small enough for a single developer to understand in the nature of things have fewer problems. Yes, that would mean a change in what we expect software to do and how we expect it to behave, but that changes all the time anyways, and I think a pendulum swing back in the minimalist direction would be a good thing.
At one point, there was a pejorative in circulation among some programmers: "hugeware". It seems to have been forgotten. We seem to have developed a kind of "hugeware acceptance".
What was dubbed hugeware was actually small by today's standards.
Readit News
What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse.
Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop).
I think an iterative tightening of the language would be of greater utility to everyday computing than a rush to re-do everything in something "better."
Obj-C was an appealingly simple extension to C from the compiler point of view, but for a long time it was hobbled by the runtime/framework situation, as the NeXT/Apple runtime wasn't open source.
Just as that compatibility hurdle was getting fixed by open source efforts around 10 years ago, the iPhone happened and Apple went nuts with extensions to the language... It used to be that Objective-C proponents would brag that you can learn the syntax in 5 minutes if you know C. Now the language is filled with uncountable double-underscored keyword warts and @ declarations. Today's Obj-C looks more like an intermediate format for a Swift->C compiler rather than an evolution of Obj-C 1.0.
I understand completely why that happened. I just wish that Obj-C had gained more of an open source foothold when the opportunity was there, so it wouldn't have been so dependent on Apple's stewardship which eventually killed it as an independent language.
On usenet, there was about the same amount of traffic in the C++ and O-C newsgroups, the respective communities were about the same size.
Which should I choose? ObjectiveC was produced by Stepstone, and they wanted a royalty. C++ was produced by AT&T, and I phoned up their lawyer who said no royalty was required.
So I picked C++ based on that.
In 1987 I shipped the Zortech C++, the first native C++ compiler, and the popularity of C++ promptly zoomed. (Yes, I do think ZTC++ had a lot to do with the crucial early surge of C++ adoption, because the PC was where the programming action was at the time, not Unix.) The traffic in the C++ newsgroup exploded, and the ObjectiveC traffic crashed.
O-C was dead until Apple picked it up again later.
And then I watch something like Gary Bernhard's "Boundaries" talk[1], which isn't bad, mind you, and think "maybe this Brad Cox guy with his Software ICs really knew what he was talking about?"
Where Apple went off the rails with Objective-C was trying to make it into an OO language like Java. It isn't. It is a deliberate hybrid, with a component implementation language ("C") married to a component connection language ("Objective").
My own approach is to take this distinction seriously, and instead of doubling down on the "better Java" part like Swift does (which in Software-IC terms is focusing on the less interesting and mostly solved component implementation part) and instead expand on the ways we can connect components (dataflow, constraints, storage composition, etc.).[2]
Minor correction: GNUStep, libFoundation etc. happened around 20 years ago, not 10.
[1] https://www.destroyallsoftware.com/talks/boundaries
[2] http://objective.st/
I think if Objective-C had caught on and C++ hadn't, the performance-critical world would look very different: you'd probably just see those domains stick to C.
Merging C with a higher-level language could only make sense in the 80s, where people didn't know better and invited all the dreadful problems of C code into application development.
Swift is the proof that one can have a safe, powerful language that can also be fast. It's not yet fully mature, but it will get there, the speed at which it's replacing Obj-C in iOS and macOS development is impressive.
I'm always met with strawman arguments about how I can't possibly write "correct" code. It's a strawman because I don't claim to write correct code. I don't care if Herb Sutter can find 1000 "bugs" in my C++. I care that my users and myself are happy.
At the same time, I think that Rust made the right choice for most domains. For most software, memory safety problems that hostile attackers find have consequences. Games are an exception, not the rule. It would be irresponsible for us to target servers or network-facing client software without memory safety.
It's also of course true that we have many game developers in the Rust community. A lot of people, including me, see safety as a productivity booster, especially combined with all the other features in Rust. I've advanced suggestions in the past for making unsafe Rust easier to program in, effectively turning off some of the safety checks, specifically for game developers who would prefer not to have the restrictions. These suggestions have been very unpopular in the Rust community, including from the game devs, and so they haven't gone further.
Your code might work 100% correctly for your users, but it may also put their system into risk when processing arbitrary and potentially malicious data. When your system needs to handle data that may come from anywhere - and almost every system does - writing Herb Sutter-correct code is no longer just a nice-to-have.
Until the new release of GCC improve its performance by 10% by optimizing more cleverly an Undefined Behaviour but OOPS it now breaks your code …
> I quickly dropped Rust upon realizing that the core of the language addresses problems I don't have.
Rust isn't only about safety, it's also a «C++ on steroid from 2015» with a ton of cool features : Modern type system, no null pointer, parallel code without fear, package manager …
Rust is a huge productivity booster IMHO !
There are plenty of other expressiveness advantages to Rust, over and above the safety advantages you apparently wouldn't benefit from.
"Hey, that C++ code that's been working for years? All wrong! Go rewrite it in Node.js. No, no, no, in Go this time. Now Rust!" ...
Dead Comment
Have people been actively looking for mistakes in your code to find exploits?
I just wrote a simple throwaway .otf parser in C, which I've been coding in for a decade and a half. After trying to think about all the places overflow due to malicious input could occur, I just gave up and wrote "FIXME: Insecure" over it, pending a rewrite in something better.
In general, I don't see how you can deny that memory safety problems exist. Pwn2Own is a thing.
> What has caused me tremendous grief are all of the inconsistencies in the compilers, the gotchas of the precompiler, and the ambiguities in the language itself. C++ is even worse.
> Rust is great, but not great enough to justify a redo of a program that has been extended and maintained for decades (like vim or photoshop).
You just explained exactly why all those inconsistencies and ambiguities exist. And we will keep suffering from them as an industry until we decide to move beyond a language from 1978.
My primary points are:
1. Memory management has never presented itself as public enemy #1 in my personal career. Other things have always been far more troublesome.
2. For complicated programs that have been continuously developed and extended for decades, a re-write in a "better" language is not a particularly good idea.
FWIW, for new stuff, Rust is a good choice.
Also, being at Mozilla, I can understand why memory management seems like priority #1. You are a platform!
The rest of us are building on the shifting sands that the west coast creates. Keeping up with Microsoft changing this and Google changing that is WAAAAY more trouble than pointer arithmetic (for me anyway).
Deleted Comment
I agree with that, and most people do even in the Rust community. I don't expect people to rewrite their software in Rust, but if people could stop writing new C code[1], the world would become a better place in the next decades …
> Whenever C gets brought up, people are like, "pointers... memory... dangerous!" In 20+ years of C, I've never had a (self-inflicted) problem in that area.
In 20+ years of C, you never faced a single segfault ?! I'm sorry but I don't trust you. You're basically pretending being the One True God of programming.
[1]: even in a full C project, it's straightforward to write you new code in Rust in separate files, thanks to Rust really good interop with C. Example: https://bawk.space/2016/10/06/c-to-rust.html
There's nothing godlike about it - it's just practice. He's been using C for 20+ years. So that's probably 10+ years of very little or no Bad UB Voodoo.
This is why C and Unix are irredeemably flawed designs; they trust the individual programmer/sysadmin to get things right and disaster happens when they don't. In the case of Unix, it can be demolished with a single fat-fingered rm command as root. VMS made a different call: in VMS it is assumed that the sysadmin is tired and hasn't had their coffee. This affects everything from how permissions are assigned to the notorious verbosity -- and extensive help system -- of the VMS shell. Properly configured, VMS was darn-near impregnable; it had also never fallen to the sort of buffer vulnerability common under Unix.
From the reboot one group is doing:
http://modula-2.info/m2r10/pmwiki.php/Spec/DesignPrinciples
The best we can hope for in the medium term (20 years?) is to have C as a target / intermediate / escape (ie. FFI) language.
The implication here being that Rust is adequate, I take it? Let us not circle around the issue!
You could assert the same for assembler, and yet, assembler is the ultimate programming - the last stop: highest performance, maximum control, no safety. When then, was the last time you heard or read someone claiming that "assembler is inadequate", especially when it comes to security?
I could think of no language more adequate to push the electronics to their limit, and beyond, as Commodore 64 teaches us over and over again, even in 2016.
All I want to say is that your argument rings hollow. Yes, C has no safety. If my code has a hole, it will be noone's fault but my own. And that's the way I like it: it is far more preferable to an ultracomplex programming language like Rust.
And finally, a Zen koan: I was troubleshooting some code today, which I wrote in AWK. Now the code transformed the data exactly as I had coded it, and the code was 100% correct, the transformed data was exactly as expected, yet no output was coming out.
Everything which was in the program was 100% correct. The problem wasn't in that which was in the program, but that which was not: there was no clause to output the transformed data. There is enlightment to be had from this tale, specifically about security, and even more specifically about Rust the programming language and its compiler.
YES: Because you're right. Small more iterative changes in terms of tightening up the language to allow for more predictable software (and environment like the kernel) can get us a long way ahead.
NO: Because even though you're very correct, there comes a point in any software stack where the expenses of rewriting the whole thing are vastly smaller than the expenses of iteratively reworking it.
I have drifted away from C/C++ a long time ago -- around 10 years. I personally got sick and tired of per-compiler quirks, different precompiler policies, and writing sed scripts to fix messed up preprocessed files, to name only 3 generic problems.
IMO I believe if something between Golang and Rust comes along and brings only their positives to the table, it'll be very worth to rewrite (or make richer version of) a huge amount of legacy tools in them -- especially if they bring extremely easy cross-compiling and strong runtime guarantees.
I don't know enough to claim either way but in my eyes C has been around for a very long time and a good chunk of the complaints are still in place. I'm tempted to think the community had its chance and that it's time something [somewhat] better must replace it.
It's like, "Oh, to be C-2016 compliant I've got to get rid of all my calls to unsafe string functions." Search, replace, and some elbow-grease later, and I've improved my program with a much lower likelihood of breaking functionality.
Worst experiences I've had in that domain were due to inconsistencies in things like the Win32 API across different OS versions that were allegedly supposed to behave the same way.
Sometimes I think better API and language documentation would improve programs more than better languages.
From my experience using a simple subset of C++ using things like shared_ptr reduces problems a lot.
That you know of.
(Also a meta-note about HN discussion: we have years of people saying "there's a problem here" and one guy saying "it's not a problem for me", seemingly unable to see why anyone else has a problem. "Works for me" is not a mission statement.)
As the article states, it's resurgence is bc of restricted small devices, but that's not because it's a great language. Debugging memory issues is horrible, having strange things happen because of randomness between compilers, no fun.
I had a recent desire to get back to baremetal, but I didn't go back to C; I have too many battle scars. I went to Rust, and have never looked back or regretted it. The FFI between Rust and C is pretty easy too for any cases where I need it.
It is sort of looking like the industry as a whole is starting to see if there isn't a better way to do things and I think we will see how things shake out in the next five years or so.
When I was doing my CS degree it was Java all the way.
I mean, today you can start a Haskell or OCaml project without people laughing at you.
Thank you.
That said, take the kind of lifelong momentum that PHP has, and multiply it by a few orders of magnitude, and you have C. It will be a very long time before C is replaced by anything.
Is rust willing to make that commitment? Or even 5 years? 2?
By comparison, C++ has precisely two working open source compilers --- clang and gcc --- and Rust has one: if you commit to using Rust, you're also committing yourself to an LLVM-based monoculture. The chances of the entire Rust team being simultaneously hit by a bus is low... but it's something that needs to be factored into a product assessment.
rust currently has only one backend, which is LLVM, but their is a working project to build an alternative one for the Cretonne compiler[1] for the «debug» builds, and there might also be a GCC backend for rustc one day if people are interested enough to build it. I'm not aware of any fundamental difficulties that would prevent it.
[1]: https://internals.rust-lang.org/t/possible-alternative-compi...
The language with the most sensible implementations seems to be javascript, I guess.
That's not necessarily a bad thing since the compilers are all open source and you can port them to whatever platform you want anyway. C managed to spawn a lot of adequate compilers, but the language itself has seen very few changes since it was standardized (27 years ago), while all the other contenders (including C++!) see a major release at least every 2-3 years, and up to several times a year (for Rust).
You can't have that pace of changes and still maintain compatibility between all the different implementations.
Practically, PHP has one interpreter, but if they go out, you can be assured that someone will fork and maintain it.
On the other hand, if MyToyLangOnGitHubGraduateProject goes belly up, you're stuck maintaining it yourself.
To be fair, it's an amazing language, but if you're coding to get things done with a deadline (or with an unknown set of specs), of course you should go for the nailgun instead of making custom hammers.
There are many articles by others out there for getting going with Rust on baremetal, and with Rustup it's now easy to cross compile from your Dev computer to the tartget device.
I don't know much about other languages, but it seems C is pretty well tailored for doing all bit-level stuff. Is rust the same way?
I did C++ for about 20 years, and gradually reverted to C, simply because of the footprint and the ease of maintaining a C codebase compared to a C++ codebase. C++ codebase's footprint will /explode/ very quickly, while it's really, really hard to do that with C.
You can't have 'shockwave' effects in C codebases; you can't have an intern adding a subtle 2 liner to your codebase in an obscure base class and make the footprint of your application explode. (been there...). It's a lot easier to review, test and maintain over a number of years.
Also, I've grown up considerably since I believed object oriented programming is THE way to solve everything related to programming problems, I've seen a lot of cases where you'd have a spaggetti plate of classes to solve a problem while you in fact could have solved that problem in a 15 line static function.
C -- especially C99 with it's extensions -- is nice, lightweight, hard to mess around with. it's actually a sharp tool but at least it's a straight sharp tool. You know where it's going and how it can hurt you. It's not the case for many of the other solutions who just add bloat to try to hide the fact that they are about as sharp cutting, but it'll get you at the back of the head, later :-)
I keep a keen eye on what's going on with Rust and Go in particular, but it'll be a long time still for me to commit to any of the new kids on the block. Right at this minute I imagine myself easily having to rage-recode it in C at some critical point because of some unforeseen effect.
My only regret with C is that the C committee is completely out there. C11 doesn't solve any of the problems that would be useful for 99% of C programming. Like, rolling in some of the GNU extensions that have been around for 25+ years (case X...Y comes to mind!)
I really like the take on the "sharp tools" analogy here: https://www.schneems.com/2016/08/16/sharp-tools.html . Your tool might be sharp, but that doesn't mean that you can't make it safer to use.
https://www.youtube.com/watch?v=eiYoBbEZwlk
Maybe we need to use your sharp tools point with that video. It drives the point home with even experienced people losing fingers to their tools followed by tech modified to prevent it. The demo also never gets old. Just too badass.
> This design is an evolution of planes over centuries of use
How did early ones look like then? Was getting hurt by them a problem, at all?
I'm not debating that main point, that in many cases, safety and usefulness are orthogonal. But that example is kind of worse than none.
The consequence is having to painstakingly code everything at a low level of detail though, with only macros and its limited functions to rely on for code reuse. This would be fine for low-level embedded work, but anything other than that is simply painful, unproductive and in my opinion not fun at all. I shudder at the thought of having to manually free resources, to use the embarrassing C strings and arrays or having to write dozens or hundreds of line of code to do one simple thing that C++ can do more safely and also in a highly-reusable way.
C is inadequate and has been for a long time. Its status of mythical, hardcore programming language continues to protect it, but slowly people are becoming more outraged at its inadequacies, as they should be. That's what the fuss is about.
As for small devices in this day and age, it's not like we can't use cross compilers hosted on desktop computers, since that what phone/tablet systems already do.
You just answered your own question: most people don't apply sufficient care and attention. So should we leave sharp tools lying around and encourage their use knowing they're going to be abused and cause serious problems?
What do you mean by "footprint" here? Because if it's heap space or CPU, you can certainly have it.
And if I can 'have' that, where do I stop?
That was my principal problem with C++ in the end; you'd get some people in the codebase, and then it was endless fear of someone screwing it up, or deciding that it was such a good idea to add 'boost' thingies to the application because it was SO much nicer. And added 20MB to the installer size (let alone memory footprint).
I remember one day when I investigated why the new version of our commercial application was taking about a minute to startup while it used to take about 15 seconds...
After a long time, pain and effort, it turned out that someone had decided that one of the String class accessors would take it's String parameter as a value, and not as a reference. ONE character source code difference, but it made the millions of Strings created at startup being duplicated, converted back forth from UTF16 to UTF8, destructed etc etc etc.
For the "why not X" crowd, the problem is that there are very few Xs out there with 30+ years of code to build off of. That, and it's almost a psychosis among us CS grads to overestimate the magic that "better" languages are capable of.
For unsafe memory management errors leading to RCEs it's a different story. Guess what language are the patches usually in.
Some people do things where performance is crucial. This is probably why Intel is moving into the FPGA space and Google is making their own accelerators for machine learning.
Instead one hears complaints about Python's GIL, hears about people moving to golang, about this new thing called Rust, about a C and C++ resurgence and so on.
How did nginx unseat apache?
I loved my junior days programming in C & C++. It was really fun writing your own logging framework, container classes etc. OTOH spending weeks looking for root causes of memory problems was fun the first few years then became an annoyance.
Higher level languages are much more productive - which was initially great, but now I feel more like a sysadmin than a programmer. Its a lot of researching, wiring up and configuring libraries. Probably results in better results but not as fun as hitting the metal.
So sometimes I wish I could go back to the old days but my nostalgia is probably rose tinted. I'd love to do it, but I don't think its commercially productive enough, so I'm skeptical of talk of a resurgence.
That being said, I don't think I'd like to do C professionally and I'll happily stick with languages the manage my memory and have all kinds of libraries that give me "free" stuff.
It has a different learning curve from C, as initially you'll be having a hard time getting programs to compile at all, but from that point the ergonomics are much better and you don't ever have to deal memory bugs unless you're developing a low-level library.
Rust is so awesome. Unlike Python or Ruby it's typesafe at compile time. Unlike Java and Go, it has no dumb GC, and unlike C and C++ it's memory safe. At compile time!
Programs can be distributed as a single binary, which makes deployment a breeze.
If that weren't enough, Rust innovates beyond every language I know of with its compile time threadsafety and fucking sweet package manager. (Cargo is seriously the best package manager I've ever used--perhaps the best in existence right now.)
Give Rust a try. It's freaking awesome.
(I'll buy you a coffee if you do and don't like it!)
Deleted Comment
It seems like nostalgia is a big thing over the past few years. Old game emulators, people getting back into C64 or whatever. I guess it's fun for some people. I've considered playing with such stuff, but I know I'd miss some of the real advances we've made since then.
But my major projects at work are in C. My previous job was about 50% C, 50% scripting languages. For all C's deficiencies it's a known quantity and does its job well enough. And knowing C well is a rare enough skill to be valuable, apparently.
When I don't need C I'd much rather reach for something like ocaml/haskell, a lisp, erlang/elixir, or something. Basically I ignore all the "C replacement" languages because I can either use C or pick something way better.
Think of it like this: In python you could be a beginner, and still write effective code to accomplish your goal. And while it might be slow, you also avoid having deal with a great many subtleties, which in C, to write code for a similar function, you could very well need to be high-intermediate to write the same bug-free code.
Faster? Most likely, but if it's error-prone, does speed really matter?
That's my belief anyway, ymmv.
The other I've commonly seen is transitioning from a language that allows arbitrary data in a "string" variable. Null-terminated strings are no fun in comparison, and passing buffers around is more work.
The only thing that's uniquely an advantage of C in the article is understanding legacy code in popular projects. It's mostly in C for historical & social reasons. Mastering C is a great help there. Although, one could still use Ada (Ada-to-C compiler) or DSL approaches above with better results when writing code. Maintainers won't accept that in popular projects, though. So, back to knowing & writing good C for this sort of thing.
http://ivorylang.org/ivory-introduction.html
As much as I love C (despite its flaws), I have to agree here: Like drinking, C is only fun if you do it socially. If you do it nonsocially at all hours, your friends might begin to distance themselves from you. Or hold an intervention.
Is that your point?
C is great too. C99 especially so. C11 threads are good too. C20 seems to be on a good path as well, here's its charter: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2086.htm
Only thing I would add to C as a language or in standard libraries is some kind of (better) string and UTF handling. ICU4C is coolio, but too much. Antirez's SDS looks cool, but I haven't used it, so I don't know from practice how/if it works with UTF and if it's great in production.
The nobody does part seems off given amount of customers companies like AdaCore have and how much is recurring business. Safety-critical industries like tools that help software work correctly from the start. A significant chunk, esp in aerospace, use Ada.
As I Get Older™, I'm starting to agree with the Suckless[1] people that the small-project way is better, and that one of the reasons it's better is that C still works for it. Projects that are small enough for a single developer to understand in the nature of things have fewer problems. Yes, that would mean a change in what we expect software to do and how we expect it to behave, but that changes all the time anyways, and I think a pendulum swing back in the minimalist direction would be a good thing.
[1] http://suckless.org
What was dubbed hugeware was actually small by today's standards.