transit-lang-cmp VS jsoniter-scala

> The axum::debug_handler macro is invaluable to debug type errors (there's some with axum too), like for example, accidentally having a non-Send type slip in.

Heh, yeah. For my recent project where I explored implementing the same little app in a few different languages[0], I chose Axum for the rust version.

The whole "extractor" system was pretty magical, and when I had this exact issue (non-Send argument), the compiler error was totally useless. I did see the docs about adding this extra macro crate for error messages but it seemed like a bit of a red flag that the framework was going against the grain of the language. Still, on the whole, I did enjoy working with Axum.

[0] https://github.com/losvedir/transit-lang-cmp

This is great! Just pushed up a commit that uses it and updated the benchmarks[0]. I'm seeing a 1.6X - 2X improvement in overall performance. Not bad for a drop-in replacement. And since it's based on serde, I trust it, and I feel like trying out a different JSON library is within scope for me of not just "gaming the benchmarks", as this is actually something I'd now consider using at work.

It's not quite as high as I was seeing with `jiffy` (3,800 req/sec here vs 4,000+ with jiffy), but I'm not confident that was a totally fair comparison. `jiffy` doesn't integrate as nicely with Phoenix, so I was just calling `:jiffy.encode(...)` in the controller and then doing a `text(...)` response. I need to double-check if `json(...)` is doing more work here.

[0] https://github.com/losvedir/transit-lang-cmp/commit/140d693b...

Nowadays, I reached out for some benchmark results. Scala is slower than Java and Kotlin. Can you explain it? https://github.com/losvedir/transit-lang-cmp https://github.com/kostya/benchmarks

I had a chance to update the Go code (commit) to pre-allocate the arrays based on the known length before all the appends, and saw ~30% increase in performance, with top requests per second going from about 8,600 to 11,000.

I recently did a little project to compare several languages (https://github.com/losvedir/transit-lang-cmp) so I contributed to a bunch of those points!

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.