Live data from Hacker News

Ask HN: Why isn't F# more popular?

news.ycombinator.com

81–90 of 115 posts

Re: Ask HN: Why isn't F# more popular?

#81

As a long-time advocate of functional programming, I was once asked after a talk what is the "best" FP language to learn. Since I'm known as a Haskell/Scala/ML person, I surprised much of the audience by answering that I thought F# was the best entry point. What I did not say, however, was that I think that Windows is a challenging environment for anyone who is used to Linux/Mac -- and this includes the "open source"…

>I would encourage you to stick with F# as you will be further along in not only understanding FP, but other modern programming languages, including ones that haven't been invented yet.

Interesting. Why do you say "including languages that haven't been invented yet"? Does F# have some features that are modern / good, but not common in some other current languages, but are likely to be there in future ones?

Re: Ask HN: Why isn't F# more popular?

#82

Earlier quoted context omitted.

C# interop doesn't seem that hard: https://fsharpforfunandprofit.com/posts/completeness-seamles... Also, from what I've read it's easy enough to use F# code from C# if you wrap it in an object. F# is multiparadigmatic, including support for FP and OOP.

I think interop is not hard, but F# still enforces functional way over imperative. Write imperative code on Scala is easier then write imperative code on F#

Okay, but wrapping functional F# code in .NET objects abstracts the functional internals away from C#. C# code can then use the F# object as if it was using a C# object. Does that address the issue you were referring to, or were you referring to something else?

Re: Ask HN: Why isn't F# more popular?

#83
post #40

Earlier quoted context omitted.

Scala may be worth a look. You can write libraries using it and pop them into Java code like it's no big deal. There's a few caveats and gotchas, but overall I've been pretty happy with what it's allowed us to do (Apache Spark in Scala especially is lovely).

Scala's future is very unclear, pick Kotlin instead.

Scala 3 first release candidate: https://news.ycombinator.com/item?id=14453196

Re: Ask HN: Why isn't F# more popular?

#84
post #26

Earlier quoted context omitted.

Node.JS specifically has a lot of libraries in certain domains not available, with the same maturity, in other programming languages. For example, in the cryptocurrency space there are good libraries (e.g. Ethereum web3 support) but when you try to use similar ones in Python they don't have the same level of support.

And when you use Java you can actually access even more libraries that do not exist in JS world. Including Ethereum web3 support. It even has a much more stable runtime. Why did you choose JS again?

You can check by yourself that the web3j doesn't have the same capabilities of the official web3 version: https://github.com/web3j/web3j/wiki/Roadmap I am not arguing against Java, just saying that there are tons of libraries written for Node not available in other programming languages. Another example is the BitPay infrastructure.

Re: Ask HN: Why isn't F# more popular?

#85
post #58
post #48

I spent a bunch of time using F#, and it is good, but C# is a seriously good language and the advantages of F# kind of turned out to be minimal, and most annoyingly, not well supported by the tooling. On the F# slack channel I asked what was the compelling reason for F#, why isn't it more popular, and basically there wasn't one. There's some stand out language syntax like computation expressions. The community is rea…

I think this nails it. C# is a really good language. F# has some advantages, some disadvantages, but there's not much clamor for something better in the dotnet world. Java and Objective-C are far behind as languages, so the motivations for Scala, Clojure, Kotlin, Swift were far greater.

I've always wondered if you ported F# to the JVM if it would suddenly become much more popular.

Re: Ask HN: Why isn't F# more popular?

#86
post #4

I think it's two things. If you write a lot of F# then if anyone leaves you need to replace them and it's harder than finding a C# developer. Secondly most of the libraries you interop with are C# and so you have to go through interop which is more annoying.

What's surprising is that Scala/Java basically has the same issues, but Scala seems to be more popular due to early adoption by several industry actors (Twitter IIRC).

I think the strength of the C# language vs. Java is a factor in this.

Re: Ask HN: Why isn't F# more popular?

#87
post #30

Is there a practical use case (deep learning, cloning Uber, trading, bitcoin mining, healthtech etc.) where F# or a F# framework is significantly better than what's out there?

I prefer F# as my day-to-day, but I can understand why, for day-to-day challenges, a lot of devs might look at some language features and say "C# has something that's pretty similar." However, use-cases that can be solved elegantly by pattern-matching, type providers, and/or computation expressions are areas where the "C# is good enough" argument is harder to make.

One set of use-cases where pattern-matching are particularly valuable is parsing and other times when you're deconstructing / transforming a complex structure.

One use-case for a type provider would be, say, taking an XML schema and exposing its structure as a compile-time constraint.

One set of use-cases where computation expressions are valuable relate to (oh god I don't want to use the "M"-word) the creation of a small DSL that isolates some type of specialized computation on a parameterized type. For instance, the (built-in) `async` computation expression.

Those might sound like fairly esoteric use-cases, but they're really not that uncommon if you do DSL / library development.

Re: Ask HN: Why isn't F# more popular?

#88
post #55

I worked with it and while its technically a probably a good language it's nowhere near as easy to get shit done with it as C#.

I disagree with this. As someone with over a decade of C# experience and a few years F# experience, I'm more productive in the latter. However it did take about two years to get to that point, and the productivity difference is only marginal. So if you account for the ramp-up time, this is probably true.

I'm no believer in silver bullets, but I wonder about "the productivity difference is only marginal." For one thing, I think being an F# dev is likely to improve one's OOP code (immutability by default, smaller methods), so while I agree that it might feel like one is similarly productive, I think one changes one's baseline.

For another, I think it really boils down to maintainability. Elsewhere in this thread, there is a comment that "return to your code in 6 months and it's incomprehensible." As a guy who worked with a large Scala codebase, I totally "get" that, but the thing with "functional code you haven't seen in 6 months" is: It's either incomprehensible or it's MUCH easier to reason about than stateful OOP code. And the "incomprehensible" stuff tends to fall into a couple different categories (lifting and conversion, complex function composition, etc.) that gets at least a _little_ better once you've hit your head against them a few times.

Re: Ask HN: Why isn't F# more popular?

#89
post #80
post #57

Earlier quoted context omitted.

Data wrangling is a really clear case. I do a tonne of this and it's so much easier in FP.

Why is data wrangling easier in FP? Is it because of functional composition being like using Unix pipelines (inside the same program)? But one can do that in a procedural language that has functions too.

Yes, functional composition in part. And while pretty-much-everyone has first-class functions now, they're usually not _quite_ as easy to declare and use as they are in F# (e.g., if you have to specify `Func> Foo` rather than `let Foo s1 s2 = ... `

Another data-wrangling thing easier in F# (not FP in general) is type-providers.

Re: Ask HN: Why isn't F# more popular?

#90
post #89
post #80

Earlier quoted context omitted.

Why is data wrangling easier in FP? Is it because of functional composition being like using Unix pipelines (inside the same program)? But one can do that in a procedural language that has functions too.

Yes, functional composition in part. And while pretty-much-everyone has first-class functions now, they're usually not _quite_ as easy to declare and use as they are in F# (e.g., if you have to specify `Func > Foo` rather than `let Foo s1 s2 = ... ` Another data-wrangling thing easier in F# (not FP in general) is type-providers.

Thanks.
Post reply on HN