
F# Data Type Providers in .Net Core (2018) - kroltan
https://lukemerrett.com/fsharp-data-type-providers/
======
EdwardDiego
Ah, F#, when I was desperately trying to get skills in .NET (lots of .NET in
my town, and I don't have a degree) I encountered F# and lost my enthusiasm
for C#. Which is doubly ironic now that I work for a JVM shop.

I still have a lot of love for it though. Especially things like measure
types.

~~~
mc3
JVM has a lot of functional languages. As well as the usual Clojure, Scala,
etc. I think it has some Haskell-like ones.

~~~
desert_boi
Is there an ML on the JVM? The best part of F# is it felt like a simpler
version of Scala, even without things like higher kinded types that are
present in OCaml.

~~~
yen223
If you squint very (very) hard, Kotlin can fill that role. You've got
algebraic data types via sealed classes, a weaker form of pattern matching via
`when` expressions, and decent facilities for higher-order functions.

~~~
soulnothing
I was going to comment the same thing. I moved from F# to kotlin and have
about 80% of what I want / used from F#. With more tools eco system that makes
management happy. Arrow adds to that, with it's library and compiler
additions.

I have also been building type providers in Kotlin. Where a gradle plugin
scans a file / schema then generates types and DSLs off of it. It's a
pragmatic functional language.

The biggest catch to me. Is there are very few places using Kotlin in a fully
functional style. On the back end more often than not you'll find Spring.
Which undoes a lot of these features / patterns.

------
breatheoften
F# looks like a great language... A friend of mine who is a non-programmer DBA
just reached out to me and asked about recommendations for learning .NET ...

I've not seen anything as elegant looking as F# in the .net world before ...
What do people think ... -- is F# a good language for a beginner to learn
which is also sufficiently well-supported that they could find themselves
building useful script-like database (MSSQL) oriented utilities as early
project ...?

~~~
muststopmyths
F# has tended to lag far behind C# in Microsoft's ecosystem. I haven't kept up
with in a few years, so I don't know how far behind it still is. It is a fun
language for sure.

If your friend is looking into getting into .net for professional purposes, I
would steer them towards C# first. That's likely to be much more useful in the
long term. Especially since it can be a stepping stone to other C/C++ like
languages.

With F# I would bet that they hit some limitation sooner or later where
something that could be easily done in C# will take more work in F#. Which
could be fine if they have the time/inclination to rough it. I just would not
advise F# as a resume builder.

~~~
dgudkov
>With F# I would bet that they hit some limitation sooner or later where
something that could be easily done in C# will take more work in F#.

From my experience of working with both C# and F# for a few years, it's more
likely to be the other way around.

~~~
pjmlp
F# lacks the Visual Studio tooling support that VB.NET, C# and even C++ enjoy.

It is also not officially supported on UWP, and needs some hacks to the
generated MSIL (as .NET Native doesn't cover 100% of all MSIL).

~~~
dgudkov
The support for F# in VS leaves a lot to desire, indeed. However, in my
experience, I've found that the developer productivity gains from F# outweigh
the inconvenience.

~~~
pjmlp
Only if what you are doing is directly supported by F#.

If you attempt to do GUI development, then you are forced to look for
community projects like Fabulous, use the XAML type provider with a dummy
C#,VB.NET,C++/CLI project for the XAML generation, or actually use one of
those languages for the UI, with F# used only for the logic.

So even though I am a big fan of ML language family, at the end of the day,
the other .NET languages get the green light from most customers and team.

~~~
WorldMaker
I don't recall having too much difficulty getting the VS WPF XAML Designer to
basically function with F#. Some features just don't light up like event
connecting/code-behind, but that's fine and what I wanted anyway (taking an
MVVM-ish approach).

There's a hope that with F#'s upcoming move to the "shared project system"
that a lot of the pains will go away in hopefully the near future.

