gepheum

6 ms·

1. 1.▲
   Show HN: Skir, modern alternative to Protobuf, now supports 9 languages(github.com)

   3 points by gepheum 6mo ago|1 comments
2. 2.▲
   by gepheum 6mo ago

   The languages that Skir supports officially: C++, Dart, Go, Java, Kotlin, Python, Rust, Swift, Typescript Links: - Website: https://skir.build/ -- Skir Go doc: https://skir.build/docs/go -- Skir Rust d
3. 3.▲
   by gepheum 6mo ago

   I stand corrected.
4. 4.▲
   by gepheum 6mo ago

   flatbuffers and capnproto are in the game of trying to make serialization to binary format as efficient as possible. Their goal is trying to beat benchmarks: how long it takes to convert an object to bytes and vice-versa. It's cool, bu
5. 5.▲
   by gepheum 6mo ago

   Thanks for the comment! Agree with you about the horrible Protobuf-to-Python bidding, it was a big frustration and definitely contributed to me wanting to build Skir. 1. You can create an enum with just "wrapper" fields, that&#x27
6. 6.▲
   by gepheum 6mo ago

   Hey, thanks a lot for the comment! I share your frustration with protobuf: although I think it's great, it carries a few design flaws which are hard to fix at this point and they create pain points which are not going away. I completel
7. 7.▲
   by gepheum 6mo ago

   Hey, Skir does have numerical tagging, see https://skir.build/docs/language-reference#structs
8. 8.▲
   by gepheum 6mo ago

   Let's imagine you have this: ``` struct User { id: int64; email: string?; name: string; } ``` You store some users in a database: [10,"john@gmail.com""john"], [11,"jane",null,"john@gmail.com&quo
9. 9.▲
   by gepheum 6mo ago

   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
10. 10.▲
    by gepheum 6mo ago

    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
11. 11.▲
    by gepheum 6mo ago

    That is correct and that is a good catch, the idea though is that when you remove a field you typically do that after having made sure that all code no longer read from the removed field and that all binaries have been deployed.
12. 12.▲
    by gepheum 6mo ago

    +1 Copying from blog post [ 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 Pro
13. 13.▲
    by gepheum 6mo ago

    Thanks for the feedback. 0. Yes, I looked at Avro, Ion. I like Protobuf much better because I think using field numbers for field identity, meaning being able to rename fields freely, is a must. 1. Yes. Skir also supports that with binary f
14. 14.▲
    by gepheum 6mo ago

    Thanks. Definitely agree, will try to think about what that could look like.
15. 15.▲
    by gepheum 6mo ago

    Thanks! Main use case (similarly to Protobuf) is when you need to exchange data types between systems written in different languages. Like Protobuf, it can also be used in a mono-linguistic system, when you want to serialize systems and hav
16. 16.▲
    by gepheum 6mo ago

    Fair. I changed the tagline on the website to "A modern alternative to Protocol Buffer". Thanks for the feedback.
17. 17.▲
    by gepheum 6mo ago

    > 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
18. 18.▲
    by gepheum 6mo ago

    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 accou
19. 19.▲
    by gepheum 6mo ago

    Also, thank you for flagging the constant syntax problem (x = 600) on the website. Fixed.
20. 20.▲
    by gepheum 6mo ago

    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/@gephe
21. 21.▲
    by gepheum 6mo ago

    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#.
22. 22.▲
    by gepheum 6mo ago

    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 propertie
23. 23.▲
    by gepheum 6mo ago

    Absolutely, I am planning to add these 2 as well as C# by June. Working on it now.
24. 24.▲
    by gepheum 6mo ago

    It's not obligatory. Basically Protobuf gives you a choice between (1) binary format, (2) readable JSON. Skir gives you a choice between (1) binary format, (2) readable JSON, (3) dense JSON. It recommends dense JSON as the "defaul
25. 25.▲
    Show HN: Skir – like Protocol Buffer but better(skir.build)

    113 points by gepheum 6mo ago|64 comments
26. 26.▲
    Skir: Like Protocol Buffer but Better(skir.sh)

    2 points by gepheum 7mo ago|0 comments