C#'s runtime (dotnet runtime) adds overhead compared to Rust with GC and other stuff too. This is true even with single-binary AOT compilation, the runtime is still there (just like Go). So it will never be suitable for some scenarios.
You can definitely implement manual ownership tracking in C#, this is quite common for non-memory resources and does have some language syntactic sugar with the Dispose pattern for example. But you can't truly roll your own memory management/ownership unless you do something with "unsafe" which seems counter-productive in this case :P.
/btw, I am not affiliated with neonsunset, but could people please comment to explain what is wrong instead of downvoting? If there is any substance to a comment and it isn't obviously a misinformation or disinformation one (Paradox of Tolerance), we should have a discussion instead.
On topic: Could F* unlock even more possibilities, like crossing the gap of the heap and the stack in terms of direct access? It has a very powerful type system and it can eject an F* program to F#.
Looks like many/most of their comments are dead, probably some account-level action that was taken at some point. Vouched for the comment here to bring it back from the dead.
> Ownership model for example, would it be possible to enforce practice via some-sort of meta framework?
It should be possible to at least write an analyzer which will be based on IDisposable-ness of types to drive this. Notably, it is not always more efficient to malloc and free versus using GC, and generational moving GCs do not operate on "single" objects allocating and freeing them, no, so you cannot "free" memory either (and it's a good thing - collection is marking of live objects and everything unused can be reclaimed in a single step).
Also the underlying type system and what bytecode allows is quite a bit more powerful than what C# makes use of, so a third language targeting .NET could also yield a better performance baseline by better utilizing existing (very powerful) runtime implementation.
Lastly, there have been many improvements around devirt and object escape analysis, and GC changes are also a moving target (thanks to Satori GC), so .NET is in quite a good spot and many historical problems were or are in the process of being solved, that make Rust-style memory management less necessary (given in Rust you also make use of it because you want to be able to run your code on bare metal or without GC at all, only relying on host-provided allocator - if you do not have such requirement, you have plenty of more convenient options).
C# is underrated because it only works well on Windows and has bad frameworks such as .NET.
There isn't really any reason to use it outside of developing Windows native applications. There are much better cross-platform languages, with a bigger community and better support.
No. It is quite a viable cross-platform language and there is a large community.
1. C# works on Linux almost seamlessly. See the documentation: https://learn.microsoft.com/en-us/dotnet/core/install/linux
2. Actually C# specification is open. Meaning C# is like Java, anyone can implement in any platform. There are even alternating compilers, open sourced, thanks to Mono's efforts: https://www.mono-project.com
This isn't true at all anymore for years! Microsoft acknowledged Linux won for server-side and since C# is primarily used as a server-side language they made everything work incredibly well on Linux.
I find that modern versions of dotnet seem to run better on Linux. And from what I see from Azure and from MSFT engineer blog posts, I'm assuming dotnet support on Linux is a higher priority than on Windows.
In any case, their claim that dotnet is a bad framework made me chuckle out loud. I'd like to see their impression of what a better framework looks like.
I have the same result : performances on Linux are better and this is a real focus for MSFT engineer (Azure has a tons of linux instances running dotnet)
C# is already memory safe. This isn't the reason why some people chose Rust over C#.
C#'s runtime (dotnet runtime) adds overhead compared to Rust with GC and other stuff too. This is true even with single-binary AOT compilation, the runtime is still there (just like Go). So it will never be suitable for some scenarios.
You can definitely implement manual ownership tracking in C#, this is quite common for non-memory resources and does have some language syntactic sugar with the Dispose pattern for example. But you can't truly roll your own memory management/ownership unless you do something with "unsafe" which seems counter-productive in this case :P.
neonsunset shared an interesting article, but his comment is dead: https://em-tg.github.io/csborrow/
/btw, I am not affiliated with neonsunset, but could people please comment to explain what is wrong instead of downvoting? If there is any substance to a comment and it isn't obviously a misinformation or disinformation one (Paradox of Tolerance), we should have a discussion instead.
On topic: Could F* unlock even more possibilities, like crossing the gap of the heap and the stack in terms of direct access? It has a very powerful type system and it can eject an F* program to F#.
Looks like many/most of their comments are dead, probably some account-level action that was taken at some point. Vouched for the comment here to bring it back from the dead.
C# actually already has limited lifetime analysis :)
https://em-tg.github.io/csborrow/
> Ownership model for example, would it be possible to enforce practice via some-sort of meta framework?
It should be possible to at least write an analyzer which will be based on IDisposable-ness of types to drive this. Notably, it is not always more efficient to malloc and free versus using GC, and generational moving GCs do not operate on "single" objects allocating and freeing them, no, so you cannot "free" memory either (and it's a good thing - collection is marking of live objects and everything unused can be reclaimed in a single step).
Also the underlying type system and what bytecode allows is quite a bit more powerful than what C# makes use of, so a third language targeting .NET could also yield a better performance baseline by better utilizing existing (very powerful) runtime implementation.
Lastly, there have been many improvements around devirt and object escape analysis, and GC changes are also a moving target (thanks to Satori GC), so .NET is in quite a good spot and many historical problems were or are in the process of being solved, that make Rust-style memory management less necessary (given in Rust you also make use of it because you want to be able to run your code on bare metal or without GC at all, only relying on host-provided allocator - if you do not have such requirement, you have plenty of more convenient options).
C# is underrated because it only works well on Windows and has bad frameworks such as .NET.
There isn't really any reason to use it outside of developing Windows native applications. There are much better cross-platform languages, with a bigger community and better support.
Almost every statement is incorrect. Your knowledge of the .NET ecosystem seems to be about ten years out of date.
Not almost, every single one ^^
No. It is quite a viable cross-platform language and there is a large community. 1. C# works on Linux almost seamlessly. See the documentation: https://learn.microsoft.com/en-us/dotnet/core/install/linux 2. Actually C# specification is open. Meaning C# is like Java, anyone can implement in any platform. There are even alternating compilers, open sourced, thanks to Mono's efforts: https://www.mono-project.com
This isn't true at all anymore for years! Microsoft acknowledged Linux won for server-side and since C# is primarily used as a server-side language they made everything work incredibly well on Linux.
I find that modern versions of dotnet seem to run better on Linux. And from what I see from Azure and from MSFT engineer blog posts, I'm assuming dotnet support on Linux is a higher priority than on Windows.
In any case, their claim that dotnet is a bad framework made me chuckle out loud. I'd like to see their impression of what a better framework looks like.
I have the same result : performances on Linux are better and this is a real focus for MSFT engineer (Azure has a tons of linux instances running dotnet)