8 ms·

Death to C

61 points by ggonweb 11y ago

lambdaelite 11y ago
So for a mission critical or safety critical system, what's the alternative? It looks like the options are: 1, assembler 2, C + validated compiler + static verification + coding standard (MISRA-C maybe) 3, C++ + validated compiler + static verification + coding standard (MISRA-C++ maybe) 4, Java + specialized VM with RTSJ + static verification + coding standard (RTSJ) 5, Ada/SPARK + ??? So really, C/C++/Java/Ada aren't being used alone, it's the language + validated compiler + verification tools + a coding standard that are being used. How are Haskell, Rust, Go, and whatever other nouveau language of interest to the HN crowd tenable options for serious work when they lack the ecosystem of a formal standard, validated compilers and verification tools, track record, etc.?
cpncrunch 11y ago
I think the article points out the real problem: overly complex code. If you make the effort to write sensible, simple, easy to understand code, it's definitely possible to review every line of code to ensure there are no memory management bugs.
marvel_boy 11y ago
Newbie here. Can anyone share their experiences with Rust?
- vbezhenar 11y ago
  I generally work with high level languages (Java, JavaScript, Scala) but I always loved C (and in some ways C++) because it's so close to metal. I fell in love with Rust. Usually I (internally) complain about a lot of things in languages. There are many drawbacks and bad design decisions. It might be hard to express but there's sense of engineering beaty. And I like Rust almost in every way. So far I wrote a bunch of little programs and some simple parser (bitmessage protocol). I didn't have any real problems. Macroses looked a bit clumsy, I hope they'll see some overhaul, but they did their work. Much better than cpp anyway. And I can say that it's just so easy to write code when you're 100% sure there are no problems with memory management. There are billion of other little things making life easier, but painless memory management is the big one.
- steveklabnik 11y ago
  I just posted this paper[1] to HN. It's an bachelor thesis comparing Rust, Go, and C for high performance computing. The author claims to have 'moderate' experience with Rust and C, at least. It includes a story about how the Rust version actually caught an error in the C and Go implementation. 1: http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf
- st3fan 11y ago
  I'm interested in those stories too. Also do a search for Rust in the story subject here on HN. There are many many 'one week with rust' and 'moving to rust' articles posted. Many are interesting reads.
- Eerie 11y ago
  Newbie here. My first language was Python, then I wanted to learn a so-called low-level language, but not C or C++, as I felt I don't have THAT much free time to waste. This left me only Rust, and it is a pleasure to learn. The compiler errors are very helpful, and so is the community. You can take your time and gradually discover new stuff, like the difference between heap and stack, static/dynamic dispatch, Move vs. Copy semantics, usefulness of tagged unions in combination with pattern matching and so on...
  - mdup 11y ago
    And if you ever want to learn C++ later (C++11 specifically), you'll have a big chunk of the work already done. Rust's move semantics are very helpful to understand C++ smart pointers, for example. Also, lambdas/closures. You'll also miss how you were babysitted (in a good sense!) by the Rust compiler, whereas C++ does not care if you mess up with dangling references!
