A comparison of Rust’s borrow checker to the one in C#

https://em-tg.github.io/csborrow/

by SkiFire13 • 2 years ago

333 323 2 years ago

em-tg.github.io

bob10294• 2 years ago

Maybe I’m bad at searching for these things, but these changes to C# seem to have gone completely under the radar in places where you read about memory safety and performance. Maybe it’s just because the language additions have happened super slowly, or maybe the C# and Rust communities have so little overlap that there aren’t enough people who program in both languages to notice the similarities.

If you are looking at this through the lens of HN, I think much of this can be attributed to a certain ideological cargo cult that actively seeks to banish any positive sentiment around effective tools. You see this exact same thing with SQL providers, web frameworks, etc. If the tool is useful but doesn't have some ultra-progressive ecosystem around it (i.e., costs money or was invented before the average HN user's DOB), you can make a winning bet that talking about it will result in negative karma outcomes.

Everyone working in enterprise software development has known about the power of this language for well over a decade. But, you won't find a single YC startup that would admit to using it.

zdragnar• 2 years ago

Well, common lisp and some schemes and prolog tend to get a good deal of praise here, even if their commercial utilization is lower. OCaml, F# and Clojure tend to get a good deal of favorable comments as well.

I suspect it is less about cargo culting, and more about two separate things:

First, the tooling for C# and really anything dotnet has been awful on any OS other than Windows until fairly recently. Windows is (to be blunt) a very unpopular OS in every development community that isn't dotnet.

Second, anthing enterprise is worth taking with a skeptical grain of salt; "enterprise" typically gets chosen for commercial support contracts, vendor lock-in, or astronaut architects over-engineering everything to fit best practices from 20 years ago. Saying big businesses run on it is a virtue is akin to saying that Oracle software is amazing or that WordPress engineering is amazing because so many websites run on it. Popularity and quality are entirely orthogonal.

I suppose there is probably another reason, which is the cluster fuck that has been the naming and churn of dot net versions for several years. ASP.NET, then core, then the core suffix got dropped at version 5, even though not everything was cross platform... So much pointless confusion.

devjab5• 2 years ago

Everyone working in enterprise software development has known about the power of this language for well over a decade.

I think it depends on location. In my part of the world .Net is something which lives in middle sized often stagnating companies. Enterprise around here is married to the JVM and they even tend to use more Typescript on the backend than C#. I’m not going to defend the merits of that in any way, that is just the way of things.

There being said I do get the impression that HN does know that Rust isn’t seeing much adoption as a general purpose language. So I wouldn’t count C# out here considering how excellent it has become since the transition into Core as the main .Net. I say this a an absolute C# hater by the way, I spent a decade with it and I never want to work with it again. (After decades of SWE I have fun with Python, C/Zig, JS/TS, and, no other language.)

DeathArrow14• 2 years ago

Enterprise around here is married to the JVM and they even tend to use more Typescript on the backend than C#. I’m not going to defend the merits of that in any way, that is just the way of things.

Many developers already know Java, so it's easier to hire Java developers.

There being said I do get the impression that HN does know that Rust isn’t seeing much adoption as a general purpose language. So I wouldn’t count C# out here considering how excellent it has become since the transition into Core as the main .Net. I say this a an absolute C# hater by the way, I spent a decade with it and I never want to work with it again. (After decades of SWE I have fun with Python, C/Zig, JS/TS, and, no other language.)

I didn't like the old C# and .NET. However, the new one is wonderful and I quite enjoy using it. More than Java or Go. On par with Python, but I wouldn't use Python for now for large web backend applications.

I tried Rust, bur for some reason I can't grow to like it. I'd prefer using C or Zig and even a sane subset of C++ (if such thing even exists).

radicalbyte3• 2 years ago

I have fun with Python, C/Zig, JS/TS, and, no other language.

Python is the least fun language currently in use at any scale. Pretty much completely down to the lack of a coherent tool chain. When JS has better package management than you then you know you have a massive problem.

WD-422• 2 years ago

I think it has more to do with c# being a Windows only programming language for the majority of its life. And guess what, a lot of people don’t like Windows.

And don’t bring up mono, etc. it was a dumpster fire then and it’s only recently gotten better. It tough for any tech to shed a very long negative legacy.

Kipters3• 2 years ago

.NET Core 1.0 was released cross-platform 8 years ago though, there's a ton of new devs for who it has always been cross-platform

DeathArrow14• 2 years ago

I don't get why you are downvoted. It's true that some languages, frameworks, operating systems are more popular on HN that others. Reasons for this might be complex and we might enter into very hard and complicated sociological arguments if we try to discuss them.

Everyone working in enterprise software development has known about the power of this language for well over a decade.

What is an enterprise? Is Google not an enterprise? Is Apple not an enterprise? Is Facebook not an enterprise? What about Netflix, Uber and any other big tech company? Weren't all enterprises start-ups at the beginning?

Does enterprise mean boring old company established long before the invention of Internet, which does old boring stuff, employs old boring people and use old boring languages? I imagine a grandpa with a long white beard staring at some CRTs with Cobol code and SAP Hana.

wongarsu• 2 years ago

In this context I'd interpret enterprise to mean any company with over 1000 employees that is not what Silicon Valley calls a tech company. So no Apple, Google or Uber, but the notable players of basically every other industry, from A for accommodation or accounting to W for wood paneling.

