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.

Is there anything about using F# that you would see as a plus over Scala or Haskell?

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 `_`).

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.

Just use VS Code + Ionide. That's where the action is for at least for F# + .NET Core

It's misleading to pretend that it's a substitute for full Visual Studio.

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

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.

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

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.

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

I'm sorry, but what you're saying is factually incorrect. Can you please update your comment so as not to spread misinformation?

Updated with the blog quote.

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.

If the issues faced by your team were related to C# I assume management would have taken other path.

And this is the reason why none of our customers wants to even discuss integrating F# into C# projects.

Perhaps it's worth taking a different viewpoint. With VS 2017, no single release updates every part of the product to the latest things. For example, UWP does not support .NET Standard 2.0 yet. That did not put the VS 2017 15.3 release on hold. Similarly, although F# fully supports .NET Core and .NET Standard 2.0 with this release, the tooling quality wasn't high enough for us to declare the associated tooling support in VS as fully supported. That also did not put the VS 2017 15.3 release on hold. This because we're already three updates into Visual Studio, and it's only been 6 months since its release. Visual Studio updates faster and teams can release things easier and more rapidly without needing to wait for everything else. This is a really good thing.

Point taken, but apparently Microsoft employees keep forgeting F# is part of .NET, or isn't EditorConfig at all relevant for F#?

https://docs.microsoft.com/en-us/visualstudio/ide/editorconf...

This, and also VS2017 did in fact ship C# without some things (for instance, full support for value tuples).

This is minor compared to all the major things VS isn't shipping for many years in a row now.

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

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.

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

We blogged about their experience, and they do have practical examples there.

Units of measure. So in C# you can do something like this (using floats for convenience):

    class Power {
      public static HoursUsed(
        float totalBillDlrs, float deviceWattage, float rateDlrsPerkWh) {
        return 1000.0 * totalBillDlrs / (deviceWattage * rateDlrsPerkWh);
      }
    }

Then call it like this:

    var totalBillDlrs = 10.95;
    var deviceWattage = 100.0;
    var rateDlrsPerkWh = 0.15;

    Power.HoursUsed(deviceWattage, totalBillDlrs, rateDlrsPerkWh);

But, oops! that was actually supposed to be:

    Power.HoursUsed(totalBillDlrs, deviceWattage, rateDlrsPerkWh);

In F# you can use units of measure to prevent this kind of thing at compile time:

    [<Measure>] type dollar
    [<Measure>] type watt
    [<Measure>] type kilowatt
    [<Measure>] type hour

    module Power =
      let hoursUsed
        (totalBill : float<dollar>)
        (deviceWattage : float<watt>)
        (rate : float<dollar/(kilowatt hour)>) : float<hour> =
        1000.0<watt/kilowatt> * totalBill / (deviceWattage * rate)

    let totalBill = 10.95<dollar>
    let deviceWattage = 100.0<watt>
    let rate = 0.15<dollar/(kilowatt hour)>

    // Compile error
    Power.hoursUsed deviceWattage totalBill rate

And, yes, in C# you can use things like named parameters to reduce the chances of something like this, but you can't eliminate it at compile time, which is what F# does.

How many times have you had the runtime exception

    AttributeError: 'NoneType' object has no attribute 'foo'

(or its equivalent in your favourite language)?

That's something addressed by static typing though. I'm pretty sure any dynamic language has that issue, functional or not.

It's fair to say that the boundaries of "functional programming" are pretty amorphous and I certainly didn't mean untyped functional programming. In any case, if you want to prevent null/None errors in a way that gives the programmer his/her own access to create similar new abstractions then you need

* sum types

* parametric polymorphism

* pattern matching

at which point you may as well also add

* first class functions

and then if you don't describe your language as "typed functional" then how do you describe it?

Is your programming language unreasonable? or, why predictability is important

http://fsharpforfunandprofit.com/posts/is-your-language-unre...

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

:(

Kafunk is great https://jet.github.io/kafunk/