> <i>5.Hiring developers is already very hard. Do we want to limit the pool of available candidates significantly (and take the increased salaries that come with the harder-to-find skills)?</i><p>To that one, if I were in your shoes, I'd answer "yes" in a heartbeat. Using F# can help you differentiate yourselves on the job market. Everybody's looking for great developers, but you guys have a big plus when recruiting developers who prefer functional programming.<p>As an anecdote, Dutch startup Silk writes their entire backend in Haskell. Their founder Salar told me that while <i>finding</i> people is harder, the people they find are, nearly without exception, really good and passionate. They want to work for Silk because they want to code Haskell for their day jobs. They don't cost more than "other" developers at all, because they're so happy they can finally use what they feel is a decent programming language at work.<p>I guess F# has a bit less of a hardcore following than Haskell, but I bet that if you're one of the few functional programming shops in the region, Haskellers (and MLers and maybe even Lispers) will definitely prefer that over C# or Python.
I can confidently answer "yes" to this question, because Tachyus, the first Silicon Valley start-up in the oil and gas industry, <a href="http://dealbook.nytimes.com/2014/04/10/tachyus-a-data-start-up-for-oil-industry-raises-6-million-from-founders-fund/" rel="nofollow">http://dealbook.nytimes.com/2014/04/10/tachyus-a-data-start-...</a> , chose F# as the core software language. How did this work out? We went from absolutely no software written to deployed as the core operational software of a regional oil production company in 12 weeks. Our management and our customer's management are so happy with the results we are "all in" and not looking back.
For those who expect that Betteridge's law of headlines ("Any headline which ends in a question mark can be answered by the word no.") applies here, the article is actually quite positive about F# :-)<p>But even then, it is just worth pointing out that there is a massive list of testimonials from those who are already happily using F# in production in a wide range of areas, including finance, science, line-of-business, startups and many more: <a href="http://fsharp.org/testimonials/" rel="nofollow">http://fsharp.org/testimonials/</a>
many of the concerns the op had where with marketing of the f# ecosystem.<p>For example the tooling issues he mention are solved with a Visual Studio Extension<p><a href="http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff" rel="nofollow">http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-...</a><p>His concern with Roslyn seems like a non issues, a f# compiler is also opened sourced and was written in f# on day one. And there are many tools already taking advantage of it being open. So in this regard f# is farther ahead in c# in rubric.<p>As far a c# being ahead of f#, its funny, as most of the new features the are being added to c# seem to come from f#.<p>The op approach to hiring dev seems backward to me, you hire smart people and train then on your tools. There are so many good recourses for learning f#, having candidates without f# on their resume does not seem like a issues.<p>over it is great the he was able to bring f# into his environment. as more people adopt f# for there needs knowledge will spread and his concerns will fade.
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.<p>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.<p>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#. <a href="http://luketopia.net/2014/02/05/fsharp-and-output-parameters/" rel="nofollow">http://luketopia.net/2014/02/05/fsharp-and-output-parameters...</a><p>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 <a href="http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-compiler/" rel="nofollow">http://fsharpforfunandprofit.com/posts/roslyn-vs-fsharp-comp...</a><p>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.<p>C# has poor defaults that are now irreparable due to the need to keep backwards compatibility.<p>F# is open to contributions now so I would expect some great things. Joinads, for example... <a href="http://tryjoinads.org/" rel="nofollow">http://tryjoinads.org/</a><p>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.
Having used F# in a professional context (ok - I wasn't supposed to, but technically I got paid to do it), my general impression is that it's slightly better than C#, but not so much that it's really worth the effort to move towards it. Ask me in 2005 and my response would be totally different, but basically C# already co-opted most of the nice features F# brings to the table, so the only real downside of C# is that it's slightly more verbose and the type system isn't quite as good. In a vacuum I'd rather use F#, but all things considered C# is (almost) as good and using it brings a lot less friction.<p>Not to mention that it sort of brings a bit of weird legacy cruft from OCaml. Granted C# also drags along some annoying legacy cruft from Java, but using F# on the .NET stack always felt a little bit alien. It was nice, but it definitely didn't quite "fit". How to write "standard" C# always felt pretty simple, but I could never quite figure out what "standard" F# should look like, and it generally clashed a bit with code from other languages.
I'm curious about your experience with Powershell now. Did you put much work into using it to automate your processes? I spent about half a day or so looking into Powershell at our all-C# shop, and decided to use Ruby for my automation instead, which I have much more experience with. If you moved away from it, what are you using instead?<p>The first task I tried to pick up was doing backups and restores of our SQL server databases. I spent a couple of hours and couldn't figure out how to get Powershell to do that, but it took about 10 minutes to find a T-SQL command to do what I wanted, figure out how to run it from the command line using sqlcmd, and set up a Ruby script to automate it and generate the commands dynamically, etc.<p>Powershell also seems to require installing dozens of little thingys for using most of its features, all of which are very picky about bittedness, and which are mostly tucked away in weird corners of Microsoft's sites. Ruby has one installer on an easy to find site, though I admit it took a while to discover that using anything but 32-bit 1.9.3 on Windows will only lead to pain.
I'm much more optimistic on F# after watching this video series from Mark Seemann on pluralsight. He addresses some of the tooling issues and shows how to build a nice API in F#.<p><a href="http://pluralsight.com/training/courses/TableOfContents?courseName=functional-architecture-fsharp" rel="nofollow">http://pluralsight.com/training/courses/TableOfContents?cour...</a>
What I see in closed source systems - this is particularly clear in MS - is that the developers are always waiting for the controlling company to do something.<p>I don't see this same attitude in open source - the users are common major contributors to the ecosystem.<p>Just something I've noticed.