8 ms·

F# Good and Bad

120 points by amscotti 5y ago

unbanned 5y ago
Real world use cases of F# which aren't pet projects and the empty set are equivalent.
- JackMorgan 5y ago
  I've worked for two different finance companies that are entirely on F#. One has huge customer bases and sells the product as on prem hosted solutions, the other hosts internally.
- firlefans 5y ago
  jet.com used it heavily for backend dev, grew quickly, were acquired by Walmart, 560million+ in funding: https://www.crunchbase.com/organization/jet https://www.crunchbase.com/organization/jet Even if you'd consider them the Jane Street of F#, it's a counterexample to your argument.
  - thrower123 5y ago
    Hasn't Walmart rewritten all the Jet stuff in python and c# by now? At least that's what I was being told five years ago.
  - pjmlp 5y ago
    How much of the jet.com code is still in use nowadays? Having been through a couple of merges during my lifetime, I guess "it depends".
  - nojito 5y ago
    Not really. https://careers.walmart.com/us/jobs/WD635714-senior-software-engineer https://careers.walmart.com/us/jobs/WD635714-senior-software... >Top-notch programming skills, with an interest in functional programming languages. We use F# right now but are transitioning to Java. It's still used for the warehouse distribution team though
- vmurthy 5y ago
  > which aren't pet projects and the empty set are equivalent Wow. So much hubris in that sentence. I used to work with a startup in Sydney that still regularly uses F# for middleware/backend work. When I was there for 1.5 years, I saw the # of users of our product went up 3x but with very little delta in defects, rework etc. F# wasn't the only reason for this of course but it helped.
- xboxnolifes 5y ago
  We have F# in production.
- dgudkov 5y ago
  We've built a high-performance in-memory data transformation engine in F# and it works like a charm in thousands of installations around the world every day and supports business-critical processes in many organizations.
- clausok 5y ago
  I have been consulting at a world-renown hedge fund that has a lot of F# including nightly processes that have apparently been running for years with zero maintenance. You'll never hear them talk about it or see them at meet-ups though. The CTO is a bit of a maverick -- I'm not suggesting that this type of quiet adoption is common.
  - throw868788 5y ago
    Sadly in my experience it is common for F# given its finance background at least historically, particularly in London/Europe. There is a culture of not showing your cards in these environments having worked in a few of them, and quietly being a success. Its an "arms race" with your competitors after all - only people in the industry jumping between companies have an idea what their other competitors are using often sometimes with "non-compete" clauses. Meetup's/conferences/articles showing your work are often explicitly banned or at best not encouraged by the companies for commercial reasons.
xupybd 5y ago
The bad of F# is trying to find work in F#. I have the freedom to choose F# at work but it often seems like the wrong choice. If I want a web app I'm pulling in so many extra dependencies.
- dsizzle 5y ago
  It sounds like you did find work in F# (if you wanted it)? What language are you using?
  - xupybd 5y ago
    I use a tiny bit of F# in small isolated scripts. PHP and JS in the largest project. C# in small GUIs. The gui builder saves so much time and I think they could find any reasonable developer to replace me. If I use too much F# they would have a hard time finding someone. I also use a lot of SQL I think it's fantastic for data manipulation. There are some legacy Java apps as well. I don't mind working with most languages (the only exception is Perl, I'm not a fan). I just love working with F#, so much less boilerplate and type safety. It's so much more fun. But I want everything I do to last that means reducing the number of dependencies and build tools I introduce. Fable is amazing but a SAFE stack app will bring in a huge number of extra dependencies and I'm not sure what maintenance would be like in 10 years. As it is I'm working with a stack of docker containers that compile an old version of PHP and drag in legacy libraries.
- Eji1700 5y ago
  The upside is you can use all the net core libraries. The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. It is by and far my favorite language, but i'm also super lucky i have, relatively, low code demands (basic ETL/CRUD stuff) and the ability to choose what I use in my environment. I hope to god it gets more traction because I think it's amazing, but being second child to C# hurts it in a lot of small ways. Especially because "well we don't need that library, just use the netcore one" is such a common reaction in the community, but it's really not ideal.
