Slashdot Mirror


TechCrunch Urges Developers: Replace C Code With Rust (techcrunch.com)

Software engineer and TechCrunch columnist Jon Evans writes that the C programming language "gives its users far too much artillery with which to shoot their feet off" and is "no longer suitable for the world which C has built." An anonymous reader shared Evans' post: Copious experience has taught us all, the hard way, that it is very difficult, verging on "basically impossible," to write extensive amounts of C code that is not riddled with security holes. As I wrote two years ago, in my first Death To C piece... "Buffer overflows and dangling pointers lead to catastrophic security holes, again and again and again, just like yesteryear, just like all the years of yore. We cannot afford its gargantuan, gaping security blind spots any more. It's long past time to retire and replace it with another language.

"The trouble is, most modern languages don't even try to replace C... They're not good at the thing C does best: getting down to the bare metal and working at mach speed." Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust... we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time."

He also suggests other fixes -- like using a language-theoretic approach which conceptualizes valid inputs as their own formal language, and formal verification of the correctness of algorithms. But he still insists that "C has become a monster" -- and that we must start replacing it with Rust.

63 of 505 comments (clear)

  1. Yes, go ahead! by mveloso · · Score: 5, Insightful

    Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?

    1. Re:Yes, go ahead! by SCVonSteroids · · Score: 4, Funny

      Well if this guy says so, what doubts could you possibly have left?

      --
      I tend to rant.
    2. Re:Yes, go ahead! by BCooley · · Score: 5, Insightful

      He's not suggesting that at all.

      "..I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it — slowly, bit by bit — with Rust."

      He's suggesting that when you refactor a critical piece of C code - in other words you're already going to change it and potentially add brand new C/C++ security issues - you instead use a language with some form of god damn formal verification and some fucking way of validating that you're not opening a new exploitable vulnerability that will bring down half the damn internet.

      I mean is that really too much to ask?

    3. Re:Yes, go ahead! by Chris+Mattern · · Score: 4, Interesting

      I mean is that really too much to ask?

      Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.

      The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.

    4. Re:Yes, go ahead! by jmccue · · Score: 4, Insightful

      I think we should replace c with COBOL, no pointers, no dynamic memory allocation, rounding errors with floats rare and all strings fixed length.

      That is just as good an option as any for these crazy "my language is better than your's" posts

    5. Re: Yes, go ahead! by Zontar+The+Mindless · · Score: 2

      I would expect Slashdot users to post numerous variations on, "Is she hot?"

      --
      Il n'y a pas de Planet B.
    6. Re:Yes, go ahead! by Anonymous Coward · · Score: 3, Insightful

      I can never explain to people which things need to be validated in a safe manner in C, C++, or Java. Is Rust going to give me the tongue of a oceanside saltwater merchant, or open their ears?

    7. Re:Yes, go ahead! by ShanghaiBill · · Score: 4, Insightful

      What needs to happen is the cost of security breaches must greatly exceed the cost

      Why does that "need" to happen? If there was actually a "need" for secure and expensive software the marketplace would already be providing it. Most people want cheap, or even better, free. There is no political demand for an authoritarian solution to online security, nor should there be. Government involvement will stifle innovation, increase costs, and do little to actually solve the problem.

    8. Re:Yes, go ahead! by Jeremi · · Score: 4, Insightful

      Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.

      The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.

      It won't guarantee that your program does what you intended, but at least if your Rust program compiles, you have a pretty good assurance that it won't be corrupting its memory space and suffering from (potentially-exploitable) Undefined Behavior when it runs.

      The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.

      There's some truth to that; in most cases, people are only going to invest a modest, finite amount of additional time/effort/money into making code secure.

      Which is why it makes sense to minimize the cost of making code secure, e.g. by building the necessary checks into the language itself so that all programs benefit from them "for free".

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    9. Re: Yes, go ahead! by Anonymous+Brave+Guy · · Score: 4, Interesting

      A much better argument against formal regulation of the software development profession is that we don't know the best way to do it yet.

      We have centuries of experience building bridges, and have a pretty good idea of how to build bridges that don't fall down by accident, even under unlikely but plausible conditions like freak weather events or excessive loading because the public ignore some limit or other.

      We have decades of experience building software at all, and little consensus on the best way to do it. Indeed, we don't even have a clear definition for what "best" means in this context, and it's possible that depending on the purpose of and risks associated with software, a reasonable set of good practices might look entirely different in one case from another.

      Worse, the people who are most qualified to judge when we do reach that level of maturity within the industry, and to formally recognise good practices, are probably among the least likely to actually do that. They're probably too busy building good software where quality matters.

      Instead, there must be an all too realistic possibility that any formal regulatory system would be dominated by the famous consultblogauthspeakers who spend a career burnishing their profile within the industry, but who in many cases have remarkably little experience actually building working software of their own, never mind working software to a very high quality standard. The very last thing we need is these fools being given any real authority over developers who are trying to do better, or $DEITY forbid, being required to give their blessing to those developers before anyone can ship anything.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    10. Re:Yes, go ahead! by Anonymous Coward · · Score: 2, Interesting

      Pascal is the only language that's created a verified A-1 secure computer system, so let's use that.

    11. Re:Yes, go ahead! by Megane · · Score: 4, Interesting

      How about this: rewrite systemd in Rust first and I might consider it.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    12. Re:Yes, go ahead! by johanw · · Score: 2

      Aparently he didn't seem capable of hiring sysadmins who are thinking about making things possible instead of trying to prevent others from doing their jiob to remain their position of power.

    13. Re: Yes, go ahead! by Anonymous+Brave+Guy · · Score: 3, Interesting

      Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.

      It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)

      Finally, your hypothetical $100K low risk vulnerability is irrelevant, given that within the past few weeks alone we have seen major security outbreaks with consequences like bringing down large parts of the NHS infrastructure in the UK, which probably cost lives and certainly caused a great deal of unnecessary suffering. Even the lower bound on the cost of security screw-ups in modern software includes people dying unnecessarily.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    14. Re:Yes, go ahead! by doom · · Score: 2

      It's pretty impressive for a pundit to come up with this idea. Of course, "let's rewrite everything in rust!" it's already such a cliche I've seen people moderated down for posting it, but you have to expect pundits to be a little slow on these things.

      The response of the postgresql folks was something like "how about we finish porting it from lisp, first?"

    15. Re:Yes, go ahead! by AaronW · · Score: 3, Informative

      Rust is not all that portable. Rust is tied to LLVM. There are a lot more platforms supported by, say, GCC than LLVM. For example, I'm working on some Arduino and Xtensa based stuff at the moment. No Rust support but C and C++ are both supported. It's also trivial to link between C and assembly or for that matter C and just about any other language. I mix C and assembly all the time in the work that I do. I don't need any overhead of garbage collection, bounds checking, etc. either. The C calling ABI is very well documented and supported on all but the lowest end microcontrollers. If I write a library in C, it can be called from virtually any language. If I write a language in Rust, i doubt that would be the case. The C runtime library is pretty trivial. I've written bootloaders with only a page of assembly before calling the main function. By bootloader I'm referring to a true bootloader, code that is the first code executed when a CPU comes out of reset, not something called by the BIOS but code that will at some point load the BIOS.

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    16. Re: Yes, go ahead! by Chris+Mattern · · Score: 3, Insightful

      Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.

      It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)

      That means the first cost will be training a generation of developers in how to do it. Aside from assumptions, that will not be cheap.

      And actually, their ignorance is an argument. Corporations are very allergic to costs they can't estimate in advance. It's up to the advocates to demonstrate that it'll be cheap, not to the skeptics to demonstrate that it'll be expensive. That's the way the world works.

    17. Re: Yes, go ahead! by TheRaven64 · · Score: 4, Informative

      I work with a group that does formal verification and you seem also to be talking from a position of ignorance. Currently, the record for low-cost formally verified software is held by the NICTA team behind seL4. Their number is around 30 times the cost of using best practices for normal software development. A few caveats for this number:

      • The baseline is assuming the effort involved in creating a test suite with full coverage of the specification and a detailed specification. Few projects actually have this level of QA, so add another factor of 2-4 to the cost relative to most projects.
      • They're employing mathematicians on fairly low (academic-level) salaries for the verification. In an industrial setting, with skills in so much demand, you'd find it difficult to pay them less than double this.
      • Their entire software stack is around 10,000 lines of code and they've not yet shown that their verification effort scales linearly with the complexity of the software.
      • The cost of refactoring is close to the cost of initial development, as the proofs are not often reusable after modifications to the code.
      • It was a whole 6 hours between the first public release of their formally verified microkernel and someone finding the first exploitable security vulnerability.

      There's a lot of ongoing research in this area (I quite like F*, though it has some significant issues with proof reuse and usability of its error messages), but the tools for formal verification are currently as appropriate for large-scale modern software development as punch cards.

      --
      I am TheRaven on Soylent News
    18. Re:Yes, go ahead! by TheRaven64 · · Score: 4, Insightful

      The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.

      Please don't confuse type checking, using a non-verified type system, with formal verification.

      --
      I am TheRaven on Soylent News
    19. Re:Yes, go ahead! by TheRaven64 · · Score: 4, Informative

      Except that Rust is kinda a bit like C except with a formal verifier built in so you can prove you don't have memory errors

      Please stop repeating this. Rust has a type checker. Most languages have a type checker. The type system in Rust is stricter than that in C (though it is possible to implement the same thing in the library in C++), but it is not a formally verified type system and the implementation of the type checker (which is not a formal verifier) is also not verified (and can't be until the type system itself is verified). If you want a language with a formally verified type system, look at Pony. If you want a language that integrates formal verification, look at F*. If you want to use Rust, that's fine, but stop claiming that it has features that it doesn't.

      --
      I am TheRaven on Soylent News
    20. Re: Yes, go ahead! by Peter+La+Casse · · Score: 2

      The baseline is assuming the effort involved in creating a test suite with full coverage of the specification and a detailed specification.

      The detailed specification is an often overlooked cost driver in this scenario. Customers really hate having to write detailed specifications and then being held to them.

    21. Re: Yes, go ahead! by TheRaven64 · · Score: 2
      Two things:

      First, verifying the type system is formal verification, applying the results of a formally verified type system is still just type checking, not verification (except in the loosest possible sense of the word, with about the same level of accuracy as when the press says 'AI' when they mean 'algorithm'). A lot of verification works by reducing the problem to type checking, but in the case of Rust the guarantees afforded by the type system are not correctness according to the specification of your program (the property that you get from verification), they are much weaker (e.g. no data is aliased and mutable at the same time).

      Second, unlike that of Pony, the Rust type system is not yet verified and usually this kind of process is iterative, with the type system being found to be unsound during the verification process and fixed. Type systems are assumed to be unsound until they have been verified, type checking against an unsound type system is a long way from verification.

      --
      I am TheRaven on Soylent News
  2. Ada by Anonymous Coward · · Score: 4, Interesting

    Why now? Why rust? What about Ada? They're not so different that somehow the argument becomes that much better than it was for Ada. I just don't get all this rust hype. But, then again, I'm a C programmer, and I am 100% certainly I won't see C replaced in the systems I work on (cars), so it's a moot point. I would, however, support a move to Ada. My industry would never consider Rust. Pushing it over Ada is actually counterproduction, because it primes the C-suite to see languages pushed as a replacement for C as immature. Rust is still immature, way too immature for a conservative industry. Ada, though... maybe not.

    1. Re:Ada by david.emery · · Score: 4, Interesting

      In part it's a cultural thing. Ada is considered "complex and verbose" (but compare with Java). Ada is, of course, from the DoD, so it's "obviously bad." Most importantly, Ada requires a bit more thought before you jump into the code.

      The interesting thing about Ada is that a skilled practitioner learns how to use the language to his advantage. You code so the compiler checks as much as it can, so you can concentrate on things the compiler can't check. When the compiler and you agree the code is correct, it probably is, at least with respect to typos and coding errors.

      One big criticism I have with most languages, even those with a type system, is they don't support strongly typed scalars. But that's where type errors are most common. I don't think I ever tried to "add apples to oranges". But I have tried to add "count of apples" to "count of oranges" (or more specifically, once tried to add horizontal pixel location to vertical pixel location.)

      Furthermore, those who think their C code is "close to the machine" don't know much about modern machine architectures. Compilers do a LOT MORE work than they did in the days of the PDP-8/PDP-11 or original x86 family. Ada (among other 'higher level' languages) provides the modern compiler with a lot more information for code selection and optimization. For example, register flushing is a lot easier to manage in Ada because pointer types are always declared as such, and unless there are specific language constructs, the compiler can prove a given variable will not be accessed through its address (and therefore doesn't have to spill the register to memory.) That's a simple example, compiler optimizations and instruction scheduling are very complex topics.

      Finally, I've always thought C syntax was harmful, because it's so easy to make a mistake, either through ignorance or simple typo ("=" vs "==").

      I know experts can do amazing things in C. Aren't that may experts out there slinging code, and most of the software we use these days shows it!!

    2. Re:Ada by phantomfive · · Score: 2

      How does Ada prevent buffer overflows?
      How does Ada prevent memory leaks?

      (Maybe I should also ask how Ada prevents rockets from exploding, but Rust won't do that either)

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Ada by david.emery · · Score: 2

      #1 is not true. See https://sourceforge.net/projec... There's been a GPL Ada compiler for at least 30 years. The Ada Core product is open source, you pay for maintenance.

      For #2, the debate in many respects boils down to "simple programs in complex language" or "complex programs in a simple language." But see http://www.adacore.com/sparkpr... (and there are free versions of that, too), for a subset of Ada specifically designed to support proof-of-correctness.

    4. Re:Ada by Rockoon · · Score: 4, Interesting

      This will come up again and again. Every generation will need to be taught about Ada.

      This guys beginning premise is wrong. People dont use C because its "getting down to the bare metal and working at mach speed." C is not a "bare metal language" so that cannot be the reason. The reasons that people use C mainly stem from it being based on a simple yet expressive-enough abstract machine.

      C isnt the ideal language for its purpose. The issue is really that none of the other languages are suitable upgrades. Many of those other languages can greatly help with "security" .. truly they can .. but they are not based on a "simple yet expressive-enough abstract machine."

      Now Ada as used in practice is the language if you are looking for formal proofs about the algorithms expressed. Not only does the Ada abstract machine lend itself to formal proofs, there is a whole mature ecosystem of analysis software for Ada already there and being used. Quite a bit of military contract stuff has to be done in Ada.

      --
      "His name was James Damore."
    5. Re:Ada by david.emery · · Score: 2

      1. No address arithmetic. Arrays are programmed with bounds-checking, usually through dope vectors generated by the compiler. It is a requirement of the language to generate an exception if you try to go beyond the bounds of the array.

      2. Ada handles pointers through access types (which, by the way, are always checked before dereferencing to be sure the pointer is not null). There are coding styles and means to do memory management, e.g. setting up a memory pool for a specific access type. Ada95 and beyond includes good support for constructors and destructors. Under some circumstances, the compiler can prove when there are no more extant values for a given access type and reclaim the entire pool.

      That being said, if you're not a bit careful, you can program storage leaks in Ada through the normal mechanisms. It's not 100% foolproof. Some competence by the developer is required.

      And there are means to escape the restrictions of the language. These have substantial syntactic sugar, so the developer (coder, reviewer, tester) knows "we are now doing something extraordinary. Certain checks provided by the language no longer apply here." In my experience, the most skilled developers work on this stuff (carefully) and then package it up (pun intended!) for use by the rest of the project.

      And the Ariadne 5 incident is interesting, in part because the developers -turned off- the checks provided by the language!!! That's kinda like deciding you don't need seat belts in your car driving down the highway, because it passed crash testing.

    6. Re:Ada by phantomfive · · Score: 2

      Arrays are programmed with bounds-checking, usually through dope vectors generated by the compiler. It is a requirement of the language to generate an exception if you try to go beyond the bounds of the array.

      Doesn't a bounds-check on every array access slow things down?

      --
      "First they came for the slanderers and i said nothing."
    7. Re:Ada by david.emery · · Score: 3, Insightful

      The particular interesting thing about -avionics- is the cost of development is dwarfed by the cost of verification. I remember a presentation by Boeing Commercial Aircraft on the 777. They said, "We've done DO-178b Level A in a bunch of languages. For most languages, the cost to develop and the cost to verify is pretty much the same. For Ada [Ada83 - this was in the 90s], the cost to develop in Ada was 25% more than other languages. But the cost to -verify- that Ada was about 1/4 the cost of any other language. DO-178b Verification costs up to 10x development," He wouldn't say just how much that cost for 777, but he strongly implied it was multiple billions of dollars.

    8. Re:Ada by ckatko · · Score: 2

      You are what you eat?

    9. Re:Ada by david.emery · · Score: 2

      There's a lot of good stuff here: http://www.adahome.com/ and here: http://www.adaic.org/

      And It's "Ada" not "ADA". The language name is not an acronym. Rather it's named after Ada Countess Lovelace, see https://en.wikipedia.org/wiki/... The choice of the name was deliberate, Ada Lovelace is commonly cited as the first computer programmer (for Babbage's Analytical Engine). And that name long pre-dates the current initiatives for "women in computing." (There were a fair number of women involved with the Ada program, such as the late Jean Sammet, quite unusual in the late 1970s/early 1980s during the initial development of the requirements and then language itself.)

  3. Re:Betteridge's Law bullshit by war4peace · · Score: 2, Funny

    Well ain't that a self-confirming statement...

    --
    ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
  4. An embarrassing admission by BarbaraHudson · · Score: 4, Insightful

    Basically, this is an admission that the average programmer is fairly shitty. Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.

    --
    "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    1. Re:An embarrassing admission by Anonymous Coward · · Score: 2, Informative

      While in grad school I had a roommate take an introductory to programming course. I saw grave errors in the example code the lecturer was giving the students. It starts with the education. If they are not taught properly from the beginning don't expect anything but crap later.

      In the basic read stuff from a file example given to the students -

      char c;
      while ( (c=getc)!=-1) {
      }

    2. Re:An embarrassing admission by BCooley · · Score: 4, Insightful

      Yeah.. expert C programmers never write insecure code.

      Except for when they do, which is pretty much constantly because true expert C programmers know it's impossible to write any large piece of C/C++ software using it's native features without making at least a few mistakes.

      If you're a C programmer, and you don't already know this, then you aren't an expert.

    3. Re:An embarrassing admission by Anonymous Coward · · Score: 3, Insightful

      If the only way you can document your code is "this may look wrong but it's not" You're a shitty developer.

    4. Re:An embarrassing admission by swillden · · Score: 2

      Of course, a year after I left, someone modified the code and it started eating up ram. When they called me, I told them to put the code back the way it was, because even the source said "this may look wrong - but it's not. DO NOT TOUCH". They reverted to my old code, and everyone was happy.

      So... from that anecdote, are we to conclude that C code is unmaintainable, your code is unmaintainable, or both?

      All in all, your story is a great example of why C is bad. It took a long time to build something that worked correctly, and once completed the code is brittle and unmaintainable, to the degree that you felt the need to comment that it should not be touched. And you were apparently right. Also... the code could still be full of security holes. The fact that it runs correctly in normal circumstances says next to nothing about what happens under attack.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  5. Bullshit slashvertisement by lorinc · · Score: 3, Interesting

    Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.

    The usual PR stunt of "use my new language that is so good and so simple even a stupid high school teen with an IQ somewhere between stone and plankton in the phylogenetic tree could use it without wrecking anything" is not going to convince anybody here. It's boring at best, and no-one cares about your "advice".

    The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe. Oh, maybe it's because they are written by competent guys.

    1. Re:Bullshit slashvertisement by TheRaven64 · · Score: 2

      I'd argue that there aren't many good reasons to favour C over C++ these days and there's a much simpler migration path as most C code is valid (though not idiomatic) C++ code. Replacing bare arrays with std::array, collections implemented in macros with ones implemented in templates, and raw pointers with std::unique_ptr / std::shared_ptr will go a long way to catching bugs. You retain the ability to easily sidestep the type system if you need to, but a lot of the things that require you to in C can be simply implemented with C++.

      --
      I am TheRaven on Soylent News
    2. Re:Bullshit slashvertisement by sphealey · · Score: 2

      = = = Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright. = = =

      I've met a lot of very competent cabinetmakers over the years, but of those who use circular saws 80% are missing at least the tip of one finger. The SawStop technology seems like a good idea to me, although many deride it as "sissy stuff".

      In any case, the history of the last 30 years shows that you really can't depend only on having hired the "competent" programmers - there aren't enough of them, it is hard to determine who is/isn't until it is too late, and anyone can make a mistake.

      sPh

    3. Re:Bullshit slashvertisement by phantomfive · · Score: 2

      The first four bugs there wouldn't have been prevented by rewriting in Rust. They're logic errors (which happen in every language). That is the biggest downside or Rust: people think they will be secure by using it, leading to turning off their security brain.

      --
      "First they came for the slanderers and i said nothing."
    4. Re:Bullshit slashvertisement by Jeremi · · Score: 4, Insightful

      Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.

      A competent C developer will make only a very small number of mistakes per N lines of code, so that's a good thing.

      Of course, it only takes a single tiny mistake to produce potentially devastating consequences, so unless every single one of your C developers is not just good, but infallible, then by hiring "only" competent C programmers you are guaranteeing that your software will include a security hole, sooner or later.

      The problem with infallible C programmers is that they do not exist. The problem with competent C programmers is that there are only a limited number of them around, and it's not always easy to tell up front the competent C programmers from the seemingly-competent ones. Not to mention that every competent C programmer started out as a less-than-competent C programmer; if companies hired only competent C programmers, there would not be any competent C programmers since nobody would be able to make a living as a C programmer during the first N years of their programming career.

      Since the whole point of computers is to automate processes to make them quicker, easier, and less susceptible to human error, why would you not want to automate the creation of secure software, to the extent it is practical to do so?

      The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.

      Why do you think the Linux kernel is good and safe? It has suffered from many security holes in the past, and will probably suffer from more in the future. There are almost certainly multiple gaping security holes in the Linux kernel right now, just waiting to be discovered and exploited. And this is despite it being written by competent guys.

      Imagine how much more robust the Linux kernel would be if the competent guys were also using a language that caught more of their mistakes at compile-time, rather than leaving them to be discovered by testers, users or hackers at some later date. Dunno if Rust is the language to do that, but it's hard to see how automatic coding-error detection wouldn't be a big improvement over the status quo.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
    5. Re:Bullshit slashvertisement by SoftwareArtist · · Score: 2

      Hire competent C developers and you should be good to go.

      Anyone who is a competent C programmer understands the limitations of the language, knows there's a lot of truth in his criticisms, and uses C only when there are no other reasonable options. They understand that because they're competent C programmers.

      You can write correct code in any language, or incorrect code in any language, but the choice of language makes a really big difference in how many errors your code has. C is a minefield of potential errors that don't exist in many other languages, and then it only gives you really primitive tools for avoiding those errors. You're responsible for manually doing all memory allocation, and then manually freeing that memory when it's done, and you don't even have access to destructors or try/finally constructs to do that more safely. All memory access is through pointers, which can then be used to access any memory location in the program's address space. That's insane. We've learned a lot about language design in the 40 years since C was created, and we know there are much better ways of doing these things.

      At least use C++ instead of C. It's a superset of C, so it can do anything C can do. But it also provides tools for avoiding those problems. Use STL containers instead of arrays. Use references instead of pointers whenever possible. Use destructors to do your memory management via RAII. You will make fewer mistakes, and your code will contain fewer errors as a result.

      --
      "I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
  6. well, he's not wrong by Anonymous Coward · · Score: 3, Insightful

    C was one of the most influential languages the world has ever seen, but all things reach a point where time moves and and they are not good ideas for new projects any more. I don't think we should necessarily go replace every line of C code out there - couldn't if we wnanted to - but for new projects we should use better tools now.

    Tools do matter. It's just way way way too easy to write buffer overflows in C, even for highly experienced programmers. History shows that clearly. We need better tools that are not so dependent on the human being doing the checking. That isn't to argue you can't write bugs in Rust, just that it helps the programmer avoid some classes of problems. Slashdot readers tend to think "if it isn't 100% perfect and can't guarantee bug-free code then it must be worthless", but that's autism thinking at its finest.

    People get attached to "the way things have always been done", but sometimes it really is best to move on. Yes, there is still COBOL code out in the world but that's not a language people use very often now for new projects. It did its job decades ago but we have learned lessons since then and we don't have to repeat the mistakes of the past.

    It's time to leave C in the past.

    1. Re:well, he's not wrong by TheRaven64 · · Score: 2, Interesting

      It's just way way way too easy to write buffer overflows in C

      Technically: it's too easy to write buffer overflows in most implementations of C. The C specification makes accessing beyond the end of a buffer undefined behaviour. That means that an implementation is allowed to do whatever it wants (and doesn't have to do the same thing consistently). Most implementations implement this as 'trample an arbitrary memory location', but it's completely valid to transform it into a recoverable trap. My research group has proposed a small set of CPU extensions that we're talking to vendors about adopting that allows an implementation of C (which I've created and which we're able to build complex C programs with) that provides these guarantees. Any out-of-bounds array access for us is a CPU trap, which the OS turns into a signal. You can then either kill the process, unwind the stack and kill the thread, or recover in some other way.

      --
      I am TheRaven on Soylent News
  7. Fix the code dont try a new language by gordona · · Score: 3, Informative

    How about training developers on security policy, training mgmt on the need for secure code and the balance between acceptible risk and convenience, proper requirement and tests.

    --
    "Gentlemen, you can't fight in here! This is the War Room!" -- Dr. Strangelove
  8. Recent experience with C by CustomSolvers2 · · Score: 2

    I have recently started a quite demanding development by fully relying on C and this experience has being quite eye-opening. One thing is knowing that C is really fast (and dangerous), but a completely different story is getting in there from a modern-language background.

    C can certainly be extremely problematic in bad hands (increasingly careless attitudes in the programming world, anyone?). Also I don't see the point of using it other than under very specific conditions. But completely replacing it? I don't think that this is neither possible nor logical.

    --
    Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
    1. Re:Recent experience with C by gweihir · · Score: 2

      Indeed. Use C for core algorithms, containers with tight space requirements, hardware access, etc. Use something modern for glue code, "business logic", UI, etc. like Python.

      The problem here is not C, it is incompetent C coders. I actually thing using C is an advantage, because it makes incompetent coders far more obvious than, for example, Java, were even the most incompetent ones can hack something together. The second problem is however incompetent "managers" that do not fire incompetent C coders, because competent C coders are quite a bit more expensive. That they are worth it overall several times over is not something the bean-counters can grasp.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  9. The Rust community worries me. by Anonymous Coward · · Score: 4, Insightful

    The Rust community really worries me. It's far too tyrannical for my tastes. For example, they apparently aren't capable of acting like civilized adults on their own. They need a Code of Conduct to tell them how to behave, and a Moderation Team to act as what is effectively a judge/jury/executioner role.

    What's worse is when they use these tyrannical apparatuses to attack others. For all of their bragging about how they value "tolerance" and "inclusivity", they so often exhibit the opposite behaviors. Just look at any Reddit or Hacker News discussion about Rust. Anyone who doesn't post a glowingly positive comment about Rust will quickly become the victim of downvote attacks. It worries me when people offering valid, correct and relevant criticisms of a technology are attacked, censored and silenced.

    I've used a lot of languages over the years, from C to C++ to Java to Perl to PHP to Erlang to Haskell. But none of them have had communities as hypocritical, contradictory and tyrannical as I have found Rust's to be.

    1. Re:The Rust community worries me. by Zontar+The+Mindless · · Score: 3, Insightful

      When I first heard about Rust and went to check it out, the so-called "community" put me off it completely.

      --
      Il n'y a pas de Planet B.
    2. Re:The Rust community worries me. by Anonymous Coward · · Score: 2, Insightful

      It's a language by and for SJWs. The real reason for its existence is to try to push out the older generation of hackers, whose politics they despise.

    3. Re: The Rust community worries me. by Anonymous Coward · · Score: 4, Funny

      emacs vs vim, obiously.

    4. Re:The Rust community worries me. by Zaurus · · Score: 4, Interesting

      I had the exact opposite experience! I have never had such a positive experience with a programming community of any sort as I have with the Rust community. I have never seen an open source project put so much thought and effort into the community side of things. Because of my interaction with the community, I ended up contributing a couple patches and giving two talks about Rust at a conference this last week.

  10. What happens to Rust when Mozilla is gone? by Anonymous Coward · · Score: 5, Interesting

    Rust is very tied to Mozilla. And Mozilla's only remaining "successful" product is Firefox. But Firefox's market share is dropping. It was only a few percent, last I saw, while Chrome is over 50%. Mozilla reportedly gets a lot of funding from Yahoo, due to a Firefox search deal. So here we have an organization with one major product, but this project is being rejected by consumers, and what might be this organization's most significant source of revenue comes from this failing product and is paid for by another company that isn't doing so well. I fear for Mozilla's future if, say, the Yahoo deal wasn't renewed and they couldn't find a replacement.

    If Mozilla goes the way of the dodo bird, then I can't see the Rust project really going anywhere. I don't think it has a robust independent community like Python or C++ has, for example.

    I think it is too risky to adopt Rust, especially for important long term projects. The tech industry moves fast. Rust could plausibly be gone in 3 years, while languages like C, C++, Python and PHP are far more likely to be going strong.

    1. Re:What happens to Rust when Mozilla is gone? by AaronW · · Score: 4, Informative

      I agree. If Firefox or Thunderbird is anything to go by I'd stay far away. I used Thunderbird for years until very recently but its performance is unusably bad. On my quad core xeon workstation it's almost impossible to write email because the editor freezes so frequently, often for seconds at a time. In the process it drops characters so I can't even type ahead. I suspect it's due to its single threaded nature and I'm dealing with several IMAP accounts with a LOT of emails. I recently switched over to KMail which seems to work far more smoothly. On top of that, Thunderbird is a huge memory pig. I gave up on Firefox ages ago and switched to Chrome due to horrible performance with single-threaded Javascript and the fact that it leaked memory like crazy for years. I also blame Mozilla for killing off MNG which is why we so often are STILL stuck with gif, which is a horrible format for most of the animations I see.

      Rust has its place but it isn't going to replace C any time soon. There are other languages that also make the same claims, i.e. Go, Swift, D, etc.

      One thing about C is it is supported on virtually everything except the micros where only assembly or some oddball language is the only thing supported (I used a processor that ran a pattern matching functional programming language at the hardware level once). There are plenty of other languages that are better than C in many cases, but one thing with C is you don't need to worry about libraries having weird interactions with other languages. C bindings are ubiquitous and very well understood and supported. C++ apps can easily link to and call C libraries but the other direction often requires some glue logic. Most languages can link against C code whereas the opposite is often not true. C has very minimal underlying requirements. I have written numerous bootloaders in C which require only around a page (or less) of assembly code. By boot loader, I'm talking about with no BIOS underneath for embedded systems. Cross compiling is well supported as well and I frequently am cross compiling for MIPS or AARCH64 with compilers that are tuned to the specific chips they're targeting.

      I'm playing with an ESP32 device right now which has two Xtensia cores in it. No Rust support but C and C++ are both supported. There's no underlying operating system. Similarly, one doesn't run Rust on Arduino platforms. Rust is tied almost exclusively to LLVM. There is no GCC support for Rust so there are plenty of platforms where Rust just isn't supported.

      C and C++ are supported by many toolchains, both open source and proprietary. Rust is not.

      --
      This post is encrypted twice with ROT-13. Documenting or attempting to crack this encryption is illegal.
    2. Re:What happens to Rust when Mozilla is gone? by phantomfive · · Score: 2

      It's worth watching how Firefox goes as they begin to switch to Rust. If they see performance problems, or if their security bugs all go away (they won't, but you know, some of them might), then those are good data points.

      --
      "First they came for the slanderers and i said nothing."
  11. Many who code in C should not by Alain+Williams · · Score: 4, Insightful

    To be able to code effectively in C you need to have been doing so for at least 3 years and, preferably, spent 6 months or more writing in assembler. I am not saying that without this people cannot write good C, but I believe that this is what is needed to provide you with the level of insight that is necessary to be a competent C programmer. To be a great one, add a few years experience.

    C is not a language for every one, it is not a language for all problems. But for some it is a good language. The trouble is that some people use it when the, perhaps, should be using another language and then when they get problems blame the language and not themselves.

    Anyway: how can you call a language complete if it does not have a GOTO statement ? I'm not saying that I use it a lot, but it is useful for handling errors & similar. I will doubtless now be flamed by those who have heard Dijkstra's complaint about GOTO and not understood it. I remember programs where one in every three statements was a GOTO - yuck, that is what he was complaining about; not about the single GOTO in every 1,000 to 3,000 lines that I seem to write. Yes: I could eliminate those GOTOs but either by making the program less clear (by introducing extra state variables, or similar) or by making it less efficient. His complaint was about excessive use of GOTO, many who have not read the paper, or do not have enough real programming experience, forget that important qualification.

  12. Swift by johnrpenner · · Score: 4, Interesting

    i've recently converted from C++ to Swift — better modern native unicode string handling, and scales really well from beginner semantics all the way to system level stuff. its a great language to work in — and written by chris lattner (who wrote the clang and LLVM compiler/architecture) — so its well fitted for performance optimizations/very fast.

    swift is the first language that i'd say i feel comfortable replacing C++ with.

    2cents from toronto
    john p

  13. Re:Choice the Language by Anne+Thwacks · · Score: 2
    You sir, are a Unix, neckbeard hipster.

    The whole point of this posting is that you should rewrite NetBSD in Rust. Without losing any portability. It is really quick and easy with such a modern and trendy language - you might even finish by next Thursday.

    I expect it to work fine on a 6809.

    Any failure will be punished by a lifetime PHP project.

    --
    Sent from my ASR33 using ASCII
  14. Re:Lack of an Ada bootstrap compiler in C. by sphealey · · Score: 2

    = = = Having said all this, if someone gets the old NYU Ada interpreter (written in C!) = = =

    DB: HAL, I think I've detected a logic error in the main core.

    HAL: I'll get right on that Dave

  15. Use C with the right tools by GuB-42 · · Score: 2

    The strength of Rust is that it has a great static analyzer.
    But C also has great tools : linters, debuggers, test frameworks, ... Use them. No need to rewrite everything.

  16. Re:Yes it is too much to ask. by Anonymous+Brave+Guy · · Score: 3, Interesting

    Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices?

    Because at some point, you can't keep building skyscrapers on shaky foundations. If the underlying programming model in your language doesn't provide some useful guarantee in relation to the correctness of your code, there is only so much you can do. Even modern C and C++ are very far into the not-providing-guarantees area compared to many other languages that have been designed with correctness in mind and the benefit of decades more collective experience in the industry.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.