- cornstalks 11y ago
  I mainly program in C and C++, but have recently started a side project in Rust. So these are thoughts from a Rust newbie (which I still think can be valuable): Pros: - Pattern matching is beautiful, and is one of the things I miss most when not working in Racket. - I love their static typing. I think they hit a sweet spot with type inference inside of functions but required types to be specified as parameters (too much inference can make it hard to know exactly what type something is, too little inference means I spend all my time writing type signatures). - Borrowing and lifetimes are neat and have helped me avoid some lifetime-related bugs. - Being able to call Rust code from C is a huge win, and I think this world needs more "systems-level" languages than C and C++. Cons: - Borrowing and lifetimes. This is actually is a huge pro, but sometimes the compiler can spot a lifetime issue that I don't understand (which makes fixing it hard). I'll get better with this with time, but associating lifetimes with object types is a bit confusing and hard to do if you want to do anything nontrivial. Again, I'm sure this is mostly because I'm a newbie, but it's also reality. - Verbosity. Rust is actually concise for the most part, but if you want to pass a &str to a function, but have a String, (which, FYI, is fairly common in my experience, as most string-related functions take a &str), you've got to either call as_str() (which is unstable) or dereference-reference (i.e. &*) the String. There are a few simple things that require you to be more verbose than some other languages do. Overall I like Rust. I think it's worth experimenting with, but I wouldn't start a really serious project with it right now (because it's so young and volatile). If someone wants to use it for a really serious project, I'd suggest checking out Rust in another year or two when it's a little more mature.
  - steveklabnik 11y ago
    Glad you're having a good time with Rust. :) One small note: > if you want to pass a &str to a function, but have a String You can just add a & to your String. &String coerces to &str. Deref coercions are one of the few places where Rust does an implicit coercion: http://doc.rust-lang.org/nightly/book/deref-coercions.html http://doc.rust-lang.org/nightly/book/deref-coercions.html
    - cornstalks 11y ago
      Ah, cool, that's much better! Is that relatively new? I swear you had to do &* if you had a String and & if you had a &String. Edit: Ah, here: https://github.com/rust-lang/rfcs/blob/master/text/0241-deref-conversions.md#benefits-of-the-design https://github.com/rust-lang/rfcs/blob/master/text/0241-dere...
gregjor 11y ago
Well, there's Go. Java was supposed to fix all of these problems, but it's a mess in its own way. There's no perfect language. Almost simultaneously with C the Pascal language was introduced, completely safe and easier to learn. It enjoyed a period of popularity, and for a while it was widely taught in high schools and universities. Some big systems were built in Pascal, but every big Pascal app I've ever seen relied on external code in C (or assembly language) because Pascal is hobbled to enforce safety (see Brian Kernighan's article "Why Pascal Is Not My Favorite Programming Language, http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html). Some of Pascal's faults were fixed in Modula and Oberon but those never got any traction. To be absolutely safe the language is either crippled so it's missing important features, or it requires a runtime to sandbox everything, check pointer references, do garbage collection, etc. And that slows things down. I don't see C going away any time soon in embedded software, which is where bugs and vulnerabilities can be most dangerous and where they are hardest to fix. It's not much of a disaster for a video game to crash, but it can be very bad if piece of hospital hardware or a flight control system has a latent bug. There are tools that can analyze C code both statically and dynamically -- the language is not just old, it's mature. I'm sure someone is already rewriting the Linux kernel and all of the Unix-y tools in Rust or Go or whatever. I won't hold my breath.
- coldtea 11y ago
  >Well, there's Go. Not for the things C is good for. OS work, drivers, common libs like OpenSSL callable from other apps, infrastructure work, etc. Besides Go is nothing new. There have been similar languages ever since 1970, and they are not replacing C.
  - __Joker 11y ago
    Agree, better shout out would be Rust. Also referring the complete interview[1] which the TC article quotes, which seems to be favouring Rust. [1]. https://www.codementor.io/rust/tutorial/steve-klabnik-rust-vs-c-go-ocaml-erlang https://www.codementor.io/rust/tutorial/steve-klabnik-rust-v...
    - 11y ago
falcolas 11y ago
I personally don't see Rust as a good replacement for C - it's too complex a language, and it is especially easy to loose sight of what is happening at a low level due to all of the abstractions. Even if you did decide to use Rust instead of C in C's typical domain - operating systems, drivers, and constrained resource devices - you would be forced into using "unsafe" blocks anytime you had to interact directly with the hardware, manually manage memory, or issue ASM commands; at which point you're as vulnerable to programming mistakes as C.
- neikos 11y ago
  Not necessarily as the idea is to isolate those components into the unsafe blocks, and having locality on a bug is a pretty big component of fixing it.
  - hga 11y ago
    Well, that's locality on what in theory could be causing a bug, but not on where it might manifest, i.e. a wild pointer trashing data maintained by purely safe code. Still, in theory isolating the possible causes is a fantastic advantage.
- wyldfire 11y ago
  > at which point you're as vulnerable to programming mistakes as C. Yes, but if you start off in C's typical domain, then you cannot decompose your problem set into safe and unsafe bins using C. So you're stuck with unsafe-lowest-common-denominator everywhere you go.
- sharpercoder 11y ago
  This is okay. The point is that the majority of time, compiler checks/errors warn you from mistakes in safe code blocks. As such, you can put more focus on the actual unsafe parts. It is not about completely removing unsafe stuff. It is about reducing the possible mistakes as much as possible.
- rhodysurf 11y ago
  I agree. One of the best parts of C is how simple it is.
gnuvince 11y ago
You're not going to convince C programmers simply by beseeching them. The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe and of how Rust addresses that. There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead (or to be called by C without overhead). Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much.
- coldtea 11y ago
  >* The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe* Every C programmer already knows what kind of C issues exist, and how with C you can screw up things and what operations are unsafe. It's not like he's saying something novel that will leave C programmers scratching their head as to the value of a safer language. >There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead He suggested they look at it, and he gave the basic 10,000 foot overview. It's not like C programmers (an industry with millions) will convert simply if some random blog post gave more specific examples...
- ci5er 11y ago
  I really like the promise of Rust. I mostly like its design. But, for myself, I notice this: Writing Rust programs (vs. writing C programs) correctly is hard! N.B. This might be an old dog new tricks thing. I automatically structure my programs (be they rendering engines, or computation/numerical simulations or even agent-based simulations) where allocating and freeing memory from/to pools just isn't that hard. I don't really think about it. I just throw together my code, compile it and run it. Of course, I make many (many!) silly/stupid mistakes during the course of development, but failing to free a pointer is rarely one of them. Now I loop back to your point. (Sorry I took the long way) > Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much. I know what the problems of C are. I am aware of the alternatives. But the problems of C don't seem to be overwhelming enough to bother throwing away and constructing an entirely new tool-chain and support system on whatever your platform is. That was a pretty bold statement, and I would invite a response. I would like to think that we, as an industry, are not just implementing new language ecosystems because we can't be bothered to free our pointers...
wyldfire 11y ago
I'll confess, I have looked ever-so-briefly at D and Go and I figured that Rust was probably similar to Go but I just didn't take the time to learn about it. I like the idea of D (especially design-by-contract), but I have difficulty convincing my colleagues (and myself) that a product with a garbage collector can perform consistently well enough. Then I read this in TFA: > Despite guaranteeing memory safety, Rust does not have a garbage collector or runtime, and one of the benefits of this is that Rust code can be called from C with no setup at all. Maybe I should think about it as "you always enable ASan in your production binary"? That suits me just fine, if that's one of its major benefits. I will resolve today to follow up on Rust and try to learn more about it.
- steveklabnik 11y ago
  Most of Rust's safety guarantees are at compile time, not at runtime, and so have no runtime overhead. ASan's docs claim a 2x slowdown. That said, defense in depth is always nice. kmc got AFL working with Rust recently, and it's uncovered some things. Using an ASan-like tool to do some of the runtime stuff would be great to have.
  - wyldfire 11y ago
    > uncovered some things Those were problems with the rust compiler or the binaries it generates?
    - steveklabnik 11y ago
      Three things so far. Two in the parser, one in generated code: - https://github.com/rust-lang/rust/issues/24276 https://github.com/rust-lang/rust/issues/24276 - https://github.com/rust-lang/rust/issues/24275 https://github.com/rust-lang/rust/issues/24275 - https://github.com/rust-lang/rust/issues/21889 https://github.com/rust-lang/rust/issues/21889
christianbryant 11y ago
I'm sorry, but as a user and hacker of UNIX, POSIX and all things GNU/Linux since 1996 I have to say this is just fruitless and counter-productive. Although, I will support the sentiment "Death to C++" :-) The argument is over-simplified and rather than looking to the root of the problem tries to sweep it under the rug by also ignoring the fact that many new languages have their interpreters written in C. The root issue is that the C language needs an update, an overhaul, and that once the standard has been refreshed, C will continue to be the #1 language among programmers. Sadly, nothing can be done for C++ and to lump C and C++ together is as upsetting as calling for programmers to cease the use of C! :-) Last thought: There needs to also be more focus on teaching programmers how to write secure C programs. Every year new exploits are released that target insecure C programming styles, and the C community should make sure programmers are being educated on how to avoid these issues. Look to subsets like MISRA C as an example and a move in the right direction; advocating secure programming/language subsets rather than changing languages ultimately makes more sense.
- deleted 11y ago
  [deleted]
- asveikau 11y ago
  If you are a c leaning c++ hater, as I used to be, I would encourage you to look at some of the more recent techniques and standards in depth. Some examples I can probably not do justice towards in a short post: stl giving you inline-able data structures, functors (and now lambdas) giving you inline-able callbacks, raii for making C's "goto cleanup block" idiom more automatic, rvalue references getting rid of a lot of the unnecessary copies of "old" c++. There are a lot of warts in the language and a lot of people in the community writing bad code. But there is a good language emerging, and plenty for low-level hackers to appreciate.
  - christianbryant 11y ago
    As a hacker rather than programmer, I am pretty much stuck on the C train, so any distaste for C++ is reactionary and not borne of actual programming experience :-) However, I have noted in my career that almost every package I regularly use and have to do something with at the build level is written in C (or Lisp). However, I do know of one project written in C++ that I respect and does great things, and that is GNU Octave. Lambda expressions in the STL... Go figure!
damian2000 11y ago
I'm sure C will be still going for a while yet in embedded development ... microcontrollers, etc. There's usually no other option except assembler.
- steveklabnik 11y ago
  While this is true for many embedded platforms, if it's an architecture that LLVM knows about, you can use Rust on it. That said, many have just a proprietary C compiler, or something similar for a barrier to entry, it's true.
- federico3 11y ago
  That's why I'm looking at Nim http://nim-lang.org/ http://nim-lang.org/ - it generates C code and compiles through GCC
- agumonkey 11y ago
  I wonder how Haskell DSL (I think one is called Atom) would fare on this.
leonatan 11y ago
And here's hoping for the death of sensationalist articles with zero substance.
- coldtea 11y ago
  Or sensationalist comments with zero substance. Perhaps there should be this unwritten rule, that if a post has made it to the front page of HN, it means enough HN users voted it, and it's interesting to them, so it's counter-productive to dismiss it as uninteresting...
  - leonatan 11y ago
    An article can be up voted for many reasons, including mockery. I was not dismissing the post here, but the article itself. Also, it is already off of the front page.
- wiggumz 11y ago
  That's Jon Evans' specialty FYI
  - leonatan 11y ago
    I am not familiar with his posts, but it is very often these days that uneducated liberal arts majors who attempt passing as serious journalists, have no clue what they are writing about (usually rephrasing blogger and forum posts as their own), trying their best to make as much sensational article titles at best, in an attempt to lure casual readers in. But instead of enriching the casual readers with information, like journalism used to, now they are subjected to substance-free jibber jabber.
weland 11y ago
My list of "things I hate about C" is about 4 pages long now, after many years in embedded development (and a few in scientific computing prior to that). As soon as a viable replacement for it comes, I'm going to get drunk, ritually burn K&R's "The C Programming Language" then get drunk again. But I've been waiting for that day for a long, long, long time, and there's still no sign of it, not even with Rust (maybe with Go but we'll have to see). I cannot think of a single systems programming language that has not vowed to put an end to all this buffer overflow and dangling pointers mess. The ones I tried so far (I think there's a dozen...) failed because of at least of one of the following items: * Some of them mainly achieve safety by forbidding any unsafe read or write -- and then when you have to do a read or a write, they implement that by cleverly eschewing a protection mechanism or by isolating everything in an unsafe area. The former is disastrous because you can have bugs that eschew the protection mechanisms, too (see Heartbleed -- which can be perfectly replicated in Rust or Go); the latter, while useful in most application software, is next to useless in my day to day activity, where I have entire modules that consist of nothing other than unsafe reads or writes. At that point I might as well be using C. * Others mainly achieve safety through a complicated system of annotations ("this parameter must not be NULL") or a type system that makes certain guarantees ("these parameter can never be NULL"). The end result is a system of annotations and/or types which you can describe in about as much space as The C Programming Languages takes to describe the whole language. Barring the fact that my memory is limited after ingesting C++, real life experience shows that "more complexity" is how bugs get introduced, rather than resolved. Except that the new problems don't arise because a pointer is pointing where it shouldn't, but rather because 1 == 1 returns False for certain types of 1 or something. * Aaand some of them simply delude themselves through clever sandboxing and protected writes, ignoring the fact that the sandboxing back-end is C all the way and can be exploited. Except it's so mind-boggingly complex that fixing it is incredibly complicated. Historically, there have been many instances of operating systems written in high-level (ish) languages. Hell, there are operating systems written in Common Lisp. It can be done. People haven't flocked towards high-level languages despite 30 bloody years, if not more, of operating systems written in high-level languages because it turns out you usually can't do it unless you turn most of those fancy protection features off. At which point you end up with C, only with a more complicated syntax, and why the hell bother? The key to writing secure software that doesn't crash is still in correct programming. Tooling can help, but no language, no matter how fancy and hand-holding, is going to compensate for that.
deleted 11y ago
[deleted]
wiggumz 11y ago
Jon Evans, master complainer. C could be improved, but the amount of important C code out there (Linux...) militates against adopting a new C. Is someone going to pay to switch over the code base? Ultimately if a newer, tighter, safer C is going to arise it must come fron the GCC or LLVM people. Go: owned by google so it's a no-go.
- chris_j 11y ago
  What is it able Go being owned by Google that makes out a no-go?
  - wiggumz 11y ago
    If it's owned by a corporation that participates in the PRISM program I would not trust them.
- Intermernet 11y ago
  > Go: owned by google so it's a no-go. It's actually an open source project, and many of the core contributors don't work for Google. Just thought I'd point this out as it seems to be a common misconception.
  - wiggumz 11y ago
    And are people expected to download the compiler executable from Google's website? Given that the CIA recently bragged that they were able to put spyware in iOS apps because they have somehow exploited Xcode on developers' machines, one has to think about the implications of downloading executables from companies that are complicit in spying. Just because I do something safe e.g. I compiled the compiler myself, it is the larger implication of everyone else not doing it right that is the concern.
    - Intermernet 11y ago
      Or you could compile it yourself from the github repo.
kazinator 11y ago
Rather than "death to C" a better viewpoint is: minimize our use of C and anything that looks like it. We don't need a better C, in which to write mega-projects. There is a parallel here in assembly language. Once upon a time, programmers extended the viability of assembly language by building smarter assemblers with powerful macros and such. None of that is necessary if you minimize your use of assembly language, so that all you have in your system that is in assembly language is a few atomic instructions, some context saving/restoring code, interrupt dispatch, and a speedy memcpy and whatnot. Going from C to Rust (or Go, or C++ or whatever) is kind of like trying to use a deluxe assembler to write large assembly language programs with better reliability. If I'm going to leave C behind for some task, it's because I want to get away from that sort of semantics---any version of that semantics.
dibanez 11y ago
In order for a language to replace C, it has to do two things: 1) be able to write an OS kernel competitive with Linux in this language. 2) get its compiler(s) ported to new architectures, including the Top500 supercomputers, where I work. Note that these two help each other: you make a new architecture, you either code a custom OS in C or port Linux, both of which start with a port of a C compiler. If your language can't do the OS thing, C will remain out of necessity, and be too tempting and stable an alternative.
- wiggumz 11y ago
  Someone to come up with a list of 10 reforms for C, nail it to Kernighan's or Ritchie's front door, and start a new language sect.
