Microsoft is Getting Rusty [video] | Hacker News Reader

Microsoft is Getting Rusty [video]

youtube.com

87 pointsweinzierl70 comments

It's probably just a matter of time before Rust replaces C and C++ for most use cases.

Rust continues to make in-roads in the Linux kernel and userland.

As this video shows, Microsoft is adopting Rust to improve reliability and security.

Don't say that to the linux kernel devs..

The Linux Kernel development process is the quintessential "Ask 10 people for opinions on where to get lunch and you'll get half the Internet chiming in with their thoughts"

Inertia is going to keep C and C++ going for a while. The ship takes a long time to turn and it just started turning in the past couple of years. It's probably more accurate to say that individual ecosystems might become Rust-dominated in the coming years but "most" is maybe a tough call.

Like: I wouldn't be surprised at all if most (new) linux drivers were written in Rust 5 years from now, and software like git and systemd and pipewire and LLVM and maybe even Postgresql had started to adopt it. And I basically expect that Rust will be completely dominating internet-facing software like servers, browsers, media parsers and the like within 10 years.

But I'd be pretty surprised if Rust had more than 20% penetration in automotive / aerospace firmware, or gamedev, even 10 years from now.

And until then someone might create a more ergonomic evolution of Rust.

Ada?

>> And until then someone might create a more ergonomic evolution of Rust. > Ada?

Um what? Which is to say -- how is Ada more ergonomic, if ergonomic means "relating to or designed for efficiency and comfort in the working environment"? I'm curious about what advantages Ada has there.

Ada has a more traditional syntax compared to Rust, for good or for bad.

> Ada has a more traditional syntax compared to Rust, for good or for bad.

How do you mean? "Traditional" in the sense that Pascal and Ada are old, and Rust is not? Rust may be ML in C's clothing, but isn't C's clothing more ergonomic for most C/C++ types?

I wished Rust had developed as an ML in Pascal/Ada's clothing but as you said it would not have been ergonomic for C/C++ folks and probably not as successful as it is.

In my opinion, Ada needs some better tooling to become accessible.

Though I'll have to give the Ada LSP a go again, hoping that it plays nicely with JetBrains' suite.

> And until then someone might create a more ergonomic evolution of Rust.

I wouldn't discount Rust's ability to create a more ergonomic evolution of Rust, because they already have. A few times. See: Polonius, https://github.com/rust-lang/polonius, and NLL, https://rust-lang.github.io/rfcs/2094-nll.html

This is a thing I've been wondering about for a while. How many people are exploring the general design space of safety, but from the ground up, so that they aren't tied to the set of design decisions Rust made? At one point MS had Verona but I have not heard anything about it in years so no clue if it is still actively being worked on/explored.

Rust is a good language IMO, but the industry cannot just stop there and decide this is good enough. Even with ideas like editions, there's a level of breakage Rust isn't going to do.

By total LoC owned, sure. I would be completely unsurprised if 20% of major companies in those industries have significant components written in Rust within a decade. It's been a long time since there was this much language interest within the embedded/safety critical domains.

Yeah embedded software strikes me as one of those areas where rust can really shine (and where the cost of a crash can be high esp. if you run close to bare metal).

Penetration into those domains has still been pretty brutally slow. AFAIK only Volvo is shipping Rust code, in 2 models of car, and not for anything safety-critical yet.

That's not a demerit to Rust, just a testament to the conservatism of those industries.

I'm aware of Rust code in various states of "development/experimentation" within GM and Toyota, as well as rust applications that might already be in your home if you've purchased any expensive, brand name appliances recently. It's slow, but happening.

I worked in the automotive space (CAD/CAE/CAM) and there was tons of code that had commit headers starting in 1996 - the year they moved the previous code base into that particular VCS. Plenty of files had less than 10 commits to them since.

They still had some FORTRAN in the code base. According to my coworker who worked there for 25 years, his first project at the company involved the initiative to replace FORTRAN with C.

So yeah, there's plenty of C code hanging around that's not going anywhere.

I wonder whether Rust will stick similarly because that's just how things go, less because now the migration process has been tested and the system is more flexible as a while or more because it's really pretty good enough this time.

