7 ms·

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at odds with open-source, functional languages. They are used to producing codebases that can never be open-sourced, using tooling provided by a single vendor. They don't tend to be the ones contributing interesting or new libraries. In fact, this is a large issue with .NET in general. Most strong libraries are spiritual or literal copies of something from the JVM world. This urge hurts in other ways. For instance, Don Syme has indicated he doesn't want to put things like Type Classes or Dependent types into the language because it adds a cognitive load to the language that's hard to balance vs the gains in productivity. But their absence means that many of the dev's you actually want contributing to the ecosystem, just use other languages. They adopt Haskell/Idris/Scala/whatever and start contributing blog posts, tweets, libraries, conference talks, etc. I actually think a large part of this decision is that many of these things would make F# pretty incompatible with C#, which is trumpeted as a feature, but again, it waters down the language to the point that C# dev's look at it and say, "Why bother? It's compatible like VB is, so C# can already accomplish the same things." And in the meantime, it prevents new features that would attract others. What sounds more enticing to developers, "More Functional C#" or "Haskell With Better Tooling"? What's more, there are even examples of how some of these features could be implemented (both Type Classes and Dependent Typing exist in some capacity through feature requests and F*, an experimental Microsoft language). Basically, F# should be more about being different than the rest of .net, than trying to be ".net through an OCaml set of glasses".

throwaway7645 9y ago
Yes...F# for a non C# dev is a major pain.
rubber_duck 9y ago
I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. Functional programming is also seeping in but again tons of boiler plate. Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.
- brianberns 9y ago
  C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.
  - rjbwork 9y ago
    Does the F# SQL type provider integrate with the .sqlproj database projects that are in the solution, or do you have to have an actual running SQL database?
    - brianberns 9y ago
      It needs a connection string to a real database. http://fsprojects.github.io/FSharp.Data.SqlClient/ http://fsprojects.github.io/FSharp.Data.SqlClient/
  - mbenoni7 9y ago
    There's a new type provider out that takes a different approach by bundling a SQL parser: https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL It can't check everything that the other providers can, but IMO you get most of the benefit without requiring any onerous build-time dependencies.
    - brianberns 9y ago
      Very cool. Thank you.
  - ice109 9y ago
    that kind of thing is a collosal mistake in my opinion - just on the face of it I/o at compile time seems very wrong.
    - brianberns 9y ago
      Why? Compilers have to read source files anyway. What's wrong with reading other stuff as well? For example, there are type providers for XAML, JSON, app.config, etc. Do they also seem wrong to you?
platz 9y ago
Type Classes, yes. Dependent types, eh.. that is a bit of a stretch to say the least.
macca321 9y ago
I think a better approach is encouraging the use of functional/F# concepts in C#.
- louthy 9y ago
  I take this approach in my language-ext project [1]. I wrote it because as well as wanting to use F#, I had a decade old C# project to maintain, and I wanted to bring functional techniques into. We're (my team) finding that the pull to to F# is diminishing quite significantly; this is partly due to the functional framework features I've added to lang-ext; partly the new features of C# (expression bodied members, tuples, etc.), and majorly the relatively poor tooling. This is not some desire for ReSharper in F#, it's basic stuff like compilation speed, the amount of time it takes for the red-squiglys to turn up (lulling one into a false sense of security), build issues: I have a C#->F#->C# dependency graph in a new satellite project I'm working on. If I change the root C# project then the F# project won't re-build/link, then at runtime I'll get errors that the F# DLL expected a function or type to exist that I'd removed from the C# one. And the absolute classic about the necessity for ordering files in the project in dependency order... I get that this reduces cyclomatic complexity, and that's laudable, but it's just a pain once a project gets to a reasonable size. For my open-source projects I had to drop F# APIs from the projects because I couldn't create net451 and netstandard1.X project files that would build, pack, and be deployable to nu-get. Also the interop story between C# and F# really isn't that good. Even though it's shouted from the rooftops as a main selling point. Everything prefixed with FSharp is ugly, FSharpFunc can't implicitly convert to Func, FSharpOption evaluates to null for None, so you get none of the safeness in C#, FSharpAsync is reeeaaally difficult to consume from C#, etc. This means we have to build an interop layer and that always feels like needless effort. It would be much better if there was some tooling support that could create proxies between the F# and C# worlds. It always feels like there's something in the way. And the way of human inertia is that those seemingly minor niggles will tend to put people off full-scale adoption. I love F# as a language (well, not its OO grammar, but I don't use that), but C# + language-ext actually gives me pretty much everything I need (bar ADTs). [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
  - 9y ago
d--b 9y ago
I don't think that's correct. I think the main strength of F# lies in its interoperability with C#. Basically C# and F# are 2 different languages that are good at solving different problems, and are mastered by different people. C# is a solid infrastructure language. F# is a good business modeling language. What I think is best about F#/C# is to have data scientists / mathematicians work in a language and have infrastructure people work in another one, and yet have those 2 languages interoperate well. The main issue for me is that they don't actually interoperate very well... If F# is pushed too far from C#, what's the point? Just use Haskell...
- yawaramin 9y ago
  > If F# is pushed too far from C#, what's the point? Just use Haskell... But you said it yourself: > I think the main strength of F# lies in its interoperability with C#.
