4 ms·

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied

Good work! The idea of dropping extern crate is worrying, however. Most of the ways that that would be done would add more irregularity, complexity, and implied environment to the language (Rust Platform is always there, whether or not you want it), all of which are opportunities for bugs to creep into code.

steveklabnik 10y ago
What worries you about dropping extern crate? A lot of people feel like it's duplicating what's in your Cargo.toml anyway.
- dikaiosune 10y ago
  Would it still work correctly when invoking rustc on its own or from another tool? I've seen a couple of people on IRC asking about driving rustc from a non-Cargo tool.
  - steveklabnik 10y ago
    rustc already requires passing an --extern flag for each 'extern crate' in the source, so in some sense, yes. You'd be passing that stuff along. You already have to know where those deps are on disk; the difference is that you wouldn't have a list of which deps in the source code. But if you did, it would work.
    - qwertyuiop924 10y ago
      Ah. I was working under the assumption that extern crate acted as that, but file-embedded. If rust already needs --extern, I have no objections.
    - gpm 10y ago
      > rustc already requires passing an --extern flag for each 'extern crate' in the source Only if it can't find the crate otherwise. Generally it just searches your library path and any directories you specify with -L, e.g. most cargo executables can be recompiled (the first compilation via cargo used to compile the dependencies) via `rustc src/main.rs -L target/debug/deps`
      - steveklabnik 10y ago
        Ah thanks; Cargo always passes the flag for each, I guess it's just being extra-explicit. (And that doesn't change the main point, which is that you could still be explicit about what deps you're including)
- qwertyuiop924 10y ago
  Cargo.toml isn't in language. It's for the package manager and the build tool. The language shouldn't be married to either thing. As for dropping extern crate, it either marries rust to cargo, or it makes imports implicit. Neither is desirable.
  - tatterdemalion 10y ago
    One possibility is for rustc to take extern crate declarations as commandline args and for cargo to invoke them based on what's in the toml.
    - Manishearth 10y ago
      This technically already happens
      - deleted 10y ago
        [deleted]
      - tatterdemalion 10y ago
        Right, I guess there's no info needed outside what the --extern flag contains.
  - themihai 10y ago
    You have modules, use, extern, cargo.toml, cargo.lock. It looks quite verbose and redundant to me. I expected it to simplify but moving more to config files seems a backwards step. I may be biases but I find the Go import/packing vastly superior in terms of usuability(i.e using a single import statement you make the import explicit and ready to use). I think the trick is to build the tools on top of the source code not on top of config files(i.e ala C/C++).

steveklabnik 10y ago

What worries you about dropping extern crate? A lot of people feel like it's duplicating what's in your Cargo.toml anyway.

dikaiosune 10y ago
Would it still work correctly when invoking rustc on its own or from another tool? I've seen a couple of people on IRC asking about driving rustc from a non-Cargo tool.
- steveklabnik 10y ago
  rustc already requires passing an --extern flag for each 'extern crate' in the source, so in some sense, yes. You'd be passing that stuff along. You already have to know where those deps are on disk; the difference is that you wouldn't have a list of which deps in the source code. But if you did, it would work.
  - qwertyuiop924 10y ago
    Ah. I was working under the assumption that extern crate acted as that, but file-embedded. If rust already needs --extern, I have no objections.
  - gpm 10y ago
    > rustc already requires passing an --extern flag for each 'extern crate' in the source Only if it can't find the crate otherwise. Generally it just searches your library path and any directories you specify with -L, e.g. most cargo executables can be recompiled (the first compilation via cargo used to compile the dependencies) via `rustc src/main.rs -L target/debug/deps`
    - steveklabnik 10y ago
      Ah thanks; Cargo always passes the flag for each, I guess it's just being extra-explicit. (And that doesn't change the main point, which is that you could still be explicit about what deps you're including)
qwertyuiop924 10y ago
Cargo.toml isn't in language. It's for the package manager and the build tool. The language shouldn't be married to either thing. As for dropping extern crate, it either marries rust to cargo, or it makes imports implicit. Neither is desirable.
- tatterdemalion 10y ago
  One possibility is for rustc to take extern crate declarations as commandline args and for cargo to invoke them based on what's in the toml.
  - Manishearth 10y ago
    This technically already happens
    - deleted 10y ago
      [deleted]
    - tatterdemalion 10y ago
      Right, I guess there's no info needed outside what the --extern flag contains.
- themihai 10y ago
  You have modules, use, extern, cargo.toml, cargo.lock. It looks quite verbose and redundant to me. I expected it to simplify but moving more to config files seems a backwards step. I may be biases but I find the Go import/packing vastly superior in terms of usuability(i.e using a single import statement you make the import explicit and ready to use). I think the trick is to build the tools on top of the source code not on top of config files(i.e ala C/C++).