F# support

[ErikSchierboom]

I'd love to see F# support, similar to how VB support will be added.

[KodrAus]

+1 for F# support

[spencerwi]

Another +1; F# is the whole reason that I'd try to do .NET work (as a Linux/OSX dev)

[itajaja]

yay! +1

[muratg]

Language support (including VB.NET) is not in scope for V1. Putting this one to Backlog as well.

[jskulavik]

@davidfowl pointed out how this could be achieved long ago, @Alxandr already gave it a go, and we've now got beta 7+ to work with possibly using this as a spring board. Given that ASPNET5 is an OSS project, why shouldn't the 'community,' in this case the outstanding F# community, contribute? The new MSFT is give and take folks, no longer just give, and we shouldn't just take, but give. I'm personally +100 for the support of F#, but let's make it happen as a community rather than demand this already overloaded team just provide it like they did in the MSFT of old.

[spencerwi]

@jskulavik As you pointed out, @Alxandr did already give it a go. This issue is, as I understand it, about official support for F# (a Microsoft language) on Microsoft's own .NET language runtime, using stabilized APIs, rather than unofficial support against beta APIs.

Trust me, I've tried quite a bit using and digging into Alxandr's YoloDev work, but the problem right now is that aspnet/vNext are in such a "move fast and break everything" phase right now that community support is far from stable.

[jskulavik]

@spencerwi Great point! My only real point was that the community could help out and ideally shorten the development time associated making the official support come to life. Pull requests are a beautiful thing, and I'm sure the ASPNET5 team would love to exercise the out-of-band development approach.

[muratg]

Thanks folks, as @jskulavik pointed out, the team is overloaded with V1 so had to cut some features to make room for core features + stability. These were hard cuts to make, and we're planning to bring most of these back post V1. (That's why these issues are not closed.)

That being said, I personally love F# and hope to see some community supported F# support in the meantime.

[Alxandr]

I'd just like to point out that the API used to implement the F# compiler on top of DNX has been mostly stable for months. I've had to make a few, really small changes, due to refactorings in DNX, but nothing that has taken any major effort or rewrite. I'm not saying go use my YoloDev F# support in production or anything (I mean, the name should give you that hint if anything), but all in all it's just a plug for the actual F# compiler to compile your code (as opposed to Roslyn), so the output should in general be just the same as if you used the actual F# compiler. Also, if you wanted to take it to production, you'd most like produce binaries locally, (or on CI) before doing so, in which case it wouldn't much matter either way, because the YoloDev compiler plug wouldn't even be loaded.

Also, @spencerwi, if there's anything you don't understand about the current compiler plug implementation, I'll be happy to answer any questions :) (I just might not notice them being asked, so just scream at me a little if you don't get a reply within a day or two :P ).

[KodrAus]

I'm wondering what 'F# support in DNX' should look like idealy. Is a plug to the F# compiler sufficient, or should support for F# go down to Roslyn?

[davidfowl]

Roslyn supporting F# really has nothing to do with the DNX. The compiler API in DNX is separate from roslyn itself. It just happens to be our default experience.

[KodrAus]

@davidfowl I get that, I'm trying to be philosophical