Cargo's next few years | Hacker News Reader

Cargo's next few years

ncameron.org

110 pointsmcp_40 comments

Very happy to see mainstream support for cross-compile at the top of the list.

I've been diving headfirst into C for a project at work with no previous experience, while being quite comfortable in Rust. I couldn't agree more.

Cargo is great and keeps getting better. However, in the embedded space I find the whole area of “features” very confusing. Just the fact that doing a web search for “rust features” will not usually get you what you want because we use the word “features” for everything! But in the embedded rust world, having a good understanding about how features affect the build is critical to successfully building something with no standard library. Thankfully the rust community really shines here and you find stack overflow questions answered at record speeds!

There's a lot of hype around rust which may or may not pan out, but cargo should really be the gold standard for package management/build systems going forward, it's incredibly well designed. Everything is painless and integrated: builds, tests, benchmarks, publishing, installing dependencies, downloading cli binaries.

When you eventually have to go back to all the other hacked together Frankenstein alternatives out there it's a painful, frustrating experience.

Discussion here:

https://www.reddit.com/r/rust/comments/amat47/cargos_next_fe...

https://internals.rust-lang.org/t/cargos-next-few-years/9321...

I assume the title is meant to be "Cargo's next few years"?

Thanks, we've removed the leading “(Rust) ”.

What about the "next" instead of "new"?

Good heavens! Yes, thanks. Lexer error on my part.

Ha! I should've been more explicit.

> it lowers barriers to contribution

Arguably this is a bad thing. Lowering the bar is not necessarily a good thing. How could it be?

EDIT: Please if you down-vote, could you also provide a reason as to why lowering barriers to contribution is inherently a good thing, and why even considering the idea that it may not be, is something utterly horrible that requires a down-vote? Sure, you don't have to, just trying...

Dealing with unnecessary build and packaging complications, often dictated by legacy constraints, is a distraction for a systems programmer and does nothing for the quality of the software itself.

OK, but that means that people who are more motivated and knowledgeable (depends) will be the ones contributing, or will make up the majority of contributors. Does it not? I can see how it could be beneficial to a project.

But they will be knowledgeable in something that is only tangentially related to systems programming.

You are potentially missing out on a lot of talented systems programmers who are not willing or able to put up with terrible build and packaging infra and therefore stick to another domain.

As for motivation, you are also missing out on anyone who has a small contribution to make but isn’t willing to dedicate hours trawling through Makefiles. That doesn’t seem good either?

I didn't say it was without downsides, I realized that there's a huge potential of losing lots of talented people who merely just don't have the patience to [...].

I don't have anything valuable to add, hopefully someone else might.

people who are more motivated and knowledgeable (depends) will be the ones contributing

I have contributed to projects where I am neither motivated or knowledgeable.Sometimes its enough to be annoyed by a bug or confusing behaviour.

I would say that is being motivated though, just with a different motivator! :P

"Lowering the bar" and "lowering barriers" are two very different things that you are conflating.

Is it? I have seen them used in the exact same way. For example: lowering barriers to entry to a university is lowering the bar. Are they not the same thing?

Bars are lowered, barriers are removed; lowering barriers is a mixed metaphor that doesn't really work because "lowering a barrier" often, in reality, means that a barrier has been put in place. Plus the metaphor has to mean the same thing in this case — there is a barrier to entry, but it is not as difficult to get past as it was previously, which exactly the same as lowering the bar (the bar is still there, it's just lower and therefore easier to jump over)

Easier to jump over, which means that people who otherwise wouldn't have been able to pass, now can easily jump over. It reduces quality, doesn't it? What I meant was that due to eliminated barriers, you may get lower quality. I emphasize may here. Just in case.

Only if a) the bar(rier) is correlated with quality and b) there are no other quality gates elsewhere in the process.

So does anyone know if in this exact situation it is, or it is not, or are we all just assuming that it's necessary a good thing and bash on anyone who dares to bring it up that it may not be the case? I said "arguably", and yes, while I did not provide an argument, I thought someone else could.

