manifold VS nanoserde

Considering the Amount domain types, I like the manifold project’s unit expression[1] approach where the unit and domain type are integrated and always reconciled.

1. https://github.com/manifold-systems/manifold/tree/master/man...

> I am glad to see a project that provides a robust and elegant API for building rest services in Java.

Alternatives for _consuming_ REST services is perhaps an equally interesting proposition, particularly since there are potentially potentially many consumers per service e.g., the manifold JSON project[1].

Other areas where Springboot feels overbearing include JPA/ORM support. In my view this is its greatest weakness, but like the "no one ever got fired for buying IBM" cliche, the same can be said today about Springboot.

1. https://github.com/manifold-systems/manifold/blob/master/man...

what do you think of the parser in nanoserde? https://github.com/not-fl3/nanoserde/blob/master/derive/src/parse.rs

Yeah proc macros have a massive hole in their user experience. Nobody actually wants to use them without syn + quote functionality, so the majority of people just pay the compile time cost of syn/quote/procmacro2. But then a subset of people can't afford to pay the compile time cost, so they either: 1. Don't use them. And remove all of their deps that use them ... which is generally a lot. 2. Hand-manage the TokenStream (which is very much not fun). Macroquad doesn't want syn + quote in their tree because they care _deeply about compile times, so they opted to re-implement serde. Serde is the crowned jewel of the rust ecosystem. Someone feeling unable to use it is a massive failure of the system.