←back to thread

Net 9.0 LINQ Performance Improvements

(blog.ndepend.com)
201 points olvy0 | 2 comments | 18 Oct 24 10:39 UTC | HN request time: 0.001s | source
Show context
DeathArrow ◴[18 Oct 24 13:00 UTC] No.41879035[source]▶
The more C# borrows from F#, the happier I am. I am awaiting for discriminated unions to finally reach C# so I can do domain modelling like a boss. :)
replies(4): >>41879289 #>>41880258 #>>41885677 #>>41903512 #
stult ◴[18 Oct 24 15:21 UTC] No.41880258[source]▶
I'd kill for units of measure too. It makes maintaining any kind of engineering or scientific code so much easier.
replies(2): >>41882449 #>>41882809 #
1. Jordanpomeroy ◴[18 Oct 24 19:44 UTC] No.41882809[source]▶
In my experience units of measure in technical apps is only interesting in the UI layer as most apps I’ve worked on have a “base” system of units that all calcs are expecting. What alternate experience have you seen?
replies(1): >>41884425 #
2. greggyb ◴[18 Oct 24 23:32 UTC] No.41884425[source]▶
Units of measure in F# are useful for more than unit conversion workloads.

They are compile-time type information with no runtime overhead. So if you're using a lot of interrelated arrays, you can make a unit of measure for indices into just a specific type of array. This allows type-level enforcement of never using the wrong index for the wrong array.

Anywhere you might want to keep categories (not category theory) of numeric values distinct from one another without intermixing, units of measure in F# can cover you.