But I wouldn't say their choice of C# is due to them being old and boring. If it was that, they'd use Java (as many do). In my eyes choosing C# signals to me that you do want good technology (again, you could have gone with Java), but want that technology to be predictable and boring. A decent rate of improvement with minimal disruption, and the ability to solve a lot of issues with money instead of hiring (lots of professionally maintained paid libraries in the ecosystem).

Ygg29• 2 years ago

...actively seeks to banish any positive sentiment around effective tools

Effective at what?

Want GC lang with lots of libraries? Use Java.

Want GC free lang with safety? Use Rust.

Otherwise just use C. Or C++.

For me C# lies in this awkward spot. Because of past decisions it will never have quite the ecosystem of Java. And because GC -free and GC libraries mix as well as water and oil, you get somewhat of a library ecosystem bifurcation. Granted GC-less libraries are almost non-existent.

DeathArrow14• 2 years ago

I worked in both C# and Java. And other languages. Resuming C# and Java to "GC languages with lots of libraries" doesn't accurately depict neither C#, nor Java.

Since we discuss C# here, it is a good jack of all trades language where you can do almost anything, with decent performance, low boilerplate. It's easy to read, easy to learn and you have libraries for everything you need, excellent documentation and plenty of tutorials and examples. A great thing is that for every task and domain there is a good library or framework that most developers use, so you don't have to ask yourself what to use and how and you find a lot of documentation, tutorials and help for everything.

Java it's a bit more boiler plate-y, had a bit less features and ease of use and had many libraries and frameworks that did the same thing. Had Java been better, Kotlin wouldn't need to be invented.

Want GC lang with lots of libraries? Use Java. Want a fast to develop and easy to use language? Just use C#.
Want GC free lang with safety? Use Rust. Want a language which you can use for almost eveything? Web front-end, web backend, services, microcontrollers, games, desktop and mobile? Use C#.
Otherwise just use C. Or C++. Or whatever works for you. Whatever you like, find fun and makes you a productive and happy developer. There is nothing wrong in using C or C++. Or Python. Or Haskell.

high_na_euv• 2 years ago

Java ecosystem is more fragmented and inconsistent than C#

C# is better designed lang, has really strong tooling and ecosystem and well designed std lib

DeathArrow14• 2 years ago

Everyone working in enterprise software development has known about the power of this language for well over a decade. But, you won't find a single YC startup that would admit to using it.

Not sure about that. Maybe there are? If you do web or mobile apps, C# would be an excellent choice. Go would be also an excellent choice for web.

For AI I wouldn't use C#. Even though it has excellent ML libraries, most research and popular stuff is done using Python and pytorch, so that's what I would chose.

For very low level, I'd take C or Zig. But I don't know many startups who are into very low level stuff.

jeroenhd• 2 years ago

C# is an incredible language with a past haunted by Microsoft only making it useful on Windows and expensive licenses for really good editors. It's come a long way, but I don't blame people for thinking of it as "Microsoft Java".

My only issue with many of the improvements in C# is that all of them are optional for backwards compatibility reasons. People who don't know or don't care about new language features can still write C# like it's 2004 and all of the advantages of trying to modernize go out of the window. That means that developers often don't see the need to learn any of the new features, which makes it hard for projects to take advantage of the language improvements.

alkonaut9• 2 years ago

Hard agree on the backwards compatibility. It appears to be some law of nature that "our next compiler must compile 20 year old code".

Instead of new platform libs and compilers simply defaulting to some reasonable cutoff date and saying "You need to install an ancient compiler to build this".

There is nothing that prevents me from building my old project with an older set of tools. If I want to make use of newer features then I'm happy to continuously update my source code.

johnisgood4• 2 years ago

Yeah, or you think Ada / SPARK ever comes up when people cry for memory safety? It has existed in Ada / SPARK for ages, but nah...

failbuffer• 2 years ago

Alternatively (or at least additively), most C# developers don't really need all the new ref/Span features. They're writing line-of-business apps and garbage collection is a fact of life, not some burden to be avoided.

Microsoft probably added these features to push the language into new niches (like improving the story around Unity and going after Arduino/IoT). But it's of little practical appeal to their established base.

Dykam• 2 years ago

As far as I'm aware, it's the development of Kestrel which pushed the introduction of ref/Span etc. Due to it Kestrel has seen quite a large speedup, it being one of the fastest HTTP servers nowadays. ref/Span allowed them to make the core almost allocation free, together with using vectorized operations (SIMD ) for parsing the request.

neonsunset22• 2 years ago

What a great article, thank you for sharing it!

zigzag31211• 2 years ago

I always felt like these features are adding a new programming paradigm to C# that allows you to bypass GC in safe code.

I wish more people would talk about it. Thank you for such an interesting article!

pjmlp10• 2 years ago

Many of these features exist since .NET 1.0, given its scope of languages to support, including C++.

So even those that weren't initially exposed in unsafe mode, were available at the MSIL level and could be generated via helper methods making use of "System.Reflection.Emit".

Naturally having them as C# language features is more ergonomic and safer than a misuse of MSIL opcodes.

zigzag31211• 2 years ago

"System.Reflection.Emit" is not compatible with NativeAOT.

Using C/C++/Rust to do the same task is probably more productive than emitting MSIL opcodes, so that solution wasn't really that practical.

