3 ms·
> 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-
by dewey 8mo ago
> 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 https://buf.build/plugins/typescript does for Protobuf already, with the advantage that you can just keep Protobuf and all the battle hardened tooling that comes with it.
- deleted 8mo ago[deleted]
- nine_k 8mo agoThe 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.
- waynesonfire 8mo ago[flagged]
- nine_k 8mo agoIf you are fine enough with protobufs so that you're not actively looking for alternatives, maybe you should not spend the effort.
- gepheum 8mo ago+1 Copying from blog post [https://medium.com/@gepheum/i-spent-15-years-with-protobuf-then-i-built-skir-9cf61cc65631?postPublishedType=repub https://medium.com/@gepheum/i-spent-15-years-with-protobuf-t...]: """ Should you switch from Protobuf? Protobuf is battle-tested and excellent. If your team already runs on Protobuf and has large amounts of persisted protobuf data in databases or on disk, a full migration is often a major effort: you have to migrate both application code and stored data safely. In many cases, that cost is not worth it. For new projects, though, the choice is open. That is where Skir can offer a meaningful long-term advantage on developer experience, schema evolution guardrails, and day-to-day ergonomics. """
- gepheum 8mo agoSkir 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-then-i-built-skir-9cf61cc65631?postPublishedType=repub 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.
- hrmtst93837 8mo ago[flagged]
- gepheum 8mo agoThanks 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-then-i-built-skir-9cf61cc65631 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.
- danlitt 8mo agoSorry, you are wasting your time arguing, I am pretty sure this "user" is an LLM. edit: Apparently not!
- hrmtst93837 8mo ago[flagged]
- AlexeyBelov 8mo agoThey 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.