[HN Gopher] KEON is a human-readable Serde format that is syntac...
___________________________________________________________________
KEON is a human-readable Serde format that is syntactically similar
to Rust
Author : eternal-io
Score : 35 points
Date : 2025-01-11 16:50 UTC (4 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| speed_spread wrote:
| 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 wrote:
| I think UCL is probably the best of all. Wish it had more than
| one implementation and formal specification.
| unshavedyak wrote:
| I too am curious. I like Ron quite a bit for it's Rust
| similarity.
| VyseofArcadia wrote:
| > 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.
| samtheprogram wrote:
| I find it really straightforward until lifetimes are involved.
| I used Rust for a few weeks last January.
| Klonoar wrote:
| 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.
| zamalek wrote:
| 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 wrote:
| 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 wrote:
| 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.
| craftkiller wrote:
| 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.
| Animats wrote:
| 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
| airstrike wrote:
| _> 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 wrote:
| 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 wrote:
| Because JSON is explicitly meant for machines only?
| Arnavion wrote:
| 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.
| yencabulator wrote:
| Item::IdCard > 101, // <- newtype variant.
|
| That looks _really_ weird.
| Philpax wrote:
| This is mostly just confusing to me. It's almost Rust syntax, but
| not quite, and the divergences away from Rust syntax don't really
| make sense (like the newtype syntax). What are the benefits of
| this over RON?
___________________________________________________________________
(page generated 2025-01-15 23:02 UTC)