[MichaelGG]

In general, overall tooling is not at the same level. Code gen is focused on a C#-like model, designers aren't there, debugging isn't the same (immediate window, for instance). Last i checked (which was a while ago), VS testing didn't work with F#. Even Intellisense is not as complete. I'm happy with F#, very happy indeed. But it lacks the resources that C# gets thrown at it. And it suffers from MS not having the honesty to just admit MSR outdid them again (as they did with generics), that as a language, F# simply outclasses C#. Instead, we get lines like "F# is for scientific computing" or similar spin.

So yes, shipping F# with VS is a good step, and technically it's supported, it's obvious MS has some discomfort there. Which is too bad, cause F# is a rare jewel, nothing else has the combination of language features, interop/library, performance, and tooling.

[jarcane]

This is something that does rub my the wrong way a bit as well. F# is a fantastic language, easily my favorite non-Lisp FP language, and possibly period, but it was very clearly second-class in the field of actually building full apps with it. MS just flat does not seem to believe that anyone would want to build full apps with F#, so support for doing so is a bit of a wild frontier.

Hopefully with F# in open source hands now this can continue to improve. In the meantime, I'm studying up on C# and .NET, so that I hopefully have at least the bare minimum familiarity to work around these limitations.

[MichaelGG]

It's a self fulfilling prophecy. F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps.

Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript.

I will say though otherwise I'm happy. In using F# to run my server apps with smooth pinvoke into my Rust code, which is expressive enough to offload a lot of logic. And with VS soon to be free, and Mono working fine, MS might not get any money from it. (Why deploy any sort of scale on Windows when it's line $35/core/month?) So, in that sense it's selfless and I'm quite grateful.

[kirse]

F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps.

This is just something that takes time and commitment from the community. It's only ~7 years old at this point, and if everyone just sits back and whines about the lack of tooling without, y'know, building & releasing something themselves, it'll be an ongoing problem. It's the "take take take" mentality - often disguised as being an open source advocate - of most software devs where they want everything for free (guilty as charged, myself).

That said, WebSharper is out there, which is a pretty solid framework for a lot of tasks. I've been thinking about ways to creatively encourage/solve the tooling problem though, starting with exhorting all of us in the F# community to reduce the whining and redirect the energy into creating solutions. Tooling is only a self-fulfilling prophecy if we continue to act as-if the outcome is out of our hands.

[MichaelGG]

You're right, I am just whining.

But more to the point, I am pointing out that Microsoft is not treating F# like C#, not giving it the same resources. No one says C# users are just whining when they wanted, say, edit and continue.

Has any community, ever, stepped up and offered an experience as good as Visual Studio's? I mean, that's sort of a major reason Microsoft makes and sells that product.

Yes WebSharper is pretty awesome. But I still don't see why we shouldn't criticize MS for not doing something like that directly. After all, MS got flack over ASP.NET Web Forms then went and put resources into MVC.

[jarcane]

Ultimately, I decided this is what I want to do. I wanted to learn more about the Windows ecosystem anyway, so why not learn the missing bits from C# and .NET (which I came to F# without), and then be able to continue working in a language I love with enough know how to help fill in those gaps myself. Besides, having that under my belt can hardly hurt my career; the nice thing about F# is the related skills are also well in demand too, and a lot more pleasant to code in than some other hosted FP languages ...

[pjmlp]

> Instead, we get lines like "F# is for scientific computing" or similar spin.

You will never sell the typical VB.NET/C# enterprise .NET developer into F#.

I find very commendable what Microsot has done so far, even if it feels too little.

It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO.

Let me know when Oracle gives at very least the same level of support to Scala in Netbeans and JVM design.

[MichaelGG]

F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type.

MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and be honest and complete in their statements. It'd also be nice if MS viewed shipping actual language independent code, instead of stuff that takes dependencies on C# compiler details.

MS gained a huge amount from the F# folks by getting CLR generics from them - that's one major benefit over the JVM. Just on that alone perhaps they owe them that (maybe, I've little clue of internal politics, except that there is some resentment towards F#, and at least a bit of censorship on publishing things that make C# look poor).

Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

[pjmlp]

> Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

Is Rust 1.0 out yet?

They are on Microsoft research.

While the world still isn't ready for the likes of Singularity and IronClad, Spec# and Dafny, at least part of the technology has landed on Windows Phone 8 and .NET Native compilers.

[steveklabnik]

Rust 1.0 is currently slated for 8-14 weeks away: http://blog.rust-lang.org/2014/12/12/1.0-Timeline.html

[pjmlp]

I know, and comparing its current state with what F# offers today doesn't make sense, not today.

In a few years time when Rust has the same eco-system has F# offers today to Windows devs, then we can compare the current state of the languages.

[steveklabnik]

Sorry, I thought you were asking a question, not being rhetorical.