I used to be a big Haskell programmer. While I still love the language, I've really come around to the idea that strictly evaluated functional languages like F# or OCaml are the best for programming in. You get the nice functional features but don't have the straightjacket of laziness forcing you into certain design decisions. It's really nice sometimes to be able to mix in impure, side effectful code without having to thread it through a monad. The OCaml family feels like a nice blend of good sound functional features with enough escape hatches to be productive in real world programs that might occasionally need arrays or mutable state or IO. Laziness by default also makes things like debugging or reasoning about performance frustratingly difficult. I do miss Haskell's typeclasses in these languages, though. My ideal language is basically Ocaml/F# but with Haskell's syntax and typeclasses.
Years ago I was working a miserable job writing boilerplate template code where I had to sub in variables based on certain conditions, it was using a very bland language to look up data from our database and format the output. I wasn't allowed to download any software onto my work computer despite having a technical background.<p>So what I did instead to make my life easier was write F# to create a kind of DSL and create the template lookup scripts for me. I did it all from the browser with repl.it, and I generated dozens of scripts and saved myself a lot of time in the process.<p>Now I mostly use Racket, but F# is where I kind of started out. It's a fun dialect.
F# is a joy to use. After a certain time, many C# developers find themselves writing in a functional style. F# makes this the default, but lets you continue using all of your existing code.<p>Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net Core is now a powerful alternative to Node.js.
Been using F# on personal projects and C# at work. I noticed my C# coding gone high quality once I got into functional thinking. It is highly recommended for anyone to check/learn F#. F# is my goto lang. now to competitive programming too. I believe F# and ML will make a great combo, but python is still leading.
Unlike most commentors my experience with F# hasn't been stellar.
I feel the language itself is well designed and the community is great but there is just so much of it.<p>Any source code that i try to go through is sprinkled with so many new keywords, so many different way of combining stuff, that there seems to be so many syntactical stuff going on. It is really making me struggle.<p>It just feels like a language where the maintainers are going overboard with. And I am sure that once I understand it, I would love it, but the path to get there is so hard.<p>Pretty much no tutorials or articles are out there and reading sources for small projects is not viable for me either due to the keyword noise and too many ways to do something.<p>I did not feel anything like this when I taught myself python, ES6, lua, Crystal etc. F# just feels too big.
The problem is F# doesn't get enough resources internally at Microsoft. How many times has VS shipped missing the latest version of F# tools? In terms of community, it's tiny. If I want to do functional programming, F#/.NET isn't the strongest option. I have several books on F# and as much as I'd like to learn/use it beyond toying around, I can't help but feel like all it's worth using for is tinkering (outside of the few shops that use F# extensively.)
Here’s a Tour of F# by Microsoft:<p><a href="https://docs.microsoft.com/en-us/dotnet/fsharp/tour" rel="nofollow">https://docs.microsoft.com/en-us/dotnet/fsharp/tour</a>
I just bought Scott's book on Railway Oriented Domain Driven Design. So far so good. I am the domain expert though, so no revelation there.<p>The modeling of state machines using types and functions is pretty revolutionary to me for where I'm currently at development skill wise. Everything just seems so clean and elegant.
While there's nothing you can do in C# that cannot be done in F#, the reverse is not true. The biggest thing that comes to mind is to influence the direction of the other language (C#). I've heard it said many times that if you want to see what features will be in C# in the future, look at F#. Too many features to cite (though Linq is the biggest that comes to mind) were in production use in F# long before they arrived in C#.
<i>> Anything C# can do...</i><p>Yes, yes, you <i>can</i> do anything in F#, but what <i>should</i> you do?<p>My opinion is that that what F# is missing is a good set of idioms and a strongly opinionated set of guidelines. To my beginner's eyes, every F# codebase I've seen feels like it's written in a completely different language; it's like the opposite of Python's "one right way to do everything".<p>I've heard that F# is great for domain-specific languages, but in most cases a DSL is the cardinal opposite of what I want. I want a <i>common</i> language that I can use to express a multitude of different concepts. It seems like all of the guidance out there about F# is about showing off features, being extremely clever, or using F# to teach functional concepts, not actually about <i>writing useful applications</i>.
I started F# lately and found it absolutely amazing. I come from heavy C# programming, and always find myself reaching out to have sane default like immutable types.<p>But unfortunately there are still lot of libraries out there for F# which don't support .net core fully. Especially db access ones.
... and exhaustive matching: <a href="https://github.com/mcintyre321/OneOf" rel="nofollow">https://github.com/mcintyre321/OneOf</a><p>I'm not saying it's as good as writing F#, or that C# shouldn't include these features of course.
If you want to try F#, here's the full F# compiler in the browser run using WebAssembly. Very fun to play with: <a href="https://tryfsharp.fsbolero.io/" rel="nofollow">https://tryfsharp.fsbolero.io/</a>
I think several interesting points were brought up in this thread regarding the assumption of functional aspects presented in F# by C#. LINQ being the most popular example. I am currently lead to believe that a purely functional application development domain is potentially an overreach of theory in terms of building things that can interact with the real world in very complex and 'functionally-leaky' ways.<p>My biased perspective as someone who hasn't really used F# very much is this: Perhaps an imperative language such as C# 8.0, with a few high-value functional features sprinkled in, is actually the best of both worlds when viewed through the lens of someone who has to interface with really weird business systems. I use imperative techniques for handling remote calls, exception handling, etc. Then, when I need to work with my internal business logic or models, I can use more functional techniques.<p>Based on my own understanding and other comments presented here, C# does not seem to preclude the usage of functional approaches to solving problems if you have the discipline and experience to do so. C# also brings with it a host of other benefits in terms of tooling support and simply being able to find other developers who can understand your codebase.
For all the love Microsoft has been getting these days, I still don’t get how I’m supposed to write C# or F# without Visual Studio and Windows. Am I missing something? VSCode doesn’t support these languages, right? I’m a person who spent a long time trying to write Java in Vim, but switched to IntelliJ and wouldn’t want to write C#/F# without some comparable IDE.
One line data types <a href="https://github.com/mcintyre321/ValueOf" rel="nofollow">https://github.com/mcintyre321/ValueOf</a>
It's a pity the tooling is comparatively immature, with F# (or at least that was my experience last time I tried to develop with it). I think Rider is getting there, though.<p>To go into more detail, the initial implementation in Rider was limited to not much more than syntax highlighting. Inspections were fairly limited, ASP.NET MVC integration was not as featureful.<p>On the C# side, it's much more developed and refined. Within Rider, it's obviously been the main focus so I suppose it's only natural it's received more polish.