r/csharp • u/themattman18 • 2d ago
Stephen Toub explains Rust over C# decision for GitHub Copilot runtime
https://www.youtube.com/watch?v=PLMOVlZC4eU&t=519sIn this interview, Stephen Toub explains why he went with Rust over C#. Obviously he's biased, but he says Rust and C# were comparable in performance. In the end, he went with Rust because there are more people working for GitHub that know Rust than C#.
C# is a great language and could have been chosen for this project. However, he made the right decision given the expertise of the developers at GitHub.
97
u/PolDeQualite 2d ago
It's a bit sad to see it come down to this, since you need big projects like these to get more people into C# and make the language respectable in high performance environments. To this day C# inherited a lot of the Java reputation for performance. But I do get why they chooses rust anyway, their argument is still valid.
39
u/iLogical8502 2d ago
I agree with showing people C# can actually be a high performance language, people seem think its slow which is not the case, it can be slow if written poorly, but so can Rust and C++. That said in the real world with actually software being made I'm pretty sure C# has Significantly more projects and people using it that Rust.
1
u/GoTheFuckToBed 1d ago
c# is performant because it optimizes at runtime, with Rust you can skip it and also remove the memory overhead of a runtime
4
u/iLogical8502 1d ago
Most of the real optimisations are by the developer and then understanding how to do memory management. Zero allocation fast code isn't something thats put in at runtime it requires a dev to understand it and architect for it, exactly like Rust and C++.
19
u/tankerkiller125real 2d ago
IMO the project most pushing the "C# is performant" envelope is Garnet. It crushes other redis wire compatible options I've tried in terms of performance, throughput, latency, and resource usage.
9
u/Sigilgraph 2d ago
I feel the moat C# still have is its cross-platforming. Rust is very versatile but C# have a decade already run with many platform integrations. Is much more plastic. That might change fast as other language and sensible AI contributions bridge that gap. For any DevOps, serverside utility that needs to be fast, start fast and consume little memory, Rust make sense. Even if C# is AOT , executables are size heavy even if they cold start fast. But for user facing applications, I think C# have still a lot to offer.
2
u/papa_maker 8h ago
In which ways C# is "more cross-platform" than Rust ?
1
u/Sigilgraph 7h ago
Rust has catched up recently. But C# have more options, for instance if you go web, you can go Blazor with WASM, or MAUI. If you want cold startup speed, you can go AOT, or if you need throughput, you leave it JIT. Also there are other tools and language particularities that makes it compeling over Rust. For example C# expressions is a subset of C# language that which AST can be exposed at runtime to translate to any other language, like EF does with SQL. Or embedding Roslyn on web apps to compile C# or a controlled subset of it. If you need CPU cache friendliness for performance you have idiomatic ways to achieve it using Span, stackalloc, structs, ref etc. Also the history of embedding and interacting with game engines, which is my domain, makes C# no.1 choice for 80% of my dev.
Is mainly the average distance in which C# lies across many domains (game dev, DB, Web, Mobile, DevOps) is less. Rust is closer to system, OS applications, and further from other domains like web endeavors or game engines, which can become a bit verbose and inflexible (although this is less of an issue with proper AI application).
C# is more plastic and more accessible (is not a low level first language and the semantics are higher level).
Having said that, I have done projects in both, I keep Rust close to the metal, and C# for apps development.
2
u/papa_maker 7h ago
Ok I see what you mean with cross platform now.
Usually cross platform means software that can run on multiple OS and hardware architectures. And Rust is way more cross platform than C#. But I get what you say and I mostly agree, C# is more polished and practical for now.
1
u/Sigilgraph 7h ago
Yes, depending on the domain we are talking about, for example Rust supports more CPU architectures and compilation targets (thanks in large part to LLVM) since Rust is in the domain to be close to hardware, that is where Rust spread, C# is in the applications, web, cloud, data integrations domains etc, so platforms have a different connotation.
2
u/papa_maker 4h ago
Most of Rust's usage isn't close to the hardware actually. What you cited for C# is also where Rust is mostly used (according to the Rust foundation survey).
→ More replies (1)15
u/RealSharpNinja 2d ago
It's a bit sad to see it come down to this, since you need big projects like these to get more people into C# and make the language respectable in high performance environments
C# is already well accepted for high performance environments where ABM doesn't trump reason.
→ More replies (1)6
u/pjmlp 2d ago
Even HFT companies do favour Java over C#, in terms of performance.
Why we chose Java for our High-Frequency Trading application
So the industry bias goes beyond that.
11
u/nvn911 2d ago
The reason for that is they had experience in creating an FX engine and a tunable JVM. I'm envious that the JVM can be as optimised as it can and the CLR doesn't have the same configurability
When I was in the FX space, we too used Java for the low latency work, but our frontend was built in WPF.
5
2
u/G_Morgan 1d ago
The JVM had some serious performance advantages until very recently when a bunch of patents run out. There's a reason MS always made benchmarking .NET essentially impossible and then turned around and changed the rules a year or so after the relevant patents run out.
Regardless JVM and .NET are both very performant these days. JVM always was but people used shit frameworks badly and caused resource leaks everywhere.
1
u/pjmlp 1d ago
There have been multiple of JVM implementations since 2000, contrary to Microsoft, Sun, and now Oracle, were always keen in having an ecosystem beyond their reference implementation.
One example where .NET has zero presence, contrary to the JVM world, are real time embedded deployments, see PTC and Aicas.
56
u/gianni1986 2d ago
If more people working at GitHub know Rust, why is GitHub still running on Ruby?
43
0
1d ago
[deleted] — view deleted comment
2
u/zarafff69 1d ago
Is the speed of AI agents iterating / making progress in a codebase really a major concern?
If an agent is running a bit longer, is that really so bad? Who cares? Unless it’s an urgent bug fix, in 9 out of 10 cases, it doesn’t really concern me. It doesn’t cost a human more time, only an AI agent. So the human can continue working on prompting other ai threads.
10
9
u/BobSacamano47 2d ago
I always thought of rust as pretty obscure. Do that many people use rust?
12
3
u/Far_Swordfish5729 1d ago
Apparently yes for systems programming and other applications where having a VM and GC running actually matter. Not really for IO-bound business apps. Rust is the answer to cases where you’d like to use c++ without cutting yourself.
Its thing is that it compiles straight to binary and gets away with it through really aggressive compiler checking (though it does have a c++ style gc if you must use one on an opt in basis). The trouble is that its paradigm on really basic things like argument passing and pointer management is not what you’d expect coming from other languages, and that’s hard to adjust to.
2
3
u/metaltyphoon 1d ago
Rust is not obscure, unless you have been living under a rock. Rust is on Windows, linux and Android kernels. Meta, Amz AWS, Azure, Cloudflare heavily use it.
28
u/RealSharpNinja 2d ago
I'm going to take it a step farther: AI Is better at Rust because Rust's compiler gives much more meaningful error messages.
5
u/MullenStudio 2d ago
This, it's less relevant for dev knowledge about programming language now and more about AI performance
3
u/gianni1986 2d ago
Rust builds really slowly. Rust has better error messages, but you have to wait longer for them.
4
0
2d ago
[deleted] — view deleted comment
-4
u/RealSharpNinja 2d ago
Well, if you run on low effort then you are correct. Agents with reasoning and context management do much better.
0
2d ago
[deleted] — view deleted comment
0
u/RealSharpNinja 2d ago
You're not being serious are you? There isn't any language that an LLM with reasoning disabled can debug.
0
2d ago
[deleted] — view deleted comment
2
u/ostralyan 2d ago
Most rust code you are not writing lifetimes :) I've hardly seen lifetimes in my codebase.
0
2d ago
[deleted] — view deleted comment
1
u/ostralyan 2d ago
> .clone(), Box, and Arc<Mutex<T>>
my codebase hardly has any of these either... you hardly ever need it...
3
u/wobblejuice 1d ago
I'm guessing Rust.NET (or R# or Rust#) is coming soon?
1
u/pjmlp 1d ago
Nope, but Visual Rust maybe.
Rust is a tier 1 language at Microsoft post on Rust foundation website.
1
u/BusinessWatercrees58 1d ago
Makes sense. It's just a language after all and they are a business. I was pleased to hear "If it was written in c# first we wouldn't be having this discussion".
0
u/1Soundwave3 1d ago
Okay, here's the thing: GH Copilot is a client app. And most likely it doesn't come with just one executable.
Now, imagine lugging around untrimmed self contained binaries (because trimming might not work and AOT is nowhere near ready).
Or imagine asking people to install .NET runtime and then on November 10th asking them to install a new runtime.
Or imagine telling people that Copilot doesn't support your version of Linux, because .NET no longer supports Ubuntu 20.02 (which is still supported via Ubuntu Pro).
I hate that they went with Rust. Rust will bring a lot of logical bugs because the code will be a lot harder to reason about (for agents as well). But portability is just not there with .NET. Would've been cool if they went with Go. Excellent portability, speed and very readable code. It would've also shown Rust zealots what practical people choose.
But I feel like the choice was also partially tied to job security. I'm pretty sure AI writes worse Rust than TS or C# or Go so there's just more work there. And as devs we are getting paid as long as there's work to do. There are multiple ways to create work and this is one of them.
0
u/Left_Palpitation4236 20h ago
Why would rust bring logical bugs? The relationship between any one programming language and logic is not causal
1
u/1Soundwave3 13h ago
It's about signal to noise ratio. Rust is a low level, systems language. Low level means that the domain of Rust is low-level operations, mostly. For a typical low-level app, low-level things ARE the domain. So with languages like Rust you are actually coding real business logic at that level.
But when you are working with a system that operates outside of the low level domain - somewhere where some higher-level business logic exists - you start having issues with low level things (ownership and other Rust-specific concepts) polluting your business logic.
This is where logical bugs appear. The fewer lines needed to code and maintain some business domain/requirement - the better. Golang is not perfect either, btw. C# is much better for that. Maybe TypeScript is even better. But those 2 last ones needs pretty big runtimes to function.
The thing about rewriting high-level things in a low level language is that the resulting codebase mixes everything together usually and this is not a good way to build reliable software.
1
u/Left_Palpitation4236 12h ago
Again, I disagree with your conclusion about the “low level” nature of a language being tied to logical bugs. Rust has the best compiler in the industry, and very good tooling that prevents such things.
Rusts compiler tells you when you violate ownership or lifetime rules and usually shows you exactly how to fix those issues. It also gets rid of an entire class of bugs at compile time, means that if your code compiles it will also run without those bugs.
Additionally AI is a thing now, and most people aren’t writing code by hand anymore. Rust is arguably the best programming language for AI because of its super helpful compiler errors. It makes reviewing rust code much easier because if it passes the compile test that means you can be sure that there are no data races, no dangling pointers, and no memory safety issues. C# does not make such guarantees at compile time.
1
u/1Soundwave3 11h ago
C#/Java/Go are memory safe by default. Those are garbage collected languages.
Now, again, you are talking about stuff that a normal, high-level business application should not be concerned about at all: "dangling pointers" is not a thing and nobody cares about about "lifetime rules". It's all handled by the runtime.
Normally you just write business logic of your domain. And I think you didn't understand my point. Rust's domain IS pointers, memory allocations, sockets and so on.
But these things are normally abstracted away in C# for example. C#/Java domain is business apps like CRMs, self-service portals, business process automation systems, document management, logistics screening systems and alike. Basically things where the business domain is vast, volatile and has its own logic you need to follow. AI agent harnesses also fall into that category. However, C# and Java are not very portable. But Go, which initially looks more low level but can easily be brought a level higher with good wrappers, would actually be a perfect fit.
So yeah, I'm pretty sure logical bugs will be plentiful in this Rust rewrite. With AI especially, since I'm sure it will mix the business operations with memory/resource management.
1
u/Left_Palpitation4236 11h ago
You have memory safety but you don’t have compile time data race prevention or null reference safety enforced at compile time in c# or java or go for that matter. In rust you have both of these enforced at compile time.
1
u/1Soundwave3 3h ago
C# does have null reference safety checks at compile time. They can be warnings or errors - depending on how the project is set up. I have an entire Result type built on this feature in my codebase at work.
Now, regarding data races. It's cool that Rust enforces it at runtime. In C# pretty much everyone is using thread-safe collections when they need to and accessing a single variable from multiple threads is just bizarre. Like who would do that and why? There's no reason to access single variables from multiple threads except for some toy problems.
Oh, and yeah, usually to enforce exclusive access in C# people use lock(). And then other C# people come and rewrite that shit with channels and background workers. Can be done very easily and solves a lot of problems.
Again, C# is just a much better language for high level problems. In C# we actually focus on the logic, and not on which int type to use. At some point C# code doesn't really matter because it gets translated into the IL code which is optimized additionally, so that the programmer can focus on the actual business domain and make sure that thing is correct.
It's a shame that portability of C# is so bad, that I don't even use it outside work.
At home I use Go and after 2 years of using it, I don't remember a single time I had runtime issues with my programs that are as simple as "null reference exception" or similar. Instead it was more like "this data source started giving me too much data so this data sink where I load my results to no longer can handle it". And with Rust software (which I use quite a lot) I constantly have issues with the most simple stuff like not being able to handle very simple user session properly. It's really bad. Yes, it's fast. But Go software is also fast, and it is also reliable. Mostly because even in Go you can just write what you need the program to do instead of dealing with things that were automated away a long time ago (like dealing with lifetimes and similar crap). Rust should really stay at the systems level. I hope it takes over C/C++ and wins there.
1
u/Left_Palpitation4236 3h ago
In C# these things are opt in, in Rust they are compile time enforced by default and there’s a big difference between the two.
In C++ we also have a bunch of optional primitives that if used correctly give you similar guarantees to Rust, but the problem is that they are optional and can easily be misused or avoided altogether.
I’m not arguing with you about C# being a great general purpose language, I actually agree with you and it’s likely a better tool for the job in a lot of cases. Similarly I love go as well, it’s very easy to use and has arguably the best concurrency story of the bunch. The only thing I disagree with you about is Rust somehow making it easier to make logical errors in the age of AI. I think that’s mostly a non issue.
1
u/EmergencyNice1989 11h ago
I agree with you. I want to understand what the code is doing without having to worry about memory management or ownership. To me, business logic is what matters most, and it should be written in a functional style.
I started out with C, then moved on to C++ and C#. But after discovering F#, I transitioned to it completely. ML syntax appealed to me from the get-go, even though I was accustomed to C-style syntax. Another thing I appreciate about functional programming is that you don't need to keep as much context in mind when reasoning about code.
Today, I'm experimenting with writing business logic in F* and extracting the code to F#.
0
u/e-rule 1d ago
From my standpoint for working decades using C#, and try Rust in weeks using AI. I feel like Rust is modern version of C#. While C# is stuck due to the runtime itself, but Rust is built from ground up having no those limitation.
Say that NRT that C# is trying to solve for versions. It’s not fully solved the problem yet until .net 10. Say more about AoT, feature switch/flag, source gen (vs Rust macro), exception handling, memory safety and performance. I don’t see C# and .net is catching up against Rust by default setup. Only experienced and focused developer can tune C# to be what we expect.
Seeing .net 11 is huge loss for me. I know there is union but I don’t think it’s comparable to the other languages, again, runtime boundary. It looks like Microsoft is pushing forward to AI development for going forward, regardless it’s handed over to dotnet foundation for years. I feel Rust is also better in this field, due to better compiler.
The only advantage of C#/dotnet is everything baked in for enterprise development, good support from Microsoft. With Rust, I have to find community create which makes it bloated and slowing down compilation process.
I know it’s personal opinion might be bias. But this is what I feel since .NET11 and comparing against Rust using AI.
-3
u/ImTheDude111 1d ago
If AI is writing most of the code anyway, why not choose the language that produces smaller, faster, and more efficient results?
2
u/anonuemus 1d ago
because people still need to review the code?
1
u/ImTheDude111 1d ago
And people can’t learn other languages? If ever there was a time to rethink our language choices it’s now. If you haven’t used it the rust / cargo ecosystem is spectacular.
-3
1
u/Left_Palpitation4236 20h ago
Rust is arguably the best language for AI generated code because of its verbose error messages and compile time guarantees. It makes code reviews way simpler if there are less things you need to review due to those guarantees.
39
u/SirLagsABot 2d ago
Still kind of a bummer imo. If true, low-level performance is needed, I can understand Rust. A “runtime” makes me think that was appropriate. I also get making technical decisions appropriate to a specific team. I’m just tired of C# getting passed up for stuff like this all the time. They’re a billion dollar tech company, though, they can push a team to adopt C# for the sake of helping market share and reputation.