Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming

[Thomas1965]

No matter how much investment software companies may put into tooling and training their developers, “C++, at its core, is not a safe language,” said Ryan Levick, Microsoft cloud developer advocate, during the AllThingsOpen virtual conference last month, explaining, in a virtual talk, why Microsoft is gradually switching to Rust to build its infrastructure software, away from C/C++. And it is encouraging other software industry giants to consider the same.

https://thenewstack.io/microsoft-rust-is-the-industrys-best-chance-at-safe-systems-programming/

[zapshe]

What a bunch of noobs, they only have to use unique_ptr ;)

[jonnin]

I call it like I see it:
safe is manager-speak for 'slow'.

[George P]

@jonnin, another reason why a division at MS likes Rust! Slo-o-o-o-o-w-w-w-w! You'd think they'd want FAST cloud computing, but noooooo!

[jonnin]

M$ has been on an anti-C / anti-C++ kick since they lost the java lawsuit and cooked up the pound C language thing. They should have called it !C, a double pun on their draconian approach to things and that is isnt remotely C. (Say it out loud if you missed that).

That xor managed C++ garbage is just more of the same: we hate c++ and 'fixed' it for you, you are welcome..!

Its hard to take anything they say about C or C++ serious because of this ongoing campaign against the language.

[helios]

Nah, Rust is not slower than C++. At least, not necessarily. The main difference with C++ is that is has a more robust type system that keeps track of references (or something along those lines). It's not like C#, which has a much, much more sophisticated runtime environment.
Rust's only potential limitation in terms of performance compared to C++ is that it's newer and therefore not as much compiler-writer-brain-time has been spent on it.

I feel like it's just lip service. C and C++ are still first class citizens on Windows. I don't know what they're referring to when they say "infrastructure software", but personally I encourage anyone to not use C++ if they don't need to. The right tool for the right job and all that.

[zapshe]

Anyone here actually code in Rust? I looked up a quick tutorial and it looked almost exactly like C++.

[Albatross]

Disclaimer: I've been coding in Rust for the past half a year.

The largest performance issue Rust devs have is that of their compiler. There's a lot of analysis that has to happen in order for Rust's reference management to work correctly. But it's not like us C++ enthusiasts can claim that things are so much better in that regard here, especially now that C++ is increasingly becoming a language for compile-time computation. :)

Otherwise, Rust programs don't use tracing garbage collection, are generally AoT compiled using a production-grade optimizing LLVM backend, and are fairly simple in terms of the type checking that needs to happen at runtime for stuff like pattern matching to work. In short, there's no practical reason why Rust programs need be significantly slower than their standard C++ counterparts.

That said, I doubt rustc gets nearly as much developer attention as clang++ or g++ do, so (without having looked at any benchmarks), I would not be surprised if compiled Rust programs are slightly slower in practice (to say nothing of any overhead incurred by writing idiomatic rather than optimized code).

However, there's definitely room in the ecosystem for a language like Rust, and no, Microsoft is not being evil or insulting for recommending it. There's a LOT of suboptimal cloud computing code that would be substantially more performant if it were rewritten in Rust and compiled.

And sure, it could also be rewritten in C++ to similar effect, but remember: C++ is one of the most mis-taught programming languages in the world. Even though C++ has smart pointers that take care of most of the potential memory safety hazards, and has static analysis tools to demonstrate (a lack of) memory safety, people aren't taught them. And the perceived responsibilities that come with programming in C++ scare the crap out of devs who've spent their whole careers programming for environments that manage your resources for you.

...I should start a blog.

-Albatross

[zapshe]

Why have you been coding in Rust? Job, curiousness, etc.?

https://www.quora.com/How-is-Rust-RAII-principles-in-comparison-to-C++-RAII

[Albatross]

Protip: Quora, like any community of self-proclaimed "experts" with no validation, is a dubious source at best.

No, heap memory allocation isn't recoverable if you're using Rust's standard library to do it. One can argue about how practical it is to allow attempts at recovery from OOM as a core language feature (personally, I think they should have), but ultimately, if being able to recover from failed heap allocations is important, you don't need to use the standard library's facilities for allocating memory. Besides, odds are that you'll want to use a different allocator than your libc standard one anyway if you're doing something that memory-intensive.
EDIT: Misleading. See my post below.

