This vs JTD?
Show HN: Skir – like Protocol Buffer but better
51–60 of 69 posts
Re: Show HN: Skir – like Protocol Buffer but better
#52> 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…
[flagged]
Re: Show HN: Skir – like Protocol Buffer but better
#53> 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…
[flagged]
Thanks for the comment. I am very familiar with Buf+Protobuf, I think it's a great system overall but has many limitations which I think can be overcome by redesigning the language from scratch instead of building on top of the .proto syntax.
In the Skir vs Protobuf part of the blog post [https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t...], only 2 out of 10 pertain to "syntax" (and they're a bit more than syntax). Since you mention compatibility check, Buf's compatibility check prevents message renaming, which is a huge limitation. With Skir, that's not the case. You also get the compatibility checks verified in the IDE.
Re: Show HN: Skir – like Protocol Buffer but better
#54Looks really like Prisma to me: https://www.prisma.io/docs/orm/prisma-schema/overview#exampl... Why build another language instead of extending an existing one?
I looked at Prisma, I very much prefer the Protobuf/Thrift model of using numbers to identify fields, which allows 2 important things: fields to be renamed without breaking backward compatibility, and a compact wire format.
I think the Protobuf language (which Skir is heavily influenced by) has some flaws in its core design, e.g. the enum/oneof mess, the fact that it allows spare field numbers which makes the "dense JSON" format (core feature of Skir) harder to get, the fact that it does not allow users to optionally specify a stable identifier to a message to get compatibility checks to work.
I get your point about "why building another language", but also that point taken too far means that we would all be programming in Haskell.
Re: Show HN: Skir – like Protocol Buffer but better
#55Earlier quoted context omitted.
[flagged]
Thanks for the comment. I am very familiar with Buf+Protobuf, I think it's a great system overall but has many limitations which I think can be overcome by redesigning the language from scratch instead of building on top of the .proto syntax. In the Skir vs Protobuf part of the blog post [ https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t... ], only 2 out of 10 pertain to "syntax" (and they're a bit more t…
Sorry, you are wasting your time arguing, I am pretty sure this "user" is an LLM.
edit: Apparently not!
Re: Show HN: Skir – like Protocol Buffer but better
#56Earlier quoted context omitted.
Thanks for the comment. I am very familiar with Buf+Protobuf, I think it's a great system overall but has many limitations which I think can be overcome by redesigning the language from scratch instead of building on top of the .proto syntax. In the Skir vs Protobuf part of the blog post [ https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t... ], only 2 out of 10 pertain to "syntax" (and they're a bit more t…
Sorry, you are wasting your time arguing, I am pretty sure this "user" is an LLM. edit: Apparently not!
[flagged]
Re: Show HN: Skir – like Protocol Buffer but better
#57I had my fair share of frustration with proto as well. I appreciate in Skir
GH style import. This is a big one I wish proto had in the first place. The entire idea of a proto registry feels reactive to me when, ideally, you want to pull in a versioned shared file to import that is verified by the compiler long before serve or client verifies the payload schema.
Schema validation and compatibility checks on CI. Again a big one and critical to catch issues early.
Enums done right... No further comment required.
I think with some more attention to details e.g. hammering out the gaps some other comments have identified and more language support e.g. Rust, Go, C# this can actually work out over time.
Here is an idea to contemplate as a side gig with your favorite Ai assistant: A tool to convert proto to Skir. Or at least as much as possible. As someone who had to maintain larger and complex proto files, a lot of proto specific pain points are addressed.
The only concern i have is timing. Ten years ago this would have been a smash hit. These days, we have Thrift and similar meaning the bar is definitely higher. That's not necessarily bad, but one needs to be mindful about differentiation to the existing proto alternatives.
I hope this project gains trajectory and community especially from the frustrated proto folks.
Re: Show HN: Skir – like Protocol Buffer but better
#58That “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 don't know the reason TextFormat was invented, but in practice it's way easier to work with TextFormat than JSON in the context of Protos. Consider numeric types - JSON: number aka 64-bit IEEE 754 floating point Proto: signed and unsigned int 8, 16, 32, 64-bit, float, double I can only imagine the carnage saved by not accidentally chopping of the top 10 bits (or something similar) of every int64 identifier when it…
JSON is slightly worse than you describe - the JSON language doesn’t restrict you to 64bit floats, but most implementations do as you describe. On the other hand, the JSON language doesn’t support NaNs or infinities, so the union of language and implementation means that in practice JSON is strictly weaker than IEEE 754.
Re: Show HN: Skir – like Protocol Buffer but better
#59Definitely interesting and seems to be a nice improvement over Protobuf. Especially for Python, Protobuf bindings for Python were made probably after taking a lot of hallucinogenic drugs.
I like constants, great addition.
Things that I'll miss:
1. Oneof fields. There are enums, but it looks like it's not possible to have ad-hoc onefos?
2. Streaming requests/responses.
3. Introspection and annotations.
4. Go bindings.
Re: Show HN: Skir – like Protocol Buffer but better
#60Earlier quoted context omitted.
Thanks for the comment. I am very familiar with Buf+Protobuf, I think it's a great system overall but has many limitations which I think can be overcome by redesigning the language from scratch instead of building on top of the .proto syntax. In the Skir vs Protobuf part of the blog post [ https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t... ], only 2 out of 10 pertain to "syntax" (and they're a bit more t…
Sorry, you are wasting your time arguing, I am pretty sure this "user" is an LLM. edit: Apparently not!
They are using an LLM. I've seen accounts that are very obviously LLM bots, but have a human in the loop to reply when you accuse them. Then, of course, they go back to posting obvious LLM text.