Microsoft seeks Rust developers to rewrite core C# code

Microsoft's adoption of Rust continues apace if a posting on the IT titan's careers website is anything to go by. Although headcount at Microsoft might currently be down – by two percent compared to the previous year – recruitment persists at the Windows giant. In this case, the company is forming a team of Rustaceans to …

[abend0c4]

Quite a statement of intent

Personally, I wouldn't be contemplating a significant investment in replacing a relatively modern, working system with a functional equivalent unless I had misgivings about the ongoing support from the technology provider. Now, I realise there is a faddish determination in some quarters to pursue "modernity" for the sake of it, but I have a sneaking suspicion that a lot of Microsoft's customers will take away a rather different message.

[Abominator]

Re: Quite a statement of intent

I read this as both a faddish replacement (as you highlight) and also quite telling that they are ditching their own product that they sell commercially to other developers.

It's really quite shocking.

[Anonymous Coward]

Re: Quite a statement of intent

Yes I take it as a clear statement that C# is working well. Too well.

[m4r35n357]

Re: Quite a statement of intent

It was only there in the first place to kill Java - mission accomplished.

[RobLang]

Re: Quite a statement of intent

Java is still very much alive and I believe C# (or the CLR) was created not to kill Java but to make building Windows apps easier by abstracting away the Win32 API. Strangely, they've never really managed to succeed - I imagine C# is used more on web servers than for Windows apps.

[Anonymous Coward]

Re: Quite a statement of intent

Yes it was their second attempt to kill Java. The first was Visual J++ which was discontinued and replaced with C#.

[Anonymous Coward]

Re: Quite a statement of intent

> It was only there in the first place to kill Java - mission accomplished.

Java was killed by Larry.

C# could never have brought Java down if it were not for Oracle.

It was just a glorified VB/Java chimera. No ecosystem whatsoever (comparable to JSF and the FOSS community). Only used by MS partners (and ppl who think Microsoft is in the IT business).

Only kept alive today in the FOSS community thanks to Unity and a few others.

[Jason Hindle]

Re: Quite a statement of intent

An intent to use better-performing software to extend the life of bloody expensive hardware?

[Code For Broke]

Re: Quite a statement of intent

Am I mistaken, or isn't C# largely a creation of Microsoft's?

[Paul 195]

Re: Quite a statement of intent

Moore's law is no longer reliably delivering exponential performance increases from hardware, but the amount of stuff we want to run on computers goes up every year. At this point moving back from the abstract machine runtimes of C# and Java to native code looks like a savvy move to slow down datacenter's ceaseless appetite for electricity. I expect Rust and Golang to start creeping up the language charts as enterprises realise they can do more with less by switching to "faster" languages. GraalVM is a convincing attempt to do the same for the Java world.

[abend0c4]

Re: Quite a statement of intent

And the opposite argument is being used for server-side Javascript: because it's ubiquitous, the work done in improving performance means it's competitive with native code.

C# can be entirely pre-compiled and the compilers are entirely within Microsoft's control. Its performance, for example in web applications, benchmarks favourably.

I'd be very surprised if there were significant performance gains to be had from a language switch alone (if they're starting with a fresh piece of paper and the ability to remove a lot of legacy cruft that's a different matter, but even more risky). And at this stage in the game they probably don't have a huge pool of potential talent to call on.

[CowHorseFrog]

Re: Quite a statement of intent

Your statements about javascript performance are rather short sighted. For starters JS is single threaded, which means a VM for each CPU whch of coure means no global sharing of anything across cpus because each lives in its own VM.

[abend0c4]

Re: Quite a statement of intent

Not my argument - but it's one that's often made by proponents of Javascript. But the point remains that you can get surprising levels of performance even out of what were conceived as interpreted languages if you put in sufficient effort. You can even coerce unpromising candidates into multithreading (eg with worker-threads and async/await in Javascript), but that's not really relevant.

[fg_swe]

JavaScript "Performance"

What they do to speed up JS programs is: tracing execution with real data types and constructing a "typed" version of the program in the background. Then execute the typed version.

Obviously, this is LOTS of complex code. Lots of attack surface.