But with these new features being more ergonomic and practical, it becomes cost effective to just do it in C# instead of introducing another language.

MarkSweep• 2 years ago

There is a runtime (not C#) feature that has been added that is relevant to the article: ref fields in structs. Before these, only certain runtime-blessed types like Span<T> could contain refs directly.

In case anyone is interested, here is the spec about refs in structs and other lifetime features mentioned in the article:

https://github.com/dotnet/csharplang/blob/main/proposals/csh...

And here is the big list of ways .NET differs from the publish ECMA spec. Some of these differences represent new runtime features.

https://github.com/dotnet/runtime/blob/main/docs/design/spec...

algorithmsRcool8• 2 years ago

Span and ref-like types enable massive changes to the way that memory is managed in C#. You can absolutely write almost GC-less code. I have been tinkering with a toy no-GC database engine in C# based on Direct I/O and some object pooling. I have been amazed at how far i can get before resorting to GC heap allocations

DeathArrow14• 2 years ago

Anything that uses classes and interfaces will be memory managed by the GC. So instead of using lists, dictionaries, IEnumerable, you will have to roll your own.

It would be better if the GC can be turned off with a switch and just add a delete operator to manually free memory.

pjmlp10• 2 years ago

This kind of features is C# catching up to what was already possible in languages like Modula-3.

Unfortunately, as usual in computing, we have to do huge circles shaped in zig-zag, instead of adopting what was right in front of us.

johnisgood4• 2 years ago

Yeah I feel like we are taking "reinventing the wheel" to a whole new level, and with enough time, people forget, same with Lisp and Forth (i.e. how they just re--implement stuff that were already a thing in those two languages, but perhaps under a different name).

uticus3• 2 years ago

The biggest difference is the number of people involved and the target. C# is built for collaboration by a large number of people (of sometimes little experience), for everything from Windows GUI to microservice AWS lambdas

algorithmsRcool8• 2 years ago

There is very little new under the sun. It reminds me of the wheel of time books, as the wheel turns we forget about the learnings of the previous age and reinvent them for ourselves. Often worse.

stonethrowaway• 2 years ago

C# is Pragmatic [0].

[0] https://news.ycombinator.com/item?id=41761346

lowbloodsugar• 2 years ago

This restriction is central to Rust’s safety guarantees, but C# doesn’t need it. The reason is that Rust has to account for the possibility that a reference may be invalidated at any time.

That’s not why though. There’s lots of reasons for Rusts safety model, such as allowing for vastly faster code because aliasing can’t happen unless both references are read only, in which case it doesn’t matter. There is lot to Rusts borrow rules that this article misses.

It’s like the article earlier today that was, essentially, “I don’t understand Rust and it would be better if it was Haskell”.

fulafel2• 2 years ago

Is there some benchmarking work that has quantified this speedup from aliasing guarantees or is this more of a sufficiently smart compiler[1] thing?

[1] https://kidneybone.com/c2/wiki/SufficientlySmartCompiler

DonaldPShimoda2• 2 years ago

The Sufficiently Smart Compiler is a hypothetical argument used in advocating for a programming language whose naive implementations might tend towards inefficient designs, whereas the aliasing argument is not itself hypothetical but it may not be backed by data. That's a different thing altogether.

Whether the aliasing argument holds water does not affect whether it was used as justification for Rust's design.

vlovich1234• 2 years ago

Of course: https://github.com/rust-lang/rust/issues/54878#issuecomment-...

TLDR: 0-5% faster with noalias optimizations on.

You can always try running some benchmarks by building code with -Zmutable-noalias=no.

physicsguy4• 2 years ago

aliasing can’t happen unless both references are read only

Other languages have long had aliasing, Fortran for one. C and C++ have the restrict keyword though obviously it's a programmer guarantee there and is less safe, since if the user of the function does pass the same memory ref offset for e.g. the optimisation is not safe.

orangeboats• 2 years ago

The restrict keyword is very seldomly used in C programs. You could probably remove it and still be able to compile the majority of C programs.

(Otherwise, the Rust project wouldn't have encountered all the bugs related to aliasing analysis in LLVM.)

vlovich1234• 2 years ago

C and C++ have the restrict keyword

I'd say in name only given that there were numerous aliasing bugs in llvm that only became visible when Rust tried to leverage it. I suspect similar pitfalls exist in every single C/C++ compiler because the rules for restrict are not only difficult to understand for use but also difficult to implement correctly.

DonaldPShimoda2• 2 years ago

Instead of throwing an exception, we’ve decided that this function should always return something, even if it’s not in the haystack

The right move at this point would be to use an optional type, surely...

vlovich1234• 2 years ago

This restriction is central to Rust’s safety guarantees, but C# doesn’t need it. The reason is that Rust has to account for the possibility that a reference may be invalidated at any time.

Is this right? I thought Rust's reason for XOR is deeper & is how it also guarantees memory safety for multi-threaded code too (& not just for reference lifetimes).

lionkor2• 2 years ago

That's how I understood it, too

Animats• 2 years ago

So what are the C# compiler lifetime error messages like? It if guesses about lifetimes, the messages have to be good.

lionkor2• 2 years ago

The article has some examples

leosarev• 2 years ago

Maybe I’m bad at searching for these things, but these changes to C# seem to have gone completely under the radar in places where you read about memory safety and performance.

The reason is this changes are not aimed on average Joe developer writing C# microservices. This changes and whole Span/ref dialect of C# are aimed on Dr. Smartass developer writing C# high performance libraries. It's advance-level feature.

yread• 2 years ago

The article that introduced them talks about mainstay and is certainly not trying to hide their impact

https://learn.microsoft.com/en-us/archive/msdn-magazine/2018...

DeathArrow14• 2 years ago

I use low level C# constructs, mostly for fun. At current job we write backend microservices and our business domain doesn't need too much low level stuff.

But before span and friends you could always use pointers. Spans just make things friendlier.

And C# also has built-in SIMD libraries if you need to do some high performance arithmetic stuff.

bob10294• 2 years ago

I don't think Span<T> and ref are particularly sophisticated concepts.

Span makes working with large buffers easier for Joe developer, if he could be bothered to spend 20 seconds looking at the examples in the documentation.

EVa5I7bHFq9mnYK2• 2 years ago

All this "advance" stuff does is work around the too clever memory model and allow to simply allocate data on stack, something invented ~60 years ago.

WorldMaker3• 2 years ago

C# always supported stack allocations and always supported things like stack-based pointer operations. It just tagged a lot of it as "Unsafe" and/or required the `unsafe` language keyword (and concomitant security escalation in the old Framework security model where assemblies that used `unsafe` code needed additional code certificates to be installed into places like the GAC).

The "advanced" stuff is very much about bringing Rust-like lifetimes to the language and moving the powers and capabilities outside of the `unsafe` keyword world, by making it much less unsafe in similar ways to how Rust does lifetime/borrow-checking but converted to C#/CLR's classic type system. It's adding the "too clever" memory model of Rust to the much simpler memory model of a GC. (GCs are a very simple memory model invented ~70 years ago.)

CharlieDigital5• 2 years ago

The absolute best way to stay on top of C# changes is the "What's New" docs: https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...

Basically gives you a release-by-release highlight reel of what's changed and why it's changed.

I glance at it every release cycle to get an idea of what's coming up. The even numbered releases are LTS releases while the odd numbered releases (like the forthcoming 9) are short term. But the language and runtime are fairly stable now after the .NET Framework -> .NET Core turbulence and now runtime upgrades are mostly just changing a value in a file to select your target language and runtime version.

zero0529• 2 years ago

Is there a RSS feed for this? I can’t find it unfortunately

snoman• 2 years ago

There’s some YouTubers that regularly cover these if youre the type that enjoys watching it instead. Nick Chapsas is one I enjoy watching.

daxfohl3• 2 years ago

So why all the interest in rust, comparatively?

My assumption is since there is a GC, and it is not native code, there are too many use cases where it can't apply, but rust can. Once there is a way to have it compete with rust in every use case rust can be used, maybe there will be more talk.

neonsunset22• 2 years ago

What does .NET compile IL to? :)

stackghost• 2 years ago

Garbage collection doesn't imply interpreted. Common Lisp has had GC'ed compiled code for decades.

DeathArrow14• 2 years ago

How is it possible that I can write efficient and provably-safe code in C# without a degree in type theory?

Because Anders Hejlsberg is one of the greatest language architects and the C# team are continuing that tradition.

The only grudge I have against them is they promised us discriminated unions since forever and they are still discussing how to implement it. I think that is the greatest feature C# is missing.

For the rest C# is mostly perfect. It has a good blend of functional and OOP, you can do both low level and high level code. You can target both the VM or the bare hardware. You can write all types of code beside system programming (due to the garbage collector). But you can do web backend, web front-end, services, desktop, mobile apps, microcontroller stuff, games and all else. It has very good libraries and frameworks for whatever you need. The experience with Visual Studio is stellar.

And the community is great. And for most domains there is generally only one library or framework everybody uses so you not only don't have to ask what to use for a new feature or project, but you also find very good examples and help if you need.

It feels like a better, more strait trough version of Java, less verbose and less boiler plate-y. So that's why .NET didn't need its own Kotlin.

Sure, it can't meet the speed of Rust or C# for some tasks because of the garbage collector. But provided you AOT compule, disable the garbage collector and do manual memory management, it should.

jabwd• 2 years ago

Except that the GC makes it exactly not viable for games and its one of the biggest problems Unity devs run into. I agree it's a great language, but its not a do it all.

neonsunset22• 2 years ago

Unity (and its GC) is not representative of the performance you get with CoreCLR.

The article discusses ref lifetime analysis that does have relationship with GC, but it does not force you into using one. Byrefs are very special - they can hold references to stack, to GC-owned memory and to unmanaged memory. You can get a pointer to device mapped memory and wrap it with a Span<T> and it will "just work".

SeasonalEnnui2• 2 years ago

I could argue the opposite - GC makes it more viable for games. "GC is bad" misses too much nuance. It goes like this: developer very quickly and productively gets minimum viable game going using naive C# code. Management and investors are happy with speed of progress. Developers see frame rate stutters, they learn about hot path profiling, gen0/1/2/3 GC & how to keep GC extremely fast, stackalloc, array pooling, Span<T>, native alloc; progressively enhancing quickly until there are no problems. These advanced concepts are quick and low risk to use, and in the case of many of the advanced concepts; what you would be doing in other languages anyway.

greener_grass• 2 years ago

not viable for games
Unity devs run into

So it's viable but not perfect

DeathArrow14• 2 years ago

one of the biggest problems Unity devs run into

Unity used Mono. Which wasn't the best C# implementation, performance wise. After Mono changed its license, instead of paying for the license, Unity chose to implement their infamous IL2CPP, which wasn't better.

Now they want to use CoreCLR which is miles better than both Mono and IL2CPP.

Paradigma11• 2 years ago

Doesnt Unity use its own GC or transpiles to C++? Unity on .Net core is more than a year away, no?

bob10294• 2 years ago

GC in modern .NET runtime is quite fast. You can get very low latency collections in the normal workstation GC mode.

Also, if you invoke GC intentionally at convenient timing boundaries (I.e., after each frame), you may observe that the maximum delay is more controllable. Letting the runtime pick when to do GC is what usually burns people. Don't let the garbage pile up across 1000 frames. Take it out every chance you get.

pjmlp10• 2 years ago

Except that is a matter of developer skill, and Unity using Mono with its lame GC implementation, as proven by CAPCOM's custom .NET Core fork based engine used for Devil May Cry on the PlayStation 5.

lmm2• 2 years ago

Many of the top games in recent years have used it, so you've got a funny definition of "not viable".

rafaelmn3• 2 years ago

C# has much better primitives for controlling memory layout than Java (structs, reified generics).

BUT it's definitely not a language designed for no-gc so there are footguns everywhere - that's why Rider ships special static analysis tools that will warn you about this. So you can keep GC out of your critical paths, but it won't be pretty at that point. But better than Java :D

zigzag31211• 2 years ago

Games would need alternative GC optimized for low latency instead of maximum throughput.

AFAIK it has been possible to replace the GC with alternative implementation for the past few years, but no one has made one yet.

EDIT: Some experimental alternative GC implementations:

https://github.com/kkokosa/UpsilonGC

https://www.codeproject.com/Articles/5372791/Implementing-a-...

lifthrasiir5• 2 years ago

At least for Unity, the actual problem lies in IL2CPP and not C#. I have professionally used C# in real-time game servers and GC was never a big issue. (We did use C++ in the lower layer but only for the availability of Boost.Asio, database connectors and scripting engines.)

alkonaut9• 2 years ago

It's hard to use C# without creating garbage. But it's not impossible. Usually you'd just create some arenas for your important stuff, and avoid allocating a lot of transient objects such as enumerators etc. So long as you can generate 0 bytes of allocation each frame, you won't need a GC no matter how many frames you render. The question is only this: does it become so convoluted that you could just as well have used C++?

Rohansi5• 2 years ago

Unity has literally the worst implementation of C# out there right now. Not only is it running Mono instead of .NET (Core) but it's also not even using Mono's generational GC (SGen). They have been working on switching from Mono to .NET for years now because Mono isn't being updated to support newer C# versions but it will also be a significant performance boost, according to one of the Unity developers in this area [1].

IL2CPP, Unity's C# to C++ compiler, does not help for any of this. It just allows Unity to support platforms where JIT is not allowed or possible. The GC is the same if using Mono or IL2CPP. The performance of code is also roughly identical to Mono on average, which may be surprising, but if you inspect the generated code you'll see why [2].

[1] https://xoofx.github.io/blog/2018/04/06/porting-unity-to-cor... [2] https://www.jacksondunstan.com/articles/4702 (many good articles about IL2CPP on this site)

jayd164• 2 years ago

The two biggest engines, Unreal and Unity, use a GC. Unity itself uses C#. C# is viable for games but you do need to be aware of the garbage you make.

It's really not that hard to structure a game that pre-allocates and keeps per frame allocs at zero.

_7acn2• 2 years ago

What do you think about F#, then? It already covers everything you mentioned and it has discriminated unions.

rafaelmn3• 2 years ago

Basically C# is like using a Mac and F# is "I use Arch btw."

ZeroClickOk• 2 years ago

No partial classes is painful. I know that we have some alternatives, but migrating from C# is a doom without it.

DeathArrow14• 2 years ago

I absolutely love F#! Two things though: adoption is low so you kind of can't use it professionally and most libraries are written in C#, so you kind of use them in a non idiomatic way.

zigzag31211• 2 years ago

The only grudge I have against them is they promised us discriminated unions since forever and they are still discussing how to implement it. I think that is the greatest feature C# is missing.

To ease the wait you could try Dunet (discriminated union source generator).

https://github.com/domn1995/dunet

CharlieDigital5• 2 years ago

There's also OneOf (https://github.com/mcintyre321/OneOf) as well which feels more ergonomic to me (having used both).

Practical example in a short write up here: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

whizzter2• 2 years ago

I'm hardly missing discriminated unions (sure exhaustive checking would be nice) anymore since the introduction of switch expressions that in combination with records handles most practical cases.

CharlieDigital5• 2 years ago

I find DU's particularly useful with `System.Threading.Channels` because it lets the channel handle multiple types of results in one stream.

GTP4• 2 years ago

How does C# fares in terms of portability these days? I checked years ago, and at the time, for non-Windows OSes you had to use Mono. But whether your application was going to work or not also depended on which graphic libraries you were using, e.g. WinForms wasn't going to work on Mono. At the time, C# was presented to me as a better Java, but to me it seemed that Java had true cross-platform compatibility while C# was going to work nicely only on Windows, unless you had some proper planning of checking beforehand which libraries were working with Mono.

Rizu• 2 years ago

you should checkout AvalonuiaUI[0] or unoPlatform[1] if wanting to target web/mobile/window/linux/macOS

if building for the web online, asp.net core runs on Linux servers as well as windows

and there's MAUI [2] ( not a fan of this), you are better-off with with the others.

in summary c# and .NET is cross-platform, third party developers build better frameworks and tools for other platform while Microsoft prefers to develop for Microsoft ecosystem, if you get

[0] https://avaloniaui.net/ [1] https://platform.uno/ [2] https://learn.microsoft.com/en-us/dotnet/maui/what-is-maui?v...

CharlieDigital5• 2 years ago

Very good.

I work at one of the few startups that uses C# and .NET.

Dev machines are all M1/M3 MacBook Pros and we deploy to a mix of x64 and Arm64 instances on GCP and AWS.

I use VS Code on macOS while the rest of the team prefers Rider.

Zero friction for backend work and certainly more pleasant than Node. (We still use Node and JS for all front-end work).

lwansbrough• 2 years ago

.NET is totally cross platform these days. Our company develops locally on Windows and deploys to Linux. I’m the only team member on Mac and it works flawlessly.

SirMaster• 2 years ago

I mean since Mono it has completely changed. They are about to release .NET 9 which is the 8th version (there was no v4 to reduce confusion with the legacy .NET Framework) since being cross-platform.

Mono was a third party glorified hack to get C# to work on other OS. .NET has been natively cross platform with an entirely new compiler and framework since mid 2016.

WorldMaker3• 2 years ago

Back in the day Mono had surprisingly good WinForms support on Gtk. It was never going to win awards for pretty and could never hit true compatibility with P/Invoke calls to esoteric Win32 APIs, but it was good enough to run any simple WinForms app you wanted to write for it and ran some of the "popular" ones just fine. (That old Mono WinForms support was recently donated to Wine, which seems like a good home for it.)

.NET has moved to being directly cross-platform today and is great at server/console app cross-platform now, but its support for cross-platform UI is still relatively nascent. The official effort is called MAUI, has mostly but not exclusively focused on mobile, and it is being developed in the open (as open source does) and leaves a lot to be desired, including by its relatively slow pace compared to how fast the server/console app cross-platform stuff moves. The Linux desktop support, specifically, seems constantly in need of open source contributors that it can't find.

You'll see a bunch of mentions of third-party options Avalonia and Uno Platform doing very well in that space, though, so there is interesting competition, at least.

dachris2• 2 years ago

If you're doing ASP.NET Core webdev, it's seamless. Runs in Linux docker containers. Developers in my team have either Windows (Visual Studio) or Linux or Mac (Rider) machines.

giancarlostoro2• 2 years ago

Weird, I opened a binary I built years ago on Windows in Mono, and it was Winforms and rendered correctly, I think you mean WPF and the later GUI techs. Winforms renders nicely on Mono for a little while now I think?

There's a lot of options, but also the latest of .NET (not Framework) just runs natively on Linux, Mac and Windows, and there's a few open source UI libraries as mentioned by others like Avalonia that allow your UI to run on any OS.

factormeta2• 2 years ago

The experience with Visual Studio is stellar.

I assume you mean just the Windows Visual Studio? The Mac version is not exactly on par with the Windows. Yeah C# is great, but one would need Window's version of VS (NOT VS Code) to take full advantage of C#. For me that is a deal breaker, when the DX of a language is tight to a proprietary sourced IDE by MS.

moomin3• 2 years ago

These days, JetBrains have stepped into the gap with Rider. Rider isn't perfect, but there's definitely people who prefer it to Visual Studio.

alkonaut9• 2 years ago

Mac visual studio isn't visual studio, it's something else that they stuck the label visual studio on. They are about as related as java and javascript (which are famously, related as car is to carpet)

uticus3• 2 years ago

Incidentally JetBrains Rider (competitor IDE) announced as free today for non-commercial, if you’d like to try it out:

https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-ride...

[edit: I’ll note I’ve used successfully both Win and Linux]

alkonaut9• 2 years ago

The DU stuff is enormous once you consider all the corners it touches. Especially with refinements. E.g. in code like

if (s is string or s is int) { // what's the type of s here? is it "string | int" ? }

And not to mention that the BCL should probably get new overloads using DU's for some APIs. But there is at least a work in progress now, after years of nothing.

colejohnson66• 2 years ago

One of the claimed benefits of .NET Core was that they could improve the runtime at a much faster pace than .NET Framework did, especially if that meant adding new features or even IL opcodes. And they've done this before, with a big one (IMO) being ref fields in ref structs. Lately, when it comes to developing C#, the language design team has frustratingly been trying to shoehorn everything into the compiler instead of modifying the runtime. Then they say the runtime should be modified to pattern-match what they output. If DUs are to be implemented fully in C#, niches would probably be impossible. This means Optional<T>, when T is a class, would take two words.

pif2• 2 years ago

For the rest C# is mostly perfect.

No, it isn't. The power of C++ templates is still astronomically far from C# generics.

roetlich3• 2 years ago

Yes, another plus point of C#.

Sorry for the snark, but I do think C# compile are just barely acceptable for me, so I'm happy they aren't adding more heavy compile time features.

lifthrasiir5• 2 years ago

That power is usually considered too reckless to retain and simultaneously too cumbersome to actually use, partly because it was never planned in the first place.

jayd164• 2 years ago

What about the built in Roslyn source generator stuff? Is that sufficiently abusable?

I'm not a templates/macro guy so I'm curious what's missing.

nick_2• 2 years ago

There are pros and cons. C++ templates can't be reified at run-time like C# generics can.

DeathArrow14• 2 years ago

I don't miss that power. I remember having to modify some template heavy code and it brought me to the verge of madness. :)

phito• 2 years ago

I'm so glad it doesn't. There is absolutely no need for it and when it's used it usually makes a big mess. It goes in the same pile as multiple inheritance.

pif2• 2 years ago

For the rest C# is mostly perfect.

No! It misses "typedef", both at module API level and within generics.

algorithmsRcool8• 2 years ago

Because Anders Hejlsberg is one of the greatest language architects and the C# team are continuing that tradition.

I wish Anders was still in charge of C# :(

nick_2• 2 years ago

Fingers crossed that he'll one day come back and make T#

yndoendo• 2 years ago

My long term experience with Visual Studio is the inverse of stellar.

In order to submit bugs with Microsoft the application redirects the end user to their website with web socket. The company I work for has extra security and this breaks preventing me from filing a cornucopia of bugs with Visual Studio. I cannot even file a bug on how the submit system is broken with Visual Studio.

Closing and re-opening Visual Studio is a daily task. Most often during code refactoring of multiple parts. Creating new classes has inconsistency of template usage in the second most recent released version. Compile error message history can become stale and inconsistent where the output console does not. Pasting content into the resource manager is still broken during tab entry. Modal dialogs still cover the screen during debug. And those don't even touch the inconstant and buggy user experience.

C# is a tool and like all tools it is good for some things and really bad for others. No tool is perfect. You can still use a ball-peen hammer for roofing but be better to have a roofing hammer. I would use Swift on iOS and Kotlin on Android for those platform projects, I don't even know those languages, and wouldn't use C#.

yeputons• 2 years ago

How is it possible that I can write efficient and provably-safe code in C# without a degree in type theory?

Because of two things mentioned in the article just below.

Here we see C#’s first trade-off: lifetimes are less explicit, but also less powerful.

If C# is less powerful, it does not need powerful syntax. One does not need explicit lifetimes in Rust for a long time either, deduction work just fine.

The escape hatch: garbage collection

If C# is ok with not tracking _all_ lifetimes _exactly_, it does not need powerful syntax. Not an option in Rust, by design.

Basically, not all code is possible to write, and not all code is as efficient.

daxfohl3• 2 years ago

Both have "unsafe" escape hatches, so all code is possible to write efficiently. Just some cases are harder to prove correct in the type systems of each.

sirwhinesalot2• 2 years ago

The sort of "borrow checking" C# does is also similar to what the lifetime profile for C++ tries to do to catch bugs (but that's sadly a bit of a shitshow, existing C++ code is too much of a mess).

A related idea are the concept of second class references, as exist in Hylo. There the "ref" is not part of the type, but the way they work is very similar.

Lifetimes give you a lot of power but, IMO, I think languages that do this should choose between either being fully explicit about them, or going "second class" like C# and Hylo and avoiding lifetime annotations entirely.

Eliding them like Rust does can be convenient for experts but is actually a nightmare for newbies. For an example of a language that does explicit lifetimes without becoming unbearable, check out Austral.

Instead of C#'s scope ref solution to having a function accept and return multiple references, another option (in an imaginary language) would be to explicitly refer to the relevant parameters:

ref(b) double whatever(ref Point a, ref Point b) { return b.x; }

pjmlp10• 2 years ago

In theory, unfortunately VC++ and clang implementations since 2015 still leave too much off the table for us to fully rely on their lifetime static analysis.

nickitolas• 2 years ago

You're correct that as far as I understand it the analysis propsoed by the C++ Lifetime Safety Profile is similar in many ways, however I think there's a few important distinctions with these C# features that are not directly related to the analysis: The C++ safety profilers are trying to be backwards compatible with as much C++ code as possible. Whereas my understanding is most of what's talked about in this post is sort of a clean break from idiomatic C#, and is not changing the semantics or adding new warnings to any pre-existing code. Another difference is that C++ obviously does not have a built in runtime GC, so the situations mentioned in this post that get "fixed" by GC heap allocation would remain an issue.

sirwhinesalot2• 2 years ago

Yes, I only meant that the way they work (meaning how the "lifetimes" are tracked) is very similar.

C++ has to be "best effort" because it tries to bolt these semantics onto the pre-existing reference types, which were never required to adhere to them. It can catch some obvious bugs but most of the time you'll get a pile of false positives and negatives.

PoignardAzur• 2 years ago

Cool article!

Quick nitpick: the find example could return a reference to a static variable, and thus avoid both the heavy syntax and the leaked allocation:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Arnavion• 2 years ago

It doesn't even need to be a `static`. It can be `const` or just inlined `&0` because borrows of consts get promoted to `'static`

raverbashing• 2 years ago

How is it possible that I can write efficient and provably-safe code in C# without a degree in type theory?

Excellent question

And I feel that Rust, by making it explicit, makes it harder and unergonomic on the developer

Decabytes2• 2 years ago

My biggest issue with C# is that it doesn't have a good cross platform GUI. Maui dev is too slow and lacks a lot of the features a lot of people want, and Avalonia still uses the hybrid axml approach that just feels bad. I wish C# had a Flutter like library that utilized C#'s Hot Reload features

zigzag31211• 2 years ago

I agree. Avalonia tries too much to be like WPF, but in my opinion, WPF was two steps forward and one step back (mainly due to XAML).

neonsunset22• 2 years ago

You have Avalonia, Uno Platform and, yes, MAUI. Most cross-platform GUI frameworks are flawed regardless of the language. The ones .NET has are decent, with various ways to approach the UI wiring - you have both XAML and declarative SwiftUI-style (and with MVU pattern too) options. Avalonia even has F# support through FuncUI. There are also plenty of bindings for SDL2, there's GTK# successor Gir.Core.

I wish the comments focused more on the subject of the article which is interesting and under-discussed.

fire_lake• 2 years ago

MAUI is the official one but Linux support AFAICT? Such a shame!

kkukshtel2• 2 years ago

Using something like Photino (https://www.tryphotino.io) with Blazor can start to feel like an actual good C# cross plat GUI solution but even as a C# truther I agree with you.

I think you'll start seeing a lot more "cross platform C# frameworks" when PanGUI drops: https://pangui.io

It's a native layout/gui util by the devs of the mega-popular Odin extension in Unity, and the idea is to directly solve "good native c# gui lib" with the implementation just being a single shader and an API that is more like DearIMGUI.

I'm also planning on using it my own small 2D C# engine when it's available: https://github.com/zinc-framework

I already do iterative hot reload GUI with DearImGUI in that engine so PanGUI will work in the same way.

noveltyaccount• 2 years ago

Photino sounds almost identical to Maui Blazor Hybrid. Do you know the difference?

fireant• 2 years ago

Pangui seems really cool. Especially since it's from people developing Unity plugins so we could get good GUI for games too.

InvisGhost• 2 years ago

re: PanGui, it seems nice but the fact that they don't even have "accessibility" in their docs means it really shouldn't become widely used until they address that. It would be a big step backwards and one that is unacceptable in these modern times.

Unfortunately, the way they've designed it without accessibility in mind from the start means it's unlikely ever to be anything other than an after thought.

aero_code• 2 years ago

Besides the other GUI libraries people have mentioned, there is also Eto: https://github.com/picoe/Eto

not2b• 2 years ago

For the first example, for C or C++ code gcc will catch the dangling reference/pointer and warn about it, and since my group normally turns on -Wall -Werror, it's an error. However, the analysis is local and not as powerful as Rust's borrow checker.

Try int* bug() { int longlived = 12; int* plonglived = &longlived; { int shortlived = 13; plonglived = &shortlived; } return plonglived; }

With gcc -Wall -Werror

akira25013• 2 years ago

The defaults can also be unintuitive: say we wanted to write a method on a struct which returns a reference to one of the struct’s members.

Why would you do that?

n fact, this is so common that Rust doesn’t require you to write the lifetimes explicitly

This is an actual _pattern_? Yikes^2.

0x4574• 2 years ago

Why would you do that?

a getter?

This is an actual _pattern_? Yikes^2.

wat.

akira25013• 2 years ago

a getter?

Getters return values. This returns a pointer. So it's an accessor. With unchecked semantics. It's bizzare to me that anyone would use this technique. It's all downside with no upside.

wat.

I'm expressing surprise that anyone would do this. I'm sure you were capable of understanding that.

lowleveldesign• 2 years ago

I feel that nowadays Rust is the language to go when you are doing system programming, but C# is not a bad choice either. With .NET 9 being released in a few weeks we will get NativeAOT (compilation to a native single binary) for x86 (x64 and ARM64 are already available). At work, I'm writing patches for legacy apps and needed to use C++ for most of my tasks. Nowadays, I'm doing more and more stuff in C# and enjoying it. For WinAPI there is a fantastic cswin32 [1] project that generates FFIs signatures on the fly. And it's fairly simple to extend it for other Windows libraries (I did it for detours [2], for example). And using pointers or working with native memory blocks is straightforward and intuitive for people with C/C++ background.

[1] https://github.com/microsoft/CsWin32

[2] https://lowleveldesign.wordpress.com/2024/07/11/implementing...

starquake• 2 years ago

Although NativeAOT sounds cool and it's better than nothing: I don't like that it comes with a bunch of limitations[1]. I would have loved this if you could just use it without any changes, but I'm very worried that at some point I used something that prevents me from getting it to work and I have to figure out which limitation I just walked into. Correct me if I'm wrong.

[1] https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

Kwpolska3• 2 years ago

Those limitations are often obvious. With AOT, you don't have the VM around, you can't load new bytecode or introspect the objects. I would focus on writing working code, and try to go AOT close to the end. If it fails and it's not fixable, tough luck, but it works on the standard runtime.

Salgat• 2 years ago

With source generation, I'd say that its biggest limitation is rapidly diminishing. Even ASP.NET Core is embracing it, allowing for better support for json deserialization and eventually MVC.

two_handfuls2• 2 years ago

Things could have gone so much differently if they had committed early on to being cross-platform.

Instead, its growth was stunted and many people avoid it even though it is an excellent language.

A comparison of Rust’s borrow checker to the one in C#

Related Stories