Comment by endeavour | Hacker News Reader

Comment by endeavour | Hacker News Reader

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...

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-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/

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.

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 :(

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-incide...

Your article is out of date, and unfortunately the fact that you "could do" something is far less useful than simply having it done.

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.

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.

I wasn't being hostile at all, or at least that wasn't my intent. I explained why I disagreed with each of the points made.

Calling a reasoned, even-handed assessment "ridiculous" sets a pretty bad tone at the outset. That tone continues through your post (e.g. hiring difficulties are "nonsense").

The submission asks a question that many shops confront when F# is proposed. And the reality today is that many come to the conclusion that no, it isn't ready for production, for many of the reasons the submission notes. Your outrage will not change this reality.

"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.

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.

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.

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!

What's the largest project you've ever written in a dependently typed language?

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*.

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.

Reply on news.ycombinator.com