
Cargo's next few years - mcp_
https://www.ncameron.org/blog/cargos-next-few-years/
======
dbcurtis
Very happy to see mainstream support for cross-compile at the top of the list.

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

------
davidhyde
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!

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

------
dochtman
Discussion here:

[https://www.reddit.com/r/rust/comments/amat47/cargos_next_fe...](https://www.reddit.com/r/rust/comments/amat47/cargos_next_few_years/)

[https://internals.rust-lang.org/t/cargos-next-few-
years/9321...](https://internals.rust-lang.org/t/cargos-next-few-years/9321/6)

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

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

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

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

~~~
ChrisSD
Ha! I should've been more explicit.

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

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

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

~~~
achamayou
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?

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

