4 ms·

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose a

by d--b 9y ago

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing doesn't feel FP ish at all. You often need to implement classes with interfaces to interact with C#'s core libraries.

phillipcarter 9y ago
> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.
- smithkl42 9y ago
  It's the "Go to Definition" and "Find all References" pieces that are so annoying to me, and slow me down tremendously. It means that (practically) you have to do your whole solution in one language for it to feel like a unified solution, and that makes it hard to start by bolting an F# project onto an existing solution.
- smithkl42 9y ago
  And FWIW, I remember complaining about this to Don Syme something like 5+ years ago, and while he gave lip service to the idea that F# needed better tooling (and better tooling interop with C# specifically), I don't think he was really convinced.
- d--b 9y ago
  You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.
  - phillipcarter 9y ago
    > You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). This is actually added in F# tooling for VS 2017! Both via a lightbulb code fix and with IntelliSense itself. If you have a reference to a .dll with symbols, the IDE can suggest an open statements for you.
brianberns 9y ago
I hardly think the lack of a cross language usage reference means that you lose all the benefits of static typing. I don't see F# as primarily a scripting language at all. It builds executables just as well as C# does. F# and C# classes are very compatible, since they're both .NET. If you expose F#-only features (e.g. currying), then obviously C# isn't going to be able to use your API as well.
- d--b 9y ago
  It just adds up, and right now the combination of these annoyances outweighs the benefits of using F# for me.
  - brianberns 9y ago
    This is how my C# developers feel as well. Personally, I've concluded that F# is a more reasonable language than C#, so I see these "annoyances" as challenges that are not a big problem.
    - bonesss 9y ago
      Miguel de Icaza commented on a trend they've seen with the C# devs on Mono/Xamarian that matches well with my experience: the C# devs who start using F# simply do not come back. F# is the first language built on top of a mature .Net framework, and it shows. Much of what has made C# become so great was pushed through the F# research group (remember when C# didn't have generics?... yeah...). It is not Microsofts favorite child. It will never be the implementation language of MS's next GUI platform du jour. Personally, looking at old XAML, Silverlight, EF1, EF2, EF3, EF4, EF5, and EF6 projects... [oh hey, EF7 is out, and it _still_ has no second level cache story! Back to NHibernate everybody!... again!] ... I do not think it's a bad thing to have some distance between production and Microsofts first-run attempts at products.
mevile 9y ago
This is what I agree with. I would love to write F#, I write Haskell on Windows, I love functional programming, but jesus the tooling around F# is broken, at least for someone not familiar with it. I can write, compile and run a small example program in C# or C++ in visual studio in minutes, but last I tried, even after spending half a day looking through how to get it done, I couldn't get the F# tooling to work for me. It just didn't seem worth exploring further to me at that point.
- phillipcarter 9y ago
  Could you clarify what you had problems with? F# comes with Visual Studio (and VS for Mac), has templates, and builds/runs/debugs/etc out of the box. No need to configure beyond checking "F# language support" in the installer for VS 2017 (and in some cases, the Workloads in that installer come with F# already-checked).
  - mevile 9y ago
    Thank you, that was a really helpful comment! That seems to have been the problem. I had Visual Studio installed already and I just reran an installer and that gave me the option to install F#. That I needed to run the installer for visual studio again, that I couldn't just install F# support some other way, that just wasn't clear to me. I have to say that messing around in visual studio in F# just now was extremely painful. I had to press shift+enter to add a new line, just enter did nothing. Tab didn't indent. I don't know what indents. I don't know what key does the job backspace is supposed to do (delete the previous character). I don't really understand why everything is so hard. I don't have this problem with Visual Studio C++ files. O_o To be honest I'd prefer using VS Code to write F# and build from the command line, do you know of any good getting started guides? I'll check the VS Code extension documents, maybe now that I have it working in VS Code this will be easier. Thank you for your help so far!
    - phillipcarter 9y ago
      You're welcome! The bug you're experiencing is known and fixed (both in nightlies and a servicing fix). VSCode and F# is a great experience! We have some guides about how to get started with F# here: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/