dsizzle 5y ago
> I like F# because it's the best programming training language I've found.... It still works great for making me think about and become a better programmer, no matter what language I use in everyday work. I can understand how trying a range of language can make you a better programmer, by better appreciating the dimensions of language design and how it fits together, etc. but I have harder time accepting this stronger, more specific claim. There's not really any support for this claim in the article.
- kirse 5y ago
  Mark Seemann has a good talk on this called the "functional pits of success" -> https://www.youtube.com/watch?v=US8QG9I1XW0 https://www.youtube.com/watch?v=US8QG9I1XW0 Of all the languages I've used nothing is quite as fun as refactoring an F# app down to nothing. Expressive power is king in F# with the whole .NET ecosystem behind it.
  - verinus 5y ago
    I quite like Mark's way of thinking and stumbled upon his blog several years ago while learning FP with F#. [1] Especially the series about category theory... Can also recommend his recently published book "Code that fits in your head". [1] https://blog.ploeh.dk/ https://blog.ploeh.dk/ edit: typo
    - Akronymus 5y ago
      If you like his blog, you surely are gonna enjoy wlashins blog as well. (Making the BIG assumption you don't know it already) It is THE blog that made me grok a lot of FP. https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
      - verinus 5y ago
        Ah yes- superb content on FP/F#! He helped me a long way to understand FP- thanks for mentioning it, I can definitely recommend it to anyone who wants to get into FP / F#!
throw868788 5y ago
Many of the points here don't necessarily have to do with the language, well at least to me and could easily have occured in other languages such as coding style. Sure - the language uses some sensible defaults and is somewhat pragmatic when to be pure and when to not. But in the end programming can get complex. Even if the language steers you towards practices that lower complexity (a productivity win) you still need to understand what is going on and use the right tool when appropriate. On a side note the performance thing seems to be a myth to me. There's no reason C# or F# should be faster or slower than one another with enough effort given the same underlying runtime. Many of the functional features are moving to be lower/zero cost in F# (inline lambdas, state machines, etc). They all compile down to IL in the end so as long as you can get the IL you want does it matter? Sure it may be easier to express more performant code in one or another depending on the domain. I could argue many cases where F# was easier to write performant code (numeric, generic algo's, explicit inline functions, inline vs ref, tail rec, compile time polymorphism, avoiding virtual dispatch preferring static functions, etc) and vice versa (native interop, until recently specialised async/await, etc).
- reallydontask 5y ago
  > On a side note the performance thing seems to be a myth to me. I've always thought about the performance advantages as more related to how (FP) allows for easy parallelisation as your functions are pure, no mutability, etc .
  - pharmakom 5y ago
    Yes F# could be faster than C# but the compiler is missing some advanced optimisations. Right now you can do those by hand but often the code will read like C# once you are done.
    - verinus 5y ago
      I wonder if a FP compiler should actuall be able to produce faster code than for imperative style: imho knowing intention and context could lead do far superior optimizations (for loop with var for summing vs. List.sum)
lmm 5y ago
Maybe this is a problem of our tooling or terminology not being good enough, but I don't agree with the idea that code that passes the available acceptance tests at a given point in time is "right". A codebase is a living thing that needs to be maintained, so it's not enough for the code to be "accidentally right"; it needs to do the right thing for the right reasons such that it will still do the right thing as it evolves.
Ros2 5y ago
In the 2010s, there were a lot of posts about how C# could never even match F# even in 30 versions from that time. But then C# started adding compiler flags that allow a redo of past suboptimal decisions (nullable reference types) without breaking existing code. What is the current feeling on this? It seems kind of countered by the fact that the C# team is no longer bound by any past decisions.
- int_19h 5y ago
  C# is much further towards readability on the readability/conciseness scale, and I don't expect that to change. Sure, it gets many similar features over time, but compare e.g. pattern matching and how much clunkier it is. Or pipelining.
- deleted 5y ago
  [deleted]
- pharmakom 5y ago
  C# can never be made expression orientated. This is the real killer feature of F#.
verinus 5y ago
What I love about F# is - no NULL- just use option types and pattern matching - how powerful pattern matching is - pipelining - units of measurement- we all know the billion dollar disasters caused by distributed teams all thinking in their respective units- these should always be in the signature of a method but when starting I can still remember how I struggled with the rather mathematical notation of int -> int -> int for signatures- I often failed to quickly spot the error in calling a function. brace placement just felt wrong (when nesting function calls, which could be necessary despite pipelining)- I understand why, but for the most part it just felt wrong coming from Java/C#. unfortunately it is a rather niche language- being a .net language does not help here as the main features such as algebraic datatypes are largely incompatible with C# syntax. I am just glad that more and more features are adopted by C#- only downside is, that C# suffers of feature bloat :(
- moonchrome 5y ago
  F# selling point to me is type providers. Being able to write a SQL query and the IDE/compiler knowing the result types is magic. Screw ORM this is how it's supposed to work.
  - verinus 5y ago
    you are right, I loved that feature too. another thing I forgot to mention: what I was missing: "dotting into" in the sense that I have a object/data I want no manipulate and quickly see what can be done with an data in FP after getting into FP some years ago I have significantly altered my programming style in C#, using much more extension methods for pure functions, and recently NonNullable, pattern matching etc...
  - bmitc 5y ago
    I love F# but have never gotten a type provider to actually work.
    - moonchrome 5y ago
      I have to admit I only used F# on a small project a few years back, but the type providers made the job super simple - the job was basically generating some fancy reports from multiple data sources and being able to just specify database connection strings and have everything work in the IDE/compiler was a huge win. Setting up CI was a bit of a PITA because I remember needing to spinup a DB to create schema, there was some option to do it from schema directly but didn't want to waste time.
firlefans 5y ago
I personally found F# to be a decent alternative to Elm for small browser apps with Fable, Elmish/Feliz, Feliz.Plotly etc. You can generate typed interfaces for any libs you're missing which have a typescript interface using ts2fable, that's the kind of pragmatic tooling you need if you're veering off the well-trodden path in commercial development. Ionide in VSCode is excellent (though not perfect) and the compilation times are decent. In terms of community (which is not unimportant when it's that small) even the compiler gitter folks were super helpful when I had some reflection questions. Overall I'd use it again for small browser apps, for backend I guess it depends on your company and domain.
- verinus 5y ago
  while I love F# too I think what hinders adoption is: - training in FP: for an enterprise on the most crucial points is imho recruiting - tooling: while the tooling is ok for F# (though not ReSharper grade by far!) it is still lacking what I often see as refactoring is not that supported in F#/FP languages is the functional equivalent to spaghetti code, where function call after function call is piped without following SOLID principles/ Clean Code style.
  - truculent 5y ago
    > what I often see as refactoring is not that supported in F#/FP languages Could you elaborate on this please? I have found easy, confident refactoring to be one of the biggest benefits of using this family of languages.
  - firlefans 5y ago
    I don't think you can apply the same principles to OO and FP but in terms of refactoring, my experience is that pure functional code is a joy to test and maintain. Small pure functions (again functions can only be pure functions, otherwise you're really talking about procedures), are by their nature easy to test, compose, cache, parallelise and pipeline. If that sounds bad to you, then fair enough.
