6 ms·

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

by wk_end 2y ago

fluoridation 2y ago
I get the feeling F# is a second-class citizen in the ecosystem. How likely is it (or is it at all possible) that I'm going to run into some library that doesn't work with F#?
- nightski 2y ago
  None, it's a CLR after all. That said many libraries may not utilize the best features F# has to offer.
- antonyt 2y ago
  It's impossible for a .NET library to not work with F#. It's very possible (and even likely) for a .NET library to prevent you from writing idiomatic F#. You're right that it's a second-class citizen.
  - debugnik 2y ago
    > It's impossible for a .NET library to not work with F#. This isn't true, C# has been adding new ABI features that didn't interact correctly with F# until the compiler and tooling catched up. For example, the spanification of C# was a huge a pain point and it still is when it comes to tooling.
    - antonyt 2y ago
      TIL. Have links to any details about this? I'm very curious!
      - pjmlp 2y ago
        Stuff like Roslyn analysers, code generators and interceptors, only take C# semantics into account, the first one also works with VB.NET. Since its introduction that CLR has the notion of CLS, the Common Language Subset, that any language targeting the CLR should be able to understand. Anything in the MSIL or metadata, that isn't part of that, requires additional effort from the respective language to be able to expose those features, and many of the more recent improvements, are more in the sense of CLR meaning C# Language Runtime, than Common Language Runtime.
      - debugnik 2y ago
        You mostly have to look at the time frames between C# adding features with new ABIs and the time it takes for F# to announce they can actually consume them. For example, F# used to crash the CLR with InvalidProgramException when setting C# `init` properties. [1] It took almost three years, I think, to release the fix. [1]: https://github.com/fsharp/fslang-suggestions/issues/904 https://github.com/fsharp/fslang-suggestions/issues/904 Another rough example would be spans, and their more general feature, byref-like types (ref struct). These required plenty of compiler support, as they've got special lifetime rules (and more pending to implement `scoped`), they are banned as generic type arguments, and they require ignoring a special Obsolete attribute. While these were added to F# timely, many language features still break when they interact with them: local functions, computation expressions (even the built-in ones), recursive type inference, and generic intrinsic methods such as `raise`, `defaultof` or `typeof`. This wouldn't be so bad if C# hadn't "spanified" the shared framework and the entire ecosystem without CLS alternatives for many APIs. So, these natural F# snippets don't compile: let numbers = [| for span in text.EnumerateLines() -> Int32.Parse span |] let checkNonEmpty (span: ReadOnlySpan<'T>) = if span.Length > 0 then span else failwith "Expected non-empty span." Edit: And I haven't even gotten into the libraries that use reflection expecting you to declare types in ways F# doesn't support.
- Eji1700 2y ago
  Just to add to the other comments, in my experience a large majority of libraries work fine. Maybe a little tweak here or there, or maybe you need to use some C# esq syntax (which is harder in my case because I so rarely do now). Generally though, it's pretty easy. Sometimes you'll want to make bindings around various things (not that you need to, but it'll make things smoother). It's not actually awful, it's just that there's no real documentation of "hey today we're going to take Serilog/whatever and show you how to configure it in F#" style videos, so depending on where your weaknesses lie it can feel frustrating.
  - gopherchucks 2y ago
    My experience mirror yours. I really lean into the functional core, imperative shell because of this. Im mostly interacting with C# flavored libraries at the edges and I don’t try to force F# paradigms there, I just roll with the punches.
DaiPlusPlus 2y ago
The benefits of F# only really apply when using a 100% F# codebase. Try doing WinForms in F#...
- Eji1700 2y ago
  I mean that's mostly pretty easy bindings, but yeah it's annoying that you have to do them and feels like you're losing out on the whole damn point of using F#
- Archelaos 2y ago
  That F# has no native GUI framework is the reason why I stick with C#. When coding something with a GUI, the majority of my development time is typically spent in the GUI layer. The rest is some more or less straightforward object relational mapping with some validation an calculations in a business layer where I use Linq to emulate functional programming in C#. Adding F# to the game would only complicate the scenario, because I would need to connect the F# interfaces somewhere to C# anyway, requiring an additional layer of mappings in many cases.
  - neonsunset 2y ago
    There is! https://funcui.avaloniaui.net/ https://funcui.avaloniaui.net/
    - Archelaos 2y ago
      It is just a wrapper around Avalonia, which is written in C#.
      - neonsunset 2y ago
        It is (together with FuncUI Elmish) an extension for Avalonia to write GUI applications in F#. What difference does it make if Avalonia itself is written in C#?
