5 ms·

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures ar

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associate programming with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier. I think that functional programming is on the rise, and that more and more developers are starting to realize that the types of bugs that hold them back can be reduced by using a more powerful language. But it's got a very long way to go, because there is a lot of unlearning to do. The article alludes to this a bit. For example, immutability is one of the key concepts in nearly every FP language. Functional programmers take it for granted, but it's transformational and completely changes the way you have to solve a problem. This hump is often too big for many people to get over, at least in their first trial with a functional programming language. It's hard to solve a task you know how to solve when you now need to re-think your approach because the language doesn't let you change x in-place. Additionally, I believe that many programmers aren't necessarily aware of all of the problems they're having. The next time you hear someone say, "and make sure to check for null here", watch them to see if they're seeing that as a general problem hurting their ability to get bits out the door or not. In my experience, it's not usually viewed that way. Yes, null is a necessary evil in many environments, but it's one that can be tamed, and different languages have already figured out how to do that. But unless it's seen as a problem by people at large, they won't see that as a carrot when you wave things like Optional types in front of them. Overall, I'm still excited. Jet.com is a billion-dollar company that built their stuff with F#. There are similar stories of companies successful with F# (and other functional programming languages), and it feels as though this is happening more often. And as the mainstream (read: C-style languages) adopt more functional programming techniques, I think this will only get better. I think that people will see the value, then see a language which does it better, and give it a try.

rottyguy 9y ago
"...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.
- phillipcarter 9y ago
  It's often very difficult to come up with one, because there isn't really a silver bullet here. The draw to F# for me, when I was learning it, was I needed to build a DSL in a large system I was working on (side note: there must be a law somewhere stating that any large system will have a DSL in it somewhere). I didn't know about libraries like FParsec or anything (or a C# equivalent), so I just googled "how to write a DSL C#" and ended up somewhere showing F# code. I was curious. A week later, I wrote the whole thing in F#, with tests, and all requirements were fulfilled. Upon re-writing in C# (because reasons...), I had to re-think the problem. I used F# types and pattern matching everywhere, and Active Patterns to make stuff really concise and readable. A lot of the branching logic in my C# rewrite didn't really exist in F# because of this, and it was really hard for me to track down how everything worked in C#. I'm still convinced that someone unfamiliar with F# could understand the F# version better than the C# version because of how much less code and branching logic was involved. For a more professional case study, Microsoft Security Risk Detection is a fuzz testing service written in F#: https://blogs.msdn.microsoft.com/dotnet/2016/12/13/project-springfield-a-cloud-service-built-entirely-in-f/ https://blogs.msdn.microsoft.com/dotnet/2016/12/13/project-s... We blogged about their experience, and they do have practical examples there.
- dep_b 9y ago
  I can't give you any examples in F# from the top of my head, haven't touched it for a few months but I did ship software with it. I can give an example in Swift: C#: ResultObject MyFunction(SomeObject some, AnotherObject another) You have no idea if every value you pass in is required, or if you would always get a ResultObject or also need to expect null. Could possibly throw an Exception as well. Swift: func myFunction(some: SomeObject, another: AnotherObject?) throws -> ResultObject Forces you to give SomeObject, but you can pass nil to AnotherObject if you would like to, and the code inside this function will be forced to deal with it. Also it will always return ResultObject unless it throws an Error. You will have no surprises using Swift while C# forces you to guess unless you know the inside of the function. F# works the same as Swift in that regard. You need to be explicit about nullability and mutability, and if it is nullable you are forced to deal with it it before you use it. Immutable and non-nullable is just easier to use. The leap between C# and F# is much bigger because C# is really good and F# is a real functional language where Objective-C was older and Swift is less functional. Same goes for Java vs. Kotlin. Android Java is terrible compared to C# while Kotlin is much more similar in syntax.
