back to article In Rust We Trust: Microsoft Azure CTO shuns C and C++

Microsoft Azure CTO Mark Russinovich has had it with C and C++, time-tested programming languages commonly used for native applications that require high performance. On Monday, Russinovich urged the technology industry to leave C/C++ behind. "Speaking of languages, it's time to halt starting any new projects in C/C++ and use …

Page:

  1. GNU SedGawk

    Thanks but no thanks.

    I'll stick to C when unavoidable, C++ where needed and scripting languages everywhere else.

    1. bombastic bob Silver badge
      Devil

      Re: Thanks but no thanks.

      I'll stick to C when unavoidable, C++ where needed and scripting languages everywhere else.

      from a practical standpoint, that makes the most sense, especially if you are in IT and need to solve problems as they appear and keep things running the rest of the time.

      re-learning "New Shiny" everytime Micros~1 announces something is a colossal waste of time anyway. I'm thinking Silverlight, and that "Metro" thing. BOTH ARE BIG FLOPS.

      And I stuck with C++ for any windows progs I wrote, which was not many, and they run fine on 7 too.

      Still they ARROGANTLY chose to "Deprecate" C and C++. Who died and made THEM *GOD* ???

  2. Steve Davies 3 Silver badge
    Linux

    If it is good enough for Linus then...

    it should be good enough for Azure.

    But... will that tin of Hammerite paint I have in my garage stop 'rust' from spreading? (only joking)

  3. Ken Moorhouse Silver badge

    ...been developing its own cloud-oriented memory safe programming language called Project Verona.

    I'm sure that somewhere they must have a Wheel Research & Development Lab.

    1. yetanotheraoc Silver badge

      Re: ...been developing its own cloud-oriented memory safe programming language ...

      "Wheel Research & Development Lab"

      v1 a triangle

      v2 a square

      v3 a square with rounded corners - so close!

      v4 dark mode

      1. pavel.petrman Silver badge

        Re: ...been developing its own cloud-oriented memory safe programming language ...

        "We welcome the community to implement their own custom square rounding add-ons. Of course we will supply some, too, so that we can produce shiny demos of a wheel rolling, but we are going to forefully avoid any blame towards the core square team when the add-ons start to fall apart at high speeds."

      2. Ken Moorhouse Silver badge

        Re: v3 a square with rounded corners - so close!

        Beta testers were frustrated that the wheel hub positioning had been moved yet again.

        El Reg commentards in particular were vocal in questioning whether bottom left hand corner of wheel arch was a very eccentric choice.

      3. Fred Daggy Bronze badge

        Re: ...been developing its own cloud-oriented memory safe programming language ...

        v5 telemetary added

        v6 compulsory registration added before wheel could be activated. Also allows chat with other wheel users

        v7 use of wheel downhill now requires optional micropayment

        v8 wheel is no longer available to purchase but as pay-as-you-go

        1. horse of a different color

          Re: ...been developing its own cloud-oriented memory safe programming language ...

          v9 - install ask.com toolbar when changing wheel

        2. Anonymous Coward
          Anonymous Coward

          Re: ...been developing its own cloud-oriented memory safe programming language ...

          v9 Google buy it and end of life it without warning.

      4. Ken Moorhouse Silver badge

        Re: v3 a square with rounded corners - so close!

        Have you seen those fancy Silverlight hub caps?

        1. Pirate Dave Silver badge

          Re: v3 a square with rounded corners - so close!

          And that Zune stereo system is da bomb...

      5. Someone Else Silver badge
        Coffee/keyboard

        Re: ...been developing its own cloud-oriented memory safe programming language ...

        Stop. It. Now. - - - - - ->

    2. LDS Silver badge

      Re: ...been developing its own cloud-oriented memory safe programming language

      They hire those people who keep on re-inventing languages based on Java...

  4. VoiceOfTruth

    Hold your horses!

    -> Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable.

    It only makes rust programs less vulnerable in those areas. It does nothing to stop bad programming in general, and there are plenty of bugs around like that. Does it stop hardcoded credentials being part of a program, AKA a common Cisco bug? Can a rust function be written to return true even if it doesn't actually do anything?

    1. Anonymous Coward
      Anonymous Coward

      Re: Hold your horses!

      Tooling to prevent credentials from being hardcoded does not need to be language-specific. I work at Microsoft and we have such tooling baked into our processes. You have to run these checks before anything hits the field. There are plenty of similar tools available in the community.

      As for useless functions in Rust, I'm not sure, but the compiler is very good at spotting when something is not used.

      Just in case you think this tweet was all talk, what little coding I do at work does sometimes involve some Rust, and I know plenty of colleagues who practically write little else.

      1. VoiceOfTruth

        Re: Hold your horses!

        The point I was making, with some simple examples, is that Rust does not automatically make your programming less vulnerable. It handles certain things better, and that is good. But it is very wrong to make the over-generalised statement as in the article that "Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable", as though that is the *only* or most important feature making software vulnerable.

        I would not want anyone to think "we are programming in Rust so we are secure (or more secure)". That is far too big a jump.

        1. Chris Gray 1

          Re: Hold your horses!

          But, you are doing the same thing, only in the other direction. The statements in the article about "less vulnerable" are correct, as is your statement that Rust does not make programs fully secure. To me, it seems like you are deliberately trying to downplay the advantages of using safe languages like Rust. The benefits are real - such usage *will* make many (most?) programs less vulnerable. Not completely invulnerable of course, but definitely LESS vulnerable.

          There are other types of gotchas in most languages. One that I found a couple days ago in my C code is years old:

          wrong: ... 1 << n ...

          right: ... 1ull << n ...

          (64 bit compilation)

          If I recall correctly integral literals in Rust are u32, so the same problem exists there.

          1. VoiceOfTruth

            Re: Hold your horses!

            You have fallen into the trap. You are a good example of what I wrote about people using Rust saying that automatically makes them more secure.

            Rust has certain features, but it can not stop you writing insecure programs. Let's say you have the most memory-safe Rust program out there, yet your shoddy programming still has an error - let's say you accept an authentication token that you should not or you allow access from an IP range that you shouldn't because you can't calculate a netmask properly. Congratulations. Your memory safe program will not save you, yet you think you are safe just because you are suing Rust. These are trivial examples that I see today in all sorts of programming "examples", and no doubt I will see them in Rust too.

            1. Chris Gray 1

              Re: Hold your horses!

              Did you read what I wrote?

              Or, have I fallen into the trap of feeding a troll? Usenet news is too long ago!

              1. VoiceOfTruth

                Re: Hold your horses!

                Can't win an argument? Call the other person a troll...

              2. bombastic bob Silver badge
                Devil

                Re: Hold your horses!

                a troll will ultimately make pejorative comments, not attempt to make a point.

                maybe some people just come for a good argument? (instead they accidentally walk in on Graham Chapman instead of John Cleese)

            2. Anonymous Coward
              Anonymous Coward

              Re: Hold your horses!

              This is like someone saying "a car with airbags, seatbelts and bumpers is safer in a crash" and you respond with "that doesn't mean it won't crash into a tree if I drive it at a tree?!?!?!" Like, no, obviously not, nobody said it did, what is your point?

              1. Gtdelarosa

                Re: Hold your horses!

                The point is that Rust programmers are claiming that the language WILL save you despite writing bad code.

                That belief is what is driving the enthusiasm for Rust despite being completely untrue.

                1. werdsmith Silver badge

                  Re: Hold your horses!

                  Cite your source please Gtdelerosa?

                  I’ve never heard anyone claim that Rust does save us from bad code.

                2. bombastic bob Silver badge
                  Devil

                  Re: Hold your horses!

                  That belief is what is driving the enthusiasm for Rust despite being completely untrue.

                  I think the one selling feature to NOT adopt Rust is interoperability. That, and a learning curve for your existing experts in C and/or C++ (that last one bothers ME a LOT, wasting weeks or months getting back what I already have with the existing tools and programming lingos).

                  So, do we really need to re-write a large number of existing libraries code bases in Rust so we can use them again? This may or may not be justified (I really do not know) but it IS a concern, at least for me.

        2. Michael Wojcik Silver badge

          Re: Hold your horses!

          But it is very wrong to make the over-generalised statement as in the article that "Rust seems less prone to potential memory corruption bugs and this makes software less vulnerable", as though that is the *only* or most important feature making software vulnerable.

          0/10 for reading comprehension and critical thinking.

          The quoted statement in no way implies your gloss.

          1. nijam Silver badge

            Re: Hold your horses!

            > The quoted statement in no way implies your gloss.

            I think he was complaining about other people's gloss.

    2. StrangerHereMyself Bronze badge

      Re: Hold your horses!

      Of course it doesn't. But considering that memory bugs comprise 70-80% of security vulnerabilities this alone is a huge step forward.

      Also, the stability of the application will be rock-solid if programmed in Rust. No more time wasted with looking for that memory pointer bug somewhere in your 200K LOC codebase. If it compiles it works.

      1. Someone Else Silver badge

        Re: Hold your horses!

        But considering that memory bugs comprise 70-80% of security vulnerabilities this alone is a huge step forward.

        Citation needed.

        Something about lies, damn lies, and statistics...

        1. fg_swe

          Do Yourself

          Pick 30 Random CVE bugs and create the statistic yourself.

    3. DrXym Silver badge

      Re: Hold your horses!

      In answer to your question, no Rust won't help you against application logic issues and never claimed it did.

      However it will stop your code from suffering the mass of bugs that plague C & C++ and are directly caused by the language syntax - null pointers, double frees, buffer overruns, data races etc.

      Most people regard that as a good thing.

      1. bombastic bob Silver badge
        Meh

        Re: Hold your horses!

        null pointers, double frees, buffer overruns, data races etc.

        I rarely see that kind of bug. Usually I see infinite loops and bad logic. Easily found and fixed. Rust would be "about the same" I'd think.

        Those pointer-related issues can also be resolved in C++ by use of abstract objects with reference counts.

        /me once solved 'asynchronous allocated memory lifetime' bugs by using ref counts on each allocated buffer instead of trying to manage things with state variables. The end result is that the code became faster as well, which most definitely sold the idea to everyone. It seemed to me to be the obvious solution.

        1. DrXym Silver badge

          Re: Hold your horses!

          Count up half the CVEs in the Linux kernel and they are *exactly* that sort of thing. Since kernel programmers aren't exactly green around the gills others projects probably have it even worse.

          And yeah C++ has templates to mitigate some issues but it doesn't solve them. I've seen code where a smart pointer has yielded its raw pointer and for another piece of code to wrap the raw pointer in its own smart pointer, causing 2 reference counts. I've seen enormous quantities of badly written multi threaded code where data isn't guarded properly by threads.

          The C++ compiler doesn't give a shit about any of this whereas the Rust compiler would kick your ass. The net result is safer code from developers who spend less time working on stupid race conditions or other rare bugs and more on fixing application logic issues.

        2. jamesgwd

          Re: Hold your horses!

          >> null pointers, double frees, buffer overruns, data races etc.

          > I rarely see that kind of bug.

          That is precisely the problem.

    4. nijam Silver badge

      Re: Hold your horses!

      > Can a rust function be written to return true even if it doesn't actually do anything?

      Returning true definitely counts as "doing something".

    5. fg_swe

      F.U.D.

      They say that "just" 70% of CVE bugs are eliminated by memory safe languages such as Rust, Swift or Sappeur.

      Now you complain about the other 30%.

      "I find airbags boring, they do not stop me from flying out of a curve with excessive speed".

    6. Anonymous Coward
      Anonymous Coward

      Re: Hold your horses!

      When I first started coding in C (in 1976 at UC Berkeley when the manual was a few photocopied sheets), Pascal was used for teaching. The difference was that Pascal assumed the programmer didn't know what they were doing and C assumed they did.

      I think it's a much bigger problem that programmers don't understand the security aspects of the libraries they use. For example, open an HTTPS connection AND THEN call the function that checks the cert is valid.

  5. HildyJ Silver badge
    Boffin

    Replacement versus successor

    As the quotes in the article and elsewhere point out, Rust is currently the language of choice for new projects that would have previously been written in C/C++. But migrating an existing system from C/C++ to Rust is difficult. It is a replacement for C/C++, not a successor.

    In July at Cpp North, Google announced it is working on Carbon as a successor which will be backward compatible with C/C++ and would make it much better for conversions. But when or even if it emerges from the lab is up in the air.

    Addressing some of the comments, rest assured that C and C++ will still be available if you want them. Heck, Fortran and COBOL are still available.

    Also rest assured that bad programmers will still be able to write bad code regardless of the language.

    1. StrangerHereMyself Bronze badge

      Re: Replacement versus successor

      No, it's a successor. It will obviously take a long time before Microsoft has rewritten large parts of Windows in Rust. But I believe they're well on their way.

      I do wonder why they're keeping quiet about it. Maybe Heijlsberg is cooking up some Microsoft derived version of Rust. Who knows.

      1. Tom 38 Silver badge

        Re: Replacement versus successor

        Its not a successor, because Rust doesn't interop with C, you can't write a library in Rust and call it from C..

        Holy fuck, you can! That's pretty cool. This means one could take a common library with potential pitfalls, lets say libpng, implement it in Rust and provide the same API for existing C consumers of that library. That's pretty dope actually.

        Having said that, there are quite a few unsafe declarations in the example I was reading.

        1. DrXym Silver badge

          Re: Replacement versus successor

          Rust has very good interoperability with C and C++ and tools for generating bindings too. If you want to see a mad example of this, check out the Redox OS - they wrote a C-lib in Rust with C bindings so literally you compile and run C against a runtime which is Rust but exposes stuff like strcpy(), malloc() etc

      2. bombastic bob Silver badge
        Trollface

        Re: Replacement versus successor

        Oh no - I just had a nauseating though... Rust-pound (Rust#)

        It make me think they should make an extended version of a programming lingo called "Sand" so we can call the new one "Sand-pound"

        1. Someone Else Silver badge

          Re: Replacement versus successor

          There are those that refer to the '#' symbol as a "pigpen"...

    2. DrXym Silver badge

      Re: Replacement versus successor

      I don't think you'd ever want to port code that works unless you have a very sound reason to do so. That's whether we're talking Rust or some other language. A sound reason might be the old code is broken, hard to maintain, non-performant or new requirements are so substantial that you'd have to rewrite anyway. At which point you may as well consider it at least.

      As for C and C++ I don't believe there is any way you can fix those languages. There is no superset which can be backwards compatible because the issues are baked into the language. Throwing new keywords or semantics at the issue doesn't fix the existing code.

      1. Michael Wojcik Silver badge

        Re: Replacement versus successor

        I don't think you'd ever want to port code that works unless you have a very sound reason to do so.

        Right. We have plenty of data showing that rip-and-replace is expensive and risky. It's extremely easy to introduce new implementation bugs, and often existing applications disagree with whatever specifications might be available (and usually there isn't much) in ways that business processes depend on.

        Also, Rust isn't available on many "legacy" platforms that are still in use.

        I like Rust for new projects where fast native code is called for, provided it's fully supported on the target platforms. And it can be integrated with existing projects where you're developing a new component with a clean interface to the existing code, provided you can budget the time to create (well-designed) bindings. But few people seriously consider rewriting large projects.

        1. bazza Silver badge

          Re: Replacement versus successor

          Agreed, but with the Linux kernel things may be different.

          One of the kernel's unsolved problems is its license. Gpl2 was OK in its day, but it's problematic now. A Linux rewrite in Rust would also be a relicensing opportunity.

          I've no idea what license would be best - that'd be one for the kernel community - but if they wanted to relicense it that apparently does mean at least a partial rewrite, either to overcome problems of contributors having since passed away, or those who don't agree to relicense their contributions. If there were the motivation to do it, doing it in Rust where rewrites are needed could be a good idea. The language change certainly makes it clear that it's a rewrite, as it places a clearer marker between new and derivative code.

      2. Blazde

        Re: Replacement versus successor

        You can always auto-translate C/C++ code to Rust. The issue is you're left with lots of unsafe code or you have to tidy up your memory ownership to satisfy Rust's strictness (which could involve big architectural changes to pull off cleanly), however the fact your code doesn't already satisfy Rust's ownership model IS a valid reason to call it broken if you care a lot about security, and will make it easier to maintain if you reduce the firehose of CVEs.

        As for Rust being difficult to learn, it isn't really. It's more accurate to say it's difficult to learn how to code in a memory safe way and Rust happens to force (or at least strongly convince) you to learn that fairly invaluable skill. I'd even say it's much easier to learn the skill with Rust as a crutch rather than spending years of your life debugging mysterious memory corruption bugs as punishment for not being born with the skill.

  6. Bitsminer Bronze badge

    bad programmers will still be able to write bad code bad Fortran regardless of the language

    FTFY.

    1. wolfetone Silver badge

      This is it.

      We could have a language based on the nature tongue of the programmer, where programmers explicitly describe what they want the software to do, and garbage will still be created.

      I think a lot of the time (I'm guilty of it, I know others are) people dive in to languages like they're the be all and end all, without ever first considering the structure and shape of the software. Which then means you go and create something, test it, then discover issues. At this point then you're shoehorning fixes in to what you've made to make it work, and for it to pass "tests", and you end up with a mangled mess of software full of sticking plasters and workarounds. Just because you didn't bother to plan what you wrote, you didn't plan better methods of fixing issues you've caused.

      Languages aren't the problem. The problem are the programmers.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022