Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

61–70 of 333 posts

Re: Why F# evangelism isn't working (2015)

#61
post #8

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.

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.

It's easy enough to do DUs, they are working on it, but they are just syntactic sugar for abstract class/subclass

for instance, as an example for this https://fsharpforfunandprofit.com/posts/designing-for-correc... where a C# solution is suggested and done with DUs in F#, I wrote the equivalent DU solution in C#... https://gist.github.com/keithn/ceeeed5f7eb567e1b2333747065d1...

Only thing you don't have is exhaustive checking, which I personally don't think is much of a problem pragmatically.

Re: Why F# evangelism isn't working (2015)

#63

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 pre…

Really?

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.

Re: Why F# evangelism isn't working (2015)

#64
post #56

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 pre…

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…

I wrote F# for a long time, and there were definite phases to learning and becoming comfortable with it. For example, it's often pitched as a functional language but in reality its a functional-first hybrid language on the .NET framework - to be efficient with it is to embrace this and write imperatively when you need to.

Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated feeling compared to other languages.

Re: Why F# evangelism isn't working (2015)

#65
post #8

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.

... or units of measure

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

Re: Why F# evangelism isn't working (2015)

#66
post #56

Earlier quoted context omitted.

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…

I wrote F# for a long time, and there were definite phases to learning and becoming comfortable with it. For example, it's often pitched as a functional language but in reality its a functional-first hybrid language on the .NET framework - to be efficient with it is to embrace this and write imperatively when you need to. Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated fee…

    though having a single pass compiler makes it a bit dated feeling compared to other languages
Can you please share how F# could improve with a multi-pass compiler?

Re: Why F# evangelism isn't working (2015)

#67

Earlier quoted context omitted.

I have been programming for 20 years, and yet despite having used dynamic languages I don’t actually know what it means to leverage dynamic programming techniques. For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript. I get the impression that dynamic programming, besides the odd untyped line of code, is best used only for ext…

There is much naïveté among the strongly typed herd. When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task, reaching for a strongly typed language is never the best option for code complexity and speed of development. Yet the hammer will often succeed if you hit hard enough and club the nail back to shape when you invariably bend it.

    There is much naïveté among the strongly typed herd.
Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust.

Also, the example that you gave is incredibly specific:

    When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task
Can you provide a concrete example? And what is "data engineering"? I never heard that term before this post.

Re: Why F# evangelism isn't working (2015)

#68
(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.

Re: Why F# evangelism isn't working (2015)

#69
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.

Re: Why F# evangelism isn't working (2015)

#70

Earlier quoted context omitted.

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 we…

I have been programming for 20 years, and yet despite having used dynamic languages I don’t actually know what it means to leverage dynamic programming techniques. For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript. I get the impression that dynamic programming, besides the odd untyped line of code, is best used only for ext…

The problem is the word dynamic is overloaded, and I'm not at all sure which one your parent comment meant.

"Dynamic programming" traditionally has nothing to do with dynamic languages but is instead a class of algorithms that are "dynamic" in the sense that they represent time.[0] This might be what your parent was referring to because these algorithms lend themselves well to Haskell's lazy evaluation, and they reference F# as being eager.

That said, they also talk about F# as being type safe, so they could also be referring to dynamic programming languages. The grandparent was definitely referring to this one, but "dynamic programming techniques" sounds much more like the algorithmic meaning.

[0] https://en.m.wikipedia.org/wiki/Dynamic_programming

Post reply on HN