Now we are close to shipping F# 4.0, what could we have done better

[KevinRansom]

Folks,

we are close to shipping F# 4.0, there have been eight previews since January 2015, and many when we were on CodePlex.

• We shipped two updates to Visual F# 3.1, in January 2014 and August 2014.
• We have opened up the compiler to community contributions
• We open sourced with community contributions the VS integration components
• We co-developed F# 4.0 with you the you using UserVoice CodePlex and GitHub
• We kept the community informed using GitHub, CodePlex and Twitter

How did we do? What did we do that you like? What did we do that you disliked? what should we do more of? and what should we do less?

Please keep this feedback focused on the process and our interactions, uservoice remains the right place for feature requests.

We would appreciate your feedback and help us to learn how to do a better job of working alongside you to create the tools that we all want to use.

Thank you

Kevin

[braden]

I think you did a great job listening (putting up with?) the community!

One thing I am not crazy about is Uservoice, it is another website to signup for and remember to check if people want to stay engaged. The voting model is sort of flawed (I used my votes ages ago and can't do anything now.) I think the way rust is handling their process with RFCs is really great - https://github.com/rust-lang/rfcs it is all on Github so contributors already have accounts / notifications set up and won't miss important updates. Using pull requests for proposals is great for collaboration as well, especially as things get more serious the amount of detail in the proposals gets fairly large.

Overall awesome job, things just keep getting better and better!

[TIHan]

You all have been doing amazing work. It's incredible to see how F# is evolving with the help of the community, especially with the help from you guys. You all have helped me, considerably.

I agree with @braden that the Uservoice isn't exactly great, but not bad. I wish I had more feedback; I need to be more involved.

Anyways, great stuff you all have been doing. The language and community are going to be growing from here on out.

[imfrancisd]

Note: This comment is made by someone who just started looking at F# recently.

I really wanted to see design discussions from the F# community regarding the new standard library functions for List, Sequence, and Array.

I saw these:

• https://github.com/fsharp/FSharpLangDesign/blob/master/FSharp-4.0/ListSeqArrayAdditions.md
• https://fslang.uservoice.com/forums/245727-f-language/suggestions/5663997-make-fsharp-core-collection-functions-for-list-ar

but I didn't really see much community input on how those functions should be defined.

Since some of the designs for those functions goes against this, this, and even this, I was surprised that I couldn't find discussions about the new functions from the F# community.

Note: I wanted to chime in, but since the F# community didn't complain, it didn't seem right for a person like me (who is not affected by the changes in the language and library) to complain.

[forki]

First of all: I'm absolutely happy with things are progressing with VF#. Accepting PRs and moving to github was an amazing step. Also the "one click build" and enabling CI made things so much better for us. Thanks for that and for your amazing work in general. I simply can't express how awesome this is, given the small VF# team size. You guys rock!

But since you asked about "what could have been done better", I have the following small suggestions:

• As already discussed, UserVoice is the place where feature requests go to die. I know this is one of reasons of why MS invented UserVoice ;-) - Please get rid of it. Seriously.
• Create more getting started docs/tutorials about "how to debug compiler/VS". Maybe show how you fix a small bug in a screencast.
• Try to make the discussion with other MS teams more transparent. Asp.Net + VS Code things are currently very confusing. Nobody knows anything specific. Of course this is more something that the other teams could do better, but somehow this needs to be addressed.
• Try to give more talks at conferences (and channel 9,..). I know this one is especially hard given the limited resources, but I hope the VF# could be a bit louder. You do awesome work and people need to see it (and see you guys) more.

Thanks for all.

[latkin]

@imfrancisd Thanks for the comment, we can always do better, and indeed I think more/deeper design discussion in the open would be a good thing. I can try to give some context --

Almost all of the "new" APIs were not new so much as "dedicated ports" - i.e. the API already existed for, say, Seq, and we just made an optimized, dedicated clone for Array and List with matching behavior. So the signatures and expected behaviors of the "new" APIs were for the most part already set long ago. For the few brand-new APIs that were added, there actually was a fair bit of discussion. (e.g. here, here), when it wasn't totally straightforward what the design should be. The main goal of this work was just to normalize the APIs across Array, List, and Seq, and part of that was to ensure uniform signatures and semantics across the board.