lp0_on_fire 2y ago
Nothing against F# but the developer ecosystem around C# is just plain better, especially if you're already a dotnet shop. Documentation, code examples, tooling, developers who already know the language, etc. F# doesn't really buy you anything if you're already invested in C# (or even VB.net for those poor souls) unless you have a very specific use-case for it, IMO.
rafaelmn 2y ago
F# has it's own warts, tooling isn't as polished, stuff like type providers sound really cool but suck in practice IMO, file ordering being relevant for compilation is bleh... Every time I try to use it I'm left with a feeling it's not worth the hassle over C#. C# has been quite nice for 10 years and they keep improving consistently with every version.
- hnthrow289570 2y ago
  The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack. You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I envy people who only do hobbyist C# so get to work on code bases that have all the newest language feature usage.
  - rafaelmn 2y ago
    I definitely dislike most C#/.NET developers/community (every time mediator is mentioned I want to stab myself) and would rather work with people in F#/FP. But when you have to work on "diverse" development teams having some sort of patterns established (flawed as they are) brings some order to the insanity.
    - xeromal 2y ago
      My brain really likes how organizes C# libs tend to be compared to the 50 different organization schemes I deal with in node and python
      - bbkane 2y ago
        Does C# impose a lot of organization? I've only worked in one C# codebase but it has partial classes everywhere and TONs of abstraction bloat. I found it difficult to reason about the organization.
GiorgioG 2y ago
Because nobody uses it, Microsoft doesn’t invest or promote F# heavily. I’m pissed about all of this, but I accept that eventually C# will get much of F#’s goodness.
- Akronymus 2y ago
  I don't think that c# will ever get immutability by default though.
throw868788 2y ago
Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well without a hiccup and with the C# interop we never find we are blocked (e.g enterprise/vendor libs). They found it easier to learn F# than C# - it has a lot more in common with JS/Go/etc in how code is structured and maintained from their POV. Good mentorship is critical for learning and deriving extra value from it especially if coming from old C#/Java/etc. The push for C# to minimal APIs, less classes, etc from our experience has slowly made it less necessary to have F# wrappers as well - the interop ugliness usually only resides in one file (e.g. ASP.NET Startup.fs or equilvalent in given C# framework). Given our proprietary nature however we don't broadcast a lot of our dev effort/development online - I assume many F# shops are/were similar. We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

by wk_end 2y ago

Instead of C#, why not F#? You get proper ADTs among many other great features, but you still get all the utility of the .NET ecosystem.

fluoridation 2y ago

I get the feeling F# is a second-class citizen in the ecosystem. How likely is it (or is it at all possible) that I'm going to run into some library that doesn't work with F#?

nightski 2y ago
None, it's a CLR after all. That said many libraries may not utilize the best features F# has to offer.
antonyt 2y ago
It's impossible for a .NET library to not work with F#. It's very possible (and even likely) for a .NET library to prevent you from writing idiomatic F#. You're right that it's a second-class citizen.
- debugnik 2y ago
  > It's impossible for a .NET library to not work with F#. This isn't true, C# has been adding new ABI features that didn't interact correctly with F# until the compiler and tooling catched up. For example, the spanification of C# was a huge a pain point and it still is when it comes to tooling.
  - antonyt 2y ago
    TIL. Have links to any details about this? I'm very curious!
    - pjmlp 2y ago
      Stuff like Roslyn analysers, code generators and interceptors, only take C# semantics into account, the first one also works with VB.NET. Since its introduction that CLR has the notion of CLS, the Common Language Subset, that any language targeting the CLR should be able to understand. Anything in the MSIL or metadata, that isn't part of that, requires additional effort from the respective language to be able to expose those features, and many of the more recent improvements, are more in the sense of CLR meaning C# Language Runtime, than Common Language Runtime.
    - debugnik 2y ago
      You mostly have to look at the time frames between C# adding features with new ABIs and the time it takes for F# to announce they can actually consume them. For example, F# used to crash the CLR with InvalidProgramException when setting C# `init` properties. [1] It took almost three years, I think, to release the fix. [1]: https://github.com/fsharp/fslang-suggestions/issues/904 https://github.com/fsharp/fslang-suggestions/issues/904 Another rough example would be spans, and their more general feature, byref-like types (ref struct). These required plenty of compiler support, as they've got special lifetime rules (and more pending to implement `scoped`), they are banned as generic type arguments, and they require ignoring a special Obsolete attribute. While these were added to F# timely, many language features still break when they interact with them: local functions, computation expressions (even the built-in ones), recursive type inference, and generic intrinsic methods such as `raise`, `defaultof` or `typeof`. This wouldn't be so bad if C# hadn't "spanified" the shared framework and the entire ecosystem without CLS alternatives for many APIs. So, these natural F# snippets don't compile: let numbers = [| for span in text.EnumerateLines() -> Int32.Parse span |] let checkNonEmpty (span: ReadOnlySpan<'T>) = if span.Length > 0 then span else failwith "Expected non-empty span." Edit: And I haven't even gotten into the libraries that use reflection expecting you to declare types in ways F# doesn't support.
