Cargoの役割
Rustでアプリケーションを開発する際、Cargoというツールを利用することがデファクトスタンダードとなっています。このツールは、Rustアプリケーションのビルドを行ったり、他のライブラリへの依存関係を管理したりします。
Cargoはcargoコマンドを使って利用します。公式のインストーラを使ってインストールした場合は、Cargoも同時にインストールされています。以下のコマンドでインストールされていることを確認できます。
cargo --version
JS/TSプロジェクトでは公式のビルドシステムというのは無く、何かしらのバンドラツール（例：Vite）を頼ることになります。
ライブラリの依存関係は公式のnpmやサードパーティーのyarn・pnpmを使うことが一般的です。
Rustにおいてはそのどちらも公式ツールとして機能提供されていることが特徴的です。
cargo new
Cargoを使うには、そのプロジェクトが、前提となる構造に従っている必要があります。cargoには、その構造通りにプロジェクトを作成するサブコマンドが用意されています。
以下のコマンドで、カレントディレクトリの配下に新しいプロジェクトディレクトリを作成できます。
# qiita-sampleの部分は任意
cargo new qiita-sample
コマンドを実行すると、カレントディレクトリにqiita-sampleというディレクトリが生成され、その中に必要なファイルやディレクトリが生成されています。
cargo newによって生成されるのは以下のものです（厳密にはGitの初期化も行われるので.gitや.gitignoreも含まれますが、ここでは省略します）。
Cargo.toml-
srcディレクトリ
Cargo.toml
Cargoプロジェクトの設定ファイルです。パッケージ名やバージョン、依存関係を管理します。
Node.jsプロジェクトにおけるpackage.jsonのようなものです。
srcディレクトリ
ソースコードが格納されるディレクトリです。Cargoは基本的にsrcディレクトリ配下のソースコードをビルド対象にするので、新規にファイルを追加する場合はsrcディレクトリ配下に作成しましょう。
srcディレクトリの中にはmain.rsが生成されています。Cargoでは、src/main.rsがエントリーポイントになります。cargo new直後のsrc/main.rsの中身は以下のようになっています。
fn main() {
println!("Hello, world!");
}
cargo buildとcargo run
プロジェクトディレクトリ（前項でいうqiita-sampleディレクトリ）で以下のコマンドを実行すると、プロジェクトをビルドします。
cargo build
このコマンドによるビルド成果物はtarget/debug/qiita-sampleに生成されます。このファイルを実行すると、src/main.rsのmain関数の処理を実行できます。
root@k4nd4windows:/work/rust/qiita-sample# ./target/debug/qiita-sample
Hello, world!
ビルドと実行を同時に行いたい場合は以下のコマンドでそれが可能です。
cargo run
Cargoによるコンパイルは、ソースコードに変更があったときに行われるため、すでにcargo buildによってコンパイル済みのバイナリがあり、そのときとファイルが変わっていなければ、コンパイルのフェーズは実行されません。
cargo buildには--releaseというオプションが存在します。このオプションを付与すると、プロダクションリリース向けに、より最適化されたバイナリを生成します（サイズが小さくなり、高速になる）。ただし、その最適化フェーズによってコンパイラ時間は増大します。
開発時により早いサイクルでビルドしたい場合は単にcargo buildを、最終的なプロダクションリリースをするときはcargo build --releaseを実行します。
cargo checkでコンパイラエラーだけ検証できる
cargo buildやcargo runを実行したときに、例えばソースコードに誤りがあるとコンパイラエラーが出力され、そうでないときはビルドやバイナリの実行まで進みます。コンパイラエラーが存在するかどうかのみを検証する（＝検証に成功すればそこでコマンドが終了してよい）場合はcargo checkというコマンドを使用します。
cargo check
cargo checkの具体的なユースケースを考えてみましたが、例えばGit hooksを組み合わせてコミット前に実行し、コンパイルエラーが発生しないソースコードを保証する、などがあるでしょうか。
似たようなケースを過去のNode.jsプロジェクトでやっていた経験があります。