I may not be a majority here, but I see JSON as a data transportation format, while I see TOML or YAML as configuration formats.

You cannot write comments in JSON, for instance.

You're not alone. YAML or similars are the right formats for these things, not JSON. Less clutter, comments separated from data, easier to read (by humans).

I don't really care what format the cargo files use (that's just an inconsequential bikeshed as far as I'm concerned) but in your example "comment" is really not a comment. I would expect to be able to put free-form comments anywhere I want and have them thrown away by the parser.

Your solution works fine for docstrings, but comments and docstrings are not the same thing (although many languages that don't support docstrings in the syntax hack them together using comments, admittedly).

But beyond that, what's the argument for switching to json? Is there some kind of intercompatibility with npm/Node.js to be gained?

Comments aren't just used to put notes in the file. They're also used to comment out code.

Also, having to quote everything makes writing JSON by hand a pain. Why would you want to use it over a nicer format?

It's sad to see that the guidelines about downvoting are clearly not respected.

YAML is a serialization format, not a configuration format.

It's really a configuration format that mistook itself for a serialization format.

What I wouldn't do for a cut-down YAML standard with most of the serialization crap cut out.

There isn't a lot of attachment to the exact manifest format used, but using json is clearly a step backwards!

JSON is annoying with the commas. One forgotten comma or comma too much and the whole file doesn't parse.

Because comments.

json is only marginally easier to edit by hand than xml. also, comments.

Yeah, why use some format that no one knows, and is harder to parse by other tools?

Not only that, but TOML is still considered unstable by its author. Granted, it hasn't been updated in several months. But that seems like a shaky foundation to be building on top of.

From: https://github.com/toml-lang/toml

"Latest tagged version: v0.2.0.

Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly."

While this is true, NOTHING in Rust-land is stable yet, so it's not as big a deal.

That's not really carte blanche to build everything on unstable technology. The point is things are supposed to be converging on stabilization. And a lot of what's unstable now is under the direct control of Rust. What TOML does or doesn't do is now a matter that needs to be worked out with Tom. It's not confidence-inspiring in the least.

If the plan is to jettison TOML, then it's simply just an odd choice to use for a first cut. And from a purely perception manner, seemingly reaffirms concerns some have had about the bundler team building cargo (right or wrong).

The plan isn't to jettison TOML, but even though it's 'unstable,' it hasn't changed in a very long time. And, given, uh, Tom, I doubt it will very much. He has better things to do these days.

I can see an argument for INI files, but TOML is basically INI with some extensions. And YAML (which has no Rust parser, and nobody who wnats to write one) and JSON (which does have one in the standard library) are very poor configuration formats.

Which one would you have preferred? It seems like a reasonable choice to me.

> And from a purely perception manner, seemingly reaffirms concerns some have had about the bundler team building cargo (right or wrong).

You could just spell out the personnel issues rather than being all FUDdy about it. (I'm friends with Yehuda, but also was room-mates with the current maintainer of Bundler (until very recently). Bundler isn't perfect, but lots of that had to do with people assuming a pre-1.0 project is stable, and upstream bullshit with RubyGems.)

That's a fairly weak argument. If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0. Otherwise you're opening yourself up to the exact same issue you outline as an issue for Bundler -- people assumping a pre-1.0 project is stable. As long as there's the option for someone to say "this is pre 1.0 so I can change it whenever" it's going to cause concern because most of us have been burned by that several times over. A de facto 1.0 release vs an actual 1.0 release.

As for the FUDdiness, there was another extensive comment thread here on HN when Cargo was announced. I didn't feel it necessary to re-enumerate all those concerns. And to the best of my recollection, the problems listed were all technical in nature, not personal. For my part, my list was:

https://news.ycombinator.com/item?id=7421629

But, I'm hardly alone in being concerned. This is something that will drastically influence the ecosystem. So, it should be met with some level of scrutiny. If it comes out passing muster, great. But that's not going to happen by being glib about things.

> If it's not going to change, then maybe some outreach should be done to get him to tag it 1.0.

Absolutely. Let me make an issue about that: https://github.com/rust-lang/cargo/issues/46 If he doesn't respond, I will email him.

> As for the FUDdiness...

Thanks! Since the points are enumerated, I can refute them:

> * You can't override a dependency:

You can, in modern Bundlers. But the transitive dependency issue is inherent to Ruby, not Bundler. Cargo will work like npm in this regard, not like bundler.

> Dependencies can disappear on you:

The central repository isn't built yet, but this is very valid. The reason that `gem yank` is still available to everyone is that you'd be surprised how often people push proprietary stuff up to RubyGems. It was removed for a while and caused a significant burden on the RubyGems team.

Regardless, yes, this is a serious consideration.

> It has weird rules:

Totally fair. Let's learn from that and make Cargo not have weird rules. :)

> * It promotes bad practices:

Yup, that's a Rails thing. Rust should be way better, as it doesn't have this kind of issue.

> * It's slow:

This actually has just as much to do with RubyGems as it does Bundler. See all of the presentations Andre has been doing recently, and the bundler-api project.

> * It was designed for MRI:

Quite fair. We only have one Rust implementation so far, but `cargo exec` won't be necessary.

------------------------

> So, it should be met with some level of scrutiny.

Absolutely! I don't mean to say "just take this without complaints." But without specific, actionable complaints, it won't get fixed. Please make as many specific, actionable complaints as possible, especially now, pre 1.0.

I think we wound up on the same page, even if a circuitous route. So I don't want to continue beating up on bundler. But I guess I'm going to take one more parting shot and mention that a lot of its execution performance is due to thor as well (at least when I've profiled). Using binstubs rather than "bundle exec" can be a good deal faster.

I feel compelled to mention it because this seems to be a clear case where an aesthetic DSL was chosen over performance and it can't really be fixed without a backwards-incompatible change. Rust and Ruby are two different beasts and I get that. I just hope that performance is a core design consideration for Cargo (I have no idea if it is or if it's just a nice-to-have).

Airing dirty laundry is hardly ever pleasant. I'm certainly not immune to my own set of WTFs. I legitimately just want to make sure Cargo comes out awesome. And I much appreciate Mozilla's commitment to having a standard dependency resolution tool when Rust ships.

Sounds good. I'll make one tiny parting shot to your parting shot, and we'll be done. :)

