KEON is a human-readable serde format that syntactic similar to Rust

31 points 16 comments 4 days ago

Animats

But why? It's roughly the same as JSON, but incompatible. Please, stop writing your own JSON variants.

Rust's serialization macro system allows you to write back ends for any format. I've written back ends for all three serialization formats used by Second Life.[1] (There's a binary form, an XML form, and something called "notation".) But other than for compatibility with existing code, there's no reason to use them.

[1] https://github.com/John-Nagle/serde-llsd

Arnavion

I know of one format that serde's system doesn't support well. D-Bus requires empty arrays to be aligned according to the type of their element, but serde's system has no way to tell the serializer any metadata about the type of an array element apart from giving it the array element to serialize. All the serializer gets to know that an array has started and then ended; it doesn't know anything about the element alignment unless it receives at least one element.

There is a sort of workaround - preload into the serializer what it is expected to serialize, eg by passing in the D-Bus signature string in the serializer ctor. But a) this is a somewhat unclean solution because everything other than arrays is redundant information that the serializer already gets from the serde::Serialize impl, and b) it's manual work for the user to have to specify this and easy to make a mistake and have the two get out of sync.

In my D-Bus library I decided to have my own Serializer setup as a workaround. serde's Deserializer setup still works though so that's not a problem.

airstrike

> But why?

It's literally in the README...

    • Less syntactic noise, more intuitive look.
    • Allow comments and trailing commas.
    • Write KEON almost like you write Rust:
        - Humanized optional type annotation.
        - Distinguishable between tuples and lists (seqs).
        - Arbitrary type as dictionary (map) keys.
        ...
    • Shorthand for newtypes.
    • Support use Base64, Base32 and Base16 to represent bytes.
    • Provide paragraphs may be helpful when writing something by hand.

JSON is pretty terrible. Its only real pro is the fact that it is widely used.

Rantenki

As a comparison, here's the "Why RON" for the native RON/Rust format:

Note the following advantages of RON over JSON:

  * trailing commas allowed
  * single- and multi-line comments
  * field names aren't quoted, so it's less verbose
  * optional struct names improve readability
  * enums are supported (and less verbose than their JSON representation)

I feel like they are close enough that it would be better to just use RON, which has existing uptake/tooling.

searealist

Because JSON is explicitly meant for machines only?

VyseofArcadia

> human-readable

> sytacticly similar to Rust

Choose one.

I kid, I kid, but Rust is not the easiest-reading language out there. It has the same problem as C++, with a syntax that's not terribly straightforward to begin with, but then it's just liberally sprinkled with nearly every bit of punctuation that can by typed with the US QWERTY layout.

zamalek

Rust is extremely unreadable if you're not used to it, but becomes one of the most readable languages once you are. My subjective experience, at least.

cloud-oak

With some notable exceptions. I'll never love the turbofish [1] for example.

[1] https://github.com/rust-lang/rust/blob/master/tests/ui/parse...

nu11ptr

I love Rust, but would disagree. It is always difficult to read partially because there is so much boilerplate. impl blocks and where clauses in some codebases cause a lot of noise, for example. Granted, it probably could not be as easy to read as say a subset of Python is, for example, simply because it is a very strongly typed systems language and therefore needs to describe a lot more.

Klonoar

Some of this is just preference at the end of the day.

I find modern Typescript to be utter spaghetti and arguably worse at the points you’ve listed here.

craftkiller

Well this project isn't the full rust syntax, its just rust's object notation. I don't think its any harder to read than JSON.

samtheprogram

I find it really straightforward until lifetimes are involved. I used Rust for a few weeks last January.

yencabulator

            Item::IdCard > 101,         // <- newtype variant.

That looks really weird.

speed_spread

Looks nice enough. How does it compare with RON? https://github.com/ron-rs/ron

More than a syntax, what I look for nowadays in a descriptive language is tooling, including a schema system, IDE plugins and library / build tool integration. Convenience makes it hard to dislodge the incumbents (toml, yaml, json).

0x457

I think UCL is probably the best of all. Wish it had more than one implementation and formal specification.

unshavedyak

I too am curious. I like Ron quite a bit for it's Rust similarity.