by d--b 9y ago

phillipcarter 9y ago

> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.

smithkl42 9y ago
It's the "Go to Definition" and "Find all References" pieces that are so annoying to me, and slow me down tremendously. It means that (practically) you have to do your whole solution in one language for it to feel like a unified solution, and that makes it hard to start by bolting an F# project onto an existing solution.
smithkl42 9y ago
And FWIW, I remember complaining about this to Don Syme something like 5+ years ago, and while he gave lip service to the idea that F# needed better tooling (and better tooling interop with C# specifically), I don't think he was really convinced.
d--b 9y ago
You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.
- phillipcarter 9y ago
  > You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). This is actually added in F# tooling for VS 2017! Both via a lightbulb code fix and with IntelliSense itself. If you have a reference to a .dll with symbols, the IDE can suggest an open statements for you.

brianberns 9y ago

I hardly think the lack of a cross language usage reference means that you lose all the benefits of static typing. I don't see F# as primarily a scripting language at all. It builds executables just as well as C# does. F# and C# classes are very compatible, since they're both .NET. If you expose F#-only features (e.g. currying), then obviously C# isn't going to be able to use your API as well.

d--b 9y ago
It just adds up, and right now the combination of these annoyances outweighs the benefits of using F# for me.
- brianberns 9y ago
  This is how my C# developers feel as well. Personally, I've concluded that F# is a more reasonable language than C#, so I see these "annoyances" as challenges that are not a big problem.
  - bonesss 9y ago
    Miguel de Icaza commented on a trend they've seen with the C# devs on Mono/Xamarian that matches well with my experience: the C# devs who start using F# simply do not come back. F# is the first language built on top of a mature .Net framework, and it shows. Much of what has made C# become so great was pushed through the F# research group (remember when C# didn't have generics?... yeah...). It is not Microsofts favorite child. It will never be the implementation language of MS's next GUI platform du jour. Personally, looking at old XAML, Silverlight, EF1, EF2, EF3, EF4, EF5, and EF6 projects... [oh hey, EF7 is out, and it _still_ has no second level cache story! Back to NHibernate everybody!... again!] ... I do not think it's a bad thing to have some distance between production and Microsofts first-run attempts at products.

mevile 9y ago

This is what I agree with. I would love to write F#, I write Haskell on Windows, I love functional programming, but jesus the tooling around F# is broken, at least for someone not familiar with it. I can write, compile and run a small example program in C# or C++ in visual studio in minutes, but last I tried, even after spending half a day looking through how to get it done, I couldn't get the F# tooling to work for me. It just didn't seem worth exploring further to me at that point.

phillipcarter 9y ago
Could you clarify what you had problems with? F# comes with Visual Studio (and VS for Mac), has templates, and builds/runs/debugs/etc out of the box. No need to configure beyond checking "F# language support" in the installer for VS 2017 (and in some cases, the Workloads in that installer come with F# already-checked).
- mevile 9y ago
  Thank you, that was a really helpful comment! That seems to have been the problem. I had Visual Studio installed already and I just reran an installer and that gave me the option to install F#. That I needed to run the installer for visual studio again, that I couldn't just install F# support some other way, that just wasn't clear to me. I have to say that messing around in visual studio in F# just now was extremely painful. I had to press shift+enter to add a new line, just enter did nothing. Tab didn't indent. I don't know what indents. I don't know what key does the job backspace is supposed to do (delete the previous character). I don't really understand why everything is so hard. I don't have this problem with Visual Studio C++ files. O_o To be honest I'd prefer using VS Code to write F# and build from the command line, do you know of any good getting started guides? I'll check the VS Code extension documents, maybe now that I have it working in VS Code this will be easier. Thank you for your help so far!
  - phillipcarter 9y ago
    You're welcome! The bug you're experiencing is known and fixed (both in nightlies and a servicing fix). VSCode and F# is a great experience! We have some guides about how to get started with F# here: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/ https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/