Eji1700 2y ago
Just to add to the other comments, in my experience a large majority of libraries work fine. Maybe a little tweak here or there, or maybe you need to use some C# esq syntax (which is harder in my case because I so rarely do now). Generally though, it's pretty easy. Sometimes you'll want to make bindings around various things (not that you need to, but it'll make things smoother). It's not actually awful, it's just that there's no real documentation of "hey today we're going to take Serilog/whatever and show you how to configure it in F#" style videos, so depending on where your weaknesses lie it can feel frustrating.
- gopherchucks 2y ago
  My experience mirror yours. I really lean into the functional core, imperative shell because of this. Im mostly interacting with C# flavored libraries at the edges and I don’t try to force F# paradigms there, I just roll with the punches.

DaiPlusPlus 2y ago

The benefits of F# only really apply when using a 100% F# codebase. Try doing WinForms in F#...

Eji1700 2y ago
I mean that's mostly pretty easy bindings, but yeah it's annoying that you have to do them and feels like you're losing out on the whole damn point of using F#
Archelaos 2y ago
That F# has no native GUI framework is the reason why I stick with C#. When coding something with a GUI, the majority of my development time is typically spent in the GUI layer. The rest is some more or less straightforward object relational mapping with some validation an calculations in a business layer where I use Linq to emulate functional programming in C#. Adding F# to the game would only complicate the scenario, because I would need to connect the F# interfaces somewhere to C# anyway, requiring an additional layer of mappings in many cases.
- neonsunset 2y ago
  There is! https://funcui.avaloniaui.net/ https://funcui.avaloniaui.net/
  - Archelaos 2y ago
    It is just a wrapper around Avalonia, which is written in C#.
    - neonsunset 2y ago
      It is (together with FuncUI Elmish) an extension for Avalonia to write GUI applications in F#. What difference does it make if Avalonia itself is written in C#?

lp0_on_fire 2y ago

Nothing against F# but the developer ecosystem around C# is just plain better, especially if you're already a dotnet shop. Documentation, code examples, tooling, developers who already know the language, etc. F# doesn't really buy you anything if you're already invested in C# (or even VB.net for those poor souls) unless you have a very specific use-case for it, IMO.

rafaelmn 2y ago

F# has it's own warts, tooling isn't as polished, stuff like type providers sound really cool but suck in practice IMO, file ordering being relevant for compilation is bleh... Every time I try to use it I'm left with a feeling it's not worth the hassle over C#. C# has been quite nice for 10 years and they keep improving consistently with every version.

hnthrow289570 2y ago
The language itself is nice, the code bases that companies produce with it is not, and sadly that reputation plays into your decision to choose a career stack. You're going to have patterns from the .NET Framework era being ported to .NET Core projects. It works, but you'll have two paradigms of doing things mixed into your project. I envy people who only do hobbyist C# so get to work on code bases that have all the newest language feature usage.
- rafaelmn 2y ago
  I definitely dislike most C#/.NET developers/community (every time mediator is mentioned I want to stab myself) and would rather work with people in F#/FP. But when you have to work on "diverse" development teams having some sort of patterns established (flawed as they are) brings some order to the insanity.
  - xeromal 2y ago
    My brain really likes how organizes C# libs tend to be compared to the 50 different organization schemes I deal with in node and python
    - bbkane 2y ago
      Does C# impose a lot of organization? I've only worked in one C# codebase but it has partial classes everywhere and TONs of abstraction bloat. I found it difficult to reason about the organization.

GiorgioG 2y ago

Because nobody uses it, Microsoft doesn’t invest or promote F# heavily. I’m pissed about all of this, but I accept that eventually C# will get much of F#’s goodness.

Akronymus 2y ago
I don't think that c# will ever get immutability by default though.

throw868788 2y ago

Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well without a hiccup and with the C# interop we never find we are blocked (e.g enterprise/vendor libs). They found it easier to learn F# than C# - it has a lot more in common with JS/Go/etc in how code is structured and maintained from their POV. Good mentorship is critical for learning and deriving extra value from it especially if coming from old C#/Java/etc. The push for C# to minimal APIs, less classes, etc from our experience has slowly made it less necessary to have F# wrappers as well - the interop ugliness usually only resides in one file (e.g. ASP.NET Startup.fs or equilvalent in given C# framework). Given our proprietary nature however we don't broadcast a lot of our dev effort/development online - I assume many F# shops are/were similar. We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.