hamiltonkibbe 11y ago
The whole fallacy with articles like this is that they all too often show why a language is unsuited for some subset of tasks and then proclaim "death to $LANGUAGE." There's a time and place for C, and while writing a web framework is probably not that place, I think for embedded C is going to be around for a while. Sometimes you need to do things that could potentially cause problems (like every single pointer dereference) because there are deadlines for things to happen. If DMA had to check whether the place it's about to write the next 4 sample from the ADC is ok every single time, you might very well miss it
xorcist 11y ago
Yeah. "Stop using PostgreSQL and Redis. And Linux." Then these people usually go on to describe a completely different problem domain, it used to be something-lisp and now it's ruby-whatever. Problem is, sooner or later you need to be using the operating system for something more than just starting processes, be it controlling file handles or sandbox code or whatever. Then you need API compatibility and control over your mallocs. Which isn't impossible in non-systems PLs, but it isn't exactly a walk in the park either, as you're basically left calling wrappers for syscalls instead of doing it directly, which means you have master both your runtime and your C-based operating system. At least this time they have an answer that's at least worth listening to. The newest crop of languages with Rust and Go actually make an effort towards system programming. That excites me! Now all you have to do is make something as secure and robust as Redis or Postfix, and let's see how it fares in production. And if Servo grows to be a fully grown competitive web browser, applying binary deltas to itself, sandboxing GL code, and everything in between, that would be a great litmus test for Rust to actually compete with C++.
- Ygg2 11y ago
  > And if Servo grows to be a fully grown competitive web browser From what I hear Servo is a research project. There exists a great chance it will never become a fully grown web browser. It already started sandboxing some code, but I'm not sure what binary deltas have to do with massively parallel web brwoser.
