21 ms·

Why F# evangelism isn't working (2015)

202 points by luu 3y ago

medler 3y ago
I like OCaml quite a lot so I’m F#-curious but I don’t know anything about the .NET environment and don’t currently have any need to program on Windows. What are the trade-offs between OCaml and F# for programming on Linux?
dzdt 3y ago
(2015)
- aaronbrethorst 3y ago
  I really scratched my head at this one, at first. "Why your F# evangelism isn't working" — uhh, maybe because it's a decade late?
gemstones 3y ago
This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time. For some reason the candidates just do not do well. Now I can think of some confounders - maybe the types of people who would apply to a job with some dynamic programming requirements and people who are good at F# just have no overlap. I've thought about that. But it seems like this line Pragmatists don't make technology decisions on the basis of what is better. They prefer the safety of the herd. Implies that if someone just saw some code in F# and realized what people can do in it, they would be super impressed. I have not found that to be the case. If that's a general problem and not just a quirk of my personal experience, that has to be fixed first.
- EdwardDiego 3y ago
  I found F# great for dynamic programming, do you recall what tripped them up?
  - gemstones 3y ago
    Parsing realistic (messy) JSON, usually. I would have expected F# to shine at that due to type providers, so it was doubly surprising to me. The F# candidates I've seen spend most of the interview manipulating the data.
    - nick__m 3y ago
      Those F# candidates would have been be better to use C# to do the adhoc data wrangling and F# for algorithmic part of the program.
      - FrustratedMonky 3y ago
        Isn't ad-hoc data wrangling the feature of F#? Why are so many people here against F# for reading/manipulating ad-hoc data, that's what it is good for.
    - throwa18991900 3y ago
      I've seen the opposite, and have seen some pretty big fast large professional systems being built in it. Admittedly most of them are closed source, and the community contribution allowed to be made is small. Most of the developers using it normally just market themselves as C# developers when they change job because of some of the above opinions they see online. Have seen speed comparisons compared to other similar tiered languages internally where F# shines with less code as well particuarly around math (C# is just starting to catch up here). Even seen dynamic problems solved in it to your point in a professional setting to speed up very often run calculations to a large customer base. However technical capability and efficiency of the tool isn't the only concern picking up the comments in this thread so far. The herd effect sadly can make people nervous creating a barrier for people to try it especially if career is in it. What other people think of it, and their preconceived notion can matter.
keithnz 3y ago
just as true today as 2015 when the article was written, except C# got even better. While I like the F# language, I don't like the (understandably) abandonware of the small community. I've ported most of my F# stuff to C#, and it's not that much different in that you can program in a functional style in C#. Probably the nicest thing in F# that C# doesn't have is computation expressions.
- KurtMueller 3y ago
  ... or units of measure
  - eyelidlessness 3y ago
    This is a surprising gap for most non-ML type systems from what I’ve gathered. I don’t understand the gap, tbh. Most of us aren’t slinging primitive values with no particular domain in mind, it’s weird that we have to encode most of the domain in naming conventions and docs.
  - keithnz 3y ago
    while I like it, it doesn't actually seem that useful.... and given I work on IoT systems measuring all kinds of things in all kinds of units, it isn't at all useful for that. Kind of cool for when you are using F# as a calculator though
    - zogrodea 3y ago
      I haven't found them useful in my experience either, but they seem to have a real indispensable utility in some cases like algebra for simulations. At least, that is what I gathered from Matthew Crews who has the "FastFSharp" channel on YouTube and a Twitter account with the same name. (He employs mutability heavily for performance, so not what I think of as an average F# developer.)
- runevault 3y ago
  On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.
