Computation expression and type provider are awesome features, and the language itself is really fun and easy to write/refactor/understand (this mean code work as expected at first run usually) and help you write correct code
And being sold as library only language on Visual Studio tooling, but I when I look around the enterprise environments I work on, I do get the point why Microsoft tries to push it that way.
> I find myself spending a lot less time writing code and a lot more time thinking.
That's exactly what I have found to be true as well. I spend practically all of my coding time implementing things rather than trying things. That has spilled over into my use of C#, JS and Python too.
I'm hoping I can slowly introduce F# at work, until one day, a few years later we look at all our code and realize it's mostly F#.
More and more places that use C# are opening up to using F# where it makes sense. So any time you see C# in a job description that sounds interesting it's worth asking about F#.
As someone who is wanting to learn a functional language, it seems to me that F# is a good place to start. I've heard people disparage the lack of HKTs, but some of the other features like Type Providers seem too compelling to pass up.
I've just really started using F#, but the first time I used the Type Providers in FSharp.Data, I was blown away. That and F# interactive make prototyping a REST API client something I can do in minutes.
It's a perfectly good language and a sensible choice if you need the .net interop. But if you just want to learn a functional language, Haskell or Scala provide much the same features and also have HKT support.
If anybody is interested in F#, look for a nearby meetup group to join. The SF F# group is pretty active and Mathias Brandewinder's hacker dojos are absolutely awesome!
OCaml can compile to native. That makes it faster than F# running in a VM. OCaml can compile to bytecode as well. Also, if you ever need interfacing with C/CPP, OCaml is better suited (faster) to the task than, say, Ruby or JVM based languages.
Apart from that, multithreading in OCaml is a bit like on its on Python, IIRC, with GIL taking the sting out of it. But I am sure the researchers in France and elsewhere would bring true multithreading / multicore support to OCaml sooner rather than later.
There is a multicore runtime in the works, with an ETA of "when it's done". That said, you have a couple of full-featured monadic concurrency libraries (Lwt and Async).
It also has functors (they let you parametrize a module over other modules), which F# doesn't, and you can do AST rewriting at compile-time via PPX (don't know if F# has anything like that). On the other hand, F# has access to the .NET ecosystem (which is admittedly larger than the OCaml one, though it suffers from enterprisitis), and has some nice goodies like type providers.
FYI, my Hopac library (https://github.com/Hopac/Hopac) is also a full-featured monadic concurrency library, inspired by Concurrent ML, for F# that is optimized for parallel programming.
Excellent. F# is fully supported by ASP.MVC / WebApi and there are a number of F# specific frameworks/components available.
There are two "Javascript transpilers" available, WebSharper and FunScript, both capable of compiling a large subset of F# to JavaScript. WebSharper offers a very attractive "server mode" as well. And the new - soon to be released - version 3.0 of WebSharper makes that into a very large subset and supports features like source maps as well.
What do you mean by "ripoff"? F# is not OCaml, but it indeed is closely related. They share some syntax and basic language features like tail call optimization, records and variants or pattern matching. On the other hand F# object system is completely different from OCaml's as it needs to work with other .NET languages. F# introduces active patterns and operator overloading which is absent from OCaml. OCaml features a very sophisticated module system, which in turn is absent from F#.
In short, F# and OCaml are similar but distinct languages. Both are interesting and worth looking into, each in its own right.
Computation expression and type provider are awesome features, and the language itself is really fun and easy to write/refactor/understand (this mean code work as expected at first run usually) and help you write correct code
an good "why f#' http://fsharpforfunandprofit.com/why-use-fsharp/
More info
- user groups list http://c4fsharp.net/groups.html
- browser http://www.tryfsharp.org/
- more info fsharp.org
- open source http://github.com/Microsoft/visualfsharp (vs stuff) or http://github.com/fsharp/fsharp (cross plat)