frameless VS Lantern

I don't see how Spark is any "less controversial" when the Spark Delay instance for cats-effect takes an entire SparkSession implicitly.

To add to this I lately have used Spark with frameless for compile time safety and it's an interesting library that works well with Spark.

For type safety with dataframes, techniques like https://github.com/typelevel/frameless can be used.

The preferred way to write Spark programs is to use DataFrame API which is untyped and is essentially the same in Scala, C# and Python. It's a DSL that's used to describe AST of the computation and the end result is the same regardless of language. There's a library called Frameless (https://github.com/typelevel/frameless) that implements typed DataFrame API but it is not in wide use, it looked dead for quite some time (though now development seems to continue) and didn't play nice with IntelliJ IDEA last time I checked. Performance-wise there's no difference most of the time (since all the program does is create an AST) except when using UDFs - Python UDFs are significantly slower and you can't write "proper" UDFs in Python - ones that generate Java code.

Frameless is a nice way to grab some type safety back from Spark, and features opt-in Cats integration.

Valid point! Have you seen the withColumnTupled API? It returns a typed tuple instead. This seems to satisfy your use case - the dataset preserves its type and doesn't require a new case class. This is kind of what you're suggesting but without case class generation. Though not sure whether attribute labels (names) are preserved in this case. It's also unclear whether this is good enough for wide tables.

I recommend using Frameless, which includes a Cats module. In general, I would encourage you to master “purely” functional programming first, because it’s foundational. Spark is a very specific technology, and probably not even the best in that class today—I would be very careful about trying to build a career around it.

Yeah. The point here is that the machine learning algorithms in libraries like TensorFlow and PyTorch ultimately rely on differentiating functions. The idea behind "differentiable programming" is to make the central mathematical aspects of machine learning more first- or at least second-class citizens. So at the library level you find "autodifferentiation" in Haskell, an implementation as part of Rainier in Scala, autodiff in Rust, etc. More ambitiously, you have the Lantern system providing autodifferentiation-as-metaprogramming in Scala (but generating C++), another metaprogramming approach in Scala, and autodifferentiation as a language feature in Swift.