5 ms·

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

by zanny 9y ago

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.

ditonal 9y ago
> 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.
- nolok 9y ago
  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.
- zanny 9y ago
  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.
  - k__ 9y ago
    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?
    - steveklabnik 9y ago
      I can't simply use Nix; it doesn't support Windows.
      - k__ 9y ago
        It doesn't run on the Linux subsystem?
        steveklabnik 9y ago
        I hear it sorta works, but nix-shell doesn't. Regardless, while it's cool and useful, it's not really actual Windows support.
        k__ 9y ago
        true. Didn't take you for a Windows guy, hehe
        steveklabnik 9y ago
        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.
- freshhawk 9y ago
  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.
nolok 9y ago
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.
- Manishearth 9y ago
  > 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.
  - greenhouse_gas 9y ago
    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".
    - steveklabnik 9y ago
      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.
    - killercup 9y ago
      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™).
    - 9y ago
pjmlp 9y ago
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.
- Sean1708 9y ago
  > 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?
  - pjmlp 9y ago
    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, ...
    - Sean1708 9y ago
      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).
      - pjmlp 9y ago
        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.
CodesInChaos 9y ago
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.

by zanny 9y ago

ditonal 9y ago

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

nolok 9y ago
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.
zanny 9y ago
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.
- k__ 9y ago
  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?
  - steveklabnik 9y ago
    I can't simply use Nix; it doesn't support Windows.
    - k__ 9y ago
      It doesn't run on the Linux subsystem?
      - steveklabnik 9y ago
        I hear it sorta works, but nix-shell doesn't. Regardless, while it's cool and useful, it's not really actual Windows support.
        k__ 9y ago
        true. Didn't take you for a Windows guy, hehe
        steveklabnik 9y ago
        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.
freshhawk 9y ago
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.

nolok 9y ago

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.

Manishearth 9y ago
> 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.
- greenhouse_gas 9y ago
  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".
  - steveklabnik 9y ago
    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.
  - killercup 9y ago
    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™).
  - 9y ago

pjmlp 9y ago

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.

Sean1708 9y ago
> 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?
- pjmlp 9y ago
  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, ...
  - Sean1708 9y ago
    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).
    - pjmlp 9y ago
      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.

CodesInChaos 9y ago

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.