6 ms·

Every time I read "Rust tooling is weak" I'm sure in following lines I will not find words about IDEA plugin (powerful and with regular updates) and Cargo (with

Every time I read "Rust tooling is weak" I'm sure in following lines I will not find words about IDEA plugin (powerful and with regular updates) and Cargo (with a lot of builtin features, such as testing). Rust tooling promotion is weak, not tooling itself.

pjmlp 10y ago
Still has a bit of catch up to do, compared with what I enjoy daily in Java and .NET projects. Right now my biggest pain, are the compilation times, specially seeing cargo compiling multiple times the same crates instead of reusing the already binary compiled libraries. Unless there is some magic cargo incantation I am missing.
- EugeneOZ 10y ago
  Cargo doesn't recompile all crates on each iteration, you are missing something definitely. It only recompiles changed code. Or if rustc/cargo version has been changed. "a bit of catch up" is one thing, not mentioning most powerful IDE plugin is another.
  - pjmlp 10y ago
    This is not what I see, I imagine you are talking inside one single project, while I mean across all Rust applications I might have available. 1 - Get Project A 2 - Crate X gets compiled as one of the dependencies 3 - Get Project B 4 - Crate X gets compiled again as one of the dependencies I usually see this when compiling all the VSCode related projects during new Rust releases. Could the reason be that Crate X on Project A and Project B isn't the same version? Where are the binary rlib visible to all cargo projects stored? I could only find text versions zipped together. I haven't checked this deeply yet, just seeing "Compiling crate X" multiple times isn't fun.
    - EugeneOZ 10y ago
      All projects are independent and binaries are stored in "target" folder. It's a good thing. Even libs nominally same versions can have different source code and dependencies (because of "replace" or vendoring).
      - pjmlp 10y ago
        No, it is not a good thing. It is a waste of my development time that I could use for productive work. On other AOT compiled languages that I use at work, I can reuse binaries across projects, including the languages Rust intends to replace. It is a hard sell, if using Rust means having to spend more time compiling than even with C++ (specially now that modules are finally coming, at least for us with VC++).
        EugeneOZ 10y ago
        For me is a good thing, because, as I explained, version number is not a guarantee.
        pjmlp 10y ago
        So, than cargo needs to be improved so that there is a set of dependency values (name, version, rustc version, etc) that can guarantee the uniqueness of a binary library. To me it seems FOSS undervalues the value of binary libraries in the enterprise, or how they get used in many corporations or companies selling components. Rust improved safety is a good thing™, but not at the expense of continuously seeing the same libraries being compiled over and over, vs reusing binary artifacts across projects.
        EugeneOZ 10y ago
        Cargo needs to be improved, here I agree :)
        p0nce 10y ago
        dub (D build tool) support both of these locations. I can attest stuff gets reused.
    - steveklabnik 10y ago
      We don't do any of this kind of caching because flags can be different per-project. There's an open bug on it; it's not impossible, we just haven't used it yet.
      - pjmlp 10y ago
        Same applies to any language that compiles to native code or has support for conditional compilation. Even with MIR, Rust will never compile faster than C or even C++ if dependencies on binary libraries aren't supported. Right now I can compile my C++ projects on Windows, and .NET Native ones, faster than when updating Rustfmt, racer and Rustsym, after each new Rust release. VS2017 will bring the new linker, and the ongoing MS work for C++ modules (now a TS). Rust won't win the hearts of C++ developers if it doesn't allow for binary dependencies, and doesn't compile faster.
        deleted 10y ago
        [deleted]
- fjrieiekd 10y ago
  Needs better build support, CI testing and better tooling to match C++ on mobile.
allengeorge 10y ago
I use the IntelliJ plugin daily, and although I recommend it (and the maintainers are awesome!) it has a ways to go before it matches what I've seen with IDEA (Java).
- EugeneOZ 10y ago
  It proves point that tooling is weak?

pjmlp 10y ago

Still has a bit of catch up to do, compared with what I enjoy daily in Java and .NET projects. Right now my biggest pain, are the compilation times, specially seeing cargo compiling multiple times the same crates instead of reusing the already binary compiled libraries. Unless there is some magic cargo incantation I am missing.

EugeneOZ 10y ago
Cargo doesn't recompile all crates on each iteration, you are missing something definitely. It only recompiles changed code. Or if rustc/cargo version has been changed. "a bit of catch up" is one thing, not mentioning most powerful IDE plugin is another.
- pjmlp 10y ago
  This is not what I see, I imagine you are talking inside one single project, while I mean across all Rust applications I might have available. 1 - Get Project A 2 - Crate X gets compiled as one of the dependencies 3 - Get Project B 4 - Crate X gets compiled again as one of the dependencies I usually see this when compiling all the VSCode related projects during new Rust releases. Could the reason be that Crate X on Project A and Project B isn't the same version? Where are the binary rlib visible to all cargo projects stored? I could only find text versions zipped together. I haven't checked this deeply yet, just seeing "Compiling crate X" multiple times isn't fun.
  - EugeneOZ 10y ago
    All projects are independent and binaries are stored in "target" folder. It's a good thing. Even libs nominally same versions can have different source code and dependencies (because of "replace" or vendoring).
    - pjmlp 10y ago
      No, it is not a good thing. It is a waste of my development time that I could use for productive work. On other AOT compiled languages that I use at work, I can reuse binaries across projects, including the languages Rust intends to replace. It is a hard sell, if using Rust means having to spend more time compiling than even with C++ (specially now that modules are finally coming, at least for us with VC++).
      - EugeneOZ 10y ago
        For me is a good thing, because, as I explained, version number is not a guarantee.
        pjmlp 10y ago
        So, than cargo needs to be improved so that there is a set of dependency values (name, version, rustc version, etc) that can guarantee the uniqueness of a binary library. To me it seems FOSS undervalues the value of binary libraries in the enterprise, or how they get used in many corporations or companies selling components. Rust improved safety is a good thing™, but not at the expense of continuously seeing the same libraries being compiled over and over, vs reusing binary artifacts across projects.
        EugeneOZ 10y ago
        Cargo needs to be improved, here I agree :)
      - p0nce 10y ago
        dub (D build tool) support both of these locations. I can attest stuff gets reused.
  - steveklabnik 10y ago
    We don't do any of this kind of caching because flags can be different per-project. There's an open bug on it; it's not impossible, we just haven't used it yet.
    - pjmlp 10y ago
      Same applies to any language that compiles to native code or has support for conditional compilation. Even with MIR, Rust will never compile faster than C or even C++ if dependencies on binary libraries aren't supported. Right now I can compile my C++ projects on Windows, and .NET Native ones, faster than when updating Rustfmt, racer and Rustsym, after each new Rust release. VS2017 will bring the new linker, and the ongoing MS work for C++ modules (now a TS). Rust won't win the hearts of C++ developers if it doesn't allow for binary dependencies, and doesn't compile faster.
      - deleted 10y ago
        [deleted]
fjrieiekd 10y ago
Needs better build support, CI testing and better tooling to match C++ on mobile.

allengeorge 10y ago

I use the IntelliJ plugin daily, and although I recommend it (and the maintainers are awesome!) it has a ways to go before it matches what I've seen with IDEA (Java).

EugeneOZ 10y ago
It proves point that tooling is weak?