srean 9y ago
At what point does big company politics become a drag rather than a lift ? F# is not Microsoft's important story in a way that Java was for Sun. In such situations, I wonder if something that came into being organically and in the open (and helped on by a sugar daddy) has better chances/purchase.
- pjmlp 9y ago
  Replacing the contents of my previous post regarding VS 15.3 support of F#. "For long time .NET developers, a common question is "when will Visual Studio support F# .NET Core projects". We’re working hard to get this functionality ready, but unfortunately, we’re not quite happy enough with the quality in the 15.3 update to announce that it’s fully supported. While Visual Studio 2017 version 15.3 is able to open the new F# .NET Core projects, build, and debug them, IntelliSense does not yet work correctly" From https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/ https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...
  - phillipcarter 9y ago
    I'm sorry, but what you're saying is factually incorrect. Can you please update your comment so as not to spread misinformation?
    - pjmlp 9y ago
      Updated with the blog quote.
      - phillipcarter 9y ago
        This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.
flavio81 9y ago
> People, especially while learning, associate programming with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier. I'd say this is the main problem with the programming community at large, in 2017.
GiorgioG 9y ago
I'll get excited when the Visual Studio team actually holds up a release because something is horribly broken in its F# support. So basically...never.
- toyotaboy 9y ago
  Just use VS Code + Ionide. That's where the action is for at least for F# + .NET Core
  - TensorMetric 9y ago
    It's misleading to pretend that it's a substitute for full Visual Studio.
deleted 9y ago
[deleted]
runT1ME 9y ago
My previous job was working for a .NET shop that powered tons of automotive search engines etc. across the web. We moved to more and more functional concepts using C# as the team learned about them and had a lot of success with them. At a certain point, we explored using F#, but the lack of type classes & HKTs meant we kept having to repeat ourselves. We ended up choosing Scala for some new projects despite having an inferior IDE experience and being unable to use some of our other libraries. I don't think I can emphasize how much not having type classes and HKTs hurts productivity once you buy into the fully functional mindset. We were extremely productive in Scala because the language was a bit more powerful. I would love to use F# again, but not until the language adds those features.
- corn_dog 9y ago
  Is there anything about using F# that you would see as a plus over Scala or Haskell?
  - runT1ME 9y ago
    Oh yeah, 1. IDE experience is much better. 2. I like the fact that F# emphasizes the functional aspects, it's a bit of a 'tighter' language than Scala (despite the two crucial missing pieces) and so I think people could learn it a bit faster. Scala has things like structural typing, all kinds of optional syntax, multiple inheritance, etc. 3. Lack of flexibility in syntax is a plus imo for F#. Some of Scala's flexibility is nice, but some of it just confuses the newbies (like the various usages of `_`).
arwhatever 9y ago
I feel like someone invented a toaster oven that doesn't catch fire, but everyone wants to stick with the model that does catch fire all the time.
- pjmlp 9y ago
  Because when you manage to actually make a meal on both of them, the ones from the latter taste better.
nickpeterson 9y ago
Speaking of Jet.com and their billion, here is their GitHub page, https://github.com/jet https://github.com/jet :(
- toyotaboy 9y ago
  Kafunk is great https://jet.github.io/kafunk/ https://jet.github.io/kafunk/

rottyguy 9y ago

"...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.

phillipcarter 9y ago
It's often very difficult to come up with one, because there isn't really a silver bullet here. The draw to F# for me, when I was learning it, was I needed to build a DSL in a large system I was working on (side note: there must be a law somewhere stating that any large system will have a DSL in it somewhere). I didn't know about libraries like FParsec or anything (or a C# equivalent), so I just googled "how to write a DSL C#" and ended up somewhere showing F# code. I was curious. A week later, I wrote the whole thing in F#, with tests, and all requirements were fulfilled. Upon re-writing in C# (because reasons...), I had to re-think the problem. I used F# types and pattern matching everywhere, and Active Patterns to make stuff really concise and readable. A lot of the branching logic in my C# rewrite didn't really exist in F# because of this, and it was really hard for me to track down how everything worked in C#. I'm still convinced that someone unfamiliar with F# could understand the F# version better than the C# version because of how much less code and branching logic was involved. For a more professional case study, Microsoft Security Risk Detection is a fuzz testing service written in F#: https://blogs.msdn.microsoft.com/dotnet/2016/12/13/project-springfield-a-cloud-service-built-entirely-in-f/ https://blogs.msdn.microsoft.com/dotnet/2016/12/13/project-s... We blogged about their experience, and they do have practical examples there.
dep_b 9y ago
I can't give you any examples in F# from the top of my head, haven't touched it for a few months but I did ship software with it. I can give an example in Swift: C#: ResultObject MyFunction(SomeObject some, AnotherObject another) You have no idea if every value you pass in is required, or if you would always get a ResultObject or also need to expect null. Could possibly throw an Exception as well. Swift: func myFunction(some: SomeObject, another: AnotherObject?) throws -> ResultObject Forces you to give SomeObject, but you can pass nil to AnotherObject if you would like to, and the code inside this function will be forced to deal with it. Also it will always return ResultObject unless it throws an Error. You will have no surprises using Swift while C# forces you to guess unless you know the inside of the function. F# works the same as Swift in that regard. You need to be explicit about nullability and mutability, and if it is nullable you are forced to deal with it it before you use it. Immutable and non-nullable is just easier to use. The leap between C# and F# is much bigger because C# is really good and F# is a real functional language where Objective-C was older and Swift is less functional. Same goes for Java vs. Kotlin. Android Java is terrible compared to C# while Kotlin is much more similar in syntax.

