[flagged]
How much extra config or shell scripts would cargo have to have to add code coverage, findbug tools (that do things like linting and pattern matching to detect common coding errors)? How much extra is needed to add a unit testing mechanism, an integration testing mechanism, a dependency checker (e.g., checking if you're not using a duplicate transitive that is pulling in different versions that might clash)?
The only thing comparable to cargo.toml is these 40-ish lines[1], which you pay double for the xml tax. The rest are things that are adding value, but could be removed (tho i would say it's adding a lot more value than it's costing you lines of code).
[1]https://github.com/binkley/modern-java-practices/blob/master...
2 lines with cargo tarpaulin. 1 to add the dependency, 1 to actually run it.
> findbug tools (that do things like linting and pattern matching to detect common coding errors)?
0. It's built in. Cargo check runs by default, you can run cargo clippy with 1 line if you want stricter checks.
> How much extra is needed to add a unit testing mechanism, an integration testing mechanism,
0. It's built in. (I don't particularly like the built in integration test mechanism, but that's another matter)
> a dependency checker (e.g., checking if you're not using a duplicate transitive that is pulling in different versions that might clash)
0. Cargo does this already.
Statements like "just 2 lines" in Cargo is just a weird comparison. Because it's only 2 lines if you don't configure anything. You can also use all this stuff out of the box with Maven or Gradle with far fewer lines if you don't configure anything. I can point out a whole slew of weird defaults in Clippy [1] which will probably require me to specify a dozen of the hundreds [2] of configuration options it has.
> 0. It's built in. Cargo check runs by default, you can run cargo clippy with 1 line if you want stricter checks.
Findbugs is a framework for static code analysis with plugin support and what not. Clippy is just a linter.
[1] https://rust-lang.github.io/rust-clippy/master/index.html [2] https://doc.rust-lang.org/clippy/lint_configuration.html
Yes, you could add a load of config for files to include/exclude from coverage and so on, but the idea that that's a norm is way more common in Java projects than other languages. Like here's some example Cargo.toml files from complicated Rust projects:
Servo: https://github.com/servo/servo/blob/main/Cargo.toml
rust-gdext: https://github.com/godot-rust/gdext/blob/master/godot-core/C...
ripgrep: https://github.com/BurntSushi/ripgrep/blob/master/Cargo.toml
socketio: https://github.com/1c3t3a/rust-socketio/blob/main/socketio/C...
The thing is, with any non-trivial project, zero to hello world isn't a very useful metric. Gradle (and Maven, sbt, ...) do a lot more than Cargo, and their usage is primarily optimized for complex multi-modules projects.
Hardly a surprise that we got better at this.