It’s nuanced. Google has shown that legacy C/C++ code is fairly stable in terms of memory safety bugs. That and the effort and risks involved means that existing C/C++ code is unlikely to be replaced wholesale. But that also means that switching new development to Rust has an outsized effect on preventing new bugs. So expect old code to stick around, but new code to be written in Rust with interoperability with the old code.

The way I read the parent comment was as in; replacing C/C++ with Rust as a choice for language going forward, not replacing existing C/C++ code bases with Rust.

That’s fair, I think I might have been interpreting it as a call to “rewrite it in rust.”

In the video, Mark talks about Microsoft investing in replacing certain portions of Windows/Office/Azure going C/C++/C# [eliminate GC, SharePoint being mentioned] with Rust. Primarily in security-critical areas, but one of the first points in Windows was font handling, a huge security issue for Windows historically.

There are definitely some regions of existing code where legitimately replacing the existing C/C++ functions with Rust is justifiable on its own. The big one I can think of is parsing code--things like parsing fonts (as sibling mentions) or A/V codecs are things that have historically been replete with exploitable memory safety issues and are reliably untrusted data.

Threading is another case. The Asahi's gpu Tust driver was able to avoid a lot of threading issues because of Rust.

I think folks said the same thing about Java in the 90s...

It did to a degree but still left a sizeable amount of use cases as they were ill suited for Java. I feel like this is repeatedly happened since where each new or newly hyper language has peeled off parts of C++'s use cases but never gone for the core. I feel like Rust is the first that can do it and significantly improve on it. While it does lack specialization and some template tricks, it has memory safety, core/alloc/std, first and third party libraries focusing on `Result` rather than exceptions, etc. This is much better suited for kernel, embedded, and framework development while also being able to scale up into the use cases that went to Java and other languages previously.

Nobody wrote systems software in Java and been successful. But Rust did.

Arguably, Android is a systems software large chunks of which are written in Java.

The places that Java is used are mostly higher level parts AFAIK. Java is more for the API of Android for app developers.

Java completely replaced C++ in business software

C++ is almost nowhere to be seen in modern day distributed computing and business software, outside OS, language runtimes, databases and networking stacks, also known as low level infrastructure code.

All relevant application software is written mainly in a mix of Java and .NET languages, complemented with a mix Go, Rust, Python, Ruby, and SQL dialects.

Likewise Apple, Google and Microsoft no longer have C++ based GUI frameworks, like it was common in the 1990's, and one of them ships a whole OS where Java rules the userspace.

Is Rust itself 100% written in Rust yet?

Close! Depends what you call 100% I suppose. Even C isnt 100% C

I suspect they are arguing that it is not because the default codegen backend produces LLVM IR, which C++ code turns into the final executable. The Cranelift backend which is pure Rust exists, but because it is not the default some people discount it. I personally believe that leveraging existing codegen infrastructure is sound engineering. Having a "pure" implementation is not a goal of the project, having solid tooling is. That might translate in the future to tackling codegen more directly, but it isn't a huge pain point today.

The real contention is how do you know it’s memory safe if Rust itself isn’t pure safe Rust?

Because that’s not really relevant; Java is a memory safe language and the JVM is written in C++, Ruby is a memory safe language and it’s written in C.

Both of those have had memory related exploits, as I recall

Bugs happen. That’s true of any program.

rustc is written in Rust - for many years, start based on OCaml

I've spoken to a few former colleagues and a lot of them took roles because it was in writing Rust. It's not that the role required writing Rust and they happened to know it, it's that they selected jobs based on whether they would be writing Rust or not.

One of the problems I currently have is that I am not comfortable writing other languages anymore that aren't as strict. I was able to shift part of the cognitive load to the compiler. There are productivity benefits associated with that if you're writing code at that level.

That said, it's hard to find the jobs themselves as quite often you see requirements of Python/Java/Rust/Go. Doesn't tell you what stack they use.

Out of the major operating systems, Windows is probably by far my favorite to develop for[1] using Rust. windows-rs[2] is officially supported and is constantly being worked on and improved.

[1]: https://github.com/LGUG2Z/komorebi

[2]: https://github.com/microsoft/windows-rs