dom96 11y ago
There is no way that any language can truly replace C at this point, C will still be around for the foreseeable future. We should learn to coexist with it not replace it.
- steveklabnik 11y ago
  This is generally the position of the Rust team as well. It's also why the zero-overhead interop is important to us.
sudioStudio64 11y ago
Hardware level approaches to making C more secure are in the works at Intel. Hardware assisted bounds checking and the like...http://en.wikipedia.org/wiki/Intel_MPX http://en.wikipedia.org/wiki/Intel_MPX The main thing that will finally convince people that a high-level of abstraction is OK for OS level programming is for someone to get off their a$$ and build one. (That's actually usable. It would have to be SO usable that people could quickly build out the new user code to make something like *nix or windows seem like more of a hassle in contrast. That's such an insanely tall order...not sure how you get there.) I think that the best you'll ever be able to do is to build systems with frameworks that are safe(r). People won't give up C because it makes them feel smarter. The pile of code for C based systems will be with us forever. A new system would have to be able to do all that AND be safe.
- wiggumz 11y ago
  You're missing a key point. What makes Linux usable is that it has numerous drivers written for it... written in C. An OS's core is not supremely difficult to write. But the drivers are... Much specialized knowledge is required.
denim_chicken 11y ago
The C ecosystem has tools designed to compensate for its issues. There's valgrind, static analysis, debuggers, asan, tsan, etc.. With its immense popularity, its flexibility and portability, and its mature, comprehensive ecosystem behind it, there's no all-purpose programming language better than C (expect maybe C++).
michaelochurch 11y ago
Terrible title. A more useful dialogue would be along the lines of "Death to C where it is inappropriate", but C isn't used much these days where it's the wrong tool for the job. Mostly, C is used for the things that C does very well. Maybe we'd agree on "Death to C++ where it's inappropriate", because C++ is much more often used (than C) where it isn't appropriate. Then we have to go down the rabbit hole of why C++ often sucks, and we realize that it's not even that it's a bad language itself (not that it's great, but it doesn't have to be horrible) so much as object-oriented programming (OOP) has been bastardized by business, and misused by reactively-writing programmers under tight deadlines, to create obfuscation. Then we realize that this problem is even more severe in Java codebases. Then we wonder if a new language can really fix a problem (code quality) that is partially sociological and political... The counterexample to the "C is unsafe" argument is that C is what people use for extremely high-reliability programming. I prefer Haskell, and Rust is promising, but the fact is that JPL uses C. The Mars Rover is probably running C code. While C is insecure as hell under typical corporate use (tight deadlines, unskilled programmers) it can be pretty damn reliable in the right hands.
- kyllo 11y ago
  Do you think that avionics software is an appropriate application of C? Boeing does... http://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-bug/ http://www.engadget.com/2015/05/01/boeing-787-dreamliner-sof...
Animats 11y ago
Rust people, please don't screw up. We desperately need a replacement for C. Rust could be it. But it's not too late for the Rust crowd to blow it. Rust may have too much cruft at version 1.0 for C programmers. Things that worry me about Rust: * Too much mandatory metaprogramming. Basic things such as I/O require generics, and even lambdas. Rust's cruft level in this area picks up where C++ with Boost left off. * Error handling is too verbose. Wrapping things in "Result<>" and "Some<>", then unwrapping them with "match" is wordy. Wrapping that in generics makes it shorter but hides what's happening. * The type system and type inference are very complex, and type errors induced from another module can be hard to diagnose. * Too much language churn. Supposedly "stable" modules still keep changing. I'm surprised when I recompile a program after a few weeks and it still works. This needs to settle down very soon. * Resource Allocation is Initialization. Initialization isn't that bad, but what do you do about an error discovered in a destructor? Destructors are always troublesome, and Rust doesn't seem to have that area under control. A "with" clause approach would have been cleaner. The recent discovery of a soundness problem in Rust destructors is being handled in a way that bears watching. First, the actual issue reporting the problem was closed without a fix.[1] The discussion was "moved to an RFC" so as not to block the release of Rust 1.0.[2] Related issues are now being discussed to death. A good discussion of the issue is at [3]. While Rust avoids complex run-time abstractions, it has very complex compile-time abstractions. Rust has all the cool abstraction ideas - closures, generics, templates, type inference, RAII, functional programming, etc. This may be too much for the C crowd. The basic libraries use all these features, so you can't restrict their use on a project. [1] https://github.com/rust-lang/rust/issues/24456 https://github.com/rust-lang/rust/issues/24456 [2] https://github.com/rust-lang/rfcs/pull/1066 https://github.com/rust-lang/rfcs/pull/1066 [3] http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-reference-counting-and-leaks/ http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-r...
- barosl 11y ago
  I understand your anxiety on the complexity of Rust. I wonder if there were a language that fixes exactly the pitfalls of C (e.g. sane string manipulation), without adding any high level concepts, but with memory safety. However, at the same time I think the language researchers cannot help but add abstractions on today's languages. The unusual exception was Go, but it failed to target the same niche as C/C++ at the end. Actually I think there are more people who like abstractions than those who like the extreme simplicity of C. So unfortunately, a "direct" replacement of C will not happen in the foreseeable future, I think.
mtunjic 11y ago
Safe programming is bogus programming.
a-saleh 11y ago
Can anybody point me to a good 'modern c programming' book? I liked the approach of Learn C the Hard Way, (i.e. lesson 1: "Now compile the hello.c with -Wall", lesson 2: "Lets learn to write simple makefiles",..., lesson 4: "Lets use Valgrind", ...) But the latest revision of the last chapter that I remember had quite a good critique of K&R's C writing style, now contains just a rant on internet trolls (?). http://c.learncodethehardway.org/book/krcritique.html http://c.learncodethehardway.org/book/krcritique.html

61 points by ggonweb 11y ago