torginus 5y ago
I'm mostly a C# programmer by trade, and having tried F# multiple times (last time by doing half of the AoC in F#) , I haven't felt that I'd be ready to make the jump. My main issues were: - Much of the functional stuff like map/filter is available in C# as Linq, which granted, is not as nice, but the difference is not huge. - Much of the new stuff in C# like ValueTuples does make it into F# but with a godawful syntax, I don't think this is the language's fault, but rather is the result of Microsoft's inattention - I'm still not sold on the idea of functional languages - much of the stuff in them, like map/filter, option chaining, high quality type inference, pattern matching has shown up in procedural languages (they are all available in C# with the exception of option chaining), and the downsides, like immutability making some algorithms impossible to implement, is great. Imo, local mutation is not that bad, and functional languages actively prevent it, while global mutation is still a thing, which tends to be more problematic - The generated .NET IL is not great. seq turns into an IEnumerable, list is some sort of linked list, I'm pretty sure you'd get pretty terrible performance if you did this.
- paavohtl 5y ago
  > high quality type inference C# type inference is not really comparable in any way to F#'s ML-style global type inference. You can realistically write a non-trivial F# program without a single type annotation. C#'s type inference is local: the type of a variable solely depends on the type of the expression on the right. F# uses global type inference, where all expressions of a program are used to infer the types of variables. This means that you can e.g create a list with just [], and then latter append a string to it, which the compiler uses to infer the type of the list. Both approaches have their upsides and downsides (a program without a single type annotation is really hard to read without the help of an IDE), but they are clearly very different.