This makes me wonder what .NET would look like if developed in Rust instead of C#

Like working with dotnet from f#?

Rust#

Rust-sharp? That's tetanus.

Fun fact I didn't learn until adulthood: rust itself doesn't carry tetanus. What does is dirt. A rusty nail can pierce through clothing and skin because it is a nail, and can be assumed to have been in the dirt because it is rusty. It's "only" a useful approximation.

Not quite the same guarantees.

Honestly, I am someone who knows nothing about the .NET / Windows ecosystem outside of the Win32 calls required to build out a tiling window manager and a hotkey daemon. These are mostly calls that go all the way back to Windows 95 (and maybe even earlier?)

However, if I as an absolute Windows programming newbie with basic competency in Rust could pick up windows-rs and build a tiling window manager, I'm sure that people who are intimately familiar with the .NET and Windows development ecosystem could develop incredible things targeting Windows with Rust.

the .Net environment strongly depends on the runtime-ability of all .Net Languages - its feel like AOT (ahead-of-time/finaly compiled) but its not, so Rust woulnd fit good

It does now, yes.

This is a hypothetical that only looks at what .NET but in Rust would look like, ecosystem aside

I really loved watching Mark Russinovichs troubleshooting videos. This guy really knows Windows client and server.

The case of the unexplained https://www.youtube.com/watch?v=AJyr21spwkA&list=PLhFhDWFYcc...

His two part serious about Windows memory management was an eye opener for me.

1st part:

https://youtube.com/watch?v=TrFEgHr72Yg&pp=ygUpd2luZG93cyBtZ...

Sadly seems the second part is missing.

It is really good to see how they've actually applied Rust rewrited in areas that make sense too, having worked with C++ Microsoft code that was sold to Ericsson I can say it's extremely dense and requires a lot of learning curve time to get a feel for their 'way'. It is very easy to make mistakes we found with the C layers specifically, I wish Rust was around and mature enough at the time to realise a rewrite. The productivity benefits alone would have been worth it.

The way I think about languages is that one must in their programming journey go toward greater type safety. If the journey begins with JS/Python, it must go to TS/Go, then Rust, then Haskell, and finally Idris.

Type safety is exceedingly and especially important in a shared code development where one is not the only developer.

But one also has to live and work among newbies, so there is a constant pull in the other direction towards simplicity, otherwise productivity grinds to a halt.

What exactly ends up being the most pragmatic language that strikes the best balance is likely never going to be decided.

If companies get their way, there won't be "career newbies". Students will spend years developing a portfolio for free to prove they can out-efficiency an LLM. Which of course will suppress the industry as Tech is no longer this fast path to riches (the actual wage suppression doesn't help either).

Which is why everything ends up as json in the end.

Type safety is helpful but it can be excessive. I feel like a lot of stuff in Haskell is like that, and probably even in Rust. Everyone has a finite amount of time and energy to spend writing (and compiling!) increasingly complex specifications.

This is why I'm so bullish on Typescript. The type system is so good and expressive that you want to use it, but it doesn't keep you from using interfaces and methods because some complicated vendored type can't be satisfied.

That's all the excuse a teammate needs to never satisfy any type constraints.

I'm pretty satisfied with the amount of type checking in C++ and Java. You can go crazy with it but the people who write those languages usually have the good taste to not go overboard with complex type tricks.

Great talk. I wish Mark had gone over the "dislikes" slide a bit longer though. For instance, I'm not sure what "dynamic linking will eventually bite us" means. He says dynamic linking is commonly used on Windows, but I don't understand how that's problematic with Rust.

Rust doesn't have a stable ABI for things that can't be expressed in C, so I assume he means when you're screwed when you want to publish Rust-specific interfaces to a shared library.

This is one area where Swift is far ahead of Rust, at least for now.

The stable ABI is really tricky. Another pointer from another talk was about how stabilizing ABI might reduce the performance hash functions (which is used by the compiler) by 0.5%. So, it is really a tricky decision to make that involves doing the right tradeoff at the right point in time.

I'm convinced that a COM-like solution with support for concepts that Rust/Swift have will be the sweet spot.

Reply on news.ycombinator.com