So for a mission critical or safety critical system, what's the alternative? It looks like the options are: 1, assembler 2, C + validated compiler + static verification + coding standard (MISRA-C maybe) 3, C++ + validated compiler + static verification + coding standard (MISRA-C++ maybe) 4, Java + specialized VM with RTSJ + static verification + coding standard (RTSJ) 5, Ada/SPARK + ??? So really, C/C++/Java/Ada aren't being used alone, it's the language + validated compiler + verification tools + a coding standard that are being used. How are Haskell, Rust, Go, and whatever other nouveau language of interest to the HN crowd tenable options for serious work when they lack the ecosystem of a formal standard, validated compilers and verification tools, track record, etc.?

cpncrunch 11y ago

I think the article points out the real problem: overly complex code. If you make the effort to write sensible, simple, easy to understand code, it's definitely possible to review every line of code to ensure there are no memory management bugs.

marvel_boy 11y ago

Newbie here. Can anyone share their experiences with Rust?

vbezhenar 11y ago
I generally work with high level languages (Java, JavaScript, Scala) but I always loved C (and in some ways C++) because it's so close to metal. I fell in love with Rust. Usually I (internally) complain about a lot of things in languages. There are many drawbacks and bad design decisions. It might be hard to express but there's sense of engineering beaty. And I like Rust almost in every way. So far I wrote a bunch of little programs and some simple parser (bitmessage protocol). I didn't have any real problems. Macroses looked a bit clumsy, I hope they'll see some overhaul, but they did their work. Much better than cpp anyway. And I can say that it's just so easy to write code when you're 100% sure there are no problems with memory management. There are billion of other little things making life easier, but painless memory management is the big one.
steveklabnik 11y ago
I just posted this paper[1] to HN. It's an bachelor thesis comparing Rust, Go, and C for high performance computing. The author claims to have 'moderate' experience with Rust and C, at least. It includes a story about how the Rust version actually caught an error in the C and Go implementation. 1: http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf http://octarineparrot.com/assets/mrfloya-thesis-ba.pdf
st3fan 11y ago
I'm interested in those stories too. Also do a search for Rust in the story subject here on HN. There are many many 'one week with rust' and 'moving to rust' articles posted. Many are interesting reads.
Eerie 11y ago
Newbie here. My first language was Python, then I wanted to learn a so-called low-level language, but not C or C++, as I felt I don't have THAT much free time to waste. This left me only Rust, and it is a pleasure to learn. The compiler errors are very helpful, and so is the community. You can take your time and gradually discover new stuff, like the difference between heap and stack, static/dynamic dispatch, Move vs. Copy semantics, usefulness of tagged unions in combination with pattern matching and so on...
- mdup 11y ago
  And if you ever want to learn C++ later (C++11 specifically), you'll have a big chunk of the work already done. Rust's move semantics are very helpful to understand C++ smart pointers, for example. Also, lambdas/closures. You'll also miss how you were babysitted (in a good sense!) by the Rust compiler, whereas C++ does not care if you mess up with dangling references!
