Why F#?

Our shop converted 6 years ago, from C# to exclusively F#. I also author and maintain some packages (falco, donald, validus and others). The language is tough to learn if you're coming from a C-style language. But worth the effort and experience. It's extremely concise a true delight to build programs in that are fast, robust and durable.

There are a few drawbacks, depending on your perspective:

- compilation is slower than c# and hot reload isn't supported (it's in progress)

- there are very few opportunities to use it professionally

- hiring devs can be challenging

How does the typing system work for F#?

From the article, it looks like it's mostly dynamically typed. Or is it inferred? Or is it something else?

Like, if I write

    let hello value =
      print value
    
    hello "world"
    hello 2

Does that just work?

To me, that'd be a point that might steer me away from the language. Deducible types seem vital to larger and long lived projects.

As a proficient Elm developer with industry experience, I’m wondering what are the biggest challenges in hiring devs? Is it the paradigm, learning the ecosystem, lack of interest? Are you currently hiring?

F# is a statically typed language with gradual typing and full type inference.

Given

  let hello value =
      printfn "%A" value
    
  hello "world"
  hello 2

The binding "hello" has "'a -> unit" signature where 'a is a generic argument it accepts because the "printfn" binding with a given format specifier is generalized the same way and an unconstrained 'T (here 'a) is the most narrow type inferred for "hello".

It's statically typed and inferred.

With regards to your example, the print/printfn (equivalent of Write/WriteLine) functions are a bit funny in F#. They don't actually take bound string values directly. You need to specify the type (which could be a string, a number, obj, etc)

https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...

As someone who quite likes f#: It seems like a chicken and egg problem, not many companies doing f# because not many devs know it and not many devs learning it because not many companies are doing it.

I certainly wish I were doing f# professionally, but I only ever found 1 job listing for it, and that was in vienna while I am located like 200km away from it :(

Speaking of elm: I really like elmish for the frontend, when I need to make a dynamic page in the first place. Maybe that could be to your interest? (It transpiles to react under the hood via fable, which you can webpack into a drop in bundle. But I digress)

Hiring devs is perfectly fine if you don't look for F# skills - just hire generally smart people, and allow them 1-2 weeks to get comfortable with F#. Make them just solve problems from project euler or something.

For those who have already done functional programming, they wont take more than 2 days to start getting productive. For those who have written a lot of code, it will take them ~2 weeks to pick up functional thinking.

Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

Additionally, I've never had anyone reject our job offer because we do F#. I'm sure a whole bunch of people might only be looking for python or javascript jobs, but that's fine because I'm not looking for them. I always have more people who I want to hire but I can't due to budget constraints.

Source: direct experience - I run a pure F# company with a team size of ~80.

Hi Isaac ;) Of course you can train people. But in my experience they take a lot longer to learn than you suggest.

Thanks for your work on falco, it’s a really great library.

>- there are very few opportunities to use it professionally

- hiring devs can be challenging

Those drawbacks are huge, IMO.

Jobs are kind of rare. I have to learn F# hoping maybe I will find a job in one or two years. And if I find it, they might want someone with F# work experience.

    > Anyone who is still uncomfortable with F# after 1 month - well that's a strong signal that the dev isn't a fast learner.

I think you may be reading this wrong. Agree with sibling post that even teaching folks C# -- which isn't far off of TypeScript, Java, etc. -- is never so straightforward if the individual wants a full grasp of the tool.

For myself, I feel that I have "full" command of C# as a programming language, but also how to structure projects, how to isolate modules, how to decouple code, how to set up a build system from scratch for C#, how do deploy and scale applications built with C#, what the strengths and weaknesses are, etc. My definition of "comfort" would entail a broader understanding of not just the syntax, but of the runtime ecosystem in which that code operates.

For me, my discomfort with F# is due to not knowing if what I’m doing is the correct/idiomatic way of doing things. With C# I have learned all the ways I should not do things…so it’s easier/faster to just use C#.

> with gradual typing

Isn't gradual typing widely understood to mean "gradual between static and dynamic", which F# certainly isn't?

The problem is, many recruiters don't work with this mindset. If they're hiring a Java developer, and they get a CV from someone who has 1 year of Java experience and 5 years of C# experience, they see 1 year of experience, and immediately put it on the "unqualified" pile.