transit-lang-cmp VS µPickle

> 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!

The upickle library has traditionally had great performance for handling json in Scala apps so is likely to be seen as a safe choice for someone starting a Scala project. It appears though that not just upickle, but other json library projects are having difficulties maintaining their old level of performance when they release using Scala 3's macros. uPickle currently has an open issue where you can see some of these issues: https://github.com/com-lihaoyi/upickle/issues/389 and here you can see the weePickle folks are also having the same performance problems. Looks like things changed up significantly enough between Scala 2 and Scala 3 so that in order to maintain the same functionality they have resorted to using runtime reflection for mapping to/from case classes.

See here for sample code size numbers (not picking on upickle specifically, it's just what I'm using myself. I've heard similar reports about e.g. circe)

A good starting point is the note in MacroImplicits.scala in upickle sources. "derives Writer" for a specific case class Foo simply adds a given Writer[Foo] to a companion object of the same specific class. However, this cannot be done automatically for a trait defining sum type - in this case trait Thing. The required given must be defined manually, and the ones automatically obtained for case classes can be used in it.