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:
Hey Philip, great post - really informative. Especially happy to see that the nightly releases are coming along considering the pace of improvements by the likes of Vasily and all the rest.
I do have a small question about the Visual F# team at Microsoft. Are there any plans to grow the team at all? It seems that the company deems F# as a second class .Net language, preferring VB.Net/C# when it comes to contributions from employees and IDE features. Given the popularity of F# in surveys such as the recent annual Stack Overflow developers survey, is there any interest at the company to put more manpower to F# development?
P.S. I hope to see you around at the F# Exchange in London next month if I go.
By sitting the F# language service atop Roslyn Workspaces, F# in Visual Studio is in a far better place infrastructure-wise than it has ever been. Roslyn Workspaces are the lower-level piece that nearly every bit of .NET IDE work is done in.
A great example of how that enables F# in other areas is how the idea of support for the Roslyn Project System[0] went from a complete unknown to a reality. The work needed to support F# in various areas went down by orders of magnitude as a result of this work.
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.
> Is F# a good alternative to C# for writing purely object-oriented code?
Yes! F# is perfectly suitable for OO code, and supports all the same features that C# and VB do, plus Object Expressions, which are a really cool way to implement an interface in an ad-hoc way.
Lots of folks in the F# community would encourage you to adopt a functional pattern (as I would as well), but since so much mindshare in the world is currently surrounding object orientation, I think it's great to use F# for OO code and slowly start to sneak in functional patterns. F# is a very "clean" language in that regard.
> 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.
Hmmmm. You should be able to build F# 4.1 projects in VS 2017 without an internet connection, but it currently does take a dependency on System.ValueTuple to support struct tuples. This is a point-in-time problem that C# shares as well, because System.ValueTuple is not in the .NET Framework yet. It will be in a future .NET Framework release. This shouldn't limit you, though - you can still do anything in-box, just without using struct tuples.
Naturally, anything involving NuGet packages will be off-limits in your case. So that does cut you off from some of the awesome community packages out there. Have you considered hosting an internal NuGet feed with a package cache so that you're not limited in this way? A lot of companies do this.
> 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.
This sounds like a horrible environment to work in. If you don't trust your developers to make those kind of decisions for themselves then what are you even paying them for? That gives them no ability to exercise their skills and I would not expect any good developer to stay long in such a place.
Frankly it suggests a level of brokenness in your process that I've always found unfixable. I'd advise finding a better job.
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.
> 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.
> It's probably possible to convince me that the limitation on circular references is actually a feature
Have that in Haskell as well. As the community largely views FP as "type-driven development" and Haskell as a "typeful language", it isn't uncommon to have a single module just for listing all the Algebraic Data Types (not their "methods" though, that's more an OOP concept anyway). Having all ADTs at a glance has its own benefits in terms of "high-level overview" etc too of course.
But of course the question was about OOP so you're right calling this a "caveat" in that respect.
It's not supported by the underlying .NET object model, so no .NET language can handle it without reinventing the wheel in a way that's incompatible with the rest of them. Since cross-language interop is one of the bigger benefits of OO in .NET, no-one really bothers.
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.)
Not sure about the contrast, I looked at F# after Haskell exposure and "it seems fairly similar to me". Sure you have some minimal notion of some OOP constructs so as to be able to do the .net interop where necessary/beneficial, but other than that, I remember looking at it and thinking "oh cool, in .NET there's something with a lot (more than enough) in common with Haskell, good to know on the off-chance I might land a .net rewrite gig (or win app dev gig) where I get to have a say about language choice but not platform choice"
Go and Rust aren't "following the wrong path" IMHO but are great tools fit for purposes other than the ones Haskell or F# can excel at. The former are great for high-speed crunching, OS/network interops and transformations of massive volumes of say byte (more so than richly parsable text) formats, state machines, simple SIMD parallelism (where locks/mutexes etc aren't a major concern).. whereas the FPs excel at richer expressiveness for business domain models, workflow rule engines, of course also (and certainly even related) (e)DSLs and parsing / AST transformations+rewrites, propositions etc
JAHO (just another humble opinion). In the end they're all turing-complete so you "can" use any for anything
I'm also generally a fan of multi-paradigm languages (such as OCaml, Scala, and F#), as pure languages often run into the problem (somewhat simplified) that they handle 80% of all problems well, 10% adequately, and 10% poorly.
At the same time, I'm extremely skeptical of naming any single language the "programming language of the future". Application domains are simply too diverse for their problems to be solved adequately by any single language. On top of that, different people seem to think very differently: some have an easier time with a predominantly functional style, others get more mileage out of object-oriented programming (which again is completely alien to others) and so forth.
If there's one thing that I'm fairly certain of is that there's no such thing as a one-size-fits-all solution in the realm of programming languages and environments.
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.
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).
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.
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.
When writing high perf F#, I wished for ownership capabilities to rely less on the GC and really get some speed. While Rust is a bit verbose, doesn't have custom operators, can't do pointfree, etc. -- it's not a bad FP language. And all the while, I get to think of how fast the code is, so that's often worth it. Rust does FP better than C# has done.
Well, that's my point. Rc<T>/Arc<T> essentially mean: "I can't figure out ownership here; let's use automatic memory management instead". The thing is that this is pervasive in ML (even simple functions like List.rev – functionally reversing a list – are a problem), so you end up having Rc<T>/Arc<T> all over the place. The underlying problem is that pure functions from data structures to data structures create multiple ownership naturally.
Remember that this is about the claim that "Rust is very much ML". It really isn't. It's a totally different programming paradigm. That's not bad. Rust does some things very well that ML has a hard time with. But it's not the same.
Rust is not ML but takes a lot of ideas from ML and functional languages, such as options, pattern matching, traits and "type classes" ...
Go is just bad feature wise for a language born after 2005. It's a good language for managers that don't trust their developers with their intelligence though, and will lead to a generation of developers who can only code in Go, because using anything else is "too complicated"...
> Go is just bad feature wise for a language born after 2005. It's a good language for managers that don't trust their developers with their intelligence though, and will lead to a generation of developers who can only code in Go, because using anything else is "too complicated"...
I've argued that some minor updates to SML with actors/csp and a couple more primitive datatypes (esp unicode strings) would result in a language that is both easier and far more powerful than go.
And the same can be said for elm on the web dev world. It's a nice compromise between haskell and friendliness, allowing a greater adoption. In the not-so-long future, Elm will be able to take advantage of web assembly and ditch javascript (almost) completely.
By no means imperative languages will disappear, but I too share the opinion the future is bright for f#, elm, erlang etc.
WebAssembly has no way of directly interacting with the DOM. It has to use JS interopt which is quite slow. It'll take a couple years to get Wasm up to speed. It'll be a couple more years to add the rest of the low-level interfaces and even more time to deliberate about a GC spec (you don't want to ship apps with entire language environments attached). It'll be a couple more years to deliberate over new DOM APIs and a couple more to implement them. After that, it'll be a half-decade or more until old browser share drops low enough to use it without needing a JS equivalent.
Are traits really an ML thing? To me, they seem more similar to Haskell's typeclasses (and by "more similar to", I mean "almost exactly the same thing as"). From my somewhat limited experience with OCaml, it seems like the closest thing it has to traits is modules/functors, which seem to work fairly differently (i.e. traits are "added" to existing types, whereas functors are used to create new types).
Having used F#, I find Rust to be much closer to following the "right path". F# may have mode some good choices initially, but it strays back and forth between intuitive and straight-up senseless regularly. It lacks most of the elegance in other MLs and lacks much of what makes C# usable with its own feature set, rather choosing to create a weird concoction of the two styles with little thought behind it.
> one being purely functional languages (Haskell, Scheme, etc.)
You can easily do imperative programming in Haskell using IO. There are even lots of straightforward bindings to C libraries, directly exposing C functions. There are IORefs and so on.
Not sure about Scheme, usually lisps are quite imperative.
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.
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!
I've been enjoying this new push into cross-platform, open source stuff by Microsoft, whereby everything is always broken, incomplete and incompatible.
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.
They really released VS 2017 without .NET Core support? That seems like a questionable decision, as hyped up as the whole .NET Core push seems to be. Unless they had a mandate to push it out in Q1.
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.
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].
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.
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/
* https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
* https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
* https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto...
* Visual Studio for Mac (comes with F#): https://www.visualstudio.com/vs/visual-studio-mac/