←back to thread

201 points olvy0 | 9 comments | | HN request time: 0.63s | source | bottom
1. DeathArrow ◴[] 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 #
2. CharlieDigital ◴[] No.41879289[source]
You can largely already pretty easily incorporate DUs using OneOf[0] and Dunet[1].

A practical example of using this: https://chrlschn.dev/blog/2024/07/csharp-discriminated-union...

[0] https://github.com/mcintyre321/OneOf

[1] https://github.com/domn1995/dunet

3. stult ◴[] 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 #
4. fuzzy2 ◴[] No.41882449[source]
In a past project, we used Units.NET. It worked pretty well as far as I could tell. (I was not involved with the gritty domain details.) My colleagues even extended the library where units were missing.
5. Jordanpomeroy ◴[] 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 #
6. greggyb ◴[] No.41884425{3}[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.

7. throw234234234 ◴[] No.41885677[source]
I do find this an interesting thing often said in the .NET community. Yet the question "Why not just use F#" comes up in my head every time someone says this. C# has been playing catchup for many years.

If it is F# that is pushing a lot of innovation in the .NET ecosystem and many years in features ahead (at least it was a few years back) why not reward that effort through its use? We should encourage the behavior we want out of these language development teams after all by voting with our feet. Worked with the Java ecosystem for example - even Java now is improving. It would create a positive feedback loop (like most other innovative tech) where more market would create more engineering effort on it as well.

Reading these forum's over the years it feels like many C# people really want to stick in their camp and wait "just because" - it almost feels "tribal" and their team is "C#". I just don't see this culture in some other language ecosystems - makes me think if F# was in any other ecosystem than .NET it would of thrived a long time ago. That's just my impression though.

replies(1): >>41886450 #
8. DeathArrow ◴[] No.41886450[source]
>"Why not just use F#"

Because we don't really make choices and the C-level executives think that only C# or Java are worth using since they are the behemoths of the industry.

And I am quite content we don't have to use Java with all that object everything, factory factory factory and plainly insane "design patterns".

9. SeriousM ◴[] No.41903512[source]
It's an open secret and cited many times by officials (eg Hanselman) that F# is the testing playground for C# (and vb.net) features.