slfjw____ 3y ago
Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation * two error handling models: Result (monadic but without do notation) & C# style Exceptions * not rich in community libraries, like a desert & abandonware
- xupybd 3y ago
  > not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?
  - jasdfwef 3y ago
    They may have meant F# packages
  - pjmlp 3y ago
    Right, but like the curse of guest languages (which F# isn't one), they decided to create their own ecosystem. So using .NET libraries directly is frowned upon, while some of them like GUI frameworks, expect C# features (like Roslyn and Code Generators) not available in F#.
  - rami3l 3y ago
    The last time I gave F# a shot, I tried to write a simple Telegram bot in it. Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results). I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181 https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe. I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.
- lostmsu 3y ago
  * the complexity of the compiler makes it hard to make it better
jacamera 3y ago
I feel like this article is dead on. It's old but the principles still hold true. > Because C# is really, really good. The first language I learned was VB.net because I thought "Visual Basic" sounded easy. I quickly moved to C# because it was more popular. I've always been curious about F# but never invested the time to learn it exactly because C# never caused me enough pain.
wly_cdgr 3y ago
It doesn't help that C# has a much, much better name for the purposes of appealing to Pragmatists (in the article's terminology). Every Pragmatist knows that C is a trusted and proven language. So, something that is an improvement or iteration on C is probably fine, too. But what is F? No one knows.
- jjgreen 3y ago
  When I first saw it mentioned, I assumed a Microsoft version of Fortran :-|
- hardware2win 3y ago
  C being trusted?
cratermoon 3y ago
2015
nneonneo 3y ago
Needs a (2015) tag, but seems awfully relevant even today.
muglug 3y ago
Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next decade will see a reduction in programming language diversity. JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Platform-specific languages like Swift will persevere, as will Java, which is unkillable, but the vast array of languages will become less vast.
- Semaphor 3y ago
  > JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Why do you see the popularity of C# waning?
  - lostmsu 3y ago
    Rust might take its place if the tooling would be on par. Personally I'd jump.
    - pjmlp 3y ago
      Good luck having the whole .NET Windows ecosystem rewritten in Rust.
      - lostmsu 3y ago
        Eh. It is vast, but the tide is shifting. Non-UI components were never that good. WPF is in maintenance mode. And there is a growing need for deep learning which is currently a total lackluster in .NET
        pjmlp 3y ago
        Still, more likely to be Python and C++ than Rust. See ONYX, DirectML and ML.NET announcements at BUILD.
xupybd 3y ago
I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning curve to get over. Critical mass is a problem for all new languages and often it's not the best language that will win critical mass. It's the one that gets adopted for reasons that aren't always merit (see javascript). I pick F# because it's easier for me to avoid silly mistakes. I find my code is easier to change and it's harder to write some classes of bugs. It's also very pleasant to use. But C# is pretty good at all of these things, F# is just a little bit nicer. But that little bit comes at a big cost of being very different.
- 2h 3y ago
  > Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.
  - xupybd 3y ago
    Yes I think the The Functional Core, Imperative Shell Pattern is a good way to do things. But somethings take a bit of ramping up. Like the option type, it is great and works well with pattern matching. If you don't know why exhaustive pattern matching with union types and options instead of nulls is amazing then it just feels like coding with your hands tied.
  - epgui 3y ago
    > some people insist on using functional tactics EVERYWHERE It’s difficult to relate to this without specific examples (I don’t think I agree with the sentiment on balance, but I could also imagine all kinds of obviously-bad things), but FP really does transcend other programming paradigms. Languages such as Java and C++ code definitely do benefit from FP approaches, even if these languages are perhaps not the best at facilitating the approach.
Fervicus 3y ago
I love C# and it keeps getting better and better, but I don't get the same level of satisfaction with it that I do with F#
- arwhatever 3y ago
  Im pretty fond of C# as well, but pretty often the type system feels like it leaks like a sieve compared to F#.
chrfrasco 3y ago
> This is how a new product gets across the chasm. Find a pragmatist in pain. Do whatever-it-takes to make them happy with your product. Then go back and do it again. Good advice, I think the useful idea is: An excellent product in competition with a very good incumbent is a bad idea. A mediocre product in competition with an absent or terrible incumbent is a great idea
ideasman42 3y ago
This article misses that there are pragmatists are not the kind of technology-disinterested "normal" people. An individual may have the same values as an early adopter, while having to make the decision to used tried and true systems for various reasons out of their control - one of which might be that you depend heavily on the continued development & support of surrounding ecosystems. Or that large code-bases can't simply switch to a new technology without it being a massive multi-year undertaking which is difficult to justify. So while the article makes some reasonable points, I think it doesn't fully take into account that pragmatists often use what they use for better reasons than "following the herd".
- makeitdouble 3y ago
  I read both your examples as instances of "following the herd". The expression has negative connotations in litterature and net circles, but that's exactly a pragmatic behavior most of the time. I'm also "following the herd" when choosing a platform that will make it easier/cheaper to hire (there is an existing "herd" of developpers), or has wide support by multiple vendors etc .
