Disagree with this; because it very much depends on the program being written. From what I've seen they've become more popular with ironically the exception of the SQL ones for the reason you describe. As long as you can get the schema/example file locally on the source tree without the type provider needing to fetch it remotely it saves having to write up a lot of classes by hand. E.g with web UI calls just get the swagger Json and download it into your solution, for rest/json APIs just drop all the example documents into a folder and have the type provider reference that. Once the source data is local the flakiness mostly goes away and it just becomes a much quicker/less error prone way of expressing schema from a wide variety of sources. It's personally saved me a lot of time in development especially when interacting with many data sources at the same time - that's a lot of Dtos I would have to craft myself and I would in this case probably moved to a dynamic language a while ago for the work I do. A type provider that allows local schema would deal with your issue and then you would get type checked SQL queries at compile time without the direct db dependency and connection latency.
> A type provider that allows local schema would deal with your issue and then you would get type checked SQL queries at compile time without the direct db dependency and connection latency.
You might be interested in Rezoom.SQL [1], which is exactly the thing you describe.
As an aside, it also has unusually thorough documentation [2] by F# standards.
If you only use it that way, type providers are only slightly more convenient than doing what everyone already does for every other language: code generation.
See quicktype, for example, which supports a lot of languages.
This isn't built in to the editor, but can be run from the command line. A benefit is that it does not suffer from the other problems with type providers, like not supporting the full language, (e.g., records and discriminated unions in F#).
Having 10 lines of code for 10 different data sources and having a explorable Intellisense API for all of them is much nicer though than having 10 code generator + command line tools in my now required build pipeline, each one with a different syntax. Don't get me wrong - I will resort to code generation for some things if there isn't a type provider available but I always find more friction with this path and still doesn't give me all the benefits of type providers (e.g the SQL static type checking aspect). It works across different IDE's, don't need to introduce more build tooling, generated code is obvious vs a code generator, is as cross-platform as the underlying language/runtime is, etc.
Slightly more convenient for one source becomes very convenient as the amount of data your analyzing increases. It's not the be-all-end-all it was promised to be as a feature but it is easier than code generation IMO. If you can get rid of the disadvantages by keeping reference schema locally in its native form (e.g no flakiness you mention) then why not use it?
Fair points. I consider the lack of support for the good F# features like records and DU to be an extremely big downside. I think we agree on the facts, just weigh the costs and benefits differently.
