4 ms·

This article is ridiculous. F# is used in production in lots of places from startups like Tachyus and SnappyGrid, to mid-sized firms like Trayport all the way t

This article is ridiculous. F# is used in production in lots of places from startups like Tachyus and SnappyGrid, to mid-sized firms like Trayport all the way to huge corporations like Aviva, Credit Suisse, EDF and Barclays Capital. IDE Support: Sure, the IDE support might not be quite as developed as C#. But frankly most refactorings are just pressing tab a few times with F#. Refactorings for C#/VB.NET are mostly workarounds for languages that require huge amounts of excess syntax. The IDE support for F# is still way ahead of most of the competition (particularly dynamic languages). The intellisense and error highlighting work fantastically well. Options/nulls: Yes I suppose you still occasionally have to do a null check if you interface with legacy libraries. but I think having thousands upon thousands of .NET libraries means this is a worthwhile tradeoff. Plus you can use the TryGetX methods in F# far more nicely than in C#. http://luketopia.net/2014/02/05/fsharp-and-output-parameters/ http://luketopia.net/2014/02/05/fsharp-and-output-parameters... F# missed by Roslyn: F# has had an open source compiler written in F# for years. C# is a ridiculous language to choose to write a compiler in. See http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-compiler/ http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-comp... What's coming next: F# is so far ahead of C#/VB.NET that this argument is ludicrous. Even if F# remained stagnant it would still always be better than C#. It has sensible defaults: immutability over mutability, functional over OOP, parametric polymorphism over inheritance, lack of nulls over null checks everywhere. C# has poor defaults that are now irreparable due to the need to keep backwards compatibility. F# is open to contributions now so I would expect some great things. Joinads, for example... http://tryjoinads.org/ http://tryjoinads.org/ Hiring developers is hard: This is a nonsense statement. Sure, if you want to hire 100 F# developers you might struggle, but you're going to struggle to find 100 good C# developers. Yaron Minsky from Jane Street reports hiring OCaml developers was "the easiest hiring he's ever done". If you tweet that you are looking for F# developers I know from experience that you'll get a lot of responses from very talented developers. Most places I've worked have a terrible time finding decent C# devs - interview:hiring ratio is around 50:1.

d2p 12y ago
I didn't conclude it wasn't ready; it was an open question documenting my own concerns. The IDE support is poor compared to C#, which is what we're currently using. Roslyn isn't just about open source (nor writing a compiler in C#!); there's a bunch of functionality (like refactor, diagnostics, code fixes) that will breed a bunch of new tools that F# is sadly not on the boat for :(
- endeavour 12y ago
  There's no reason you couldn't implement those things for F#... the compiler, the libraries and the visual tooling is all open source now and accepting contributions. In fact I suspect it would be easier than trying to use Roslyn. http://neildanson.wordpress.com/2012/12/24/the-roslyn-incident/ http://neildanson.wordpress.com/2012/12/24/the-roslyn-incide...
  - Locke1689 12y ago
    Your article is out of date, and unfortunately the fact that you "could do" something is far less useful than simply having it done.
- sklivvz1971 12y ago
  Don't get discouraged by the comments, your post is fair. I was a team lead at one of the companies mentioned by the OP, and using F# was a painful and ultimately a major failure, because of poor tooling and difficulties in hiring skilled developers in the language. It's not impossible to succeed, but there are a lot of ways to making it much harder -- one of this being choosing a niche language without a compelling reason to do so. There is nothing wrong with F#, the language (even though I don't particularly like its syntax), but clearly one has to account for the costs of reskilling the team on a new language, as well as a new paradigm, making a bet on a language with a still uncertain future (will it ever become a mainstream language?) and really non-existent tooling support. Given that both C# and F# are general purpose, hybrid languages, I don't see a compelling story -- in 2014 -- behind F# that makes it such as huge deal as its advocates make it. The onus is on them to bring convincing evidence to the table that, once factored in the risks and the costs that arise from the shortcomings, the benefits are still a good bargain in the real world, and with real people, outside of the easy fake example one finds on blogs etc.
- personZ 12y ago
  Your post is reasoned and fair, and some of the bizarrely defensive replies you have received are just wholly undeserved. People vest too much of their ego into technology choices, and it reflects in that sort of over the top hostility.
profquail 12y ago
I'm a bit miffed as to why MS didn't use F# -- a language from a family of languages designed to implement compilers -- to implement Roslyn. If they had, they could've even gone back later and re-implemented parts of it in F* to guarantee the compiler was bug-free!
- Locke1689 12y ago
  What's the largest project you've ever written in a dependently typed language?
  - profquail 12y ago
    Please re-read my comment. I didn't suggest implementing the entire Roslyn project in F* , I suggested it might have been better to write it in F#. If that were the case, and the code were written in an idiomatic functional style, it would at least be plausible (although still not easy) to verify parts of the codebase in F*.
