Ziggy: Data serialization language for expressing API messages, config files
ziggy-lang.io
ziggy-lang.io
Hi all, author here, just a quick warning: the version is v0.0.1 for a reason.
I developed Ziggy as part of my work on the Zine static site generator (https://zine-ssg.io) and, while I do believe there’s something to improve over JSON (as I stated in the frontpage copy, and other documentation pages) at least for my own usecases, I have developed Ziggy up to the point of being usable from Zine and then went back to work on the SuperHTML templating language / html language server.
I will do in the near future a second round of polishing on Ziggy and smooth out some things I’m unhappy with (e.g. custom string literals and how those interact with enums in particular), so beware that Ziggy has to compete for resources with the rest of the Zine ecosystem… and a lot of things in the Zine ecosystem require more work still.
Someone should make a zaggy, which would be data isomorphic to Ziggy, but like yaml, minus all the stupid shit in yaml (like prohibiting Norwegian use)
I also quite like the statement
Alpha, using Ziggy now means participating in its development.
It is neither, "go-away, it's not ready", nor boldly proclaiming to be more than it is. It encourages engagement.
I suspect I'll always find it ever-so-slightly unsatisfying because I really want the token to be `\\ `, and it's just `\\`. I don't want those backslashes touching my text!
It's probably the better rule, I say, gritting my teeth slightly, because if you want the text indented, let's say four spaces, making sure it's actually five is annoying and easy to forget. But ugh I don't like looking at unindented multi-line Zig text. Imagine leaving no space between `//` and a comment, I would never. Never!
Eh. You get used to it.
I usually do this when I out-comment single lines of code. That way I can grep for `//[^ ]` to find lines that are out-commented code, as opposed to being actual comments for humans.
It also helps the readability in the case where a comment for humans is followed by out-commented code, to distinguish where the comment for human ends.
why should i prefer this over protobuf?
For Ziggy to be competitive vs protobuf it would need more machinery for managing schema changes, which currently is not there at all.
I'm currently writing an application where I'm doing binary serialization of data and I'm not sure yet how that should play into Ziggy, but as I explore my use cases more I will change Ziggy accordingly.
That said, I will probably always err on the side of small scale, so it might very well never become a format worth considering vs protobuf. We'll see.
It's schemaless, so the binary format can't be as effecient as protobufs, but IMO the minor overhead is worth not paying the costs protobuf has to.
The text format (which is interoperable) is a strict superset of JSON that resolves many of the issues ziggy tackles (tagged unions, comments, verbosity, multiline strings), although not quite as prettily for configs.