undefined | Better HN

0 pointssteveklabnik11y ago0 comments

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

0 comments

nirvdrum11y ago

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.

steveklabnikOP11y ago

> 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.

nirvdrum11y ago

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.

1 more reply

mercurial11y ago

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

1 more reply

j / k navigate · click thread line to collapse

0 comments

nirvdrum11y ago

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

steveklabnikOP11y ago

> 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:

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.

nirvdrum11y ago

1 more reply

mercurial11y ago

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

1 more reply

j / k navigate · click thread line to collapse