Moreover, inheritance is not necessary for the concept of RAII to work (read: Rust has no classes in the way C++ does). Moreover, it's absolutely possible to have constructor-like functions in Rust that can fail on resource acquisition failure. It's actually a common idiom there, just that errors are handled differently than throwing an exception.

As for why I program in Rust, it's because I have no deep-seated loyalty to any one set of tools, and Rust offers me a bunch of things that are on my C++ wishlist. Some of them C++ either might get or will get in the future, like pattern matching or a de-facto standard package manager. Others are too fundamental, like more sensible default behaviors or not having classes in the traditional OOP sense.

That's not to say Rust is a better C++. It's not. There are some things about the language and its ecosystem that I hate, and there are some things that C++ does that I regularly find myself missing in other languages. I also don't program in Rust exclusively, and not even to the exclusion of C++.

-Albatross

[zapshe]

Protip: Quora, like any community of self-proclaimed "experts" with no validation, is a dubious source at best.

Imagine me thinking otherwise when looking up Hinduism and their top answer is an Ode to Brahman.

Well, if you like it! I don't think I'd be able to code with Rust without criticizing. I do love my C++. I've been coding in C# lately, but I also found myself missing some C++ features that were simpler or more expedient. Maybe I'm just to use to taking a C++ style approach.

[Thomas1965]

coding in C# lately, but I also found myself missing some C++ features that were simpler or more expedient.

What are you missing?

[zapshe]

Mostly I'm miss understanding 😂. Something like std::count has a replacement in C#, works oddly to me. I miss vectors, C# has me on the fence with arrays and lists - I'm not use to them and so I'm not using them to their full advantage. I miss string streams, I don't know if C# has something equivalent. I also miss cout << and cin >>, they felt more expedient to work with, though I really like String.Join !

[Thomas1965]

The equivalent to vector is List in C#:

List<int> numbers = new List<int> { 1, 2, 5, 2, 3, 4, 5 };
Console.WriteLine(numbers.LongCount((x)=> x ==5));

I miss string streams, I don't know if C# has something equivalent.

C# has MemoryStream, StringReader and StringWriter.

[helios]

C#'s modern method of string construction is miles ahead of anything that's possible in C++. It's a combination of the expediency of printf()-style formatting without losing type- or memory-safety. For example, Console.WriteLine($"Hello, my name is {name}. The current time is {DateTime.Now}");. What that does is automatically construct the format string and call string.Format() for you, while passing each object's ToString()'s return value. Obviously, the result is a string that you can do anything you want with, not just send it to the console.

In C#, string streams are MemoryStreams, and they deal with bytes instead of characters. Characters are handled by building a StreamReader or a StreamWriter with the correct encoding on top of a Stream. IMO this is a saner method than what iostreams does, although I don't like that Streams are for both input and output at the class level and you need to query their capabilities when you receive them (CanRead, CanWrite, CanSeek). I think having InputStream, OutputStream, and IOStream would have been better and would have more readily facilitated self-documenting code.

[zapshe]

Got a lot to learn about C# and string manipulation! Thanks for the insight, I'll be sure to mess around and code with some of these things.

So far, I've only used C# for Clash of Code in Codingame.com (winning is addictive!). But since they're limited on time, I end up coding something that's just like C++ rather than taking advantage of C#'s capabilities. I'll solve some puzzles instead :3

Thanks again, really helpful info!

[mbozzi]

C#'s modern method of string construction is miles ahead of anything that's possible in C++.

The C++20-equivalent is roughly

std::format("Hello, my name is {}. The current time is {}", name,
  std::chrono::system_clock::now());

Much improved.

[Cubbi]

Albatross wrote:

Protip: Quora, like any community of self-proclaimed "experts" with no validation, is a dubious source at best.

I wrote that quora answer. Indeed I have no Rust experience. I'm familiar with the C++ side of things though.

Albatross wrote:

it's absolutely possible to have constructor-like functions in Rust that can fail on resource acquisition failure. It's actually a common idiom there, just that errors are handled differently than throwing an exception.

As far as I've seen, the "common idiom" in Rust is to panic, and maybe provide a non-panicking alternative that nobody uses, e.g. thread::spawn vs thread::Builder::spawn. This kind of approach is exactly why in C++ world, most open-source libraries are off-limits when writing software that needs to survive OOM or other resource-constrained conditions. Once something transitively uses glib or webkit, you're dead (their allocation functions terminate on OOM, providing alternative APIs that nobody uses). But standard library and some other high-quality libraries, so far, have been acceptable.

