Ron: Rusty Object Notation

[andrewstuart]

Nothing will ever unseat JSON because whilst it's crap, it's good enough.

The toughest competition in the universe is a "good enough" competitor.

[noctune]

JSON is fine for inter-machine communication (like APIs). It's IMO terrible for human-to-machine communication (like configs), which is why there are so many alternatives trying to improve in this space (TOML, YAML, RON, etc.).

[the_mitsuhiko]

> Nothing will ever unseat JSON because whilst it's crap, it's good enough.

JSON is "secretly" being replaced by JSON5 in quite a lot of contexts. So I'm not sure that this is entirely accurate. The same was said about XML a long time ago and people claimed that XML will never be replaced. Yet today XML is barely used any more. Likewise TOML is showing up in more and more places were previously INI or YAML was the standard.

[sylware]

That's why open source is not enough anymore, we need _lean_ open source, and that stable in time.

Big Tech is based mostly on 2 related scams: planned obsolescence and grotesquely and absurdely massive and complex open source software/standards/protocols.

To protect us against them, is to go to simple but able to do a good enough job and stable in time protocol/standard/open source software/etc. You will need lawyers.

This is common sense, but many seem to lose it... more or less sincerely...

[kevincox]

I don't see this intended to unseat JSON. But it can be helpful for local testing and debugging of Rust projects. I wouldn't really expect this for general purpose serialization because JSON is more standard and for inner-app communication you can use something more compact.

I did actually use this in a project because it differentiates between nesting of Option. Particularly we were having some confusion of Some(None) and None and this helped our tests catch more issues. In production we used JSON. Serde makes it trivial for the same code to switch between formats.

[veidr]

While I think (and lament) that you are almost right -- that is, that ridding the world of the foul pestilence that is JSON it will take insanely longer than it should -- I do think it will come a bit sooner than the heat death of the universe.

The reason I think so is that so many JSON users are no longer actually using JSON. Although there are apparently several competing implementations still vying for the name "JSONC", one of those is the non-JSON format that allows comments used by VS Code (among many others), and it is spreading (often inadvertently).

This weakens JSON by diluting the meaning of the term (many users of this "JSON plus comments" think they are using JSON). The end result might be that we standardize on some "JSON+" type name, or that the meaning of "JSON" itself is diluted to include such superior mutations.

Either way is pain in the ass, though, because JSON is a human-readable format (I mean, not really, but in practice), but it is also a machine-to-machine format, so deviation from the spec is certainly unhelpful there.

But we got rid of Latin-1 and SJIS (for the most part), and I have hope that in the fullness of time, we'll get rid of JSON, too. (Probably not with RON, though.)

P.S. Nrwl guys, JSON config files are literally the most painful part of using Nx, and you should consider just using TypeScript, but if not, "VS Code style comments-enhanced JSON" would still be a massive improvement. :-D

[maze-le]

I wouldn't be so sure about that, I thought the same about XML in 2005...

[hyperthesis]

They thought that about XML, and ASN.1, and...

[IshKebab]

I think it will for config, simply because JSON doesn't support comments and that's really not an optional feature.

But I have tried lots of alternatives and none have as good tooling except maybe XML. Especially for schemas, which I think is really important.

I want JSON5 to succeed but there's no good IDE support really.

I also tried Dhall, which looks promising except they've imported all the super weird stuff from functional languages that are just going to put people off (e.g. the weird leading commas, and very odd way of declaring functions).

[iudqnolq]

I just wrote a little cli that takes JSON input, deserializes it into rust structs, serializes it into my custom binary protocol, sends it to my server I'm developing, and then does the reverse with the reply.

This looks like a nice replacement because it looks like the debug logs of my types. Plus it lets me specify numbers as hex.

[jasfi]

Startups competing against an existing, good enough competitor have this problem too.

[sfvisser]

We’re using something similar(ish) internally and it’s interesting how much more readable and expressive JSON can get by allowing Rust style constructors/tags for your data types.

Suddenly sum types become conveniently easy to express and understand, which is always incredibly awkward in JSON.

Besides that: tuples, tuple structs, comments, properly handling NaN, optional.

Really hope something like this takes over the role of JSON/yaml soon.

[pdimitar]

Can you show examples? What you say is intriguing.

[maxloh]

What's worng with YAML? It seems to be the best of the kind I have seen.

[habitue]

A big addition that json is missing a distinction for, which Ron has is the notion that hashmap and record/struct type are different. Hashmaps, you don't necessarily know what all the keys are. Structs, you know the keys and what type each key should be.

[mjburgess]

Moreso that semantically hashmaps are collections and structs arent. Structs are single items with a fixed number of properties.

[cies]

hashmap's a collection type, record/struct is a product type (tuple is another product type), many miss the sum type (incl JSON) sadly.

JS conflating the hashmap and record/struct is a big loss, probably fixed by TS. it does show JS's dedication to its radical dynamic typing discipline (or lack thereof).

[the_mitsuhiko]

