Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider using fsprojects/fsharp-language-server as a starting point for LSP #361
I recently read on @Krzysztof-Cieslak twitter that he'll be working full-time on contract with MS for the next few months, and that one of the major focuses will be finishing the LSP implementation of FSAC. Congrats!
For one moment, let me try to convince you (@Krzysztof-Cieslak) to use https://github.com/fsprojects/fsharp-language-server as a starting point for your efforts:
I would be very happy to make @Krzysztof-Cieslak , @enricosada and any other maintainers of this repo admins on https://github.com/fsprojects/fsharp-language-server. I think you could very quickly port the features of FSAC that aren't in fsharp-language-server, such as the "type hints" that appear to the right of function definitions.
If I have failed to convince you of this proposal, there are several notable features of fsharp-language-server that it would still be worth trying to replicate in FSAC:
On the other hand, if I have succeed in convincing you to try to "adopt" fsharp-language-server and port the missing functionality from FSAC, just let me know who to add as maintainers
TLDR; Thanks for the suggestion, but no, we won't do this.
While I appreciate that https://github.com/fsprojects/fsharp-language-server exists and I welcome anyone wanting to work on the F# tooling, I don't think it provides advantages outweighing potential costs of such move. FSAC is a long-standing project (7 years old) that has been battle-tested by thousands of users on multiple different editors.
What you call "incidental complexity" it's usually not an incident - FSAC enhance what FCS does in every single feature - from simple tooltips including signature formatting and markdown formatting of documentation, through autocomplete doing the ordering, autocomplete of external symbols and inserting opens, making sure Attribute autocomplete doesn't insert unnecessary
Those features were created over the years, with hundreds of hours of work of different contributors. Moving away from FSAC is not "clean break". I rather see this as abandoning things that are not trivial to port, that are pretty well designed and what's most important for the users are working right now.
Also, I'd like once again (I've done this in Slack some time ago as far as I remember) address this "fsharp-lang-server is faster" point. Of course, it's faster, it does fewer things. Simple as that. As I've mentioned - FSAC is not just a thin layer of calling FCS, it does a lot of heavy lifting. As such, obviously, FSAC puts a lot more pressure on FCS reactor queue. In any complex system that's bottlenecked by single-threaded queue, you cannot judge the performance of a single feature. Because it's impacted by any other action that's happening right now in the server. And we do a lot of computing in the background, in fact, most from any F# editor that's on the market - code lenses, custom analyzers, linter, error reporting across files without saving, error reporting across projects without rebuilding projects, etc. All those features impact the general performance of any feature at any moment in time. Additionally as I've said before - for basically any feature we're doing some additional enhancements - ofc, simple autocomplete that's calling one function from FCS and mapping results is faster than the one that orders entries, uses entities cache to provide completions for not opened namespaces/modules, checks if we're in Attribute scope, and do other stuff. Especially type checking of the projects depending on current project to get cross-project errros without rebuilding solutution is something puting lot of pressure on reactor, and accidentally is something that VS is not doing.
Of course, FSAC performance is not perfect - but not beacuse LSP is somehow inharently better. Over the years performance was never huge point of focus for the FSAC maintainers, and I'm strongly sure that there are multiple low hanging friuts, easy to fix, that will imporve FSAC performance. Fortunatly, this is something Microsoft wants to help me with, so I expect improvements in this area over next few months. I think such performance focused work is a way forward rather than reimplementing same set of features in other projects and hoping that we won't have same performance problems.
Abandoning one project and moving to another is not only a technical question, nor it's the "let me know who to add as maintainers" problem, but it's also a thing impacting the community of given projects in general. FSAC is a long-standing project, with a decent amount of contributors that's been contributing for years. Those people know how to contribute, they know parts of the code base they created, they are experts in some particular niches. I'm the only one lucky (and this is just temporary state for me, so I understand them well) - all of them are doing this in their free time, they care about some particular functionalities, or they just want to help. Moving to another project is just an additional thing making their life more difficult - they'd need to learn new code base, they'd potentially need to port something they've already written to the project.
Thanks for writing such a detailed response! For what it’s worth, based on my experience traipsing through FSharp.Compiler.Service and the FSAC code about a year ago, I think you will be able to get the same performance with FSAC, even with all its features. My experience was that it’s a matter of calling FSharp.Compiler.Service in just the right order that makes its internal caches happy and then suddenly it goes really fast. The fsharp-language-server implementation might be a useful speed comparison for you once you turn your attention to performance—you should be able to get the exact same autocomplete times, for example. Good luck!
Thanks a lot @georgewfraser for the suggestion.
If we can share knowledge will be awesome, also if the two projects continue to exists as separate entities, because the issues are shared.
I think @Krzysztof-Cieslak has already explained really well what i think about it too, so i'll try answer about your points and my high level view of FSAC.
As a personal note about FSAC, my personal feeling and my effort as maintainer is:
That's what's important for me.
That mean we can put some enhancement/bugfix inside FSAC asap who seems accidental complexity, but we later refactor and extract to new libraries so easier to maintain (like with current effort of project system to
A single library like FCS cannot do everything (project system, F# info, additional features, different scenarios and integration with extenal tools), because will become too big to be maintained and entangled (difficult to reason about), so features are splitted in multiple libs. FSAC do the plumbing.
About architecture, the core layer is independent from the transport and api layer, to maintain IO mode (vim/emacs) and http (ionide) in parallel, making easier to add LSP now.
@georgewfraser your project is really interesting, every new solution helps improving the state of the art because we can share ideas, and try different approach.
I'll check the repo sources to see if we can reuse some of the code and pattern to speedup things later.
That's a good point.
That's really interesting, i really when community try different ways to fix the same solution, because all projects can benefit of it.
I'll check these thanks, the test suite is an area who helps a lot with maintenance.
I actually agree with @georgewfraser this is the approach we took with the tooling in Visual Studio for Mac. (back in the day it was xamarin studio) Some of the first work I did was to strip away some incidental complexity from FSAC originally 80% of the internals were also used by xamarin studio, rip out the parser, remove the cracker, remove json encoding etc. Basically remove all the bits that we had issues with. Last I checked in FSAC there were still some parts of what we removed still present, so this could be a good chance to do some internal clean up too.
We're considering cleanup and perf work as a part of the deliverables in our contract with @Krzysztof-Cieslak. However, we want to rebaseline performance and measurements after LSP support is in. Among other things, it changes how data is serialized to/from the FSAC process and VSCode, which means issues like #324 will now be different. How that shapes up is TBD, but it will be based on measurements before/after specific changes.