Generated types are much better than manually-updated types when you've got a source of truth that lives in a different codebase, but I can't help feel like we could do better. I wish there were a "lingua franca" for type declarations that could be understood directly by different languages. Not only would you avoid the mess that is generated source code, but it could be a n^2 -> 2n situation, like LLVM and LSP, where you only have to translate to and from this common ground instead of to and from every combination of leaves.
Unfortunately it might be pretty challenging given how different type systems can be. But maybe if you started with a subset of popular languages that have similar-enough type concepts?
When it comes to JavaScript / Web APIs, the language you're looking for is WebIDL. The standards specify all APIs in WebIDL, and I believe Chrome does exactly what you're describing, generating C++ interfaces from WebIDL.
In Cloudflare Workers we've taken a different path, having the C++ interfaces be the source of truth, as we feel this leads to less cognitive overhead for developers on the project (and avoided the need to write a new WebIDL code generator matching our internal C++ dialect). It's possible we'll revisit this decision in the future, but for the moment it seems to be working well.
Looking at https://webidl.spec.whatwg.org/ I'm not sure if I understand how this really helps bridging type information from js to python to c++ - it looks very tied to js?
There's openapi (swagger) and json schema which seems more like helping define RPC over http?
Maybe. Those seem pretty low-level though; I'm thinking of something abstract enough to be used with TypeScript or GraphQL just as easily as Rust or Kotlin. So byte-layouts are likely too specific.
(Correct me if I'm wrong about how Protocol Buffers work)
I think Serde is the closest thing I've seen to what I'm getting at; the way it can freely translate between XML and JSON and Rust structures without any help. But of course it's not a standalone schema language.
For those who don’t know, much of Serde’s magic is powered by Rust procedural derive macros, which generate (i.e. “derive”) code from a Rust struct definition.
You can, of course, write your own derive macros, and apply several derive macros to a single struct.
I wrote some to derive SQLite schemas and migrations and queries and auto-generate frontend TypeScript RPC code. So my source of truth is the Rust struct, and that sort of magically generates everything else.
I don’t know if this is a good idea, but it’s been pretty fun so far. :-)
There are also derive-macro-powered crates to do GraphQL, other flavors of SQL, WASM bindings, etc etc.
Just to drive the point home, serde does solve the n^2 → 2n problem: serialized data is first deserialized to serde's intermediate data model (consisting of, like, 30 or so different types), from which a bespoke Rust object is produced. So you define how your types (de)serialize oblivious to the fact that serde_json, say, will be on the other end doing the actual (de)serialization.
This is nice. I started to learn Cloudflare Workers a few months ago, and used TypeScript for my project. Since I was to this platform, I relied heavily on the TS types and tab completion in my IDE to explore the APIs and to make sure I was using them correctly. Unfortunately there were several gaps which lead to a less-than-ideal development experience and general confusion.
The story around types in Workers should be leaps-and-bounds better than it was a few months ago (thanks to the work outlined in this blog post) - would love to hear your thoughts on this new work, and hope it helps!
Generated types are fine (if a bit cumbersome) when you trust input. When you don’t, “parse [don’t validate]” and produce static types at the place where input becomes a known quantity.
You can brag about your automation, when it is well tested.
https://github.com/cloudflare/workers-types/issues/116