4 ms·

Are there any benefits of Taxi over Protobuf (the language)?

eyelidlessness 4y ago
From the looks of it, documentation as a first class part of the schema definition, and enforceable, arbitrarily meaningful subtypes of scalars. There are tons of use cases for those features, which are achievable with Protobuf for struct-y types, but the advantage of using scalar subtypes is better integration into common host systems without gymnastics to wrap/unwrap the values.
- martypitt 4y ago
  Exactly. Also, the idea that those types can be embedded across multiple schemas is how you can describe cross-system interoperability, without requiring all systems to have the same Model for "Customer" or "Account"
Groxx 4y ago
Protobuf is rather (extremely?) weak type-wise, so a lot of it probably boils down to "it has reasonable / usable types". Like, it doesn't even have semantics for saying "this string is assumed to be a timestamp" in a way you can refer to in multiple locations, the best you can do is name your field "ThingTimestamp" and hope people get the right idea. This also seems to be describing a querying system, data mapping (e.g. for using csv data), runtime calculated data (likely used to drive the csv reading stuff), etc a number of other things that are less related to just data and more how to get that data, beyond just an RPC API described by types. E.g. the annotations and computed types could describe a fair number of sql queries in your data model, so you could probably just point it at a database with very minor "glue" code. Whether that second part is relevant probably depends on how much you want to write in your implementation language vs in taxi's language... but it's substantially different than protobuf in any case.
- gabereiser 4y ago
  Ummm... google.protobuf.Timestamp is a thing. Use it. Don't just throw an int32 at me and _say_ it's a timestamp. /s
  - Groxx 4y ago
    It's a struct which contains an int field, which iirc has more encoding, transfer, and decoding costs than an int (nobody cares when it's one, you might care when it's many thousands), and implies nullability because all message types are nullable. And unless you're using a Google-blessed code generator in a Google-blessed language, it's also noticeably more verbose to use[1]. But yes, you do indeed have user-defined structure (message) types in protobuf, and you can bend them quite far. There are also annotations of a sort, though support there seems worse, personally I've only very rarely been able to use them cross-language at all. [1] yeah, there are alternate code generators, but their support and quality is "mixed" to put it mildly. They do exist though, and many have a plugin system of some kind for making your own less-painful custom types.
- martypitt 4y ago
  Taxi is a documentation and query language, but not a runtime wire format. ie., you can't encode a message into Taxi and send it across the wire, like you can with Protobuf. Taxi is intended to work with protobuf, rather than replace it. The idea is teams work on the Taxi type system collaboratively, building a library of terms (FirstName / LastName / etc), which can be applied consistently across multiple team's schemas. Developers using Protobuf / OpenAPI / RAML / etc., can embed those terms directly into their existing schemas, to improve documentation, and describe interoperability between multple internal systems. (TeamA's field called "givenName" is the same data as TeamB's field called "FIRST_NAME") As I write this, I realize our docs are missing how to use Taxi with Protobuf, which is kinda embarrassing. There's examples documented elsewhere[0], but we need to get the Taxi docs updated! [0] https://docs.vyne.co/reference/message-formats/protobuf/#embedding-semantic-types-in-protobuf https://docs.vyne.co/reference/message-formats/protobuf/#emb...
  - Groxx 4y ago
    Yep, excellent point, I completely missed that it had no encoding specified. Thank you! That's mostly on me for skimming, don't take it as any kind of strong "docs should be more clear on this" signal :) Honestly I think this makes it more interesting... though I'm curious how it handles its generics in an agnostic way, as protobuf has some, but they're quite crippled. Or do you just have to know the limitations of your encoding and not use those features, and/or build your own translation layer to handle it? E.g. you can get pretty far with a double-encoded blob of bytes.
    - martypitt 4y ago
      Taxi has support for generics[0], but it's pretty nascent at the moment. Internally, the compiler understands the idea of a generic type A<B>, which is used for Array<T> and Stream<T>, as well as describing generic functions. I definitely think there's more we could do here, but haven't hit the usecase yet. Hit me up on Slack[1] if you wanna discuss ideas, as I'd love to hear more about what role generics can play. [0] https://docs.taxilang.org/language-reference/functions/#generic-types https://docs.taxilang.org/language-reference/functions/#gene... [1] https://join.slack.com/t/vyne-dev/shared_invite/zt-697laanr-DHGXXak5slqsY9DqwrkzHg https://join.slack.com/t/vyne-dev/shared_invite/zt-697laanr-...

