30 ms·
Microsoft seeks Rust developers to rewrite core C# code
- rubyfan 3y agoCan they start by not needing a multiple gigabyte download and admin rights to get the rust compiler to work on Windows?
- vijaybritto 3y agoIs that needed because the compiler accesses some higher privileged APIs?
- Measter 3y agoThe MSVC-based compiler doesn't come with a linker, so you need the MSVC build tools to get it. One of the ways to get the build tools is to install Visual Studio, which is fairly large.
- filiphorvat 3y agoYou don't need the whole Visual Studio installation, only MSVC build tools and Windows SDK. See here: https://rust-lang.github.io/rustup/installation/windows-msvc.html#installing-only-the-required-components-optional https://rust-lang.github.io/rustup/installation/windows-msvc...
- Narishma 3y agoThose are still huge though, for some reason.
- Thaxll 3y agoWhy would a compiler needs any privileges, it's like a text editor
- cerved 3y agoIn widows, you get bonus points if your program needs administrative rights
- vijaybritto 3y agoI don't know. That's why I'm asking
- itishappy 3y agoDoes C# not require a multiple gigabyte download and admin rights? FWIW I've gotten rust working with the GCC build tools on windows without admin rights, thought it's admittedly somewhat janky.
- metaltyphoon 3y agoNot C# doesn’t need multiple gigabytes and admin rights. Dotnet tooling != Visual Studio
- timeon 3y agoI upvote almost any post "in Rust" here (yeah that's me) but this story went bit too far. It was just one job posting and so many sites acts like MS is going to ditch C#.
- fortran77 3y agoThat’s funny because I downvote almost any “in Rust” post here! C# — and garbage collected languages in general — aren’t going anywhere. With the shift to Arm, languages compiled for a runtime interpreter will get even more important for Microsoft.
- xedrac 3y agoGiven your username I suspect you're quite a bit older. I've mentored several grey beards on Rust and they weren't at all happy about it, at first. After a few months though, they were some of its strongest advocates. It's hard to not love Rust when you realize just how much pain it saves you from.
- candiddevmike 3y agoWhat pain does it save most folks from that are using GC languages (as GP alluded to)? Genuinely curious.
- deleted 3y ago[deleted]
- williamdclt 3y agoGC _is_ the pain. Lots of use-cases where precise memory management is critical, or real-time guarantees are needed that are difficult with GC.
- nycdotnet 3y ago“The garbage comes from somewhere” -David Fowler
- bigtex 3y agoThere is a reddit post where a dotnet developer on the MSFT team details why they are moving certain processes to Rust. TLDR, it is all about performance that scale.
- atesti 3y agoDoes anybody have a link?
- bigtex 3y agoI will try to find it today if I have a chance. I think it was on cscareerquestions or dotnet.
- bigtex 3y agoHere is the reddit link, https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8lnf2/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8...
- thrownaway561 3y agoJust hire Yehuda Katz
- rahen 3y agoWhat'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?
- chiph 3y agoI suspect this is the .NET runtime + libraries, not applications written in C#.
- Merad 3y agoNo, they're looking at migrating some core Office 365 services to Rust. This is the job posting: https://jobs.careers.microsoft.com/global/en/job/1633482/Principal-Software-Architect https://jobs.careers.microsoft.com/global/en/job/1633482/Pri... 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).
- cebert 3y agoToo bad you have to be in the office 50% of time for that role.
- solarkraft 3y agoThat surprises me since I'd expect that you could get really far with hot path optimisation.
- adrr 3y agoNot sure microsoft’s problem is the language. Their frontend JavaScript code is bloated and slow. It makes office365 feel slow and there are so many bugs in the azure management tools. I assume the backend code has the same low quality.
- Merad 3y agoI imagine the goal here is to optimize MS' compute and hosting costs. The core pieces of O365 probably handle many billions of requests per day. At that scale even small optimizations can be worth millions a year in cost savings.
- gigatexal 3y agoWhy is MS so hyped on Rust? It’s good but doesn’t it have its caveats? It seems they’ve become Rust zealots.
- marcosdumay 3y ago> It’s good but doesn’t it have its caveats? Compared to C#, it's a low level language, where you have to be concerned with a lot of details. But then, I'd bet this is for replacing bad C# that does low level tasks, that nobody sane would write but MS pushed for anyway because they were hyping C#.
- tialaramex 3y agoOffice 365 is was introduced in 2010. So when it was created Microsoft had two reasonable options: 1. Accept the performance penalty from using a safe garbage collected language (such as their own C#) which is slower which may make the service less attractive and more resource hungry which means more expensive to run at scale. 2. Accept the correctness penalty from C++ which delivers good performance but will cause an endless stream of bugs, some very hard to diagnose. Rust makes this much easier, because you aren't paying the correctness penalty, your Rust will probably have the same or fewer correctness bugs as your C#, and yet you get the good performance you'd have wanted from C++. For a 2010 product Rust was not an option, but presumably at some point in the last say five years, Microsoft did the maths and worked out that unless they're killing Office 365 soon or somehow C++ magically becomes safe with no work, a transition to Rust is cost effective.
- jimberlage 3y agoMS has lots of battle scars from the security headaches they went through in the 2000s/2010s.
- 01HNNWZ0MV43FF 3y agoIn 2007 they were .NET zealots and now .NET is old guard
- 3y ago
- lucasRW 3y agoI can understand the move from unmanaged C to Rust for security reasons, but C Sharp to Rust ? Am I missing something here ?
- mmastrac 3y agoI love writing Rust, but I was really surprised by how difficult it was to find a job _actually_ writing Rust. I'm happy to see the increased activity in the space, but searching for a job in Rust is probably still 10x harder than C or C++. It worked out in the end, and I'm happy to be getting paid to be writing Rust every day, but I hope that the market for Rust jobs continues to grow -- ideally even faster than it has been.
- rockwotj 3y agoOn the reverse side of things, trying to find a C++ dev is usually harder than finding people who want to write Rust.
- secondcoming 3y agoYup, we were hiring C++ devs recently and it was quite common for candidates to mention Rust. Did they not read the job description??? Immediate red flag.
- jimbob45 3y agoAre you not a developer? Being proficient in one means that it will take very little time to transfer to the other. C++ and Rust have a great deal of overlap in that way.
- risyachka 3y agoIt only works one way though (at least in this case). If you know C++ you can quickly become proficient in Rust. But not the other way around.
- timeon 3y agoYeah C++ have steep learning curve compared to Rust.
- PartiallyTyped 3y ago
- bobajeff 3y agoI'm not totally sold on rust as a language but I have to admit the tooling and ecosystem is really nice. I'm noticing that I'm increasingly using more stuff built with it. I'm also not sold on zig either for many of the same reasons. I prefer my low level languages to be smaller like c. I think that might be true for languages higher level languages too. I just don't like to have to down a lot of documentation on hundreds of different features and concepts behind them.
- kiririn 3y agoThe tooling/ecosystem looks probably great for developers actively creating with it, but for developers ‘consuming’ it (downloading some foss from github and changing a couple of lines) it leaves a lot to be desired. Not being able to ‘apt install’ a working toolchain on Debian for example - it’s already too outdated after just a year
- tracker1 3y agoThat's pretty true of a lot of development tools on Debian.
- wslh 3y agoHi @dang, regarding HN karma, what happened to the karma points if a user posted the same article just twenty hours earlier? (◔_◔) [1] [1] https://news.ycombinator.com/item?id=39232275 https://news.ycombinator.com/item?id=39232275
- Sparkyte 3y agoI imagine it comes down to the handling of threads vs anything else. Technology is rapidly adopting the more cores strategy of technology since we are hitting some IPC limitations and in the server space more cores is better.
- munchler 3y ago.NET supports asynchronous code very well, so that hardly seems like a likely reason for rewriting in Rust.
- pdimitar 3y ago> .NET supports asynchronous code very well Work-stealing task schedulers?
- neonsunset 3y agoYes, and overall task-based code has been a basis for many APIs since .NET Framework 4.5 (2012), earlier async patterns existed before too. It is not in a frozen state either as each release sees improvements to asynchronous code execution (overall improving ThreadPool, reducing size of state machine boxes, experimenting with alternate underlying implementations like green threads experiment, the learnings of which have been carried over to runtime task handling experiment which will massively reduce the async overhead when it eventually finds its way into mainline runtime).
- neonsunset 3y agoMulti-core scaling (in particular within GC) is one of the strongest points of .NET (for example, Go used to have poor scaling on many-core systems (has this changed in 2024?) while in .NET the throughput would continue scaling linearly)).
- pdimitar 3y agoI really doubt that this is true, might be your bubble. Have you dabbled in Erlang/Elixir? Your standards would increase substantially if you did.
- TideAd 3y agoI find this very strange, Microsoft has a lot of big internal high-performance services written in C#. You have to be intentional about some things - largely making sure objects are very short-lived or very long-lived, to avoid long GX pauses. But .NET performs much better than it did 10-15 years ago and I can't think of a fundamental reason why you'd rewrite in Rust.
- dtx1 3y agoMight not be all about performance but about security aswell.
- zozbot234 3y agoThe Rust folks are working on experimental codegen for the CLR https://fractalfir.github.io/generated_html/rustc_codegen_clr_v0_1_0.html https://fractalfir.github.io/generated_html/rustc_codegen_cl... leveraging the existing CIL/CLR support for "unsafe" languages. Once that work is complete, you should be able to rewrite C# code to Rust on a very fine-grained basis (a single function at a time or thereabouts), just like you can when porting C to Rust. Of course, you'll also be able to remove the CIL/CLR dependency altogether if you're left with 100% Rust code, and compile to a binary just like in ordinary C/C++.
- jasonjmcghee 3y agoAre there any rust books that have the focus of “ok you are productive in rust, this is what you should know / do to write proper rust”? Edit: ok found https://github.com/sger/RustBooks https://github.com/sger/RustBooks Any specific recommendations?
- sn9 3y agoIt sounds like you want Rust for Rustaceans: https://nostarch.com/rust-rustaceans https://nostarch.com/rust-rustaceans
- jasonjmcghee 3y agoThank you
- BradfordBob 3y ago[dead]
- psuresh 3y agoExpect MS own clone of rust like C#(for java) or typescript (extended js) in future
- tracker1 3y agoI think they already have this internally. That said, I believe they already have board seats and are large contributors to the rust foundation.
- atesti 3y agoDoes anybody know more about the "Substrate App Platform group"? As far as I understood it, actually Microsoft Exchange and ESENT powers a lot of Office 365, e.g. the compliance tools, the search and e.g. teams chats. Next to it is another pillar: Sharepoint, which is also exposed as OneDrive and is based on SQL server. Is substrate or has it been part of Exchange?
- bigtex 3y agoHere is a link to a user on reddit claiming to work at Microsoft going into more detail, https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8lnf2/?utm_source=share&utm_medium=web2x&context=3 https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8...
- WuxiFingerHold 3y agoBelow some background from a Microsoft employee (https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8lnf2/?context=3 https://www.reddit.com/r/dotnet/comments/1aezqmg/comment/ko8...): Makes perfectly sense. Rust is a replacement for ultra performance sensitive parts that might have been written in C/C++ before, but not a replacement for C#. --------------------------------------------------------------------------------------------------------- Hey there! I work at Microsoft. I can shed a bit of light here. We use .NET for TONS of things. Absolutely tons of different products and services. I'm on the Office 365 side of the business, currently managing Deployment for all of the hundreds of services that roll out across the world... And we use .NET extensively. I'm starting my new position managing a team that does routing next week. They have some things that are extremely performance critical. As others have pointed out, we're talking about supporting services and traffic literally across the planet. When it comes to optimizing, they will find ways to squeeze out what they can. There are languages like C and C++ that get used for some extreme use cases like I mentioned. Reducing as much overhead as possible in certain situations even leads to .NET apps with unmanaged pieces included with them. There's been a lot of hype around Rust, and for good reason. But it's a system language. It's not like Microsoft is about to go rewrite millions and millions of lines of code and toss out C# (for anyone getting nervous ). They're just being pragmatic and using an effective tool for the job. Hope that offers some clarity. ---------------------------------------------------------------------------------------------------------