VS 2017 15.5 is released Lots of F# tooling improvements and .NET Core tooling
1 points · Open discussiondotnet
fsharp
F#2015–2026
dotnet / fsharp
fsharp
The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
41Distinct people
59Mentions
0Explicit recommenders
4.4KGitHub stars
What to know before exploring
What it is
The F# compiler, F# core library, F# language service, and F# tooling integration for Visual Studio
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- fsharp/fsharp · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year59 dated mentions
Observed mentions: 2015-01-14 17:42:32 UTC to 2026-05-14 14:09:36 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 3 | 9 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 2 | 0 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
The F# compiler, F# core library, and F# editor tools
You're invited to contribute to future releases of the F# compiler, core library, and tools. Development of this repository can be done on any OS supported by .NET.
You will also need .NET SDK installed from here, exact version can be found in the global.json file in the root of the repository.
Contributing
Quickstart on Windows
Build from the command line:
build.cmd
The build depends on an installation of Visual Studio. To build the compiler without this dependency use:
build.cmd -noVisualStudio
After it's finished, open either FSharp.slnx or VisualFSharp.slnx in your editor of choice. The latter solution is larger but includes the F# tools for Visual Studio and its associated infrastructure.
Quickstart on Linux or macOS
Build from the command line:
./build.sh
After it's finished, open FSharp.slnx in your editor of choice.
Documentation for contributors
The Compiler Documentation is essential reading for any larger contributions to the F# compiler codebase and contains links to learning videos, architecture diagrams, and other resources.
The same docs are also published as The F# Compiler Guide. It also contains the public searchable docs for FSharp.Compiler.Service component.
See DEVGUIDE.md for more details on configurations for building the codebase. In practice, you only need to run build.cmd/build.sh.
See TESTGUIDE.md for information about the various test suites in this codebase and how to run them individually.
Documentation for F# community
The F# Documentation is the primary documentation for F#. The source for the content is here.
The F# Language Design Process is the fundamental design process for the language, from suggestions to completed RFCs. There are also tooling RFCs for some topics where cross-community co-operation and visibility are most useful.
The F# Language Specification is an in-depth description of the F# language. This is essential for understanding some behaviors of the F# compiler and some of the rules within the compiler codebase. For example, the order and way name resolution happens are specified here, which greatly impacts how the code in Name Resolutions works and why certain decisions are made.
No contribution is too small
Even if you find a single-character typo, we're happy to take the change! Although the codebase can feel daunting for beginners, we and other contributors are happy to help you along.
Not sure where to contribute?
Look at the curated list of issues asking for help. If you want to tackle any of those, use the comments section of the chosen issue to indicate interest and feel free to ask for initial guidance. We are happy to help with resolving outstanding issues while making a successful PR addressing the issue.
The issues in this repository can have big differences in the complexity for fixing them.
Are you getting started? We do have a label for good first issues as well.
Per-build NuGet packages
7.0.40x series
FSharp.Compiler.Service 43.7.400-preview
<add key="fsharp-prerelease" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
8.0.10x series
FSharp.Compiler.Service 43.8.100-preview
<add key="fsharp-prerelease" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json" />
NOTE: Official NuGet releases of FCS and FSharp.Core are synched with SDK releases (on purpose - we want to be in sync). Nightly packages release to Azure feeds on every successful insertion.
Branches
These are the branches in use:
main
Almost all contributions go here.
Able to be built, installed and used in the latest public Visual Studio release.
May contain updated F# features and logic.
Used to build nightly VSIX (see above).
release/dev15.9
Long-term servicing branch for VS 2017 update 15.9.x. We do not expect to service that release, but if we do, that's where the changes will go.
release/dev17.x
Latest release branch for the particular point release of Visual Studio.
Incorporates features and fixes from main up to a particular branch point, then selective cherry-picks.
May contain new features that depend on new things or fixes in the corresponding forthcoming Visual Studio release.
Gets integrated back into main once the corresponding Visual Studio release is made.
F# language and core library evolution
Evolution of the F# language and core library follows a process spanning two additional repositories. The process is as follows:
Use the F# language suggestions repo to search for ideas, vote on ones you like, submit new ideas, and discuss details with the F# community.
Ideas that are "approved in principle" are eligible for a new RFC in the F# language design repo. This is where the technical specification and discussion of approved suggestions go.
Implementations and testing of an RFC are submitted to this repository.
License
This project is subject to the MIT License. A copy of this license is in License.txt.
Code of Conduct
This project has adopted the Contributor Covenant code of conduct to clarify expected behavior in our community. You can read it at CODE_OF_CONDUCT.
Get In Touch
Members of the F# Software Foundation are invited to the FSSF Slack. You can find support from other contributors in the #compiler and #editor-support channels.
Additionally, you can use the #fsharp tag on Twitter if you have general F# questions, including about this repository. Chances are you'll get multiple responses.
About F#
If you're curious about F# itself, check out these links:
What is F#
Get started with F#
F# Software Foundation
F# Testimonials
Contributors ✨
F# exists because of these wonderful people:
Made with contrib.rocks.
Read the full README on GitHubWhat Hacker News says
12 sourcesF# does not need UWP support since MS have allowed ["desktop bridge" apps](https://github.com/Microsoft/visualfsharp/issues/1096) (which may or may not signal the unofficial death of UWP...).
The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it.
F# will always come in second in the MS tooling wars.
Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.
In Build a web service with F# and .NET Core 2.0The post describes Facebook's motivation for their license, but personally, I don't care about their motivation, but about the fact that their license is anti-Open Source, anti-Free Software.
There's actually a big difference between the patents grant of a license like Apache 2.0 and FB's license and I quote (from Apache 2.0):
> "If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed"
In other words the patents grant and its revocation is made explicitly in the context of "The Work" being licensed. So you can still sue a company like F
Read the rest
acebook for unrelated projects and still be protected by the license.
By contrast Facebook's PATENTS license says that:
> "The license granted here under will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates ..."
Let me spell this out for you:
1. if Facebook infringes your IP, but you happen to use React, then you can't sue them without also risk infringing on their React-related IP and be counter-sued for it
2. their PATENTS creates a unidirectional relationship; when Facebook accepts your contributions, they are protected because MIT / BSD are said to have an "implicit patents grant" (which supposedly works in the US) due to the estoppel principle
Btw, Microsoft is taking steps to do what Facebook is doing as well. See for example how they are switching from Apache 2.0 to MIT and the disingenuous way they are communicating the change:
https://github.com/Microsoft/visualfsharp/issues/3440
But folks, this is not how Open Source or Free Software is supposed to work. When you release something as Open Source, you need to allow others to use your work as they wish (Freedom 0, or in OSI parlance, no discrimination against fields of endeavor).
Patent-encumbered software is NOT Open Source or Free Software.
On C# having had an incomplete ECMA specification always lagging behind and source code made available under an obscure, non-open-source, legally tainting license acting as a boobytrap for anything commercial DOES NOT count as open.
Even now they are being disingenuous about license changes, witness for example the leadership of this project changing license from Apache 2.0 to MIT and being obtuse about the licensing of patents or about reasoning, not explaining clearly the drawbacks of the change: https://github.com/Microsoft/visualfsharp/issues/3440
OpenJDK happened on May 8, 2007, that's 10 years ago and you've got companies like Red Hat and IBM collaborating on it. By comparison .NET Core was released 2016, so that's 9 years later.
And the JCP might be a farce as far as standardisation efforts are concerned, but at least you've got mu
Read the rest
ltiple companies participating.
I'm replying this because I'm getting tired of Microsoft's marketing campaigns on this forum.
UPDATE:
Btw I actually applaud Microsoft's open sourcing efforts, I see myself using .NET in the future and I'm actively using Visual Studio Code and TypeScript at the moment. They've got fine people there working on dev tools, they always had.
But then I also see them engaging in what's basically racketeering, threatening Android phone makers with patents (i.e. if you can't innovate, litigate), having potential for becoming one of the largest patent trolls ever. And I also see them breaking user privacy in Windows 10. Therefore my view of them is balanced, as a large organization the left hand doesn't know what the right does, etc.
I cannot love them and even though I may have forgiven them for their past attacks on Linux and the open web, I can't forget their past that easily. And before you mention Google, Apple, Facebook, or other media darlings, check my history to see that I'm consistently ranting about all of them and the malevolence of one does not excuse the rest.
What I'm saying is that "Microsoft changed" messages make me feel nausea because it's been a clear marketing campaign and people fell for it. Let their actions speak, applaud and reward them when they do good, but don't put them on a pedestal and don't do marketing for them without getting paid for it.
If it's going to be fixed this year, then why isn't it even on the official road map? https://github.com/Microsoft/visualfsharp/issues/2400
In Announcing .NET Core 2.0> After one year since has been flagged as WORKING ON IT , the support for .NET Native is not even in roadmap https://github.com/Microsoft/visualfsharp/issues/2400.
And see comments here
https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-start...
> There is no timeline for F# support on UWP. If you must use UWP for your workplace, then F# is not an option for you. We make no such claim that you can do this, though. If there is such a statement somewhere, please do let me know. I do not wish to mislead anyone.
>This is an interesting point:
>> Full tooling support, every single feature as VB.NET and C# have on Visual Studio.
> Is it your expectation that every programming language be supported across everything you can use in Visual Studio?
>> As for .NET Core, most of us on the enterprise hardly care about .NET Core beyond UWP, until
Read the rest
it gets feature parity with .NET Framework.
> I will challenge this position. Perhaps you’ve not seen .NET Core in your organization, but we’ve seen strong adoption and significant interest in the enterprise for .NET Core. And this also goes beyond Visual Studio tooling. Many enterprises have developer who wish to program on macOS and deploy to Linux machines. We’ve made that a priority for .NET Core, and F# is every bit as capable as C# on that front. This has also been a significant area of growth for C#, F#, and .NET as a whole.
And here
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> No further news or updates on F# Support for .NET Native. There is no affinity between .NET Native, .NET Core, or VS 2017. It's an orthogonal area.
> There are three options:
> Use UWP Bridge
> Deploy elsewhere than the Windows Store
> Use Fable + React Native
See also this comment from the F# creator Don Syme.
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> @KevinRansom My impression was that F# libraries would likely work immediately in UWP (not coreclr native code gen) if tail. was ignored. I think it's up to the UWP team though, not the Visual F# Tools team. It's not a compiler problem, it's a runtime problem.
> To be honest, it appears UWP is simply not implementing the .NET specs correctly - tail. has been in all editions of the ECMA 335 CLI Standard... Mind you, generics have also been in that standard, with no mention of "limits of 7 deep" or anything like that. I'm always somewhat surprised when I see adhoc limitations that incorrectly implement the ECMA standard - I really thought that was a standard which mattered.
Come on Microsoft, this is unacceptable, you're driving existing and potential valuable programmers away from your platform and F#.
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> I found this thread tonight while looking for information about how to build a UWP application using F# in Visual Studio Community 2017. I kept seeing lots of references to C# .NET and VB.NET for this purpose, but suspiciously F# was missing. Which made me curious:
>> ... CAN you build a Universal Windows Platform native application with F#?
> And then I found this thread. I now regret investing any time in examining F# as a future development platform for any purpose. I'll probably never pay attention to it again, and I worry about the sincerity of any of Microsoft's future developer endeavors.
F# is a mature fully .NET compliant Microsoft language, it should be expected and a high priority to get the .NET Native UWP (your main client application platform) to accept F# code.
Most people I know invested in F# with the expectation to target modern Windows without fuss and workarounds. And no, UWP Bridge and Fable + React Native are not acceptable solutions.
See also comments here https://blogs.msdn.microsoft.com/dotnet/2017/07/24/get-start...
> There is no timeline for F# support on UWP. If you must use UWP for your workplace, then F# is not an option for you. We make no such claim that you can do this, though. If there is such a statement somewhere, please do let me know. I do not wish to mislead anyone.
>This is an interesting point:
>> Full tooling support, every single feature as VB.NET and C# have on Visual Studio.
> Is it your expectation that every programming language be supported across everything you can use in Visual Studio?
>> As for .NET Core, most of us on the enterprise hardly care about .NET Core beyond UWP, until it gets feature parity with .NET Framework.
> I will challenge this position. Perhaps you’ve not seen .NET Core in your organization, but we’ve seen strong adoption
Read the rest
and significant interest in the enterprise for .NET Core. And this also goes beyond Visual Studio tooling. Many enterprises have developer who wish to program on macOS and deploy to Linux machines. We’ve made that a priority for .NET Core, and F# is every bit as capable as C# on that front. This has also been a significant area of growth for C#, F#, and .NET as a whole.
And here
https://github.com/Microsoft/visualfsharp/issues/1096#issuec...
> No further news or updates on F# Support for .NET Native. There is no affinity between .NET Native, .NET Core, or VS 2017. It's an orthogonal area.
> There are three options:
> Use UWP Bridge
> Deploy elsewhere than the Windows Store
> Use Fable + React Native
Come on Microsoft, this is unacceptable, you're driving valuable programmers away from your platform.
F# is a mature fully .NET compliant Microsoft language, it should be expected and a high priority to get the .NET Native UWP (your main platform) to accept F# code.
Most people I know invested in F# with the expectation to target Windows without fuss and workarounds. And no, UWP Bridge and Fable + React Native are not acceptable solutions.
After so many years, still no .NET Native nor proper UWP support for F#
1 points · Open discussionMy team switched an entire application from C# (~350k loc) to F# (~30k loc). Smaller team, smaller code base, fewer bugs, complete implementation of requirements, clearer code. The whole of the F# code base was less than the number of blank lines in the C# code base and a lot more fun to read and write.
https://github.com/Microsoft/visualfsharp/issues/2766#issuec...
In Ask HN: When has switching the language/framework made an important difference?Author of the article here. Happy to see this up on HN!
The article is actually more of an annotated version of the F# Tutorial Script[0] which ships inside Visual Studio 2017 (also in other version of Visual Studio, but the Tutorial script is a bit different there).
You can get started with F# just about everywhere everywhere:
* Visual Studio[1]
* Visual Studio for Mac[2]
* Visual Studio Code (via Ionide plugins)[3]
* .NET Core and the .NET CLI (`dotnet new console -lang F#`)[4]
* Azure Notebooks (Jupyter in the browser via Azure) [5]
[0]: https://github.com/Microsoft/visualfsharp/blob/master/vsinte...
[1]: https://www.visualstudio.com/vs/visual-studio-2017-rc/
[2]: https://www.visualstudio.com/vs/visual-studio-mac/
[3]: https://marketplace.visualstudio.com/items?itemName=Ionide.I...
[4]: https://dot.net/core
[5]: https://notebooks.azur
Read the rest
A few things still need to be ironed up.
Expect full support around .NET Core 2.0 time.
https://github.com/Microsoft/visualfsharp/issues/2400
In Getting Started with Functional Programming in F#