- Banana699 5y ago
  >high quality type inference, [...] available in C# This is not what I would say at all, the only thing that C# offers in type inference is the ability to use "var" when initializing a variable to save yourself the tedium of writing an obvious type, I have heard something about generics too but I can't remember what it does exactly. This doesn't hold a candle to F#'s ML-like inference : omitted function argument types and return type, automatic generalization, the ability of the compiler to tolerate individual expressions not being obviously typed right away as long as function-level-context eventually makes it clear what all things are. C#'s type inference is pitiful and trivial by comparison.
imdoor 5y ago
I've seen a lot of praise for F# but trying it out left me somewhat disapointed. Overall, it was nice to program in but there was a constant feeling of awkwardness which, it seems, was caused by F#'s ties to the rest of the .NET world. I don't remember the details too well but some of the examples are: - NULL values still are a problem because they can be introduced any time you interact with the .NET framework. I got hit by this almost right at the beginning when first using the language – i defined some data type with non-optional fields and used it as an argument to an ASP.NET Core controller method only to realize that my non-optional fields don't enforce anything and ASP.NET will happily set them to NULL when data aren't present. - There are multiple slightly different ways to define data types – classes, records, discriminated unions – and it's not immediately clear what are the consequences of using which. I remember having to switch some of my datatype definitions to classes because otherwise i couldn't make ASP.NET Core automatically deserialize them. - You still have to learn in detail how all of the C# and .NET concepts map into F# to work with .NET and other libraries, e.g., there is a weird duplication of collection types, sometimes you have to do a weird casting dance with the :> and :?> operators when working with interfaces, dealing with out parameters also took me quite some time to figure out. - Namespaces, classes and modules also seem to have some confusing redundancy. I've tried out F# only once for a single project so a lot my complaints are probably due to my inexperience with the language, but all in all it seems that a lot of the suffering is inflicted by the association with .NET and the language could have been a lot nicer if it wasn't tied to it (I'm not dismissing the benefits of it, though).
- mdm12 5y ago
  Some of the issues (such as null values sneaking through the standard library) are a price to be paid for using a runtime such as .NET with a large ecosystem of existing libraries. This can be avoided to some degree by writing/using thin wrappers around the troublesome integration points that translate nullable values to option types. I agree, it is a source of friction. I believe other functional languages that target existing platforms (such as Scala) have similar issues. Other points you mention (like being forced to upcast values to interfaces) have been resolved in recent versions of F#.[1] The language continues to evolve and improve with annual major releases. My biggest pain point is actually the tooling around the language, but that situation has been improving as well. [1] https://docs.microsoft.com/en-us/dotnet/fsharp/whats-new/fsharp-6#additional-implicit-conversions https://docs.microsoft.com/en-us/dotnet/fsharp/whats-new/fsh...
specialist 5y ago
This lament reminds me of the cliché: A good programmer can write FORTRAN code in any language. Much as I loved LISP, back in the day, I hated working on other people's code. The author's prior (preferred) programming language was so obvious. And advocating consistent idiomatic LISPy house conventions never proved worthwhile. Ditto pretty much every language since. So much so, I've come to reject metaprogramming and reflection for team projects. Any more, JavaScript (gods save us) is a language dialect construction kit, with every person and cohort creating their unicorn opinionated mutant variant. As much as C++ ever was. In contrast: I do like like Lua. But I almost prefer using it. It's one virtue is simplicity. It has less potential for individual artistic expression. When maintaining someone else's Lua goo, I spent much less time bending my mind to the author's mental frame. Perhaps we should revert to BASIC, Pascal, or Java 1.0. Perhaps future parsers will permit subsetting grammars, to better define and enforce house rules. Perhaps we'll all revert to just banging the rocks together. Ook, ook.
- Tarucho 5y ago
  Most code ends up being pseudo-basic or pseudo-pascal in the language du jour.
pjmlp 5y ago
The good, it is a ML language with the goodies from the .NET ecosystem. One of the languages I enjoy coding every now and then. The bad, it appears .NET team never really knows how to "sell" F#, and anything related to it comes as an afterthough if at all. So on MS shops that actually make use of it, it gets relegated to writing libraries, or in a parallel universe with wrappers or competing stacks for anything .NET.
AtNightWeCode 5y ago
F# is practically dead. Worked with a lot of projects that jumped that hype wagon. Do not know of any company that use F# as of today. From a holistic viewpoint F# is complete garbage comparing to C#. Could we have a working pure attribute in C# though.

F# Good and Bad

