Hacker News new | ask | show | jobs
by leosarev 589 days 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.

6 comments

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.

There’s some YouTubers that regularly cover these if youre the type that enjoys watching it instead. Nick Chapsas is one I enjoy watching.
Is there a RSS feed for this? I can’t find it unfortunately
For that, your best bet is https://devblogs.microsoft.com/dotnet/
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...

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.

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.

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.

Garbage collection doesn't imply interpreted. Common Lisp has had GC'ed compiled code for decades.
Or Go, for a more mainstream modern example.
Yeah but C# is. Or, compiled to IL and JITted. Unless there is an AOT thing now that can truly compete with c and rust. Been out of the ecosystem for a while.
What does .NET compile IL to? :)
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.
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.)

70 years ago the memory model was: keep all data in global static memory locations (Fortran). Then Algol and Pascal came around, implementing the stack memory model.
Lisp was released in 1958, same as Algol, and doing some form of garbage collection from that humble beginning.