4 ms·
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.
by i_s 9y ago
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.
https://quicktype.io/ https://quicktype.io/
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#).
- akra 9y agoHaving 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?
- i_s 9y agoFair 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.