Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust and the limits of swarm design

esr.ibiblio.org

Post reply on HN
Print view View original

21–30 of 55 posts

Re: Rust and the limits of swarm design

#21

Post by Manishearth »

nxrabl wrote: post #15

>"A lot of Rustaceans don’t seem to grasp why, when the question is “where do I get feature X?” the answer “oh, there are 23 crates for that” is objectively terrifying." This is a real problem. Here's a blog idea: "Consumer Reports for libraries" (As an aside, the phrase "objectively terrifying" bugs the hell out of me. Terror is fundamentally subjective - it's a primal emotion. Please let's not let "objectively" bec…

FWIW, this is not as bad a problem as he makes it out to be -- the reason folks don't seem to grasp it's a problem is because from inside the community the answer is usually "there are 2 crates for that, with the following tradeoffs". You have to ask, however; and it's hard to find out which crate you want to use without asking someone.

This is still a problem, however, but it's one the community has been aware of for a while. https://github.com/rust-lang/rfcs/pull/1824 is step 1 in fixing it.

Re: Rust and the limits of swarm design

#22

Post by sidlls »

bluejekyll wrote: post #11
rst wrote: post #9

Earlier quoted context omitted.

He may be talking about NTP -- that is core infrastructure code that had been poorly maintained for many years, and he's been involved in the rescue effort. Points off for not saying so, though; without context, your reaction is pretty natural.

The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view. Rust has curation in its crate system. It's all in really good crowd sourcing numbers. Crates.io, number of downloads,…

> The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view.