dang 3y ago
Discussed (a bit) at the time: Why F# evangelism isn't working - https://news.ycombinator.com/item?id=8841534 https://news.ycombinator.com/item?id=8841534 - Jan 2015 (5 comments)
ericsink 3y ago
(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
- mastazi 3y ago
  Also, you correctly anticipated that Swift would become mainstream long before F#, which happened. Of course hindsight is 20/20, but this wasn't that obvious back in 2015. Your reasoning was sound.
  - zokier 3y ago
    Swift is still very much a niche language. Its a big niche, but niche nevertheless.
- 7thaccount 3y ago
  I really wanted to learn it, but I wanted to learn F# & not C#. The problem is...you can't really learn F# without knowing .NET and how it does all the OO stuff. Even the most basic things that require one easily googleable line in Python would return no results for F#. You just have to figure it out in C# and then you can apply to F#.
- throw868788 3y ago
  Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example. Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).
banashark 3y ago
I find it interesting to compare F# with Kotlin. F# had Jet as the one large success story of a full f# shop, but outside of that there weren't many large companies using a lot of F# (except microsoft internally, and they didn't blog about it _too_ much). Kotlin on the other hand is seeing server-side adoption in quite a few large companies. Google is recommending it as the server-side JVM language for new services going forward. Airbnb and a handful of other large companies blog about having kotlin services in their architecture. There's a few reasons I think Kotlin is succeeding where F# hasn't been able to: * JVM + tooling is a proven and great ecosystem. First-class support for most of your cloud tooling and databases (AWS, Kafka, ElasticSearch, Cassandra, etc). * It has fantastic editor tooling (given that an IDE company created and maintains it). F# for quite a while has had less-than-average tooling (it's gotten better now with newer versions of FSAC, Ionide, and Rider, but it was _rough_ for a while). It's hard to move to something new that's supposed to be safer when your language server has memory leaks or breaks every X hours. I remember stretches of time where I was just writing F# in vim without syntax highlighting because any editor I tried would constantly throw errors in the middle of me coding. That hasn't happened to me with Kotlin. * It's close-enough looking to a scripting language with nice features that it's more approachable. Classes and functions look similar to other languages. It even has block parameters that are inviting for rubyists (although the implementation is different). It also has some syntactic sugar to make some things very ergonomic to work with. * All of the above just works. No big fiddling necessary. The pain points in working with the Java ecosystem are written about and known (largest that come to my mind are coroutines interacting with java threading, exceptions in mixed coroutine/threading environments, and null/optional which Kotlin has some great features built-in to work around). There's also things like arrow-kt and http4k for those desiring the more functional side of things. The one thing that continues to baffle me is how little I see in people talking about kotlin in various communities (slack, discord, reddit, etc) compared to how many people are writing it (both for android and for server-side concerns). The one upside I'll give is that fable has been much better IME than my experience with Kotlin/js. I also prefer F# from a purely language standpoint, but Kotlin is just better to work with.
- pjmlp 3y ago
  Kotlin is only succeeding on Android thanks to godfather Google, it is hardly used on the JVM. On the JVM is as much as F# on the CLR, as any google trend analytics and similar will show.
d--b 3y ago
This is all very true. Mostly what I have seen happening is people really loving F# convert to using C#. The tooling being the main reason. What this article isn’t saying is that F# is awful at interoping with C# and windows APIs in general. Mostly that F# functions cannot be used as Func<> objects. So even in a C# environment, bringing some F# is a pain. Definitely didn’t help the adoption.
- Turskarama 3y ago
  Yes, it would actually help so much if F# libraries could be painlessly used in C#, it might be all that was needed. Unfortunately it's not the case. Maybe if discriminated unions are ever added to C# some real cross compatibility could be made,
