Rendered at 21:42:06 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
special_bread 3 hours ago [-]
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.
CharlieDigital 2 days ago [-]
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.
WorldMaker 1 days ago [-]
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.
pjmlp 13 hours ago [-]
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.
pjmlp 13 hours ago [-]
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.
CharlieDigital 12 hours ago [-]
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.
pjmlp 10 hours ago [-]
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.
When .NET team complains about lack of adoption in podcasts, they could start with their own former team members.
CharlieDigital 8 hours ago [-]
Sure it has existed, but it's lack of maturity was explicitly cited by Anders as a gap.
pjmlp 7 hours ago [-]
Which probably would have been a priority 1 ticket instead in the Steve Balmer Microsoft days.
tester756 2 days ago [-]
Why?
I'm C# Dev that'd want to learn Rust at some point and such guide makes it very helpful
CharlieDigital 2 days ago [-]
Do you need to learn Rust to use it at this point?
I think the tooling matters more than the language at this point.
tester756 5 hours ago [-]
Job opportunities
slopinthebag 2 days ago [-]
idk, rust is really good for web services. it depends on your taste obviously but i prefer it to C#.
CharlieDigital 2 days ago [-]
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).
baranul 2 days ago [-]
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.
wronex 2 days ago [-]
And here I was hoping for Rust support in Visual Studio.
pjmlp 2 days ago [-]
Most likely it will never happen, unless too many key customers ask for it.
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.
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.
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.
C# is getting its memory model revisited, in a refactoring similar to how Swift 6 went through, both caused by Rust's adoption.
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.
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.
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.
I'm C# Dev that'd want to learn Rust at some point and such guide makes it very helpful
I think the tooling matters more than the language at this point.
https://learn.microsoft.com/en-us/windows/dev-environment/ru...
https://code.visualstudio.com/docs/languages/rust