Ron is quite practical if you are having a serializable interface, and you want to get debug like output from it for snapshotting purposes. I am using this with my insta snapshot testing library (https://insta.rs/) in some projects.

[pveierland]

Sweet, it supports trailing commas! Single biggest personal JSON annoyance.

[codethief]

That, and comments!

Personally, I really hope Human JSON, https://github.com/tailscale/hujson , will get more popular!

[capableweb]

That's a big pet peeve for me as well! Only thing remaining now is those pesky colons (edit: was semi-colons) that everyone and their mother seems to place in their new formats. Just get rid of them already!

Who wants to type `{name: "pveierland"}` when you could just do `{name "pveierland"}`?!

[hnarn]

From the repo:

> 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’m no fan of JSON but honestly, I think this is a very weak list of benefits if you’re trying to convince someone to switch.

[rwalle]

Agreed. I don't know why "trailing commas allowed" is a plus -- it is not going to make things simpler or easy to maintain, and it is very questionable whether the added flexibility is worth it

[Tuna-Fish]

The big reason for potential users is likely this one:

> It's designed to support all of Serde's data model

[djedr]

As long as we are on topic of JSON alternatives suitable for configuration, I've been tinkering with various minimal syntaxes and formats for a long time, most notably Jevko[0].

One format based on that I've been conjuring up recently would represent the first example from the RON README like so:

    GameConfig[ optional struct name
        window size [[800] [600]]
        window title [PAC-MAN]
        fullscreen [false]

        mouse sensitivity [1.4]
        key bindings [
            up [Up]
            down [Down]
            left [Left]
            right [Right]
            
            Uncomment to enable WASD controls
            ;[
            W [Up]
            A [Down]
            S [Left]
            D [Right]
            ]
        ]
        
        difficulty options [
            start difficulty [Easy]
            adaptive [false]
        ]
    ]

I put a syntax-highlighted version and some more details in this gist[1].

I wonder what you guys think about such a minimal alternative.

[0] https://jevko.org

[1] https://gist.github.com/djedr/4eeac1de466512ec211ff17cfd1f5e...

[orthoxerox]

Why have mandatory commas at all? Both Ron and JSON can be parsed unambiguously without commas.

[fb03]

I am using RON in a gamedev experiment I'm doing and it's great for live reloading of stuff

[t43562]

An Object notation for every language? Perhaps this is the way all languages will go but it seems a little bit retrograde.

e.g. Python Object Oriented Notation (POON) would have double quotes and True and False and "None" but otherwise be easily mistaken for JSON.

Scheme Object Notation Externtion (SCONE) would presumably just be a lot of brackets?

[dmytrish]

"Scheme object notation" is called s-expressions :)

I'd argue that toml can be called "a Python(ic) object notation" in some sense.

[_vbnz]

I wish this were more commonly used - just having comments is so useful!

Are there already parsers available for Scala, Python, Java, etc.?

[vkakade]

The biggest advantage of json is its ease-of-use. It is super easy to get started, and once you are start using it to build a quick prototype, you are stuck with it.

And the customers of your api understand it as well, so you likely need to support json even if you may use something else internally.

[ronyeh]

Bookmarked just because I like the name.... ;-D

So all JSON is valid (modern) JavaScript. [1]

Is RON valid Rust?

[1] https://github.com/tc39/proposal-json-superset

[hyperthesis]

The first three advantages are present in javascript, and removed for JSON:

    trailing commas allowed
    single- and multi-line comments
    field names aren't quoted, so it's less verbose

[krapp]

Those advantages also apply to lua tables, fwiw.

[juliangmp]

Looks neat but honestly I think I'll stick with toml for config files

[pzmarzly]

Can it parse Rust debug output (dbg!() or {:?}) back into original data?

[codeflo]

It’s not intended to do that, and I don’t think that would be possible in general. Debug output can be arbitrary and ambiguous, while this is a well-defined serialization format that only happens to have a readable Rust-like syntax. Of course you’re always free to use RON in place of debug output for logging purposes.

[the_mitsuhiko]

Usually not, because Rust's debug output is largely unstructured. There are some projects that are trying to do it though: https://crates.io/crates/darrentsung_debug_parser

[junon]

I could output `ksdjflaskjdflkajsdf` every time my custom structure is Display'd or Debug'd. There's no sense in trying to parse that output.

[cies]

Who needs TOML when we have this?

Also this is really cool when you want to upgrade your config file to a script!

It has comments! (looking at you JSON; pre-5 I know...)

[ayhanfuat]

Is it yet another markup language?

[Findecanor]

"Markup languages" are for documents. RON, YAML and JSON are data-oriented.

Even though YAML was named "Yet Another Markup Language" in the beginning, it changed to "Yaml Aint a Markup Language" to emphasise that.

[Ygg2]

That's YAML. This is object notation.

[tetromino_]

What are the security implications? It sounds like they might be feeding the config text directly into Serde - which means allowing potentially untrusted user input to instantiate arbitrary structs. That's a big attack surface.

[chrismorgan]

None. Serde is strongly, strictly typed: you have to specify what type you want to decode to. It’s nothing like Python’s Pickle protocol.

See, for example, https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1..., where it (in a type-inferency way) says “parse as Config”.