HN Theater @HNTheaterMonth

⬐ m0skit0

Any hints on why would anyone choose F# over the multitude of functional languages out there? (This is not a sarcasm, I'm actually looking for real answers :))

⬐ kvb

It depends on what you're looking for, of course. There are certainly a few unique features that are very nice (e.g. type providers, units of measure, etc.). Compared to Scala, there's much better type inference and more of an emphasis on the functional as opposed to object-oriented side, though both languages support both paradigms (and Scala supports things like higher-kinded types which F# lacks). Compared to other ML-family languages, F# has broader access to libraries thanks to its very nice .NET interoperability (but much weaker support for true ML-style modules). F#'s tooling is also much better than that of most functional languages (especially on Windows via Visual Studio, but people seem very happy with the tooling on Linux with Mono, too).

But personally the thing I most like about F# is the community.

⬐ tel

Firstly, he works at Microsoft Research in Cambridge. Secondly, he's using MSR's Z3 SMT solver which maybe has really nice F# bindings. Thirdly, he suggests somewhere toward the end that he finds Visual Studio + F# nicer than Emacs + OCaml for doing exploratory programming, though he doesn't exactly explain it at all.

⬐ lucian1900

To me, it's an ML with good access to useful libraries and that can easily be distributed on any OS.

⬐ Matthias247

I'm currently new to this too and just doing some smaller experiments with F# but reasons for me would be:

  - Powerful tooling with IDE, Debugger, Packet Managers, Build system
  - Access to the whole .NET ecosystem
  - Powerful concurrency and parallelism constructs
  - relatively easy to reason about. If you don't know how to build something functionally you can still build things in a C#-like way because mutability and strict evaluation is there.
  - I like the very concise and yet good to understand syntax. The type interference is great.

⬐ Rickasaurus

The biggest reason is .NET and all of the nice tooling that come along for the ride. Profilers, remote debugging with breakpoints on other machines, recording program state over execution, cross compilation to phones for free, a rich ecosystem of libraries, etc.

There are other good reasons though. Modern day F# is (except for a very small number of type resolution foibles) 100% backwards compatible to the first release. This is a huge problem for Haskell in business. Also, Type Providers are totally awesome for scripting over structured data.

⬐ mightybyte

I would consider F# if interoperability with the .NET ecosystem was important for my task. Otherwise I would probably pick Haskell.

⬐ enricosada

Why use f#? see http://fsharpforfunandprofit.com/why-use-fsharp/ (concise for programmers) or http://fpbridge.co.uk/why-fsharp.html (more high level) more info about fsharp at http://fsharp.org/

my take:

#ecosystem

- vibrant and friendly community

- open source (long time ago, use pr, wrote by community)

- cross plat (linux/mac/win/ios/android)

- is .NET, same standard library as C# or VB.NET and virtual machine (CLR). Finally open source

- use nuget components written for .net

#language

- fun to use

- concise, i can easy write code without boilerplate

- easy async, parallel, gpu

- easy interop with c#, native

- fast

- multi-paradigm (functional first, but can do oop like c#)

- help write correct code (no null reference => no null reference exception, pattern matching,

- unit of measure (like 1<m/s> )

and a lot, read the links above for a better (and faster) summary

⬐ marxama

> no null reference => no null reference exception

This is only true in the same sense that there are no NRE in C# as long as you don't use reference types. F# seems to be a fine language, and its non-nullable types are certainly a good thing, but you have to handle null references in F# just like in C#.

⬐ Rickasaurus

This is kind of misleading. F# classes/records/unions cannot be given null values by default. Null only ever rears its ugly head when you're working with C#/VB.NET/C++CLI APIs.

In practice you catch these out at the boundaries and have nice clean null-free F# code.

⬐ marxama

Every so often, I use strings in my code. F# gives me no compile time checks against null references when I'm dealing with strings, nor any other reference type. I did mention that the constructs F# provide are not nullable, which is nice, but that doesn't mean that F# is NRE free. As I said, F# is a nice language, but the "no null reference exceptions" claim, if anything, is misleading.

(I'm not very experienced with F# and would be thrilled to be shown that I'm incorrect!)

⬐ m0skit0

I don't understand the cross-platform part, isn't F# .Net? Then how is it cross-platform? Also open source, that's nice, but what's the license? Also Microsoft is not very friendly to open source, why would I trust them to keep it this way?

⬐ enricosada

FSharp was one of the first open source microsoft projects year ago

about license: https://github.com/Microsoft/visualfsharp/blob/master/Licens... -> http://www.apache.org/licenses/LICENSE-2.0

the open source repo https://github.com/fsharp/fsharp

is open source AND accept pull request, the development is done on github, very friendly

the .NET too is going opensource, see https://github.com/dotnet/corefx (.NET base class libraries) and https://github.com/dotnet/coreclr (.NET virtual machine) and https://github.com/dotnet/roslyn (C#/VB compiler)

⬐ jackfoxy

Mono today for Linux and Xamarin for Android, iOS, & Mac, and Core .NET http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-i... will soon be a viable choice on the other platforms, and only get better with time. There are builds of the F# language for all these platforms.