Just want to let You all that I'm an author of most stuff ( but of course we have also some cool contributors!) so if You have any questions feel free to ask them here.
This is really awesome! How are you finding Funscript? Last I tried to look at it following the tutorials to get started was not a smooth process due to being out of date. It's also, unfortunately, not a terrible active project :|
FunScript for sure is not perfect and have many rough edges - getting started as new user is hard, getting started with different type of project even as experienced user is not perfect (for example Atom plugin requires completely different approach than normal web application), it has problems with "OO" features of JS so using it with frameworks which requires such approach is bit hacky, generated code is not perfect.
But i still like it and managed to create fancy stuff with it - Ionide, React.js + Material UI applications etc. Wouldn't recommend using it on production ( unless You want to commit really hard into FunScript project and probably fix lot of this stuff) - WebSharper is providing more complete, richer solution and commercial support if needed
FunScript is in the middle of a restructuring/reorganization process[1]. Hopefully FunScript will find its legs and start moving forward sometime soon.
Intellifactory's Websharper projects are well supported and regularly updated, you could try Websharper.Warp[2] in lieu of FunScript.
What a coincidence? I installed Win 10 through bootcamp just to practice & develope a hobby project in F#. I logged in to Win 10, installed VStudio 2015, F# tools etc. & then checked HN. And found this. So Now I just shut down Win and came back to Mac to Install Atom and then Ionide.
F# has been working well enough on Mac for many years. Even if You won't like Ionide (I hope You will like it ;) ) it's worth checking different projects which allow for F# development on Mac - Xamarin Studio has very good F# support, there are also Vim, Emacs, and Sublime Text 3 plugins / modes for F# (all 3 for core F# language services features are using same backend as Ionide).
Also in context of cross platform development - there exists also F# yeoman generator which provides some nice templates for F# projects outside of VS.
Omnisharp[1] is build on top of Roslyn so as for now it supports only C# / VB. As far as I know they are working on adding plugin support for it for non-Roslyn language so maybe in the future we will have F# plugin there ( actually, as far as I know, that's MSFT plan for adding F# support in VS Code)
F# has had opensourced compiler[2] (written in F#) before it was cool in .Net stack and for most tooling things we are using FSharp.Compiler.Services[3] project - which basically provides all features of F# compiler (and much more) as normal .Net library. Projects like Visual F# Power Tools[4] and Xamarin Studio F# support[5] are using it to provide very interesting F# IDE features.
Since Vim, Emacs, Sublime and Atom (even though Ionide is written in F# and compiled to JS we can't use all .Net libraries) don't have direct access to .Net assemblies, community have created FsAutoComplete[6] project which is just command line wrapper around FSharp.Compiler.Services and works as "standard I/O server" where we send requests (for example if user wants completion list) and get appropriate responses.
> for now it supports only C# / VB
Nope, there is not any support for VB at this point in time. It's C# only I'm afraid!
As cloudroutine mentions, the older omnisharp-server implementation is NRefactory based, whilst omnisharp-roslyn (as the name implies) has been built atop roslyn.
omnisharp-roslyn retains a bit of NRefactory (the code actions part[1]), which was called NR6Pack and has now been renamed as Refactoring Essentials [2].
Anyway, there's been a lot of recent changes in the works, as someone has already mentioned, omnisharp-rolsyn currently has an open PR [3] which will provide a plugin system to omnisharp-roslyn. Once introduced, it will mean that the various omnisharp editors/clients can pick and choose which plugins they wish to bundle with their editor. This may include F#, VB, Cake, Fake and many others.
You should also install the F# Power Tools[1] if you haven't already. It has a lot of great features.
I definitely prefer Atom+Ionide when I want to try something out quickly or experiment. Opening VS and creating a new project just to write a simple fsx script seems excessive to me.
Although, most of the time I'm running them simultaneously.
I started out with OCaml too, it's a really easy transition into F#. You can basically cut and paste OCaml code into F#, unless it involves stuff like Functors, first class modules, and polymorphic variants.
Active Patterns are a pretty cool F# feature that OCaml doesn't have. You can do something that's effectively the same with OCaml macros, but those are a lot more tedious.
The F# intellisense and code completion are great productivity enhancers, especially when it comes to working with unfamiliar libraries.
My biggest hurdle in transitioning from OCaml to F# was learning my way around the .Net ecosystem, so it was still a relatively minor one.
If you decide to get into F# and have any questions about it someone on the #fsharp channel on the Functional Programming Slack[1] usually has an answer.
[1] http://fpchat.com/ <- sign up here, invites usually arrive within 24hrs
VS Code does not currently support extensions/plugins. The team has confirmed they're coming at some point[1] but we'll need to see how they set it up to determine the best approach to building an F# plugin for it.
Ionide definitely won't be compatible out the gate, but if the API isn't too different we might be able to reuse some of what we've already done.
The best case scenario would be the if plugin system supports dlls so that we could use the FSharp.Compiler.Service directly[2]
VS Code is using Omnisharp[1] which is build on top of Roslyn so as for now it supports only C# / VB. As far as I know they are working on adding plugin support for it for non-Roslyn language so maybe in the future we will have F# plugin there ( actually, as far as I know, that's MSFT plan for adding F# support in VS Code)
Since VS Code is built not on top of Atom but on top of Electron[2] both projects share just "lower level" possibilities and will both build different abstractions layers on top of it. Unless VS Code team chooses to build very similar API to Atom one direct porting won't be easy.
