Because they are pretty annoying to implement and most are quite fragile

They are only as fragile as your type source.

Maybe not 'fragile' as in buggy, not buggy, but I found them to be 'quirky'. Sometimes stop working unless I close /re-open VScode. Stuff like that.

And other downfall. Do they still not work with DOTNET Core??

They've worked for several years now on dotnet, but the type provider author has to do some work to allow their type provider to compile and target that runtime.

Yep, implementing one (a solid one) is hardcore. But think about it. Building, say, an XML or SQL type provider is a big deal. Doing it right requires special talent, because you are essentially building a transpiler to seamlessly interface with F#.

But this is also it’s greatest strength. Having direct, type-safe access to structured data is truly awesome. What else compares? Certainly not conventional code gen.

Oh, don't get me wrong: Type providers are absolutely fantastic. Just, they are such a complex beast, most implementations I used so far are pretty fragile, at best. But tbh, even a fragile one is surprisingly useful

I got downvoted on the typescript subreddit when I mentioned how Type providers work in F# because "nah, it can't be working that way. The compiler can't be making http requests to make up types for an API" smh.

In fairness it is rather terrifying :P personally I pull all necessary information into some form of version-controlled storage, and then have a test to assert that the remote information is consistent with the stored version. Life's too short to have nondeterministic builds.

yeah that's fair. That's what I landed on too, and would think anyone using it seriously would be doing the same. But the fact that you could extend the compiler to program your own code generation in F# itself is amazing. Comptime in Zig reminds me of this too. I'd have to think OCaml has something similar, but I'm not too familiar with it.

Java has this too with the Manifold[1] project. It’s mind blowing.

1. https://github.com/manifold-systems/manifold

woah, I had no idea. That seems pretty cool

SQLX has entered the chat [1].

[1] https://github.com/launchbadge/sqlx

Nice.

Java has what looks like SQLx on steroids with the manifold project coming down the pike.

https://github.com/manifold-systems/manifold/blob/master/man...

This is the coolest thing I have seen over the previous week! Looks fantastic!

Couldn't these also be done in C# via source generators?

No.

> How do Source Generators compare with Type Providers in F#?

> If you’re an F# programmer (or familiar with the language), then you might have heard of Type Providers. Source Generators were inspired in part by Type Providers, but there are several differences that make them distinct. The main difference is that Type Providers are a part of the F# language proper and emit types, properties, and methods in-memory based on an external source. Source Generators are a compiler feature that analyzes C# source code, optionally with other files, emits C# source code to include back into a compilation.

https://devblogs.microsoft.com/dotnet/introducing-c-source-g...

I get that the mechanisms are different, but the end result is the same.

Ah, okay I thought that source generators had more limitations compared to F#. Turns out they can make arbitrary calls, including across a network, which previously I thought was only in the domain of type providers:

> For Schema.NET, we do a HTTP request to get the JSON we need to build

https://turnerj.com/blog/the-pain-points-of-csharp-source-ge...

Also phillipcarter says yes so I'll happily take his view over mine.

Yes. The mechanisms are very different of course, but both the F# and C# components involved generate types with properties, methods, etc. that can populate IntelliSense.

It's available to some in extend in rust, e.g. SQLX [1] allows you to typecheck queries.

[1] https://github.com/launchbadge/sqlx