Hacker News Reader

Comment by zanny | Hacker News Reader

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps).

With Rust, you really should just use crates. The std is meant to be limited to just the most used code and that which should not change for the sake of keeping the ecosystem stable.

View on HN

> even Python

Off topic, but it shouldn't be better than "even Python", because Python has a really, really broken dependency system. Far more so than Java, which has Maven/Gradle which are both infinitely better than the pip/virtualenv disaster.

People complain about things like shading in Maven being complicated. What they might not realize is that pip doesn't even try to address conflicting dependencies, it will just silently give you the wrong version! You ask for A==0.2 and it will give you A==0.1 if another dependency asked for A==0.1 first. And it won't even warn you even though it's straight up broken behavior. Virtualenv makes packaging annoying since it's almost vendoring but not quite. To totally understand the packaging system forces you into the world of eggs, wheels, disutils, conflicting versions, condas, etc.

Sorry for tangent, just thought it was funny you would hold Python up as a standard of dependency excellence when it's probably the worst overall ecosystem of major languages.

I find it super weird how Python is still in this state while even PHP has managed to get something good going.

To me, this is a clear case of trying to fix a broken system whereas starting from scratch would be much better.

Yeah, as someone who's done a deep dive into Python dependency management (mostly because virtualenv has some insane ideas about how to make shell tools) that bit made me laugh.

There are a lot of great things about Python, but dependency management is right there under the GIL on the list of things that are very painful.

My language development went from C -> C++ -> Java -> Python. So when I got there and figured out pip was a thing (or easy_install back in the day) it was a major innovation at the time.

Additionally, for anyone coming from almost all compiled native languages, a native environment like Rust with better dependency management than Python (which, as you say, and in retrospect, is pretty broken) is a bit of a mind screw.

The Python devs I worked with always envied me for npm. I asked them if they don't have something similar with pip, but seems like npm is a whole different level.

Cargo should even be better than npm.

On the other hand I always asked myself if they couldn't simply use Nix?

I can't simply use Nix; it doesn't support Windows.

It doesn't run on the Linux subsystem?

I hear it sorta works, but nix-shell doesn't.

Regardless, while it's cool and useful, it's not really actual Windows support.

true.

Didn't take you for a Windows guy, hehe

Historically not! If you managed to dig up my old /. account you'd see "M$" and all that. Lots of growth and change since then, ha!

It's due to video games... but I'm actually enjoying Windows 10.

Haven't used Rust yet, is it kind of similar to Go where any file can simply import and then Go knows how to fetch and build when needed ? And then when you remove the calls (eg during a refactor) the compiler force you to remove the imports too, stopping the infinite bloat caused by "no one really knows if we still need this" that can be common in other language.

I really liked that "dependancy as part of the language and build tool".

Of course, Go still had its own dependancy issues (versionning, availability, ...) that they now work on, but that was a step in a direction I quite liked.

> is it kind of similar to Go where any file can simply import

You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever.

> the compiler force you to remove the imports too

it warns.

Do you know if there are plans for rustfmt to auto-import like gofmt does? In the sense that if a crate is available (in the .toml file) and you reference it, rustfmt will automatically insert the required "import" and "use".

If the compiler gives you an error with a suggestion "You probably need to add `extern crate foo;`" (and it already does in some cases), RLS (i.e., your editor plugin) will be able to automatically add it for you (soon™).

There's been talk of it, but it hasn't been built yet.

It's more likely to be a part of RLS than rustfmt.

This would probably be an RLS thing.

There's a separate tool called rustfix in development that can apply the suggestions given by the compiler, so it could theoretically prompt for these.

Its kind of the reverse. You declare versioned dependencies in the toml file, and (soon) Cargo will add them to rustc so they just show up for your source files. Right now you declare them twice, once in the toml and once in the crate root - ie, you add url = 1.5 in toml, and extern crate url in src/main.rs. There is an RFC coming that will make the extern crate part optional.

A current problem with " should just use crates" is that cargo only works with source code dependencies, not binary libraries.

So each new crate added to your project ends up increasing the overall build time, which gets exponentially bad if you happen to add a dependency to a crate than happens to have a big dependency list.

I have a very basic word counting application with a GUI written in Gtk-rs, a fresh build straight out of "git clone" takes a few minutes, mainly thanks to Pango.

> So each new crate added to your project ends up increasing the overall build time,

That's only a problem the first time you compile though, isn't it?

A problem that I usually don't have with C++[0], Java[1] or .NET[2], thanks to the build systems support for binary libraries.

[0] - I eschew header only libraries, only if there is no technical way around them (e.g. templates).

[1] - I can AOT compile with Excelsior JET, IBM J9, JamaicaVM, PTC, , Oracle Java 9 (Linux x64 for the time being), ...

[2] - I can AOT compile with Mono, NGEN, .NET Native, CoreRT, IL2CPP, ...

I'm not saying it isn't a problem, I just wanted to know if I was correct in thinking that it is only a problem the first time you compile each crate (or rather each version of each crate, I think).

I see.

Yes, it is a problem when you do a clean build, or when you have common crates across projects, because cargo doesn't have a concept of build cache.

You can try to workaround it by setting all target directories to same one via target-dir in your .cargo/config file, but there is no guarantee that the crate won't get rebuild.

Every dependency can run code on every computer your project runs on. That means you have to trust its author to:

1. not be malicious

2. not write a vulnerability by accident

3. not get their computer infected, their email account hijacked, etc.

4. be wise in transferring ownership

5. not add a dependency with a license incompatible with your project

All the above concerns apply recursively to the dependencies of the dependency.

Reply on news.ycombinator.com