[retendo]

I'm using .NET Core/F# for the backend of my bootstrapped "startup". I mostly have an iOS dev background so take my experiences with a grain of salt.

So far everything has gone pretty smooth. ASP.NET Core is running under the hood which seems to be pretty mature. F# and the libraries that I work with all provide a functional development experience. I interface with a Postgres database, so there's libraries for that as well.

You mentioned Domain-Driven Design. I would recommend reading Scott Wlaschins book Domain Modeling Made Functional [1].

If you are interested in playing around with F#, a quick way to start would be to try SAFE stack [2].

From what I have read during the last couple of months, MS seems to be interested in pushing F# as one of their go-to languages for machine learning. At least they have an F# example online [3], which can not be said for most other areas where F# would also be a good fit in my opinion.

[1] https://fsharpforfunandprofit.com/books/ [2] https://safe-stack.github.io [3] https://dotnet.microsoft.com/apps/machinelearning-ai/ml-dotn...

[ablekh]

Much appreciate your feedback and advice. I was considering using F# instead C# for my potential .NET-based solution. But not because of Microsoft's ML push for F# (which seems to be just a move to achieve feature parity with C# within ML.NET framework, which, by the way, is not as comprehensive as relevant Python ecosystem), but rather because of F#'s meta-programming features. However, the advantages of F# still do not overweight its IMO two main disadvantages: a much more limited (vs. C#) pool of available developers and limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products).

[retendo]

> a much more limited (vs. C#) pool of available developers

I don't plan to hire anyone in the foreseeable future but what I can say is that there's 2 people happily working on the F# codebase at the moment, that do not have any prior experience in the language (professional Swift/ObjC background and played around with other languages). Getting into it is quite easy if you're interested in FP. I wouldn't worry too much about that. Just get some people who are experienced in .NET and some people who are good in FP.

> limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products)

I use JetBrains Rider on a Mac, without major problems so far

[ablekh]

Fair enough. Thank you, will keep this in mind.

[oaiey]

Google Jetbrains Rider.

Do not worry about the pool. The limiting factor in finding good people is the good part not the programming language.

[ablekh]

Thank you for sharing your thoughts. I'm aware of JetBrains Rider. In fact, I have installed it on my desktop and used it to explore the above-mentioned .NET boilerplate templates (C#-based). Perhaps, I missed that Rider fully supports F#. Will check it out.

Re: finding good people - I certainly agree with importance of focusing on the good part. However, still ... having a significantly larger pool of developers statistically increases chances to find good ones (which is important, especially considering competition with big tech firms in hiring engineering talent).

[737maxtw]

Does it?

I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path.

For certain organizations that is exactly what they need.

[ablekh]

I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).

[Xixi]

There's another point of view: that by targeting people who either know, or are interested in learning F#, or any other less popular language (like Rust, Erlang, Julia, etc.), you massively increase the quality of your applicant pool.

Developers that just want to pay the bills learn the popular languages: Python, javascript, Java, C#, Swift, etc. Developers who plays with (or maybe find little projects to do with) the like of F# are statistically more likely to care about their craft, even if they don't necessarily have the possibility to use these at their current jobs.

If someone contact you specifically because they want to use an FP language, but they can't at their current job, it's a very good sign. Of course if you limit yourself to something like: 5 years of experience writing F# in insert field of interest here, it's going to be very tough to hire anyone...

[kqr]

But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem.

My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have".

Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want.

So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know.

What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.

[oaiey]

Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100.

There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.