Sounds interesting as a format, but the implementation is a big supply-chain attack risk if you're not already in the JVM ecosystem.

This is because the only implementation is written in Kotlin. There are Python and Rust packages, but they both just link against the Kotlin version.

How do you build the Kotlin version? Well, let's look at the Rust package's build.rs:

https://github.com/kson-org/kson/blob/main/lib-rust/kson-sys...

It defaults to simply downloading a precompiled library from GitHub, without any hash verification.

You can instead pass an environment variable to build libkson from source. However, this will run the ./gradlew script in the repo root, which… downloads an giant OpenJDK binary from GitHub and executes it. Later in the build process it does the same for pixi and GraalVM.

The build scripts also only support a small list of platforms (Windows/Linux/macOS on x86_64/arm64), and don't seem to handle cross-compilation.

The compiled library is 2MB for me, which is actually a lot less than I was expecting, so props for that. But that's fairly heavy by Rust standards.

▲

wofo 2 days ago | parent | next [-]

Glad you liked the format. I hope we can close the implementation gaps as development advances, and I'd love to see native libraries sprout for all conceivable programming languages!

Edit: point taken about verifying checksums, just created an issue for it (https://github.com/kson-org/kson/issues/222)

▲

Terr_ 2 days ago | parent | prev [-]

Past-me had hoped that by the Future Year 2025, it'd be typical to publish a parser grammar file for this kind of thing.

Both to bootstrap making a parser in a new language, and also as a kind of living spec document.

	▲	wofo 2 days ago \| parent [-]
		I think the current grammar should be precise enough for that, though it's embedded in the source code as a comment and not in its own file (see https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5...). It probably can't be fed verbatim into a parser generator, but anyone who reads the parser's source code should have an easy time writing a parser by hand for their programming language of choice (heck, they might even have an LLM translate the original parser into whatever language they want, once there is a comprehensive conformance test suite to validate the resulting code). All in all, I'm confident that KSON can become ubiquitous despite the limitations of the current implementation (provided it catches on, of course).