4 ms·

Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed lang

Huh, I did F# for years with discriminated unions, and I guess I just assumed C# would have had them by now. I know not everyone likes them, but for typed languages I find it extremely hard to go back to languages without ADTs of some kind. I do Java for my current job, and Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines of F#.

Eji1700 2y ago
F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in. Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.
- ctenb 2y ago
  It makes sense from a language adoption standpoint, especially if you look at typescript for example, which is also by Microsoft. Though I agree with you personally
- tombert 2y ago
  I agree; F# is probably my favorite of the "compromise" functional languages [1], where you can drop into the "wrong" way when necessary. F# pushes a more or less pure approach, but in some cases, like when mutation will be a bit easier and/or faster, it's easy to do that as well. I also think that even F#'s OOP is actually really pleasant...If nothing else, it's a lot more terse than C#'s. I miss writing it; I haven't had a job using it in a few years but I really enjoyed writing code in it when I did. Most of my personal projects haven't really been able to use .NET for awhile, so I never seem to have an excuse to play with F# in my personal time. I never got into C#, so I can't say that I really feel the pain of the C# transition into F#. [1] At least in the typed world. I'm also really partial to Clojure.
- kriiuuu 2y ago
  I feel the same about Scala. I use Scala3 daily and almost every other language is such a step back. I have looked at F# and it looks like one of the only other languages I would enjoy as much as Scala. Haskell is nice too, but the ecosystem is just not quite there. F# being able to tap into the rich C# ecosystem and Scala being able to tap into the Java ecosystem is such a win and makes them feel a lot less niche when you use them.
  - tombert 2y ago
    I do like Scala, and I haven't touched Scala3, but I've found it pretty unwieldy for actual use. It feels like I'm constantly fighting with the type system in a way that ends up being annoying an unpleasant. To be clear, it's not like I'm new to functional languages and their type systems, I've been doing Haskell for forever, and I did F# for a multiple years, but Scala has never really clicked for me. Personally, for doing JVM stuff, I'm a pretty die-hard Clojure advocate. I feel like it's easy for me to write Clojure in the way that I think, while still allowing me to mooch off the entire Java ecosystem, and if there are things that I don't like about the language it's really not that hard to macro in a new feature (though obviously this should be used sparingly). I definitely recommend giving F# a try. I think it's an extremely underrated language.
    - agent281 2y ago
      > I definitely recommend giving F# a try. I think it's an extremely underrated language. Do you have any recommendations for people who do not have C#/.NET experience who want to rip their toes in F#? The last time I tried the language I bumped my head on the .NET parts. :/
      - tombert 2y ago
        Out of curiosity, what confused you about the .NET stuff? I didn't have any .NET experience going into F# either [1] and I didn't find it too hard to pick up the .NET stuff. For the most part I didn't need most of the built in .NET libraries; the F# stuff was fine, but the ones I ended up using a lot were the threadsafe libraries for when I needed mutation across threads. ConcurrentDictionary was one I used an awful lot, ConcurrentBag occasionally, SemaphorSlim, and Interlocked Incrementors. The reason that the .NET compatibility was handy to me was because it made it easy to get third party libraries without much fuss, which was great because they were generally pretty well supported. The rule of thumb that I used was that F#, while it kind of looks like Haskell, is not Haskell, and specifically it's not lazy, and as such I always kind of pretended I was in the `do` block. Things execute top down, and you can mix in side effects wherever, so you kind of have to pretend everything is in an IO monad, or at least if you see anything that has a side effect in there. [1] I was hired at Jet.com specifically because I had Haskell and Erlang experience prior. I had never written any significant C# code before.