waffletower 3y ago
I loved the marketing bell curve. But there were terrible opinions here which show other relevant chasms that were not detailed. Parroting C#'s supposed superiority to Objective-C shows an embarrassing lack of understanding of the languages differences, development ecosystems and strengths. I would never use C# where I needed to interact with native code -- Objective-C can do so with immense power and practicality.
tragomaskhalos 3y ago
"you can't swing a 9-iron in the Apple/iOS ecosystem without hitting a pragmatist in pain". This line was very funny, but I wonder (not being an Apple person myself) the extent to which, 8 years later, Swift has alleviated this.
ReleaseCandidat 3y ago
There is now (well, 2020) a Haskell version of this idea (Moore's "Crossing the Chasm") too, as a conference talk: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA
raphinou 3y ago
I think it shows in the community management that F# originated in a closed-source environment. For example, it is required to be a member of the F# Software Foundation to get access to F# Slack. Putting such a roadblock early in the discovery of the community is a sure way to limit your growth.
- physPop 3y ago
  you sign up with any random email address and you get an invite.. its not closed at all
FrustratedMonky 3y ago
Still crossing fingers that F# takes off. Love it, but not many jobs with it. I'm still surprised how much more can be done and better in F#, but nobody uses it. After switching brain over to that way of thinking, have trouble going back.
- BiteCode_dev 3y ago
  Don't hold your breath. The stigma of the MS touch and the fear of getting bitten in the future is a strong deterrent. You can easily migrate from github or vscode, but not your programming language.
FrustratedMonky 3y ago
I've stopped trying to explain to people why I use F# and just tell them I'm a language hipster.
revskill 3y ago
No, because of Typescript.
deleted 3y ago
[deleted]

202 points by luu 3y ago

I like OCaml quite a lot so I’m F#-curious but I don’t know anything about the .NET environment and don’t currently have any need to program on Windows. What are the trade-offs between OCaml and F# for programming on Linux?

dzdt 3y ago

(2015)

aaronbrethorst 3y ago
I really scratched my head at this one, at first. "Why your F# evangelism isn't working" — uhh, maybe because it's a decade late?

gemstones 3y ago

This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time. For some reason the candidates just do not do well. Now I can think of some confounders - maybe the types of people who would apply to a job with some dynamic programming requirements and people who are good at F# just have no overlap. I've thought about that. But it seems like this line Pragmatists don't make technology decisions on the basis of what is better. They prefer the safety of the herd. Implies that if someone just saw some code in F# and realized what people can do in it, they would be super impressed. I have not found that to be the case. If that's a general problem and not just a quirk of my personal experience, that has to be fixed first.

EdwardDiego 3y ago
I found F# great for dynamic programming, do you recall what tripped them up?
- gemstones 3y ago
  Parsing realistic (messy) JSON, usually. I would have expected F# to shine at that due to type providers, so it was doubly surprising to me. The F# candidates I've seen spend most of the interview manipulating the data.
  - nick__m 3y ago
    Those F# candidates would have been be better to use C# to do the adhoc data wrangling and F# for algorithmic part of the program.
    - FrustratedMonky 3y ago
      Isn't ad-hoc data wrangling the feature of F#? Why are so many people here against F# for reading/manipulating ad-hoc data, that's what it is good for.
  - throwa18991900 3y ago
    I've seen the opposite, and have seen some pretty big fast large professional systems being built in it. Admittedly most of them are closed source, and the community contribution allowed to be made is small. Most of the developers using it normally just market themselves as C# developers when they change job because of some of the above opinions they see online. Have seen speed comparisons compared to other similar tiered languages internally where F# shines with less code as well particuarly around math (C# is just starting to catch up here). Even seen dynamic problems solved in it to your point in a professional setting to speed up very often run calculations to a large customer base. However technical capability and efficiency of the tool isn't the only concern picking up the comments in this thread so far. The herd effect sadly can make people nervous creating a barrier for people to try it especially if career is in it. What other people think of it, and their preconceived notion can matter.

keithnz 3y ago

just as true today as 2015 when the article was written, except C# got even better. While I like the F# language, I don't like the (understandably) abandonware of the small community. I've ported most of my F# stuff to C#, and it's not that much different in that you can program in a functional style in C#. Probably the nicest thing in F# that C# doesn't have is computation expressions.

KurtMueller 3y ago
... or units of measure
- eyelidlessness 3y ago
  This is a surprising gap for most non-ML type systems from what I’ve gathered. I don’t understand the gap, tbh. Most of us aren’t slinging primitive values with no particular domain in mind, it’s weird that we have to encode most of the domain in naming conventions and docs.
- keithnz 3y ago
  while I like it, it doesn't actually seem that useful.... and given I work on IoT systems measuring all kinds of things in all kinds of units, it isn't at all useful for that. Kind of cool for when you are using F# as a calculator though
  - zogrodea 3y ago
    I haven't found them useful in my experience either, but they seem to have a real indispensable utility in some cases like algebra for simulations. At least, that is what I gathered from Matthew Crews who has the "FastFSharp" channel on YouTube and a Twitter account with the same name. (He employs mutability heavily for performance, so not what I think of as an average F# developer.)
runevault 3y ago
On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.

slfjw____ 3y ago

Likely will never use again * two async models present: task (C#) & async (f#) * horrible async performance: perhaps fixed by native task & FSM transformation * two error handling models: Result (monadic but without do notation) & C# style Exceptions * not rich in community libraries, like a desert & abandonware

xupybd 3y ago
> not rich in community libraries, like a desert & abandonware You have access to the entire .net ecosystem?
- jasdfwef 3y ago
  They may have meant F# packages
- pjmlp 3y ago
  Right, but like the curse of guest languages (which F# isn't one), they decided to create their own ecosystem. So using .NET libraries directly is frowned upon, while some of them like GUI frameworks, expect C# features (like Roslyn and Code Generators) not available in F#.
- rami3l 3y ago
  The last time I gave F# a shot, I tried to write a simple Telegram bot in it. Just to test how much I would actually benefit from the .NET ecosystem, I chose to use a C# wrapper for the Telegram API. Suddenly I had to handle null references and exceptions everywhere (it's in this regard even worse than Rust, where I'm guaranteed to get Options and Results). I know proper support for C# T? type interop is in the works (https://github.com/dotnet/fsharp/pull/15181 https://github.com/dotnet/fsharp/pull/15181), but really it seemed to me that too few cared about F# to get it landed in a reasonable timeframe. I'd really love to see a pragmatic FP language with a reasonable amount of libs to choose from (both natively and via interop without much effort), but F# was a bit far from that description IMO.
lostmsu 3y ago
* the complexity of the compiler makes it hard to make it better

jacamera 3y ago

I feel like this article is dead on. It's old but the principles still hold true. > Because C# is really, really good. The first language I learned was VB.net because I thought "Visual Basic" sounded easy. I quickly moved to C# because it was more popular. I've always been curious about F# but never invested the time to learn it exactly because C# never caused me enough pain.

wly_cdgr 3y ago

It doesn't help that C# has a much, much better name for the purposes of appealing to Pragmatists (in the article's terminology). Every Pragmatist knows that C is a trusted and proven language. So, something that is an improvement or iteration on C is probably fine, too. But what is F? No one knows.

jjgreen 3y ago
When I first saw it mentioned, I assumed a Microsoft version of Fortran :-|
hardware2win 3y ago
C being trusted?

cratermoon 3y ago

2015

nneonneo 3y ago

Needs a (2015) tag, but seems awfully relevant even today.

muglug 3y ago

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next decade will see a reduction in programming language diversity. JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Platform-specific languages like Swift will persevere, as will Java, which is unkillable, but the vast array of languages will become less vast.

Semaphor 3y ago
> JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Why do you see the popularity of C# waning?
- lostmsu 3y ago
  Rust might take its place if the tooling would be on par. Personally I'd jump.
  - pjmlp 3y ago
    Good luck having the whole .NET Windows ecosystem rewritten in Rust.
    - lostmsu 3y ago
      Eh. It is vast, but the tide is shifting. Non-UI components were never that good. WPF is in maintenance mode. And there is a growing need for deep learning which is currently a total lackluster in .NET
      - pjmlp 3y ago
        Still, more likely to be Python and C++ than Rust. See ONYX, DirectML and ML.NET announcements at BUILD.

xupybd 3y ago

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning curve to get over. Critical mass is a problem for all new languages and often it's not the best language that will win critical mass. It's the one that gets adopted for reasons that aren't always merit (see javascript). I pick F# because it's easier for me to avoid silly mistakes. I find my code is easier to change and it's harder to write some classes of bugs. It's also very pleasant to use. But C# is pretty good at all of these things, F# is just a little bit nicer. But that little bit comes at a big cost of being very different.

2h 3y ago
> Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.
- xupybd 3y ago
  Yes I think the The Functional Core, Imperative Shell Pattern is a good way to do things. But somethings take a bit of ramping up. Like the option type, it is great and works well with pattern matching. If you don't know why exhaustive pattern matching with union types and options instead of nulls is amazing then it just feels like coding with your hands tied.
- epgui 3y ago
  > some people insist on using functional tactics EVERYWHERE It’s difficult to relate to this without specific examples (I don’t think I agree with the sentiment on balance, but I could also imagine all kinds of obviously-bad things), but FP really does transcend other programming paradigms. Languages such as Java and C++ code definitely do benefit from FP approaches, even if these languages are perhaps not the best at facilitating the approach.

Fervicus 3y ago

I love C# and it keeps getting better and better, but I don't get the same level of satisfaction with it that I do with F#

arwhatever 3y ago
Im pretty fond of C# as well, but pretty often the type system feels like it leaks like a sieve compared to F#.

chrfrasco 3y ago

> This is how a new product gets across the chasm. Find a pragmatist in pain. Do whatever-it-takes to make them happy with your product. Then go back and do it again. Good advice, I think the useful idea is: An excellent product in competition with a very good incumbent is a bad idea. A mediocre product in competition with an absent or terrible incumbent is a great idea

ideasman42 3y ago

This article misses that there are pragmatists are not the kind of technology-disinterested "normal" people. An individual may have the same values as an early adopter, while having to make the decision to used tried and true systems for various reasons out of their control - one of which might be that you depend heavily on the continued development & support of surrounding ecosystems. Or that large code-bases can't simply switch to a new technology without it being a massive multi-year undertaking which is difficult to justify. So while the article makes some reasonable points, I think it doesn't fully take into account that pragmatists often use what they use for better reasons than "following the herd".

makeitdouble 3y ago
I read both your examples as instances of "following the herd". The expression has negative connotations in litterature and net circles, but that's exactly a pragmatic behavior most of the time. I'm also "following the herd" when choosing a platform that will make it easier/cheaper to hire (there is an existing "herd" of developpers), or has wide support by multiple vendors etc .

dang 3y ago

Discussed (a bit) at the time: Why F# evangelism isn't working - https://news.ycombinator.com/item?id=8841534 https://news.ycombinator.com/item?id=8841534 - Jan 2015 (5 comments)

ericsink 3y ago

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

mastazi 3y ago
Also, you correctly anticipated that Swift would become mainstream long before F#, which happened. Of course hindsight is 20/20, but this wasn't that obvious back in 2015. Your reasoning was sound.
- zokier 3y ago
  Swift is still very much a niche language. Its a big niche, but niche nevertheless.
7thaccount 3y ago
I really wanted to learn it, but I wanted to learn F# & not C#. The problem is...you can't really learn F# without knowing .NET and how it does all the OO stuff. Even the most basic things that require one easily googleable line in Python would return no results for F#. You just have to figure it out in C# and then you can apply to F#.
throw868788 3y ago
Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example. Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).

banashark 3y ago

I find it interesting to compare F# with Kotlin. F# had Jet as the one large success story of a full f# shop, but outside of that there weren't many large companies using a lot of F# (except microsoft internally, and they didn't blog about it _too_ much). Kotlin on the other hand is seeing server-side adoption in quite a few large companies. Google is recommending it as the server-side JVM language for new services going forward. Airbnb and a handful of other large companies blog about having kotlin services in their architecture. There's a few reasons I think Kotlin is succeeding where F# hasn't been able to: * JVM + tooling is a proven and great ecosystem. First-class support for most of your cloud tooling and databases (AWS, Kafka, ElasticSearch, Cassandra, etc). * It has fantastic editor tooling (given that an IDE company created and maintains it). F# for quite a while has had less-than-average tooling (it's gotten better now with newer versions of FSAC, Ionide, and Rider, but it was _rough_ for a while). It's hard to move to something new that's supposed to be safer when your language server has memory leaks or breaks every X hours. I remember stretches of time where I was just writing F# in vim without syntax highlighting because any editor I tried would constantly throw errors in the middle of me coding. That hasn't happened to me with Kotlin. * It's close-enough looking to a scripting language with nice features that it's more approachable. Classes and functions look similar to other languages. It even has block parameters that are inviting for rubyists (although the implementation is different). It also has some syntactic sugar to make some things very ergonomic to work with. * All of the above just works. No big fiddling necessary. The pain points in working with the Java ecosystem are written about and known (largest that come to my mind are coroutines interacting with java threading, exceptions in mixed coroutine/threading environments, and null/optional which Kotlin has some great features built-in to work around). There's also things like arrow-kt and http4k for those desiring the more functional side of things. The one thing that continues to baffle me is how little I see in people talking about kotlin in various communities (slack, discord, reddit, etc) compared to how many people are writing it (both for android and for server-side concerns). The one upside I'll give is that fable has been much better IME than my experience with Kotlin/js. I also prefer F# from a purely language standpoint, but Kotlin is just better to work with.

pjmlp 3y ago
Kotlin is only succeeding on Android thanks to godfather Google, it is hardly used on the JVM. On the JVM is as much as F# on the CLR, as any google trend analytics and similar will show.

d--b 3y ago

This is all very true. Mostly what I have seen happening is people really loving F# convert to using C#. The tooling being the main reason. What this article isn’t saying is that F# is awful at interoping with C# and windows APIs in general. Mostly that F# functions cannot be used as Func<> objects. So even in a C# environment, bringing some F# is a pain. Definitely didn’t help the adoption.

Turskarama 3y ago
Yes, it would actually help so much if F# libraries could be painlessly used in C#, it might be all that was needed. Unfortunately it's not the case. Maybe if discriminated unions are ever added to C# some real cross compatibility could be made,

waffletower 3y ago

I loved the marketing bell curve. But there were terrible opinions here which show other relevant chasms that were not detailed. Parroting C#'s supposed superiority to Objective-C shows an embarrassing lack of understanding of the languages differences, development ecosystems and strengths. I would never use C# where I needed to interact with native code -- Objective-C can do so with immense power and practicality.

tragomaskhalos 3y ago

"you can't swing a 9-iron in the Apple/iOS ecosystem without hitting a pragmatist in pain". This line was very funny, but I wonder (not being an Apple person myself) the extent to which, 8 years later, Swift has alleviated this.

ReleaseCandidat 3y ago

There is now (well, 2020) a Haskell version of this idea (Moore's "Crossing the Chasm") too, as a conference talk: https://www.youtube.com/watch?v=fNpsgTIpODA https://www.youtube.com/watch?v=fNpsgTIpODA

raphinou 3y ago

I think it shows in the community management that F# originated in a closed-source environment. For example, it is required to be a member of the F# Software Foundation to get access to F# Slack. Putting such a roadblock early in the discovery of the community is a sure way to limit your growth.

physPop 3y ago
you sign up with any random email address and you get an invite.. its not closed at all

FrustratedMonky 3y ago

Still crossing fingers that F# takes off. Love it, but not many jobs with it. I'm still surprised how much more can be done and better in F#, but nobody uses it. After switching brain over to that way of thinking, have trouble going back.

BiteCode_dev 3y ago
Don't hold your breath. The stigma of the MS touch and the fear of getting bitten in the future is a strong deterrent. You can easily migrate from github or vscode, but not your programming language.

FrustratedMonky 3y ago

I've stopped trying to explain to people why I use F# and just tell them I'm a language hipster.

revskill 3y ago

No, because of Typescript.

deleted 3y ago

[deleted]