Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Intel

Intel Engineer Launches Working Group To Bring Rust 'Full Parity With C' (packtpub.com) 111

Posted by EditorDavid from the Rust-never-sleeps dept.
Someone from the Rust language governance team gave an interesting talk at this year's Open Source Technology Summit. Josh Triplett (who is also a principal engineer at Intel), discussed "what Intel is contributing to bring Rust to full parity with C," in a talk titled Intel and Rust: the Future of Systems Programming.

An anonymous reader quotes Packt: Triplett believes that C is now becoming what Assembly was years ago. "C is the new Assembly," he concludes. Developers are looking for a high-level language that not only addresses the problems in C that can't be fixed but also leverage other exciting features that these languages provide. Such a language that aims to be compelling enough to make developers move from C should be memory safe, provide automatic memory management, security, and much more...

"Achieving parity with C is exactly what got me involved in Rust," says Triplett. Triplett's first contribution to the Rust programming language was in the form of the 1444 RFC, which was started in 2015 and got accepted in 2016. This RFC proposed to bring native support for C-compatible unions in Rust that would be defined via a new "contextual keyword" union...

He is starting a working group that will focus on achieving full parity with C. Under this group, he aims to collaborate with both the Rust community and other Intel developers to develop the specifications for the remaining features that need to be implemented in Rust for system programming. This group will also focus on bringing support for systems programming using the stable releases of Rust, not just experimental nightly releases of the compiler.
Last week Triplett posted that the FFI/C Parity working group "is in the process of being launched, and hasn't quite kicked off yet" -- but he promised to share updates when it does.
This discussion has been archived. No new comments can be posted.

Intel Engineer Launches Working Group To Bring Rust 'Full Parity With C' More

Intel Engineer Launches Working Group To Bring Rust 'Full Parity With C'