- electroly 2y ago
  I'm glad they're simply turning C# into F#. They're coming to us where we are, rather than forcing us to make a jump. I'm a relatively "blue collar" developer, I know a little about FP (not enough to be productive in F#) but I have tons of C# experience. I appreciate them taking the good stuff from F# and making it understandable to C# developers. It's been a delightful progression; no big jumps, no paradigm shifts, just the steady addition of useful new features that I can understand.
  - Eji1700 2y ago
    So the issue for those of us in F# land, is that it's really not a big jump from C#. I've taught it (lightly) to at least one C# dev who basically picked it up in a weekend. Something that helps, a ton, is as you're transitioning, you can write code almost identically to how you did before. It doesn't force FP on you at all. It's less useful if you try to do that, because you're not taking advantage of the language, but it makes testing your beliefs on how things work SUPER easy because you can set it up in the OOP way, get the result you expect, then set up in what you think is the correct FP way, and see if it matches. The only issue is there's a severe lack of beginner friendly documentation (although it's leagues better than it used to be). I honestly think that if you're a C# dev, it's probably worth giving it a weekend or two to play with. ESPECIALLY if you like linq syntax.
  - progmetaldev 2y ago
    I agree with you, as far as adding new features to C# from F#. When I have the time to refactor larger codebases, I'm often finding new C# features/syntax makes the code easier to understand and reason about (often due to decreasing the number of lines needed to accomplish the same thing, without overcomplicating things). I do make sure that if I'm introducing new language features, that I'm refactoring related portions of code, so I'm not leaving behind the "old" way of doing things while also introducing the "new" way for the same functionality. I'm always thinking of the next developer with anger issues coming into the codebase after me.
  - freilanzer 2y ago
    > I'm glad they're simply turning C# into F#. I'm not. I find F#s syntax much more pleasing and elegant, and I'm afraid F# will wither away when C# is a watered down version of it.
- kbgart 2y ago
  Looking at the syntax in the type union proposal, I hope they take a bit more from F#. It really needs some work.
  - ctenb 2y ago
    What are some issues you see with the current proposal?
kriiuuu 2y ago
Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is
- tombert 2y ago
  Yeah, I know, and I have started using those, though that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option. Still, good to see Java joining the 21st century at least.
  - cies 2y ago
    > that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option. Same for C# with this new feature. Sum types (as I like to call tagged/type unions) are such an important tool to have, not having it makes languages resort to all kinds of abominations, e.g. exceptions, product types (= records, structs, etc) that are actually sum types, "null to signify something went wrong", etc. Not having them from a language's start results in an std lib that does not use them and hence teaches new comer to the language a bad way to do it.
- karmakaze 2y ago
  Java can't do the ad-hoc mixing of types from different libraries, which is something I've wanted/needed for some ORM+expressions work I was doing. I really like where C# is going with this. Hopefully it will accelerate continuation of the evolution of Java. I'm almost of the mind to use F# or C# instead of waiting.
  - bad_user 2y ago
    Those are untagged union types and are less useful than you think. For one, they don't work for generic code where you want to discriminate. I.e., if you have a generic A or B type, you can't pattern match on it. And it's hard to add restrictions to the generic types such that it would work. Such types sort of work in TypeScript, but TypeScript also has structural typing, meaning that it's designed for it.
