BT

F# Past and Future Discussed at F# Gotham

| by Pierre-Luc Maheu Follow 4 Followers on Oct 21, 2015. Estimated reading time: 2 minutes |

On October 17th,  F# Gotham gathered experts who presented different aspects of the language and tooling such as asynchronous programming, computation expressions, optimization, FParsec and Xamarin.Forms. The presentation of David Stephens and Jay Schmelzer, respectively program manager for F# and director of program management for Visual Studio, focused less on the technical aspect and more on the bigger picture. They presented the past, present and future of F#.

Plans about what’s next for F# were discussed at length and were the bulk of the presentation. As David Stephens explained, one of the top priorities is to port F# on .NET CoreCLR. This will bring portability and modularity to the language, as it is the end goal of the .NET Core project.

One of the challenges of the development of F# is to keep up with the current developments in the .NET ecosystem, which is currently evolving at a fast pace. Furthermore, supporting the already existing technologies such as VS Code, WPF, Windows Forms, ASP.Net and Universal Windows Apps is also to be considered.

As several planned projects for F# are already implemented for C#, David and Jay were asked if the end goal was to put F# on par with C#. The answer was no, as things are moving fast and new features implemented for other languages such as C# do not necessarily have the same priority for F#. This would also mean each new release would need to support both F# and C#, which would slow down the pace too much in a competitive environment. Instead, projects will be implemented on a priority basis, based on the language usage. Community feedback will also be considered in the prioritization process.

Another question raised was if F# will support Roslyn. They started by making a clarification about what is Roslyn. Roslyn is the name of the rewrite project of the C#/VB compiler. As such, it makes no sense per se to support Roslyn. The Roslyn workspaces, however, provide an higher level API and are not tied to a specific language. Therefore, the F# support of Roslyn would actually consist of extending the F# compiler to support the Roslyn Workspace API. David and Jay then explained that this project is in the plans, but a few select ones such .NET CoreCLR have higher priority.

Throughout the presentation, importance of open source has been reiterated for Microsoft and the F# team. Contributions to the code and feedback are welcomed by the team, as they help setting priorities and provide a stronger workforce to push the language forward.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Calling it "F#" is often not clear enough by List Walker

Please refer to blogs.msdn.com/b/dsyme/archive/2015/10/23/a-let... to see Don Syme's thoughts on how to best refer to F# - Microsoft does major work in F# and tooling, but so do many many actors in the open systems community.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss
BT