
F# 4.1 and Visual F# Tools for Visual Studio 2017 - dustinmoris
https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-f-4-1-and-the-visual-f-tools-for-visual-studio-2017/
======
phillipcarter
Author of the post here. Happy to answer any questions you may have!

Edit: Just to reiterate, the releases described in the blog post have an
immense amount of community sweat behind them. We're super happy about how
engaged the F# community is and proud to have such a long section dedicated to
attribution.

If you want to learn more about F# or get started, try any of the following:

* [http://fsharp.org/](http://fsharp.org/)

* [https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...](https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-visual-studio)

* [https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...](https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-vscode)

* [https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...](https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/getting-started/getting-started-command-line)

* Visual Studio for Mac (comes with F#): [https://www.visualstudio.com/vs/visual-studio-mac/](https://www.visualstudio.com/vs/visual-studio-mac/)

~~~
mee_too
Is F# a good alternative to C# for writing purely object-oriented code? For my
current project I have a very low level spec/architecture, that says class Abc
does Xyz, classes A1, A2, A3 implement a strategy pattern, etc. It's designed
with C#, VB.NET or Java in mind, but the dev team would prefer F# or Scala.

One more question. I work at a place with a very restrictive firewall. F# 3
projects worked fine, but with F# 4 the build fails to download nuget
packages. Is there a way to use the latest version without Internet
connection? I can download anything from microsoft.com, as that site is
whitelisted, but nuget.org is not.

~~~
mcbits
I haven't used F# in a while, but it seemed pretty clean for OOP with a couple
of caveats. You have to explicitly implement interfaces and do a lot of casts
to use interface members, which is ugly compared to the rest of F#. It's also
difficult (impossible?) to have circular references between types unless you
cram it all into one file.

It's probably possible to convince me that the limitation on circular
references is actually a feature, but implicit interfaces would be really nice
to have.

If I ever dive back into to F#, I think I will treat it as "procedural first
with a neat type system" and limit the use of both OO and functional features
to where they markedly improve the code.

~~~
yawaramin
> If I ever dive back into to F#, I think I will treat it as "procedural first
> with a neat type system" and limit the use of both OO and functional
> features to where they markedly improve the code.

This _may_ be a good strategy; I would urge you though to try doing top-down
design in F# using modules and interface (.fsi) files. E.g., let's design a
calculator GUI app in F# using, say, Windows Forms. Sketch out the interface
first:

    
    
        (* Calculator.fsi *)
        namespace CalculatorApp
    
        module Calculator =
          type number = Zero | One | Two | ... | Nine
          type op = Plus | Minus | ... | Sqrt
    
          (*
          Holds the app model. Note that it is mutable; the keypress operations
          return `unit`, i.e. they update the `t` value in place.
          *)
          type t
    
          val init : t
          val press_number : t -> number -> unit
          val press_op : t -> op -> unit
          val calculate : t -> double
    
          (*
          Draws the app and hooks up event handlers to the above operations.
          *)
          val render : unit -> System.Windows.Forms.Control
    

Then in the implementation file (Calculator.fs), fill in the blanks based on
the types! Of course you'll need a separate file for the main entry point, but
that's good practice anyway.

------
Koshkin
F# (and ML in general, despite having been around for a while) looks like a
programming language of the future. It occupies just the right place between
the two extremes - one being purely functional languages (Haskell, Scheme,
etc.) and the other being taken by all sorts of imperative languages (C, PL/1,
Java, etc.), which - from a certain standpoint - could all be viewed as
derivatives of the assembly language, and which, therefore, should have been
long abandoned in favor of languages worthy of the name 'language' as the
medium of human thought.

(Unfortunately, the two modern languages - Go and Rust, despite showing so
much promise, appear, from this perspective, to be following the wrong path.)

~~~
alkonaut
Rust is very much ML. It's the systems programming token salad that makes it
look like C++, but if you squint you can see it looks a lot like ML. As does
swift.

~~~
rbehrends
I honestly can't see that. Functional programming and ownership are concepts
that just don't mix well. Just think about OCaml's Set module (which uses
balanced trees with partial sharing of subtrees as the result of set
operations, if you look at the implementation).

~~~
pjmlp
> Functional programming and ownership are concepts that just don't mix well.

Of course they do, ownership is part of substructural type systems, more
precisely affine types.

~~~
rbehrends
The particular problem I was getting at was that the structural sharing
required by purely functional data structures is not a natural or easy task
when you're restricted by affine or linear types.

Several idiomatic functional programming techniques are similarly difficult to
express with the additional invariants of affine types.

~~~
pjmlp
Yet there are quite a few programming languages considered functional with
substructural type systems.

Being easy or hard is not what defines FP.

~~~
rbehrends
Well, that was in the context of the claim that "Rust is very much ML". We
weren't talking about (say) BitC here.

I've got nearly two decades worth of ML code lying around (mostly OCaml, some
SML and F#) and for most of it rewriting it in Rust would require significant
redesign for the reasons I mentioned. This starts with even very simple things
like List.rev.

~~~
pjmlp
> We weren't talking about (say) BitC here.

No, we are talking in the context of ATS, LinearML, Idris, Mercury, F* and a
few others.

------
Rapzid
Alpha .net core support :( I'm excited things are moving forward, but I wonder
how much of the slowness around this is due to the coupling of F# releases
with the release cadence of Visual Studio/Visual F# Tools.

Hopefully ionide will support dotnet core soon now, and we can get a fully
cross-platform development experience with VSCode and .Net Core.

~~~
phillipcarter
Sorry for the confusion, but F# isn't in alpha for .NET Core support. From the
post:

 _Specifically, the following are in RC:_

\- _FSharp.Core as a .NET Standard NuGet package_

\- _The F# compiler running on .NET Core as a .NET Core console application_

\- _F# support in the .NET CLI and the .NET Core SDK_

 _However, the following are not supported at this time, but will be supported
in a future Visual Studio 2017 update:_

\- _F# support for .NET Core Visual Studio tooling_

\- _F# Interactive (FSI) running on .NET Core as a .NET Core console
application_

------
GiorgioG
Sadly VS2017 doesn't support .NET Core F# projects. Come on Microsoft!

~~~
jarnonijboer
F# supports .NET Core projects. VS2017 however doesn't support the new MSBuild
syntax which is used for new .NET Core projects. Fortunately this is the goal
for the next VS2017 update and the F# community and the MS VF# team, are
working hard to get this working.

Instead of complaining we, as a community, should be helping the VF# team and
contributors with there efforts!

~~~
thom
I've been enjoying this new push into cross-platform, open source stuff by
Microsoft, whereby everything is always broken, incomplete and incompatible.

~~~
jarnonijboer
Are you talking about F# with .NET Core or .NET Core/Standard in general? If
you talk about the latter, I agree with you, that this has been a shit show.
However MS is aware of this and Scott Hanselman has complained several times
about versioning and other stuff, during the ASP.Net standups, in regarding of
(ASP).NET Core in general. I believe that MS is trying their best and since
all the open source stuff is new for them as an organization, this an area
they are exploring and hopefully learning from there mistakes.

------
nbevans
Is there any news on when .NET Native's stupid AOT compiler (i.e. UWP store
apps) will support F#? It is becoming scandalous now. We have a circa 800k LOC
F# Xamarin codebase working on iOS and Android but cannot spin up the UWP
variant for this reason.

------
lilactown
Is there a good, cross-platform UI framework for F#?

~~~
phillipcarter
This may not be _quite_ the direct answer you expect, but yes there are
multiple ways to create cross-platform UIs with F#:

1\. Xamarin[0]. It supports F# for everything aside from UWP targets.

2\. WinForms on Mono[1].

3\. FABLE[2] to compile your F# into JavaScript. It's a _very_ good tool and
it produces really nice JavaScript as well. From there, you can run the code
on the web, Electron, or React Native[3].

[0]: [https://developer.xamarin.com/guides/cross-
platform/fsharp/f...](https://developer.xamarin.com/guides/cross-
platform/fsharp/fsharp_support_overview/)

[1]: [http://www.mono-project.com/docs/gui/winforms/](http://www.mono-
project.com/docs/gui/winforms/)

[2]: [http://fable.io/](http://fable.io/)

[3]: [https://github.com/fable-compiler/fable-react](https://github.com/fable-
compiler/fable-react)

~~~
cm2187
I am struggling to understand why xamarin supports F# but not VB...

~~~
nickpeterson
I believe it has more to do with the founder being an F# enthusiast and less
to do with marketshare or suitability.

------
hacker_9
Great to hear the move to Roslyn is complete! Last time I used F# I was
suprised at the lack of IDE features compared to C#, so I look forward to
trying out the improved experience.

~~~
jarnonijboer
VF# now uses the Roslyn Workspaces, however the migration to the new Roslyn
ProjectSystem is just started ;)