Albatross wrote:

odds are that you'll want to use a different allocator than your libc standard one anyway if you're doing something that memory-intensive.

OOM handling is not about being memory-intensive, it's about reliability (servers that don't die from large/hacked requests), transactional integrity (every sane database e.g. postgres), preserving unsaved user data, and many other aspects of software engineering.

[zapshe]

The C++20-equivalent is roughly
std::format("Hello, my name is {}. The current time is {}", name,
std::chrono::system_clock::now());

Much improved.

Wow, that looks really nice. Can't get it to compile anywhere I use it though, will have to wait for updates I guess.


I personally can't see where Rust would have a specific advantage over C++ if you're dealing with a programmer who knows what they're doing.

[Albatross]

To clarify, my statement was aimed at Quora as a whole, not at any particular individuals on Quora. That said, I do partially retract it: upon doing some research, turns out Quora does do some answer quality assurance (as it were). They're just not nearly up-front about it as the Stack Exchange sites (and many forums) are, which makes it harder to build trust in the responses there.

Cubbi wrote:

As far as I've seen, the "common idiom" in Rust is to panic, and maybe provide a non-panicking alternative that nobody uses, e.g. thread::spawn vs thread::Builder::spawn.

That has not been my experience. The "common idomatic" approach I was referring to was to use Result (I'll get to my thoughts on the standard library not always using it below). That general practice isn't limited to Rust, but is fairly common among all functional programming languages that provide a single standard way of doing something similar. And most well-designed libraries that I've used have been religious about it.

That said, there absolutely is a lot of panic abuse in Rust, and when I said earlier that there were some things about the language that I hate, that's definitely one of them. It's like assert abuse all over again.

Cubbi wrote:

This kind of approach is exactly why in C++ world, most open-source libraries are off-limits when writing software that needs to survive OOM or other resource-constrained conditions. Once something transitively uses glib or webkit, you're dead (their allocation functions terminate on OOM, providing alternative APIs that nobody uses). But standard library and some other high-quality libraries, so far, have been acceptable.

So there are four saving graces to Rust's panics, which is why I call Box::new()'s behavior questionable instead of downright broken:

* Panics are thread local.
* Panics unwind the stack. Destructors still get called in reverse order on panic.
* For safety-critical applications, Rust's standard library allows you to either react to panics (with set_hook) or catch them entirely (with catch_panic or catch_unwind).

The fourth one takes explanation. Panics can be changed to not unwind and instead abort, with all the explode-the-world things that entails. Doing so requires explicitly opting in to a specific feature of the standard library, which is incompatible with a complementary feature that guarantees that panics unwind. In short, we get compile-time checking for if a library a safety-critical application transitively uses would abort on panic.

AFAIK there have been some slow efforts to add a way to more elegantly recover from OOM problems (specifically, as opposed to any other panics) without changing the API of Box::new(), but none of them have landed yet. That's what I meant when I said that OOM wasn't recoverable, and I'm sorry for being misleading.

Cubbi wrote:

OOM handling is not about being memory-intensive, it's about reliability (servers that don't die from large/hacked requests), transactional integrity (every sane database e.g. postgres), preserving unsaved user data, and many other aspects of software engineering.

Maybe I wasn't clear on what I meant. I didn't mean to imply that memory-intensive programs are the only ones likely to face OOM, only that the class of programs most likely to run into OOM issues are also the ones most likely to NOT use the default Rust facilities for heap allocation. Apologies.

zapshe wrote:

I personally can't see where Rust would have a specific advantage over C++ if you're dealing with a programmer who knows what they're doing.

Except programmers cannot be trusted to always know what they're doing at all times. Even excellent programmers have bad days. That's why we do code reviews. That's why we do automated code testing, and coverage checks to make sure those tests are as complete as possible.

But Rust is not a single-issue language. It tries hard to be pleasant to use for people who've gotten a taste of what functional programming can offer. Generic traits are more or less type classes. Enums are full-blown algebraic data types with pattern matching and de-structuring. Most containers in Rust are at least somewhat monadic. Most expressions in C++ that don't have a value do in Rust. In short, once you get used to its syntactic differences and having to express your ownership model in code, it can be very pleasant to use. And yes, that's a valid reason for wanting to use a language. Else nobody would use Ruby.

-Albatross