Comments Filter:

  • Regulatory testing. (Score:5, Funny)

    by 0100010001010011 ( 652467 ) on Saturday August 31, 2019 @03:43PM (#59144622)

    It's going to need an ISO26262/IEC61508/DO178C certification before it ever gets a second look in some industries.

    And an OS.

    And maybe then GreenHills can finally die with their compiler straight out of 1990.

    • Re:Regulatory testing. (Score:5, Interesting)

      by nagora ( 177841 ) on Saturday August 31, 2019 @04:03PM (#59144650)

      It's going to need an ISO26262/IEC61508/DO178C certification before it ever gets a second look in some industries.

      Sad but true. ISO and its "pay for certification" model is the next thing on the hit-list after Elsevier IMO. 99% of their "standards" are worthless pieces of crap invented by a bureaucracy in order to make work for bureaucrats or simply made up by "industry leaders" to lock in their positions.

    • If C programmers haven't even moved to C++ yet then they're not going to move anywhere. Period.

      They're simply not interested in things like memory safety, getting the compiler to do the error-prone drudge work for them, or any other modern practices.

      C is the ultimate self-taught-hacker language. It lets you close enough to the underlying metal to imagine you're a real programmer without any of that pesky studying or other-people's-hindsight nonsense.

  • I personally think that Swift will probably be the better candidate for a next-gen systems language. It's moving more rapidly into different domains.

    By the time Rust has studied this Swift will be there.

    • Swift is a huge sack of shit. We really need protocols for every stupid feature etc. Swift == C++ without any of the performance

    • Re: (Score:3)

      by roca ( 43122 )

      You don't want to use reference counting for everything in a systems language.

    • Swift is moving more rapidly into different domains.

      What domains is it moving into besides Applesphere? The only people who like Swift are Apple fanboys.

    • Or Dart with Flutter, Dart is meanwhile on 3 desktop OSs and iOS as well as Android.

  • If successful, C will become the new Cobol (Score:5, Interesting)

    by mykepredko ( 40154 ) on Saturday August 31, 2019 @04:11PM (#59144658) Homepage

    Anytime somebody has the idea of putting C into the dustbin of history, they always seem to forget about the literally billions of lines of code that are out there doing real work that are not going to be rewritten but must be maintained.

    I can't see Intel (of all companies) porting UEFI for their processors to Rust as that would entail hundreds of thousands (millions) of hours porting the C source and verifying that it works properly. What about Linux? Do you think Linus will allow all the parts written in C to be ported to Rust without a validation/verification plan? Who will pay for that work to be done? The most logical course of action will be to maintain the code in C and any new projects are rewritten in Rust.

    Regardless, if Rust does manage to supplant C in systems programming, I look forward to making a mint in my declining years maintaining C code bases.

    • Given the way things go, part in programmer skills and computing power, anything that has to be written in C will be, and everything else will be written ina much higher level language. Trying to replace C is like trying to empty the ocean with a bucket.

      What C really needs to make it absolute perfect is a) RAII (ie scoping for local structs with automatic destructor functions like C++ has), and b) a string library that doesn't suck 1970s balls. (A set of collection libs like STL's map, list,vector etc would

      • So what C really needs to be absolutely perfect is to become C++? Well then just use C++. And I say this as a C++ developer. It makes no sense to me when people are using C, and keep re-implementing the functionality of C++ (poorly) without just moving to C++ directly.

        • Re:If successful, C will become the new Cobol (Score:5, Funny)

          by phantomfive ( 622387 ) on Saturday August 31, 2019 @07:02PM (#59144932) Journal
          You can use C++ instead of C, but then the drawback is you have to use C++.

          • You don't have to use all of C++ (yet).

            You can start by using std::string instead of malloc() and strcpy() and take it from there.

            You could also use std::vector, std::list and std::map instead of rolling your own versions of them every time for every data type in your program. That would help, too.

            etc., etc.

            Everything in C++ is there for a reason and after much discussion.

            (apart from new[] and delete[] which were added because std::vector wasn't implemented yet, they should probably be deprecated now...)

            • Everything in C++ is there for a reason and after much discussion.

              No kidding, it looks like a language made by a committee of monkeys. cin/cout are garbage.

        • I didn't say it needs to be C++, just the best bit of C++ could be taken and put in.

          If you're doing C++ nearly all of it is irrelevant to making good products, but the things that really help you: RAII and the STL containers, you always use those. So a "better C" would take those bitys that are the most helpful and ignore the stuff that adds complexity for no practical benefit.

      • Re: (Score:2)

        by Uecker ( 1842596 )

        What do you think about there the __cleanup attribute of GCC?

        I agree about library part. We are currently working on C2X. Suggestions welcome.

        • Suggestion: Don't waste any more time reinventing C++.

        • My suggestion is simple really:

          find the bits that truly help programmers be productive, put those in. Don't put the arcane bits that add complexity without a corresponding increase in productivity.

          a string lib should be trivial to add to C (ok, though possibly difficult to make compatible with all the old code) but one that has string length up front, should make performance increase, buffer overruns decrease and usage pretty much stay the same.

          The rest of libraries, the SGTL containers are awesome and were

      • a string library that doesn't suck 1970s balls.

        This is very true, I second it.

        • Re: (Score:2)

          by Uecker ( 1842596 )

          This is something I plan to propose for inclusion in C2X.
          I would be interested to hear about string libraries with good interfaces.

          • The biggest difficulty with parsing things manually is remembering to free stuff after it's allocated (because when you are parsing, you are dealing with lots of little bits of things). Java solves the problem by having garbage collection. I've done something similar in C by using memory pools, so I can allocate as many strings as I want in the pool, then delete them all at once. Once you have that, split() is probably the most useful function for parsing, and then some kind of string-builder on the other s

            • Re: (Score:2)

              by Uecker ( 1842596 )

              Something like this? With additional functions that operate on it?

              struct string {
                  int n;
                  char buf[n];
              };

              • Something like this? With additional functions that operate on it?

                struct string {

                int n;

                char buf[n];
                };

                What would be really awesome is if the functions could somehow be associated with the struct so that a) They don't contaminate the global namespace so much and b) Don't end up with super-verbose names to avoid name clashes with the billions of lines of existing C code.

                C++ has an excellent way of doing this by putting the functions inside the struct itself and calling them via the struct variable by using '.'. You might want to follow C++'s example.

                • Re: (Score:2)

                  by Uecker ( 1842596 )

                  Except that C has a really cool feature which does not work anymore, if you do it the C++ way.
                  You can forward declare an incomplete struct in a header and use pointers to it in an API.

                  struct string;
                  void string_append(struct string* a, const struct string b);

                  This completely hides the implementation which has many advantages of API stability an
                  fast separate compilation This breaks when you use the C++ way which I would not use i
                  even it were supported by C.

                • Re: (Score:2)

                  by Euler ( 31942 )

                  Possible solutions that currently exist:
                  put function pointers in your struct?
                  make functions static to a module (.c/.o file) so your code stays modular and re-usable?
                  give public functions some arbitrary prefix that is unlikely to collide?
                  if it helps, structs can contain anonymous members in more recent C standards.

              • Re: (Score:2)

                by Euler ( 31942 )

                Anybody is free to do this at any time. In fact, you should be able to find many such free implementations available already.
                There is no obligation in C to use the default libraries. C itself only manages how basic operators and data types behave, function calls are just whatever the library provides, supply your own. There is very little 'magic' built-ins like the higher-level languages depend on. (C init routines are somewhat magic, but can usually be substituted if you need to.)

                Memory allocation schem

              • That would be good for a memory-buffer object (instead of a string). Then instead of memcpy() you could have safe_memcpy() that checks the bounds before copying.

                As for strings, null-terminated strings are ok, but treating strings as a buffer of bytes doesn't work anymore. With unicode, a single character isn't a sensible abstraction (for example, to_upper() can result in two characters, as is the case with the German ß). Because of this, the easiest way to deal with text is to treat everything as str

    • Re: (Score:3)

      by roca ( 43122 )

      Just about every Rust proponent would agree with you.

      If new projects stop being written in C and some essential core C components are replaced with rewrites in Rust then that's a huge and valuable change. Magically replacing all C code is obviously not going to happen.

    • Yep. Much of it in the form of a very large number of old but thoroughly debugged libraries for almost everything under the sun. I have my set of complaints about Python, but one of the things Guido did right was make it easy to call such libraries.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Well, the TIOBE index puts C at 2nd place with 15% (and C++ at place 4 with another 6%). Rust is place 28 with 0.45%.

      You probably need a different plan to finance your retirement. Rust is a niche language pushed by loudmouths.

    • Strawman argument.

      If new code is in Rust, why would anyone feel the urge to rewrite old code?

  • C as assembly - yawn (Score:5, Insightful)

    by kschendel ( 644489 ) on Saturday August 31, 2019 @04:32PM (#59144690) Homepage

    This rather peculiar notion that C is a sort of easy-to-read assembly language has been around since its inception, and in fact was a lot closer to reality 40 years ago when compilers were dumb, register declarations were important, and one might have fussed over the proper use of pre-decrement vs post-increment (if you were writing for a PDP-11 or VAX).

    Today, I wouldn't characterize C as a fancy assembly. It's a basic, (mostly) easy to read and write, language that gets the job done without a lot of mommy semantics. It's certainly not for every project, but it's not going away in my lifetime.

    • Re:C as assembly - yawn (Score:5, Interesting)

      by roca ( 43122 ) on Saturday August 31, 2019 @05:00PM (#59144746) Homepage

      Experience shows that if your goal is to write secure code, C does not get the job done. People inevitably make mistakes and when you make mistakes in C, you create exploitable vulnerabilities.

      • Experience shows that if your goal is to write secure code, C does not get the job done.

        All you need is a decent string library and a decent memory-block library, and 99% of the problems go away. Your code will be as secure as Java or Python code (not saying that's secure by any stretch). People don't do it because either they don't know, they are too lazy, or too overconfident.

        The technique is there. If you care, use it.

        • All you need is a decent string library and a decent memory-block library, and 99% of the problems go away.

          You can have that today by simply using std::string and std::vector in your C code. It really is that simple/painless.

          If people aren't using those then maybe you're seeing the real problem with C, i.e. it's the home-hacker mentality of the C programmers, not the language itself.

          • std::string is garbage, and so is cout/cin

          • Re: (Score:2)

            by Euler ( 31942 )

            You can have that today by simply using std::string and std::vector in your C code. It really is that simple/painless.

            Then it would be C++, but I would happily use a C-library that better manages strings.

            If people aren't using those then maybe you're seeing the real problem with C, i.e. it's the home-hacker mentality of the C programmers, not the language itself.

            Perhaps that is a sub-set of C programmers that are more visible. There is an awful lot of C code out there working just fine and the programmers are following a more rigid set of practices. MISRA, DO-178, etc.

      • Re: (Score:2)

        by gweihir ( 88907 )

        Seriously? And when you make mistakes in any other language, and particularly in RUST, everything else magically stays secure?

        In the real world, that is not the case. In the real world, most C mistakes are not exploitable either.

      • Experience shows that if your goal is to write secure code, C does not get the job done.

        Experience shows that no matter how foolproof you make a language, fools will find a way to subvert it.

        It is more possible to write secure code in C than in any other higher level language because you have complete control over everything, so nothing "unexpected" can happen... if you designed your code properly.

        Sure, there are languages, such as Rust, that make it "easier" to avoid certain types of issues, but the trade-off is not understanding what is actually happening in order to keep you safe. It is eas

    • Re: (Score:2)

      by HiThere ( 15173 )

      C has 3 basic problems:
      1) it allows pointer arithmetic.
      2) it allows reads/writes beyond the array bounds
      and
      3) it doesn't address multi-CPU programming.

      A couple of, lesser, problems:
      4) the way it handles (doesn't handle) unicode.
      5) the dependence on a preprocessor for constants.

      There are reasons for all of these problems that were valid when the language was designed, but which are no longer reasonably valid. But none of the replacements proposed only address the problems with C.

      N.B.: Don't take this too s

      • Re: (Score:2)

        by guruevi ( 827432 )

        Pointer arithmetic is really useful when you do anything related to hardware, large arrays etc. Otherwise you're just copying or indexing/searching (like Rust) which is slow.
        Reads/writes beyond array bounds is simply illegal in C/C++ and leads to unexpected behavior. Compilers check for it but once again, the alternative is to use MORE memory and processor cycles to keep track of indexes, again, it may not seem like much but if I have to do a jmp or cmp in every loop, especially these days in GPU's where so

        • Why is pointer arithmetic any better than using array indices?

          (...which can be bounds checked)

        • The result is that everywhere in the kernel you are passing around pointers to arrays and a length.
          How is that any better than having support for checking length built into the language?
          It can do the bounds checks at compile time and remove them at runtime making it more efficient in some cases.

      • Re: (Score:2)

        by lsllll ( 830002 )

        C has 3 basic problems: 1) it allows pointer arithmetic. 2) it allows reads/writes beyond the array bounds and 3) it doesn't address multi-CPU programming.

        Nonsense. That's like saying a knife's problem is that you can accidentally cut your finger with it. Yeah, they got those plastic knifes that can cut most things and won't cut your finger, but they're not good when you need a real knife.

        • Re: (Score:2)

          by gweihir ( 88907 )

          And that is pretty much the thing. C is not a tool for amateurs. Amateurs love blaming the tools and not their own lack of skill. And amateur coders, in particular, are always looking for that magic language that will make their code not suck. Of course, that language does not and can not exist.

      • Re: (Score:2)

        by Uecker ( 1842596 )

        1) I am not sure how this is a problem
        2) I doesn't allow this. The problem is that compilers do not detect this. So the tools are not good enough.
        3) C has threads and atomics.

        • 1) I agree completely with you here
          2) I'm not aware of a compiler that detects this situation as indexes into arrays and the like tend to be dynamic at runtime.
          3) and they aren't really that difficult to use.

          Back to array over reads - there is nothing magical in any other language that detects this situation at runtime. The data structure, i.e. the array, is not just a block of memory, it has associated length attribute. All access to the array then checks this length attribute and generates an error at r

          • Re: (Score:2)

            by Uecker ( 1842596 )

            Yes, you can safely wrap the array access in another data structure.

            But you can also detect out-of-bounds at run-time (e.g. using -fsanitize-undefined)

        • > So the tools are not good enough.
          And rust is an improvement on the tool.

          • Re: (Score:2)

            by Uecker ( 1842596 )

            Sure. but at the same time it is also a completely new language while it might be possible to get most of the advantages by using better tools with C.

      • C has 3 basic problems:
        1) it allows pointer arithmetic.
        2) it allows reads/writes beyond the array bounds
        and
        3) it doesn't address multi-CPU programming.

        C++ address all of those without losing any of the "power" or "speed" of C.

        So...what's the excuse? I think you'll find it's in the "We don't need no steenking array bounds checking" mentality of C programmers.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Well, smart people have been saying instead that C is a suitable replacement for assembler in many cases. That is different. The clueless cloud (for example, people that do not understand computer memory and its use) does indeed call C a kind of assembly language.

  • Full Parity with C (Score:4, Interesting)

    by hackus ( 159037 ) on Saturday August 31, 2019 @04:41PM (#59144710) Homepage

    I think the guy has a "parity" bit error personally because there is nothing wrong with C, its the people who write the code.

    Expecting RUST to fix people issues, or any technology for that matter to magically make people do what you want is delusional.

    Good Luck with that.

    • Re: (Score:2)

      by gweihir ( 88907 )

      This. Very much this.

      Brooks wrote "No Silver Bullet" more then 30 years ago and people are still looking for that silver bullet in the form of the One True Language that will finally make their code not suck. Here is news for you, Rust disciples: If your code sucks, then the problem is you and no language ever will fix that.

      • There is a powerful logical fallacy at play here. You're basically saying no language will magically make bad code not suck therefore we should never use a new language.

        Assembly won't make bad machine code not suck.
        C won't make bad assembly not suck
        C++ won't make bad C not suck.

        So why aren't we still writing in machine code?

        Catching bugs at compile time is way better than debugging them at runtime. Code you don't write has no bugs, so a language which allows you to automate away tasks will reduce the amount

      • This. Very much this.

        Brooks wrote "No Silver Bullet" more then 30 years ago and people are still looking for that silver bullet in the form of the One True Language that will finally make their code not suck.

        Languages can certainly help.

        (otherwise we'd all still be coding in hexadecimal).

    • I think the guy has a "parity" bit error personally because there is nothing wrong with C, its the people who write the code.

      I agree it's the people writing the code that's the underlying problem but there's also plenty wrong with C in the sense that you can't get the compiler to generate any of the boilerplate code that's the bread and butter of programming. C code takes much longer to write because of all the wheel-reinventing and is far less reliable as a result.

      You also have every function in a single namespace where name clashes can become a serious problem in large projects.

      etc., etc...

  • Rust Failed To Make Its Case - Industry Moved On (Score:4, Insightful)

    by L_R_Shaw ( 5544684 ) on Saturday August 31, 2019 @04:42PM (#59144712)

    People always talk about the toxic Rust community, but the real problem with Rust is it utterly failed to make its use case.

    Instead the tiny Rust advocates put out inane claims about C/C++ being rewritten in Rust and it inevitably turned out the C/C++ was maliciously written in some way that would never happen in the real world or other silly fanboy type shenanigans.

    That crap just isn't going to work with people who live and breath code.

    Rust failed, just like D, because it was measured against other options and found wanting.

    I don't know if this is just one of the dwindling number of Rust advocates hyping something minor, a tax write off for Intel, or and early April Fools joke.

    People have real work do get done and have moved on.

  • C is the new Assembly? srsly? (Score:3)

    by darthsilun ( 3993753 ) on Saturday August 31, 2019 @04:49PM (#59144718)

    believes that C is now becoming what Assembly was years ago. "C is the new Assembly,"

    People have been calling C a glorified Macro Assembler for as long as I've been coding in C. Probably longer even.

    Which was circa 1985 using Lattice C on MS-DOS 2.0.

    • A decent macro pre-processor makes C easier to use, but good luck enforcing standards if you are working with a team.

    • Re: (Score:2)

      by gweihir ( 88907 )

      And since back then, these are mostly people that have never coded in assembler. C is a pretty good _replacement_ for assembler in many situations, but it is not assembler in any meaningful way itself.

    • Re: (Score:2)

      by Euler ( 31942 )

      I do write a lot of assembly code, and I still hear things like that. Maybe there was some type of assembler tools out there that were precursors to compilers, but I have not seen them in my time. Assembly vs. C are just completely different levels of abstraction.

      I don't think C is a replacement for assembly. I get a lot of pressure to move code to C from asm, and the fact is there are some specific classes of problems that cannot efficiently be done this way in the code I work on. Granted, I'm talking

  • Ada (Score:4, Interesting)

    by Elledan ( 582730 ) on Saturday August 31, 2019 @04:57PM (#59144738) Homepage
    So what's wrong with just using Ada instead of badly reinventing that language?
  • What issues can't be fixed? I am sure if you really need to fix something that C can't do you can always use inline ASM, if it can't be done in ASM it can't be done period! C is not the new assembly, assembly is assembly! C doesn't use mnemonics it uses key words that are translated to machine code! C doesn't work at the processor level, assembly does! The two aren't interchangeable!

    • Re: (Score:2)

      by gweihir ( 88907 )

      The "problem" these people try to "fix" is that C is not Rust and that C exposes their incompetence, while Rust would make it harder to see (but probably even more devastating in the end).

  • You can't have your cake and eat it too. Part of what makes C so powerful is the manual unsafe access to memory. Once you take that away, you ruin the exact thing that makes C so powerful and good.

    • Re: (Score:2)

      by jythie ( 914043 )
      This is the problem with trying to reach 'parity' with C. If something can do all the same things as C, then it has the same problems, meaning all you have done is ended up in the same place you were with more steps.

      • Re: (Score:2)

        by gweihir ( 88907 )

        Indeed. There is also absolutely not need to replace C. C is entirely fine. Some of the people coding in C have no business doing that, but that is a completely different problem and Rust will not and cannot fix that.

        • There is also absolutely not need to replace C.
          Says one who sounds as if C is the only language he can code in ... C is simply inadequate for many many things. If I need to code in C for you and can not even use C++ you have to pay me damages for pain and suffering, aka twice the normal wage :P

        • The 21st century version of Luddites.
          People who can't move on beyond 1980 and think nothing is ever better than what they had back in the day.
          We've had 40 years of experience programming and research into programming languages since then.
          The reality is that those people are coding in C right now, and nothing you do or say will change that, so we might as well give them a better tool.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Coding in Rust apparently reduces the level intelligence and understanding of any person doing it immediately and drastically. Because what you say is both obvious and the Rust fanatics cannot see it.

    • I see you have never bothered learning anything about Rust. Rust allows manual unsafe access to memory, but clearly partitions where it occurs via unsafe blocks. You can write the parts that do pointer offsetting or whatever in unsafe functions, write safe functions that use them in unsafe blocks and ensure their safety, and then reuse them everywhere in safe code with zero worries about memory safety. It's not a new concept - something as high level as C# can do this too. The thing that's broken about C is

  • Dishonest statements, lying, misdirection, deriding of well-established working alternatives, etc. i.e. the usual propaganda from the Rust fanatics.

    No, C is _not_ and never will be "assembler". Anybody stating that is either lying or has never worked with any assembler variant.

  • Oh the gods save us all... (Score:3)

    by l3v1 ( 787564 ) on Sunday September 01, 2019 @05:08AM (#59145776)
    "provide automatic memory management, security, and much more"

    So the preachers of doom have found us again, it must be that time of the year, Halloween is near, whatever. And yet again, here come the people who think they really can "solve" bad coders with another language. You can manage issues to a level, but there's just no way. There's one recipe for good coders: be a damn good coder. My own position is, if you go the way of the automatic memory management route full throttle, you'll end up with an army of useless coders - i.e., people who claim they can code, then produce a million lines of junk you'll have a very hard time finding real coders to clean up. This wouldn't be the first time for such a wave to reach us, and it surely won't be the last.

    Somehow, good c/c++ coders could survive it all, and will survive it all. Yes, it's magic, the magic of knowledge and experience. And a reduced amount of arrogant knowitallbetterism.

    You'll claim you produce automatic mem management and security - and "much more" nonetheless -, don't get surprised to end up with people who care less about the one than they know about the other.

    Better coder education - theory, and practice, and theory, yes, that, with practice :) - would be a much better way to go, since we can all witness - some more first hand than others - the general knowledge and versatility decline in coders abilities during the last 10-20 years.

    You can't make that disappear by giving them a new language. You can temporarily alleviate issues, somewhat, until you again reach a point where even Rust is not enough to help you, and then what? Come up with another, again? Right.

    Preach all you want, but also pray I won't be deciding to hire you or not.

    • Re:Oh the gods save us all... (Score:4, Insightful)

      by anarcobra ( 1551067 ) on Sunday September 01, 2019 @08:50AM (#59146140)
      People keep bringing up this ridiculous argument of "just be a better coder".
      That is not something we have control over. Most people are retarded and nothing we can do will change that.
      The 100s of CVEs every single year in the linux kernel alone are proof of that.
      Most of them stupid mistakes like missing null or length checks, things that could be prevented with better compilers.
      What we can change is the tools they use and try to mitigate the mistakes they make.

      • Re: (Score:2)

        by Euler ( 31942 )

        Some people just assume they are perfect and every else is terrible. First step is to admit that most of us will make stupid mistakes.

        Perhaps "being a good coder" is simply being humble enough and not too lazy to make use of testing tools. I haven't quite seen a language that makes mistakes impossible.

        • No one is asking for a language that makes mistakes impossible. Just one that makes a certain class of mistakes far less likely than in C.
          Built in bounds checking prevents pretty much the most common mistakes found in the kernel.
          In C everyone ends up writing the same boiler plate for checking array lengths over and over again, so eventually mistakes are made.
          I don't know about everyone else, but writing boilerplate is not my idea of a fun time.\
          I'm not suggesting everyone should switch to Rust, I'm not sugg
      • Rust isn't intended to be general purpose. Python, Java, Go, and plenty of other languages function perfectly well as general purpose languages and are wildly popular as a result. That's not what Rust is designed to be. Rust is C with type safety and a handful of other changes. This is by design so as not to remove control from the programmer over things like e.g. memory management. Like you said, lots of people suck at doing manual memory management, but there are people who are good at it and there are us

Slashdot Top Deals

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Close