> 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)?
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.
As an anecdote, Dutch startup Silk writes their entire backend in Haskell. Their founder Salar told me that while finding 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.
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.
+1 I also say that language polyglots are generally a much better find than those who build their career around a single language to rule them all. Although some of us promote JS as pretty close to that, even JS has a C/C++ base under the covers.
It's hard to get any new system to be seen seriously. It took the better part of 3-4 years for NodeJS to see any traction, and even then it's misunderstood. I continuously see people following the same patterns in building Node modules as they would for C# libraries.
It looks like you've at least tackled what is a very hard part in many organizations, and that is infrastructure. Not to mention, the new code can intermingle with the old (at least for a while).
I like FP paradigms, I find that it definitely leads to better unit test coverage... Not that unit test coverage is everything.
Maybe so; though job ads I'd seen for F# seemed to have higher salaries. Possibly that was just because of where they're based (London salaries are way higher than here, for example)
Well, nothing stops you from trying it out and seeing what happens, right :-)
Post a job ad explicitly requiring functional programming experience and I'll bet an enthusiast will end up on your doorstep soon enough. Then you can see whether your fears hold or not.
The job ads for F# usually do have higher salaries than those for C# programmers. However, I think you misunderstand why that is the case; it's not (just) because good F# developers are harder to find than good C# developers, it's because a good F# developer will be more productive, even more so than reflected by the salary ratios. A good F# developer is (almost always) going to also be very proficient in C# too, so they'll be able to switch back and forth easily and use whichever language is better-suited for a specific project.
Please don't put F# on a shiny golden pedestal. A good C# developer can use it without any problem as well. You of course would need to be open-minded enough to understand that a C# developer doesn't mean an imperative developer. I am not the best developer at all, but my C# code tends to be quite functional and I prefer using the Maybe monad to deal with nulls in some cases for example. I just don't see any massive obvious benefit of loosing the tooling and ReSharper to switch to F#. Especially now that C# is open-source and the Roslyn is nearly there.
PS: a good JavaScript developer will probably be even more productive than both C# and F#, despite the language being horrible.
Well, by switching to F# you get much better type inference, discriminated union types, pattern-matching, explicit tail-recursion, serializable types by default, and type providers (and that's not even a comprehensive list). I suppose it depends what type of app you're building as to whether those are worth anything to you -- but in the areas where F# is rapidly getting more popular (data science, numerical/algorithm-heavy work, distributed computing) they do in fact make you much more productive. A good chunk of that productivity gain results from being able to easily and quickly write type-safe code and express algorithms without a great deal of syntactic overhead.
A JavaScript developer might be more productive than either a C# or F# developer depending on what kind of app he/she was writing; overall I don't think that would be the case, especially once you factor in maintenance costs of the code over the long-term.
> A good C# developer can use it without any problem as well.
This is not true (I've been a C# dev for many years already, and I've been learning F# for the last months). It's not so easy to switch the mindset and the syntax.
> PS: a good JavaScript developer will probably be even more productive than both C# and F#, despite the language being horrible.
Yeah, more productive the first days (at a PoC phase), but more productive the next months? I don't think so. You need to watch this talk: http://vimeo.com/72870631
The video is not a good argument. All the time I saved writing Haskell by being able to use quick check was completely torched by having to refactor my entire codebase, with no tooling, when I realized I needed to thread some configuration state all the way down to a tiny area of my code as well as spending a good 4 or 5 days hunting down space leaks.
Overall, I think I would have been more productive with OCaml. Every language has trade-offs, you just have to understand what they are and how they affect the problem you're working on.
The talk isn't about Haskell. Haskell is used just as an example for most code snippets. But all arguments raised in the talk apply perfectly well to F#, and F# has much better tooling than Haskell.
I can confidently answer "yes" to this question, because Tachyus, the first Silicon Valley start-up in the oil and gas industry, http://dealbook.nytimes.com/2014/04/10/tachyus-a-data-start-... , 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.
> IDE support even in Visual Studio 2013 is absolutely poor
It suits my needs well. References for functions/values/types would be a big nice to have, but I don't miss it that much. Refactoring? Rename refactoring is in the F# community Power Tools http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-... I've never missed it enough to bother. As for the show-stopping bug in the Power Tools formatter, I would not want software someone else wrote re-arranging the white space in my file. Beyond that refactoring support is rather ill-defined. Making a mish-mash of functional and imperative code more functional/compositional/readable requires thought.
> Options are great; nulls are bad
Many functions in the .NET Framework now support a try version which interface very well with F#, thank you. Other than that F# cannot perform the miracle of making external software null safe.
> F# was completely missed from Roslyn
I respect the OP, but I couldn't care less. (See my next comment.) Roslyn in many ways is just playing catch up with F#, anyway.
> There’s little info on what’s coming in the next version of F#
As a language, F# is pretty feature mature. (The big thing I would like to see is dependent types.) The action going forward is with the open source community, https://groups.google.com/forum/#!topic/fsharp-opensource/1C..., which Microsoft fully supports, as it should be with a fully open source language. I know people in the community who already have compiler enhancements, for instance, that should come around in the foreseeable future.
> Hiring developers is already very hard
Fortunately for Tachyus, we have a compelling technology company story and a growing team that makes the F# people (and not just F# people) we want to recruit also want to join us, going so far as to relocate across the country.
This of course does not work for the IT Department of Acme Industries in Flyover, Kansas. The HR department will hate you, but the best alternative is probably to build a core of F#'ers internally. You will have to be creative about your recruiting after that. You need to demonstrate your organization offers a career rather than just a job.
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# :-)
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: http://fsharp.org/testimonials/
To be honest, I think that "not getting the love it deserves from MS" is the best thing that happened to F# :-). They did really good job at supporting the community - by open-sourcing F# and now also accepting contributions to the official MS release.
But the fact that they did not keep full control of F# means that the community had time to setup "The F# Software Foundation" (http://fsharp.org) and develop a really healthy open-source ecosystem around F#.
If you look at the data-science story around F#, there are libraries like F# Data, Deedle, R Type Provider, etc. I'm biased, because I contributed to most of them, but I think that community did much better job than Microsoft would in this area. So "not getting the love" is more like "getting freedom". And I think it really helped F# in many ways.
Do not get me wrong - MS is an important contributor and everyone in the community acknowledges that. But they are just a part of the F# story (there is excellent Xamarin support, great open-source projects etc.)
For the language, maybe so; but MS are building great tools for C#/VB and it's senseless for the community to reimplement them for the "other" .NET language :(
The refactor/codefix support in Roslyn/VS is great; but I wouldn't even know where to start doing something similar in F#? Can I reuse the functionality? Or is the editor so disconnected that I'd need to implement all the menu etc. myself too? (This would make it inconsistent and not play nice with submissions else's CodeFixes that might draw menus).
Those used to make c++ and COM/win32 as their main platform think MS has definitively abandoned them and will soon or late drop its support and bet everything on managed languages.
Those that now are trying to use javascript think that MS is using it just as a fourth class citizen and will soon or late drop it without much emotions and/or that anyway the documentation support is very poor intentionally.
Those of C# think that MS is making fun of them constantly switching from a framework to another and, anyway, that MS is surely betting all again on c++ and javascript.
Those of F# think that MS is investing nothing in it and that it is considered just a bastard son of C# and tries to never speak about it.
So if you hear all the voices it seems that MS is investing in nothing and making all unhappy.
OR, maybe, the grass is always greener on the other side.
I think that given MS's own history of creating dead ends, then dropping them you can't fault them too much. MS does simply respond to market demand more or less than anything. And sometimes there's internal developer demand.
MS invested quite a bit into NodeJS and libuv for windows. That said, they did little to actually get a tooling option for making native modules easier. I would think that this was to first and foremost get node.js into a place where it is an Azure option. Not to mention that it seems some of their own tooling in this space is using it.
After MS announced the Dynamic Language Runtime (DLR) with managed JScript as it's debut language of choice, I was rather excited. When they brought in IronPython and IronRuby, I was happier still. A unifying platform for many dynamic languages seemed pretty awesome. Then JScript fell to the side, and before long MS support for IronPython, IronRuby and the runtime itself fell to the side.
MS can't support everyone 100%, and backing nothing but .Net has certainly cost them mind share. It's also not like MS is a single hive mind. There are lots of people that have come and gone over the years. I think MS does what its' paying customers (and potentially paying customers) asks of it.
The irony is a lot of this effort has been into a platform (Azure), whose sales and marketing tactics were the biggest driver of me to look away from .Net in the first place. For many years every .Net presentation from MS was pretty much an Azure demo.. and only in the past year or so has Azure actually become a platform worth considering. That said, I hate a hard sell.
I think MS sees the writing on the wall, and knows they'll remain a first class citizen for many developer desktops, and an also ran for the mobile space. That means going hard into both tools, and support. They need Azure, and they need Visual Studio to be a best of breed platform. They've done a decent job at both. If they can get your code to run in Azure, you're a potential customer.. so they'll work to support that.
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.
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#.
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.
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.
I did mention that extension; and the bug I found right away :(
Roslyn isn't just about being open source; there's functionality like the Diagnostics/CodeFixes that make it trivial to do some really useful things, which are significantly harder using the F# source.
Overall my conclusion is not that F# is bad; I really love it; but there are some niggles for me still... Mostly around the level of investment from 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 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...
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 :(
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.
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.
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.
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!
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.
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*.
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.
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 once showed some of my C# code to Don Syme and he told me...that looks a lot like F# :) The biggest challenge, I guess, of F#, is that C# isn't that broken like say...Java is compared to Scala.
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?
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.
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.
We automated quite a bit with PowerShell. Our deployment scripts which unzip releases, update IIS config (apppools, virdirs, new sites) and our scheduled jobs are all done via PoSh. We also use it for lots of generation/execution of ad-hoc SQL for data manipulations.
As a shell (especially remoting to servers); it's great. As a scripting language, ironically I'm more likely to use F# (FSI) these days, mainly due to two serious bugs in PoSh Scheduled jobs we've never gotten any response from Microsoft over :(
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#.
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.
I don't see this same attitude in open source - the users are common major contributors to the ecosystem.
I think the F# community is much more like the "open source" model than the "closed MS model". The change is slowly happening in the rest of .NET, but F# is way ahead here.
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.
As an anecdote, Dutch startup Silk writes their entire backend in Haskell. Their founder Salar told me that while finding 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.
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.