How to drive F# Adoption - Part 3

[KevinRansom]

Okay thanks for sticking with this,

• we have a wall of sticky notes, white-papers here: How to drive F# Adoption - Part 1? #798
• we have a wide array of prioritizations here: How to drive F# Adoption Part 2 #803

Before we do the next bit: __ the internet is a confirmation bias machine ... I may suffer from it, you may suffer from it.__

Now the tricky bit:
It appears to me that as enthusiasts the top 4 suggestions for improving F# adoption you would propose are:

1. Microsoft employees needs to talk about the future of F# more, and be more positive about it

• This had pretty much universal agreement.

2. Improve F# out of the box experience

• This was a majority opinion with different flavors of "improve"
• Address experience blockers and bugs quickly
• Make available the power tools type functionality -- better yet the power tools by default
• Improve documentation

3. Coreclr

• Common response
• For alignment with .Net technical direction

4. Web Tools
   • lot's of work done by developers in VS is currently web programming so make that easier
   • Common response
   • Good ASP experience
   • Good DNX experience because ... its the future!
   • Interestingly Suave seemed to not resonate with you that much ... I wonder why? cos it's great (Please answer it in Part 2 because it's irrelevant to this discussion)

Is this the right set? very brief comments please.

[lefthandedgoat]

Looks good.

I use suave and really enjoy it, especially vs ASP.net MVC with F#.

[CumpsD]

👍

[lambdakris]

I think a richer SQL and NoSQL data access/manipulation story still needs to be a part of this. Having a DSL/language integrated means of generating optimized SQL code and idiomatic F# drivers/adapters for top NoSQL databases is as necessary as the Web Tools if we want to be able to say that you can do most common things in F# at least as easily as you can in C# or Java or Scala.

[KevinRansom]

@lambdakris The story for data access is type providers .. personally I think we should make them much easier to find, and make them look more integrated into the tooling experience. Currently they are on nugget but you sort of need to know what you are looking for. A type provider wizard, that answered questions and selected the type provider and generated the source to get started might be interesting.

Something like that anyway ...

[rojepp]

[KevinRansom]

@rojepp Clippy is exactly the right model yes :-)
I always liked the Clippy suicide note story.

[lambdakris]

@KevinRansom I've become quite chummy with the SqlClient Provider, having used it in two projects at work, and I have also had time to evaluate the SQLProvider at various times over the past 5 months. The SqlClient is an improvement over ADO.NET, certainly sufficient, and in my estimation currently the best sql data access tool for F#, but personally I've found that most micro-orms offer more productivity from a query building and conventional reads and writes perspective (if only they knew what to do with Option types...). As for SQLProvider, I fear that it's use of SqlMetal.exe means that the generated SQL is less optimized than what is generated by EF 4.1+. If you are interested, check out http://getquill.io/ as an example of a cool approach in Scala land. I think Type Providers are also cool, but the problem here really isn't the discovery of types, but rather the combinators that can make that type of SQL generation and verification possible (which LINQ and anything LINQ based/derived cannot really accommodate).

[rojepp]

Clippy aside :)
I agree, finding the TP to use is not a problem. By then you are in F# land.

[KevinRansom]

@rojepp if you are a new user to F# and you have just created a console app. Is it possible that you might want some help trying to access data?

[jackfoxy]

1, 2, 3, 4, perfect.

Related to the OOTB the community needs to be able to add F# code examples to all the MSDN documentation across the board through pull requests. Especially for Core CLR going forward. I'm sure this will get a big participation and all of those empty F# code boxes will quickly fill.

Suave resonates with me. There is a good chance I will start a Suave/Websharper project real soon.

[enricosada]

@jackfoxy documentation and code example you want is https://github.com/Microsoft/visualfsharpdocs i think, send pr!

[panesofglass]

Looks mostly right to me. I think Web Tools should be replaced with .NET Native / LLVM support. I don't care any longer about ASP.NET support. I think we have better options now; just need better docs. However, native / IoT support is crucial for performance and breaking out into other domains (F# everywhere).

[panesofglass]

@jackfoxy @enricosada I don't know if MSDN is the right focal point. I liked the idea of http://getfsharp.net/ and providing a hub of great content and docs. In particular, see https://doc.rust-lang.org/stable/book/, http://elixir-lang.org/docs/stable/elixir/Kernel.html, etc. These look like ReadTheDocs or GitBook output. If we have something like this available, we will be in a far better place. F# samples in MSDN are important, but less so compared to this more basic need.

cc: @swlaschin - I would love to help with this effort if/when you move forward.

[enricosada]

@panesofglass i was speaking about msdn docs because lot of devs find info there.
a general f# docs site is a nice idea

something like https://get.asp.net/ ( we have fsharp.org => get.fsharp.org , or get.fsharp.net better )
for docs yes, ReadTheDocs is nice, again https://docs.asp.net/en/latest/

about .NET core, http://dotnet.github.io/ and http://dotnet.github.io/docs/ ( we need to add F# info there )
I sent a pr to dotnet compile a f# project.

btw dotnet cli work really well, OOTB experience too

1. http://dotnet.github.io/getting-started/
2. download msi/rpm
3. dotnet new ( scaffold a new project )
4. dotnet compile ( restore nuget, build )
5. dotnet run or an .exe ready to use