120 points by amscotti 5y ago

unbanned 5y ago

Real world use cases of F# which aren't pet projects and the empty set are equivalent.

JackMorgan 5y ago
I've worked for two different finance companies that are entirely on F#. One has huge customer bases and sells the product as on prem hosted solutions, the other hosts internally.
firlefans 5y ago
jet.com used it heavily for backend dev, grew quickly, were acquired by Walmart, 560million+ in funding: https://www.crunchbase.com/organization/jet https://www.crunchbase.com/organization/jet Even if you'd consider them the Jane Street of F#, it's a counterexample to your argument.
- thrower123 5y ago
  Hasn't Walmart rewritten all the Jet stuff in python and c# by now? At least that's what I was being told five years ago.
- pjmlp 5y ago
  How much of the jet.com code is still in use nowadays? Having been through a couple of merges during my lifetime, I guess "it depends".
- nojito 5y ago
  Not really. https://careers.walmart.com/us/jobs/WD635714-senior-software-engineer https://careers.walmart.com/us/jobs/WD635714-senior-software... >Top-notch programming skills, with an interest in functional programming languages. We use F# right now but are transitioning to Java. It's still used for the warehouse distribution team though
vmurthy 5y ago
> which aren't pet projects and the empty set are equivalent Wow. So much hubris in that sentence. I used to work with a startup in Sydney that still regularly uses F# for middleware/backend work. When I was there for 1.5 years, I saw the # of users of our product went up 3x but with very little delta in defects, rework etc. F# wasn't the only reason for this of course but it helped.
xboxnolifes 5y ago
We have F# in production.
dgudkov 5y ago
We've built a high-performance in-memory data transformation engine in F# and it works like a charm in thousands of installations around the world every day and supports business-critical processes in many organizations.
clausok 5y ago
I have been consulting at a world-renown hedge fund that has a lot of F# including nightly processes that have apparently been running for years with zero maintenance. You'll never hear them talk about it or see them at meet-ups though. The CTO is a bit of a maverick -- I'm not suggesting that this type of quiet adoption is common.
- throw868788 5y ago
  Sadly in my experience it is common for F# given its finance background at least historically, particularly in London/Europe. There is a culture of not showing your cards in these environments having worked in a few of them, and quietly being a success. Its an "arms race" with your competitors after all - only people in the industry jumping between companies have an idea what their other competitors are using often sometimes with "non-compete" clauses. Meetup's/conferences/articles showing your work are often explicitly banned or at best not encouraged by the companies for commercial reasons.

xupybd 5y ago

The bad of F# is trying to find work in F#. I have the freedom to choose F# at work but it often seems like the wrong choice. If I want a web app I'm pulling in so many extra dependencies.

dsizzle 5y ago
It sounds like you did find work in F# (if you wanted it)? What language are you using?
- xupybd 5y ago
  I use a tiny bit of F# in small isolated scripts. PHP and JS in the largest project. C# in small GUIs. The gui builder saves so much time and I think they could find any reasonable developer to replace me. If I use too much F# they would have a hard time finding someone. I also use a lot of SQL I think it's fantastic for data manipulation. There are some legacy Java apps as well. I don't mind working with most languages (the only exception is Perl, I'm not a fan). I just love working with F#, so much less boilerplate and type safety. It's so much more fun. But I want everything I do to last that means reducing the number of dependencies and build tools I introduce. Fable is amazing but a SAFE stack app will bring in a huge number of extra dependencies and I'm not sure what maintenance would be like in 10 years. As it is I'm working with a stack of docker containers that compile an old version of PHP and drag in legacy libraries.
Eji1700 5y ago
The upside is you can use all the net core libraries. The downside is then you have to know how to write wrappers/helpers for them and probably don't get to use all the cool stuff that comes with F# because you're using a library written for C#. It is by and far my favorite language, but i'm also super lucky i have, relatively, low code demands (basic ETL/CRUD stuff) and the ability to choose what I use in my environment. I hope to god it gets more traction because I think it's amazing, but being second child to C# hurts it in a lot of small ways. Especially because "well we don't need that library, just use the netcore one" is such a common reaction in the community, but it's really not ideal.

dsizzle 5y ago

> I like F# because it's the best programming training language I've found.... It still works great for making me think about and become a better programmer, no matter what language I use in everyday work. I can understand how trying a range of language can make you a better programmer, by better appreciating the dimensions of language design and how it fits together, etc. but I have harder time accepting this stronger, more specific claim. There's not really any support for this claim in the article.