On partial functions - for most collections APIs X which can fail, F# also exposes a corresponding tryX API which returns an option type. e.g. List.head vs List.tryHead. We actually filled in the tryX guys more completely for F# 4.0, though there are admittedly still gaps (e.g. no 'tryTake, that probably should be added). The convention of exposing both (unsafe)Xand (safe)TryX` is in the .NET tradition. There is an argument that for F# the unsafe APIs should never have been written in the first place, but that's not something we can change now.

I'm not sure I understand the IEnumerable and truncate links. Many of the F# collection APIs are similar to LINQ IEnumerable APIs, but with signature or behavioral tweaks to make them more suited for F# consumption.

[imfrancisd]

@latkin

Thanks for the links.

It's not what the functions do that confuses me, but how the functions handle errors that confuses me.

take vs. truncate

I added the links to partial functions, Linq.Enumerable and Seq.truncate because the new truncate functions illustrates perfectly what I find confusing about the F# library for collections.

• Seq.take is not consistent with Linq.Enumerable.Take or even Haskell's take.
• Seq.truncate is Linq.Enumerable.Take (they're both total functions).
• The new List.truncate and Array.truncate throw on negative counts (at least from what I can tell from the source, doc comments, and tests since I can't compile it).

So, the new List.truncate and Array.truncate are inconsistent with .NET (Linq, C#, VB), inconsistent with languages like Haskell, and inconsistent with the F# library itself.

Why it's so confusing

When I read blogs and tweets about F#, the message I get is "F#: stronger than C#, second only to Haskell, and if the code compiles, it's probably right".

However, when I look at the library for collections, I see runtime errors instead of compile time errors. Instead of throwing errors, why not use unsigned numbers to begin with, or define the errors away.

Of course, there are other weird things like skip, windowed, zip3, and so on. What I see from List.truncate and Array.truncate just confuses me the most, and I just want to understand the reasoning behind it, or if other people are as confused about it as I am.

Note:

I just want to emphasize again that I'm new to F#, and a lot of this frustration is probably just part of learning a new language.

No offense intended.

[latkin]

take and truncate in F# are independent, semantically unique operations. What F# calls truncate happens to match what LINQ and Haskell call take. That is understandably a bit confusing, but it's just names at the end of the day, and each technology/language is free to name things however it likes. F# and Haskell both use map, while LINQ uses Select. F# and LINQ both use distinct whereas Haskell uses nub.

That the new Array.truncate and List.truncate behave differently wrt negative inputs than Seq.truncate is absolutely a bug. Thank you for bringing it up! I've opened #453 for this. Hopefully we haven't missed any other similar issues.

F# lands somewhere in the middle, by design - more functional, safer, and with a stronger type system than C#/Java, but more approachable and practical than Haskell/Idris. Ideally this represents some kind of "sweet spot", but naturally some would prefer it to be closer to one side or the other. You can trace much of the design to the need for strong .NET compatibility, and also to OCAML heritage.

We've probably hijacked this thread enough :sweat_smile: I would suggest opening an issue at https://github.com/fsharp/FSharpLangDesign for further conversation along these lines, or tweet at #fsharp and you will get plenty of people weighing in (mostly F# partisans :laughing:). Maybe a suitable topic of discussion at http://programmers.stackexchange.com/

[jackfoxy]

@KevinRansom and @latkin great job on github migration and everything else.

Yes, user voice is not ideal. Perhaps if there were some sort of dynamic roadmap planning and reporting tool that among other things could manage features, put them in categories (e.g. all type enhancements together), record user votes, status, etc., all in the context of what the F# team is doing and plans to do.

[dsyme]

I think @KevinRansom and @latkin have been doing an incredible job :)

As already discussed, UserVoice is the place where feature requests go to die.

This is not the case for the F# Language Design user voice. It is the place that I personally use to track F# language design items. I'm ok with it, at least so far. I'm sure it could be improved, but it suits my core needs as owner of language/core-library design+evolution well enough - a single place to gather wide-ranging ideas, votes and lightweight feedback from all-comers in a way that is relatively low-intensity and which I can go and look at in depth every month or two. I personally appreciate that fact that the medium don't demand immediate reaction (which from experience can eat into precious development resources). Evolving a language is not something to rush. Further, I'm very happy with the language/core-library evolution being separate from the tooling evolution.

Perhaps if there were some sort of dynamic roadmap planning and reporting tool....

I may as well take the chance to point out that the success of F# depends as much on upstack frameworks (cloud, web, data, mobile,...) and broad-spectrum tooling (cross-platform, multi-editor etc.) as the core language/library design and Visual F# tooling initiatives.

Upstack frameworks and broad-spectrum tooling involve many efforts by many different contributors. I'm all in favour of a roadmap for the Visual F# Tools team. However, this is just one part of the F# universe. I don't think it's possible to have an overall roadmap for the entire F# universe, since it would have to cover a single unified roadmap for all of FSharp.Compiler.Service, Xamarin, Emacs, Vim, Sublime, FsCheck, "fsprojects/*", MBrace, WebSharper, etc. Cooperation and alignment is needed, of course, and roadmaps for the various pieces are much appreciated.

Cheers Don

[KevinRansom]

Please keep the feedback coming. It is very enlightening.

[mastoj]

I really think you've done an awesome job. The only thing I miss is ASP.NET 5 supporting F#, but that is also on the ASP.NET team. Everyone that starts a web project today with ASP.NET 5 will most likely not choose F# since the work around is too problematic. This might slow down adoption since it is harder to be heard if it's not supported for web development in the future. I know there are suave and other framework, but I want to be able to use resources from the greater ASP.NET 5 community and not have a diverged web community where we do things our way when some problem already have been solved.

[dungpa]

You guys have done very well despite the limited resources.

I'll focus on what could be done better.

• Be more transparent in terms of plans and priorities. One may think that F# 4.0 contains whatever the contributors decided to work on. If there are coordinated efforts toward common goals (similar to the way standardized F# collections have been done), that would be great.
• Be more open to the PRs that improve the code base. You guys have been working on the code base for so long, you probably forget how painful it is. It would help contributors a lot if the code base is more readable thanks to the pending PRs such as https://github.com/Microsoft/visualfsharp/pull/357.
• Encourage contributions even in the lock down. Lock down for F# 4.0 is a good thing; that is where your priority should be at the moment. But you can still encourage people to contribute for vNext. Git flows make it so easy e.g. creating a new branch to accommodate new PRs. It keeps constant streams of new PRs and we can get going when F# 4.0 release is out of the door.

Thanks.

[ssagaert]

One thing in the F# 4.0 release I am disappointed about is that it is missing one big new killer feature like type providers in F# 3.0. Instead it's lots of little changes & polishing of existing features (also important of course). So to me it feels more like F# 3.2 rather than F# 4.0.

[dsyme]

@ssagaert - We've often said that F# 4.0 is as much about a cultural transition to open engineering processes as about language features. For us openness was more important and central to the release than anything else. The open process shows through in a lot of ways - e.g. the library functions added in F# 4.0 were a major piece of practically minded work, based extensively on co-design and co-development with the community. That work alone actually counts as a pretty big-ticket item, it's just of a particularly prosaic kind.

Speaking of which, I notice the list of F# 4.0 features on the Wikipedia page needs updating.

I'm actually not sure the "big new killer feature" model used by C# 2.0-5.0 (but not C# 6.0), F# 3.0 (but not F# 1.0, 2.0 or F# 4.0) will be so prevalent going forward in the languages. It may happen, of course, however it's a model that particularly suited the needs of a closed design process (e.g. when you needed to make a splash at "launch"). But it's not necessarily how you want to operate an open language design process - these typically use an RFC process, or at least an open proposal+discussion+vote+review-by-BDFL model as we do at http://fslang.uservoice.com.

Anyway, we chose F# 4.0 because we wanted to mark a definite shift in culture towards open engineering and cross-platform. I think we've been successful in that, so when you see "F# 4.0" that's part of what we intend it to mean. I guess I think of it as the start of an open-engineering journey combining the best of enterprise and openness.

Cheers! Don

[enricosada]

First, really good job! You two have done two migrations (closed codedrop -> codeplex -> github) that's a lots of work. I think that's the best feature of f# 4. And i know there is only you @KevinRansom and @latkin , so thanks!

Some things i liked:

• Detailed comments, feedbacks and review to pull requests/issues
• it's lots easier to develop now than months ago ( codeplex ok, but also better experience on clone -> run debug ).
• Twitter
• Patience :smile:
• Actively search for bug on stackoverflow, twitter

I'll add references where possible, but i dont want to discuss here the single issues, these are examples.

I'll add the really good issue dotnet/coreclr#744 , duplicated in corefx dotnet/corefx#1445 and dotnet/roslyn#2156 , because some problems/suggestions apply here too.

Create a vision for this repo

Right or wrong, i see you @latkin and @KevinRansom like roslyn/corefx teams, the goto persons to ask questions about MS F# tech future. There are some open questions not addressed about future like netcore, asp.net vNext, universal app, collaboration with open source projects. Add long term goals and create big issues, and enable contributors to work with you on that. An example: the vs project system. It's really in bad shape, is really behind pytools/nodetools, not speaking about c# or vb. Some are not missing features anymore, are bugs (folders/templates/show all files). We can slowly fix each bug. Or we can discuss how to improve, maybe importing pytools/roslyn code or rewriting stuff ( the vb project pages as example: i want to add the exe icon picker? too annoying write f# + c# + vb , so zero contributions ). Maybe some refactoring/changes/mistake are needed but in the long run, is going to be better.

Roadmap and open source development

There are lot of components in this repo, you have limited bandwidth, that's ok, ask help from contributors, but not only about bugfix. Develop the next version in the open, create issues (coreclr/aspnetvNext/universal/vs project system/etc) and engage contributors for help. No time to work with asp.net? i think there are someone who want to do that. People like to work on different areas, you can create multiple teams, and coord the efforts ( like the coreclr porting teams, external contributors with review from ms and help when stuck/questions ). I understand is more work, but you'll have more hands. Otherwise is only you two + @dsyme and sporadic pr for bugfix/feature. If you think about what the @VisualFSharpPowerTools team has done, that's amazing.

Continue to make it easier to contribute.

We cannot use your workflow, is different. The initial work is done (build + smoke test with app-veyour.bat, open solution -> debug -> vs extension ready, easier build etc) The repo source is big ( fsc/fsi/vs extension/language service/core libraries/type providers ) + test suite for each components. Some examples:

• there isn't an official public build server (appveyour is only smoke tests, not complete test suite Debug+Release). I can submit a pr, but i'd like to see the tests suite's results because i cannot run the whole suite each time (Debug/Release/Profiles), that's the ci server job, can you help me with that?
• This repo is also the home of the fsc/fsi/core library, not only the vs extension. Make it easier to contribute from osx/unix folks, pull from openfsharp repo, not push only ( the build script, use an xplat tests runner ). Obv openfsharp repo is for packaging but visualfsharp is the source code. Ideally i can code, test and submit a new pr of fsc without Windows (ci server/review). also useful for future xplat coreclr.

Make the code easier to accept changes, to fear a bit less the regressions

This repo contains lots of things. Is like the full .net fw distribution ( .net bcl = core library, msbuild, vs ext, compiler ) Trying to split when possibile (roslyn+corefx vs fsc+corelibrary ) and use nuget workflow is good ( like corefx ). Less stuff, lower barrier to contribution ( less code to read and faster test suite ). An example are the type providers (wsdl/odata). I know is more work to create another repo and migrate code (i cant help with ms internal work, but i can help with code inside this repo) but medium/long term is easier to fix/evolve/document. Easier to review and add a feature/bugfix, because is easier to release a bugfix as nuget instead of an official/outofband vs release. Easier also to fix mistakes (i dont want buggy code, but happen. have a sane workflow + fast distribution helps alot).

Do not stop contribution flow

I know that from now until vs2015 release there is no more new work here, no new development, only some little bugfix (there are no more issues i can fix with this lockdown, too large diff, too much refactoring needed, too much time required to debug things i know less, like compiler ). I think this may drive people away, is already difficult start to contribute, more when a fix is probably going to be accepted but not merged. Or a refactoring is waiting because of lockdown, so next refactoring is not going to happen ( i dont refactor stale source code ). Git branch helps, i know branches are not free because needs yours supervision/review. Better skip one or two bugfix but create an active development story. I don't work full time on this, fix a bug and do that with a small diff is hard, lot of time is needed (see #391 , my third attempt, but is incomplete because the complete fix is too large for vs2015 ). I can do an easier fix for next version, but i need a branch to do that. If i don't send an easier pr this weekend, that's one weekend lost.

Don't do skip answers or communications

Some things are open questions (netcore/vNext/universal ) i understand you can't answer now but if you can't, just say so. No answers, "we can't speak about it now" or marketing lingo is worst.

Examples

• coreclr #263 , 2 months ago: priority issue, see roadmap (where?) and closed.
• asp.net vNext #264 , 2 months ago: same, closed.
• coreclr #387 , 1 month ago: no answer, that's worst because told by @visualfsharp via twitter to open the issue

Another good idea i'd like is the weekly corefx or aspnet team recorded meetings, that help us be in the loop

[KevinRansom]

@enricosada Thanks for this feedback.

We know we need a roadmap, we are trying to get one agreed, unfortunately the process is taking a lot longer than we expected. A roadmap for Visual F# Tools is tied up with Visual Studio planning, .Net Framework planning, Managed Languages planning. It is impacted by staffing decisions, marketing decisions and the schedules of the many teams inside and outside of Visual Studio.

If Visual F# Tools was two guys in a garage we could publish a roadmap every week, unfortunately for all of us we are not so unconstrained, not even @dsyme, who is a very significant player in the Microsoft Languages space, can tell you what the roadmap will look like yet.

It is a frustrating fact of our lives. We need to work within those constraints. However, a roadmap for v.next has not really been necessary up until now because our focus has been on bugs, because we are preparing to ship.

I am sorry for your frustration on the roadmap, I hope this is a satisfactory explanation.

Kevin

[rojepp]

You guys have been awesome! I can partly agree with @ssagaert in that this is a minor release, and that's fine. I will be looking forward to a higher cadence and you won't be stuck with the same version for long. Clients will learn to accept that it is fast-moving and will adjust. Actually client won't even know. The kind of clients willing to accept F# at all are more susceptible to change.

+1 on uservoice needs to die. Nice that @dsyme views it as his own trello board, but that voting model is horrid. My votes are spent long ago. Votes I am not willing to relocate every now and then. Sometimes I vote when I realize I'm not logged in, how broken is that? The biggest problem with UV to me is that it acts as > nil. Suggest/Report something on GitHub with good visibility, be asked to post it on UV with zero visibility effectively kills all discussion.

A small issue: I still think it is counterproductive to not merge PRs proper. IDK why you close PRs and then commit the changes anyway. For a regular GitHub committer it looks (and feels) like constant failure. Why go that way? What is so special about your way of committing code? Maybe rethink your flow, unlearn some TFS baggage?

And thanks for the mug! Big-ass cup of !

[KevinRansom]

User voice: Language design is not a popularity contest, it is about identifying the correct changes to make. Voting is interesting as a measure of interest but it is a pretty minor input to language design. Roslyn has a different language design process to F# it is more committee based and also does not rely on voting but it is similarly principled and open.

Don uses user voice because it enables the discussions that he needs to occur and that they happen in an open and respectful way. I think Don does a phenomenal job of managing the evolution of the language in a principled, open and respectful way. Let me repeat that Principled, Open and Respectful. F# is the great programming language it is because Don has those qualities himself and he has selected tools that enable him to work that way. We will see if there are changes we can make to alert visitors to the existence of interesting active uservoice threads..

Committing: We commit the way we commit to give a close to linear history. It's the style we prefer, and since we use the history a lot, we will continue to do it that way. You could productively ask GitHub to make our workflow easier if you want, a single button to implement our workflow would be great. However, it works well enough as it is.

We try to make sure that each release of Visual F# has enough interesting stuff to warrant the update. In our heads the cadence is quarterly but the reality is closer twice a year. Since we switched over fully to F# 4.0 and VS 2015 last October, there have been few interesting updates to the 2013 codebase.

Glad you like the Cup<'t> we are very pleased with them.

Kevin

[exercitusvir]

Regarding Don Syme's comments:

[...] F# Language Design user voice. It is the place that I personally use to track F# language design items. [...] I'm very happy with the language/core-library evolution being separate from the tooling evolution. [...] Cooperation and alignment is needed, of course, and roadmaps for the various pieces are much appreciated.

I always have trouble knowing where to post suggestions and issues. It's not clear where something should go with so many different projects. It would be great if there was a centralized "F# Requests for Improvements" page that lists all the different projects in the F# language, compiler and tooling ecosystem with an explanation of what it does and whether it is the appropriate place for a suggestion or issue.

[dsyme]

See fsharp.org under Report/Fix an Issue. If there are more links to add to that page please send a PR to github.com/fsharp/fsfoundation.

[dsyme]

Direct link http://fsharp.org/guides/engineering/issues

[dsyme]

(It's not possible to list every project in the ecosystem, nor the larger .NET exosystem, but the core language, editor and runtime systems are listed)

[jacqueline-homan]

I am a relative newcomer to .NET and to F#, and only recently began learning it because F# was the right tool for the job for a project I am bootstrapping that is very data-complex. Of course, the very first F# book I bought was for F# 3.0 by @dsyme which contains a ton of material. I look forward to getting more proficient in the language so I can contribute to F# core projects here on Github. And of course, so I can write a program about anything that does anything in F# :+1: I am really enjoying learning F# and functional programming in general so far. But one thing I would like to humbly suggest, if it's ok for me as a noob to do so?

I'd like to suggest to ya'll: don't be like the Ruby guys. Don't try to make F# more like Ruby. I mean F# is a DIAMOND, ya'll. :smile:

I LOVE the type providers in F# 3.0 and I just starting to use them. F# is my favorite language precisely because it is different than Ruby in its elegance, its flexibility, and its super awesome efficiency for translating an algorithm into code for solving real life problems. Problems that range from tracking geomagnetic substorm activities to finding mineral deposits to watchdogging government money given to private charities to actually coding a diversity algorithm to solve a problem (while the Ruby guys were arguing about the problem, I commenced to solving the problem—in F#). So, all that said, I realize I am very new to programming compared to everyone else on this thread but I am skilled enough to know a good thing when I see it so the only input I can offer at this point is: (1) F# is a great language and an awesome community, and; (2) don't over-engineer an already great thing. :heart:

[allykzam]

This is just a little thing, but it'd be cool if the change logs actually reflected what's changed during the alpha/beta testing. Since the first thing we see when coming to this repo is a file listing with "CHANGELOG.md", one immediately thinks to look there, only to find that it hasn't been touched in months. As it stands, I've been constantly referencing this post, despite it being a rather high-level overview, and a bit outdated itself now.

[latkin]

@amazingant yeah we don't do a good job of keeping that up to date. With earlier update releases it wasn't too hard to just fill in the entire thing at the end (not really that many changes to list), but for F# 4.0 it's going to take a bit of effort to write up a properly detailed changelog...

[exercitusvir]

One more suggestion that I would like to make for the version 5 of F#: Please implement more suggestions from fslang.uservoice.com. There are a lot of suggestions that make would make working with F# much easier and code much more maintainable. For example, all the suggestions I made are solutions to real problems that I encountered when working with F# that could and should be solved at the language-level. I don't feel that version 4 really adds much to F# as a whole. At least, there is no reason for me to upgrade.

And the F# project model must be fixed ASAP. This is the most urgent and important issue that I see. This issue has the 2nd most votes on visualstudio.uservoice.com. For example, this is what's causing the folder organization in Visual F# Power Tools to be really buggy and it makes the support in Visual Studio feel really immature. I've experienced issues where the file and folder structure in Visual Studio looked completely different from what was actually written to the fsproj file. I got compiler errors that made absolutely no sense due to this and it took me some time until I had the idea to open the fsproj file in a text editor to check what was going on. You don't want newcomers to experience this, because they will think that F# is a toy language that is not used for large projects because F#ers apparently don't care about folder support (and possibly other support) in Visual Studio.

[cloudRoutine]

Documentation

One of the great things about Rust is its high quality documentation, the Rust Book is the level of excellence that all languages should strive to achieve. It does more than just explain functionality of language features but also the reasons that informed the design of the features and the particular contexts in which they should be employed. High quality documentation for F# is severely lacking and should also exist in a unified manner outside of the MSDN reference pages. An equivalent "F# Book" with sections like "Effective F#" and more in-depth explorations of language features like Code Quotations, Type Providers, and Computation Expressions. Making it easier for F# programmers to build their competency with high level language features will lead to more high quality upstack libraries and frameworks. A strong commitment to open source source software should include a strong commitment to make the knowledge requisite to use that software free and easily available.

The F# compiler and FSharp.Compiler.Service would also benefit from more comprehensive documentation. Most of the time I find the compiler's source code to be well documented, but it would benefit from more high level explanations of the compiler's architecture and the roles of particular modules, documentation organized around language features and the stages of the compilation process that include code samples and links to the related source code. Between the language specification and comments in the source code, a large portion of this material has already exists, it's primarily a question of pulling it together into a cohesive structure that would provide a better onramp for programmers interested in contributing to the compiler or making a high quality language feature proposal.

The FSharp.Compiler.Service could use the same treatment, especially since there's a lower barrier to contributions to the compiler service than the language compiler. Everyone working on tooling to make programming in F# enjoyable on platforms other than Windows relies on this library, so making it as easy to use as possible should be a high priority. Vim, Emacs, and Atom support were all key factors in convincing other developers I know with strong (and often unjustified) biases against Microsoft to give F# a shot.

I'm positive many people in the F# community would be willing to contribute to this effort, but I think it's essential that the F# team spearhead its overarching structure, keep it focused, and provide legitimacy through their endorsement in order for it to succeed. Hopefully setting a high standard with the documentation for the F# language, compiler and compiler service will encourage programmers in the community to strive for an equivalent level of quality in the documentation for their open source libraries.

Open Engineering Processes

The Compiler.Service could also serve as a testbed for developing better processes for community contributions. @KevinRansom This project seems free from many of the constraints that burden Visual F# Tools; so it would be great to see a roadmap. Some possibilities for experiments are:

• Organizing contributors into different styles of teams to work on specific features e.g. optimizations, bug fixes, documentation, etc.
• Encourage teams to develop best practices/pitfalls documentation for particular types of tasks
• Feature requests could be ranked by priority/importance
• Experiment with different workflows and see which are the best fit for the community or parituclar types of tasks e.g. Features vs. Documentation

As solid and effective processes emerge perhaps some of them could be integrated into the compiler development process.

Community Projects

If there are libraries that don't exist that you think would be beneficial to or fit into an overarching vision of the F# ecosystem, why not suggest them to the community? I've seen people post on r/fsharp many times about their desire to work on an open source F# project, but not knowing where to start or what to work on. If it hadn't been for @dsyme's comment about the Observable module and Reactive Extensions I probably wouldn't have started working on a library of wrappers for Rx that was eventually integrated into FSharp.Control.Reactive. Today I started working on FSharp.Core.ArrayFunctions because of @dsyme's suggestion. Which leads me to believe that there must be at least a few other people who'd work on a library if someone on the F# team thinks it’s worthwhile, and if all it takes from the team to make that happen is a few sentences, that seems like a pretty good deal to me :stuck_out_tongue_winking_eye:

---

I think you guys have done a great job laying the foundation for a vibrant open source community and the barriers to entry for F# have lowered significantly, but they still need to be pulled down even further before we see F# ecosystem fully blossom.