Arnavion 2y ago
As of 2020 (when I stopped using F# and .Net in general), the CLR only had inheritance and F#'s enums were actually implemented using inheritance. Eg Some and None were derived classes of Option class. You would see it if you inspected an F# assembly in a decompiler. I don't know if it's still the same today. This C# proposal has anonymous enums using `A or B` syntax which would be hard to make work as sugar over inheritance, so I guess the CLR would support enums first-class for this to work (if it doesn't already).
- tkubacki 2y ago
  what's is your .NET replacement ?
- Lanayx 2y ago
  This is only partially true. Both Some and None were always instances of single FSharpOption class (None is actually not an instance, but null), however custom DUs are indeed compiled into classes with inheritance
  - Arnavion 2y ago
    Ah, then I misremembered.
bad_user 2y ago
FYI, Java has tagged union types (since version 16). Pattern matching too.
sideeffffect 2y ago
> Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines This is a weird take, given that Java has had ADTs for years Records https://en.wikipedia.org/wiki/Java_version_history#Java_16 https://en.wikipedia.org/wiki/Java_version_history#Java_16 Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17 https://en.wikipedia.org/wiki/Java_version_history#Java_17 And pattern matching for almost a year https://en.wikipedia.org/wiki/Java_version_history#Java_21 https://en.wikipedia.org/wiki/Java_version_history#Java_21 Otherwise big agree on how delightful to work with F# is.
- tombert 2y ago
  Most of my jobs until recently have been using Java 11, so I didn’t get to use these things.
  - sideeffffect 2y ago
    I see. But no hope is lost! You can always lean on Scala. It runs fine on any Java >= 8 and it's great. Unless you intentionally used is badly (but you could say that about any language).
johnzabroski 2y ago
Hmm. You find it hard to go back to languages without ADTs yet you use Java for your day job. Okay.

Eji1700 2y ago

F# is so hard to walk back from. I wish Microsoft would support it better and actually push it, because it's such a perfect sweet spot. Most of the functional advantages without being shackled to pure functions and the like is so easy to develop in. Instead they've been, very slowly, turning C# into F#, which is even weirder to watch.

ctenb 2y ago
It makes sense from a language adoption standpoint, especially if you look at typescript for example, which is also by Microsoft. Though I agree with you personally
tombert 2y ago
I agree; F# is probably my favorite of the "compromise" functional languages [1], where you can drop into the "wrong" way when necessary. F# pushes a more or less pure approach, but in some cases, like when mutation will be a bit easier and/or faster, it's easy to do that as well. I also think that even F#'s OOP is actually really pleasant...If nothing else, it's a lot more terse than C#'s. I miss writing it; I haven't had a job using it in a few years but I really enjoyed writing code in it when I did. Most of my personal projects haven't really been able to use .NET for awhile, so I never seem to have an excuse to play with F# in my personal time. I never got into C#, so I can't say that I really feel the pain of the C# transition into F#. [1] At least in the typed world. I'm also really partial to Clojure.
kriiuuu 2y ago
I feel the same about Scala. I use Scala3 daily and almost every other language is such a step back. I have looked at F# and it looks like one of the only other languages I would enjoy as much as Scala. Haskell is nice too, but the ecosystem is just not quite there. F# being able to tap into the rich C# ecosystem and Scala being able to tap into the Java ecosystem is such a win and makes them feel a lot less niche when you use them.
- tombert 2y ago
  I do like Scala, and I haven't touched Scala3, but I've found it pretty unwieldy for actual use. It feels like I'm constantly fighting with the type system in a way that ends up being annoying an unpleasant. To be clear, it's not like I'm new to functional languages and their type systems, I've been doing Haskell for forever, and I did F# for a multiple years, but Scala has never really clicked for me. Personally, for doing JVM stuff, I'm a pretty die-hard Clojure advocate. I feel like it's easy for me to write Clojure in the way that I think, while still allowing me to mooch off the entire Java ecosystem, and if there are things that I don't like about the language it's really not that hard to macro in a new feature (though obviously this should be used sparingly). I definitely recommend giving F# a try. I think it's an extremely underrated language.
  - agent281 2y ago
    > I definitely recommend giving F# a try. I think it's an extremely underrated language. Do you have any recommendations for people who do not have C#/.NET experience who want to rip their toes in F#? The last time I tried the language I bumped my head on the .NET parts. :/
    - tombert 2y ago
      Out of curiosity, what confused you about the .NET stuff? I didn't have any .NET experience going into F# either [1] and I didn't find it too hard to pick up the .NET stuff. For the most part I didn't need most of the built in .NET libraries; the F# stuff was fine, but the ones I ended up using a lot were the threadsafe libraries for when I needed mutation across threads. ConcurrentDictionary was one I used an awful lot, ConcurrentBag occasionally, SemaphorSlim, and Interlocked Incrementors. The reason that the .NET compatibility was handy to me was because it made it easy to get third party libraries without much fuss, which was great because they were generally pretty well supported. The rule of thumb that I used was that F#, while it kind of looks like Haskell, is not Haskell, and specifically it's not lazy, and as such I always kind of pretended I was in the `do` block. Things execute top down, and you can mix in side effects wherever, so you kind of have to pretend everything is in an IO monad, or at least if you see anything that has a side effect in there. [1] I was hired at Jet.com specifically because I had Haskell and Erlang experience prior. I had never written any significant C# code before.
electroly 2y ago
I'm glad they're simply turning C# into F#. They're coming to us where we are, rather than forcing us to make a jump. I'm a relatively "blue collar" developer, I know a little about FP (not enough to be productive in F#) but I have tons of C# experience. I appreciate them taking the good stuff from F# and making it understandable to C# developers. It's been a delightful progression; no big jumps, no paradigm shifts, just the steady addition of useful new features that I can understand.
- Eji1700 2y ago
  So the issue for those of us in F# land, is that it's really not a big jump from C#. I've taught it (lightly) to at least one C# dev who basically picked it up in a weekend. Something that helps, a ton, is as you're transitioning, you can write code almost identically to how you did before. It doesn't force FP on you at all. It's less useful if you try to do that, because you're not taking advantage of the language, but it makes testing your beliefs on how things work SUPER easy because you can set it up in the OOP way, get the result you expect, then set up in what you think is the correct FP way, and see if it matches. The only issue is there's a severe lack of beginner friendly documentation (although it's leagues better than it used to be). I honestly think that if you're a C# dev, it's probably worth giving it a weekend or two to play with. ESPECIALLY if you like linq syntax.
- progmetaldev 2y ago
  I agree with you, as far as adding new features to C# from F#. When I have the time to refactor larger codebases, I'm often finding new C# features/syntax makes the code easier to understand and reason about (often due to decreasing the number of lines needed to accomplish the same thing, without overcomplicating things). I do make sure that if I'm introducing new language features, that I'm refactoring related portions of code, so I'm not leaving behind the "old" way of doing things while also introducing the "new" way for the same functionality. I'm always thinking of the next developer with anger issues coming into the codebase after me.
- freilanzer 2y ago
  > I'm glad they're simply turning C# into F#. I'm not. I find F#s syntax much more pleasing and elegant, and I'm afraid F# will wither away when C# is a watered down version of it.
kbgart 2y ago
Looking at the syntax in the type union proposal, I hope they take a bit more from F#. It really needs some work.
- ctenb 2y ago
  What are some issues you see with the current proposal?

kriiuuu 2y ago

Good news is that you can achieve this with relatively little boilerplate in Java with sealed interfaces and records now. Relative to Java that is

tombert 2y ago
Yeah, I know, and I have started using those, though that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option. Still, good to see Java joining the 21st century at least.
- cies 2y ago
  > that doesn't undo the last 15 years of Java code that I've written where that wasn't really an option. Same for C# with this new feature. Sum types (as I like to call tagged/type unions) are such an important tool to have, not having it makes languages resort to all kinds of abominations, e.g. exceptions, product types (= records, structs, etc) that are actually sum types, "null to signify something went wrong", etc. Not having them from a language's start results in an std lib that does not use them and hence teaches new comer to the language a bad way to do it.
karmakaze 2y ago
Java can't do the ad-hoc mixing of types from different libraries, which is something I've wanted/needed for some ORM+expressions work I was doing. I really like where C# is going with this. Hopefully it will accelerate continuation of the evolution of Java. I'm almost of the mind to use F# or C# instead of waiting.
- bad_user 2y ago
  Those are untagged union types and are less useful than you think. For one, they don't work for generic code where you want to discriminate. I.e., if you have a generic A or B type, you can't pattern match on it. And it's hard to add restrictions to the generic types such that it would work. Such types sort of work in TypeScript, but TypeScript also has structural typing, meaning that it's designed for it.

Arnavion 2y ago

As of 2020 (when I stopped using F# and .Net in general), the CLR only had inheritance and F#'s enums were actually implemented using inheritance. Eg Some and None were derived classes of Option class. You would see it if you inspected an F# assembly in a decompiler. I don't know if it's still the same today. This C# proposal has anonymous enums using `A or B` syntax which would be hard to make work as sugar over inheritance, so I guess the CLR would support enums first-class for this to work (if it doesn't already).

tkubacki 2y ago
what's is your .NET replacement ?
Lanayx 2y ago
This is only partially true. Both Some and None were always instances of single FSharpOption class (None is actually not an instance, but null), however custom DUs are indeed compiled into classes with inheritance
- Arnavion 2y ago
  Ah, then I misremembered.

bad_user 2y ago

FYI, Java has tagged union types (since version 16). Pattern matching too.

sideeffffect 2y ago

> Java is generally fine enough, but it's a little annoying when I have to do whacky workarounds with wrapper classes to get something that would be done in three lines This is a weird take, given that Java has had ADTs for years Records https://en.wikipedia.org/wiki/Java_version_history#Java_16 https://en.wikipedia.org/wiki/Java_version_history#Java_16 Sealed classes https://en.wikipedia.org/wiki/Java_version_history#Java_17 https://en.wikipedia.org/wiki/Java_version_history#Java_17 And pattern matching for almost a year https://en.wikipedia.org/wiki/Java_version_history#Java_21 https://en.wikipedia.org/wiki/Java_version_history#Java_21 Otherwise big agree on how delightful to work with F# is.

tombert 2y ago
Most of my jobs until recently have been using Java 11, so I didn’t get to use these things.
- sideeffffect 2y ago
  I see. But no hope is lost! You can always lean on Scala. It runs fine on any Java >= 8 and it's great. Unless you intentionally used is badly (but you could say that about any language).

johnzabroski 2y ago

Hmm. You find it hard to go back to languages without ADTs yet you use Java for your day job. Okay.