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

71–80 of 333 posts

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

#71

Post by pbiggar »

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

Tasks are native and I've never had the use async. Performance is great.

Agree that exceptions are frustrating that they exist, sadly there's little option due to C# exception model. Same thing in OCaml though less excuse over there.

I basically use C# libraries directly, and it hasn't been annoying at all.

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

#72

Post by throwaway2037 »

lostmsu wrote: post #49
Semaphor wrote: post #34

Earlier quoted context omitted.

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

Rust might take its place if the tooling would be on par. Personally I'd jump.

You are the first person I have heard mention the desire to transition from C# to Rust. Usually, it is C++ to Rust, or Java to C#.

    if the tooling would be on par
I am betting person, and I say: "It never will be." It is easy to overlook the importance of better developer tooling. It directly translates into higher developer productivity. Every time I am forced to use a language with worse developer tooling, I am reminded of this performance hit. This is why Microsoft spends so much time and efforts on its developer tools. Also: Better tooling means below average developers can level-up to average. This is most of corporate computing, so a win for the bean counters.

Also: There is not single, commercial, controlling force behind Rust, like Java and DotNet.

Don't interpret this post as anything against Rust. I think it is a brilliant language.

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

#73

Post by ericsink »

runevault wrote: post #26
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.

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.

I too miss discriminated unions in C#.

But even more often, I find myself wishing C# blocks were expressions.

In F#, I could do this:

  let x =
      let z = whatever
      ...
      value
and z is inside a local scope.

So in C#, I want to do:

  var x =
  {
      var z = whatever;
      ...
      value
  };
Maybe it's just me.

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

#74

Post by d--b »

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.

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

#75

Post by raverbashing »

bloaf wrote: post #56
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…

Ergonomics matter

F# always came across as very weird in the syntax area

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

#76

Post by chlorion »

xupybd wrote: post #41
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…

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

Don't be sad. This is definitely a skewed perspective from a single person which makes it worse than useless as a way to gauge a random persons competence.

I'm sure you could find a person who would claim this same exact thing for any language if you searched around a bit.

To derive a useful conclusion you would need to control for all of the factors involved in the interviews and objectively measure their performance compared to other people's, anything less than that is completely useless at best.

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

#77

Post by Hasnep »

throwaway2037 wrote: post #67
waffletower wrote: post #60

Earlier quoted context omitted.

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, w…

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use.

I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small tasks where you're working with lots of types, when using a static language most of your code will be type definitions, so a dynamic language will let you focus on writing the transformation code.

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

#78

Post by xupybd »

throwaway2037 wrote: post #66
AdeptusAquinas wrote: post #64

Earlier quoted context omitted.

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?

You could have out of order function declarations.

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

#79

Post by waffletower »

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.

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

#80

Post by bmitc »

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

Post reply on HN