Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

51–60 of 333 posts

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

#51

Post by lostmsu »

keithnz wrote: 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.

I found both Linq expressions and F# computation expressions to be limited (as in: subsets of corresponding languages exclude too much) for the few purposes I tried them on.

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

#52

Post by xupybd »

keithnz wrote: 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.

Yes you get abandonware but in other fast moving language you get so out of date that you might as well have been abandoned. Unless you're spending a lot of time upgrading.

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

#53

Post by xupybd »

slfjw____ wrote: post #14

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

> not rich in community libraries, like a desert & abandonware

You have access to the entire .net ecosystem?

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

#54

Post by WalterBright »

gemstones wrote: post #3

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…

> They prefer the safety of the herd

I.e. social proof

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

#55

Post by lostmsu »

slfjw____ wrote: post #14

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

* the complexity of the compiler makes it hard to make it better

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

#56

Post by bloaf »

gemstones wrote: post #3

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

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

#57

Post by phamilton »

muglug wrote: post #32

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

> not that many people are rewriting Ruby programs in Rust

Just an anecdote (and definitely not "many") but one thing we've found is that ruby and rust actually fit fairly well together. The way I express something in Ruby (often FP stuff like `map` and `filter`) translates very well in Rust. Much better than it translates into (as an example) golang.

Beyond expression, the tooling in rust (cargo) feels very familiar and intuitive. Ruby -> Rust in that regard has felt much more natural than Ruby -> JVM/golang/C++.

Don't get me wrong, it's not a trivial jump, but I've been pleasantly surprised by much of the developer experience.

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

#58

Post by ideasman42 »

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".

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

#59

Post by ta-run »

local_crmdgeon wrote: post #35
muglug wrote: post #32

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

Agreed. Tweaks: I don't think C++ is going to be relevant for much longer, Rust solves the problem space better. Python ... maybe? It's so different than the rest, I can see it going the way of Ruby once AI bindings improve in other languages. I can also see Julia dominating the AI space. The "better than X" languages though? C#, F#, Scala? Done. I don't even hear about Kotlin that much anymore, Java is starting to a…

There's also MojoLang[0] that brands itself as a alternative to Python, and Google will look to release Carbon soon as well. It'll be interesting to see how these two grow.

There's also Odin[1] that looks promising.

I don't think C# is going anywhere, F# on the other hand :shrug: is at the mercy of MS - they always seem to be on the fence about it.

[0] - https://www.modular.com/mojo

[1] - http://odin-lang.org/

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

#60

Post by waffletower »

JoeyJoJoJr wrote: post #43
cjbgkagh wrote: post #31

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…

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.
Post reply on HN