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
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.
A way to represent types commonly found in major languages would be nice, but it would be better to start with something like wit and build on top of it, or at least have a lot of overlap with it.
Hi man - Don't take my tone the wrong way but it's the only way i can express this. I will never, ever - EVER use your craft project without a complete series of unit-tests. Especially one like yours. I stop reading immediately and just go on about my life.
Good effort though.
Edit: Oh I thought it was yours. Well I'll leave this up anyway.
fridental ·4 days ago
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
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.
Show replies
benatkin ·4 days ago
It has non-nullable types, via option, which makes non-nullable the default, since you have to explicitly wrap it in option. https://component-model.bytecodealliance.org/design/wit.html...
A way to represent types commonly found in major languages would be nice, but it would be better to start with something like wit and build on top of it, or at least have a lot of overlap with it.
Show replies
nicholaswmin ·6 hours ago
Good effort though.
Edit: Oh I thought it was yours. Well I'll leave this up anyway.
matthewtovbin ·4 days ago
Show replies
cmgriffing ·4 days ago
Seems a bit naively implemented.
Ideally, the duplicated props in Student would just be a single line of `Human`.