7 ms·

Is F# Ready for Production?

68 points by d2p 12y ago

tpetricek 12y ago
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/ http://fsharp.org/testimonials/
- d2p 12y ago
  Haha :) The title could be qualified with "in our company", but then nobody would read it! ;) I love F#, but I'm not sure it's currently getting the love it deserves from MS :(
  - pjmlp 12y ago
    Microsoft is playing it safe, as their main customers are the enterprise. They see F# is easier to sell to the enterprise as a library language, not as a full stack one. Hence leaving that support role for the community. It sucks a bit yes, but on the other hand F# is doing pretty well in the financial sector in London, for example.
  - yulaow 12y ago
    To me seems that no one is happy with MS. 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.
    - tracker1 12y ago
      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.
  - tpetricek 12y ago
    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 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.)
    - d2p 12y ago
      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).
tonyabell 12y ago
many of the concerns the op had where with marketing of the f# ecosystem. For example the tooling issues he mention are solved with a Visual Studio Extension http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-... 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.
- d2p 12y ago
  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 :/
jackfoxy 12y ago
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-up-for-oil-industry-raises-6-million-from-founders-fund/ 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.
- Serow225 12y ago
  What are your thoughts/experiences/workarounds about the points he raised in the article?
  - jackfoxy 12y ago
    > 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-4c0b-8bac-86d774189cff 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/1CrjP7i0AN4 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.
platz 12y ago
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#. http://pluralsight.com/training/courses/TableOfContents?courseName=functional-architecture-fsharp http://pluralsight.com/training/courses/TableOfContents?cour...
- deleted 12y ago
  [deleted]
skrebbel 12y ago
> 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.
- d2p 12y ago
  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)
  - lclarkmichalek 12y ago
    Where is "here", in this context?
  - profquail 12y ago
    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.
ufmace 12y ago
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.
- d2p 12y ago
  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 :(
endeavour 12y ago
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 :(
overgard 12y ago
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.
- seanmcdirmid 12y ago
  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.
pnathan 12y ago
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. Just something I've noticed.
- tpetricek 12y ago
  I completely agree with your observation, but I'm not sure what is the point that you're trying to make here :-). F# is open-source and has a very active community that is contributing to many core parts - including the tooling (http://fsprojects.github.io/VisualFSharpPowerTools/ http://fsprojects.github.io/VisualFSharpPowerTools/ and http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/), the compiler now also accepts contributions and there are a few work-in-progress pull requests, as well as building some of the core F# libraries, e.g. for data science (http://fsharp.github.io/FSharp.Data/ http://fsharp.github.io/FSharp.Data/, http://bluemountaincapital.github.io/Deedle/ http://bluemountaincapital.github.io/Deedle/, etc.) 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.

68 points by d2p 12y ago

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/ http://fsharp.org/testimonials/

d2p 12y ago
Haha :) The title could be qualified with "in our company", but then nobody would read it! ;) I love F#, but I'm not sure it's currently getting the love it deserves from MS :(
- pjmlp 12y ago
  Microsoft is playing it safe, as their main customers are the enterprise. They see F# is easier to sell to the enterprise as a library language, not as a full stack one. Hence leaving that support role for the community. It sucks a bit yes, but on the other hand F# is doing pretty well in the financial sector in London, for example.
- yulaow 12y ago
  To me seems that no one is happy with MS. 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.
  - tracker1 12y ago
    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.
- tpetricek 12y ago
  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 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.)
  - d2p 12y ago
    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).

tonyabell 12y ago

many of the concerns the op had where with marketing of the f# ecosystem. For example the tooling issues he mention are solved with a Visual Studio Extension http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-4c0b-8bac-86d774189cff http://visualstudiogallery.msdn.microsoft.com/136b942e-9f2c-... 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.

d2p 12y ago
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 :/

jackfoxy 12y ago

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-up-for-oil-industry-raises-6-million-from-founders-fund/ 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.

Serow225 12y ago
What are your thoughts/experiences/workarounds about the points he raised in the article?
- jackfoxy 12y ago
  > 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-4c0b-8bac-86d774189cff 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/1CrjP7i0AN4 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.

platz 12y ago

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#. http://pluralsight.com/training/courses/TableOfContents?courseName=functional-architecture-fsharp http://pluralsight.com/training/courses/TableOfContents?cour...

deleted 12y ago
[deleted]

skrebbel 12y ago

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

d2p 12y ago
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)
- lclarkmichalek 12y ago
  Where is "here", in this context?
- profquail 12y ago
  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.

ufmace 12y ago

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.

d2p 12y ago
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 :(

endeavour 12y ago

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

overgard 12y ago

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.

seanmcdirmid 12y ago
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.

pnathan 12y ago

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. Just something I've noticed.

tpetricek 12y ago
I completely agree with your observation, but I'm not sure what is the point that you're trying to make here :-). F# is open-source and has a very active community that is contributing to many core parts - including the tooling (http://fsprojects.github.io/VisualFSharpPowerTools/ http://fsprojects.github.io/VisualFSharpPowerTools/ and http://fsharp.github.io/FAKE/ http://fsharp.github.io/FAKE/), the compiler now also accepts contributions and there are a few work-in-progress pull requests, as well as building some of the core F# libraries, e.g. for data science (http://fsharp.github.io/FSharp.Data/ http://fsharp.github.io/FSharp.Data/, http://bluemountaincapital.github.io/Deedle/ http://bluemountaincapital.github.io/Deedle/, etc.) 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.