11 ms·
Ron: Rusty Object Notation
- ayhanfuat 4y agoIs it yet another markup language?
- Ygg2 4y agoThat's YAML. This is object notation.
- ayhanfuat 4y agoYes, it was a tongue-in-cheek reference to YAML.
- Findecanor 4y ago"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.
- pzmarzly 4y agoCan it parse Rust debug output (dbg!() or {:?}) back into original data?
- the_mitsuhiko 4y agoUsually 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 https://crates.io/crates/darrentsung_debug_parser
- codeflo 4y agoIt’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.
- junon 4y agoI could output `ksdjflaskjdflkajsdf` every time my custom structure is Display'd or Debug'd. There's no sense in trying to parse that output.
- sfvisser 4y agoWe’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 4y agoCan you show examples? What you say is intriguing.
- maxloh 4y agoWhat's worng with YAML? It seems to be the best of the kind I have seen.
- Ygg2 4y agoWhat isn't wrong with YAML? But first a quiz of two YAML documents. Yaml#1 : Yaml#2 : Is any of these two docs valid. If yes, why, if not, why not. Edit: To be succinct (assuming Yaml 1.2), what is wrong with YAML are string types, weird quoting rules, attempts to be JSON, really bizzare user friendliness rules causing really bizzare edge cases, lookahead & lookbehind being essential for Yaml, very context sensitive, and complicated to the Xth degree (where X approaches infinity). Yaml feels like it can't decide whether it wants to be whitespace sensitive (human readable but not editable) or whitespace insensitive (mostly human readable and human editable).
- Ygg2 4y ago9 hours and no solution. And this is second time I post this. Goes to show how surprising YAML is, which is it's worst property.
- lioeters 4y agohttps://noyaml.com/ https://noyaml.com/
- the_mitsuhiko 4y agoRon 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/ https://insta.rs/) in some projects.
- pveierland 4y agoSweet, it supports trailing commas! Single biggest personal JSON annoyance.
- codethief 4y agoThat, and comments! Personally, I really hope Human JSON, https://github.com/tailscale/hujson https://github.com/tailscale/hujson , will get more popular!
- higherhalf 4y agoThere's also JSON5 https://json5.org https://json5.org
- ranting-moth 4y agoJSON initially had comments. https://www.freecodecamp.org/news/comments-in-json/ https://www.freecodecamp.org/news/comments-in-json/ They were removed from the standard because some were using them for custom parser directives.
- MereInterest 4y agoI feel like that is throwing away all the advantages of comments with any benefits. If somebody wants to add parsing directives, they could still be added through specific keys or strings.
- capableweb 4y agoThat'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"}`?!
- Drakim 4y agoNot a fan, it looks kinda alright when you are using a string like that, but {num 5, val 4} looks alien to me. If you used this style in a programming language you'd even get {num var} which is even worse.
- _vbnz 4y agoI wish this were more commonly used - just having comments is so useful! Are there already parsers available for Scala, Python, Java, etc.?
- amelius 4y agoWhy can't we just save Rust data-structures in a memory-mapped file? That would make saving and loading much more efficient, and it would also make programming much more convenient.
- 0dayz 4y agoI would encourage you to try and make that idea happen.
- habitue 4y agoI mean, you can, if there are no pointers. But then you still need to verify the layout when you reload it etc. Once you solve the various edge cases, this is basically what flatbuffers and capnproto are
- j-pb 4y agoThe information what datastructures are in memory is based on compile time static analysis data, you wouldn't know what you're loading without some additional data annotations. It would also require unreasonably fixing memory layout implementation details between versions.
- amelius 4y agoBut these are things Rust can solve for the programmer! It can add annotations to the data and even provide versioning.
- tialaramex 4y agoYou can do this, but only if you know exactly what that state means. In practice this is almost certainly too fragile to be useful. If you change anything you probably invalidate your understanding of this data and cause chaos. Rust's in memory data structures don't have any meaning on their own, they only have meaning in the context of the running program. This is, in fact, the whole point of the New Type Idiom. If I have two types Minutes(u32) and Years(u32) those are represented in memory the same way, an unsigned 32-bit integer, just four bytes. But because Rust is statically Type Checked, everywhere the programs knows which is which, you can't assign a Minutes to a Years, or a Years to a Minutes, for the same reason you can't assign "Hacker News" to an f64. But this means a 32-bit value in your hypothetical file could be either a Minutes or a Years, and a program loading that file needs to know a priori which it is. Once you start coming up with rules about how you'd do that, you're inventing a serialisation format, and you're exactly back to the problem where your original question arose.
- andrewstuart 4y agoNothing will ever unseat JSON because whilst it's crap, it's good enough. The toughest competition in the universe is a "good enough" competitor.
- jasfi 4y agoStartups competing against an existing, good enough competitor have this problem too.
- hyperthesis 4y agoThey thought that about XML, and ASN.1, and...
- russtrotter 4y agoAgreed with this general notion however, I'd argue that unlike a standards body, a big driver for JSON's ascent to defacto standard were the legions of javascript developers working at every layer of a tech stack using it as a low-friction means to an end.
- noctune 4y agoJSON 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.).
- cassepipe 4y agoLet's not forget KDL! : https://kdl.dev/ https://kdl.dev/
- GrumpySloth 4y agoFor inter-machine communication TLV binary formats are far superior. Simplicity of parsing, efficiency. Can't compete.
- 4y ago
- habitue 4y agoA 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 4y agoMoreso that semantically hashmaps are collections and structs arent. Structs are single items with a fixed number of properties.
- cies 4y agohashmap'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).
- orthoxerox 4y agoWhy have mandatory commas at all? Both Ron and JSON can be parsed unambiguously without commas.
- juliangmp 4y agoLooks neat but honestly I think I'll stick with toml for config files
- cies 4y agoWho 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...)
- account-5 4y agoHaha, quickstart requires toml.
- hyperthesis 4y agoThe 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 4y agoThose advantages also apply to lua tables, fwiw.
- deleted 4y ago[deleted]
- barrenko 4y agoLooks like something I'd like to crunch with Clojure.
- vkakade 4y agoThe 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.
- Hizonner 4y agoThere is not enough hatred in the world for the people who keep proliferating these.
- hnarn 4y agoFrom 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 4y agoAgreed. 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 4y agoHuh? It reduces the logic needed to write the format.
- Tuna-Fish 4y agoThe big reason for potential users is likely this one: > It's designed to support all of Serde's data model
- t43562 4y agoAn 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?
- Patrickmi 4y agoHonest truth, this is only going to side projects I wouldn’t even think of bringing this to production, it’s cool tho
- djedr 4y agoAs 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 https://jevko.org [1] https://gist.github.com/djedr/4eeac1de466512ec211ff17cfd1f5e77 https://gist.github.com/djedr/4eeac1de466512ec211ff17cfd1f5e...
- singularity2001 4y agomaterials: { "metal": … are the second quotes optional?
- pezezin 4y agoThey are not. Materials is an identifier, the name of a struct field, while "metal" is a string literal, the key of a dictionary.
- tetromino_ 4y agoWhat 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 4y agoNone. 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/484fcab0686dfd18c7e29b6c1815c5f74f6c6db4/examples/decode_file.rs#L27 https://github.com/ron-rs/ron/blob/484fcab0686dfd18c7e29b6c1..., where it (in a type-inferency way) says “parse as Config”.
- tetromino_ 4y agoI appreciate the response, but the link you gave only states that the value returned by from_reader is strongly typed; it says nothing about what from_reader might be doing internally before it returns that value. The actual answer seems to be https://github.com/serde-rs/serde/issues/1087#issuecomment-343030233 https://github.com/serde-rs/serde/issues/1087#issuecomment-3... - no security implications if no manually implemented Deserialize impls linked to by your application have security implications.
- chrismorgan 4y agoWell that’s just common sense. You write the deserialiser, it’s your responsibility. It’s no security implication in Serde or Ron.
- tetromino_ 4y agoThe interesting part is that it's also your responsibility to audit deserializer code in your dependencies.
- 4y ago
- ronyeh 4y agoBookmarked 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 https://github.com/tc39/proposal-json-superset
- fb03 4y agoI am using RON in a gamedev experiment I'm doing and it's great for live reloading of stuff