DeepRote 9y ago
Incredibly well-spoken. I've even had devs ask me if we can use Scala instead after a couple days!
- corn_dog 9y ago
  Well can they? :) F# is ok but using it makes me really appreciate scala.
  - DeepRote 9y ago
    I mean they can but we won't get paid if our megacorp overlords don't get their .NET drivel.
jackmott 9y ago
I am a C# developer who works on a closed source enterprise app at work. I have contributed to the F# core libs and created an open source F# library.
- yawaramin 9y ago
  Have you floated the idea of writing some parts of your app in F#? How did that go over?

throwaway7645 9y ago

Yes...F# for a non C# dev is a major pain.

rubber_duck 9y ago

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. Functional programming is also seeping in but again tons of boiler plate. Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.

brianberns 9y ago
C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.
- rjbwork 9y ago
  Does the F# SQL type provider integrate with the .sqlproj database projects that are in the solution, or do you have to have an actual running SQL database?
  - brianberns 9y ago
    It needs a connection string to a real database. http://fsprojects.github.io/FSharp.Data.SqlClient/ http://fsprojects.github.io/FSharp.Data.SqlClient/
- mbenoni7 9y ago
  There's a new type provider out that takes a different approach by bundling a SQL parser: https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL It can't check everything that the other providers can, but IMO you get most of the benefit without requiring any onerous build-time dependencies.
  - brianberns 9y ago
    Very cool. Thank you.
- ice109 9y ago
  that kind of thing is a collosal mistake in my opinion - just on the face of it I/o at compile time seems very wrong.
  - brianberns 9y ago
    Why? Compilers have to read source files anyway. What's wrong with reading other stuff as well? For example, there are type providers for XAML, JSON, app.config, etc. Do they also seem wrong to you?

platz 9y ago

Type Classes, yes. Dependent types, eh.. that is a bit of a stretch to say the least.

macca321 9y ago

I think a better approach is encouraging the use of functional/F# concepts in C#.

louthy 9y ago
I take this approach in my language-ext project [1]. I wrote it because as well as wanting to use F#, I had a decade old C# project to maintain, and I wanted to bring functional techniques into. We're (my team) finding that the pull to to F# is diminishing quite significantly; this is partly due to the functional framework features I've added to lang-ext; partly the new features of C# (expression bodied members, tuples, etc.), and majorly the relatively poor tooling. This is not some desire for ReSharper in F#, it's basic stuff like compilation speed, the amount of time it takes for the red-squiglys to turn up (lulling one into a false sense of security), build issues: I have a C#->F#->C# dependency graph in a new satellite project I'm working on. If I change the root C# project then the F# project won't re-build/link, then at runtime I'll get errors that the F# DLL expected a function or type to exist that I'd removed from the C# one. And the absolute classic about the necessity for ordering files in the project in dependency order... I get that this reduces cyclomatic complexity, and that's laudable, but it's just a pain once a project gets to a reasonable size. For my open-source projects I had to drop F# APIs from the projects because I couldn't create net451 and netstandard1.X project files that would build, pack, and be deployable to nu-get. Also the interop story between C# and F# really isn't that good. Even though it's shouted from the rooftops as a main selling point. Everything prefixed with FSharp is ugly, FSharpFunc can't implicitly convert to Func, FSharpOption evaluates to null for None, so you get none of the safeness in C#, FSharpAsync is reeeaaally difficult to consume from C#, etc. This means we have to build an interop layer and that always feels like needless effort. It would be much better if there was some tooling support that could create proxies between the F# and C# worlds. It always feels like there's something in the way. And the way of human inertia is that those seemingly minor niggles will tend to put people off full-scale adoption. I love F# as a language (well, not its OO grammar, but I don't use that), but C# + language-ext actually gives me pretty much everything I need (bar ADTs). [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- 9y ago

d--b 9y ago

I don't think that's correct. I think the main strength of F# lies in its interoperability with C#. Basically C# and F# are 2 different languages that are good at solving different problems, and are mastered by different people. C# is a solid infrastructure language. F# is a good business modeling language. What I think is best about F#/C# is to have data scientists / mathematicians work in a language and have infrastructure people work in another one, and yet have those 2 languages interoperate well. The main issue for me is that they don't actually interoperate very well... If F# is pushed too far from C#, what's the point? Just use Haskell...

yawaramin 9y ago
> If F# is pushed too far from C#, what's the point? Just use Haskell... But you said it yourself: > I think the main strength of F# lies in its interoperability with C#.

DeepRote 9y ago

Incredibly well-spoken. I've even had devs ask me if we can use Scala instead after a couple days!

corn_dog 9y ago
Well can they? :) F# is ok but using it makes me really appreciate scala.
- DeepRote 9y ago
  I mean they can but we won't get paid if our megacorp overlords don't get their .NET drivel.

jackmott 9y ago

I am a C# developer who works on a closed source enterprise app at work. I have contributed to the F# core libs and created an open source F# library.

yawaramin 9y ago
Have you floated the idea of writing some parts of your app in F#? How did that go over?