kowalgta

I've worked with .net professionally for almost 20 years. At the beginning with C# while last decade almost exclusively with F#.

F# is just a better language. Simpler, more concise, more readable with stronger type safety. I will never go back to writing C# as I'm finding it too frustrating at times and unproductive.

Usage of C# packages from F# is simple and without issues. The other way is a bit more clunky, but frankly, you will not want to write any C# once you are on the F# side.

I have been programming in F# full time for the past 7 years and I hope that rumours of its death are greatly exaggerated. Perhaps this comes from a point of view that if something is not growing 10x each year is dead?

It's not a JavaScript framework that has an average lifespan of a couple of years. It's a fully featured, complete, very productive language that makes programmers life easier and more enjoyable.

As others mentioned - using smart constructor technique, but not directly as F# has no dependend type capability.

Smart constructor technique works well with 'parse, don't validate' approach [0]. You can push type construction to the boundries of your system so that you can work on a domain code with more precise types. It's not always so rosy however as too much types can become a burden.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

We use F# to build fairly complex portfolio management apps. It's a great match for F# to Javascript transpilers (Fable, WebSharper). It makes it easy to share functions and types between UI and backend and to have powerful type safety. I.e. you change your DB data type and compiler informs you where in the UI you need to make appropriate changes.

This works great with "makes illegal states unrepresentable" approach. It helps to reduce a need for boring unit tests and lets you focus more on expressing domain in code directly.