Bringing Rust memory management to C#


#1

I’ve become interested in Rust, a memory and thread safe systems programming language. However, I dislike having to learn another new syntax and Rust lacks some of the concepts (such as class inheritance) which are familiar to me.

So I was wondering, would it be possible for Microsoft to port some of the most important Rust concepts, memory and thread safety through borrowing etc. to C#?

Or do we need another .NET language family member which doesn’t have garbage collection but instead offers support for the Rust concepts? Also an AOT (ahead of time) compiler would be nice so this language could be used to built operating systems and low level programing.


#2
  • C# is already memory safe.
  • The garbage collector is an integral part of .Net, so I think it doesn’t make sense to have a .Net language without GC.
  • AOT compilers for .Net already exist. One is part of Mono, another one is CoreRT.

In general, I think that mashing two languages together the way you’re suggesting is not a good idea. The ways a language solves various problems are often specific to that programming language, so what works in one language probably won’t work well in a different language.

On the other hand, a safe, system programming language based on C# is an interesting idea. You might want to read about the Midori project, which was an attempt to create a whole operating system based on a variant of C# for how that might look like.


#3

AFAIK Midori didn’t use a separate C# language family member, but built an OS in C# running on a VM on top of a small C bootloader.

Yes, C# is memory safe, but not deterministic because of the garbage collection, and therefore not useful for systems programming.

And it turns out that memory safety and thread safety are two sides of the same coin.

In general, I’m baffled why Microsoft hasn’t built a C# AOT compiler and required frameworks to replace their C++ infrastructure. Many of their products would benefit enormously (qualitatively) if they were (re)written in C#.


#4

I don’t really know how rust work. But if you really thinks some thinks is interesting I encourage you to see if the issue wasn’t open on GitHub. https://github.com/dotnet. And open it if not.

I don’t understand. As @svick say the new c# compiler is in C# and have a AOT Scenario possible (https://github.com/dotnet/roslyn && https://github.com/dotnet/corert). Am I missing somethinks?.


#5

There is a .NET AOT compiler somewhere, but it can only be used for UWP apps, which isn’t terribly useful in itself. I’d want a AOT compiler that works with everything: WinForms, ASP.NET, WPF, the whole shabang.


#6

I’ve even conjured up a name for this new .NET member: Knife# :slight_smile:


#7

Sorry, I haven’t read these forums for a while, but your comment is great, very apropos. You raise a lot of great points. That whole “C/C++ => C#” thing is something that particularly irks me, and it has been raised before by others. I just don’t buy any reasons that I’ve seen. I’ve written a C# compiler for CIL targeting NVIDIA via LLVM (Campy) supporting like 90% of C#, and ported a mini NET runtime called DotNetAnywhere which contained a lot of C code to CUDA. Remarkably, it works. But, all those thousands of changes won’t work for AMD GPUs because it’s CUDA. And, it’s not the Net Core runtime. I really have to get the Net Core runtime rewritten in C#–with some being obviously unsafe–code, except for possibly a very, very small kernel. Some would say that C# can’t be used for HP computing, but I’m extremely slow to give up. I just don’t believe them, and I’ll prove them wrong. Anyways, I’ll be rewriting the NET runtime into C#. I’ll definitely consider replacing the GC with a deterministic algorithm. I had to rewrite the GC anyways for the GPU target to not use locking. Note, I haven’t worked on the project for a few months because I’ve been stuck on another project that Campy depends on. It re-invents pinvoke generators in a very nice, clean, template/pattern matching language on ASTs, something that some compiler writer should have done years ago. When that works, I’ll be back on Campy soon.


#8

Compile time thread safety is a wonderful thing. I’ve been a long time c# coder and have done rust for a few years now. While rust has shown that it is possible to have compile time thread safety, the whole language and APIs are geared to tracking mutability. I.e. in rust as an argument you can pass ownership of a string, lend ownership of a string or pass a ‘read only’ view of that string. This profoundly effects how you design APIs and in my opinion allows APIs to be much clearer in intent as to how they use their arguments.

Because the whole standard libraries need to specify how they are passing their arguments I think its not something one could easily ‘bolt on’ to a language and get much value from.

That said, there’s plenty of value calling fast rust libraries from c# (via C’s ffi) especially for any performance critical hot-spots you may have. (And after the one-time learning curve, rust is just as fun to code in as c#.)


#9

Also inheritance sounds like something one should miss, but I’m pretty sure they’re right - you’re better off without it. Rust has interface inheritance and that’s as it should be. Class inheritance hierarchies tend to lead to subtle bugs and reuse of code that maybe you didn’t quite realize was being reused in particular cases. In theory they’re great, but in practice there’s always lots of exceptions. Take a look at an large scale bank’s object model and you’ll see a failure of inheritance to scale.

Rust is effectively enforcing composition over inheritance by not allowing class inheritance and in general that’s probably going to be good for the world.
( https://en.wikipedia.org/wiki/Composition_over_inheritance )


#10

I’ve also been using AKKA.NET and I’ve come to the conclusion that thread communication via messaging should be built into the C# language. I’m planning to put together a proposal shortly.


#11

Mwah, the word is still out on that. In C# they compromised by only allowing single implementation inheritance and mandating composition (with interfaces) if you want more.

Implementation inheritance is certainly has its uses. I do agree that multiple inheritance has its drawbacks, but it too can be useful if used with care. Many GUI frameworks make good use of it (such as wxWidgets).


.NET Foundation Website | Blog | Projects | Code of Conduct