kirse 5y ago
Mark Seemann has a good talk on this called the "functional pits of success" -> https://www.youtube.com/watch?v=US8QG9I1XW0 https://www.youtube.com/watch?v=US8QG9I1XW0 Of all the languages I've used nothing is quite as fun as refactoring an F# app down to nothing. Expressive power is king in F# with the whole .NET ecosystem behind it.
- verinus 5y ago
  I quite like Mark's way of thinking and stumbled upon his blog several years ago while learning FP with F#. [1] Especially the series about category theory... Can also recommend his recently published book "Code that fits in your head". [1] https://blog.ploeh.dk/ https://blog.ploeh.dk/ edit: typo
  - Akronymus 5y ago
    If you like his blog, you surely are gonna enjoy wlashins blog as well. (Making the BIG assumption you don't know it already) It is THE blog that made me grok a lot of FP. https://fsharpforfunandprofit.com/ https://fsharpforfunandprofit.com/
    - verinus 5y ago
      Ah yes- superb content on FP/F#! He helped me a long way to understand FP- thanks for mentioning it, I can definitely recommend it to anyone who wants to get into FP / F#!

throw868788 5y ago

Many of the points here don't necessarily have to do with the language, well at least to me and could easily have occured in other languages such as coding style. Sure - the language uses some sensible defaults and is somewhat pragmatic when to be pure and when to not. But in the end programming can get complex. Even if the language steers you towards practices that lower complexity (a productivity win) you still need to understand what is going on and use the right tool when appropriate. On a side note the performance thing seems to be a myth to me. There's no reason C# or F# should be faster or slower than one another with enough effort given the same underlying runtime. Many of the functional features are moving to be lower/zero cost in F# (inline lambdas, state machines, etc). They all compile down to IL in the end so as long as you can get the IL you want does it matter? Sure it may be easier to express more performant code in one or another depending on the domain. I could argue many cases where F# was easier to write performant code (numeric, generic algo's, explicit inline functions, inline vs ref, tail rec, compile time polymorphism, avoiding virtual dispatch preferring static functions, etc) and vice versa (native interop, until recently specialised async/await, etc).

reallydontask 5y ago
> On a side note the performance thing seems to be a myth to me. I've always thought about the performance advantages as more related to how (FP) allows for easy parallelisation as your functions are pure, no mutability, etc .
- pharmakom 5y ago
  Yes F# could be faster than C# but the compiler is missing some advanced optimisations. Right now you can do those by hand but often the code will read like C# once you are done.
  - verinus 5y ago
    I wonder if a FP compiler should actuall be able to produce faster code than for imperative style: imho knowing intention and context could lead do far superior optimizations (for loop with var for summing vs. List.sum)

lmm 5y ago

Maybe this is a problem of our tooling or terminology not being good enough, but I don't agree with the idea that code that passes the available acceptance tests at a given point in time is "right". A codebase is a living thing that needs to be maintained, so it's not enough for the code to be "accidentally right"; it needs to do the right thing for the right reasons such that it will still do the right thing as it evolves.

Ros2 5y ago

In the 2010s, there were a lot of posts about how C# could never even match F# even in 30 versions from that time. But then C# started adding compiler flags that allow a redo of past suboptimal decisions (nullable reference types) without breaking existing code. What is the current feeling on this? It seems kind of countered by the fact that the C# team is no longer bound by any past decisions.

int_19h 5y ago
C# is much further towards readability on the readability/conciseness scale, and I don't expect that to change. Sure, it gets many similar features over time, but compare e.g. pattern matching and how much clunkier it is. Or pipelining.
deleted 5y ago
[deleted]
pharmakom 5y ago
C# can never be made expression orientated. This is the real killer feature of F#.

verinus 5y ago

What I love about F# is - no NULL- just use option types and pattern matching - how powerful pattern matching is - pipelining - units of measurement- we all know the billion dollar disasters caused by distributed teams all thinking in their respective units- these should always be in the signature of a method but when starting I can still remember how I struggled with the rather mathematical notation of int -> int -> int for signatures- I often failed to quickly spot the error in calling a function. brace placement just felt wrong (when nesting function calls, which could be necessary despite pipelining)- I understand why, but for the most part it just felt wrong coming from Java/C#. unfortunately it is a rather niche language- being a .net language does not help here as the main features such as algebraic datatypes are largely incompatible with C# syntax. I am just glad that more and more features are adopted by C#- only downside is, that C# suffers of feature bloat :(

moonchrome 5y ago
F# selling point to me is type providers. Being able to write a SQL query and the IDE/compiler knowing the result types is magic. Screw ORM this is how it's supposed to work.
- verinus 5y ago
  you are right, I loved that feature too. another thing I forgot to mention: what I was missing: "dotting into" in the sense that I have a object/data I want no manipulate and quickly see what can be done with an data in FP after getting into FP some years ago I have significantly altered my programming style in C#, using much more extension methods for pure functions, and recently NonNullable, pattern matching etc...
- bmitc 5y ago
  I love F# but have never gotten a type provider to actually work.
  - moonchrome 5y ago
    I have to admit I only used F# on a small project a few years back, but the type providers made the job super simple - the job was basically generating some fancy reports from multiple data sources and being able to just specify database connection strings and have everything work in the IDE/compiler was a huge win. Setting up CI was a bit of a PITA because I remember needing to spinup a DB to create schema, there was some option to do it from schema directly but didn't want to waste time.

firlefans 5y ago

I personally found F# to be a decent alternative to Elm for small browser apps with Fable, Elmish/Feliz, Feliz.Plotly etc. You can generate typed interfaces for any libs you're missing which have a typescript interface using ts2fable, that's the kind of pragmatic tooling you need if you're veering off the well-trodden path in commercial development. Ionide in VSCode is excellent (though not perfect) and the compilation times are decent. In terms of community (which is not unimportant when it's that small) even the compiler gitter folks were super helpful when I had some reflection questions. Overall I'd use it again for small browser apps, for backend I guess it depends on your company and domain.

verinus 5y ago
while I love F# too I think what hinders adoption is: - training in FP: for an enterprise on the most crucial points is imho recruiting - tooling: while the tooling is ok for F# (though not ReSharper grade by far!) it is still lacking what I often see as refactoring is not that supported in F#/FP languages is the functional equivalent to spaghetti code, where function call after function call is piped without following SOLID principles/ Clean Code style.
- truculent 5y ago
  > what I often see as refactoring is not that supported in F#/FP languages Could you elaborate on this please? I have found easy, confident refactoring to be one of the biggest benefits of using this family of languages.
- firlefans 5y ago
  I don't think you can apply the same principles to OO and FP but in terms of refactoring, my experience is that pure functional code is a joy to test and maintain. Small pure functions (again functions can only be pure functions, otherwise you're really talking about procedures), are by their nature easy to test, compose, cache, parallelise and pipeline. If that sounds bad to you, then fair enough.