One might easily argue that folks who criticize C and C++ for its ecosystem are also "attacking" it, by your reasoning. It detracts from the rest of your comment in my opinion (which isn't humble at all).

And "the Rust community" is not a monolithic entity. For example, I find "the Rust community" in aggregate here on HN, other than a relatively small few, to be rather caustic, aggressively defensive against criticisms of Rust, and a bit too handy with downvotes for disagreement of legitimate arguments against some of Rust's features, syntax, grammar, etc.

Re: Rust and the limits of swarm design

#23

Post by sidlls »

I can't say I agree with the author's first article (which he mentions in this one), but I think he has the kernel of a good argument here. That's not to say I agree with it entirely.

At some point "design by everyone" turns into "design by committee" by another name. This criticism of Rust has manifested itself in other ways, too. For example the amount of "unsafe" used in various crates (the idea being that "the community" will collectively minimize "bad" use of "unsafe"). In my view there's a tendency for some of Rust's advocates to simply assert that it will work itself out without presenting good reason to believe so.

Re: Rust and the limits of swarm design

#24

Post by sidlls »

Manishearth wrote: post #21
nxrabl wrote: post #15

>"A lot of Rustaceans don’t seem to grasp why, when the question is “where do I get feature X?” the answer “oh, there are 23 crates for that” is objectively terrifying." This is a real problem. Here's a blog idea: "Consumer Reports for libraries" (As an aside, the phrase "objectively terrifying" bugs the hell out of me. Terror is fundamentally subjective - it's a primal emotion. Please let's not let "objectively" bec…

FWIW, this is not as bad a problem as he makes it out to be -- the reason folks don't seem to grasp it's a problem is because from inside the community the answer is usually "there are 2 crates for that, with the following tradeoffs". You have to ask, however; and it's hard to find out which crate you want to use without asking someone. This is still a problem, however, but it's one the community has been aware of fo…

"Inside the community" isn't a very strong argument in my opinion, because there is a strong bias. Folks "inside the community" are developing Rust packages because they really, really enjoy it. This is much different from having a mature language where folks who aren't as gung-ho about it develop things (out of curiosity, because work made them, etc.).

I understand there's a recognition of the problem, and I think it's great that it's on the radar.

Re: Rust and the limits of swarm design

#26

Post by rmattes »

wwwigham wrote: post #6
srssays wrote: post #3

Earlier quoted context omitted.

I wouldn't say it works , rather that people will put up with it. When I write JavaScript/node.js code, I have no idea whether the dependencies I'm using will be supported 6 months from now. It's not so easy to just "choose the right package". Often all the packages for a given function are someone's hobby. Consequently JavaScript code needs constant, expensive maintenance. Whereas Python code can rely more on the st…

What makes the libraries blessed by the language designers so much better than a library blessed by any other trusted party? Rust is an open source language, and only the core team works on it full time - even then, any one of them could leave at any time and the community at large would need to pick up the slack. This isn't any different than the situation around any of the amazing community libararies in the Rust e…

I don't think he's arguing that the language designers are the ones that need to be curating crates, he just brought up Python as an example of some sort of curation happening in a similar ecosystem. It's the community at large that needs to be more active about identifying and signaling which crates should be preferred to provide particular functionality.

I don't think you even need to just pick one crate for a particular functionality - narrowing the field down from 23 to a handful with well-understood strengths and drawbacks would be a good start.

Re: Rust and the limits of swarm design

#27

Post by rmattes »

ayrx wrote: post #19

> This isn’t a question that comes up so often with respect to (say) Python because Python has an effective form of curation – blessing things into the standard library, at which point their alternatives generally disappear. In effect, Python modules are quality-filtered on the taste of the BDFL and the devteam. I love Python but this statement is absolutely coming from someone who does not write Python on a regular…

Sure, but even then, I think his point is still applicable. It's urllib2 and requests, not urllib2 and requests and 20 other libraries. The fact that an inferior library is being kept alive by being in the stdlib is maybe unfortunate, but there's still only a small number of choices overall. That makes it much easier to do research and see within the first few search results that the majority of the community recommends one over the other.

Re: Rust and the limits of swarm design

#28

Post by plandis »

LeanderK wrote: post #2

i think he is exaggerating a bit. Many languages have a model where most of the functionality lies in packages and not in the standard library. And it's working. You just have to get used to it and try to develop a taste in choosing the right package. But it's not fundamental and not the limit of swarm design, because you can use statistics to assess maturity.

That's not a great reason to move languages though.

For instance basically nothing comes in the standard library for C. If basically nothing is offered in the standard library of Rust then why switch? It's valid point.

If we want a lot of adoption to Rust, people need to have an easy way to find quality implementations in crates or add them to the standard library so they are easy to find. Either way, you need one of those two things to happen because people are lazy.

Re: Rust and the limits of swarm design

#29

Post by steveklabnik »

sidlls wrote: post #23

I can't say I agree with the author's first article (which he mentions in this one), but I think he has the kernel of a good argument here. That's not to say I agree with it entirely. At some point "design by everyone" turns into "design by committee" by another name. This criticism of Rust has manifested itself in other ways, too. For example the amount of "unsafe" used in various crates (the idea being that "the co…

Do you have any numbers on the amounts of unsafe? I would be interested in a decent methodology to figure this out. I've seen people assert that this is true in the same vague way you're referring to for the other perspective.

Re: Rust and the limits of swarm design

#30

Post by bluejekyll »

sidlls wrote: post #22
bluejekyll wrote: post #11

Earlier quoted context omitted.

The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view. Rust has curation in its crate system. It's all in really good crowd sourcing numbers. Crates.io, number of downloads,…

> The thing is he is attacking Rust not based on the safety the language provides, but more on a feeling that the package, crates, network doesn't fit his belief of how things should be curated. He states that he thinks this is why BDFL is good model, but gives no strong evidence supporting that view. One might easily argue that folks who criticize C and C++ for its ecosystem are also "attacking" it, by your reasonin…

'Attack' is a bit of hyperbole, so it's fair criticism, but I do feel that the article he wrote had much less to do with issues with the language, but a very monocular and subjective view of how ecosystems should be maintained.

He does have some good ideas in there about how to possibly to make crates.io help you more easily identify the best crate for your usecase, but I think the solution to that is a fairly detailed algorithm weighing the some list of values like I put above. Otherwise you end up never allowing new options to blossom.

Trying to read how what I put before wasn't humble, and perhaps your right on that point as well. The perseption of humbleness is definitely subjective, and the added color I threw in there probably in fact did remove any humility from the overall statement, which of course are my own personal views and I highly encourage people to question and criticize them.

Post reply on HN