3 ms·

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden i

Three big downturns for me: 1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history https://typeschema.org/history 2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this. 3) The biggest challenge about data models is not auto-generated code (that many people would avoid in principle anyway), but compressed, optimized wire serialization. So you START with selecting this for your application (eg. AVRO, CapnProto, MessagePack etc) and then use the schema definition language coming with the serialization tool you've chosen.

dominicrose 2y ago
also the output in markdown and php doesn't seem good
ericyd 2y ago
Point #1 was my biggest turn off. Numbers 2 and 3 are good points too.
deskr 2y ago
> ... auto-generated code (that many people would avoid in principle anyway) Auto generated code is 100% enough, sometimes.
- dirkt 2y ago
  I still have not found any way to use autogenerated code for Java/Spring that can handle updates to an external OpenAPI spec. Any pointers? (Serious question).
owlstuffing 2y ago
> 1) Yet another protocol etc. Agreed. > 3) The biggest challenge about data models is not auto-generated code I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve. Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it. Something like project manifold[1] for the jvm world is in my view the way forward. Shrug. 1. https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold
nsjdjwnn 2y ago
I mean, Java and Go are strongly typed languages if you consider Object a = new Integer(); a = new Float(); to be strong. They are also strict of cause

dominicrose 2y ago

also the output in markdown and php doesn't seem good

ericyd 2y ago

Point #1 was my biggest turn off. Numbers 2 and 3 are good points too.

deskr 2y ago

> ... auto-generated code (that many people would avoid in principle anyway) Auto generated code is 100% enough, sometimes.

dirkt 2y ago
I still have not found any way to use autogenerated code for Java/Spring that can handle updates to an external OpenAPI spec. Any pointers? (Serious question).

owlstuffing 2y ago

> 1) Yet another protocol etc. Agreed. > 3) The biggest challenge about data models is not auto-generated code I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve. Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it. Something like project manifold[1] for the jvm world is in my view the way forward. Shrug. 1. https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold

nsjdjwnn 2y ago

I mean, Java and Go are strongly typed languages if you consider Object a = new Integer(); a = new Float(); to be strong. They are also strict of cause