4 ms·

Cargo works well for building C dependencies, in my experience. I haven't really needed (from Rust) to depend on anything written in Java or some other random l

Cargo works well for building C dependencies, in my experience. I haven't really needed (from Rust) to depend on anything written in Java or some other random language, so my experience there is mostly non-existent. Advanced "infrastructure features" you're describing just aren't important for most companies that aren't Google-scale. Compile time on CI is plenty fast without that, in my experience using Rust professionally. Your mileage may vary, of course.

gravypod 6y ago
I've got a python project that depends on a c binary that depends on an shell script that depends on another binary. Bazel let's you do this without caring about how your deps work with hermetic assurances on top. Obviously this doesn't mean cargo is bad or worse or anything like that. It's just that it targets a different use case. Bazel targets many languages, with many targets, by many teams, in many ways. Cargo targets the Rust ecosystem, isn't hermetic, ist't reproducible by default, etc. BUT it's a great experience for rust.
IshKebab 6y ago
Cargo's C building falls down when you combine it with build caching, distributed builds, cross compilation, etc.
jupp0r 6y ago
> Advanced "infrastructure features" you're describing just aren't important for most companies that aren't Google-scale. I've seen several C++ code bases with a few hundred developers working on them taking several hours to compile. I'd turn your statement around and say that any non-trivial commercial C++ and Rust code base will need compiler caches and other advanced infrastructure or productivity will go down the drain.
- coder543 6y ago
  CircleCI offers build caching that works well enough, for example. It's not the super advanced stuff that Bazel can do, but you don't need Bazel to do build caching. When the Linux kernel (~27 million LoC) can be compiled from scratch in under a minute on modern machines (30 seconds on some of the beefier machines)... there's clearly a lot of low-hanging fruit in that "hours long" compilation that has nothing to do with build caching. Whether you can get stakeholders to buy into paying down technical debt or not is an unrelated discussion. Sometimes it's easier to sell fancier build systems as the solution instead of better code organization and simplifying overly generic code. C++ code doesn't have to be super slow to compile: https://www.zverovich.net/2017/12/09/improving-compile-times.html https://www.zverovich.net/2017/12/09/improving-compile-times...

gravypod 6y ago

I've got a python project that depends on a c binary that depends on an shell script that depends on another binary. Bazel let's you do this without caring about how your deps work with hermetic assurances on top. Obviously this doesn't mean cargo is bad or worse or anything like that. It's just that it targets a different use case. Bazel targets many languages, with many targets, by many teams, in many ways. Cargo targets the Rust ecosystem, isn't hermetic, ist't reproducible by default, etc. BUT it's a great experience for rust.

IshKebab 6y ago

Cargo's C building falls down when you combine it with build caching, distributed builds, cross compilation, etc.

jupp0r 6y ago

> Advanced "infrastructure features" you're describing just aren't important for most companies that aren't Google-scale. I've seen several C++ code bases with a few hundred developers working on them taking several hours to compile. I'd turn your statement around and say that any non-trivial commercial C++ and Rust code base will need compiler caches and other advanced infrastructure or productivity will go down the drain.

coder543 6y ago
CircleCI offers build caching that works well enough, for example. It's not the super advanced stuff that Bazel can do, but you don't need Bazel to do build caching. When the Linux kernel (~27 million LoC) can be compiled from scratch in under a minute on modern machines (30 seconds on some of the beefier machines)... there's clearly a lot of low-hanging fruit in that "hours long" compilation that has nothing to do with build caching. Whether you can get stakeholders to buy into paying down technical debt or not is an unrelated discussion. Sometimes it's easier to sell fancier build systems as the solution instead of better code organization and simplifying overly generic code. C++ code doesn't have to be super slow to compile: https://www.zverovich.net/2017/12/09/improving-compile-times.html https://www.zverovich.net/2017/12/09/improving-compile-times...