It would make much more sense to run some sort of strongly typed Pascal/Ada/Algol variant in the browser and have a straightforward, small compiler inside the browser.

With WASM they are pushing this decision to the developer. Now you can decide how much Memory Safety and Type Safety you want.

[CowHorseFrog]

Re: JavaScript "Performance"

fgswe: What they do to speed up JS programs is: tracing execution with real data types and constructing a "typed" version of the program in the background. Then execute the typed version.

cow: yes but in each actual requeset, the time in javascript code even if its compiled into native is a fraction of the total request.

A node server sending files, is spending v little time doing javascript, most is the OS or native code doing DB nd HTTP.

[ssokolow]

Re: JavaScript "Performance"

Plus, the elephant in the room with all these "high-level, in the 'let me focus on the business logic instead of machine details' sense" languages... it's very easy to fall off the fast path.

A statically typed GCed language like C# or Go will give the compiler more ability to say "Whoa, hold up there. Are you sure you meant that?" and something like Rust, C, or C++, where you explicitly choose things like inline/stack allocation vs. unique heap pointe vs. reference-counted heap pointer instead of letting automatic allocation handle it will do so even more.

(To be honest, my biggest complaint about Rust is that LLVM doesn't give them the APIs they'd need to viably make things like "this optimization used to get applied and now it doesn't" into a compile-time error.)

[CowHorseFrog]

Re: JavaScript "Performance"

You dont understand how to count the cpu time spent on the different layers. For basically all boring busines software, the time spent on any langage is easily surpassed by the other layers. The cost of the database query is far more your boring business logic in java or c# or go. It basically doesnt matter what langauge you use or its speed, there are other facts you have skipped.

[ssokolow]

Re: JavaScript "Performance"

You are aware that an application server will want to service more than one request simultaneously, right? Wasted cycles are wasted cycles... especially in this era of "bill for every CPU cycle" cloud services being popular.

[CowHorseFrog]

Re: JavaScript "Performance"

ssokolow:

You havent grasp my point. Im not denyong multithreading exists im simply stating that most of the cpu time is not in the application code. THe networking layer and database consumes far more than the your actual code.

[CowHorseFrog]

Re: Quite a statement of intent

abend: But the point remains that you can get surprising levels of performance even out of what were conceived as interpreted languages if you put in sufficient effort.

cow: I think you will find the perfomance of those systems is not because of javascript magic its because most of that cpu time is spent in native code.

Eg if you have a node CRUD system most of hte cpu time for every request is not in javascript, but native code for the http stuff, and prolly native code for the magic inside the db. The actual cpu in javascript doing your business logic or whatever is very small.

~

abend: ou can even coerce unpromising candidates into multithreading (eg with worker-threads and async/await in Javascript), but that's not really relevant.

cow: Like my above comment, most o fthat multi threading is actually native code, the javascript - aka your code is not multi threaded at all, at any time in that VM there is only ONE bit of javascript executing.

THeres a big diference between a c# or java where there are lots of eecuting threads sharing memory caches etc, something that cant and doent happen in js.

[CowHorseFrog]

Re: Quite a statement of intent

dont worry google will kill go before it becomes too popular.

[QD_Top]

Re: Quite a statement of intent

Won't Rust eventually have the same support issues?

[Richard 12]

Re: Quite a statement of intent

Rust is currently unsupported.

It's still in the exciting part of its lifetime when it changes and breaks existing code rather often.

C# is in the boring part of its lifetime when things can be added, but breaking changes have been banned for many years with huge amounts of existing code relying on that stability.

[CowHorseFrog]

Re: Quite a statement of intent

Most langauage changes are a joke and nonsense that simply supports slight more concise forms of another language feature.

- Eg the Diamond operator in java.

[avranju]

Re: Quite a statement of intent

> It's still in the exciting part of its lifetime when it changes and breaks existing code rather often.

Could you cite a source or provide some evidence for this claim? I have been a Rust developer since 2017 and my experience has been exactly the opposite - it is rather surprisingly good at backward compatibility and its "editions" scheme allows one to mix and match crates built with different major releases of Rust. Would appreciate any pointers you can provide that proves the contrary. Thanks.

