Microsoft Previews 'Rust for Windows' (microsoft.com) 70
From Mike Melanson's "This Week in Programming" column:
"The Rustening at Microsoft has begun," tweeted Microsoft distinguished engineer Miguel de Icaza.
What de Icaza is referring to is a newly-offered course by Microsoft on taking the first steps with Rust, which much of the Twitterverse of Rust devotees sees as a sign that the company is further increasing its favor for their crab-themed language of choice. Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software. A few years back now, Microsoft launched Project Verona, a research programming language that takes a bite from Rust in the realm of ownership and is said to be inspired by Rust, among others.
More recently, however, Microsoft announced the preview of Rust for Windows, which "lets you use any Windows API (past, present, and future) directly and seamlessly via the windows crate (crate is Rust's term for a binary or a library, and/or the source code that builds into one)." With Rust for Windows, developers can now not only use Rust on Windows, they can also write apps for Windows using Rust...
According to the project description, the Windows crate "lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module" and that, along with the introduction of a course for learning Rust, is precisely what has all those Rust devotees so excited.
InfoWorld has more information...
What de Icaza is referring to is a newly-offered course by Microsoft on taking the first steps with Rust, which much of the Twitterverse of Rust devotees sees as a sign that the company is further increasing its favor for their crab-themed language of choice. Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software. A few years back now, Microsoft launched Project Verona, a research programming language that takes a bite from Rust in the realm of ownership and is said to be inspired by Rust, among others.
More recently, however, Microsoft announced the preview of Rust for Windows, which "lets you use any Windows API (past, present, and future) directly and seamlessly via the windows crate (crate is Rust's term for a binary or a library, and/or the source code that builds into one)." With Rust for Windows, developers can now not only use Rust on Windows, they can also write apps for Windows using Rust...
According to the project description, the Windows crate "lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module" and that, along with the introduction of a course for learning Rust, is precisely what has all those Rust devotees so excited.
InfoWorld has more information...
Is their a memory-MANAGER in the house? (Score:3)
Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software.
All these decades and memory management seems to be the most difficult thing to handle.
Re: (Score:3, Insightful)
Re:Is their a memory-MANAGER in the house? (Score:5, Informative)
So instead Rust doesn't use GC but does what C and C++ do. Objects either reside in the stack or in the heap. The compiler tracks lifetimes during compilation and knows where to put the allocations and the frees if they're needed. It also has constructs sort of analogous to smart pointers in C++ called a Box (scoped pointer) and a Rc / Arc (shared pointer) that will free up when their lifetime ends.
Re:Is their a memory-MANAGER in the house? (Score:5, Interesting)
For example in Go (which has garbage collection), the GC can freeze the world while it frees stuff up.
Go is hardly the pinnacle of automated memory management. There have been way better implementations of it, such as C4. Having said that, even Go apparently got fairly good in the recent versions (or so they say).
The compiler tracks lifetimes during compilation and knows where to put the allocations and the frees if they're needed.
Yes, at the expense of twisting your program from the beginning to have a particular shape, for example the inability to construct general object graphs. So certain kinds of useful programs such as object databases are impossible to write this way.
It also has constructs sort of analogous to smart pointers in C++ called a Box (scoped pointer) and a Rc / Arc (shared pointer) that will free up when their lifetime ends.
And that comes at the expense of having to do frequent atomic operations in a multi-threaded environment, otherwise the refcount bookeeping wouldn't work at all (plus the memory overhead of those references).
Re: (Score:2)
And that comes at the expense of having to do frequent atomic operations in a multi-threaded environment, otherwise the refcount bookeeping wouldn't work at all (plus the memory overhead of those references).
Honestly that's way overstating it, atomic ref counting really isn't that big of a deal. If you really hate it that much, there are probably some tricks you can do using unsafe to get around it, but the performance you'll gain from it is almost certainly not worth it. Rust is flexible enough that there are plenty of ways of skinning any given cat. Though it's really telling that you advocate the use of a garbage collector yet at the same time you're complaining about the expensive of atomic ref counting.
Re: (Score:3)
Re: (Score:1)
Rust makes atomic refcounting performant by almost not using it, rather relying on stricter dependencies between objects and enforcing ownership most of the time. Likewise GC'd languages make GC fast by almost not doing it as well, relying on the generational behavior. There's no silver bullet and everyone in the class is cheating to pass the test. ;)
So relying on memory to be defined for it beforehand by another language that's "supposed" to be so bad at it? Another general question is this how well does this solution scale up with undefined upper limits, without a language like C/C++ doing the heavy work in the kernel?
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's actually rather simple; just use a garbage collector and don't use unsafe pointers. That makes it impossible for you to make a memory management error outside of retaining things for too long.
No. You can have an object that is referenced but unused, which happened a lot in the earlier Spring framework. Here's a simplified way [pastebin.com] of how that happens.
The static reference indicates that so long as the given class is loaded, the ArrayList list will exist, even if you never need it again. It will only be gone once you explicitly unload the class from the JVM or the application closes. And early on many objects in Spring had static lifetimes but programmers would call them into existence as if they w
Re: (Score:3)
No. You can have an object that is referenced but unused
I guess you completely ignored the part where I wrote:
outside of retaining things for too long.
rendering the rest of your text redundant. Also, the need for weak references have nothing to do with cycles. Proper garbage collectors are not confused by cycles even with strong references. If a cycle is not reachable from roots, it gets thrown away. Likewise Java language design deficiencies are avoidable and don't have to be repeated in other languages.
Re: (Score:2)
I guess you completely ignored the part where I wrote:
No I caught that, that still doesn't mean that GC is a magic bullet. So when you say
It's actually rather simple
Actually it isn't and you still need to have competency to avoid memory leaks. You just magically carving out some exception doesn't make it so. Which is where you miss my point of:
A GC ensures that you do not leak memory for most cases, but it is an insane proposition to assume that it will prevent ALL leaks.
rendering the rest of your text redundant
No because it ignores the point that I made with try-with-resouces, which the GC isn't watching for by default hence the syntax.
Proper garbage collectors are not confused by cycles even with strong references
*sigh* I mean are you going to stay in one lane or you just going to be all over the place? Because you either are
Re: (Score:3)
No I caught that, that still doesn't mean that GC is a magic bullet.
I never said that it was a silver bullet. Every solution has some drawbacks. It's just that for GC, lack of memory safety isn't one of them.
Actually it isn't and you still need to have competency to avoid memory leaks.
But not memory safety, which is what the comment I was responding to [slashdot.org] was about.
No because it ignores the point that I made with try-with-resouces, which the GC isn't watching for by default hence the syntax.
ANOTHER point that doesn't have anything to do with memory safety? How many of them will be there?
*sigh* I mean are you going to stay in one lane or you just going to be all over the place? Because you either are going to say, "yeah that's true in a single threaded environment"
Proper garbage collectors are not confused by cycles even with strong references even in multi-threaded environment.
is some serious attempt to bend reality to match up with what you're trying to prove.
Are you claiming that the cycle won't be collected? You should file a bug repor
Re: Is their a memory-MANAGER in the house? (Score:1)
My position is that GC solves the memory safety problem that MS struggles with.
No, it doesn't. When you need to do systems programming, or when you need to write highly performant code, garbage collection simply isn't an option. Rust gives you both highly performant code comparable to C, AND it gives you memory safety. No other language does, save for a few experimental ones.
Re: (Score:3)
Re: (Score:2)
It does that, at the cost of some pretty severe limitations
Those are only limitation if you do not understand the syntax and underlying point of Rust.
Expressive, safe, fast -- today, pick two
In systems programming there is only a pick one (out of the options you've given) and it is "safe" everytime. If that is not the case, then whoever does not need to be in systems programming. And that is ultimately the biggest problem MS has with their WINAPI. The nice thing about Rust is that it allows you to indicate particular contracts that you must obey by or the compiler will require you to wrap it in unsafe
Re: (Score:2)
Expressive, safe, fast -- today, pick two.
Rust gives you all three. Really. The only "limitation" of Rust would be that it's not as old as the mainstream systems languages, so there aren't as many libraries available for it, but that is very rapidly changing.
Re: (Score:2)
Re: (Score:2)
An object that can both own and construct another object that can do likewise with the other can lead to cycle references that a GC just simply can never dispose of.
that is nonsense.
If there is no reference (or chain of references) from the stack or static class members, those are cleaned up just fine.
A circle is a group of objects that reference each other, and can not be reached from "the main function" or any location on the stack. And that is the reason why reference counting is not garbage collection.
Re: (Score:2)
Re: (Score:1)
Even simpler : use the stack.
Just allocate a new process onto the stack. Yea... Try it. See how that works out.
Re: (Score:2)
Of course, this isn't the first we've heard of Microsoft looking to Rust to handle the 70% of Microsoft vulnerabilities that it says come from using the memory-unsafe C++ programming language in its software.
All these decades and memory management seems to be the most difficult thing to handle.
Not really. But I think there are too many people that underestimate memory management or do not want to be bothered by it. These people then screw up. But there are plenty of software packages written in memory-safe languages that have security problem after security problem. That is why the move to Rust is bogus. It fixes the wrong problem.
Please don't break cross-compatibility (Score:4, Informative)
Rust applications can be easily built for Linux, Windows and Mac as long as the crates they use are available for these OSs. Use this Windows crate and you break your app for Linux and Mac.
Re:Please don't break cross-compatibility (Score:5, Insightful)
So it is working as intended then.
Re: (Score:3)
Re: (Score:3)
If the intent is to break compatibility with anything, then it won't work very well. The only reason you'd need to use this crate is if you are trying to do something specific with the win32 api that you can't realistically do any other way. Whenever you use this in cross platform code, precede those bits with this:
#[cfg(target_os = "windows")]
Then when you compile for linux, that part won't be compiled in. Likewise, if you're doing something specific for Linux, you use this:
#[cfg(target_os = "linux")]
Then
Re: (Score:2)
Offline use (Score:2)
I have heard of the Internet and the cloud. I have also heard of Internet access outages. When a desktop computer is subject to a neighborhood-wide ISP outage, it cannot reach the cloud. Likewise with laptops if COVID gets contained, as a laptop outside the home may not be in range of any hotspot open to the public, and the user's cellular plan may be out of tethering megabytes. Thus offline use is still important.
Or did you have a single-page application backed by a Service Worker in mind? There are people
Re:Please don't break cross-compatibility (Score:5, Informative)
Use this Windows crate and you break your app for Linux and Mac.
No you don't; Rust has macros that allow you to specify where your code does one thing in one OS, and another thing in a different OS.
You can basically think of this crate as being a more feature complete version of the winapi crate, which tons of other crates that are cross platform already rely upon. Here's one that I use all the time:
https://github.com/hwchen/keyr... [github.com]
Re: (Score:2)
Rust has macros that allow you to specify where your code does one thing in one OS, and another thing in a different OS.
For example, you could have an application that works in Windows and displays "GUI missing; pull requests welcome!" on other operating systems.
Its Rusting (Score:4, Funny)
Accretion of rust on something is called rusting.
Microsoft is rusting.
Re: (Score:1)
Rusty windows.
Ironic (Score:4, Interesting)
They probably reckoned that C# (.NET) would win out over C++, so when it didn't they're now trying to save face by jumping on a bandwagon.
What about that D or Ada API, Microsoft?
Re:Ironic (Score:5, Interesting)
Microsoft offered many COM APIs, which were designed around their VTable format. Despite being callable from C, they are basically C++ APIs.
Re: (Score:2)
I think if I were intent on writing a GUI application on Windows these days I'd be using something like QT or wxWidgets. Not only is it fairly convenient, but also it makes cross-platform development viable too.
Getting back on topic, I think that GUI development is definit
Re: (Score:2)
GUI is definitely a sore point for Rust
Will this be like Microsoft's Java, ... (Score:2)
Re: (Score:2)
No, this doesn't modify rust in any way, nor is it Microsoft's own implementation of rust. It's basically a shim that makes it easier to call win32 functions in a way that feels more native to rust rather than building your own FFI interfaces manually. For most things you do with rust, you won't need this, but if you're calling any win32 functions, it's really handy.
Re: (Score:2)
Re: (Score:3)
Yes the MS version may be incompatible but, no, that may not be an issue. Java was intended by Sun to be cross-platform and standardized; the Java licensing specifically stated this. Microsoft intentionally introducing incompatibility went against the licensing and was clearly out to harm Java. With Rust, there is no current standardization of the API and the licenses (Apache and MIT) do not forbid MS creating their own incompatible version. Also due to the nature of the purpose, incompatibilities between v
Re: (Score:1)
Isnâ(TM)t it rusty enough? (Score:1)
Visual Rust or Rust .NET? (Score:2)
Re: (Score:1)
You can't live off the goodwill of those non-paying freeloaders.
So... (Score:2, Insightful)
Re: (Score:2)
If 70% of Microsoft's vulnerabilities come from unsafe memory handling errors in C++ land you'd think they could run a simple static analsysis to find and fix them, right?
Static analysis tools aren't able to detect all (or even most) memory-handling errors. It would be awesome if they could, but as usual the Halting Problem comes in to ruin the fun.
Re: (Score:2)
The halting problem only shows that there's an infinite number of programs can't be statically checked, it doesn't prove that the "measure" of this set of uncheckable programs inside the set of programs written by humans is significant. I really think that people over stress its meaning.
Also, from a pure theoretical point of view, since our machines are finite, you can say that they are not turing machines but finite state machines, which renders the halting problem meaningless. I feel like people like to u
Re: (Score:2)
The halting problem only shows that there's an infinite number of programs can't be statically checked, it doesn't prove that the "measure" of this set of uncheckable programs inside the set of programs written by humans is significant. I really think that people over stress its meaning.
Rust's type checker is a static analysis. It's pretty much state-of-the-art.
Also, from a pure theoretical point of view, since our machines are finite, you can say that they are not turing machines but finite state machines, which renders the halting problem meaningless.
Well not meaningless but the situation is indeed more complicated than computable or not computable. Any static analysis needs to complete in the amount of time you're prepared to wait for it, or it's not very practical. Indeed, Rust's type checker is often criticised for being slow.
I feel like people like to use the halting problem simply as an excuse to not improve static checking and/or theorem proving for programs.
Have you improved static checking and/or theorem proving? If not, what's your excuse?
Re: (Score:2)
I've done most of my programming either in OCaml or C++, with the C++ code always using unique/shared pointers and as much useful static asserts as I can think of. As for why I'm not doing theorem proving, the answer is quite simple, because it would slow down my coding and my employer prefers me to crank out code faster even if it is less secure. That's market conditions for you.
Re: (Score:3)
That said I doubt they would have any reason to rewrite that code in Rust. If it works and is stable, it makes sense to leave it the way it is. But for new code it makes a lot of sense to consider Rust because it stops bugs from happening in the first
Re: (Score:2)
If static analysis could find all unsafe memory handling in C++, then that would be built into a good C++ compiler. As far as I know, the design of C++ does not allow complete analysis of that kind. There are holes. A tool like Valgrind can detect memory errors, but only by running code on a virtual machine. This is a species of testing, rather than static analysis. I am pretty sure it is possible to write code that looks OK under Valgrind, but contains memory unsafe operations that were missed in testing.
Credit where credit is due (Score:2)