torginus 5y ago

I'm mostly a C# programmer by trade, and having tried F# multiple times (last time by doing half of the AoC in F#) , I haven't felt that I'd be ready to make the jump. My main issues were: - Much of the functional stuff like map/filter is available in C# as Linq, which granted, is not as nice, but the difference is not huge. - Much of the new stuff in C# like ValueTuples does make it into F# but with a godawful syntax, I don't think this is the language's fault, but rather is the result of Microsoft's inattention - I'm still not sold on the idea of functional languages - much of the stuff in them, like map/filter, option chaining, high quality type inference, pattern matching has shown up in procedural languages (they are all available in C# with the exception of option chaining), and the downsides, like immutability making some algorithms impossible to implement, is great. Imo, local mutation is not that bad, and functional languages actively prevent it, while global mutation is still a thing, which tends to be more problematic - The generated .NET IL is not great. seq turns into an IEnumerable, list is some sort of linked list, I'm pretty sure you'd get pretty terrible performance if you did this.

paavohtl 5y ago
> high quality type inference C# type inference is not really comparable in any way to F#'s ML-style global type inference. You can realistically write a non-trivial F# program without a single type annotation. C#'s type inference is local: the type of a variable solely depends on the type of the expression on the right. F# uses global type inference, where all expressions of a program are used to infer the types of variables. This means that you can e.g create a list with just [], and then latter append a string to it, which the compiler uses to infer the type of the list. Both approaches have their upsides and downsides (a program without a single type annotation is really hard to read without the help of an IDE), but they are clearly very different.
Banana699 5y ago
>high quality type inference, [...] available in C# This is not what I would say at all, the only thing that C# offers in type inference is the ability to use "var" when initializing a variable to save yourself the tedium of writing an obvious type, I have heard something about generics too but I can't remember what it does exactly. This doesn't hold a candle to F#'s ML-like inference : omitted function argument types and return type, automatic generalization, the ability of the compiler to tolerate individual expressions not being obviously typed right away as long as function-level-context eventually makes it clear what all things are. C#'s type inference is pitiful and trivial by comparison.

