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.
F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.
F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration.
Basically having the pivot efforts being sabotaged by the same company.
I don't think it matters how good or bad C# is, Object Oriented Programming is a mess
Learning, how to use an Object System (a tree of objects/classes) is inherently hard
The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling Objects calling Objects and more Objects
OOP is bad because eventually OO systems becomes too complex, OO API is intimidation
Separating Data from Behavior manages complexity better
If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it
> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
That's right. I mostly switched to writing "dumb records + service classes" code in C#, and while F# is terser, there's just not enough pain to cause me to switch. When DU's come to C#, the gap will get even narrower.
I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!
Your "career calculus" article has been top of mind for me recently as I've talked about it a bunch of people. Amusing how those core concepts don't change much.
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.
> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.
C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#.
However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work.
I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.
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 +).
I think another problem was that Microsoft downplayed F#. They didn't support it in SSIS packages, or fully support it in MVC projects. Those were the main things I did back then. I really wanted to use F# and had the freedom to do so, but had to conclude I'd be faster sticking with C# than switching back and forth.
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#.
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.
That's weird. I use F# because of its pragmaticism. Every other language tacks on feature after feature. I would say my F# code is boring, which is what I love about F#. And it's especially boring compared to other functional languages. The other pragmatic functional languages are Erlang and Elixir.
I would consider most popular languages, like C#, Java, and Python decidely unpragmatic as languages. There's way too many hoops to jump through to concisely describe the problem domain. In F#, I define some types that describe the domain, write some functions, and move on. It's that easy.
I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced.
Scala developers were referred to a Java refugees, Swift developers to Objective C refugees, and F# as C# refugees. A weird side effect of Microsoft doing a better job with C# is that there less of a push to F#. Plus F# by virtue of being in Dev Div had the core value proposition (Ocaml on .Net) undermined by the Win vs Dev Div internal battles that tried and failed to kill .Net.
I disagree on almost every count: it's a badly written essay, but it makes a valid point.
> 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.
Does this mean that you're measuring, like, how fast someone can deploy a CRUD webapp in the given language? I can imagine F# would do poorly on that kind of metric; it's optimized for maintainability and doesn't take unprincipled shortcuts, whereas something like Ruby lets you type one line and it will blat out a bunch of defaults via unmaintainable magic.
> 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.
I don't think it's a general problem; almost everyone who spends any significant time working in F# returns to C# reluctantly if at all. It's already a "better" language in the sense of how nice it is to program in and how productive a programmer feels when doing so. But those aren't the metrics that matter.
That's interesting, because I've tried to use F# several times, and never really felt comfortable. I've written in a bunch of different languages and F# is probably the most disappointing because of how much I want to like it.
I feel like F# deceptively presents itself as simple, when in reality it is closer to C# in complexity. I've written in languages that are actually simple (tcl) and it is a joy. I've written in languages that are unashamedly complex (Wolfram language) and that is also fun. But F# occupies that weird middle ground where it seems easy to do what you want, but for some reason you trip over your own shoelaces every time you take a step.
Curious about what one of your typical "practical exercises" looks like?
I'm not a great fan of f# (it's not rational - but every time I've tried to dip my toes, something in the syntax has felt... Tedious? In a way that for example StandardML does not). But it still seems like an eminently powerful and pragmatic language, so I'm surprised by your experience.
Fascinating that fsharpers trip up on ad- hoc json wrangling - to be fair i used to agonize over nested lists/association lists in lisp - rather than doing the "professional" thing and YOLO assume that three levels down, behind :user - there's a fifth element :email...
I'd love to know what dynamic programming exercises you're asking interviewees to complete in the timespan of an interview that wouldn't show up on LeetCode.
> 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.
Maybe I am mistaken here, but it seems to me that the line you are quoting from the essay implies the opposite of what you said.
>If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time
As someone that has just spent a while learning F# and really enjoys it, this makes me sad. I hope that I don't have some trait that drew me to F# that also causes me to be less competent.
Are you implying this is a F# problem? What language do candidates do well in?
Is F# too approachable due to its closeness to C#, popular with C# professionals, and therefore not approached as a functional programming language as much as a C# extension?
Just curious what kind of career did you have that enabled you to have a long stint as function programmer? The fact that you don't use Leet code makes it also sound you are not FAANG so makes it more intriguing.
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.
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.
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.
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".
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.
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.
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.
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.
> 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
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.
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.
"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.
[+] [-] ericsink|2 years ago|reply
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.
[+] [-] lambdaxymox|2 years ago|reply
[+] [-] ThinkBeat|2 years ago|reply
I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea.
I would much have preferred to keep C# OO and use F# when you want to go functional.
Or just create G# which is the everything mashed together language that C# is close to being.
[+] [-] pjmlp|2 years ago|reply
Basically having the pivot efforts being sabotaged by the same company.
[+] [-] systems|2 years ago|reply
Learning, how to use an Object System (a tree of objects/classes) is inherently hard
The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling Objects calling Objects and more Objects
OOP is bad because eventually OO systems becomes too complex, OO API is intimidation
Separating Data from Behavior manages complexity better
If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it
[+] [-] orthoxerox|2 years ago|reply
That's right. I mostly switched to writing "dumb records + service classes" code in C#, and while F# is terser, there's just not enough pain to cause me to switch. When DU's come to C#, the gap will get even narrower.
[+] [-] pharmakom|2 years ago|reply
[+] [-] caseysoftware|2 years ago|reply
Your "career calculus" article has been top of mind for me recently as I've talked about it a bunch of people. Amusing how those core concepts don't change much.
[+] [-] mastazi|2 years ago|reply
[+] [-] aaronmu|2 years ago|reply
C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#.
However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work.
I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.
[+] [-] throw868788|2 years ago|reply
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 +).
[+] [-] DennisP|2 years ago|reply
[+] [-] CrimsonCape|2 years ago|reply
[+] [-] 7thaccount|2 years ago|reply
[+] [-] Andys|2 years ago|reply
[+] [-] sproketboy|2 years ago|reply
[deleted]
[+] [-] mochaki|2 years ago|reply
[deleted]
[+] [-] gemstones|2 years ago|reply
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
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.[+] [-] bmitc|2 years ago|reply
I would consider most popular languages, like C#, Java, and Python decidely unpragmatic as languages. There's way too many hoops to jump through to concisely describe the problem domain. In F#, I define some types that describe the domain, write some functions, and move on. It's that easy.
[+] [-] cjbgkagh|2 years ago|reply
Scala developers were referred to a Java refugees, Swift developers to Objective C refugees, and F# as C# refugees. A weird side effect of Microsoft doing a better job with C# is that there less of a push to F#. Plus F# by virtue of being in Dev Div had the core value proposition (Ocaml on .Net) undermined by the Win vs Dev Div internal battles that tried and failed to kill .Net.
[+] [-] lmm|2 years ago|reply
> 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.
Does this mean that you're measuring, like, how fast someone can deploy a CRUD webapp in the given language? I can imagine F# would do poorly on that kind of metric; it's optimized for maintainability and doesn't take unprincipled shortcuts, whereas something like Ruby lets you type one line and it will blat out a bunch of defaults via unmaintainable magic.
> 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.
I don't think it's a general problem; almost everyone who spends any significant time working in F# returns to C# reluctantly if at all. It's already a "better" language in the sense of how nice it is to program in and how productive a programmer feels when doing so. But those aren't the metrics that matter.
[+] [-] bloaf|2 years ago|reply
I feel like F# deceptively presents itself as simple, when in reality it is closer to C# in complexity. I've written in languages that are actually simple (tcl) and it is a joy. I've written in languages that are unashamedly complex (Wolfram language) and that is also fun. But F# occupies that weird middle ground where it seems easy to do what you want, but for some reason you trip over your own shoelaces every time you take a step.
[+] [-] paulddraper|2 years ago|reply
In my experience, the worst performance is by C++ candidates.
Why? Not because C++ is bad, or attracts bad programmers.
Rather, because if that's the language you reach for a quick solve, you probably don't know very much, and that says something.
[+] [-] e12e|2 years ago|reply
I'm not a great fan of f# (it's not rational - but every time I've tried to dip my toes, something in the syntax has felt... Tedious? In a way that for example StandardML does not). But it still seems like an eminently powerful and pragmatic language, so I'm surprised by your experience.
Ed: I see this was addressed downthread:
https://news.ycombinator.com/item?id=36133560
https://news.ycombinator.com/item?id=36133578
Fascinating that fsharpers trip up on ad- hoc json wrangling - to be fair i used to agonize over nested lists/association lists in lisp - rather than doing the "professional" thing and YOLO assume that three levels down, behind :user - there's a fifth element :email...
[+] [-] jacamera|2 years ago|reply
[+] [-] EdwardDiego|2 years ago|reply
[+] [-] DonHopkins|2 years ago|reply
[+] [-] Fervicus|2 years ago|reply
Maybe I am mistaken here, but it seems to me that the line you are quoting from the essay implies the opposite of what you said.
[+] [-] xupybd|2 years ago|reply
As someone that has just spent a while learning F# and really enjoys it, this makes me sad. I hope that I don't have some trait that drew me to F# that also causes me to be less competent.
[+] [-] WalterBright|2 years ago|reply
I.e. social proof
[+] [-] keyle|2 years ago|reply
Is F# too approachable due to its closeness to C#, popular with C# professionals, and therefore not approached as a functional programming language as much as a C# extension?
[+] [-] ak_111|2 years ago|reply
[+] [-] muglug|2 years ago|reply
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.
[+] [-] xupybd|2 years ago|reply
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.
[+] [-] raphinou|2 years ago|reply
[+] [-] ideasman42|2 years ago|reply
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".
[+] [-] keithnz|2 years ago|reply
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.
[+] [-] slfjw____|2 years ago|reply
* 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
[+] [-] FrustratedMonky|2 years ago|reply
[+] [-] d--b|2 years ago|reply
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.
[+] [-] jacamera|2 years ago|reply
> 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.
[+] [-] ReleaseCandidat|2 years ago|reply
[+] [-] Fervicus|2 years ago|reply
[+] [-] chrfrasco|2 years ago|reply
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
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] waffletower|2 years ago|reply
[+] [-] nneonneo|2 years ago|reply
[+] [-] dzdt|2 years ago|reply
[+] [-] banashark|2 years ago|reply
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.
[+] [-] tragomaskhalos|2 years ago|reply