cornstalks 11y ago
I mainly program in C and C++, but have recently started a side project in Rust. So these are thoughts from a Rust newbie (which I still think can be valuable): Pros: - Pattern matching is beautiful, and is one of the things I miss most when not working in Racket. - I love their static typing. I think they hit a sweet spot with type inference inside of functions but required types to be specified as parameters (too much inference can make it hard to know exactly what type something is, too little inference means I spend all my time writing type signatures). - Borrowing and lifetimes are neat and have helped me avoid some lifetime-related bugs. - Being able to call Rust code from C is a huge win, and I think this world needs more "systems-level" languages than C and C++. Cons: - Borrowing and lifetimes. This is actually is a huge pro, but sometimes the compiler can spot a lifetime issue that I don't understand (which makes fixing it hard). I'll get better with this with time, but associating lifetimes with object types is a bit confusing and hard to do if you want to do anything nontrivial. Again, I'm sure this is mostly because I'm a newbie, but it's also reality. - Verbosity. Rust is actually concise for the most part, but if you want to pass a &str to a function, but have a String, (which, FYI, is fairly common in my experience, as most string-related functions take a &str), you've got to either call as_str() (which is unstable) or dereference-reference (i.e. &*) the String. There are a few simple things that require you to be more verbose than some other languages do. Overall I like Rust. I think it's worth experimenting with, but I wouldn't start a really serious project with it right now (because it's so young and volatile). If someone wants to use it for a really serious project, I'd suggest checking out Rust in another year or two when it's a little more mature.
- steveklabnik 11y ago
  Glad you're having a good time with Rust. :) One small note: > if you want to pass a &str to a function, but have a String You can just add a & to your String. &String coerces to &str. Deref coercions are one of the few places where Rust does an implicit coercion: http://doc.rust-lang.org/nightly/book/deref-coercions.html http://doc.rust-lang.org/nightly/book/deref-coercions.html
  - cornstalks 11y ago
    Ah, cool, that's much better! Is that relatively new? I swear you had to do &* if you had a String and & if you had a &String. Edit: Ah, here: https://github.com/rust-lang/rfcs/blob/master/text/0241-deref-conversions.md#benefits-of-the-design https://github.com/rust-lang/rfcs/blob/master/text/0241-dere...

gregjor 11y ago

Well, there's Go. Java was supposed to fix all of these problems, but it's a mess in its own way. There's no perfect language. Almost simultaneously with C the Pascal language was introduced, completely safe and easier to learn. It enjoyed a period of popularity, and for a while it was widely taught in high schools and universities. Some big systems were built in Pascal, but every big Pascal app I've ever seen relied on external code in C (or assembly language) because Pascal is hobbled to enforce safety (see Brian Kernighan's article "Why Pascal Is Not My Favorite Programming Language, http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html). Some of Pascal's faults were fixed in Modula and Oberon but those never got any traction. To be absolutely safe the language is either crippled so it's missing important features, or it requires a runtime to sandbox everything, check pointer references, do garbage collection, etc. And that slows things down. I don't see C going away any time soon in embedded software, which is where bugs and vulnerabilities can be most dangerous and where they are hardest to fix. It's not much of a disaster for a video game to crash, but it can be very bad if piece of hospital hardware or a flight control system has a latent bug. There are tools that can analyze C code both statically and dynamically -- the language is not just old, it's mature. I'm sure someone is already rewriting the Linux kernel and all of the Unix-y tools in Rust or Go or whatever. I won't hold my breath.

coldtea 11y ago
>Well, there's Go. Not for the things C is good for. OS work, drivers, common libs like OpenSSL callable from other apps, infrastructure work, etc. Besides Go is nothing new. There have been similar languages ever since 1970, and they are not replacing C.
- __Joker 11y ago
  Agree, better shout out would be Rust. Also referring the complete interview[1] which the TC article quotes, which seems to be favouring Rust. [1]. https://www.codementor.io/rust/tutorial/steve-klabnik-rust-vs-c-go-ocaml-erlang https://www.codementor.io/rust/tutorial/steve-klabnik-rust-v...
  - 11y ago

falcolas 11y ago

I personally don't see Rust as a good replacement for C - it's too complex a language, and it is especially easy to loose sight of what is happening at a low level due to all of the abstractions. Even if you did decide to use Rust instead of C in C's typical domain - operating systems, drivers, and constrained resource devices - you would be forced into using "unsafe" blocks anytime you had to interact directly with the hardware, manually manage memory, or issue ASM commands; at which point you're as vulnerable to programming mistakes as C.

neikos 11y ago
Not necessarily as the idea is to isolate those components into the unsafe blocks, and having locality on a bug is a pretty big component of fixing it.
- hga 11y ago
  Well, that's locality on what in theory could be causing a bug, but not on where it might manifest, i.e. a wild pointer trashing data maintained by purely safe code. Still, in theory isolating the possible causes is a fantastic advantage.
wyldfire 11y ago
> at which point you're as vulnerable to programming mistakes as C. Yes, but if you start off in C's typical domain, then you cannot decompose your problem set into safe and unsafe bins using C. So you're stuck with unsafe-lowest-common-denominator everywhere you go.
sharpercoder 11y ago
This is okay. The point is that the majority of time, compiler checks/errors warn you from mistakes in safe code blocks. As such, you can put more focus on the actual unsafe parts. It is not about completely removing unsafe stuff. It is about reducing the possible mistakes as much as possible.
rhodysurf 11y ago
I agree. One of the best parts of C is how simple it is.

gnuvince 11y ago

You're not going to convince C programmers simply by beseeching them. The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe and of how Rust addresses that. There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead (or to be called by C without overhead). Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much.

coldtea 11y ago
>* The article is missing an entire component: the argument for Rust. There needed to be examples of C programs that one may write that are actually unsafe* Every C programmer already knows what kind of C issues exist, and how with C you can screw up things and what operations are unsafe. It's not like he's saying something novel that will leave C programmers scratching their head as to the value of a safer language. >There needed to be a discussion on the performance of Rust, and of its ability to call into C without overhead He suggested they look at it, and he gave the basic 10,000 foot overview. It's not like C programmers (an industry with millions) will convert simply if some random blog post gave more specific examples...
ci5er 11y ago
I really like the promise of Rust. I mostly like its design. But, for myself, I notice this: Writing Rust programs (vs. writing C programs) correctly is hard! N.B. This might be an old dog new tricks thing. I automatically structure my programs (be they rendering engines, or computation/numerical simulations or even agent-based simulations) where allocating and freeing memory from/to pools just isn't that hard. I don't really think about it. I just throw together my code, compile it and run it. Of course, I make many (many!) silly/stupid mistakes during the course of development, but failing to free a pointer is rarely one of them. Now I loop back to your point. (Sorry I took the long way) > Everyone already knows what the problems of C are, what they need to know is what the alternatives offer and how in the end you are not giving up too much. I know what the problems of C are. I am aware of the alternatives. But the problems of C don't seem to be overwhelming enough to bother throwing away and constructing an entirely new tool-chain and support system on whatever your platform is. That was a pretty bold statement, and I would invite a response. I would like to think that we, as an industry, are not just implementing new language ecosystems because we can't be bothered to free our pointers...

wyldfire 11y ago

I'll confess, I have looked ever-so-briefly at D and Go and I figured that Rust was probably similar to Go but I just didn't take the time to learn about it. I like the idea of D (especially design-by-contract), but I have difficulty convincing my colleagues (and myself) that a product with a garbage collector can perform consistently well enough. Then I read this in TFA: > Despite guaranteeing memory safety, Rust does not have a garbage collector or runtime, and one of the benefits of this is that Rust code can be called from C with no setup at all. Maybe I should think about it as "you always enable ASan in your production binary"? That suits me just fine, if that's one of its major benefits. I will resolve today to follow up on Rust and try to learn more about it.

steveklabnik 11y ago
Most of Rust's safety guarantees are at compile time, not at runtime, and so have no runtime overhead. ASan's docs claim a 2x slowdown. That said, defense in depth is always nice. kmc got AFL working with Rust recently, and it's uncovered some things. Using an ASan-like tool to do some of the runtime stuff would be great to have.
- wyldfire 11y ago
  > uncovered some things Those were problems with the rust compiler or the binaries it generates?
  - steveklabnik 11y ago
    Three things so far. Two in the parser, one in generated code: - https://github.com/rust-lang/rust/issues/24276 https://github.com/rust-lang/rust/issues/24276 - https://github.com/rust-lang/rust/issues/24275 https://github.com/rust-lang/rust/issues/24275 - https://github.com/rust-lang/rust/issues/21889 https://github.com/rust-lang/rust/issues/21889

christianbryant 11y ago

I'm sorry, but as a user and hacker of UNIX, POSIX and all things GNU/Linux since 1996 I have to say this is just fruitless and counter-productive. Although, I will support the sentiment "Death to C++" :-) The argument is over-simplified and rather than looking to the root of the problem tries to sweep it under the rug by also ignoring the fact that many new languages have their interpreters written in C. The root issue is that the C language needs an update, an overhaul, and that once the standard has been refreshed, C will continue to be the #1 language among programmers. Sadly, nothing can be done for C++ and to lump C and C++ together is as upsetting as calling for programmers to cease the use of C! :-) Last thought: There needs to also be more focus on teaching programmers how to write secure C programs. Every year new exploits are released that target insecure C programming styles, and the C community should make sure programmers are being educated on how to avoid these issues. Look to subsets like MISRA C as an example and a move in the right direction; advocating secure programming/language subsets rather than changing languages ultimately makes more sense.

deleted 11y ago
[deleted]
asveikau 11y ago
If you are a c leaning c++ hater, as I used to be, I would encourage you to look at some of the more recent techniques and standards in depth. Some examples I can probably not do justice towards in a short post: stl giving you inline-able data structures, functors (and now lambdas) giving you inline-able callbacks, raii for making C's "goto cleanup block" idiom more automatic, rvalue references getting rid of a lot of the unnecessary copies of "old" c++. There are a lot of warts in the language and a lot of people in the community writing bad code. But there is a good language emerging, and plenty for low-level hackers to appreciate.
- christianbryant 11y ago
  As a hacker rather than programmer, I am pretty much stuck on the C train, so any distaste for C++ is reactionary and not borne of actual programming experience :-) However, I have noted in my career that almost every package I regularly use and have to do something with at the build level is written in C (or Lisp). However, I do know of one project written in C++ that I respect and does great things, and that is GNU Octave. Lambda expressions in the STL... Go figure!

damian2000 11y ago

I'm sure C will be still going for a while yet in embedded development ... microcontrollers, etc. There's usually no other option except assembler.

steveklabnik 11y ago
While this is true for many embedded platforms, if it's an architecture that LLVM knows about, you can use Rust on it. That said, many have just a proprietary C compiler, or something similar for a barrier to entry, it's true.
federico3 11y ago
That's why I'm looking at Nim http://nim-lang.org/ http://nim-lang.org/ - it generates C code and compiles through GCC
agumonkey 11y ago
I wonder how Haskell DSL (I think one is called Atom) would fare on this.

leonatan 11y ago

And here's hoping for the death of sensationalist articles with zero substance.

coldtea 11y ago
Or sensationalist comments with zero substance. Perhaps there should be this unwritten rule, that if a post has made it to the front page of HN, it means enough HN users voted it, and it's interesting to them, so it's counter-productive to dismiss it as uninteresting...
- leonatan 11y ago
  An article can be up voted for many reasons, including mockery. I was not dismissing the post here, but the article itself. Also, it is already off of the front page.
wiggumz 11y ago
That's Jon Evans' specialty FYI
- leonatan 11y ago
  I am not familiar with his posts, but it is very often these days that uneducated liberal arts majors who attempt passing as serious journalists, have no clue what they are writing about (usually rephrasing blogger and forum posts as their own), trying their best to make as much sensational article titles at best, in an attempt to lure casual readers in. But instead of enriching the casual readers with information, like journalism used to, now they are subjected to substance-free jibber jabber.

weland 11y ago

My list of "things I hate about C" is about 4 pages long now, after many years in embedded development (and a few in scientific computing prior to that). As soon as a viable replacement for it comes, I'm going to get drunk, ritually burn K&R's "The C Programming Language" then get drunk again. But I've been waiting for that day for a long, long, long time, and there's still no sign of it, not even with Rust (maybe with Go but we'll have to see). I cannot think of a single systems programming language that has not vowed to put an end to all this buffer overflow and dangling pointers mess. The ones I tried so far (I think there's a dozen...) failed because of at least of one of the following items: * Some of them mainly achieve safety by forbidding any unsafe read or write -- and then when you have to do a read or a write, they implement that by cleverly eschewing a protection mechanism or by isolating everything in an unsafe area. The former is disastrous because you can have bugs that eschew the protection mechanisms, too (see Heartbleed -- which can be perfectly replicated in Rust or Go); the latter, while useful in most application software, is next to useless in my day to day activity, where I have entire modules that consist of nothing other than unsafe reads or writes. At that point I might as well be using C. * Others mainly achieve safety through a complicated system of annotations ("this parameter must not be NULL") or a type system that makes certain guarantees ("these parameter can never be NULL"). The end result is a system of annotations and/or types which you can describe in about as much space as The C Programming Languages takes to describe the whole language. Barring the fact that my memory is limited after ingesting C++, real life experience shows that "more complexity" is how bugs get introduced, rather than resolved. Except that the new problems don't arise because a pointer is pointing where it shouldn't, but rather because 1 == 1 returns False for certain types of 1 or something. * Aaand some of them simply delude themselves through clever sandboxing and protected writes, ignoring the fact that the sandboxing back-end is C all the way and can be exploited. Except it's so mind-boggingly complex that fixing it is incredibly complicated. Historically, there have been many instances of operating systems written in high-level (ish) languages. Hell, there are operating systems written in Common Lisp. It can be done. People haven't flocked towards high-level languages despite 30 bloody years, if not more, of operating systems written in high-level languages because it turns out you usually can't do it unless you turn most of those fancy protection features off. At which point you end up with C, only with a more complicated syntax, and why the hell bother? The key to writing secure software that doesn't crash is still in correct programming. Tooling can help, but no language, no matter how fancy and hand-holding, is going to compensate for that.

deleted 11y ago

[deleted]

wiggumz 11y ago

Jon Evans, master complainer. C could be improved, but the amount of important C code out there (Linux...) militates against adopting a new C. Is someone going to pay to switch over the code base? Ultimately if a newer, tighter, safer C is going to arise it must come fron the GCC or LLVM people. Go: owned by google so it's a no-go.

chris_j 11y ago
What is it able Go being owned by Google that makes out a no-go?
- wiggumz 11y ago
  If it's owned by a corporation that participates in the PRISM program I would not trust them.
Intermernet 11y ago
> Go: owned by google so it's a no-go. It's actually an open source project, and many of the core contributors don't work for Google. Just thought I'd point this out as it seems to be a common misconception.
- wiggumz 11y ago
  And are people expected to download the compiler executable from Google's website? Given that the CIA recently bragged that they were able to put spyware in iOS apps because they have somehow exploited Xcode on developers' machines, one has to think about the implications of downloading executables from companies that are complicit in spying. Just because I do something safe e.g. I compiled the compiler myself, it is the larger implication of everyone else not doing it right that is the concern.
  - Intermernet 11y ago
    Or you could compile it yourself from the github repo.

kazinator 11y ago

Rather than "death to C" a better viewpoint is: minimize our use of C and anything that looks like it. We don't need a better C, in which to write mega-projects. There is a parallel here in assembly language. Once upon a time, programmers extended the viability of assembly language by building smarter assemblers with powerful macros and such. None of that is necessary if you minimize your use of assembly language, so that all you have in your system that is in assembly language is a few atomic instructions, some context saving/restoring code, interrupt dispatch, and a speedy memcpy and whatnot. Going from C to Rust (or Go, or C++ or whatever) is kind of like trying to use a deluxe assembler to write large assembly language programs with better reliability. If I'm going to leave C behind for some task, it's because I want to get away from that sort of semantics---any version of that semantics.

dibanez 11y ago

In order for a language to replace C, it has to do two things: 1) be able to write an OS kernel competitive with Linux in this language. 2) get its compiler(s) ported to new architectures, including the Top500 supercomputers, where I work. Note that these two help each other: you make a new architecture, you either code a custom OS in C or port Linux, both of which start with a port of a C compiler. If your language can't do the OS thing, C will remain out of necessity, and be too tempting and stable an alternative.

