One observation from watching Go and Rust gain popularity is that having an online code evaluation tool like https://play.rust-lang.org/ or https://play.golang.org/ can do wonders for adoption. People can experiment in a sandbox without having to hop into a development environment, and peers have an easier time debugging by easily sharing and reproducing problems.
For anyone interested in trying out F# online, looks like Microsoft Research has such a tool: http://www.tryfsharp.org/Create. Unfortunately looks like you have to create an account of some sort to share scripts, so these alternatives might be better:
Hmmm... when I click on the Horses link, I see its 3 notebooks, with a blue clone & run button. When clicked, I get prompted to sign in (requires any msft account like outlook, xbox, hotmail, ...). Once you sign in (or create an account), you'll end up in Docker/Jupyter instance with the 3 notebooks. Clicking on the first one and doing a Run All, should give you:
What happens when you click the Intro to F# sample on the front page? It should render the notebook and if you clone, it should prompt to sign in as above. Hope this helps.
When I choose to connect to an existing notebook nothing happens. When I choose to clone I get to the login screen by clicking the login button does nothing :|
EDIT: I'm now able to login. It brought up a little redirect modal after entering my user name which due to my typing was apparently getting canceled. The notebook load, but I get now chart.Plot output.
I haven't used jupyter notebooks much. They seem cool, but not as cool as light tabels insta-repl.
One of the things Go does right is the download-hello-world-compile-run experience. Especially now, since they now default GOPATH. One of the things that Go does wrong for popularity is the opinionated directory structure based environment mechanism. It has some advantages for large programming projects, but the way it runs counter to many programmer's expectations is seen by many as a wat!?
If Go had some way of mitigating that and the lack of generics, then the Hello World experience would be better for more people. (For admittedly shallow reasons, IMHO. I think that Go is pretty good the way it is. I haven't yet felt a need for generics yet in my MMO project.)
> If Go had some way of mitigating that and the lack of generics, then the Hello World experience would be better for more people.
Does the lack of generics really impact the experience of "Hello World"? I don't think I've ever seen generics used in a "Hello World" example even in languages that have them.
Whenever I evaluate a language past the hello world stage, I try to do something more complex. Which is where the generics come in.
Imagine for a second that I may want a hashmap with a custom key/hash function (most often it would actually be a set) for my own datatype. I can't just use the built in hashmap _language construct_ (the hashmap is it's own, very special type), I either have to write a hashmap implementation myself or wrap a hashmap in it's own type and have custom getters and setters which would extract a key from my custom type that is intended to be stored in the map. It might be more go to do said things, but then it just means that it's more go to write code that is more likely to be buggy.
I definitely agree with you that I prefer having generics to not having them and would consider that in my evaluation of a language; I just found it strange that a random reference to the lack of generics was dropped in the middle of an otherwise cohesive description of the pros and cons of the "hello world" experience.
No, but if you believe the ramblings of the standard HN commenter who complains about Go, very soon afterwards the lack of generics has driven them to gnashing teeth and rending hair.
I tried tryfs.net, but the Hello World sample doesn't work in Chrome: uBlock Origin blocks some scripts, but even after disabling uBlock it still doesn't render anything to the output area, it just flashes.
My issue with the online editors is that it restricts your ability to access files, add dependencies and modify your local machine. If anyone would like an online version I'd be interested to hear why?
You might also want to look at Pex4Fun which has a bunch of little coding challenges (you'll need to select F# if it isn't already). Hit 'Ask Pex' to get going.
Author of the article here. Happy to see this up on HN!
The article is actually more of an annotated version of the F# Tutorial Script[0] which ships inside Visual Studio 2017 (also in other version of Visual Studio, but the Tutorial script is a bit different there).
You can get started with F# just about everywhere everywhere:
* Visual Studio[1]
* Visual Studio for Mac[2]
* Visual Studio Code (via Ionide plugins)[3]
* .NET Core and the .NET CLI (`dotnet new console -lang F#`)[4]
* Azure Notebooks (Jupyter in the browser via Azure) [5]
Just a reminder: Scott Wlaschin's book, F# for fun is a great free resource for people interested in F#. It's available here: https://fsharpforfunandprofit.com/
If you have a short attention span, I recently started posting sped up screencasts on twitter that range between 1-2 minutes. https://twitter.com/FSharpCasts
If there's a feature you want to see, let me know. I take requests.
The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries - these .NET libraries are not nice functional libraries and don't encourage you to think functionally. Eventually I felt like everything I wrote was wrong and I just gave up on it.
F# can be a nice language even if you don't care for the functional paradigm.
Discriminated Unions and pattern mactching still come in handy, the syntax is still less verbose, there is less biolerplate/ceremony than in C# where everything has to be in a class.
it is easier to pass a function to a function than in C#
inlining functions is easier
the type inference can be useful in various ways.
if/then/else statements being expressions is extremely nice.
I tend to code in a mostly imperative style, even in F#. I understand it better, it usually performs better.
Sounds like the same issue I had with Clojure and Scala. As soon as you touch anything Java or mutable, it's like WTF?
Come to the Elixir/Erlang camp; our functional turtles go all the way down! The only jarring thing is having to write to a mutable database. They even borrowed the |> operator! And it has great pattern matching of course.
Yeah, Elixir or Haskell is probably the way I'll wind up going if I want to pursue functional programming again. I can do the basics enough to handle LINQ well and stuff, so I'm getting away without a strong knowledge for now.
One of the biggest disappointments in software development to me though is that practically all of the cool libraries these days are hitting the javascript ecosystem rather than those of all the interesting languages.
So if you want to interact with these great libraries, you have to tolerate a pretty shitty language with annoying tooling at best. So when I want to do something practical, I wind up going that way disappointingly often.
I definitely agree. Trying to jump into F# without any knowledge of .NET just requires so much mind-juggling. As a beginner, so much of the difficulty and frustration comes from the fact that you are missing so much foundation knowledge that you don't know what to ask or look for, and may not even recognize the answer. Interop won't look or behave or be optimized how you expect and will just wreak havoc with your attempts to build a mental model of what you're learning because of the strange inconsistency.
Sometimes the answer is just so obvious to people who have that foundation knowledge that no one else has bothered to ask on reddit/stackoverflow and you are googling into the wind. Sometimes the only thing you can find is several years old and giving advice that's no longer correct. I'm not sure which is worse.
I had the same trouble trying to build a learning project in Clojure. I remember when starting, I had only used pip and apt-get (and not knowing them well), I didn't even recognize Leiningen as a package manager. It worked so differently from what I thought I needed (and billed itself as a "project automation and configuration tool") that I didn't even recognize it was the solution to my problem.
It's just so easy to take for granted how many things are obvious to us that make solving problems in our comfort zone easy for us and paralyzing for another person, and I think this bias finds its way into the documentation and mindset of entire communities. This makes it harder and harder for something to be approachable if you don't fit in that same box. I'd love to love F#, (I read F# for fun and profit and worked through the F# Koans, but haven't made anything), but I'm not sure if I'll ever get over the hump unless I find myself working somewhere that's already using it. My feelings on Python are somewhere between ambivalent and bitter by now, but the work gets done, I know what to expect, and I never feel lost.
What would really help me, I think:
- More "idiomatic" wrapper libraries around .NET libraries, even if they're slower or have less features/customization.
- Pure F# libraries of typical utilities or ports of popular libraries in other languages, even if they are slower or have less features/customization.
- Content about F# project management from the perspective of someone who uses Python. This is how you do it in Python, this is how you do it in F#, this is why, these are the pros, these are the cons, these are just different because that's the way it is.
I can't upvote your comment enough. Learning F# w/o .NET and Clojure without JVM knowledge is next to impossible. There is no good doc despite what people say (and I own several books in this space). Scott W's F# articles are great for foundational FP, but neither that, any of the F# books, or any of the online tutorials show me how to do even simple things like iterate through a file. I'd love to see "Basic Office Programming in F#".
For what it is worth, the Microsoft docs are getting easier to navigate. https://docs.microsoft.com/en-us/ They are currently putting a lot of effort into docs. It's got to be hard to learn .NET from zero. Try figuring out which namespaces are the most common and start browsing the docs.
I really disagree with Microsoft's approach of homogenizing their products, and this is a perfect example.
- There's never a need for "Microsoft" documentation -- you'll have a question with a specific product or service. They really should be distinctive visually.
- This is on the microsoft domain and top left click goes to microsoft.com, but you can't get back here from microsoft.com
- By the time I click through to something (for example, .NET->F#->Get Started), I have not one but two major navbars and footer featuring prominent links and menus completely orthogonal to what I'm viewing. There is nearly zero typographical variation among the content I've expressed interest in (F#), and tons of variation for this separate content. This is distracting.
I've never had that problem with AWS and their docs are EXTENSIVE and homogeneous.
Honestly, I've always found the .NET(C#) docs pretty good even going into naming conventions and design patterns. However I'm open to improvement as they were looking a bit dated and I often had trouble ending up in docs for older versions of software/OS's.
What problems did you run into with Clojure? I haven't missed JVM/Java experience. The Clojure standard library provides nearly everything and third party Clojure libraries wrap Java libs. Off the top of my head, the only Java thing normal code sometimes references is numerics, so you might glimpse Long/MAX_VALUE or Math/sqrt.
A lot of things require you to specify the Java namespace like the "swing" demo. Iterating through a folder was similar. There are several Clojure books explaining FP concepts, but not much in the realm of here is how you do basic task "x". This isn't perfect in any language, but I've never had trouble with Perl, Python, C#, Java, Fortran...etc.
It's very hard to do it along the way if you aren't familiar with C# either. Now you're struggling to get your head around both paradigms as well as however the thing you're trying to do works.
I doubt I would have ever stuck with Clojure longer than a day, for example, if it wasn't for this library. It's not very long and all the functions are very short, but it meant that everything I needed from the file system was a 30s peek at the documentation and exactly what I expected rather than ~30+ minutes futzing with Java and forgetting what I was doing in the process https://github.com/Raynes/fs
> It's very hard to do it along the way if you aren't familiar with C# either.
Which I keep overlooking with so many years of C#, I'm so sorry about that :(
That being said, looking at the .NET framework documentation and hanging out on fsharp.org's slack might be a good way to make up for what you are missing to get started.
If I ever get up the nerve to give it a real try, I will certainly test the slack's patience for stupid questions :)
The .NET reference is useful if you are reading through code and maybe to modify it slightly, but I find it (and class hierarchy style docs in general) to be close to useless if you are writing new code and new to the library. Using a new library in Python (especially one that's heavily object oriented), I often find it easier to learn from tests instead of the docs. Reference docs are often inaccurate or too verbose or show no sense of importance or are just poorly written. Tests are straight to the point, include examples, and tend to focus on the most important parts of the library.
The MSDN docs have quite a bit of "How do I..." content, but unfortunately F# is seemingly always blank as an example.
Combine this with a huge proportion of commonly used third party libraries being .NET rather than F# libraries, and so much of the .NET infrastructure you need to use being C# focused, and as a newcomer you are paralyzed.
If F# is serious about building a community of more than just C# converts, they need to recognize that the convenience of .NET for people who already know it carries a commensurate tax for everyone who doesn't. It's harder for me to learn .NET as an F# user than a C# user. It's harder for me to learn to use NuGet as an F# user than a C# user. It's harder for me to learn to use Visual Studio as an IDE with F# than C#. In everyone of these scenarios, you're running up hill because examples and documentation and interfaces are all for the majority, which you won't be.
These are some excellent points. There's no organised, searchable F# package index. We rely heavily on NuGet, which is a generalised .Net mishmash. And we suffer from the same problems that almost every other non-dominant language does when targeting a runtime dominated by another language.
The best I can offer you right now for F#-specific packages is http://fsharp.org/community/projects/ --and the advice that, if you have questions, ask away! F# people will be, I think, extremely ready to answer any questions because we're desperate to see people use the language. Try the mailing list ( https://groups.google.com/forum/#!forum/fsharp-opensource ), https://fsharp.reddit.com/ and the Functional Programming Slack at fpchat.com (well, this one will be back online in a few days--they recently had some drama, which they settled, but they had to disable new signups to let everyone cool down).
If they're desperate, please tell someone to write a book for noobs. I opened The Book of F# and recoiled in horror. The whole book was basically if you're a C# expert, here is how F# is different...or at least a lot of it.
Sorry, you picked the wrong book to start with. Its blurb page says: 'If you're a traditional .NET developer used to C# and Visual Basic, discovering F# will be a revelation that will change how you code.... Break free of that old school of programming.'
Try Pickering & Eason's Beginning F# 4.0; its intro has a 'Who Is This Book For?' section, which says: 'This book is aimed primarily at IT professionals.... A working knowledge of the .NET framework ... would be nice, but it's not necessary.'
Just putting it out there for the next person who sees this :-)
F# 4.0 is not really out of date. The language is fairly fixed now--apart from fixing buggy behaviour actually.
Part of it is that the general ML syntax is pretty timeless--all ML books share this advantage. As for F# specifically, all the headline functionality--type providers, quotations etc.--has been there for a while. I expect books covering 4.0 to be remarkably future-proof.
I had the same feeling with Clojure. I'm not sure it's due to not having a strong functional background; I think it might be the reality of interop between very different languages.
Definitely. Understanding Clojure/Java interop to consume a library requires that you understand both Clojure and Java far more than you would need to if you were to consume a library native to whatever you were using.
Can you give an example? I think F# has nice functional replacements for most of the nasty (mutable) bits of the .NET Framework, such as List, Set, Dictionary, etc. Most of the other areas of .NET work just fine with F# in my experience.
So I learned F# and C# in parallel. But more emphasis on F# than on C#, and so when I landed my first dev job on C# I was so incredibly baffled at the code base. I would toss my arms up in shock at the sight of reference types or classes being passed around and updated from external methods. The horror! How could somebody do this.
Anyway, now I have come to learn it is just another way of doing things but my C# programming style is heavily influenced by a more functional style. I never realised till I actually landed a job where I had to interact with more standard OOP principles.
I wish there was a way I could do more F# at my work.
I learned C# (and OOP in general) first, and then made the switch to F# (and FP in general). F# does a great job combining the two paradigms, IMHO, and is a pleasure to work with. I hope I never have to go back to C# (although they keep adding new FP features to it in every release, so it's not as bad as it used to be).
I know it's already been mentioned, but I just wanted to endorse https://fsharpforfunandprofit.com/ again - you could not ask for a better teacher than Scott Wlaschin if you want to learn F#.
It's a great resource for F#. If you also want to get really strong in functional programming fundamentals I highly recommend taking Prof. Dan Grossman's free online course https://www.coursera.org/learn/programming-languages/ --he's a great teacher and the subject matter is great for all levels of experience.
How was your experience with F# and game development?
I like F#'s syntax so much more than C#(plus some stuff like pattern matching are so nice). However I feel like FP isn't effective for gamedev.
> However I feel like FP isn't effective for gamedev.
Oddly, in my limited experience, it is very effective.
I can't say it's the right pattern for every game but for the current roguelike I've been working on in my spare time it's been the best thing since sliced bread. I use the Reader and State Transformer monads in a pattern similar to the Elm Architecture that results in my engine being completely deterministic.
This allows me to dump all of the initial state of the game and all of the serialized inputs to it. I can then take that dump and step through that entire game session. This is great for debugging with friends and stuff: when they encounter an error or something they don't like they can just send me the dump file and I can replay their entire session. It's been pretty cool being able to do that.
Another thing I didn't understand at first was that immutability seemed like an egregious waste of resources. It might still be for some applications but it has much better performance characteristics than my intuition had led me to believe... because structural sharing. You can have this big blob of state that looks like it's being copied every where but it's not -- under the hood you're actually sharing 99% of the previous state and not copying anything.
It's not likely you're going to be writing a bleeding-edge rendering engine in a pure FP language on any current generation hardware platforms but you can get quite far with it.
The biggest gains I saw had to do with the units of measure and state management, with a big emphasis on the latter.
Nearly none of the traditional game-based OOP design patterns map cleanly into F# (or any functional lang for that matter) - I often had to get creative but the results were very interesting.
Take an OOP based game for an example; tracking where your game state is, how it's being mutated, and figuring out exactly what entities have been mutated can be a nightmare. With F# I ended up with a single large data structure to store the game state, and because of F#'s pedantic immutability, it's very easy to find where that game state is modified.
The only issue with the scheme above is that there are some cases where you NEED to store game state as a variable captured by a closure. That might sound really awful, but in practice variables captured by a closure are always read-only, so unless you're replacing that closure, you don't have to worry about some weird mutability sneaking up on you.
You can do imperative and object-oriented programming with F# :-) Here's an example with a Windows Forms button which modifies a string variable on click:
let mutable greeting = ""
let btn_say_hi = new Button(Text = "Say Hi", Parent = frm_main)
btn_say_hi.Click.Add(fun _ -> greeting <- "Hi!")
Curious about this also. Last time I took a peek at F# I wanted to make a simple game, but all the compatible tools seemed like C# tools that allegedly work for F# as well. Wound up using Lua/LOVE instead.
That actually looks really indispensable when you're working with units! I wonder if functional langs without this feature might be able to implement it via macros somehow which only run at build time...
I think you can do it in most reasonable statically-typed languages, with a little care. Scala makes automatic conversions a bit easier because it lets users specify them. Like C# actually. You could probably do UoM in C# too.
the developer experience isn't great, it's complicated to install and to get started with and the ecosystem related to web development is quite poor. That's not the case for F# and I really really hope it picks up steam. ML languages are really great when it comes to data modelling, domain driven design, writing algorithms and stuff like that. they are a nice compromise between pure FP and OOP.
I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.
There are some nice tools as well: merlin, utop, and friends.
As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.
I think both languages are quite nice honestly. F# has become a lot more attractive now that .NET is more readily available on more platforms. I hope it gains more steam too!
> I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.
With Javascript all that bullshit is optional, it's not with Ocaml. The JS asset pipeline is totally irrelevant here, and certainly not a good example of how an ecosystem should be.
> But you get over it.
no you really don't, and you shouldn't.
> As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.
Now Compare with .NET ecosysem . I was looking for a good MongoDB driver in Ocaml the other day, didn't any good one.
It's going to be hard for any language to compete with the .NET ecosystem due to the hundreds of millions of dollars of funding it gets from industry compared to OCaml.
There's still room for both and they're still both great languages. That F# is quite similar to OCaml is a good thing... it means there must be some good ideas in there. :)
With BuckleScript available now, you always have the option to reuse any existing JavaScript libraries with some simple bindings. You can even deploy to node.
I don't know if there's such a thing (maybe I should write one myself, as I plan to learn F# :) ), but a cheat sheet that is a bit higher level would be useful.
Can you go straight to this book or do you need to get a certain comfort level with f# first? I have the latest edition for F# 4 but haven't read it yet, plan to as part of my learning the language but haven't figured out order.
I certainly looked at the cheat sheets, played around a lot, read lots of online tutorials. Only once I had a basic understanding did I read Don's Expert F#, its great, but not for beginners.
That's a great idea. If you set up a github or wiki, I'd be happy to help out and fill in areas. If you want to get more people to help, market the cheat sheet as "The Right Way".
There's no better way to invite help from strangers. :)
I wonder, what are the pluses of F# that missing in more mature and widely adopted OCaml? Why to create a clone of good language? With porting opam to Windows platform [1], along with improving the Unicode support [2] in it I'd say it has a bigger potential in this field.
What's the quick start for using F# on the Mac? Can I get a good native development environment? Am I better off running a Windows VM to get better tooling?
I'm very curious about F# on Mac. I tried it once but it seems disjointed: Ionide requires Mono but I was wanting to use dotnet Core. They didn't seem to agree on what libraries were actually available and I would see red squiggles in the IDE while the code actually compiled.
What's the difference between VSCode and Visual Studio for Mac, for developing F#? What's the reason that you find yourself using both? I thought it would be preferable to just have one IDE.
VS for Mac is a full-on IDE, is significantly larger, and comes with lots of stuff to build a variety of apps.
VSCode is a text editor that, combined with the Ionide plugins, gives you a great lightweight IDE-like experience. It requires a bit more setup, but it's great if you prefer a more lightweight experience but still want a bunch of great features.
I use both depending on what I'm doing or what I feel like using. Typically I'll use VSCode for smaller projects or one-off F# scripts, but you can use it for just about anything. Ionide itself is actually built using Ionide, so that's a great example of using it for something bigger.
I can't speak to Visual Studio for Mac, but the Ionide plugin for VSCode is very impressive. VSCode will fire up faster than Visual Studio for windows and use less resources, ionide has some features Visual Studio does not. There are pros and cons, some people hate Visual Studio, some people prefer it. I prefer Visual Studio but Ionide is not bad when I'm in Linux.
Visual Studio on Windows is good for F#, though it kind of needs the power tools plugin for F# to make it better. It's definitely not as awesome as the C# experience is, but still better than most!
Visual Code, this seems a highly preferred option, and a lot of Fsharpers seem to use it, even on windows. The learning curve is a bit higher as it's not an out of the box experience. The trend is to combine it with FAKE, Packet and .NET Core (which I'm finding hard to keep track of).
I'm using VS for windows for F# product development at the moment.
On my Mac I use both visual studio for Mac for just mucking about, and visual code to play around with the toolsets the trendy kids keep advocating.
Note that in VS2017, many of the Visual F# Power Tools features are in-box and use the same UI that C# and Visual Basic do. The folks behind the VFPT have been porting a lot of that code over and making many improvements along the way. There will be even more features and improvements in future VS 2017 updates, as well!
I'm really looking forward to VS2017 update 1. I've been following the activity in the visualfsharp github repo and some of the new Roslyn based tooling looks fantastic (albeit with alot of churn at the moment).
F# has always had good tooling 'for a functional language' but it looks like we're getting close to good tooling period.
I know that it's not entierely related to the post, but is there a specific job board for F# jobs? I tried the language a bit and really liked it but it seems to be rarely used in a professional setting, which is a shame... I'd be interested to know where I could potentially find a job where I could use F#!
I realize that .NET is F#'s biggest strength from the perspective that Microsoft probably holds of trying to push C# more functional, and trying to attract talent from R, Ocaml, Rust, Julia, Haskell, etc, but it also feels like its biggest weakness.
I'd love to see some sort of bootstrapped version that makes use of .NET Native or CoreRT or whatever they use today, and I'd REALLY like to see a strong Stdlib for F# that takes into account what functional programmers are used to.
I've been doing functional programming for several years, and I feel like a moron working with F# because I don't know half of these dumb .NET classes and some of the domain problems don't really leave me able to budget enough time to bootstrap my own solutions OR learn all the .NET stuff I need. Especially not when I can jump into several other languages and have a working prototype often in days or hours.
Edit: just before somebody starts whining about it, I ain't got no problems with NET on its own, but the barrier to proficiency in it from a functional universe is needlessly high, and if F# had a stronger core it would be something non NET programmers could pick up along the way rather than continuously bash their heads into while doing rather menial work.
I don't want to sound whiny either but it's such a punch in the gut when someone sees me struggling with basic FP stuff in F#, just because I guess I'm so proud of what I've learned about FP in other languages.
There's also some stuff that F# is missing, but it hasn't screwed me yet because I still haven't figured out enough about all the NET classes.
What is needed is new blood among F# users, not coming from C# background and not too snob about F# not having most advanced type system when compared to Haskell or other similar ML languages.
Then, effort on making functionally orientated base libraries (without relying on baking those things in FSharp.Core, but as set of small libraries) wrapping undelrying .NET APIs, taking inspiration from what is there in Haskell and other similar languages.
Most F# users today are fine relying on mostly .NET libraries + fresher F# libraries, but most projects will be done with a mix of paradigms (which is manageable in F#) which is not most appealing to people with significant FP background.
I agree mostly but I'd argue that most F# devs are coming from c# to begin with. I'd love to see some data suggesting otherwise, but I have a very strong feeling that its true. I also like multi paradigm, doesn't take away from F# at all, but it's something that doesn't mix well with developers not familiar with the NETverse
well i mean there's all this stuff i vaguely see about .NET Core not being as good as the offering on windows but that eventually it will be? i don't know C# but i'm interested. i guess i'm just wondering if i should make the leap to starting to learn it even though i develop solely on linux.
F# works well on Mono, well enough to start learning/developing on until .NET Core gets to real production-grade status on Linux. (I've only toyed with .NET Core on Mac/Linux - it worked well enough for some simple stuff - but haven't tried to run any heavy apps on it yet.)
It works very well, it's partly about microsoft ditching a lot of dependency on windows and giving open source developers what they have had for a while with ruby/python/java (think gem packages, ability to run build tasks etc easily via a command line interface) etc.
I recently converted an asp.net web app to dotnet core and was able to run it via nginx to the in built kestrel web server the only problem I had was connecting to an MS SQL server named instance.
For anyone interested in trying out F# online, looks like Microsoft Research has such a tool: http://www.tryfsharp.org/Create. Unfortunately looks like you have to create an account of some sort to share scripts, so these alternatives might be better:
https://repl.it/languages/fsharp
http://tryfs.net/