(That said, Fabulous has piqued my interest and I'm debating rewriting my big
F# GUI in it, at least in an exploratory branch.)

------
JaggerJo
If your using F# want to build (cross platform) UIs take a look at
[https://github.com/AvaloniaCommunity/Avalonia.FuncUI](https://github.com/AvaloniaCommunity/Avalonia.FuncUI)

------
blunte
Am I missing something? This appears to be just outsourcing the record schema
definition to a sample object in another file.

You still have to keep that sample updated to handle new runtime data.

~~~
kroltan
Yes, but it is comparatively easier getting say, the result of an API's GET
and pasting into a file as a sample, than manually tweaking types. At least
when you're starting out or if it's a small F# program. You could even use the
actual network path, but that's a bit... wilder in terms of
maintenance/reproducibility.

Plus, since you can have arbitrary providers, such as a provider that connects
to a DB and generates a type-safe "ORM" over your relational database[0] with
no configuration other than pointing to the data source you're going to access
at runtime. Perfect if you want to write little data transformation scripts.

[0]:
[http://fsprojects.github.io/SQLProvider/](http://fsprojects.github.io/SQLProvider/)

~~~
xixixao
It might be easier, but it's trivial to come up with cases where you cannot
generate an example that completely satisfies given JSON schema. It feels like
this only works for some specific rigid JSON protocols. You also cannot
restrict the types to anything more specific than JSON primitive types.

A "better", certainly more common solution is to generate the type based on
whatever source code is generating the JSON, if you have access to it (or have
the API provided generate the signature for you).

~~~
kroltan
I'm still learning, but from what I gather, there's

a) less of a need to deserialize things into specific concrete classes in
functional languages

b) it seems to be idiomatic to convert data yourself if you need custom
conversions, rather than relying on a library to automagically deduce it. this
is helped by how simple doing the manual conversion ends up being in practice.

------
zyxzevn
With compile time execution, one can do similar things in other languages too.

This video shows a very advanced and practical way of using "static
introspection":

Lambda World 2019 - What FP Can Learn From Static Introspection - Aditya Siram
(Deech)

[https://www.youtube.com/watch?v=ElHi2h9Ho6M](https://www.youtube.com/watch?v=ElHi2h9Ho6M)

What if compile time and type level programming in functional programming
languages were easy, something you reach for without even thinking about it?
What if you could debug type errors with a simple compile time print
statement? Write highly flexible systems by being able to introspect into
types at compile time? Pre-calculate large portions of your programs for great
efficiency?

Typed functional programming is a great and fun way to write resilient
software, and as type systems have become more and more expressive in recent
years, we are able to program sophisticated and useful properties at the type
level for even better compile time safety. Just one problem: It is very
difficult, requires advanced knowledge of the type system, the syntax is
convoluted, the error messages are impenetrable, and it is nearly impossible
to debug.

This talk will dive into why we should steal static introspection from
languages like Nim, and D, state-of-the-art imperative programming languages
which can solve all these issues, make type systems much more approachable
without losing any expressive power, and offer new design possibilities for
functional programs.

~~~
mycall
D is an imperative programming language? I thought it was multi-paradigm.

------
platz
Is there is a moratorium on adding IL-compatible features to F# ? If so, is it
keeping pace with the additions to C# ? If not, what work is being done?

~~~
jolux
What’s C# got recently that doesn’t already exist in F#?

~~~
platz
well C# 8.0 introduced async streams, for example

~~~
adgasf
F# allows you to implement such features as libraries using computation
expressions.

~~~
louthy
So does C# with LINQ [1]. I guess C# language development tends to lean more
on concrete syntax than libraries, which is a shame, but it is possible. It's
also a shame LINQ can't be extended like computation expressions.

[1] [https://github.com/louthy/language-
ext/blob/master/LanguageE...](https://github.com/louthy/language-
ext/blob/master/LanguageExt.Core/DataTypes/Task/Task.Extensions.cs)

------
namelosw
F# is great, but it seems to be somehow slowed down by C#.

If there's a feature that takes time to implement (eg: Type Classes from
Haskell or Polymorphic Module from Ocaml), people would rather wait for CLR or
IL to support the infrastructures first.

As a result, there are many essential features waiting to be implemented
forever.

~~~
zelly
I'd try F# if it were hosted on JVM or better yet LLVM. Unfortunately .NET is
borderline nightmare inducing so I wouldn't want to spend my free time using
it. And it doesn't seem to have any better adoption than OCaml which is its
supposedly outdated predecessor.

~~~
adgasf
I think was true before .NET Core, but now the experience is quite good.

It's also possible to use F# as a compile-to-js language using Fable. This
code would run on Node or the browser.

Then there is
[https://github.com/dotnet/corert](https://github.com/dotnet/corert) which
allows ahead-of-time compilation to native code, but it is a bit more
experimental.

------
hannofcart
Is it possible for the JSONProvider to take a JSON schema as input rather than
just a piece of JSON?

~~~
coolreader18
It looks like there is/was one, but it was abandoned by its developers:

[https://github.com/jet/JsonSchemaProvider](https://github.com/jet/JsonSchemaProvider)

[https://medium.com/jettech/json-schema-type-provider-why-
we-...](https://medium.com/jettech/json-schema-type-provider-why-we-built-and-
abandoned-it-7b0659afad18)

------
scanr
I wonder if they could get the TypeScript compiler to do something similar in
future.

~~~
namelosw
Yeah, that would be very helpful since there's no dependent type in a
foreseeable future.

For example, As a front-end heavy language, talking with other systems is
quite ordinary -- a very useful case is reflecting GraphQL or SQL type without
code generation.

------
amluto
I wonder if Rust macros could be used to similar effect.

~~~
afranchuk
Many languages with powerful macro systems can do the same. Still, it's
cool/promising to see a .NET language capable of compile-time execution like
this when they do not support macros in the same way that other languages do
(but they do have plenty of reflection features and some codegen features as
we see here).

------
phillipcarter
Note: article is from 2018 - since then, the FSharp.Data package has long
moved out of preview and many other Type Providers work well on .NET Core.

~~~
kroltan
You're right, sorry for breaking the format. Hopefully a mod can fix it since
I'm not able to edit the post anymore.

I picked that article just because it is a very concise explanation, a bit
more proper for sharing, than the official documentation, which currently
requires a bit of hyperlink-following and generally nonzero familiarity with
the language.

