case class Fruit(name: String, variants: Set[String])
val fruitJson =
Json.parse(
"""{
"name": "apple",
"variants": ["cox", "braeburn"]
}""")
val fruit = fruitJson.as[Fruit]
I agree that F# is syntactically closer to ML (though Scala is closer to ML with its module system which F# gave up completely).
TBH, I think the JSON example might underrate things a bit anyway. Where type providers really start to feel impressive is when you get to tricks like being able to noodle around inside undocumented (or poorly documented) COM interfaces with the help of CodeSense, or getting red squigglies in your editor (and compile time errors) when there's a problem with an SQL query.
F# isn't all roses, of course. I really wish it had typeclasses, and discriminated unions are less powerful than Scala's case classes in some tangible ways. But from a purely pragmatic perspective, my (almost certainly biased) sense is that I can usually Get Things Done™ with less ceremony in F#, and type providers are a shining example of that pragmatism.
If there is one thing I learned using type providers it is that maintaining your own "description"–be it as sample data or a schema file–loses most benefits of using type providers in the first case.
On the other hand, want a type provider for X in Scala? Just write it.
Stuff is still moving around because Scala devs want to get the meta APIs right first, but if adapting things from time to time is not an issue, then go ahead.
(Edit) this is apparently working in the latest scala 2.11 But it killed my adoption of scala for real work early on. https://issues.scala-lang.org/browse/SI-7099
I never have seen a use-case where this would have been an issue. Sure, it "looks" unfortunate, but there is only so much you can do when running on a completely uncooperative runtime.
If devs need a typed representation of unlimited length, they provide a HList and move on.
Such a representation will replace the length-limited tuples in a future version of Scala.