Consider Rusty Object Notation (RON) for settings?

[xpe]

Check for existing issues

• Completed

Describe the feature

I recommend supporting Rusty Object Notation (RON) for Zed settings. If I had to pick one reason it would be this: to reduce the impedance mismatch between settings and code.

Motivation

In terms of community feedback, given that Zed is written in Rust, I think adoption of a settings.ron format would be welcomed.

I understand Zed is growing and changing quickly, with many ideas competing for adoption and developer time. This particular idea would be a small step towards embracing the best tooling available in the Rust ecosystem. From what I can tell, the Zed code and team embodies these ideas. Being willing to break free of purely inertial conventions is an important value to embody in a young project like Zed. 🚀

Comparison with JSON

Here are some advantages over JSON, taken from the "Why RON" section of the RON README:

• 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)

There are two key limitations of RON versus JSON -- which could be rectified:

1. At present, I don't know of something analogous to JSON Schema for RON. (If there is interest in using RON, I would be happy to start designing ideas for a RON Schema, and I'm confident others would help.)

2. In my experience, RON parsing errors could stand some improvement. Again, more eyes can solve this problem.

[jansol]

Related to 1: what is the tooling state for RON in general? For example currently we have LSP suggestions based on the schema while editing the config file, which is a huge usability feature. Additionally it's easy to faff about with the JSON using external tools such as nushell, jq, etc, which I am not familiar with RON equivalents of?

As for schemas, looks like there is not much going on upstream yet: ron-rs/ron#470

[maxbrunsfeld]

I can see the appeal of RON, but I think it's not widely-used enough to be an improvement over JSON for most users.

I worry it would be confusing to support multiple different settings file formats, and I don't think RON's benefits outweigh its drawbacks.

[xpe]

@maxbrunsfeld I am familiar with the argument. At the same time, this kind of thinking runs the risk of letting inertia (what is best for the product designers and maintainers) masquerade as "what is best" overall.

"What is best" isn't about features in isolation. If you want your product to be the best, not just be "good enough", you have to think about the cumulative, combined effect of small improvements. See https://jamesclear.com/marginal-gains:

The Aggregation of Marginal Gains

It is so easy to overestimate the importance of one defining moment and underestimate the value of making small improvements on a daily basis. Too often, we convince ourselves that massive success requires massive action. Whether it is losing weight, building a business, writing a book, winning a championship, or achieving any other goal, we put pressure on ourselves to make some earth-shattering improvement that everyone will talk about.

Meanwhile, improving by 1 percent isn’t particularly notable—sometimes it isn’t even noticeable—but it can be far more meaningful, especially in the long run. The difference a tiny improvement can make over time is astounding. Here’s how the math works out: if you can get 1 percent better each day for one year, you’ll end up thirty-seven times better by the time you’re done. Conversely, if you get 1 percent worse each day for one year, you’ll decline nearly down to zero. What starts as a small win or a minor setback accumulates into something much more.

I'm well aware that "businessy" books run the risk of being trite. Many use cherry-picked examples. Despite all this, Clear's book is very well grounded.

On the subject-level: The tooling around JSON makes it tolerable, but it is certainly not the best, in the sense of what we want from a configuration language. I've suffered at the hands of JSON many times. It has become one defacto standard for web APIs, but it doesn't have to be this way for a new product built in Rust. RON is quite fantastic, and could be improved yet. (Zed could help it BTW.)

The longer Zed stays with JSON, the longer it locks in -- and pays the price for --- this impedance mismatch. The project will pay the price a little bit at a time. Complexity snowballs unless actively fought. Short-term convenience has a tendency to win and bog down projects a little bit at a time.

Of course I'm not in charge and I could be making a recommendation that isn't the right call at this time? If so, what is the approach that world-class software projects take? How do you fight entropy, build a great product that is easy to maintain and change?