zio-protoquill VS jsoniter-scala

There is: https://github.com/zio/zio-protoquill

Among Scala 3-only macro codebases is proto-quill (Quill for Scala 3). Other than that most libraries will be cross-compiled Scala 2 and Scala 3 because they have to cater to both long-time Scala 2 users as well as those who already migrated.

Proto Quill, a query DSL similar-ish to Slick, is certainly the poster child of what's possible with Scala 3 macros.

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.

I am a Scala engineer and have upstreamed a lot of open source projects to do this, (i.e. see https://github.com/getquill/protoquill/pull/17). Basically its a github action that runs concurrently to the main build, this has the following advantages

I've been refreshing https://github.com/getquill/protoquill nearly every day!

What an amazing step by step explanation!

More than 2 years ago I found that byte array view var handles are quite suitable to cook efficient SWAR routines with Java/Scala.

See a lot of other examples of SWAR usage, like parsing Base16/64 string, java.time.* and number values directly from byte arrays:

https://github.com/plokhotnyuk/jsoniter-scala/blob/master/js...

Afaik dsl-json came up with a lot of improvements and inspired a several other libraries like JsonIter and jsonIter-scala. Jsoniter-scala by u/plokhotnyuk is probably the most optimized JSON library on the JVM at this point, and seems to power most of the Scala ecosystem. Some implementations/optimizations eventually made their way back into Jackson and other libraries.

I was on your place more then 5 years ago, when cut the 1st release of jsoniter-scala.

I've just increased compiler performance in ~1.5x times by adding these JVM options for the code cache

We have our own open-source code-generator that produces Scala code from Smithy. The code module is entirely dependency-free, and the generated code is not biased towards any library, be that http or json. We do however have out-of-the-box integration with jsoniter and http4s.

You can use jsoniter-scala. It is easy to use like upickle.

BTW, jsoniter-scala uses it for faster parsing and serialization using SWAR techniques, like here.

Probably you should have both codecs (for Foo and for its T) are implicitly available in the scope, like it is done in the following test for jsoniter-scala:

BEWARE: uJson is vulnerable under DoS attacks

Please see sources (and GitHub history of development) of jsoniter-scala as an example in the domain of JSON parsing and serialization.