Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming

Microsoft: Here's Why We Love Programming Language Rust and Kicked off Project Verona (zdnet.com) 171

Posted by msmash from the how-about-that dept.
Microsoft has explained why it's pursuing 'safe systems programming' through efforts like its experimental Rust-inspired Project Verona language and its exploration of the Rust programming language for Windows code written in C++. From a report: The short answer is that Microsoft is trying to eliminate memory-related bugs in software written in languages like C++, according to Microsoft Rust expert Ryan Levick. These bugs cost a lot to fix and make up a large share of Patch Tuesday hassles. Levick has now offered more insights into Microsoft's efforts behind safe systems programming. Systems programming includes coding for platforms like Windows, Xbox, and Azure, as opposed to programming applications that run on them.

Key systems programming languages include C++, Google-backed Go, and Mozilla-created Rust, but Rust and Go are 'memory-safe' languages while C++ is not. Other languages are memory safe, such as Swift and Kotlin, but they aren't for systems programming. The thing for Microsoft is that it writes a lot of its platform software in C++ and sometimes still in C. While it works hard to address memory issues, the company says it has "reached a wall". "We can't really do much more than we already have. It's becoming harder and harder and more and more costly to address these issues over time," says Levick, who joined Microsoft via its acquisition of Wanderlist, which has become Microsoft To Do. He gave a rundown of Microsoft's safe systems programming efforts in a session at Build 2020 this week.
This discussion has been archived. No new comments can be posted.

Microsoft: Here's Why We Love Programming Language Rust and Kicked off Project Verona More

Microsoft: Here's Why We Love Programming Language Rust and Kicked off Project Verona

