2025-12-11 Thu

• Added evaluation report: Markdown/Tool/Evaluation/Linters and Auto-Formatters for Table Alignment and Code Blocks
  • dprint is a rust based autoformatter, but it's also got some involvement with Webassembly ...
• Rust learning
  • Rust/format - documented the format! macro for string formatting
  • Cargo/nexttest
    • I've started using this in Person/codekiln/GitHub/langstar.
      • It surprised me here
        • My question:

          • In python and js, tools like linters would typically be locked alongside the libraries and specified in the package manager. Does rust really differ from these that much?
            

        • ChatGPT/Response
          • cargo-nextest is a binary tool (cargo subcommand), not a Rust library. Binary tools must be installed via cargo install, not added to Cargo.toml dev-dependencies.
          • Yes — Rust really does differ here. The difference is structural:
            • Cargo only manages libraries you compile into your project. Cargo.toml is a crate manifest, not a general dependency manifest. Unlike JS (package.json) or Python (requirements.txt), it doesn't manage binary tools.
            • Rust ecosystem assumes tools are installed globally via cargo install, Nix, Docker, or OS package managers. This matches systems languages like Go/C++/Zig, not Python/JS.
            • Version-locking tools happens outside Cargo via devcontainer.json, Dockerfiles, Nix flakes, CI scripts, or a tools/ workspace crate.
          • Bottom line: Cargo intentionally separates build tools from build inputs. For reproducible tooling, use devcontainer/Docker/Nix/CI scripts, not Cargo.toml.