11 ms·

I haven't been in .NET for a couple of years but I've worked on quite a few .NET projects over the years. I've seen F# being added to 3 (as far as I can remembe

I haven't been in .NET for a couple of years but I've worked on quite a few .NET projects over the years. I've seen F# being added to 3 (as far as I can remember), in completely different companies/teams/contexts - and it always ended up being the same - some enthusiastic guy (or a few of them) tries to sneak in F# as a part of the system. They don't really gain traction with the rest of the team because people have shit to do and no time to study a new language at work, so it becomes "their own thing". Regularly the tooling breaks (eg. visual studio intellisense stops working on C# projects if you don't disable F# projects, builds randomly start to fail, etc.) The person who introduced it becomes the go to guy for these problems, coupled with no traction for his pet project and being a motivated developer - they leave and now the project has this magic F# part that nobody really knows how it works but everyone knows how to work around. IMO C# is picking up a lot of small things that make it incrementally better than it was before, and at some point it's not worth the hassle to go to F#. F# features are gradually added to C# so C# developers have time to pick them up as well. I've heard of F# only projects doing great, but I think you need to have a team committed to doing F#. Back when I was into Clojure they had this mantra of "add Clojure to your work projects as a library and pretend it's just this small thing you used to solve some problem because it's all on JVM and Java compatible and then keep expanding on it" - I think this turns out terrible in practice.

__s 5y ago
I've been that guy. & yeah, found greener pastures a couple years later No regrets, canopy was an absolute pleasure to use https://lefthandedgoat.github.io/canopy https://lefthandedgoat.github.io/canopy
- spywaregorilla 5y ago
  > No regrets The victim of this pattern is not you
  - __s 5y ago
    I have a conscience, if I did anyone wrong, I'd regret it; the code I left behind has stood on its own
  - blacktriangle 5y ago
    Consulting and working full time have the same problem, you need to program for the customer, not for yourself. If you work with people who are unwilling and/or unable to learn a tool, then DO NOT use that tool. It doesn't matter how much better it makes your life, you've taken a more or less functional organization and given them a bus factor of 1, where that 1 is you and clearly if you're so high on your tool you're willing to shove it down the orgs throat, you're probably looking to leave already.
    - jrsj 5y ago
      Doesn’t that sort of increase your own value to the organization though as well? It would vary based on the situation but it seems like this could sort of work to your advantage if you’re the only person who can reasonably work on something critical (and others can’t be bothered to learn)
      - blacktriangle 5y ago
        I guess, but I think that behavior falls under a dark pattern of employment. I'm not saying you can't introduce new ideas into your organization, but this is where the politics of development comes into play. You need to get buy-in from your team and management, otherwise you're intentionally hurting your organization.
      - evfanknitram 5y ago
        It also means when there's an outage due to X during christmas or whatever, then you're the only person who can reasonable work on it. Great work.
      - mjmahone17 5y ago
        Only if you can ensure no one ever replaces what you wrote with their own solution. You become critical in the short term, but also critical to the business to replace in the long term, in the same way that a vendor tripling their price often results in short term profits while customers transition off of them, leading to a long term decline in revenue.
      - 5y ago
- gagege 5y ago
  I was that guy too at one job. It was wonderful to work on a few F# projects, but I have no doubt they quickly went away after I left.
  - evfanknitram 5y ago
    I have been on the 'receiving' end of such persons actions. We had one guy who worked probably 50% of his time on using not F#, but another "nice" thing. It never worked well and he spent an incredible amount of time patching it and fixing issues with it. I threw it out the day after and replaced it with some older boring technology, and the problems just went away.
    - gagege 5y ago
      Bravo. Yeah, I learned my lesson.
Kototama 5y ago
It's true that bringing in a new technology without support of your team is a bad idea. However just rejecting F# per se because C# has a lot of features is missing the point. Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it.
- reader_mode 5y ago
  I think F# in the context of C# replacement (as a superior language) is not worth it. If you have a team looking for a functional language on .NET it's amazing - so I don't dismiss it - it's just a very niche thing on .NET platform.
- trimbo 5y ago
  > Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it. What objective measure can someone use to determine whether F# is the best choice?
  - Kototama 5y ago
    Pure data-driven decisions would not be possible here, I'm afraid, because there are not enough studies about which language/framework is the more productive in a given situation (and doing such a study is super tricky, because the competences of the participants can very greatly). What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).
    - foobiekr 5y ago
      I don’t think it matters what language people think is most productive. What really matters is what language you can hire for. In the end you have to have people to do the work. I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow. People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations. Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.
MangoCoffee 5y ago
> C# is picking up a lot of small things that make it incrementally better than it was before agree. C# is kind of morphing into F# with new features like record.
- corysama 5y ago
  C# is Microsoft Research’s multi-decade play to convince Java programmers to become Ocaml programmers so slowly that they don’t notice.
  - pjmlp 5y ago
    Given that Java was Sun's attempt to bring C++ developers half way to Lisp, and C# was born out of a lawsuit due to stuff like adding Forms, COM, events and P/Invoke to Java, maybe not.
- the_only_law 5y ago
  I can’t remember if it was a joke or serious, but I recall some comment on HN a while back trying to explain why Java was an ML.
  - Zababa 5y ago
    Is it this one? https://news.ycombinator.com/item?id=26366665 https://news.ycombinator.com/item?id=26366665 The comment itself makes sense, though I don't know how is the adoption of new features in the ecosystem.
- xupybd 5y ago
  C# is OO by default, F# is functional by default. Both support either but it's easier to use the tool dedicated to the style you want to program in.
- ddek 5y ago
  I see this take a lot, and vehemently disagree. An OO language with record types and pattern matching expressions, plus a vague hint of union types in the future; is not a functional language. Depending on who you ask, it's either a quasi-functional OO language or a bloated OO language. I used to be in the first camp, now I lean towards the latter. Over time, projects morph into the average of their framework. If you started off badly, if it survives long enough eventually someone will refactor it into something acceptable. If you start off using FP features, eventually they will be eroded away; through friction with external dependencies, or later developers being less invested in the paradigm. In both cases you're usually left with an inconsistent codebase. When people say that C# is morphing into F#, my usual thought is 'have you ever seen an FP project?' Take some time and read some FP codebases, and compare them with a typical C# codebase. (side-note: one of the most widely used FP language for web development is elixir. There are a few good open-source elixir projects you can read to get a feel for the structure. Almost all elixir projects follow the same structure, and it's about as anti OO/SOLID as possible, yet still conforming to a vague onion architecture.)
jimbokun 5y ago
The lesson: Programming language adoption is based on politics, not technical merit. This isn't inherently bad, but is important to remember. Languages are successful due to the community that rises up around them, far moreso than anything inherent to the design or quality of the language itself. Which can be correlated, but not necessarily so.
- pfraze 5y ago
  It’s not all one or another. PLs are a software product and they need proper marketing and PMF. You can describe the network effect as political but its the same kind of politics as getting your friends to change chat apps.
- jensensbutton 5y ago
  Why politics and not practicality? Taking a ton of time and resources (and potentially risking attrition) to migrate a thing that works to a thing that _hopefully_ works often simply doesn't make business sense. It's not a political decision (in the common usage of the word).
  - frenchy 5y ago
    Practicality is a big part of the politics, but there's real politics at play as well. Different developers will have different levels of comfort with different tool chains, and different capacities to work outside their comfort zone. This is overly reductive, but here's an example: if you have 3 developers, and 1 will be twice as productive in F# and the others will be 10% less productive, it's probably practical sense to switch, but the 2 developers will resist it, and it may fail for political reasons.
- AnimalMuppet 5y ago
  I don't think that's the lesson. The problem described is with maintainability. That's not political; that's technical. (It just looks political, because people say "No, you can't use that language" after they've seen the maintainability problem a few times.)
jarcane 5y ago
IMO C# is picking up a lot of small things that make it incrementally better than it was before, and at some point it's not worth the hassle to go to F#. F# features are gradually added to C# so C# developers have time to pick them up as well. You cannot add the best features of F# to C# without making it a fundamentally different language. You're not gonna make C# into a type-inferred FP language by bolting on some random half-understood bits anymore than you can make a cat jump better by gluing rabbit legs onto it. It's the core paradigm and philosophy that makes it great, and if anything, what I've seen hold it back from its potential is insufficient support requiring essentially importing C# idioms into the language just to interop with existing libraries.
- paavohtl 5y ago
  Absolutely - F# is greater than the sum of its features. While it's good that C# keeps getting features inspired by F#, they fundamentally won't change the way it's written. The actual experience of using global type inference, immutability, sum types, currying (& partial application) and well thought out exhaustive pattern matching cannot be replicated by bolting them onto a fundamentally imperative OOP language.
  - tasogare 5y ago
    The lack of sum types is the main offender that blocks any C# code is evee be even remotely close to F#.
  - johnb1984 5y ago
    Lack of a "unit" type is also a huge issue. e.g. need to create Task<'T> and non-generic Task, or Action<'T> and Func<'T1, 'T2> due to "Void" not being an actual type...
- reader_mode 5y ago
  Meh - it's not really about "best features" or whatever. C# is getting expressive enough where it's not a pain point and it has widespread adoption and is platform default = no reason to go F# unless you're looking for a FP language.
gameswithgo 5y ago
I don't know the history of F# at Olo, but they use it in production projects and in a lot of internal tools. It has been well received, C# devs usually have no problem picking it up when needed and enjoy it. We are still ~90% C# but the F# code isn't going anywhere.
kirse 5y ago
because people have shit to do and no time to study a new language at work Which is really a positive - if you start a new effort in F#, it basically self-selects for the most technically curious or proficient devs. Most corporate C# code-slingers are fearful of learning it or putting themselves through the mindset shift required to grok basic FP principles. "Do you know or are you interested in learning F#" becomes the only interview question required. But I do agree, if you have to build a team around the "least common denominator" then pick the boring tech stack and go.
- majormajor 5y ago
  Willingness to try a language or framework is an extremely poor selection criteria for being able to use it well or even being willing to learn how to use it well. I've seen enough shit-ass Ruby or Kotlin or Scala from people who were like "awesome, I love learning new languages!" but never got past "oh, what's the fastest hack I can find to do this in a similar way to how I'd do it in the last language I used?"
- reader_mode 5y ago
  Introducing something into an existing team and starting a project or team are very different things. But I share some of your reasoning and am curious how this actually plays out (I haven't seen any examples so far). One project I worked on, when starting they wanted to do Clojure and they ended up using RoR because everyone was using it and Clojure was a hiring concern. In retrospect RoR fell out of favour, there's a bunch of vacancies for it but it's not very hot so it's hard to find devs and they are forced to take "learn on the job" just like with Clojure, plus you need to compete with a bunch of employers looking to support their projects in now out of fashion stack. I think using Clojure would give them a unique candidate pool and be a hiring differentiator. But that's just speculation. I haven't actually seen how this choice works out in practice.
  - kirse 5y ago
    Jane Street (OCaml) and Jet.com (F#, sold to Wal-Mart) are two obvious $B examples. It seems to be more industry-dependent as well.
zarkov99 5y ago
Jesus, you described what happened in my company exactly. Now no one wants to touch that code, the build system is a constant pain, we are stuck in an old version of the tools. The way out is going to be a rewrite.
phillipcarter 5y ago
> I've heard of F# only projects doing great, but I think you need to have a team committed to doing F#. This is very accurate, and speaks more towards the sociotechnical systems at play here than anything else. It's not just about being a fan of F# and getting management to approve you using it. You need to cultivate an environment where others want to use it too.

__s 5y ago

I've been that guy. & yeah, found greener pastures a couple years later No regrets, canopy was an absolute pleasure to use https://lefthandedgoat.github.io/canopy https://lefthandedgoat.github.io/canopy

spywaregorilla 5y ago
> No regrets The victim of this pattern is not you
- __s 5y ago
  I have a conscience, if I did anyone wrong, I'd regret it; the code I left behind has stood on its own
- blacktriangle 5y ago
  Consulting and working full time have the same problem, you need to program for the customer, not for yourself. If you work with people who are unwilling and/or unable to learn a tool, then DO NOT use that tool. It doesn't matter how much better it makes your life, you've taken a more or less functional organization and given them a bus factor of 1, where that 1 is you and clearly if you're so high on your tool you're willing to shove it down the orgs throat, you're probably looking to leave already.
  - jrsj 5y ago
    Doesn’t that sort of increase your own value to the organization though as well? It would vary based on the situation but it seems like this could sort of work to your advantage if you’re the only person who can reasonably work on something critical (and others can’t be bothered to learn)
    - blacktriangle 5y ago
      I guess, but I think that behavior falls under a dark pattern of employment. I'm not saying you can't introduce new ideas into your organization, but this is where the politics of development comes into play. You need to get buy-in from your team and management, otherwise you're intentionally hurting your organization.
    - evfanknitram 5y ago
      It also means when there's an outage due to X during christmas or whatever, then you're the only person who can reasonable work on it. Great work.
    - mjmahone17 5y ago
      Only if you can ensure no one ever replaces what you wrote with their own solution. You become critical in the short term, but also critical to the business to replace in the long term, in the same way that a vendor tripling their price often results in short term profits while customers transition off of them, leading to a long term decline in revenue.
    - 5y ago
gagege 5y ago
I was that guy too at one job. It was wonderful to work on a few F# projects, but I have no doubt they quickly went away after I left.
- evfanknitram 5y ago
  I have been on the 'receiving' end of such persons actions. We had one guy who worked probably 50% of his time on using not F#, but another "nice" thing. It never worked well and he spent an incredible amount of time patching it and fixing issues with it. I threw it out the day after and replaced it with some older boring technology, and the problems just went away.
  - gagege 5y ago
    Bravo. Yeah, I learned my lesson.

Kototama 5y ago

It's true that bringing in a new technology without support of your team is a bad idea. However just rejecting F# per se because C# has a lot of features is missing the point. Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it.

reader_mode 5y ago
I think F# in the context of C# replacement (as a superior language) is not worth it. If you have a team looking for a functional language on .NET it's amazing - so I don't dismiss it - it's just a very niche thing on .NET platform.
trimbo 5y ago
> Engineering is about trade-off and if for a given project with a given team F# is the best choice - given the information available - please go for it. What objective measure can someone use to determine whether F# is the best choice?
- Kototama 5y ago
  Pure data-driven decisions would not be possible here, I'm afraid, because there are not enough studies about which language/framework is the more productive in a given situation (and doing such a study is super tricky, because the competences of the participants can very greatly). What is possible however is to first analyze the core attributes of the techs which are relevant for the project and team such as: good supported libraries for the problem, support for immutable data-structure, expressiveness of the type system, experience of the team with the tech etc. You can then decide which tech fits better the environment. If still undecided you can try to build a prototype on a short period (at the risk on giving up on technologies which are hard to learn but could be rewarding on the long term).
  - foobiekr 5y ago
    I don’t think it matters what language people think is most productive. What really matters is what language you can hire for. In the end you have to have people to do the work. I used to be a very big fan of a certain functional language, and invested serious time and effort into projects in that language, but hindsight tells me every single time it was a mistake. It was a mistake because if you cannot hire people to do the work then the project dies when it needs to grow. People used to do very big projects in COBOL, which most hacker news readers have never even seen, and as someone who did some COBOL, I can confirm that it was absolutely terrible, but the projects got done and by and large with less tech stack Jenga or superfluous trash that infests so many projects today. COBOL died when the majority of people moved on, not because st80, pascal, ada and C were better, but because the industry switched to platforms where the dominant languages were day one different: pascal and C. Mac, Windows, the Unix workstations. Maybe those platforms used other languages because they were better. Certainly I can’t imagine the Mac built with COBOL, FORTRAN, bcpl (worked for amiga, somewhat), etc. but the dynamic of leaders is different from the dynamic of followers.

MangoCoffee 5y ago

> C# is picking up a lot of small things that make it incrementally better than it was before agree. C# is kind of morphing into F# with new features like record.

corysama 5y ago
C# is Microsoft Research’s multi-decade play to convince Java programmers to become Ocaml programmers so slowly that they don’t notice.
- pjmlp 5y ago
  Given that Java was Sun's attempt to bring C++ developers half way to Lisp, and C# was born out of a lawsuit due to stuff like adding Forms, COM, events and P/Invoke to Java, maybe not.
the_only_law 5y ago
I can’t remember if it was a joke or serious, but I recall some comment on HN a while back trying to explain why Java was an ML.
- Zababa 5y ago
  Is it this one? https://news.ycombinator.com/item?id=26366665 https://news.ycombinator.com/item?id=26366665 The comment itself makes sense, though I don't know how is the adoption of new features in the ecosystem.
xupybd 5y ago
C# is OO by default, F# is functional by default. Both support either but it's easier to use the tool dedicated to the style you want to program in.
ddek 5y ago
I see this take a lot, and vehemently disagree. An OO language with record types and pattern matching expressions, plus a vague hint of union types in the future; is not a functional language. Depending on who you ask, it's either a quasi-functional OO language or a bloated OO language. I used to be in the first camp, now I lean towards the latter. Over time, projects morph into the average of their framework. If you started off badly, if it survives long enough eventually someone will refactor it into something acceptable. If you start off using FP features, eventually they will be eroded away; through friction with external dependencies, or later developers being less invested in the paradigm. In both cases you're usually left with an inconsistent codebase. When people say that C# is morphing into F#, my usual thought is 'have you ever seen an FP project?' Take some time and read some FP codebases, and compare them with a typical C# codebase. (side-note: one of the most widely used FP language for web development is elixir. There are a few good open-source elixir projects you can read to get a feel for the structure. Almost all elixir projects follow the same structure, and it's about as anti OO/SOLID as possible, yet still conforming to a vague onion architecture.)

jimbokun 5y ago

The lesson: Programming language adoption is based on politics, not technical merit. This isn't inherently bad, but is important to remember. Languages are successful due to the community that rises up around them, far moreso than anything inherent to the design or quality of the language itself. Which can be correlated, but not necessarily so.

pfraze 5y ago
It’s not all one or another. PLs are a software product and they need proper marketing and PMF. You can describe the network effect as political but its the same kind of politics as getting your friends to change chat apps.
jensensbutton 5y ago
Why politics and not practicality? Taking a ton of time and resources (and potentially risking attrition) to migrate a thing that works to a thing that _hopefully_ works often simply doesn't make business sense. It's not a political decision (in the common usage of the word).
- frenchy 5y ago
  Practicality is a big part of the politics, but there's real politics at play as well. Different developers will have different levels of comfort with different tool chains, and different capacities to work outside their comfort zone. This is overly reductive, but here's an example: if you have 3 developers, and 1 will be twice as productive in F# and the others will be 10% less productive, it's probably practical sense to switch, but the 2 developers will resist it, and it may fail for political reasons.
AnimalMuppet 5y ago
I don't think that's the lesson. The problem described is with maintainability. That's not political; that's technical. (It just looks political, because people say "No, you can't use that language" after they've seen the maintainability problem a few times.)

jarcane 5y ago

IMO C# is picking up a lot of small things that make it incrementally better than it was before, and at some point it's not worth the hassle to go to F#. F# features are gradually added to C# so C# developers have time to pick them up as well. You cannot add the best features of F# to C# without making it a fundamentally different language. You're not gonna make C# into a type-inferred FP language by bolting on some random half-understood bits anymore than you can make a cat jump better by gluing rabbit legs onto it. It's the core paradigm and philosophy that makes it great, and if anything, what I've seen hold it back from its potential is insufficient support requiring essentially importing C# idioms into the language just to interop with existing libraries.

paavohtl 5y ago
Absolutely - F# is greater than the sum of its features. While it's good that C# keeps getting features inspired by F#, they fundamentally won't change the way it's written. The actual experience of using global type inference, immutability, sum types, currying (& partial application) and well thought out exhaustive pattern matching cannot be replicated by bolting them onto a fundamentally imperative OOP language.
- tasogare 5y ago
  The lack of sum types is the main offender that blocks any C# code is evee be even remotely close to F#.
- johnb1984 5y ago
  Lack of a "unit" type is also a huge issue. e.g. need to create Task<'T> and non-generic Task, or Action<'T> and Func<'T1, 'T2> due to "Void" not being an actual type...
reader_mode 5y ago
Meh - it's not really about "best features" or whatever. C# is getting expressive enough where it's not a pain point and it has widespread adoption and is platform default = no reason to go F# unless you're looking for a FP language.

gameswithgo 5y ago

I don't know the history of F# at Olo, but they use it in production projects and in a lot of internal tools. It has been well received, C# devs usually have no problem picking it up when needed and enjoy it. We are still ~90% C# but the F# code isn't going anywhere.

kirse 5y ago

because people have shit to do and no time to study a new language at work Which is really a positive - if you start a new effort in F#, it basically self-selects for the most technically curious or proficient devs. Most corporate C# code-slingers are fearful of learning it or putting themselves through the mindset shift required to grok basic FP principles. "Do you know or are you interested in learning F#" becomes the only interview question required. But I do agree, if you have to build a team around the "least common denominator" then pick the boring tech stack and go.

majormajor 5y ago
Willingness to try a language or framework is an extremely poor selection criteria for being able to use it well or even being willing to learn how to use it well. I've seen enough shit-ass Ruby or Kotlin or Scala from people who were like "awesome, I love learning new languages!" but never got past "oh, what's the fastest hack I can find to do this in a similar way to how I'd do it in the last language I used?"
reader_mode 5y ago
Introducing something into an existing team and starting a project or team are very different things. But I share some of your reasoning and am curious how this actually plays out (I haven't seen any examples so far). One project I worked on, when starting they wanted to do Clojure and they ended up using RoR because everyone was using it and Clojure was a hiring concern. In retrospect RoR fell out of favour, there's a bunch of vacancies for it but it's not very hot so it's hard to find devs and they are forced to take "learn on the job" just like with Clojure, plus you need to compete with a bunch of employers looking to support their projects in now out of fashion stack. I think using Clojure would give them a unique candidate pool and be a hiring differentiator. But that's just speculation. I haven't actually seen how this choice works out in practice.
- kirse 5y ago
  Jane Street (OCaml) and Jet.com (F#, sold to Wal-Mart) are two obvious $B examples. It seems to be more industry-dependent as well.

zarkov99 5y ago

Jesus, you described what happened in my company exactly. Now no one wants to touch that code, the build system is a constant pain, we are stuck in an old version of the tools. The way out is going to be a rewrite.

phillipcarter 5y ago

> I've heard of F# only projects doing great, but I think you need to have a team committed to doing F#. This is very accurate, and speaks more towards the sociotechnical systems at play here than anything else. It's not just about being a fan of F# and getting management to approve you using it. You need to cultivate an environment where others want to use it too.