- kvb 12y ago
  If you look at the Roslyn source, I'm not sure this would have worked too well. It looks like a lot of the C# is somewhat unidiomatic as it is (presumably to meet extremely aggressive performance targets), so it's not clear that F# would have provided much benefit. If you're building a compiler that doesn't need to scale to million line codebases, then F#'s a clear winner, but here I'm not so sure.
_random_ 12y ago
"F# missed by Roslyn" - it's about tooling rather than the perfect academic compiler language choice. The best language to write a compiler in is the target language of the compiler.
- profquail 12y ago
  The best language to write a compiler in is the target language of the compiler. Citation please? Writing a compiler in the language it's targeting is not always "best", but it is often done to reduce dependence on external toolchains and to flush out bugs in the language or compiler itself (since a compiler is usually a fairly complex program). Every language has it's own benefits and drawbacks; the ML family of languages (which F# belongs to) was purpose-built for implementing compilers (and theorem-proving tools), so it would have been an excellent choice for implementing Roslyn, or at least parts of it.
  - Locke1689 12y ago
    If you're writing a general purpose language, the benefit in dogfooding is impossible to beat. Language design and implementation are close bedfellows, and having the language design directly affected by the language is practically invaluable.

d2p 12y ago

I didn't conclude it wasn't ready; it was an open question documenting my own concerns. The IDE support is poor compared to C#, which is what we're currently using. Roslyn isn't just about open source (nor writing a compiler in C#!); there's a bunch of functionality (like refactor, diagnostics, code fixes) that will breed a bunch of new tools that F# is sadly not on the boat for :(

endeavour 12y ago
There's no reason you couldn't implement those things for F#... the compiler, the libraries and the visual tooling is all open source now and accepting contributions. In fact I suspect it would be easier than trying to use Roslyn. http://neildanson.wordpress.com/2012/12/24/the-roslyn-incident/ http://neildanson.wordpress.com/2012/12/24/the-roslyn-incide...
- Locke1689 12y ago
  Your article is out of date, and unfortunately the fact that you "could do" something is far less useful than simply having it done.
sklivvz1971 12y ago
Don't get discouraged by the comments, your post is fair. I was a team lead at one of the companies mentioned by the OP, and using F# was a painful and ultimately a major failure, because of poor tooling and difficulties in hiring skilled developers in the language. It's not impossible to succeed, but there are a lot of ways to making it much harder -- one of this being choosing a niche language without a compelling reason to do so. There is nothing wrong with F#, the language (even though I don't particularly like its syntax), but clearly one has to account for the costs of reskilling the team on a new language, as well as a new paradigm, making a bet on a language with a still uncertain future (will it ever become a mainstream language?) and really non-existent tooling support. Given that both C# and F# are general purpose, hybrid languages, I don't see a compelling story -- in 2014 -- behind F# that makes it such as huge deal as its advocates make it. The onus is on them to bring convincing evidence to the table that, once factored in the risks and the costs that arise from the shortcomings, the benefits are still a good bargain in the real world, and with real people, outside of the easy fake example one finds on blogs etc.
personZ 12y ago
Your post is reasoned and fair, and some of the bizarrely defensive replies you have received are just wholly undeserved. People vest too much of their ego into technology choices, and it reflects in that sort of over the top hostility.

profquail 12y ago

I'm a bit miffed as to why MS didn't use F# -- a language from a family of languages designed to implement compilers -- to implement Roslyn. If they had, they could've even gone back later and re-implemented parts of it in F* to guarantee the compiler was bug-free!

Locke1689 12y ago
What's the largest project you've ever written in a dependently typed language?
- profquail 12y ago
  Please re-read my comment. I didn't suggest implementing the entire Roslyn project in F* , I suggested it might have been better to write it in F#. If that were the case, and the code were written in an idiomatic functional style, it would at least be plausible (although still not easy) to verify parts of the codebase in F*.
kvb 12y ago
If you look at the Roslyn source, I'm not sure this would have worked too well. It looks like a lot of the C# is somewhat unidiomatic as it is (presumably to meet extremely aggressive performance targets), so it's not clear that F# would have provided much benefit. If you're building a compiler that doesn't need to scale to million line codebases, then F#'s a clear winner, but here I'm not so sure.

_random_ 12y ago

"F# missed by Roslyn" - it's about tooling rather than the perfect academic compiler language choice. The best language to write a compiler in is the target language of the compiler.

profquail 12y ago
The best language to write a compiler in is the target language of the compiler. Citation please? Writing a compiler in the language it's targeting is not always "best", but it is often done to reduce dependence on external toolchains and to flush out bugs in the language or compiler itself (since a compiler is usually a fairly complex program). Every language has it's own benefits and drawbacks; the ML family of languages (which F# belongs to) was purpose-built for implementing compilers (and theorem-proving tools), so it would have been an excellent choice for implementing Roslyn, or at least parts of it.
- Locke1689 12y ago
  If you're writing a general purpose language, the benefit in dogfooding is impossible to beat. Language design and implementation are close bedfellows, and having the language design directly affected by the language is practically invaluable.