Arguably, Nick Cameron is an agent of the Knights Templar and Cargo is a secret plan towards world domination. You need to say why you think things are plausible.

(In this exact situation I do know that there's a quality gate later in the process, and it would be very easy for you to determine that too with at most five minutes of research.)

I know what you are trying to say. Personally I would like to hear convincing reasons why lowering barriers to contribution is inherently a good thing, in all cases. I mentioned a few cases later on where it might not be favorable, to me, at least.

And again: it was just a way to get the attention of people who might agree with it, to hear their side. Or to start/stimulate a discussion.

I don't like to just believe things because it sounds good and because it has been repeatedly said to be good, without explaining why. The point was to question it, or come up with scenarios where it is not favorable. Do you agree that such scenarios exist where it is not a good thing, or not?

We have code reviews and stuff for this. It's also totally possible for somebody to spend hours setting something up and then develop really bad code - it might even be more likely in situations where time is a constraint. Having people jump through arbitrary hoops that have nothing to do with the matter at hand is not a good thing. This is especially the case with rust which isn't exactly the most beginner friendly language to begin with.

Code reviews, yes. Not all projects can afford to go through millions of contributions because the barrier was lowered or eliminated. So in that case it is not necessary a good thing to accept lazy contributions.[1] And before someone misinterprets, sure, you can work endless hours on a contribution and then submit it easily. This is not the case I am talking about, and this is not what we have observed in the case of these package managers either. Or at least that's what I did when I took a look at npm. If it's not polluted because anyone can submit their garbage easily, then what is at fault, exactly?

[1] We are still talking about a package manager, and this project specifically.

I think that as a package maintainer, you can set the bar(rier) as high or as non-existent as you like. If you've got a lot of contributors, you've almost certainly got some regular contributors who you'd be able to trust to review/triage things for you. Otherwise just stick a big note saying 'we're full up, not accepting PRs, find another project, file or support a bug, the princess is in another castle' on your readme. I think they'll get the message.

I think talking about contributions of low effort 'my-hello-world-lib' packages to repositories and contributions to existing codebases have a pretty different dynamic which we shouldn't conflate. For instance, while the npm-cli project is obviously hugely popular as a piece of software, the amount of PRs they get isn't exactly overwhelming, and they seem to accept a high proportion of the ones that do get opened against the project.

Nevertheless, the JavaScript ecosystem is flourishing by all accounts so I'm not that convinced that their repositories being that polluted are as much of a hindrance as some would like to make out. It's just not that much of a problem because people can work with recommendations, popularity, word of mouth or whatever and decide what packages they're willing to accept based on their own organisation's policies rather than having some central authority dictate it to them. You can also argue that a separation of concerns should happen here: Lists of curated packages can exist outside of the repository itself.

I also just don't think it's Cargo's job to put artificial barriers in place. It should be the package maintainer's job to decide what is an appropriate level of difficulty to contribute to them if that's how they see fit to triage contributions. If they want to make it some labyrinthine thing with external dependencies that have to be built by drawing a pentagram in your own time and blood and summoning the elder beast who instructs you as to where to find a binary blob that you have to link against that was lost in the early 1500s then more power to them? But it's not Cargo's job to decide where that line gets drawn.

Ah, I don't like the idea of artificial barriers either, but what other package managers have seems to be good enough.

Look, I came across a neat program written in Rust, and this is how the recommended way to install it looks like: https://streamable.com/iyq6b. The video is truncated, and it took 16 minutes to finish!

This entire "making it easier for everyone to contribute" idea encourages and enables such outcomes. It does sound good, but in practice it is not as good. I understand that it is up to this particular project to avoid dependencies, but that is not what I have seen in ALL pieces of Rust software that I came across. It just seems more prevalent in such ecosystems. Maybe it brings together people who think it is a good idea to depend on 2 lines of code and as many libraries as possible, I don't know.

Remember the days when it was encouraged to have as fewer dependencies as possible? It seems like these days are over because of such ideas.

I can totally sympathise with this - especially when if you look at the project's cargo.toml it looks simple enough, but turns out to have a boat load of transitive dependencies as seems to be the case with that project. Plus the experience is somewhat exacerbated by Rust just generally being quite slow to compile.

I think there's a mindset that is imported from agile business culture, more than anything else, that if you're not developing functional requirement business features as fast as humanly possible while meeting the bare minimum for quality then you're being slow and inefficient compared to the guy who's willing to do that. This same mindset also makes it completely unlikely that a tool with any kinds of barriers to entry which would have to be overcome on company time will ever gain any adoption.

The other side of that coin is that where there are community projects which are not supported by companies where developers are just working in their spare time, often around work and so on, to develop something they think might be interesting but cannot commit to making everything the best it could possibly be while also realistically getting the thing done. It also has to work everywhere, it has to look pretty, it can't just work on whatever version of Windows is current and have done with it.

Then there is just a logic to using dependencies because they've already been battle tested for you, there's a decent chance those developers have done a better job than you would given whatever limitations that you have simply because they've put the time and effort into it already. Maybe somebody's even paying them to do it.

Example: A high application fee is a barrier. Lowering it does not lower the bar.

Definition:

> To lower the standards of quality that are expected of or required for something

"or required for something".

I think it pretty much fits according to the definition, but it is usually used in terms of abilities or skills.

https://idioms.thefreedictionary.com/lowering+the+bar

You’re not parsing that correctly.

To lower the standards of quality that are expected of something.

To lower the standards of quality that are required for something.

Lowering the bar is a reduction of quality. Lowering barriers is not the same thing.

By reducing the barrier to entry by, say, making the tests easier (or the use of build systems), then effectively you are reducing the quality of "applicants". Eliminate the barrier completely (get rid of the tests), and it is guaranteed that you will get many more applicants who would not be fit for whatever.

Doesn't this make sense?

This depends on what the barrier is. A financial barrier, for instance, to submit apps to an App Store does not introduce any quality test. So removing it doesn't reduce quality.

If removing a barrier means removing a quality check, then sure it could lower the bar. But not all barriers are quality checks. Show that cargo removes a quality check, and you can come back and claim it's lowering the bar.

> This depends on what the barrier is.

I know, but we are talking about this specific barrier. It is not a financial barrier that has been lowered either.

Regarding this barrier: I already explained how it could be the case, by of course potentially losing skilled people, and as I said it is not without downsides.

We could argue as much as we want, that doesn't really explain how it is inherently a good thing. In reality you get more lazy contributions and packages, take a look at package managers such as npm.

I did not downvote, but a) if you're going to say "Arguably this is a bad thing," you should provide an argument (or, if you don't want to say that, you can say "I don't understand this, can someone please explain" instead of "How could it be") and b) on HN downvotes are a valid way to express disagreements.

While I did not really have an argument, I thought I let someone else who may think the same come along and provide an argument. Or are we all to assume that it is actually inherently, or necessarily a good thing until proven otherwise? I understand that I could have said exactly those things to help on the matter.

I am aware of down-votes being a way of expressing disagreements, and I don't expect everyone to provide a reason for doing so.

Are you not a native English speaker? I ask because most non-native speakers will accept and appreciate the correction. Only a native speaker would confidently defend their interpretation. And yet, I find it difficult to understand how a native speaker could possible misinterpret this statement.

By statement do you mean "it lowers barriers to contribution"? I just have the idea that you will get more applicants or submissions this way because anyone, without zero effort, could submit their contributions. It's the case with other package managers, too. If you take a look at modern package managers, it is filled with actual garbage, and only very few are of high quality. It seems heavily polluted, due to lowered barriers to submit them, I think. Noobs can just type in a command without having to research it or RTFM, and boom, it's there. I am not sure how people can think that this is necessarily a good thing, still.