はじめに
こんにちは。バックエンドエンジニアのよしかわです。本稿では業務で用いる Rust のライブラリをどのように探しているかやその際に何を気にしているかについてご紹介します。
この記事はエモーションテック Advent Calendar 2024の3日目の記事です。
ライブラリとクレートの関係
まず先に、ライブラリという語と Rust で頻出する「クレート(crate)」という語の関係について述べておきます。といっても大抵の場合ライブラリとクレートは同じものを指すと考えて差し支えありません。詳しくは “the book” と呼ばれるドキュメントの 7.1. Packages and Crates で説明されているのでご参照ください。
Most of the time when Rustaceans say “crate”, they mean library crate, and they use “crate” interchangeably with the general programming concept of a “library”.
私自身もライブラリを指してクレートと呼ぶことが多いです。ただ Rust に慣れていない方にとって多少でも読みやすくなればという意図のもと、ここではライブラリという語を用います。
外部ライブラリの必要性
Rust を用いたソフトウェアの開発業務を行う場合、他の言語の場合と同じく大抵は何らかのライブラリを使うことになります。むしろ Rust は外部ライブラリの利用機会が多い言語と言えるかもしれません。Python のようなバッテリー同梱(batteries included)を掲げる言語に比べて標準ライブラリの機能が多くないからです。 *1
外部ライブラリの探し方
Rust のライブラリも他の言語のライブラリと探し方は変わりません。情報がありそうなところから探します。
レジストリ
Rust のライブラリが登録されている場所(レジストリ)といえば crates.io です。有名どころから個人の習作まで数多く登録されています。登録されているライブラリはウェブサイト上で検索可能です。
私はライブラリを探すとき crates.io 上で思いつく限りのキーワードで検索してみるなんてことをよくやります。このとき他の言語のライブラリや機能の名前から探すのも面白いと思います。 *2
コミュニティ
コミュニティの情報も助けになります。例えば Awesome Rust や Blessed.rs には色々なライブラリが挙げられていますし、This Week in Rust や The Rust Programming Language Forum の話題から追ってみるのもよいかもしれません。
ある優れたライブラリのメンテナは別の優れたライブラリのメンテナでもあるという推測のもと、その人や組織のリポジトリを見てみるのも有益だと思います。有名なのは例えば David Tolnay さんや Andrew Gallant さんでしょうか。 私は最近 Andrew Gallant さんの jiff が気になっています。jiff のドキュメントには他の似たライブラリとの比較も記載されていて興味深いです。
書籍
書籍も有用な情報源です。例えば最近(2024年9月)出版されたRustによるWebアプリケーション開発という本の第8章ではRustの代表的なライブラリが一通り簡潔に紹介されています。Rustを使い始めたばかりの方にはとくに有用ではないかと思います。
ライブラリを使う前の確認事項
探し出したライブラリを使うにあたっては、機能や性能以外にも確認すべき点がいくつかあります。
ライセンス
業務での使い方がライセンス違反にならないかは確認しなければなりません。Rust 本体のライセンスの影響もあってか寛容型のライセンスのライブラリが多い印象はありますが、異なるライセンスのライブラリも当然あるからです。cargo-deny などのツールによる機械的なチェックも行うと安心です。
依存関係
使おうとしているライブラリがさらに依存している先のライブラリにも注意は必要です。依存先のライブラリが大きかったり多かったりすると、ビルドに時間がかかったりバージョンを上げるのが大変になってしまったりするかもしれません。過去の記事でも触れたようなややこしい問題を避ける上でも依存関係はなるべく簡単に保つのが望ましいです。依存関係は cargo-tree コマンドを使って調べられます。
メンテナンス状況
メンテナンス状況も気になるところです。開発や運用を継続的に行うプロジェクトであれば使っているライブラリの不具合や脆弱性に対応する必要が出てきます。その際ライブラリ側の修正をただ取り込めばよいのか、自分たちで修正を作るのか、自分たちで修正を作ったとしてそれをライブラリ側に取り込んでもらえるのか(取り込んでもらえるような修正を作れるのか)、あるいはそのライブラリを使うのをやめられるのか、そうしたことを気にしなければなりません。
ライブラリ情報の社内共有
ライブラリについて調べてみて分かったことや気になったことがあれば社内でも共有します。弊社にはバックエンド共有会という場があるのでそれを活用しています。バックエンド共有会は主にバックエンドエンジニアが下記のようなことについて話す場です。
ライブラリを使ってみた感想なども上記の話題の一部として話していますが、こうした情報共有にはサイロ化を抑えるという側面があると考えています。弊社ではマイクロサービスを採用していてチームのメンバーが向き合うコードベースが必ずしも同一ではありません。ビジネスやプロダクトレベルの情報共有については別の定例会議がありますが、技術レベルでもお互いのやっていることをある程度把握できるようバックエンド共有会という場が設けられています。
ただ、そういう組織運営上の理由以外にも、気軽に技術情報を共有できるのが楽しいという側面もあると思っています。それなりに気心も知れていて興味関心にも共通項があり互いに秘匿すべき情報も少ない、という場だからこその話しやすさがあるのかもしれません。
おわりに
今回は業務で用いる Rust のライブラリをどのような過程で選んでいるかご紹介してみました。記事を通じて弊社のバックエンド開発の雰囲気のようなものが少しでも伝われば幸いです。
エモーションテックでは顧客体験・従業員体験の改善をサポートし世の中の体験を変えるプロダクトを開発しており、その中で Rust も利用しております。もし興味を持っていただけましたら、ぜひ採用ページからご応募をお願いいたします。
*1:2017年の記事 The Rust Libz Blitz を読む限り、標準ライブラリは発展が保守的になりがちなので小さく抑えておくのが Rust には合っているという判断があったようです。
*2:会社の製品に組み込む形ではありませんが、私は Inquirer.js と似た機能の inquire を自分で使うツールに使ったり Object#tap と似た機能の tap を手元での print デバッグの補助に使ったりしています。 tap は更新が止まっているようなのでもし製品に組み込む場合はより慎重な検討が必要かもしれません。
