Back to Questions
5.5k
views17
comments
F# - A Third-class language on the .NET Platform
f#compiler.net

Hi,

There are many things that comprise a first-class .NET language, but 3 seems crucial:

1) Core libraries and compiler part of the .NET Framework.

2) Part of the core Visual Studio offering.
3) Complete CodeDOM implementation to allow broad tooling support.

Given that F# satisfies only 1 of these 3 criteria it seems fair to say that it is not (and won't be in the near future) a first-class .NET language.

I do hope that VS2010 Beta 1 will prove me wrong!

regards,

Danny

.

Thanks for starting this debate.

(I personally use the term second class to describe the status of F#.)

It's interesting to see the wide variation in what people are talking about. For example the deployment environment and preparedness to spend time thrashing things out vary widely. (It would be useful to draw up idealised descriptions that can be used to model how different F# audiences think.)

If F# was just there, in GAC, same licence... as C# or VB.NET much of the debate would be superfluous.

I'm delighted that it is coming along and can't imagine a world in which it's not a resounding success.

I can understand Microsoft being cautious with a new language. I'm sure there's history here (I hope the decision makers really grok that history).

Having said that I'm wondering if I'll just throw away any investment I've made, in F#, for the immediate future. I want a language that is just a standard part of a .NET install on a IIS server. It's in the GAC. I don't need to install anything myself, whether PowerPack or anything else. SP's keep it up to date without fuss.

I have enough to do without getting involved altering execution environments.

I guess that means .NET next (5?) is the place where I might get what I want. Deploying this for little web services might just be too hard at present. (That's too far away to think much about, so if I make this decision F# will largely drop off my radar.)

A pity but at least the other languages are not standing still.

By on 12/21/2009 4:49 PM ()

For deployment, why does static linking not provide an attractive alternative? The --standalone or --staticlink F# compiler options will wrap your app up into one assembly as needed. Then you can deploy on any targeted framework. No change needed.

For the most part, we just include F# as part of setting up a server, along with all the other things we have to install to have a useful system. "It just works" - I can't recall any F#-specific deployment headaches. Run the F# installer, install F# apps, execute. But, I work in a small deployment, only about 10 servers running F#. I can understand in a large enterprise how any small thing can be a real pain to get installed. Hence my question of why static linking isn't acceptable.

As far as the PowerPack shipping differently than the framework, I've come to like this stance even more. It means that some bugs or missing parts in such libraries can be relatively quickly patched and upgraded. If it shipped as part of the framework, that means we'd have year+ waits even for minor updates. I also imagine this would cause more features to be dropped as they might not meet the bar for inclusion in the .NET Framework.

By on 12/27/2009 8:01 AM ()

Strange criteria. You don't have to isntall VB.net when you install Visual Studio. Does that make VB a second class language? Besides, I frequently download add-ons and service packs and whatever for Visual Stuidio, so the extra download is not that big a deal.Kurt

By on 4/12/2009 6:06 AM ()

Hi Kurt,

The criteria are motivated by my experience of using F# in a large-scale enterprise environment.

Of course a single installation on your own machine is not a problem -

it becomes an issue when you write an application that is to be

deployed to thousands of machines in a heterogeneous enterprise enviroment,

in which most users are without administrative rights. This is further

exacerbated if you wish to use the F# compiler in your application - I

believe that F# license currently makes this explicitly illegal.

That F# is to be part of VS 2010 is very important and a magnificent triumph for the F# team. It means that, within the 2010 timeframe, solutions with a dependency on F# projects with be able to be built by any developer in the organization whether or not they know anything about F#. This has given management the confidence to green-light some small F# projects.

Unfortunately the deployment story is not as good.

Currently the .NET Framework 3.5 SP1 is part of the default build in of

every machine in our corporation, and I fully expect .NET 4 to be part

of the future default build. Were F# libraries and compiler to be part

of .NET 4, in time, deployment would become trivial - as they are with

C# and VB.

As it stands authoring an application with a dependency on

the F# libraries and compiler is deemed dangerous as guaranteeing that every potential client

has the F# CTP installed is impossible.

Simply stated, upper management have and will continue to disallow F# to be used widely in an enterprise environment until it becomes a core part of the .NET Platform.

Perhaps this post is simply a plea for the F# team to reconsider including the libraries and compiler in .NET 4. Without this step, uptake in enterprise will be significantly hampered, and consequently, my working life significantly poorer.

regards,

Danny

By on 4/13/2009 1:00 PM ()

Of course a single installation on your own machine is not a problem -

it becomes an issue when you write an application that is to be

deployed to thousands of machines in a heterogeneous enterprise enviroment,

in which most users are without administrative rights. This is further

exacerbated if you wish to use the F# compiler in your application - I

believe that F# license currently makes this explicitly illegal.

Thanks for elaborating.I don't know about the illegality of including the compiler. I assume that since the goal of the F# team is to release both compiler and libraries under a shared source type license (if I'm not mistaken...) this problem should be resolved, or at least it is a temporary problem.As for your other concerns, I feel your pain. As others have pointed out, this is not so different from other products and languages. For example, we use team systems at work, and it requires two or three extra installations. Adding an extra language to our stack requires us to update all build machines, and of course all developer's machines. I agree that a single install for .NET 4, F# included, would make  transitioning a lot less painful, but on the other hand I have had similar issues when trying to use C++ for interop - it was just not installed by default (neither is VB where I work).I think once a reasonable number of people can be convinced of the usefulness of F#, this is just something that is going to have to be factored in the cost of things. I do admit where I work is more of a medium-smallish business, where I believe such a transition is certainly possible.

By on 4/13/2009 3:05 PM ()

I only have limited experience deploying Windows solutions. So, I'm interested in your concerns.

For the case where no admin rights are available, how is deploying F# redistributable in an .msi (or however you do it) with your application any different than distributing any other third party library, or a first party library?

But for you situation, it sounds like you should push for the F# libs to be in the standard install. It shouldn't be a problem to convince upper management to include yet another supported MS lib in the install right? To me, it seems like the f# should get the same auto-green-light that you assume that .NET 4 will get.

Anyway, I'm going to have to make similar arguments to these in the near future. So, I'm curious why anyone would resist. (other than standard language-I-don't-know-phobia)

By on 4/13/2009 1:45 PM ()

Hi none,

our large ecosystem of applications is managed by a (proprietatry) system that - at its core - relys on xcopy deployment of an application. The majority of the FSharp binaries are illegal to redistribute and must be installed using the official Microsoft download. I've successfully deployed a few applications, but anything with a dependency on the compiler, for instance, would be impossible.

The F# CTP has a bespoke license and it not supported by Microsoft - so it was never a possibility to be part of the default build. Though it is clear productization is going to change this - any additional license conditions will have to be scrutinized by compilance. Furthermore the most obvious conclusion to draw from its exclusion from .NET 4 Framework is that it is volatile or buggy - and thus poses operational risk.

.NET 4 will not be 'auto' green-light. It will go through months of examination and testing against the entire eocsystem of applications. It will be a great shame if the F# libraries and compiler will not be part of this process.

Nothing here is insurmountable, but having F# as part of .NET will considerable ease penetration in enterprise environments.

regards,

Danny

By on 4/13/2009 3:15 PM ()

Most of your concerns seem to be around the license, which we already know will change. But what about compiling with standalone? Sorta eliminates the problem of "what's installed", assuming you're shipping apps and not libraries.

I don't think it's fair to tie "first class" to "enterprise managers will OK it easily". I'd say "first class" is entirely a function of VS integration (i.e., ships with and is supported). C++ doesn't have the same designers as C#, but it'd be a stretch to say C++ isn't "first class".

F# shipping with .NET _could_ make deployment easier, although I don't see the big problem just shipping the DLLs or statically linking. So long it doesn't hamper the F# team from improving things, fine. But if it's going to restrict them to service "enterprise" scenarios... well, I sure hope not. Note: I'm assuming they're going to have high quality stable releases regardless of ship vehicle, and that there will be reasonable compatibility across releases.

By on 4/14/2009 9:06 PM ()

the license, which we already know will change

But what license ?

In december 2008, it was told that the next F# version will be released under Ms-Pl.

Yesterday, this latest version (1.9.6.16) was released, but still under a special version of MSR-SSLA for F#.

It is a difficult decision to invest time to learn a language and start development when we can not be sure of its future.

- Will it really released under Ms-Pl, finally ?

- If not, will the license permit the redistribution of some important binaries ? (DLLs, compiler)

On could expect MS to wait until VS 2010 is ready, and decide to

release F# as an ordinary commercial product, or not, depending on the

interest generated by it.

Which is commercially-speaking a logical decision. Isn't it ?

By on 5/22/2009 6:10 AM ()

Hi Chris,

The F# team's plan of record (i.e. the one we announced last year) is to make the source release of the compiler around the time it completes the productization process, i.e. corresponding to a supported release. This means approximately Visual Studio 2010 RTM, give or take a bit . The plan is for this to be under MS-PL.

Danny - please contact Luke Hoban (lukeh@microsoft.com) about your concerns above. I am certain that we can address your managements concerns. If you'd like us to visit and discuss with your management directly we can also arrange that.

It's possible things may change, but that is our plan.

Thanks

don

p.s. Here is tha announcement we made towards the end of last year.

... Over the next year, the plan of record of the F# team at Microsoft is to do three things:

1. Bring Microsoft's implementation of F# to product quality as a supported, runtime redistributable, with a corresponding set of Visual Studio tools. You can expect these components to be shipped in various forms: if F# is shipped as part of X, then you would expect those components to have the same license as X.

2. As we complete this over the next year, our plan is to make a corresponding source release of the F# compiler components under MS-PL.

3. Along the way, we plan to make a source release of the MSR "Power Pack" components, also under MS-PL. These include tools such as fslex.exe and fsyacc.exe and some libraries. These may be released more often and may include experimental components.

The source for the compiler and Power Pack components is in the CTP release but under a different license. Note that our next planned MS-PL source release is of the power pack components.

In general, we aim for the source code releases we make of F# to open, stable and correspond to supported releases.

I hope this clarifies our plans :-) It's possible things may change, but this is our plan of record.

P.S. On the whole we prefer to "do" rather than "pre-announce". But since we've talked about our plans to do all of the above in various forums I thought it would be helpful to bring them all together in one email :-)

By on 5/23/2009 3:14 AM ()

Hi Don,

Thank you for the answer.

> our plan is to make a corresponding source release of the F# compiler components under MS-PL.

> .. make the source release of the compiler around the time it completes the productization process

Personally, I am glad to see that all F# (including the compiler) is planned to be published under MS-PL.
That helps to take long-term decisions.

Chris

By on 5/26/2009 2:57 AM ()

And now its almost 2010 and the PowerPack and all its functionality that are used in books about F# (eg Foundation of F#) is still not a part of it. You still cant use a thing like print_endline. That makes me think: are they really commited to this. Or is this going to be a new smalltalk. You know its really cool everyone is using it I promise you.

By on 12/15/2009 12:49 PM ()

Hello Adversus,

Some dispassionate skepticism is a healthy thing. Imagine if we took everything coming out of Redmond as the Law and the Prophets. Probably better to remember their concern is more the law and the profits. Still, I don't see MS dropping F#, or letting it drift of into limbo (as they have with numerous technologies). My impression (outsider looking in), is they have a lot of motivation to see this through.

If F# is anything, it's a MS property (so it is what they make it). It's a functional language if they make it so; it's multi-paradigm, if the want it to be. I think they have reasons to want it to be both. A functional approach (and a language to implement same), should be useful, if not necessary, to solve challenges for them (internal and external). They could (and to some extent have with C#), add functional capabilities to an imperative language - but that doesn't serve the change in mindset that a purposed functional language can.

Being a MS product also means is will be multi-paradigm; because they will want to leverage their investment in the .Net framework. F# gains use of an established industrial strength framework, and the framework (and ultimately MS), gain a wider audience, additional means of access, and further dependency on that important MS property. I assume that the idea is that the functional side will retain all its beneficial qualities; while the framework will provide the manageable side-effects necessary to get real work done. I guess we'll see how well they do.

Perhaps more interesting, is to consider how differently we see what is important - what makes F# a 1st or 3rd class .Net language; what criteria to use to judge where taking on a new programming language is worth it or not. Reading through the earlier posts in this thread, it's obvious that others have a much different perspective (formed by experience, style and motivations). Some of the concerns voiced would never have occurred to me; they just don't figure into the scale and direction of what I do. I doubt any of use is, or will be fully satisfied by what F# offers; but it seems a closer match, and a safer bet than the others I've considered lately. On the upside, that F# is in an early stage; and the concerns raised have a fair chance of being addressed - including the concern that might go the way of [insert your favorite abandoned technology here].

Re your mention of the PowerPacK features in VS2010, do the posts in this thread [link:cs.hubfs.net] help?

BRN..

By on 12/18/2009 6:55 AM ()

Hi Michael,

thanks for the response.

Although I believe that tooling, deployment and license are all important I hope my emphasis was on deployment, particularly the inclusion of F# compilers and libraries in .NET 4.

... assuming you're shipping apps and not libraries.

Unfortunately most enterprise applications are composite - standalone compilation is useful for the individual developers desktop, but does not scale in an enterprise environment.

I certainly don't wish to restrict the F# team in any way!

I'd love to see a complete Scripting API, syntactic macros, higher-kinded polymorphism, automatic properties, mathematical libraries etc. in the future. I just believe that should large global corporations start adopting F# in earnest, the financial rewards to the project would be large and would allow for an even greater investment in F# from Microsoft. This is the virtuous circle I'm trying to promote.

regards,

Danny

By on 4/15/2009 8:00 AM ()

Might I enquire as to the nature of the apps that are shipping?

I believe the only public info is that the PowerPack is going to ship more frequently. So, IF anything else got into .NET or some other package, you'd still have redist of the PowerPack as that gets upgraded. At least, assuming .NET doesn't obtain some faster shipping cycles :).

Have you tried to leverage your company here? For instance, use your MS representatives to inquire about this issue and provide info on how you want to use it? It probably wouldn't hurt for positive F# messages to go through other channels than fsbugs.

By on 4/15/2009 9:45 AM ()

Have you tried to leverage your company here? For instance, use your MS representatives to inquire about this issue and provide info on how you want to use it? It probably wouldn't hurt for positive F# messages to go through other channels than fsbugs.

This is a good idea - and one that I'll pursue.

P.S. Has anyone else noticed that F# is not part of 10-4?

By on 4/15/2009 10:15 AM ()

Luke deals with the issues of deployment and CodeDOM amoungst others in his nice Lang.NET presentation.

Surprisingly, no mention of .NET 4 though.

By on 4/20/2009 1:56 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper