5 ms·

Wow, I remember learning about F# and thinking, "too bad it's stuck on Windows, I'll never use it". Awesome to hear that .NET Core has really changed that. How

Wow, I remember learning about F# and thinking, "too bad it's stuck on Windows, I'll never use it". Awesome to hear that .NET Core has really changed that. How is the incremental typechecking experience, eg in vscode? (Speed, UX) Does F# have a prettier implementation or other fast/deterministic/opinionated formatter?

JaggerJo 6y ago
There is iodide for vscode. http://ionide.io http://ionide.io JetBrains Rider also supports it. Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas
- davidspiess 6y ago
  Ionide is not quite there yet when it comes to medium/big sized projects. I switched back to Visual Studio because Ionide simply stops working after a while. Even switching branch requires you restart VSCode. So be aware of that. Fantomas comes already bundled with Ionide and works pretty well. Has a few hick ups here and there as well.
  - georgewfraser 6y ago
    There’s F# language server, which is not as featureful as ionide but a lot faster.
    - JaggerJo 6y ago
      ahh interesting. I'm actually using Rider for most of my work
madarcho 6y ago
We use Rider (enterprise license) to develop our F# services. Over the past year, the experience kept improving, small tweaks kept coming, and bugs were sorted out. At the moment, some of our larger shared type definition files are a slow to edit (seems Rider/.net is trying like crazy to look over all the symbols before I've even finished typing), but overall, I had a very good experience with it. Not aware of any linters out there. Rider might have built in rules to enforce it, but that wouldn't hook into your CI/CD.
- jkulubya 6y ago
  Rider’s overeager analysis of symbols has been bugging me too, but the latest previews seem to behave a little better
- phillipcarter 6y ago
  Roughly how large of a file and how slow to edit? Although there are some aspects to performance that are Rider-specific, it uses the same underlying compiler to deliver tooling. So some issues might be solvable at a more core layer. Disclaimer: I work on F# at Microsoft
  - madarcho 6y ago
    Our setup is multiple solutions for each service, and most inherit from "Core" parts. This type def file is about 1000 lines (can't count the number of declarations in there). What seems to happen consistently: I can delete a label in a type record, no lag. As soon as I finish adding a label (haven't added its type yet), all matter of slow hell breaks loose and there is a 5 second delay before anything shows up. This happens regardless of whether or not the type is used in a low (<20) or high (>100) number of places. The delay is the same in all records.
    - phillipcarter 6y ago
      Yeah, that's a rather large type definition We used to have some issues in the compiler in processing records that are 250 or more labels large, and can process ones with 1000 labels or more. But it's still a pain point, especially if it's generated, since those can get large pretty easily. The issue you're describing sounds more like a compiler/core tooling issue than a Rider issue though. Would you mind filing an issue here? https://github.com/dotnet/fsharp https://github.com/dotnet/fsharp We collaborate with the Rider folks quite a lot and so they'll see this if it is indeed a Rider issue.
StreamBright 6y ago
> How is the incremental type checking experience, eg in vscode? (Speed, UX) Pretty good. > Does F# have a prettier implementation or other fast/deterministic/opinionated formatter? It has something but I was not working on MacOS so we are not using it. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas
- Smaug123 6y ago
  Fantomas works on my Mac! My employer has been sponsoring work on Fantomas for a while now, and it's really improved by leaps and bounds over the last year. I'd recommend giving it another go.

JaggerJo 6y ago

There is iodide for vscode. http://ionide.io http://ionide.io JetBrains Rider also supports it. Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas

davidspiess 6y ago
Ionide is not quite there yet when it comes to medium/big sized projects. I switched back to Visual Studio because Ionide simply stops working after a while. Even switching branch requires you restart VSCode. So be aware of that. Fantomas comes already bundled with Ionide and works pretty well. Has a few hick ups here and there as well.
- georgewfraser 6y ago
  There’s F# language server, which is not as featureful as ionide but a lot faster.
  - JaggerJo 6y ago
    ahh interesting. I'm actually using Rider for most of my work

madarcho 6y ago

We use Rider (enterprise license) to develop our F# services. Over the past year, the experience kept improving, small tweaks kept coming, and bugs were sorted out. At the moment, some of our larger shared type definition files are a slow to edit (seems Rider/.net is trying like crazy to look over all the symbols before I've even finished typing), but overall, I had a very good experience with it. Not aware of any linters out there. Rider might have built in rules to enforce it, but that wouldn't hook into your CI/CD.

jkulubya 6y ago
Rider’s overeager analysis of symbols has been bugging me too, but the latest previews seem to behave a little better
phillipcarter 6y ago
Roughly how large of a file and how slow to edit? Although there are some aspects to performance that are Rider-specific, it uses the same underlying compiler to deliver tooling. So some issues might be solvable at a more core layer. Disclaimer: I work on F# at Microsoft
- madarcho 6y ago
  Our setup is multiple solutions for each service, and most inherit from "Core" parts. This type def file is about 1000 lines (can't count the number of declarations in there). What seems to happen consistently: I can delete a label in a type record, no lag. As soon as I finish adding a label (haven't added its type yet), all matter of slow hell breaks loose and there is a 5 second delay before anything shows up. This happens regardless of whether or not the type is used in a low (<20) or high (>100) number of places. The delay is the same in all records.
  - phillipcarter 6y ago
    Yeah, that's a rather large type definition We used to have some issues in the compiler in processing records that are 250 or more labels large, and can process ones with 1000 labels or more. But it's still a pain point, especially if it's generated, since those can get large pretty easily. The issue you're describing sounds more like a compiler/core tooling issue than a Rider issue though. Would you mind filing an issue here? https://github.com/dotnet/fsharp https://github.com/dotnet/fsharp We collaborate with the Rider folks quite a lot and so they'll see this if it is indeed a Rider issue.

StreamBright 6y ago

> How is the incremental type checking experience, eg in vscode? (Speed, UX) Pretty good. > Does F# have a prettier implementation or other fast/deterministic/opinionated formatter? It has something but I was not working on MacOS so we are not using it. https://github.com/fsprojects/fantomas https://github.com/fsprojects/fantomas

Smaug123 6y ago
Fantomas works on my Mac! My employer has been sponsoring work on Fantomas for a while now, and it's really improved by leaps and bounds over the last year. I'd recommend giving it another go.