Comments Filter:
  • I was hesitant at first to try it but I have to admit that Dart is winning me over. It's very fast, memory safe, support AOT and JIT methodologies, works great on mobile, web and servers and it's very simple to use and learn. If there ever was a universal language for everything this is as close as it gets to it.

    • Re: How about Dart? (Score:4, Insightful)

      by Way Smarter Than You ( 6157664 ) on Friday May 22, 2020 @05:27PM (#60092702)
      There's never going to be a truly universal programming language without the concept of what programming is changing dramatically.

      Small example: sometimes you need pure speed and don't care about anything else. True real time matters for your project. You've just eliminated pretty much all the FotW stuff. Or... you need absolutely safety, your program can never crash or leak memory, must be absolutely secure. A whole of bunch of others eliminated. The language intersection of these different requirements is null, at the moment. (Please post if you know of something). And these are just two heavy handed examples. We could get into compression, math, streaming, gaming, and so on. Each field has multiple sub classes of requirements depending on,the project specifics.

      • The language intersection of these different requirements is null, at the moment. (Please post if you know of something).

        HAL/S, perhaps? In the domain it was designed for, of course.

        • Interesting. I was thinking of things like ADA but didn't want to distract from my point. The 3 line input in HAL/S is pretty wild. Kudos to those guys for that one.

          I've only read for 5 minutes on it but could you use it to write a complex desktop operating system? A high FPS video game? A web server? The AI for Tesla FSD? If not then we're still not at a universal language and I still think never will be. Maybe someday hardware will be so fucking fast that real time comes free so that requirement c

      • All that has nothing to do with languages, but if at all with libraries.

        I hope I never meet you in a job .... you have no clue.

      • Re: (Score:2)

        by Megol ( 3135005 )

        Real time systems aren't about raw performance, it's about guaranteed response time.
        Safety and real time aren't incompatible. And while you didn't mention it garbage collection/automatic memory management isn't necessarily incompatible with real time either.
        ADA could be an intersection of the two even if it isn't in any way a perfect language.

    • Dart is not for systems programming.

      • Neither is "Go". Mentioning it in the same breath as C/C++ and Rust is completely misunderstanding what it is that C/C++ and Rust bring to the table: NO GC in particular.

      • Dart is compiled to machine code, so you can do everything you want with it. That includes system programming.

  • There have been in the past few months many Slashdot stories about Microsoft doing something good.

    The ONE BIG ISSUE: When will we have a usable Microsoft operating system?

    Yesterday's stories about Windows 10:

    Windows 10 Warning: Users Hit By Serious New Failure [forbes.com]

    Windows 10 update is wrecking laptops — now Microsoft is investigating [laptopmag.com]

    Years of problems:

    August 4, 2015: Windows 10 is possibly the worst spyware ever made. [networkworld.com] "Buried in the service agreement is permission to poke through every
    • Think of it this way: we know slashdot is just an ads platform for moneyed PR departments which also supports a small message board system on the side. So long as we all understand and continue to call this stuff out I'm ok with the ads. It gives more opportunity to vent at all the shitty vendors. (And yes, PR person reading this, your company is no better, you are just as shitty).

    • Re: (Score:2)

      by MagicMike ( 7992 )

      Okay, whippersnapper.

      That was also the time Microsoft was sincerely evil. Went from the point where upgrading my install meant fresh floppy images from the slackware FTP site, up until about where Google decided to just fully ignore their phrase "Don't Be Evil" (that is, about 3 years ago?)

      Now, for some strange reason they seem to have genuinely turned the page on that $%^& and are...doing some good things.

      So maybe it's not ads? Maybe it's that in this strange alternate future I didn't expect myself to

      • Re: (Score:2, Insightful)

        by iggymanz ( 596061 )

        Bullshit, not leading edge at all. Even Azure offererings have all kinds of linux infrastructure because Microsoft not smart enough to lead. Now they're trying to suck up to the people that make and use real operating systems and the stuff that makes the internet work, because they realize they've failed in yet another space. They failed in mobile, failed in server space, failed in supercomputing and the desktop is being eroded away. Fuck Microsoft, the enemy of open source and choice.

        • Re: (Score:2)

          by MagicMike ( 7992 )

          Nah, you haven't been paying attention to where the leading edge went I think. They're doing some interesting things in mobile now that they've given up being the platform. They've pivoted to become toolsmiths (which they were actually not bad at by popularity though I personally hated them), and they're making all the tools open source. I find it hard to get worked up about that?

        • Even Azure offererings have all kinds of linux infrastructure because Microsoft not smart enough to lead.

          Actually Azure have all kinds of Linux infrastructure because Linux is what a lot of clients demand and running Linux clients on Linux virtual infrastructure is something where someone else has done all the work for you already.

          Microsoft is smart enough not to spend stupid money to replicate a function that someone else already gifted to them.

          Now they're trying to suck up to the people that make and use real operating systems and the stuff that makes the internet work, because they realize they've failed in yet another space.

          I'm curious where you think they failed? The vast majority of internet traffic hits Windows machines. Azure instances of Windows are rising vs Linux. But let's address

          • You are in denial about reality. Apple is eroding Windows desktop/laptop share, they have 13% now. Wake up and smell the coffee.

            And Windows making the internet work? Do you even know how things work? You think Microsoft email and web servers, load balancers, routers and firewalls drive the internet? News for you pal, they don't.

            You're just wrong and more wrong, must be MS stock holder to be such an ignorant uniformed shill.

            And no, Microsoft doesn't many advertise parts of Azure infrastructure that are

      • I don't think the reasons are hard to find. If you're the underdog you need to drive adoption, and the way to do that is "free." Hell, that's how Microsoft became dominant in the home in first place: piracy, and the tacit acceptance thereof. Only after they had established market dominance and started cracking down on "free" did they start slipping.

        Personally, I can't abide a non-POSIX compliant OS anymore, and while I appreciate WSL (and use it extensively whenever I need to use Windows), the only real

  • Go is NOT a systems language! (Score:5, Insightful)

    by pavon ( 30274 ) on Friday May 22, 2020 @05:09PM (#60092642)

    I don't know why people continue to group Go in with systems languages, when it is firmly in the same class as Java (Kotlin), C#, D, Swift, etc. These are all memory-safe, garbage collected, relatively efficient programing languages that are good for the vast majority of programing tasks, but systems programing is part of the minority niche that they cannot fill.

    No language that uses garbage collection, with the unpredictable latencies it introduces can be considered a systems programing language. Nor languages that do not provide low-level access to memory and hardware (eg if you can't address memory-mapped hardware, or respond to CPU interrupts).

    • (eg if you can't address memory-mapped hardware, or respond to CPU interrupts)

      ..or allow insertion of machine language directly?
      (my programming skills are way out of date so I don't know if the other languages you mentioned allow that or not, but I suspect they don't)

    • What are the defining systems language characteristics? And why? Can some of the languages you name replace their GC or control it?

    • Wow, so many misconceptions. Lisp has GC and has been used to write operating systems. Oberon has GC and has been used to write operating systems, and even has its GC written in itself. GC itself doesn't have to introduce "unpredictable latencies", although many simpler implementations of it do. And many GC'd languages like Lisp or Oberon do provide low-level access to memory and hardware.

      • The only way it's predictable is if there's only one thread running, there's no I/O concurrency, and it's invoked explicitly, which is silly.

        • That doesn't really seem to make a lot of sense. *Why* would it need those things to be predictable? There's been parallel concurrent pauseless collectors for a decade or so. So you get lots of threads predictably running without any explicit GC invocations, assuming hardware supports it (which needed specialty CPUs in the past but they've managed to make this work on AMD64 recently).

    • Java (and such Kotlin) have non GCed VMs, too.
      And even standard Java can access arbitrary memory, albeit by @depricated APIs, and then you can call C from Java - problem solved.

  • Direct link (Score:3)

    by chris-chittleborough ( 771209 ) on Friday May 22, 2020 @05:32PM (#60092716) Journal

    Video of talk is at https://mybuild.microsoft.com/... [microsoft.com]

  • Misplaced Faith (Score:5, Insightful)

    by AlanObject ( 3603453 ) on Friday May 22, 2020 @05:38PM (#60092738)

    I'm not saying that this move to Rust is wrong, but I still have difficulty with the mindset that you just change languages then magically all the bugs stop happening.

    Doesn't work that way. Never has never will.

    Yeah they will stop getting crappy pointer bugs but the team with the talent level that wrote crappy pointer bugs in the first place will naturally and effortlessly find new types of bugs to create.

    • Re:Misplaced Faith (Score:5, Informative)

      by theJavaMan ( 539177 ) on Friday May 22, 2020 @05:49PM (#60092766)

      Not all bugs, just bugs that could be avoided by not using a kitchen sink language like C++ that, despite all of its complexity, could not bother with bounds checking and better memory management. When you spend more time trying to understand what the compiler does, or how to trick it into doing what you want, instead of solving the actual computational or business logic problem, then you picked the wrong tool. Apparently everyone has.

      • This is why C++ shouldn't be a systems language.

        • This is why C++ shouldn't be a systems language.

          C also shouldn't be a systems language. It doesn't have the complexity of C++, but it also doesn't bother with bounds checking or better memory management. C is also at too low an abstraction level in many cases, and not just because it requires programmers to do extra work, but because it impedes optimization. Too much isn't expressible directly in the language, so the compiler and optimizer have to try to read the programmer's mind to figure out what's safe.

          Rust is still something of an unknown quanti

          • and a higher level of abstraction that appears to enable much more effective optimization.

            I don't really see any evidence for that claim. The abstraction level doesn't seem much different from C++, and the performance is slightly behind (on which one can probably blame less mature compilers). It looks very similar to C++ overall in the machine model it uses and the type of abstraction.

          • Re: (Score:2)

            by AmiMoJo ( 196126 )

            Too much isn't expressible directly in the language, so the compiler and optimizer have to try to read the programmer's mind to figure out what's safe.

            It's the exact opposite of that. The beauty of C is that it is minimal enough for everything to have clear, concise rules and there is no mind reading required. Everything is explicit in modern C, the few areas that were ambiguous are now formalised and the compiler can make simple logical decisions about optimising it.

            One common mistake novices make is thinking that qualifiers like const, static and volatile are related to optimisation.

            I hope Rust does take over more system programming. There is a lot of b

            • Re: (Score:2)

              by Euler ( 31942 )

              C is minimal, predictable, etc. But I think swillden's comment is related to the fact that getting optimal code (predictably) is hard due to the fact that the language lacks enough constraints to allow the programmer to convey enough clues to the compiler/optimizer, so it typically builds for the worst-case. Maybe it should be stated that "...so the compiler and optimizer have to try and read the programmer's mind to figure out the _most optimal way_ to keep the code safe." And I'm not talking about thin

              • Re: (Score:2)

                by AmiMoJo ( 196126 )

                I see what you are saying but I think some examples would really help. If anything I'd say it's more like the other way around, generally if you understand the compiler well enough (i.e. you can read its mind) you can get it to optimize the way you want it to. Never quite as good as hand coded assembler but no higher level languages manage that.

                I do a lot of code for 8 bit systems and generally don't find this stuff to be much of an issue. Occasionally I do a bit of assembler but I haven't see anything that

      • You don't need bounds checking if you don't go out of bounds. It is much better to provide high level constructs that avoid bounds all together. C++ does that and shows people how to do that with its STL algorithms, and the upcoming ranges library. It does it without introducing any runtime overhead.

        You call yourself theJavaMan. What language are most JVMs written in?

        No one spends more time trying to understand what the compiler does in C++, except for compiler writers. What you say sounds like someon

        • You don't need bounds checking if you don't go out of bounds. It is much better to provide high level constructs that avoid bounds all together. C++ does that and shows people how to do that with its STL algorithms, and the upcoming ranges library. It does it without introducing any runtime overhead.

          Yep.

          Also: Microsoft may be claiming tu use C++ but all their base APIs are C (ie "Win32"). They all use structs with no constructor, they all have an uninitialzed "size" field inside that struct to indicate how big they are as a sort of versioning system, etc., etc. It's C, not C++.

      • Actually, C++11's smart pointers are a major improvements in memory management. Regarding bounds checking, if you don't do bounds checking, you lose speed. Both Rust and C++11 are trying to implement memory protection algorithms that run AT COMPILE TIME, in order to preserve efficency.

      • The point of C++ is that you can define your own (better?) memory management.

    • > but I still have difficulty with the mindset that you just change languages then magically all the bugs stop happening.

      If that were the mindset of the Rust community, I'd agree with you. Fortunately, I have not seen or experienced that to be the case. Outside of people shooting off their mouths who don't speak for "The Community" I've never seen anyone in that community say that simply changing the language will solve all the problems.

      What I have seen said is that there are several classes of problems

      • However, it is clear, that GC can never match the performance of manual memory management like that which is done in C or C++.

        What performance? Programmer's performance when having to use malloc() and free() manually sprinkled throughout the program in C? Or the execution overhead associated with these things? In C++, the potential unbounded latency of destroying large graphs of objects? How does that compare, for example, to the allocation speed, concurrency properties and throughput of C4/Zing with guaranteed zero pauses for mutators?

        Rust does have optional single-thread-only reference counting, "Rc", and muilti-thread capable atomic reference counting, "Arc", but, you only need to use them in situations where that is the only way to model the specific problem

        I doubt that that is "the only way" to model the specific problem. Well, maybe in Rust it is. (I

        • It really depends on the use case. If memory is at a premium, then a) you will probably never have large graph objects, and b) you need very tight control over allocation and destruction. If you're working with effectively unlimited memory, then those things become less important.

    • You don't have to be a bad programmer to make off-by-one errors, or misconstrue corner and edge cases, or forget a default case. It happens *all the time* by very competent programmers who know exactly what they're doing.

    • I'm not saying that this move to Rust is wrong, but I still have difficulty with the mindset that you just change languages then magically all the bugs stop happening.

      You don't though; you just don't like it with this language. Otherwise you may as well write in machine code.

      Many of the advancements in languages have eliminated wide classes of common bugs.

      Machine code to assembly eliminates the common bug of figuring out the bit packing wrong and putting the wrong instruction variant in the code.

      Structured

  • MS shot themselves in the foot (Score:2, Insightful)

    by Anonymous Coward

    With C++ eons ago when they put COM everywhere with *client-controlled* refcounts.
    Completely subverts the standard RAII pattern that fundamentally helps prevent C++ code from leaking.

    • With C++ eons ago when they put COM everywhere with *client-controlled* refcounts.
      Completely subverts the standard RAII pattern that fundamentally helps prevent C++ code from leaking.

      This.

      All their most basic APIs and connections are fundamentally C, not C++. It's all structs with no constructors, no initialization of variables, they all have an uninitialized "size" field inside them as a sort of 'versioning' system, etc., etc.

      It's a disaster waiting to happen and they can't fix it without scrapping the whole "DLL" thing.

      • C++ has structs too. It's basically a superset of C. So all of their APIs are fundamentally C++ too. C++ has zero problems interfacing with that stuff as I'm sure you know. If C can do something then C-With-Objects can nearly always do it too and in exactly the same way.

    • Refcounting is fully compatible with RAII - have you ever used std::shared_ptr?

Slashdot Top Deals

Let's organize this thing and take all the fun out of it.

Close