magnolia VS Chimney

Scala 2/3: * Magnolia

If Mirror is too low level, I'd suggest playing with Magnolia https://github.com/softwaremill/magnolia. I haven't found any posts about it, I plan to publish something myself as a follow up to the one above. In the meantime you might want to check out magnolia examples https://github.com/softwaremill/magnolia/tree/scala3/src/examples

The second feature is the auto-derivation for case classes using Magnolia. This saves a bunch of typing for case classes, while fitting neatly into field builders. This is not new if you've used Shapeless, but I found the macro-based approach in Magnolia much easier conceptually. I did find a small bug but it's easy enough to work around.

Using shapeless is completelly optional and has a lot of disadvantages. I'd not even consider it a good learning material for functional programming. Magnolia is a bit more robust and has much better design, debugging and implicits resolution - it will be less pointful than starting with shapeless.

But yeah, I wonder if using a tool for case classes conversion like https://github.com/scalalandio/chimney would help in managing those ADT hierarchies for DB/business logic/web layer/etc.

Hello, if you have some nice examples could you please check if it's something that would fit any of issues planned for 0.7.1 or create a new one?

Perhaps, https://github.com/scalalandio/chimney would leverage it.

Thankfully, there are some solutions that can help reduce the boilerplate of these manual conversions. For instance, chimney : https://scalalandio.github.io/chimney/

I want to upgrade one project to Scala 3.1, but I'm using the macro heavy chimney (https://github.com/scalalandio/chimney) to reduce the boilerplate, which is not available for Scala 3 yet. My idea was to copy and paste the code that chimney generates on 2.13, and after that uncomment the uses of chimney for now.

In my $dayjob we originally used Scala, but I pushed for a couple of new services to be written in TypeScript/Node as it was really hard to hire Scala developers. I'd say it worked well, we even took a somewhat functional approach to building things. We tried fp-ts but that was a bit hardcore (when you are trying to hire TypeScript developers who don't know functional programming), so just built Either and Option types which provided 99% of what we needed.

There are still a few things I miss though:

* Pattern matching and exhaustive checking. Using a switch statement it is possible to define a function that can emulate the compile-time exhaustive checking, but it's still rather weak compared to what you can do in Scala.

* Implicits. Being able to define something that can convert say a UUID to a String or vice versa automatically just feels like magic, especially when dealing with data from third party systems.

* Compiler macros and metaprogramming. It enables tools like Chimney (https://scalalandio.github.io/chimney/) to be built, which I don't think are possible with TypeScript right now.

Converting between these classes can add some boilerplate, but luckily there are libraries like https://github.com/scalalandio/chimney that make it much easier.