Azure-sdk-for-net: Update F# on Azure Docs

[jongio]

The following F# docs need to be updated to the new SDKs https://aka.ms/azsdk/releases

• [ ] Blob Storage https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/blob-storage

• [ ] Queue Storage https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/queue-storage

• [ ] File Storage https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/file-storage

• [ ] Table Storage https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/table-storage

  Table Client Lib is coming soon. Skip for now

• [ ] Package Management https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/package-management

  Include both Azure. and WindowsAzure. until we have Table client lib.

[isaacabraham]

@jongio I'm just reading through this. To be honest, I think a better way to approach this today would be to find whatever Azure Storage docs you have for the new SDK and add an "F#" tab to each of them. Potentially a few new pages e.g. working with "Azure Storage from F# Scripts" or something but putting all the docs together might be the way forward.

I know the reasoning why these separate articles were created - at the time it made more sense - but I think putting the F# docs in the same place that the C# versions for them would be better. @dsyme I think that you were involved in the original creation of these pages - what do you think?

[isaacabraham]

For example, I'd be inclined to update these docs to support C# and F# as separate articles (and simultaneously let's rename the ".NET SDK" examples to "C# SDK").

[dsyme]

cc @cartermp

[cartermp]

Completely agree with @isaacabraham's suggestion.

[dsyme]

I'm not totally sure. On the one hand it would be great if the Azure SDK team took the view that the SDK was a multi-language SDK and designed and documented each experience with that in mind, making best use of the full range of facilities each language provides.

However, in reality, the SDK is designed and documented as a C# SDK and gets completely revised along those lines every 2-3 years. The SDK is still very good to use from F#, but it neither captures what's special about F# in this context nor lands F# programmers in the sweetest spot, because it misses community-developed resources like The Azure Storage Type Provider.

I reckon the most valuable point of investment is to systematically document how to make F# programmers most productive on Azure. The Azure SDK will be part of that. In many ways that's what the https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/ were angling to achieve.

@jongio If we could find a resource to work with the F# community to revamp https://docs.microsoft.com/en-us/dotnet/fsharp/using-fsharp-on-azure/ end to end - including the SDK - that would be excellent and highly worthwhile from the Azure POV

[isaacabraham]

Maybe there's room for both? I would like to get F# docs "into the box" on the standard Azure docs as it's probably going to get better SEO for people searching for help on the Azure Storage SDK, but already there are some evident differences in how the docs might be structured - for example, in the linked docs above, it talks about using a console application and setting up environment variables etc. - this is totally not how an F# developer would explore an API, they'd just open up a script, reference the nuget package and go from there (in .NET 5 this becomes even more compelling). So maybe there's a case for having both reference docs on the "standard" page, and a more opinionated piece that refers to things that are more F# specific?

The Type Provider is in a sorry state at the moment - @cartermp has done a lot of more to help out but it's been months since I touched it - it actually does seem to currently work on .NET Core in the current version but I was thinking, if we moved to this new SDK it'd probably make sense just to start from scratch and create a much more lightweight TP that was quicker to author and maintain - it probably wouldn't have support for all the fancy stuff that the current TP (particularly around Tables) has, but instead just a simple way to rapidly get to the blob references given either a live or offline schema / blob list.

[dsyme]

Yes, part of what I'd like about a community collaboration on this specific topic is it gives us a chance to revise the community technologies as well (including simplifying and deprecating them)