> Using binstubs rather than "bundle exec" can be a good deal faster.

Absolutely, which is why we switched to them with Rails. It is a tough problem, though, and given Ruby's constraints. In my testing, it's the startup time that's the issue, not Thor, which is because `bundle exec` has to re-start the interpreter multiple times, and binstubs don't. Anyway.

> I just hope that performance is a core design consideration for Cargo

Rust people already feel the pain of very long rustc compiles, so while I'm not sure that it's an overriding concern, given the Rust world's concern with performance in general, I expect it to be way better. Ruby has always kinda thrown performance to the wolves.

> I legitimately just want to make sure Cargo comes out awesome.

We all do. And I'll admit to being a bit sensitive to 'lol bundler,' which I feel is often said without fully understanding the problem space, which is admittedly large. Not that you are doing that, but I have seen similar comments elsewhere. Once you explain the details, it's pretty clear why Bundler does what it does.

Anyway, yes: let's make Cargo 1.0 and Rust 1.0 super awesome! I'm really excited that we're taking this step forward. It's a huge day for Rust.

I would like to take the opportunity to say that your fast, no-bullshit answers (and actions) are appreciated (in general the Rust community seems to foster this sort of positive attitude, carry on).

Thanks. I have a bit of an... obsessive streak when it comes to these kinds of threads. It works out, though it also means I didn't get a whole lot of other stuff done yet today...

I hope we can keep the Rust community mega positive and no-bullshit. Please let me know if I'm ever not being so.

> What TOML does or doesn't do is now a matter that needs to be worked out with Tom.

For what it's worth, I've just been brought on as a maintainer for TOML proper. Tom is still the guy though. Putting aside my involvement with Rust (<3), I also maintain the TOML library for Go, and I want to see an expedient path to 1.0 with minimal breakage. (There are lots of folks in the Go community already using TOML for things, including Mozilla's Heka project and CoreOS's `etcd` project.)

I saw that, based upon Steve's linked issue elsewhere in this thread. I think that's great and would go a long way in addressing some concerns here. Moving it to an organization is reassuring as well. Thanks for the update!

The read-manifest command seems to output a JSON of your Cargo.toml if you have tools you'd like to use that require it:

    cargo read-manifest --manifest-path .

I think that's a good point. Why use .toml when we have better alternatives already?

(I admit I have a bias against toml, but still...)

Which ones would that be?

YAML is quite mature, clean, is a superset of JSON so people could use JSON if they wanted, and it's used for config files for pub, Dart's package manager. TOML doesn't seem mature enough.

TOML is extremely simple. YAML on the other hand is incredibly hard to implement. JSON has no comments and is not really that nice for humans.

How about s-expressions :) ?

Or edn?

https://github.com/edn-format/edn

That would be my choice, but TOML is good enough for me :)

HOCON: https://github.com/typesafehub/config

toml is unstable and has no real spec + YAML has a well defined spec and is widely used?

YAML spec is also super complicated and writing parser for it is non-trivial (for comparisson YAML has ~150 EBNF rules while XML with DTD has about ~80)! I'm not comparing validation rules but they are probably about the same.

This complexity means there is already a parser for TOML, and not one for YAML. That's IMO main reason they went with TOML.

There are actually already MULTIPLE parsers for TOML in Rust, and Cargo switched between the two yesterday.

As you say, this is a testament to TOML's simplicity.

EDIT: Furthermore, TOML is going to have a 1.0 soon: https://github.com/rust-lang/cargo/issues/46