srean 9y ago

At what point does big company politics become a drag rather than a lift ? F# is not Microsoft's important story in a way that Java was for Sun. In such situations, I wonder if something that came into being organically and in the open (and helped on by a sugar daddy) has better chances/purchase.

pjmlp 9y ago
Replacing the contents of my previous post regarding VS 15.3 support of F#. "For long time .NET developers, a common question is "when will Visual Studio support F# .NET Core projects". We’re working hard to get this functionality ready, but unfortunately, we’re not quite happy enough with the quality in the 15.3 update to announce that it’s fully supported. While Visual Studio 2017 version 15.3 is able to open the new F# .NET Core projects, build, and debug them, IntelliSense does not yet work correctly" From https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net-core-roadmap-update/ https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net...
- phillipcarter 9y ago
  I'm sorry, but what you're saying is factually incorrect. Can you please update your comment so as not to spread misinformation?
  - pjmlp 9y ago
    Updated with the blog quote.
    - phillipcarter 9y ago
      This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.

flavio81 9y ago

> People, especially while learning, associate programming with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier. I'd say this is the main problem with the programming community at large, in 2017.

GiorgioG 9y ago

I'll get excited when the Visual Studio team actually holds up a release because something is horribly broken in its F# support. So basically...never.

toyotaboy 9y ago
Just use VS Code + Ionide. That's where the action is for at least for F# + .NET Core
- TensorMetric 9y ago
  It's misleading to pretend that it's a substitute for full Visual Studio.

deleted 9y ago

[deleted]

runT1ME 9y ago

My previous job was working for a .NET shop that powered tons of automotive search engines etc. across the web. We moved to more and more functional concepts using C# as the team learned about them and had a lot of success with them. At a certain point, we explored using F#, but the lack of type classes & HKTs meant we kept having to repeat ourselves. We ended up choosing Scala for some new projects despite having an inferior IDE experience and being unable to use some of our other libraries. I don't think I can emphasize how much not having type classes and HKTs hurts productivity once you buy into the fully functional mindset. We were extremely productive in Scala because the language was a bit more powerful. I would love to use F# again, but not until the language adds those features.

corn_dog 9y ago
Is there anything about using F# that you would see as a plus over Scala or Haskell?
- runT1ME 9y ago
  Oh yeah, 1. IDE experience is much better. 2. I like the fact that F# emphasizes the functional aspects, it's a bit of a 'tighter' language than Scala (despite the two crucial missing pieces) and so I think people could learn it a bit faster. Scala has things like structural typing, all kinds of optional syntax, multiple inheritance, etc. 3. Lack of flexibility in syntax is a plus imo for F#. Some of Scala's flexibility is nice, but some of it just confuses the newbies (like the various usages of `_`).

arwhatever 9y ago

I feel like someone invented a toaster oven that doesn't catch fire, but everyone wants to stick with the model that does catch fire all the time.

pjmlp 9y ago
Because when you manage to actually make a meal on both of them, the ones from the latter taste better.

nickpeterson 9y ago

Speaking of Jet.com and their billion, here is their GitHub page, https://github.com/jet https://github.com/jet :(

toyotaboy 9y ago
Kafunk is great https://jet.github.io/kafunk/ https://jet.github.io/kafunk/