imdoor 5y ago

I've seen a lot of praise for F# but trying it out left me somewhat disapointed. Overall, it was nice to program in but there was a constant feeling of awkwardness which, it seems, was caused by F#'s ties to the rest of the .NET world. I don't remember the details too well but some of the examples are: - NULL values still are a problem because they can be introduced any time you interact with the .NET framework. I got hit by this almost right at the beginning when first using the language – i defined some data type with non-optional fields and used it as an argument to an ASP.NET Core controller method only to realize that my non-optional fields don't enforce anything and ASP.NET will happily set them to NULL when data aren't present. - There are multiple slightly different ways to define data types – classes, records, discriminated unions – and it's not immediately clear what are the consequences of using which. I remember having to switch some of my datatype definitions to classes because otherwise i couldn't make ASP.NET Core automatically deserialize them. - You still have to learn in detail how all of the C# and .NET concepts map into F# to work with .NET and other libraries, e.g., there is a weird duplication of collection types, sometimes you have to do a weird casting dance with the :> and :?> operators when working with interfaces, dealing with out parameters also took me quite some time to figure out. - Namespaces, classes and modules also seem to have some confusing redundancy. I've tried out F# only once for a single project so a lot my complaints are probably due to my inexperience with the language, but all in all it seems that a lot of the suffering is inflicted by the association with .NET and the language could have been a lot nicer if it wasn't tied to it (I'm not dismissing the benefits of it, though).

mdm12 5y ago
Some of the issues (such as null values sneaking through the standard library) are a price to be paid for using a runtime such as .NET with a large ecosystem of existing libraries. This can be avoided to some degree by writing/using thin wrappers around the troublesome integration points that translate nullable values to option types. I agree, it is a source of friction. I believe other functional languages that target existing platforms (such as Scala) have similar issues. Other points you mention (like being forced to upcast values to interfaces) have been resolved in recent versions of F#.[1] The language continues to evolve and improve with annual major releases. My biggest pain point is actually the tooling around the language, but that situation has been improving as well. [1] https://docs.microsoft.com/en-us/dotnet/fsharp/whats-new/fsharp-6#additional-implicit-conversions https://docs.microsoft.com/en-us/dotnet/fsharp/whats-new/fsh...

specialist 5y ago

This lament reminds me of the cliché: A good programmer can write FORTRAN code in any language. Much as I loved LISP, back in the day, I hated working on other people's code. The author's prior (preferred) programming language was so obvious. And advocating consistent idiomatic LISPy house conventions never proved worthwhile. Ditto pretty much every language since. So much so, I've come to reject metaprogramming and reflection for team projects. Any more, JavaScript (gods save us) is a language dialect construction kit, with every person and cohort creating their unicorn opinionated mutant variant. As much as C++ ever was. In contrast: I do like like Lua. But I almost prefer using it. It's one virtue is simplicity. It has less potential for individual artistic expression. When maintaining someone else's Lua goo, I spent much less time bending my mind to the author's mental frame. Perhaps we should revert to BASIC, Pascal, or Java 1.0. Perhaps future parsers will permit subsetting grammars, to better define and enforce house rules. Perhaps we'll all revert to just banging the rocks together. Ook, ook.

Tarucho 5y ago
Most code ends up being pseudo-basic or pseudo-pascal in the language du jour.

pjmlp 5y ago

The good, it is a ML language with the goodies from the .NET ecosystem. One of the languages I enjoy coding every now and then. The bad, it appears .NET team never really knows how to "sell" F#, and anything related to it comes as an afterthough if at all. So on MS shops that actually make use of it, it gets relegated to writing libraries, or in a parallel universe with wrappers or competing stacks for anything .NET.

AtNightWeCode 5y ago

F# is practically dead. Worked with a lot of projects that jumped that hype wagon. Do not know of any company that use F# as of today. From a holistic viewpoint F# is complete garbage comparing to C#. Could we have a working pure attribute in C# though.