2 ms·
Lots of good stuff coming in .NET 8 and C# 12 - Primary constructors to simplify class declarations - Collection expressions to simplify initialization
by CharlieDigital 3y ago
Lots of good stuff coming in .NET 8 and C# 12
- 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.
- rahkiin 3y agoEFCore 8 is now able to do custom queries into on-demand types without views. This means you can drop to manually optimized queries at any time!
- CharlieDigital 3y agoEFCore is the sexiest ORM out there. Makes Prisma look like a toy. Too bad it doesn't get the hype that it deserves.
- throw1234651234 3y agoAs an EF expert, I don't have EF in my projects and use Dapper.
- CharlieDigital 3y agoI felt the same way about Dapper until I figured out how EF makes sense in my workflow. Way better experience with it now.
- ComputerGuru 3y agoThe 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.
- CharlieDigital 3y agoTo be fair, I think most devs aren't thinking about heap allocations; probably just want a collection. If one needs to initialize it with performance considerations in mind, it is still possible to do so.
- ComputerGuru 3y agoC# 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.
- neonsunset 3y agoSpeaking 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.