Rust-Written Coreutils Replacement uutils 0.0.19 Released

[lowflyer]

That will depend on what crate you use.

This is not a non-problem. crates.io will evolve. Alternatives to crates.io will spring up. If rust becomes popular there will be tens of thousands of crates that solve gazillions of different problems. This may be good for a rapid development. But the downside is the confusion. There will be crates that pull in hundreds of other crates. It will get difficult to select the correct crates and really difficult to maintain that white list. A rising number of ignorant rust developers will make the problem worse. This is exactly what happened to javascript and to a lesser degree to python.

It's not that evolutionary, and that's why this is not going to be a big problem.

I don't think so. From a pure web developer-only point of view, "not a big problem" is the natural resulting opinion. The differing sales model results in two fundamental differences:
- Web applications are short lived compared to native apps. A license issue has a shorter exposure time in a web application.
- Companies care less about web applications which leaves them under less scrutiny than native applications.

Having a package manager will always better than without one, having to manually install the dependencies using apt-get or manually download, extract and compile really is just wasting time, where you can allocate these resources to actually review the dependencies.

I don't see rust offering something new here. Dependencies will always need to be managed manually. On the contrary: the simplicity of creating and ease-of-re-use of crates will cause a problem that does not exist in this form in languages like Ada, Pascal, C, D, Haskell etc.

Besides, I haven't seen a single Linux distribution that lacks a package manager. Windows solves that problem with static linking and installers.

[lowflyer]

cargo-deny recursively checks dependency tree as well as opt in deps. I really don't see how this can be possible without an entire team working on it, checking every bit of code to manually make sure there are no patent infringements, as long as the tree is good that would be fine due diligence.

Up to now, I did not talk about patent issues - that's a whole other bucket full of worms.

assuming you really *need* a crate that pulls in an incompatible dep (which you would find out by adding the crate, running cargo-deny before work starts) it's just like anything else, fork it, strip out or make the deps optional, or replace it yourself, that doesn't really change anything. as for the leaks part. this changes literally nothing. just replace the bits once you are aware of it. and if it's too large to replace you are SOL, but that changes literally nothing from C

Thanks for confirming that. It's what I expected: nothing new under the sun. cargo-deny is not a silver bullet. It will just point to issues that still need to be managed manually. But which developer runs that tool voluntarily? - unless you have it somewhere into your CI-stack.

[NobodyXu]

This is not a non-problem. crates.io will evolve. Alternatives to crates.io will spring up. If rust becomes popular there will be tens of thousands of crates that solve gazillions of different problems. This may be good for a rapid development. But the downside is the confusion. There will be crates that pull in hundreds of other crates. It will get difficult to select the correct crates and really difficult to maintain that white list. A rising number of ignorant rust developers will make the problem worse. This is exactly what happened to javascript and to a lesser degree to python.

Like I said, the solution is to use whitelisting of authors or crates, or both.
Plus blacklisting authors known to be bad actors.

I don't think so. From a pure web developer-only point of view, "not a big problem" is the natural resulting opinion. The differing sales model results in two fundamental differences:

What I was trying to say is that, the companies/corp/devs already has experience dealing with dependencies, using whitelist/blacklist.

I don't see rust offering something new here. Dependencies will always need to be managed manually.

So without a package manager and https://crates.io, you will have to use the tools platform-dependent tool to install them.

On debian/ubuntu, this will be apt-get.
On centos/redhat, this will be yum.
On alpine, this will be apk.
On macOS, this will be homebrew.
On windows, this will be chocolatey or scoop.

As you can see, all of them are maintained separately and your dependencies might not be available there at all.
Or it is available, but with a different feature set than you expected.

If they are not available, then you will have to download source code, compile and install it manually.

Compared to cargo, you just need to edit Cargo.toml and it will get the job done for you, in a cross-platform way.
Which one is simpler is obvious.

[Quackdoc]

Thanks for confirming that. It's what I expected: nothing new under the sun. cargo-deny is not a silver bullet. It will just point to issues that still need to be managed manually. But which developer runs that tool voluntarily? - unless you have it somewhere into your CI-stack.

I know it's something I personally often check

[lowflyer]

What I was trying to say is that, the companies/corp/devs already has experience dealing with dependencies, using whitelist/blacklist.

I certainly hope so, but the problem will be worse than what they're used to because of what I tried to explain above

So without a package manager and https://crates.io, you will have to use the tools platform-dependent tool to install them.

On debian/ubuntu, this will be apt-get.
On centos/redhat, this will be yum.
On alpine, this will be apk.
On macOS, this will be homebrew.
On windows, this will be chocolatey or scoop.

As you can see, all of them are maintained separately and your dependencies might not be available there at all.
Or it is available, but with a different feature set than you expected.

If they are not available, then you will have to download source code, compile and install it manually.

Compared to cargo, you just need to edit Cargo.toml and it will get the job done for you, in a cross-platform way.
Which one is simpler is obvious.

Two things:

• On windows you generally don't need a package manager since the installers usually contain everything (yes, it's a waste)
• Deployment that requires internet access can be problematic. We deliver to customers that operate on completely isolated networks.

As I mentioned in previous posts, I am not a rust expert, so I have questions:

• does https://crates.io store the crates in binary or in source form? How is "cross-platform" handled as you mention?
• how would I deploy a rust application to a customer's machine without internet access?
• If the crates come in source form (as I suspect) there must be a compiler on the system for that workflow to work. Wouldn't this mandate the use of a package manager on top of (or before) cargo? I don't expect to find all compilers pre-installed on customers machines.

[NobodyXu]

I certainly hope so, but the problem will be worse than what they're used to because of what I tried to explain above

Handling cargo dependencies should be no difficult than handling python/javascript dependencies.

Two things:

• On windows you generally don't need a package manager since the installers usually contain everything (yes, it's a waste)
  

• Most libraries does not come with an installer, boost for example, contains instructions only.
  
  

  https://www.boost.org/doc/libs/1_82_0/more/getting_started/windows.html

  
  
  

• does https://crates.io store the crates in binary or in source form? How is "cross-platform" handled as you mention?