Shapeless VS refined

Scala 2-only: * Shapeless (there is Shapeless for Scala 3 but less often needed as basic things are in Scala 3)

I know that libraries like Scodec and shapeless were rewritten practically from scratch for Scala 3, taking advantage of the next syntax and internals, as well as protoquill - a Scala 3 implementation of Quill.

please show me something like this: https://akka.io/ or this: https://zio.dev/ or this: https://github.com/milessabin/shapeless

That largely depends on the type system. Languages like Haskell and Scala which have much more powerful type systems than C/Java/Go/etc absolutely do allow you to do those sorts of things. It is a bit harder to wrap your head around to be sure and there are some rough edges, but once you get the hang of it you can get the benefits of static typing with the flexibility of dynamic typing. See https://github.com/milessabin/shapeless or a project that I've been working on a lot lately https://github.com/zio/zio-schema.

Just use cats and use the apply syntax .mapN for this. Seriously. There isn't a way to do it without generating source code that I can see in the api. Scala 3's HList Tuples aren't like Shapeless 2's HLists and I can't figure out a way in the api to reduce the tuple members down from (A, B, C, D) into an E, generically, yet with Scala 3 poly functions, unlike what you could do in Shapeless 2 with HList

Scala has sparked a huge ecosystem of very high quality libraries (Cats, Scalaz, shapeless, to name but a few). I think a major reason for this is that Scala attracts developers who value the advantages of the JVM, but are fed up with the limitations of the Java programming language and understand the benefits of an expressive type system and functional programming.

I also investigated shapeless3 macroses: https://github.com/milessabin/shapeless/tree/shapeless-3/modules, but they are more about derivation than reflection. And probably that is all I found.

I'm not sure where is the line between extensive and basic knowledge. Here is my more detailed exposure:

In commercial context:

* Of strongly typed ones only Scala (with [shapeless]). Can reluctantly throw in Kotlin as well for it's amazing structured concurrency.

In non-commercial context:

* Went through a few chapters of [Software Foundations] doing Coq proofs.

* Worked through most of the [Types and Programming Languages] (writing typecheckers in Ocaml)

* 3 services in Haskell (1 on Scotty, 2 on Servant). Loved persistent+esqueleto for the ORM layer, disliked Opaleye.

* 2 projects in PureScript (1 with Halogen, 1 with React bindings).

* 1 project in ReasonML (Ocaml).

-

> I am afraid there is no way back for me

I see where you are coming from. In my case I can alternate between "I want all invariants properly expressed and checked" and "I just want to ship that barely-working piece of junk and iterate on it". I learned to adjust depending on organization needs. IMO, for many orgs, especially startups/scaleups, the latter is often the more fitting way. With that in mind, I'm willing to trade the guiding hand of great type systems for other productivity aspects (amazing runtime and cohesive web framework in Elixir's case).

[shapeless]: https://github.com/milessabin/shapeless

[Software Foundations]: https://softwarefoundations.cis.upenn.edu/

[Types and Programming Languages]: https://www.cis.upenn.edu/~bcpierce/tapl/

Does the Refined library for Scala (at https://github.com/fthomas/refined; "eu.timepit" %% "refined") work in Scala 3? Does it work differently?

Scala likes to do design-by-contract on the type level. You encode your pre- and post- conditions into types. Libraries like iron (scala 3) https://github.com/Iltotore/iron and refined (scala 2) https://github.com/fthomas/refined allow you to do all that without throwing any exceptions and they can even enforce some simple predicates at compile time.

Annotation is not the only way (and probably not the best IMHO) to do refined types. You might be interested in Iron in Scala 3 or Refined in Scala 2/3.

In one respect, nothing. You’re right. Even given refinement types as in Haskell or Scala, there is indeed a necessarily-partial function (refineV in Scala) to refine a value to its refinement type.

This is more or less how derivation works when you want to use something like Refined types (it exposes Validate[Type, Refinement] typeclass if I remember correctly). Enumeratum exposes Enum[A], and newtypes expose Coercible[From, To].

You will probably be interested into Iron or Refined.

You want either a refined type, a newtype, or if you are in Scala 3 an opaque type.

This example uses probably the most popular JSON library for Scala, Circe. There is another Scala library that lets us "be more specific with," or "refine," our types, called Refined. http4s doesn't provide any particular support for Refined, but Circe has a module integrating Refined, meaning that all of Circe's parsing, encoding, and decoding support is integrated with Refined. Putting together http4s' Circe support, Circe's generic codec derivation, and Circe's Refined integration, here's what I came up with: