Notably missing both Go and Rust
Absolutely, I am planning to add these 2 as well as C# by June. Working on it now.
Show HN: Skir – like Protocol Buffer but better
11–20 of 69 posts
Re: Show HN: Skir – like Protocol Buffer but better
#12I spent some time in the actual compiler source. There's real work here, genuinely good ideas. The best thing Skir does is strict generated constructors. You add a field, every construction site lights up. Protobuf's "silently default everything" model has caused mass production incidents at real companies. This is a legitimately better default. Dense JSON is interesting but the docs gloss over the tradeoff: your ser…
> Minor thing that bothered me disproportionately: the constant syntax in the docs (x = 600) doesn't match what the parser actually accepts (x: 600).
You’re a better man than me. If the docs can’t even get the syntax right, that’s a hard no from me.
Also, fwiw, you’ve got a few points wrong about protos. Inspecting the binary data is hard, but the tag numbers are present. You need the schema, but at least you can identify each element.
Also, I disagree on the constructor front. Proto forces you to grapple with the reality that a field may be missing. In a production system, when adding a new field, there will be a point where that field isn’t present on only one side of the network call. The compiler isn’t saving you.
Fresh is more honest than better, and personally, I wouldn’t change it.
Re: Show HN: Skir – like Protocol Buffer but better
#13If I may suggest, Swift support will be more than appreciated, to consider it for a viable protocol for connecting backend with mobile applications.
Re: Show HN: Skir – like Protocol Buffer but better
#14I spent some time in the actual compiler source. There's real work here, genuinely good ideas. The best thing Skir does is strict generated constructors. You add a field, every construction site lights up. Protobuf's "silently default everything" model has caused mass production incidents at real companies. This is a legitimately better default. Dense JSON is interesting but the docs gloss over the tradeoff: your ser…
Thank you so much for taking the time to dig into the compile source code and the thorough comment you left.
For dense JSON: the idea is that it is often a good "default" choice because it offers a good tradeoff across 3 properties: efficiency (where it's between binary and readable JSON), persistability (safe to evolve shema without losing backward compatibility), and readability (it's low for the reasons you mentioned, but it's not as bad as a binary string). I tried to explain this tradeoff in this table: https://skir.build/docs/serialization#serialization-formats
I hear your point about the tagline "like protos but better" which I hesitated to put because it sounds presumptuous. But I am not quite sure what idea you mean to convey by "fresh"?
Re: Show HN: Skir – like Protocol Buffer but better
#15If I may suggest, Swift support will be more than appreciated, to consider it for a viable protocol for connecting backend with mobile applications.
Yeah totally fair. I targeted Dart because of Flutter, but I think I will include Swift in the next wave of languages, after Rust, Go and C#.
Re: Show HN: Skir – like Protocol Buffer but better
#16> Skir is a universal language for representing data types, constants, and RPC interfaces. Define your schema once in a .skir file and generate idiomatic, type-safe code in TypeScript, Python, Java, C++, and more. Maybe I'm missing some additional features but that's exactly what https://buf.build/plugins/typescript does for Protobuf already, with the advantage that you can just keep Protobuf and all the battle harde…
The entire original post, it seems, is dedicated to explaining why Skir is better than plain Protobuf, with examples of all the well-known pain points. If these are not persuasive for you, staying with Protobuf (or just JSON) should be a fine choice.
Re: Show HN: Skir – like Protocol Buffer but better
#17> Skir is a universal language for representing data types, constants, and RPC interfaces. Define your schema once in a .skir file and generate idiomatic, type-safe code in TypeScript, Python, Java, C++, and more. Maybe I'm missing some additional features but that's exactly what https://buf.build/plugins/typescript does for Protobuf already, with the advantage that you can just keep Protobuf and all the battle harde…
Skir has exactly the same goals as Protobuf, so yes, that sentence can apply to Protobuf as well (and buf.build).
I listed some of the reasons to prefer Skir over Protobuf in my humble opinion here: https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t...
Built-in compatibility checks, the fact that you can import dependencies from other projects (buf.build offers this, but makes you pay for it), some language designs (around enum/oneof, the fact that adding fields forces you to update all constructor code sites), the dense JSON format, are examples.
Re: Show HN: Skir – like Protocol Buffer but better
#18That “compact JSON” format reminds me if the special protobufs JSON format that Google uses in their APIs that has very little public documentation. Does anyone happen to know why Google uses that, and to OP, were you inspired by that format?
Re: Show HN: Skir – like Protocol Buffer but better
#19I spent some time in the actual compiler source. There's real work here, genuinely good ideas. The best thing Skir does is strict generated constructors. You add a field, every construction site lights up. Protobuf's "silently default everything" model has caused mass production incidents at real companies. This is a legitimately better default. Dense JSON is interesting but the docs gloss over the tradeoff: your ser…
Also, thank you for flagging the constant syntax problem (x = 600) on the website. Fixed.
Re: Show HN: Skir – like Protocol Buffer but better
#20That “compact JSON” format reminds me if the special protobufs JSON format that Google uses in their APIs that has very little public documentation. Does anyone happen to know why Google uses that, and to OP, were you inspired by that format?
I think you may be referring to JSPB. It's used internally at Google but has little support in the open-source. I know about it, but I wouldn't say I was inspired by it. It's particularly unreadable, because it needs to account for field numbers being possible sparse.
Google built it for frontend-backend communication, when both the frontend and the backend use Protobuf dataclasses, as it's more efficient than sending a large JSON object and also it's faster to deserialize than deserializing a binary string on the browser side. I think it's mostly deprecated nowadays.