The blog of the F# team at Microsoft
The Visual Studio F# team is excited to announce a preview release of F# 3.0 as part of the Visual Studio 11 Developer Preview, announced on Tuesday at the //build/ conference. This preview is available now for all MSDN subscribers.
The general release will be Friday at 10am PDT. The F# compiler will continue to be available as an independent installation, but that configuration is not part of this preview release.
With F#, we bring you a powerful, succinct, efficient, and expressive language, which allows you to write simple code to solve complex problems. F# is a productivity accelerator—it is used by a growing community to solve analytical programming problems in a variety of domains, such as trading, finance, bio-informatics, blog analysis, advertising, and energy markets. To learn more about F#, visit the F# Developer Center.
With F# 3.0, we are maintaining and expanding this vision through the addition of F# Information Rich Programming, consisting of F# LINQ Queries, the F# Type Provider mechanism, and a set of built-in type providers for enterprise and web data standards.
Further information on using F# across various platforms can be found at fsharp.org.
F# Information Rich Programming is a response to the massive trend—seen in almost every area of programming—toward greater availability of data, services, and information. There is an explosive rise of big data in the technology, science, social networking, and economic spheres. There is deluge of data in the modern enterprise. And, web-connected devices give consumers a rich experience of data and services. F# Information Rich Programming creates an information processing framework that can consume not just data—but also its associated metadata. This lays the foundation for simplifying programming in our information-rich world.
The F# Type Provider mechanism allows you to seamlessly incorporate, in a strongly typed manner, data and services from external sources. A type provider is a component that presents your program with new types and methods which are usually based on the schemas of external information sources. For example, an F# type provider for SQL will supply types and methods that allow programmers to work directly with the tables of any SQL database. These types and methods may depend on parameters that are specified in code or configuration files. This lets you integrate external information spaces directly into your program.
F# LINQ queries bring to F# the established power of query-based programming against SQL, OData, and other structured or relational data sources. See the MSDN documentation and samples for more information.
Now it is easier than ever to access many important data sources—including enterprise, web, and cloud—using a set of built-in type providers for SQL databases and web data protocols. These providers make it easier, simpler, more uniform, and more intuitive to access both SQL databases and protocols such as OData and WSDL. With a mere three lines of code, you can access and query any SQL database—the significance of which will not be lost on enterprise developers. Plus, this is strongly-typed and has IntelliSense support!
How is this done? Rather than directly adding SQL support to the language, we have created an extensible, simple, and uniform mechanism that can be applied to many other data sources.
The Type Provider mechanism makes F# an extensible and adaptable data-rich language. A type provider is a powerful extension point to the F# language and tooling: now any F# programmer (including, of course, the Visual Studio F# team!) can integrate a wide range of information spaces and emerging industry data standards. Over time, we expect to see a number of new type provider projects—be they samples, community projects, internal enterprise utilities, or products—which each configure F# for use in a particular domain. So, not only would you have a near-seamless programming experience using SQL, OData and WSDL sources (to name a few), but anyone could create type providers that work against NoSQL data, semantic web data stores, social network graphs, scientific data repositories, data markets, SharePoint, WMI, streaming data, and high-performance cloud data stores.
Along the way, we have not forgotten attention to detail. For example, F# Type Providers can also work with F# Units of Measure. This gives you a unique and powerful synergy: rich and precise unit typing can be propagated into the language from SQL and web databases. We have also made small additions to the language, such as auto-properties. We’ve added query support and SI units to the F# core library. And, we’ve kept an eye on practicality and scale: F# Type Providers can scale to enormous spaces of types and methods through the optional use of erased representations for provided types. This is particularly important for representing entities and classifications in a very large database or in linked graphs.
We are also improving the language tooling in Visual Studio. This includes better IntelliSense, improved quick info, unused variable warnings, and Solution Explorer support. Plus, we benefit from general IDE enhancements in Visual Studio, such as an improved “find” dialog, simplified toolbars, preview tabs, and better document management. Runtime Improvements
Our .NET partner team is making foundational improvements in .NET 4.5, an in-place update over previous versions. Some exciting features include a background server garbage collector, large object heap allocation improvements, and support for balancing heap allocations across multiple processors. Additionally, Async task support provides a uniform model of asynchronous programming and improves parallel computing performance.
While F# is frequently used for components in client-side systems, F#’s most natural strengths are as a front-office and server-side language. For this developer preview, our team’s focus has been to support a new world of data-rich programming. Over the coming months (particularly in the Beta timeframe), we will be talking more about Windows 8 and F#, though this is not a focus of this preview release.
For those using the preview release, we look forward to your feedback! For those waiting on more general releases, we encourage you to check out some of our videos, our new set of F# samples, and some of our new MSDN documentation. Please continue to engage with F# community groups and forums to help understand, explain and propagate what we have to offer.
With F# 3.0, our foundational principle remains in place: simple code to solve complex problems. This now includes information-rich programming to support our information-rich world. With F# 2.0, we brought you the best language for solving computationally-complex problems. We are now proud to be bringing you the best language for solving data-complex problems. :)
The F# Team
This looks like an amazingly feature rich release. Congrats to the F# team.
Please use Nemerle instead. It is more powerful and more open
Can the connection string be runtime-calculated? (loaded from a config, decrypted, selected by user etc)
Congratulations, looking forward to trying out the new features.
Congrats !!! As far as tooling in this new version, do we still need to organize files within the project? Does it have folder support?
@Vadim: I think you don't need to replace the connection string on runtime, since the types are already compiled. You just need to somehow change the connectionstring of the instances of the generated types.
Have there been any changes or improvements to debugging?
Downloading it now! I'm excited to see the new capabilities.
I tried this in the preview and - Yes, you can supply a runtime connection aswell but you still need a static schema so the compiler knows what to do. The runtime schema and compile time schema must match.
I don't understand...how is an "F# Type Provider" different from any other IQueryable data source?
@David: it looks like Keith responded here (blogs.msdn.com/.../developing-f-type-providers-with-the-f-3-0-developer-preview-an-introductory-guide-and-samples.aspx). Sorry to make you ask the question twice! :)
What no support for WinRT and Metro-style apps!?
Why is F# always lagging behind on the GUI? This really crushes the F# adoption in our company. We'll have to go back and rewrite our code in C#...
Yes, please work on the GUI stuff.