F# 9

[vzarytovskii]

Soon, we will start to plan for F# 9, and as an experiment, for better visibility, I have created a project section for everything we want to do in F#9/.NET9: https://github.com/orgs/dotnet/projects/126/views/40

Please, keep in mind that:

a. It is experimental, might not work for us in longer term. We will figure it out as we go.
b. It doesn't yet contain all of the buckets we work on, and definitely doesn't have all of the work items created.
c. Completed items will be archived eventually by the automation due to projects limitation, we will try to keem tracking issues up-to-date and there will be a query for all the items.

[Happypig375]

Reason: fsharp/fslang-design#749

[SchlenkR]

That sounds very interesting. Thanks for that experiment @vzarytovskii. I'm curious!

[NatElkins]

Out of curiosity, is there any particular methodology used to determine which features get prioritized for dev time?

[vzarytovskii]

Out of curiosity, is there any particular methodology used to determine which features get prioritized for dev time?

I wouldn't say some particular one.

For language features - ones which are approved, and objectively more desired/helpful/missing.
For tooling - feature gaps, bugfixes, investment into future dev time (like with LSP or analyzers).
For performance and stability - not really, mostly, if it improves things - we want it in.
There's also bugs - we try to see what are they affecting, is there a workaround, how hard is it to fix/rever, etc.

Overall across categories - on the planning we try to see what's the dev estimation vs how useful the feature is vs what people want to work on.

[NatElkins]

Is there a best way to "vote" on a particular issue? My top two would be Hot Reloading (at least the infra for it, not necessarily the support for each EnC feature--community can help with that) or support for source generators. The former is currently the most 👍 'd open issue in this repo.

[vzarytovskii]

Is there a best way to "vote" on a particular issue? My top two would be Hot Reloading (at least the infra for it, not necessarily the support for each EnC feature--community can help with that) or support for source generators. The former is currently the most 👍 'd open issue in this repo.

We are considering votes when planinng, however there are other factors at play, unfortunately. Like dependecies or other work or fixes. Both hot reload and source generators are huge tasks (can't emphasize it enough), and both of them require some prior work to be done.

For example, for hot reload, we will likely need to dip into project loading (which we currently don't do and rely on project system) as well as some "incremental" and "dynamic" compilation (which is currently being worked on as part of expression evaluator work).

For the source generators, it would be integration with roslyn from the FSharp.Build and keeping up to date, and as far as I know, there will be some changes to how things work with generators (new version?), so we didn't really invest much in it, since things can change.

To recap - voted and popular features not being actively worked on mostly because of how complex they are and how many dependencies they have (essentially blockers).

[Happypig375]

yo my issue is already the most successful one

[NatElkins]

Got it, thanks for the reply.

For example, for hot reload, we will likely need to dip into project loading (which we currently don't do and rely on project system) as well as some "incremental" and "dynamic" compilation (which is currently being worked on as part of expression evaluator work).

Is this the main ticket tracking EE work?

[vzarytovskii]

Got it, thanks for the reply.

For example, for hot reload, we will likely need to dip into project loading (which we currently don't do and rely on project system) as well as some "incremental" and "dynamic" compilation (which is currently being worked on as part of expression evaluator work).

Is this the main ticket tracking EE work?

Yeah

[Thorium]

Is there a reason to push major versions? Is F# 9 incompatible with F# 8? Why not F# 8.1?
Is it business push? Just to be aligned with .Net versions?

I find it hard to maintain current systems just because all the dlls shift versions with .Net and there is no migration guides, nor proper release notes, so you never know is there actual breaking changes or is it just business managers wanting to bump vesions.

Also all the tools like Paket, always complains. What amount of work for virtually nothing.

F# 3 had TypeProviders etc (major), F# 4 and 5...hmm why? (minor?), F# 6 had task{} and structs (major) but they actually started to work on F# 7 (minor?).

[vzarytovskii]

Is there a reason to push major versions? Is F# 9 incompatible with F# 8? Why not F# 8.1?

There can be additional warnings and parser changes between versions, but generally we try to not introduce "incompatibilities".

Is it business push? Just to be aligned with .Net versions?

It's our versioning strategy, we increase it with every major release (once a year). If we release in between, we increase a minor one and make it default.

I find it hard to maintain current systems just because all the dlls shift versions with .Net and there is no migration guides, nor proper release notes, so you never know is there actual breaking changes or is it just business managers wanting to bump vesions.

Also all the tools like Paket, always complains. What amount of work for virtually nothing.

I don't understand these points. Language version updates by itself if not pinned in project settings. There's nothing to "update". Each language version maps to set of features or changes, and is default for specific compiler in specific SDK.

DLL version are auto-incremented.

We don't plan to make any changes to it.

[baronfel]

@Thorium I wanted to make sure you know about the Breaking changes docs pages that we have for each major version - each feature area records changes there, and they are updated over the course of the release.

I highly encourage anyone updating to skim those before updating their tooling.

[smoothdeveloper]

@Thorium

Also all the tools like Paket, always complains. What amount of work for virtually nothing.

the work needed on paket is pretty limited to support new major SDK release, orthogonal with the language and target runtime versions, and is generally done upfront.

Beside the psychological block to use a pre release version in case the stable release didn't get updated after support of new sdk, I don't see much hurdle.

But yes, overall, new SDK every year means lots of global.json, .config/dotnet-tools.json everywhere in the world, and there are some implications with users of the FAKE runner and whoever work on F# tooling at large (consumers of FCS, etc.).

Things are getting smoother over time though, and I think it is still not much work compared to churn of shipping dotnet itself, and delivering so much goodness :)

See a note about paket: https://github.com/fsprojects/Paket/blob/5b7b088121f08b2c14a02d42551f754f1877bd87/DEV_GUIDE.md#updates-to-support-new-major-sdk-releases and in case you have an issue with dotnet sdk 9 not being supported before anyone else reports, feel free to open the issue.

[voronoipotato]

@vzarytovskii should we update https://github.com/dotnet/docs/blob/main/docs/core/whats-new/dotnet-9/overview.md with the relevant changes?

[vzarytovskii]

@vzarytovskii should we update dotnet/docs@main/docs/core/whats-new/dotnet-9/overview.md with the relevant changes?

Probably not just yet, we're still wrapping things up