wiggumz 11y ago
Someone to come up with a list of 10 reforms for C, nail it to Kernighan's or Ritchie's front door, and start a new language sect.

hamiltonkibbe 11y ago

The whole fallacy with articles like this is that they all too often show why a language is unsuited for some subset of tasks and then proclaim "death to $LANGUAGE." There's a time and place for C, and while writing a web framework is probably not that place, I think for embedded C is going to be around for a while. Sometimes you need to do things that could potentially cause problems (like every single pointer dereference) because there are deadlines for things to happen. If DMA had to check whether the place it's about to write the next 4 sample from the ADC is ok every single time, you might very well miss it

xorcist 11y ago

Yeah. "Stop using PostgreSQL and Redis. And Linux." Then these people usually go on to describe a completely different problem domain, it used to be something-lisp and now it's ruby-whatever. Problem is, sooner or later you need to be using the operating system for something more than just starting processes, be it controlling file handles or sandbox code or whatever. Then you need API compatibility and control over your mallocs. Which isn't impossible in non-systems PLs, but it isn't exactly a walk in the park either, as you're basically left calling wrappers for syscalls instead of doing it directly, which means you have master both your runtime and your C-based operating system. At least this time they have an answer that's at least worth listening to. The newest crop of languages with Rust and Go actually make an effort towards system programming. That excites me! Now all you have to do is make something as secure and robust as Redis or Postfix, and let's see how it fares in production. And if Servo grows to be a fully grown competitive web browser, applying binary deltas to itself, sandboxing GL code, and everything in between, that would be a great litmus test for Rust to actually compete with C++.

