Hacker News Reader

Comment by rattray | Hacker News Reader

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?

View on HN

There is iodide for vscode. http://ionide.io

JetBrains Rider also supports it.

Fantomas can be used as a formatter. https://github.com/fsprojects/fantomas

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.

There’s F# language server, which is not as featureful as ionide but a lot faster.

ahh interesting. I'm actually using Rider for most of my work

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.

Rider’s overeager analysis of symbols has been bugging me too, but the latest previews seem to behave a little better

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

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.

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

We collaborate with the Rider folks quite a lot and so they'll see this if it is indeed a Rider issue.

> 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

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.

Reply on news.ycombinator.com