- Primary constructors to simplify class declarations
- Collection expressions to simplify initialization and make it more like JS/TS
- Finally ahead-of-time (AOT) compile support for Web APIs which should improve cold starts for microservices
- Lots of performance improvements
- EF Core still possibly the best ORM out there; super productive. Now with better JSON column type support.
C# and .NET is probably the stack that most teams should evaluate first when moving on from TypeScript and Node.
The new collection syntax is succinct and aesthetically pleasing but a step back in terms of functionality and information conveyance. The new syntax should have been introduced but reserved only for allocation-free (heap, that is) expressions where the result is a Span and kept the explicit new() requirement for any dynamic heap allocations.
As it is currently, the new collection syntax may result in dynamic heap allocations or it may not - it’s fully opaque.
C# devs are a bit less allocation-blind than in some other ecosystems due to the from-the-beginning distinction between value and object types, the availability of manual stack allocation, and a general awareness of the pathological behavior of some dev-friendly but performance-deadly LINQ expressions. The recent introduction and heavy focus on Span and Memory<T>, source generators, etc have also done much to raise awareness of dynamic allocations and runtime overhead. It’s in light of this that I view choosing to paper over allocations a misguided effort.
Speaking of LINQ, depending on your use case, I suggest re-evaluating the intuition regarding its performance in specific scenarios. Both .NET 7 and especially .NET 8 have seen a lot of work to improve the underlying performance of LINQ and thanks to DynamicPGO certain patterns that used to be very unfriendly to performance now have (sometimes significantly) lower cost. The speed-up depends on the use case but expect to see anything from 10% up to >200-400% improvement.
I still think Python is Lisp's revenge, after the way it went on AI Winter.
Everyone could be using a real powerful language, with JIT and AOT compilers, used to write full graphical workstations, instead they have to put up with writing bindings to C, C++, Fortran libraries.
However I still hope they get pressure enough to become more serious regarding JIT adoption in CPython.
The separate ML.NET project has never seen much traction or adoption. Perhaps this will succeed by making it possible to port existing ML frameworks or models instead.
I wonder if this will be welcomed by the community over a couple next years, but if it’s just another PR stunt for a PM or PO like ML.NET, I doubt this is a good idea to include it in .NET proper.
