I moved from C# to Rust, and comparison tables like in the guide are just nice.
With the code side by side you get to learn what each language does, even if you know neither of them. That gives you a perspective which just the book on Rust might not, or the book on C# might not.
Also I found myself amused at the section on classes, where it literally just says Rust doesn't have classes, only structs. And then the next section is on records, and it says Rust doesn't have any of that either.
I get that Rust is the new hotness, but I feel like they really address different segments, even post AI.
C# tooling for HTTP and gRPC web services is really, really good and very competitive performance wise. The large set of base class libraries and first party libraries that continuously get patched is a win, too.
Something that stood out in skimming the document was how close to parity the two languages seem to have in general, especially with things like Span<T> filling in a lot of the things that might have been "gaps" earlier in C# history. Knowing Microsoft's historic biases and wars, a part of me is wondering if this document is something of a trojan horse for the opposite conversation, trying to sell more Rust users that C# can be a "system's language" today when a Rust mindset is brought to it.
Especially the "unfair" comparison of the document sticking as much to the BCL as possible and trying to avoid NuGet packages, but needing cargo packages for a lot of the side-by-sides, seems to favor C# for some types of programming.
It's great that C/C++ developers are finally starting to see the light and moving to Rust. Maybe Rust is finally the bridge from C/C++ to C# that Microsoft has historically been missing and has been the source of some internal wars at Microsoft.
Microsoft has invested in Rust for a very long time, and uses it themselves in production. I really doubt they are trying to get Rust folks to move to C#.
Yet, C# creator gets to chose Go for Typescript rewrite, CoPilot runtime rewrite to Rust apparently was driven by the same Stephen Toub from .NET fame.
Apparently in both cases one of the reasons was Native AOT wasn't up for the job, which would have been good use cases to prioritise which tickets to care about.
Because the TypeScript runtime is not a web app? What part of my statement did not connect?
Likewise, the reason for the Copilot SDK to move to Rust is that it compiles to native binaries with no runtime and the FFI can interface with all of the supported SDK languages cleanly. Don't just read the headline; ready the actual post as well.
> ...Porting that runtime layer to 100% Rust, resulting in a pure native binary exposing a C ABI for in-process consumption by all the language front-ends
C# AOT is relatively nascent and not yet propagated through all of the ecosystem and thus is not a great choice for scenarios where the goal is a native binary with no runtime. Hejlsberg also cited the same reason for the TypeScript runtime. IMO, this is not C#'s strong point and sweet spot; sweet spot is web API backends.
Read my assertion carefully: web APIs are C#'s sweet spot. CLI apps, multi-platform SDKs -- makes total sense to use Rust.
Would love more specifics because I think this is an area where C# shines especially with hot reload. Even better if you wire it with CSharpRepl (no rebuild at all).
Comes across as Microsoft sending a subliminal type of message. Technically, C# developers should not need to give a care about Rust (unless they want to), but Microsoft looks to be "poking with stick" for unstated purposes.
I moved from C# to Rust, and comparison tables like in the guide are just nice.
With the code side by side you get to learn what each language does, even if you know neither of them. That gives you a perspective which just the book on Rust might not, or the book on C# might not.
Also I found myself amused at the section on classes, where it literally just says Rust doesn't have classes, only structs. And then the next section is on records, and it says Rust doesn't have any of that either.
I get that Rust is the new hotness, but I feel like they really address different segments, even post AI.
C# tooling for HTTP and gRPC web services is really, really good and very competitive performance wise. The large set of base class libraries and first party libraries that continuously get patched is a win, too.
Something that stood out in skimming the document was how close to parity the two languages seem to have in general, especially with things like Span<T> filling in a lot of the things that might have been "gaps" earlier in C# history. Knowing Microsoft's historic biases and wars, a part of me is wondering if this document is something of a trojan horse for the opposite conversation, trying to sell more Rust users that C# can be a "system's language" today when a Rust mindset is brought to it.
Especially the "unfair" comparison of the document sticking as much to the BCL as possible and trying to avoid NuGet packages, but needing cargo packages for a lot of the side-by-sides, seems to favor C# for some types of programming.
It's great that C/C++ developers are finally starting to see the light and moving to Rust. Maybe Rust is finally the bridge from C/C++ to C# that Microsoft has historically been missing and has been the source of some internal wars at Microsoft.
Microsoft has invested in Rust for a very long time, and uses it themselves in production. I really doubt they are trying to get Rust folks to move to C#.
Span as concept traces back to Xerox PARC influence, in languages like Cedar, Modula-3 and co.
C# is getting its memory model revisited, in a refactoring similar to how Swift 6 went through, both caused by Rust's adoption.
Yet, C# creator gets to chose Go for Typescript rewrite, CoPilot runtime rewrite to Rust apparently was driven by the same Stephen Toub from .NET fame.
Apparently in both cases one of the reasons was Native AOT wasn't up for the job, which would have been good use cases to prioritise which tickets to care about.
Because the TypeScript runtime is not a web app? What part of my statement did not connect?
Likewise, the reason for the Copilot SDK to move to Rust is that it compiles to native binaries with no runtime and the FFI can interface with all of the supported SDK languages cleanly. Don't just read the headline; ready the actual post as well.
C# AOT is relatively nascent and not yet propagated through all of the ecosystem and thus is not a great choice for scenarios where the goal is a native binary with no runtime. Hejlsberg also cited the same reason for the TypeScript runtime. IMO, this is not C#'s strong point and sweet spot; sweet spot is web API backends.Read my assertion carefully: web APIs are C#'s sweet spot. CLI apps, multi-platform SDKs -- makes total sense to use Rust.
C# AOT exists in various forms since .NET 1.0, starting with NGEN, Native AOT is only the very last implementation from a series of attempts.
Here is a .NET example of writing node.js extensions in C#, from Microsoft themselves.
"Writing Node.js addons with .NET Native AOT"
https://devblogs.microsoft.com/dotnet/writing-nodejs-addons-...
When .NET team complains about lack of adoption in podcasts, they could start with their own former team members.
Sure it has existed, but it's lack of maturity was explicitly cited by Anders as a gap.
Which probably would have been a priority 1 ticket instead in the Steve Balmer Microsoft days.
Why?
I'm C# Dev that'd want to learn Rust at some point and such guide makes it very helpful
Do you need to learn Rust to use it at this point?
I think the tooling matters more than the language at this point.
Job opportunities
idk, rust is really good for web services. it depends on your taste obviously but i prefer it to C#.
Would love more specifics because I think this is an area where C# shines especially with hot reload. Even better if you wire it with CSharpRepl (no rebuild at all).
I'm a fan of explicitness and less magic, so the approaches that rust ORM's take, as well as frameworks like axum, I prefer it.
Serialisation with serde is top-notch imo. Equivalent approaches in C# or Java are strictly worse.
Axum's approach to dependency injection is clear, obvious, and mostly free of footguns.
Yes you end up gluing multiple libraries together instead of ".net" but I also prefer that.
I really like C# the language but .net is too full of crud, over-reliance on OOP, and the culture is not there imo.
Somehow Rust makes building web services really great for my set of values.
Comes across as Microsoft sending a subliminal type of message. Technically, C# developers should not need to give a care about Rust (unless they want to), but Microsoft looks to be "poking with stick" for unstated purposes.
And here I was hoping for Rust support in Visual Studio.
Most likely it will never happen, unless too many key customers ask for it.
https://learn.microsoft.com/en-us/windows/dev-environment/ru...
https://code.visualstudio.com/docs/languages/rust