From the looks of it, documentation as a first class part of the schema definition, and enforceable, arbitrarily meaningful subtypes of scalars. There are tons of use cases for those features, which are achievable with Protobuf for struct-y types, but the advantage of using scalar subtypes is better integration into common host systems without gymnastics to wrap/unwrap the values.

martypitt 4y ago
Exactly. Also, the idea that those types can be embedded across multiple schemas is how you can describe cross-system interoperability, without requiring all systems to have the same Model for "Customer" or "Account"

Groxx 4y ago

Protobuf is rather (extremely?) weak type-wise, so a lot of it probably boils down to "it has reasonable / usable types". Like, it doesn't even have semantics for saying "this string is assumed to be a timestamp" in a way you can refer to in multiple locations, the best you can do is name your field "ThingTimestamp" and hope people get the right idea. This also seems to be describing a querying system, data mapping (e.g. for using csv data), runtime calculated data (likely used to drive the csv reading stuff), etc a number of other things that are less related to just data and more how to get that data, beyond just an RPC API described by types. E.g. the annotations and computed types could describe a fair number of sql queries in your data model, so you could probably just point it at a database with very minor "glue" code. Whether that second part is relevant probably depends on how much you want to write in your implementation language vs in taxi's language... but it's substantially different than protobuf in any case.

gabereiser 4y ago
Ummm... google.protobuf.Timestamp is a thing. Use it. Don't just throw an int32 at me and _say_ it's a timestamp. /s
- Groxx 4y ago
  It's a struct which contains an int field, which iirc has more encoding, transfer, and decoding costs than an int (nobody cares when it's one, you might care when it's many thousands), and implies nullability because all message types are nullable. And unless you're using a Google-blessed code generator in a Google-blessed language, it's also noticeably more verbose to use[1]. But yes, you do indeed have user-defined structure (message) types in protobuf, and you can bend them quite far. There are also annotations of a sort, though support there seems worse, personally I've only very rarely been able to use them cross-language at all. [1] yeah, there are alternate code generators, but their support and quality is "mixed" to put it mildly. They do exist though, and many have a plugin system of some kind for making your own less-painful custom types.
martypitt 4y ago
Taxi is a documentation and query language, but not a runtime wire format. ie., you can't encode a message into Taxi and send it across the wire, like you can with Protobuf. Taxi is intended to work with protobuf, rather than replace it. The idea is teams work on the Taxi type system collaboratively, building a library of terms (FirstName / LastName / etc), which can be applied consistently across multiple team's schemas. Developers using Protobuf / OpenAPI / RAML / etc., can embed those terms directly into their existing schemas, to improve documentation, and describe interoperability between multple internal systems. (TeamA's field called "givenName" is the same data as TeamB's field called "FIRST_NAME") As I write this, I realize our docs are missing how to use Taxi with Protobuf, which is kinda embarrassing. There's examples documented elsewhere[0], but we need to get the Taxi docs updated! [0] https://docs.vyne.co/reference/message-formats/protobuf/#embedding-semantic-types-in-protobuf https://docs.vyne.co/reference/message-formats/protobuf/#emb...
- Groxx 4y ago
  Yep, excellent point, I completely missed that it had no encoding specified. Thank you! That's mostly on me for skimming, don't take it as any kind of strong "docs should be more clear on this" signal :) Honestly I think this makes it more interesting... though I'm curious how it handles its generics in an agnostic way, as protobuf has some, but they're quite crippled. Or do you just have to know the limitations of your encoding and not use those features, and/or build your own translation layer to handle it? E.g. you can get pretty far with a double-encoded blob of bytes.
  - martypitt 4y ago
    Taxi has support for generics[0], but it's pretty nascent at the moment. Internally, the compiler understands the idea of a generic type A<B>, which is used for Array<T> and Stream<T>, as well as describing generic functions. I definitely think there's more we could do here, but haven't hit the usecase yet. Hit me up on Slack[1] if you wanna discuss ideas, as I'd love to hear more about what role generics can play. [0] https://docs.taxilang.org/language-reference/functions/#generic-types https://docs.taxilang.org/language-reference/functions/#gene... [1] https://join.slack.com/t/vyne-dev/shared_invite/zt-697laanr-DHGXXak5slqsY9DqwrkzHg https://join.slack.com/t/vyne-dev/shared_invite/zt-697laanr-...