Reposting my comment from when Ziggy came up on Lobsters:
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 think I like it, The multi-line \\ I'm not so sure about, but it means you can indent multi-line fields without screwing up the content. I guess it's only when manually creating entries that you get annoyed by typing the same characters over and over.
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.
Double-backslash for multiline literals is standard Zig and it takes a bit of getting used to.
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!
> Imagine leaving no space between `//` and a comment, I would never. Never!
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.
In the language I've implemented, I use significant whitespace for multiline strings and no leader is necessary. Having a leader almost defeats the purpose of multiline string syntax for me.
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.
Reposting my comment from when Ziggy came up on Lobsters:
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.
This looks great. Thank you for your work on Zig.
Looks great.
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 think I like it, The multi-line \\ I'm not so sure about, but it means you can indent multi-line fields without screwing up the content. I guess it's only when manually creating entries that you get annoyed by typing the same characters over and over.
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.
Double-backslash for multiline literals is standard Zig and it takes a bit of getting used to.
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.
> Imagine leaving no space between `//` and a comment, I would never. Never!
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.
In the language I've implemented, I use significant whitespace for multiline strings and no leader is necessary. Having a leader almost defeats the purpose of multiline string syntax for me.
the bytes type seems awkward. a compromise that leaves noone happy
why should i prefer this over protobuf?
I would prefer this over JSON.
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.
If you haven't seen it, I'd recommend checking out Amazon's Ion data format: https://amazon-ion.github.io/ion-docs/
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.
Is Ziggy anyhow related to Zig, the programming language?
Yes. The author is a Zig Foundation guy, the reference implementation is in Zig, and the syntax borrows from Zig.