Microsoft Seeks Rust Developers To Rewrite Core C# Code (theregister.com) 77
An anonymous reader shares a report: 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 tackle a platform move away from C#.
The job, a principal software architect for Microsoft 365, has responsibilities that include "guiding technical direction, design and implementation of Rust component libraries, SDKs, and re-implementation of existing global scale C# based services to Rust." According to the post, the job lurks within the Substrate App Platform group, part of the Microsoft 365 Core Platform organization. The Substrate does the heavy lifting behind the scenes for Microsoft's cloud services, making a rewrite into Rust quite a statement of intent. Microsoft said: "We are forming a new team focused on enabling the adoption of the Rust programming language as the foundation to modernizing global scale platform services, and beyond."
The job, a principal software architect for Microsoft 365, has responsibilities that include "guiding technical direction, design and implementation of Rust component libraries, SDKs, and re-implementation of existing global scale C# based services to Rust." According to the post, the job lurks within the Substrate App Platform group, part of the Microsoft 365 Core Platform organization. The Substrate does the heavy lifting behind the scenes for Microsoft's cloud services, making a rewrite into Rust quite a statement of intent. Microsoft said: "We are forming a new team focused on enabling the adoption of the Rust programming language as the foundation to modernizing global scale platform services, and beyond."
A Rust-y Approach (Score:5, Funny)
Re: A Rust-y Approach (Score:5, Insightful)
Nothing succeeds like a full rewrite.
Guaranteed success, can't fail.
Re: (Score:2)
Unfortunately that appears to be the delusion a lot of browser development teams work under.
Re: A Rust-y Approach (Score:4, Insightful)
Nothing succeeds like a full rewrite. Guaranteed success, can't fail.
Personally I'm usually not happy until about the 3rd full rewrite.
Re:A Rust-y Approach (Score:4)
Re: A Rust-y Approach (Score:5, Insightful)
At least now there's a good reason. Just rewriting everything done in C# don't make sense, but rewriting parts where performance matters while being safer than C matters.
It could of course have been any other language as well, it just happened to be Rust that did fulfill the demands.
For performance I have however seen that the architecture matters more than anything else. It doesn't matter how sharp the language is if you have a bad architecture.
Re: A Rust-y Approach (Score:4, Interesting)
Re: (Score:2)
I'm one of the few people here who will argue that VB was an important tool, particularly for the time. It had a poor reputation, however, when it came to performance. Sure, by today's standards it was lightening quick, but no one back then would have believed it could beat a terminal app written in C.
I don't know what kind of horrors you found lurking in that old C program, but I suspect that modern developers would have felt right at home with it.
He ended up throwing a fit about the whole thing and refusing to ever talk to me again (for like 5 years.)
People used to feel shame and embarrassment when their sho
Re: (Score:2)
If performance is the issue, changing the language would have a minimal effect at best. The real area to investigate is changing the algorithm. Altering the Big O of the algorithm is where the gains are obtained.
Re: A Rust-y Approach (Score:2)
Discord famously switched from go to rust specifically for the performance gains. The most important gain was from ditching the garbage collector, but they already noted gains outside of GC pauses before they had even optimized their rust implementation.
Re: (Score:2)
In my opinion a garbage collector is just a tool for managing less than optimal memory management.
I started coding C on MS-DOS (that was masochistic) and then when I did malloc/free I did realize that the order that you do the free has to be exactly the inverse of the order you did malloc to avoid memory fragmentation. Otherwise the program suddenly couldn't allocate more memory because the pointer for free memory start had moved up in memory and wouldn't find the first free memory fragment. There was as I
Re: A Rust-y Approach (Score:2)
Re: (Score:2)
In MS-DOS it does. But for systems with more advanced memory management then it's not really an issue even though you'd get memory fragmentation. But if it works for MS-DOS it's no penalty when it runs on a more advanced system.
Local stack allocations do have some limitations. One is that you can't pass data between threads on a shared memory area as easily.
So both methods have their advantages and disadvantages.
Re: (Score:2)
When was the first rewrite?
hiring practices (Score:2)
Microsoft's hiring (and firing) practices don't lead to them hiring (and retaining) the best personnel, so they have to try to fix the problem technically.
GLWT.
Re: (Score:3, Interesting)
Indeed. Also, clearly their real problems are in architecture and design, so this will not fix anything, really.
A tacit admission... (Score:5, Insightful)
... that virtual machine languages are simply not up to it performance wise for heavyweight use. Not just C#, but Java 30 years after it was created is still relatively slow compared to modern C++ (no JIT doesn't help much except in specific circumstances) and a horrendous memory hog.
I'm a bit surprised they're going with Rust not because there's anything wrong with it per se, but because it seems the language is still at the dotting the i's and crossing the t's stage of its design. Modern C++ (read 2017 onwards) has pretty much all the advantages of Rust plus familiarity amongst devs and the dev tooling to go with it not to mention all the libraries available for it both public and no doubt internal to MS.
Re: (Score:2)
Re: (Score:1)
Kind of a moot point, isn't it? There aren't any virtual machine languages that perform as well as compiled languages.
If your point is that Java sucks ass, just not specifically because of the VM thing, then great. We can all agree that Java is a slow, horrendous memory hog.
Make native C# compilers (Score:3)
> virtual machine languages are simply not up to it performance wise for heavyweight use
Why couldn't they make a C# native compiler? It would compile C# directly to x86 or ARM machine code. That seems an easier to job than rewriting the top level app code.
Is it because some features assume byte-code? Reflection, I'm guessin'. But maybe only those parts need rewriting instead of everything. Depends on coding style I suppose. (Reflection is a language smell anyhow, in my book. Use real data structures, the
Re: (Score:3)
There have been several successful and not super successful efforts to compile C# more natively, but yes, those things you mentioned make it not so easy.
Re: (Score:2)
Re: (Score:2)
Yes, at some cost, I don't remember really.
I'd love to see an implementation that got rid of garbage collection altogether in favor of more deterministic implementation. Unity (3D) uses a weird version of C# called High Performance C# that has no classes, only structs, with no allocations, and so no GC but a very limited API surface.
HPC# works, but it's ugly. Really it just proves that Microsoft needs to just replace C# with another language. I personally like Zig, which compiles very quickly and is easy
Re: (Score:1)
Unity (3D) uses a weird version of C# called High Performance C# that has no classes, only structs, with no allocations, and so no GC but a very limited API surface.
I'm not sure if I understand you correctly, but Unity most certainly does use garbage collection:
https://docs.unity3d.com/Manua... [unity3d.com]
And classes:
https://docs.unity3d.com/Manua... [unity3d.com]
MonoBehavior, GameObject and ScriptableObject are base classes practically every Unity game inherits. You can use plain C# classes as well but they cannot reference in-game objects (but game objects can include/call them).
Re: (Score:2)
They have an alternative API for high performance that uses HPC#.
Re:Make native C# compilers (Score:4, Informative)
Re: (Score:1, Informative)
C++ has undefined behavior and inconsistencies abound (error prone). Also, the exceptions mechanism doesn't make it a particularly useful systems programming language. Oh, yes, you can turn exceptions off, but in such cases there's no viable replacement and you simply get something useless when otherwise an exception would have occurred. Also, have you ever had the luxury of debugging templates or macros?
Rust, has none of the issues of C++, with everything that made C++ good implemented the right way. With
Re: (Score:2)
Re: A tacit admission... (Score:3)
Huh? What are you babbling about? The exceptions mechanism has nothing to do with systems programming, it's purely a language feature. In *nix all system errors are passed by an API function return code or a signal.
haha goodbye Rust team (Score:4, Interesting)
Rust isn't standardized, Microsoft will take effectively it over and make their version of it... just like C-sharp it'll be a MIcrosoft thing.
bye bye Rust
Re:haha goodbye Rust team (Score:4, Interesting)
TBH its about time *someone* standardised it. Rust has the potential to be a fine language but the constant changes arn't doing it any favours.
Re: haha goodbye Rust team (Score:2)
What are you even talking about? The only thing that really changes at all is the ABI. Additions to the language are made but they never break anything. Everybody basically just uses the C ABI if they even need one at all, which is easy to do in rust, all you really have to do is add repr and no_mangle tags to whatever structures and functions you want to expose.
Re: (Score:3)
Re: (Score:3)
Agreed mostly. I think Rust team learned from looking at the glacial pace of C standards and their failure to address issues vs. the infamous Python 2.x/3.x leap and have struck a good compromise.
None of that bars the possibility of MS Rust becoming a thing, and developers needing to maintain an ever-growing file of Rust's equivalent of #ifdef until it gets ugly; but at least for now it seems like there's enough community outside of MS for that to not be a thing. The other FAANG 800 lb. gorillas probably
Re: (Score:2)
Re: (Score:1)
But the G is an A? MAAAN, ANAMA, MANAA. All these could be one. Also these last two sentences were for the caps filter, its like YELLING.
Re:haha goodbye Rust team (Score:5, Insightful)
I think Rust team learned from looking at the glacial pace of C standards
That "glacial pace" is a very good thing if you're interested in very long-term stability.
vs. the infamous Python 2.x/3.x leap and have struck a good compromise.
Python still makes endless breaking changes. Some of us need our code to last longer than a neglected houseplant.
Re: haha goodbye Rust team (Score:2)
That "glacial pace" is a very good thing if you're interested in very long-term stability.
Rust hasn't sacrificed anything there.
Re: (Score:2)
Rust isn't even ten-years-old. You have no idea what you're talking about.
Re: (Score:2)
Rust isn't even ten-years-old. You have no idea what you're talking about.
You're not supposed hyphenate that unless you're using it as an adjective. Nevertheless, if you count the 1.0 release, then sure, it's about 9 years old. However I have to ask, when has any backwards compatibility ever been broken? Examples please.
Oh wait, you're that guy who said he is tired of getting kicked in the face after he licks boots, after he just said there's a boot on my neck, or something. My gross income was $265k last year, and I just got a $12k pay bump last month with another one coming thi
Re: (Score:2)
I have to ask, when has any backwards compatibility ever been broken? Examples please.
That wasn't my claim, but whatever. It happened almost immediately. Between 1.0 and 1.1 [github.com]
My point, obvious to everyone with an IQ above room temperature, was that Rust isn't old enough to make any claims about long-term stability.
Like I said, you have no idea what you're talking about. You need to learn your place, close your mouth, bow you head, and listen to your betters.
Re: haha goodbye Rust team (Score:2)
My point, obvious to everyone with an IQ above room temperature, was that Rust isn't old enough to make any claims about long-term stability.
And my comment remains the same: Rust hasn't sacrificed anything here. That bit you linked to had an opt-out mechanism (no longer even relevant at that per the edition marker) and caused all of nobody to have to make any significant changes. C++ can't even claim that. Besides, what is your goalpost for "long enough"?
Like I said, you have no idea what you're talking about. You need to learn your place, close your mouth, bow you head, and listen to your betters.
So then why are you even here? Aren't you supposed to be licking something right now? It's not my fault you keep getting kicked in the face per your own admission. You chose to do that after all
Re: (Score:2)
And my comment remains the same
That's because you're really stupid.
Again, you don't know what you're talking about here.
So then why are you even here?
To remind you that you're ignorant trash and to let other people know that your "opinion", like everything else about you, is worthless.
Re: (Score:2)
That's because you're really stupid.
Again, you don't know what you're talking about here.
I see that you love making claims that you can't substantiate.
To remind you that you're ignorant trash and to let other people know that your "opinion", like everything else about you, is worthless.
Yet obviously some people value my time a LOT more than anybody at all values yours. That's not an opinion either, that's just a fact.
Re: (Score:2)
I see that you love making claims that you can't substantiate.
I've more than proven my case here. That you can't see this is just more evidence that you're an idiot who doesn't know what he's talking about.
You've lost. Move on. Preferably to some other site.
Re: (Score:2)
I've more than proven my case here.
As always, you haven't proven shit here. Just like that time you tried redacting your self-admission to being tired of getting kicked in the face after licking boots.
Re: (Score:2)
You're only highlighting your own ignorance here.
Listen to your betters and stop posting about things you clearly know nothing anything about.
Re: (Score:2)
Listen to your betters and stop posting about things you clearly know nothing anything about.
So why do you keep posting then?
Re: haha goodbye Rust team (Score:2)
That's Enterprise tier FUD.
Re: (Score:2)
> bye bye Rust
Hello Rust#
Rust vs C++ (Score:4, Insightful)
Re: (Score:3)
Parallelization is almost impossible in C++?
Interesting.
Re: Rust vs C++ (Score:4, Informative)
The best way to describe it:
C++ makes it easy to get horribly wrong
Rust makes it easy to get it right
Re: (Score:1)
Re: (Score:2)
Once you intuitively understand Rust's borrowing rules, then you never run into any of that. In fact, you naturally just start writing code the way you were already supposed to be doing it in C++ but most C++ programmers don't, because in C++, RAII is very much an after-thought, so the "workarounds" you speak about basically don't even exist.
Re: (Score:2, Informative)
Parallelization is never a small step and implementing it is a minor part of getting it right. Anybody that struggles with that part has no business working with it at all. Methinks you have no clue what you are talking about.
Re: (Score:2)
Well, he teaches college students, so there's that. And he appears to suggest that "parallelization" is a function of "pointer correctness", whatever that means. Plenty of clues that you are right.
Re: (Score:2)
Thanks. Well spotted.
I think by "pointer correctness", he may be ineptly referring to concurrent data access and modification. You know, things like locking, prevention of deadlocks, avoidance of race conditions, maintaining data consistency, and a few other things critical to get concurrent code to work right. I have done it for production stuff that also had (soft) real-time requirements and quite a few people depending on it. This is _not_ easy to get right on the architecture and design level. Implement
Re: (Score:2)
The only thing you're mentioning that's not always straightforward to do in rust for beginners is avoiding race conditions. Everything else you can generally just do willy nilly, assuming you're not using a standard Mutex or RwLock you'll probably never even encounter a deadlock. There's no guessing or having to fetch documentation to find out if something is thread safe or how to use it in a way that's thread safe. If your code isn't thread safe, it literally won't even compile. If your data structure isn'
Re: (Score:2)
Nonsense. You obviously have no clue what deadlocks actually are and how they happen either. And no, the compiler and run-time system _cannot_ prevent deadlocks. It can just not contribute any additional ones. You are a typical beginner or a low-skill moron with delusions.
Re: Rust vs C++ (Score:2)
Nonsense. You obviously have no clue what deadlocks actually are and how they happen either.
On the contrary, I was doing multithreading in my earliest days. Which admittedly was only about four years ago.
And no, the compiler and run-time system _cannot_ prevent deadlocks.
I didn't claim this. Learn to read.
It can just not contribute any additional ones. You are a typical beginner or a low-skill moron with delusions.
It's actually interesting you mention being a beginner, because relatively speaking, I am. Though I know what I'm talking about on this particular topic because only a year ago I wrote a server capable of receiving thousands of data pushes per second, doing (many) lookups against them, and commiting all of this to a database in, while also being able to handle pu
Re: Rust vs C++ (Score:2)
s/connection/contention/
Re: (Score:2)
Parallelization is never a small step and implementing it is a minor part of getting it right.
You've never done it in rust then. The borrow checker is specifically designed so that it's hard to do this wrong. The only way to easily pass data between threads (including green threads for concurrency) is the safe way to do it. You can either pipeline your data with channels, or use locks. Some structures (e.g. dashmap for parallel or flurrymap for both parallel and concurrent) can even guarantee* no deadlocks.
* There's one known way to cause it with flurry, basically you have to hold two refs to the sa
Re: (Score:2)
Utter nonsense. The C++ standard has MANY "correctness guarantees."
And zero guarantees for temporal memory safety, which is where the bulk of security vulnerabilities come from, and is also the biggest reason why NIST stipulates tossing C++ for any new projects, and many big companies have already done exactly that.
Re: (Score:1)
Check out
https://v8.dev/blog/retrofitti... [v8.dev]
Re: (Score:2)
I've seen something similar from both MS and Google. The TL;DR of all of that is that C++ is fundamentally broken, and you can try to work around it with different methods such as adding garbage collection, zeroizing data upon destruct, and other such measures that carry significant runtime costs, or worse, carry a lower cost at the (painful) expense of triggering a panic. Alternatively, modify the hardware so that it tags and/or zeroizes memory that has been freed so that it can't be reused (so instead of
The latest Lego language (Score:2, Funny)
C -> C++ -> C# -> Rust-> ???
What will the next one be? Will they fork Rust into Rust#?
Re: (Score:2)
I like Zig just because it's made for fast compiles.
Re: (Score:2)
Make it #Rust and be sure to take your tetanus shots.
How do you know a hype is over? (Score:3, Insightful)
When MS starts to join the bandwagon.
How about reimplementing .NET in Rust? (Score:5, Interesting)
New and Shiny (Score:3)
Re: (Score:3)
So what?
Java is the COBOL of the 21st century.
Python is the FORTRAN of the 21st century.
Haskell is the LISP of the 21st century.
C# is the PL/1 of the 21st century.
C++ is the C++ of the 21st century.
JavaScript is the Perl of the 21st century.
And Rust looks like it might become the C of the 21st century.
It is not about the novelty. It is about the size of the code base. If it is used widely enough, it will be impossible to get rid of.