Ygg2 11y ago
> And if Servo grows to be a fully grown competitive web browser From what I hear Servo is a research project. There exists a great chance it will never become a fully grown web browser. It already started sandboxing some code, but I'm not sure what binary deltas have to do with massively parallel web brwoser.

dom96 11y ago

There is no way that any language can truly replace C at this point, C will still be around for the foreseeable future. We should learn to coexist with it not replace it.

steveklabnik 11y ago
This is generally the position of the Rust team as well. It's also why the zero-overhead interop is important to us.

sudioStudio64 11y ago

Hardware level approaches to making C more secure are in the works at Intel. Hardware assisted bounds checking and the like...http://en.wikipedia.org/wiki/Intel_MPX http://en.wikipedia.org/wiki/Intel_MPX The main thing that will finally convince people that a high-level of abstraction is OK for OS level programming is for someone to get off their a$$ and build one. (That's actually usable. It would have to be SO usable that people could quickly build out the new user code to make something like *nix or windows seem like more of a hassle in contrast. That's such an insanely tall order...not sure how you get there.) I think that the best you'll ever be able to do is to build systems with frameworks that are safe(r). People won't give up C because it makes them feel smarter. The pile of code for C based systems will be with us forever. A new system would have to be able to do all that AND be safe.

wiggumz 11y ago
You're missing a key point. What makes Linux usable is that it has numerous drivers written for it... written in C. An OS's core is not supremely difficult to write. But the drivers are... Much specialized knowledge is required.

denim_chicken 11y ago

The C ecosystem has tools designed to compensate for its issues. There's valgrind, static analysis, debuggers, asan, tsan, etc.. With its immense popularity, its flexibility and portability, and its mature, comprehensive ecosystem behind it, there's no all-purpose programming language better than C (expect maybe C++).

michaelochurch 11y ago

Terrible title. A more useful dialogue would be along the lines of "Death to C where it is inappropriate", but C isn't used much these days where it's the wrong tool for the job. Mostly, C is used for the things that C does very well. Maybe we'd agree on "Death to C++ where it's inappropriate", because C++ is much more often used (than C) where it isn't appropriate. Then we have to go down the rabbit hole of why C++ often sucks, and we realize that it's not even that it's a bad language itself (not that it's great, but it doesn't have to be horrible) so much as object-oriented programming (OOP) has been bastardized by business, and misused by reactively-writing programmers under tight deadlines, to create obfuscation. Then we realize that this problem is even more severe in Java codebases. Then we wonder if a new language can really fix a problem (code quality) that is partially sociological and political... The counterexample to the "C is unsafe" argument is that C is what people use for extremely high-reliability programming. I prefer Haskell, and Rust is promising, but the fact is that JPL uses C. The Mars Rover is probably running C code. While C is insecure as hell under typical corporate use (tight deadlines, unskilled programmers) it can be pretty damn reliable in the right hands.

kyllo 11y ago
Do you think that avionics software is an appropriate application of C? Boeing does... http://www.engadget.com/2015/05/01/boeing-787-dreamliner-software-bug/ http://www.engadget.com/2015/05/01/boeing-787-dreamliner-sof...

Animats 11y ago

Rust people, please don't screw up. We desperately need a replacement for C. Rust could be it. But it's not too late for the Rust crowd to blow it. Rust may have too much cruft at version 1.0 for C programmers. Things that worry me about Rust: * Too much mandatory metaprogramming. Basic things such as I/O require generics, and even lambdas. Rust's cruft level in this area picks up where C++ with Boost left off. * Error handling is too verbose. Wrapping things in "Result<>" and "Some<>", then unwrapping them with "match" is wordy. Wrapping that in generics makes it shorter but hides what's happening. * The type system and type inference are very complex, and type errors induced from another module can be hard to diagnose. * Too much language churn. Supposedly "stable" modules still keep changing. I'm surprised when I recompile a program after a few weeks and it still works. This needs to settle down very soon. * Resource Allocation is Initialization. Initialization isn't that bad, but what do you do about an error discovered in a destructor? Destructors are always troublesome, and Rust doesn't seem to have that area under control. A "with" clause approach would have been cleaner. The recent discovery of a soundness problem in Rust destructors is being handled in a way that bears watching. First, the actual issue reporting the problem was closed without a fix.[1] The discussion was "moved to an RFC" so as not to block the release of Rust 1.0.[2] Related issues are now being discussed to death. A good discussion of the issue is at [3]. While Rust avoids complex run-time abstractions, it has very complex compile-time abstractions. Rust has all the cool abstraction ideas - closures, generics, templates, type inference, RAII, functional programming, etc. This may be too much for the C crowd. The basic libraries use all these features, so you can't restrict their use on a project. [1] https://github.com/rust-lang/rust/issues/24456 https://github.com/rust-lang/rust/issues/24456 [2] https://github.com/rust-lang/rfcs/pull/1066 https://github.com/rust-lang/rfcs/pull/1066 [3] http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-reference-counting-and-leaks/ http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-r...

barosl 11y ago
I understand your anxiety on the complexity of Rust. I wonder if there were a language that fixes exactly the pitfalls of C (e.g. sane string manipulation), without adding any high level concepts, but with memory safety. However, at the same time I think the language researchers cannot help but add abstractions on today's languages. The unusual exception was Go, but it failed to target the same niche as C/C++ at the end. Actually I think there are more people who like abstractions than those who like the extreme simplicity of C. So unfortunately, a "direct" replacement of C will not happen in the foreseeable future, I think.

mtunjic 11y ago

Safe programming is bogus programming.

a-saleh 11y ago

Can anybody point me to a good 'modern c programming' book? I liked the approach of Learn C the Hard Way, (i.e. lesson 1: "Now compile the hello.c with -Wall", lesson 2: "Lets learn to write simple makefiles",..., lesson 4: "Lets use Valgrind", ...) But the latest revision of the last chapter that I remember had quite a good critique of K&R's C writing style, now contains just a rant on internet trolls (?). http://c.learncodethehardway.org/book/krcritique.html http://c.learncodethehardway.org/book/krcritique.html