[bombastic bob]

well, at least...

at least they are not porting their kernel and services to JAVASCRIPT... Office 362, jokingly aside, would be bloated/inefficient enough already.

[This trend towards garbage-collected memory management things has no Moore's Law to compensate for the inefficiency any more]

But shifting C-pound to Rust is probably an improvement

[Psamathos]

Re: well, at least...

> [This trend towards garbage-collected memory management things has no Moore's Law to compensate for the inefficiency any more]

It's worth noting that while C# uses garbage collection, Rust does not. The Rust compiler does compile-time analysis of object ownership in order to achieve some of the same goals, but does so with deterministic performance and typically significantly better performance.

[Yorick Hunt]

Re: well, at least...

What is this C£ you talk about?

[ldo]

Re: What is this C£ you talk about?

No, it’s “C♯”. It’s “see-sharp”, not “see-hash”. So it shouldn’t be U+0023 NUMBER SIGN, but U+266F MUSIC SHARP SIGN.

[CowHorseFrog]

Re: What is this C£ you talk about?

Why does it matter ?

The purpose of communication is the audidence understands, not whether someone can use a funny unicode char.

[fg_swe]

Efficiency

Rust is much more efficient in the memory management area. No GC required, which makes it soft-realtime capable.

[CowHorseFrog]

Re: Efficiency

Rust may be more efficient, but programs and objects are written by people, and they need temporary objects to do whaetever.

[ssokolow]

Re: Efficiency

Which is what things like stack allocation are for, along with APIs designed to make reuse of heap memory without handing it back to malloc easy.

[Richard 12]

Re: Efficiency

And of course stacks end up in cache lines or registers, so such temporary objects are often never even written to main memory.

[CowHorseFrog]

Re: Efficiency

ssokolow: Which is what things like stack allocation

cow: Long lived objects are moved away from the stack. I would have thought that was obvious, for such an object to surivive it must be moved onto a heap.

[claimed]

Knee Jerk

Emails hacked. CEO (or whoever) says how do we avoid these shit bugs, CIO (or whoever) says Rust for a lot of things but that would be mad and not fool proof.

Mad, you say? “Something”, you say? Well we must do “something”!

Get Rust involved!

(I love Rust, but this is a knee jerk response for sure)

[Mr Mittens]

Re: Knee Jerk

Except the language had nothing to do with it. It was human error. Someone gave admin privileges to a test account which got accessed via brute force attack.

[claimed]

Re: Knee Jerk

That’s my point and why I called it knee jerk. If it was technically the right response, it wouldn’t be knee jerk

[yetanotheraoc]

2. Extend

Rust#

[ldo]

Re: 2. Extend

So, you think they will drive Rust, Inc out of business?

Oh wait, there is no “Rust, Inc” to be driven out of business.

[StrangerHereMyself]

Re: 2. Extend

I personally wouldn't mind a C-like Rust version. I thoroughly dislike the syntax of Rust.

[fg_swe]

Create Yourself

Just create your own little YourSafeC->C transpiler. It can be done in pure C. Prolly less than 20kloc.

you can borrow some ideas from me: http://sappeur.ddnss.de/SAPPEUR.pdf

No need for a fancy scanner/parser generator. Handcode. Recursive descend parser. Slightly adapt the grammer of YourSafeC to make it easily parseable.

Erase what cannot be salvaged such as direct pointer incrementing, free(), the cr4ptastic string API and so on. Feel free to axe the crazy C stuff.

Devise a concept of threadlocal and threadglobal code types, etc.

Don't let id0ts from the internet weigh you down in this effort. There are lots of useless commenters out there, who will parrot some stuff they read somewhere.

[TheMaskedMan]

Would there be any performance benefit in using Rust compared to C#? Or is it just memory safety they're looking at?

[claimed]

Probably indistinguishable for web based services, but C# isn’t “to the metal”, there is a runtime interpretation layer that allows for portability. Technically Rust also has “Runtime” safety checks for specific kinds of operations, but Rust would have the edge.

Then you stick it at the end of a network socket and who gives a shit

[bazza]

One of the issues with C# (and other languages like it) is load time. Rust starts a lot quicker.

This kind of thing matters for some applications. If you’re constantly starting services on demand, the load time can be a significant overhead. Horses for courses…

[Mr Mittens]

As with anything it entirely depends on the application. Rust does, in general, load faster. The one thing that needs addresses though is the build time which is glacially slow.

[CowHorseFrog]

csharp is mostly for web apps these days ? Uses dont wait for web servers to startup...

[StrangerHereMyself]

No it doesn't. Not if you precompile it. I've done this more than a decade ago and the web application starts INSTANTLY.

There's certainly no reason to rewrite something in Rust for it to start quicker. And even if this were the case it still wouldn't matter because only the first person starting the web application would see a small delay. All other users would see the web application respond immediately.

[CowHorseFrog]

Nobody cares if your web app start in 1 or 2 seconds it doesnt matter.

[anoncow]

"Probably indistinguishable for web based services"

Probably easily noticeable. Garbage collection regularly causes huge latency spikes. Depending on how well the managed code application is written... usefully not very well.

[bazza]

Having a language that guarantees memory safety helps with multithreaded code. The Rust compiler can tell you if you have a memory fault across threads (through its ownership mechanism). C# doesn’t I think (corrections welcome!).

[fg_swe]

Indeed

Multithread-memory-safety is a huge problem in C and in C++. A lesser one, but still existing in Java and C#. A proper type system(MT-aware) can take care of this and automatically insert mutexes.

[ssokolow]

Re: Indeed

In Rust's case, it doesn't automatically insert mutexes. It instead says "Hold up. Did you mean to share this? If so, you'll need a mutex."

...because, sometimes, what you really want is to fix the bug that's causing it to keep a reference, so you can just send it to the other thread without sharing it.

Otherwise, you wind up with things like those JavaScript "something, somewhere, is still holding this alive when it shouldn't be" memory leaks.

[CowHorseFrog]

THere wouldnt be any simply because most developers are rather pathetic and doing many things wrong. The last thing one needs to worry about is a few percentage points when they are screwing many other things up.

[ssokolow]

Predictability

Here's the most recent This Week in Rust featured quote:

The sheer stability of this program is what made me use rust for everything going forward. The social-service has a 100% uptime for almost 2.5 years now. It’s processed 12.9TB of traffic and is still using 1.5mb of ram just like the day we ran it 2.5 years ago. The resource usage is so low it brings tears to my eyes. As someone who came from Java, the lack of OOM errors or GC problems has been a huge benefit of rust and I don’t ever see myself using any other programming language. I’m a big fan of the mindset “build it once, but build it the right way” which is why rust is always my choice.

-- https://www.reddit.com/r/rust/comments/1ach3ir/what_were_some_of_the_first_useful_applications/kjuhaox/

Memory safety isn't the only thing under the heading of "predictability" that Rust is good at. Implicit control flow is also a big one.

For example, NPM experimented with doing something similar with one of their Node.js-based services and kept the rewrites because, while they performed about the same as the hyper-optimized mature JavaScript codebase doing things Node.js had been tuned to be best at, they eliminated the flood of uncaught exceptions they were constantly working to track down in their log files.

[CowHorseFrog]

THe rest is prolly for the native runtime its not replacing any ch-shap.

[elsergiovolador]

Rockstar

Maybe the move is to attract young, brave, naive, rockstar developers with lack of real world experience to milk them dry.

Here is the new shiny object (Rust), now go to your cubicle and sell your soul for peanuts (at least until the next round of sackings).

[that one in the corner]

Re: Rockstar

> Maybe the move is to attract young, brave, naive, rockstar developers

Or to attract grey beards who have been pissing themselves with laughter over C-octothorpe since it appeared, by replacing it with something that demonstrably helps with memory management.

[elsergiovolador]

Re: Rockstar

Attract gray beards? I can picture gray beard getting a job there, getting to the car and then thinking oh well... jumping out and getting the garden hose to run car exhaust pipe through the car's window, close the garage door, go back into the car, run the engine and play THIS at full volume and slowly drifting away.

Seems like going back would be the ultimate failure.

[ssokolow]

Re: Rockstar

Whenever I see a hyperlink with some variation on "this" as the text, I assume Rick Astley will be on the other end and don't bother.

[Brian Miller]

Re: Rockstar

The move is always to attract developers and milk them dry. I have met very few developers there with real talent. The last time I worked there, I was chewed out over code I didn't write, and then told to "fix" exception handling in 50+ files in three days or be fired. Fixed them in two because I know regular expressions, and I can type.

I don't believe that Microsoft hires based on actual talent.

[QD_Top]

Re: Rockstar

The software equivalent of pump and dump.

[Anonymous Coward]

> Microsoft seeks Rust developers to rewrite core C# code

Good luck finding actual Rust developers.

The only "Rust" people I see are people talking about writing software in Rust. ;)

[trevorde]

Tomorrow's headline

Microsoft seeks Go developers to rewrite Rust core code

[ldo]

Re: Microsoft seeks Go developers to rewrite Rust core code

Funnily enough, it was Discord, I think that started out using Go for their back-end services. Then they did some benchmarks comparing it with Rust, and found the latter to be a lot faster. And so they switched from Go to Rust.

[fg_swe]

Makes Sense

Rust does not use GC, Go does. It is easy to generate huge GC load, which kills Cache locality and which consumes large amounts of RAM.

[ssokolow]

Re: Microsoft seeks Go developers to rewrite Rust core code

You're probably thinking of this Discord Blog post: Why Discord is switching from Go to Rust

[ldo]

The End Of Dotnet?

So, does this move away from the flagship Dotnet language mean that Dotnet, like on-prem Windows Server, is now sailing off into the sunset?

Microsoft itself never used Dotnet for anything important (e.g. Office 365) anyway. It seemed more like a Bill Gates vanity project than anything else.

[jeff_w87]

Re: The End Of Dotnet?

Let's hope. And don't forget the new support cycle where a DotNet LTS release is only good for 3 years. Maybe I'm old, but LTS should be good for at least 5 to 10 years so I don't have to keep re-writing my code due to the underlying DotNet no longer being supported and full of security vulnerabilities.

[Anonymous Coward]

Re: The End Of Dotnet?

Yes you are old. There is no longer any need for LTS, as CoPilot will automatically re-write your code for the new api's and any new language, and CI will automatically push the changes to production. Co-pilot for '365 will add any (and all) features marketing requests, parsing vaguely written emails into full requirement documents, and incorporating the changes.

(This has been smuggled out by "a friend")

[werdsmith]

Re: The End Of Dotnet?

Introducing Rust#

The basic idea will live on with Mono whatever MS decides. It’s in such things as Unity.

[StrangerHereMyself]

Re: The End Of Dotnet?

I do believe they've managed to make a Royal mess out of DotNet, but I consider it still to be the world's most foremost development platform.

They've done a great job screwing up the mobile and multi-platform stuff. They never got Xamarin.Forms to work properly even after more than a decade of development. And they keep renaming it to give themselves another shot at it.

[ldo]

Re: world's most foremost development platform.

And yet, like I said, nobody seems to use it for anything important, least of all Microsoft.

[StrangerHereMyself]

Re: world's most foremost development platform.

The Microsoft web site runs ASP.NET. And Office365 too is written in C# / .NET which is a substantial part of Microsoft's business these days.

I suspect only small parts of Azure are written in .NET but it wouldn't surprise me in the least if I'm wrong.

Also, .NET was never meant to be used internally but for customers wanting to write their own applications. Although it has found some traction within the company. But Microsoft is still a C++ bastion and will remain so in the foreseeable future. Rust will slowly but surely replace C++, though.

[ldo]

Re: Rust will slowly but surely replace C++, though.

Except the article is about Microsoft looking for Rust developers to replace C♯ code. Presumably that would include your ASP Dotnet and Office 365 stuff.

[StrangerHereMyself]

Re: Rust will slowly but surely replace C++, though.

True, but they CURRENT site uses ASP.NET which negates your claim that it's not being used for anything important.

[ldo]

Re: CURRENT site uses ASP.NET

Does it indeed? Maybe it’s already been replaced.

[Caver_Dave]

AI

Do they not keep talking about AI tools to automate development?

Eat your own dog food and see how good the result it!

[Caver_Dave]

Re: AI

Got distracted by work!

And so new comment.

So Microsoft, use your own AI tools to auto generate the translated code.

[fg_swe]

New To Biz World ?

Do you seriously believe the marketing nonsense ?

AI has the intelligence of worms. In the order of 10k Neurons. Mankind has 100 000 000 000 neurons, with 10 000 Synapses EACH.

=> educate, train and treat your developers well !

[RobLang]

Rust is a good fit for some services where you don't want to have an always on API and instead want something that starts up really quickly. If you're using functions-in-the-cloud like AWS's lambda, that start up time matters and C# + .NET Core is slow to load. I think it's the right tool for certain jobs.

[fg_swe]

Bingo

Compiled-to-machine code, memory safe programs with a lean standard library are the natural successor to C and C++

[Robigus]

En R. Gee

C/C++/Rust use less energy (when running as opposed to compiling) for the same unit of work than the higher level languages. I saw a table demonstrating where they consumed about 1/3 of the energy of C# and 1/75th that of Python - https://storage.googleapis.com/cdn.thenewstack.io/media/2018/05/3730357d-results-energy-time-and-memory-usage-screenshot-from-research-paper.png

I would have thought that on Microsoft's data-centre scale, this would be well worth doing. Going the Rust route, rather than the usual C++ will give them memory safety, (if they leave the guards in place)

[fg_swe]

Browser, Rust, WASM

Never tried myself, but this looks promising

https://betterprogramming.pub/get-started-with-wasm-in-rust-2347056bab4

Finally a browser language that does not automagically convert an integer into a double.

[StrangerHereMyself]

Why?

C# is a garbage collected language which is just as safe and much easier to program in that Rust (which implies greater developer productivity and lower costs). Also, C# developers are much easier to find and probably cheaper than Rust developers.

I support the transition to Rust for most C and C++ code, but migrating C# code to Rust is superfluous.

[fg_swe]

True ?

Is your statement true for accidental sharing of multithreaded data ?

Afaik, C# will do nothing to ensure serialized access, but Rust does.

Secondly, runtime costs are considerable for some applications. There is more to TCO than just developer time.

[StrangerHereMyself]

Re: True ?

I agree with you on that count. Writing multi-threaded C# code is similar in complexity to C or C++.

But it depends on what you're doing. Web applications are multi-threaded automatically in ASP.NET and you don't have to write locking code for it. It's all handled automatically by the ASP.NET runtime.

For standalone or console applications you would need to write multi-threading code and there are no guard rails for it.

[Richard 12]

Re: True ?

A highly probable assumption is that the ASP.NET runtime (or some other important part of the C# stack) has become an unmaintainable mess, and they want to remove their internal dependency on it before the last dev who understands it leaves.

[StrangerHereMyself]

Re: True ?

I don't believe Rust is intrinsically more maintainable or readable, but at least you can hack away in the code base without introducing any memory errors.

[Steve Channell]

worth reading the job description

Worth noting that the job advert is for the web-substrate for office - running in a browser. Rust is better than C# for web-assembly because it doesn't use a garage collector (C# downloads mono runtime). Rust is better for edge-security than C++ because it blocks unallocated read (that could reveal keys).

Rust has a bright future, but it's biggest impact is likely to be the open release of C++ code analysis tools that MS uses internally, and an alias for std::unique_ptr<T> ( T^ anyone?).

C# is now the undisputed fasted managed language, and TIOBE language of the year for good reason, but there are still situations where managed languages are not be best fit.

[StrangerHereMyself]

Re: worth reading the job description

I personally believe the latency spikes introduced by the garbage collection are overhyped. Yes, they occur, but for many tasks they don't matter. They're also in the tens of milliseconds range so most people won't even notice them.

[Bebu]

Cynic...

So finally microsoft developers will actually have to learn how to actually program? :)

Much suggests to me they haven't in the past so I am not going to asphyxiate myself in anticipation.

A hallucinating AI code assistant servicing a novice MS Rust coding hire - what can't go wrong?