Hacker News new | past | comments | ask | show | jobs | submit login

"No matter if you are already a functional developer from a different community (Haskell, Clojure, Scala, etc.) or you are a complete newbie to functional programming (like I was 3 years ago) I think F# can equally impress you" -> "For this task and for the rest of this blog post I'll be comparing F# with C# in order to show some of the benefits."

F# is neat, and I see why it's useful if you have a big .NET program already, but for anyone else I don't see why I'd pick it over a more mature (and less Microsoft-centric) functional language like OCaml, SML, or Erlang.

Does F# have any unique features that other functional languages lack, or is .NET integration its killer feature?




.NET integration is probably the biggest killer feature, because that unlocks official support for most important platforms that you'll need to use. Using AWS or Azure or GCP because your business is moving stuff to a butt provider? You have access to fully-supported SDKs maintained by teams who do that stuff for a living. And so on. .NET also has a spectacular standard library, and with .NET Core, runs _very_ well in any environemnt.

But from a language standpoint, here are three unique features

* Type Providers, which let you generate types based on a data source, and tie compilation to the use of that data being correct

* Active Patterns, which are similar to Haskell's View Patterns, and let you tie some arbitrary functionality that ultimately returns an Option into a pattern for neat pattern matching

* Computation Expressions, which let you express, compose, sequence, etc. monadic and monoidal computations in a convenient syntax that's super easy for newcomers to grok. There is also an RFC and WIP implementation that expands these to support applicative constructs

There's more (Units of Measure, universal quantification via Interfaces, etc.) but these three tend to be something people like a lot.


Thanks, I completely missed to talk about type providers, active patterns and unit of measure, but then the post was already so long lol. I think I'll add other good blog posts which cover all these topics to my final notes!


As others have said, F# interesting language features are computation expressions, active patterns, units and type-providers. The library, platforms and ecosystem benefits are gravy. Though subjective, the syntax is clean too, being somewhere between an ML and Python.

Something that no one has mentioned yet is that F# is now among the fastest functional first programming languages. At least according to (take with a grain of salt) benchmarks like [1] and https://www.techempower.com/benchmarks/

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


As someone said on HN a while ago: F# works better on Linux than OCaml does on Windows. I recently was trying to decide which new language to learn, and reduced the choices to F# and OCaml. The catch? I need something that works on both Windows and Linux. I first attempted OCaml, and gave up soon after starting. I could tell that fighting Windows would be a constant battle. So I went with F#.

And then of course, parallel computation is an issue with OCaml.

SML: Kind of lacks libraries. I did learn some SML in the past and loved it, but I want a language that will let me be about as productive as Python is. SML lacks a strong ecosystem.


Dotnet core on Linux and macOS has been a good experience for me so far.


F# features that are unique or not present in all other functional langs:

* multi-threading (vs Ocaml) * type providers (perhaps totally unique) * units of measure * active patterns * computation expressions


The .Net ecosystem is definitely a killer feature. Everything you want, and it 'just works', as well as everything being seamlessly integrated with each other. This is only possible with the backing of a huge amount of funding, and there are probably millions of man hours spent on it at this point.


Why is the .NET integration a feature rather than an antifeature? Don't null and subclassing tend to poke holes in F#'s type system's ability to detect mistakes? And would it not be better to compile to native code than to require the Mono VM or whatnot?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: