What's the point of rewriting from C# to Rust, as C# is performant enough and already has memory safety? What will offset the huge rewrite cost?
Also, at the scale of Microsoft’s core global services, when you are paying for the processing, fast enough (or “CPU efficient enough”) isn't the same as with common apps. Even small efficiency gains are going to yield sufficient savings to be worth a fair amount of developer time.
That's not really true.
Like rust, C# is memory safe, although it comes at it in a very different way.
"safe" rust does inherently prevent a certain kind of race condition in multi-threaded code that C# does not, thought that's more of a nice incremental improvement, not a fundamental one -- i.e. it doesn't make your multi-threaded code thread-safe, but it does prevent a one type of thread safety violation.
Does C# have any kind of GC behaviour guarantees that are similar?
In case you forget the GC will call Dispose but it's entirely up to the GC when that happens, so personally I wouldn't say it's similar.
[1]: https://learn.microsoft.com/en-us/dotnet/fundamentals/runtim...
[2]: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
This actually has to be implement in the classes finalizer its not done automatically. The finalizer is called by the GC which if the designer chooses can call Dispose. This is usually done in well designed classes that use unmanaged resources.
Dispose and using give you the determinism if you want it and the finalizer gives you the backstop to prevent leaks if it makes sense.
So it's flexible, but there are footguns about, especially if you're wrapping a handle to something external.
1. https://learn.microsoft.com/en-us/dotnet/api/system.idisposa...
2. https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
I think you are making a point in the broader discussion of C# vs. rust, but that doesn't fit here. (And, personally, I don't care about that so have nothing to say on the topic.)
I don't know if anyone has really investigated why this is the case but it definitely is.
I believe .net Core has supported several forms of escape analysis for quite a while.
Could you elaborate? C# has a garbage collector for tracking resources.
Safe rust is safe from data races, but that's just one kind of potential thread safety issue -- one of the simpler kinds. It's not nothing, but not anywhere close to thread-safe.
For example, Rust lifetimes (this is also the case in C++ afaik) can be used to suitably scope the lifetimes of mutexes, to have temporary folders which are deleted when they go out of scope, to require that a connection pool is destroyed _after_ the last connection inside it is returned, etc, etc.
Mostly, garbage collected language do a bad job of cleaning up objects which refer to resources held elsewhere. Java had persistent issues with direct ByteBuffers (which were wrappers around malloc (but not free!)). Locks are easily held too long. File handles are easily left open. And depending on your GC settings, that file descriptor that's holding a 10GB file around may not get cleaned up for hours.
Refcounted languages can be somewhat better, but they don't avoid the bug, they just mitigate the effects.
Despite other comments here, I see nothing in the post that says “we are moving away from C# and rewriting everything in Rust!”
Microsoft is using Rust in Windows as well. They have given examples of how. In that case, they are not “rewriting Windows” but rather targeting specific components that benefit from the characteristics of Rust. Those components are just part of the larger application that is still primarily written in C.
C# easily with C and therefore with Rust. They interoperate well. So it seems likely that MS is following the same plan and rewriting specific components of the larger system that would benefit from Rust.
until it isn't. At Microsoft's scale, I imagine performance is actually a major concern for certain pieces of applications.
At the scale of O365 it totally makes sense to look at a high performance non-GC language for your core systems that see the most traffic (I say this as a .Net dev).
One example I could think of is if it's currently a SaaS on Azure, but it needs to be portable enough for a version to run in a low end Arm IoT device.
Or if it's deployed to thousands of servers and taking excessive memory or CPU resources for a monitoring agent. Or GC freezes affecting other adjustments systems.
There are plenty of reasons to retire C# to Rust.