Output zig targets as ZON instead of JSON

[MasonRemaley]

As well as outputting ZON instead of JSON, this PR:

• Adds a few convenience functions to stringify to make this nicer
• Renames start*/finish* to begin*/end* in stringify
  • This is more consistent with the JSON API, and with other APIs out in the wild that follow this pattern
  • I didn't mark the old names as deprecated since they were live for such a short period, let me know if I should

I verified the output by diffing it with the JSON and glancing over it, and checking that it parses as ZON with the runtime parser.

The compile time parser on #22907 crashes on it right now, this is a bug there looking into it on that branch. (fixed)

[alexrp]

I guess this makes sense, though I'll be a little sad to see zig targets | jq -r .libc[] go... anyone want to implement zq real quick?

[MasonRemaley]

Hmm. If this reduces the utility of zig targets, it might make sense to wait--alternatively maybe it's good motivation for more tooling to be developed. I don't personally feel strongly either way.

(The changes to stringify.zig should probably make it in for 0.14 regardless, if we decide not to make this change I'm happy to pull them out.)

[Rexicon226]

Why not just have both? Put json behind a --json flag.

[tensorush]

I'll be a little sad to see zig targets | jq -r .libc[] go... anyone want to implement zq real quick?

Implemented very basic querying: https://codeberg.org/tensorush/zq

Examples (when run in zq repo):

$ zig build exe -- -i build.zig.zon -r .name
zq

$ cat build.zig.zon | zig build exe -- .dependencies.clap
.{
    .url = "git+https://github.com/Hejsil/zig-clap#e730233775300c0a8fe3137af880c7c58340930f",
    .hash = "12205ef27929fba18101750677ff579c0b6aff670755cacbbe6f2bc5f073622e1783",
}

zig targets would potentially work like this:

$ zig targets | zq -r .libc

[MasonRemaley]

@tensorush nice, this looks very useful!

[perillo]

What is the rationale for using ZON instead of JSON?

Thanks.

[MatthiasPortzel]

This change grates on me for two reasons. As mentioned, this is a breaking change with no rational, other than "Not invented here."

But second, because JSON is valuable as a data interoperability format. Even if ZON is suitable for serialization and deserialization, and even if it's nicer to work with from the perspective of the Zig programmer, I don't see it ever competing with JSON as a ubiquitous data exchange language. And I didn't think that was a goal. For programmatic output that is meant to be consumed by other tools, it makes sense to use a data format that is easy for those tools to understand.

Edit: This is a drive-by critical comment in an unimportant part of the compiler, so I just want to also say thanks to the Zig team for their work towards 0.14 and thanks to @MasonRemaley for their work on ZON.

[andrewrk]

The rationale is to promote zon as a data interchange format.

It's also nice to remove json dependency from the compiler.

[190n]

Looks like this didn't make it into the release notes.

[tsujp]

But second, because JSON is valuable as a data interoperability format.

JSON sucks for anything larger than a trivial-sized file. A good example that is easy to find is most package.json files in JavaScript projects. Thing's like LSP (Language Server Protocol) using JSON for data interchange that isn't intended to be read by humans add a dependency using a bad serialisation language and result in huge bottlenecks in LSP clients (and text editors) that must now optimise for JSON de(serialisation) or be forced to take on a dependency.

Even if ZON is suitable for serialization and deserialization, and even if it's nicer to work with from the perspective of the Zig programmer, I don't see it ever competing with JSON as a ubiquitous data exchange language.

"Even if (any systems-level language after C) is nicer to work with from the perspective of (said new systems-level language), I don't see it ever competing with C as a ubiquitous systems-level language".

We shouldn't stop trying to improve (sensibly) and exploring new ideas just because the new thing won't be ubiquitous. Yes, don't let perfect be the enemy of good enough but also don't let good enough halt any and all attempts at any exploration and progression.

For programmatic output that is meant to be consumed by other tools, it makes sense to use a data format that is easy for those tools to understand.

Then those other tools can add support themselves or via their users contributing it. Consider the opposite, Zig must be forced to add a dependency on JSON because... JSON is ubiquitous? Is that the only criterion for acceptance? XML was around before JSON and YAML which were both around before TOML and so forth.

I imagine your text editor can do more than open just ASCII files, perhaps we should dissolve Unicode and require all other non-ASCII formats to conform.

I don't want to start an argument here but I felt the need to comment because things like "it's popular so just use X" and "we shouldn't try new things" are bad mindsets that I think cause more harm than good and stifle progress that can potentially benefit everyone within the Zig ecosystem and outside of it.