Shinjuku.rs #17を開催しました

第1旅行プラットフォーム部 エンジニアの高橋です。

うだるような暑さを感じていたのもつかの間、あっと言う間に肌寒さを感じる気候になりましたね。秋もすぐそこまで来ているのでしょうか。
この記事では8/31（火）に開催したShinjuku.rs #17の様子についてご紹介します。GraphQL、tokio::mainの処理について、AWS LambdaへのRust利用、関数の型検索についてLTをしていただきました。

過去のイベントの様子についてはこちらからご覧いただけます！
https://www.forcia.com/blog/event/shinjukurs/

LTの内容

LT1 | RustでGraphQLやってみた | y-fujiwara さん

LT1人目はy-fujiwaraさんから、Rust + GraphQLでタスク管理のアプリケーションを作ってみたという内容で発表いただきました。GraphQLは近年注目されてきている、APIのクエリ言語（およびサーバーサイドのランタイム）で、スキーマを定義することでサーバーサイド、クライアントサイドの両方で型を意識した開発することができます。

RustでGraphQLを実現する部分にはjuniperを利用したそうです。juniperを利用する際はアトリビュートを記載する必要がありますが、juniperのバージョンによってその書き方が大きく変わるため注意が必要、とのことでした。

GraphQLを使ってみた感想をお伺いしたところ、サーバーサイドからクライアントサイドに型を引き継げるのはとても便利で、特にフロントエンジニアにとってはありがたいだろうと感じたとのことでした。一方で、N + 1問題（クエリをループで実行してしまうことで、処理に時間がかかる問題）への対応など、サーバーサイドの実装ではかえって大変な場面も多かったとのことです。

これからRustでGraphQLを使われる方は、y-fujiwaraさんの書かれたコードを参考にされるととっつきやすいかもしれません！
https://github.com/toranoana/wbs-back

LT2 | #[tokio::main]は何をやっているのか？ | motoyan_k さん

二人目はmotoyan_k さんより、#[tokio::main]の挙動についてLTをしていただきました。tokioはRustで非同期処理のプログラムを作成する際によく用いられるクレートです。
tokioを用いる場合、非同期処理をする際は以下の例のようにコードブロックの前に #[tokio::main]を記述します。

#[tokio::main]
async fn main() {
    println!("Hello world");
}

この時、#[tokio::main]とはいったい何者で、どのように動作するのでしょうか？motoyan_kさんはそこに興味を持たれて、公式のドキュメントを調べてみたとのことでした。
公式ドキュメントによると、先ほどのコードは以下のように評価されます。tokioのランタイムの中で非同期処理として実行させる、ということのようです。

fn main() {
    tokio::runtime::Builder::new_multi_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            println!("Hello world");
        })
}

わからない処理をそのままにせず、公式ドキュメントに当たって処理を確認する姿勢は自分も見習っていこうと思います！

LT3 | AWS LambdaでのRust利用 | FORCIA 原 旅人

3人目は弊社エンジニアの原より、AWS LambdaでのRustの利用についてLTを行いました。AWS Lambdaはサーバレスで利用可能な、プログラムの実行環境です。Lambdaの課金体系は 実行回数と実行時のメモリ量 × 実行時間となっており、実行速度の速くメモリ消費量の少ないRustはLambdaでの利用に適していると考えられます。
今回のLTでは、LambdaにおけるRustの優位性を確かめるため、Rustの他にGo, TypeScript, Pythonのそれぞれで同じ処理のプログラムをLambdaで動かしたときの実行時間やメモリ量を計測結果を発表していただきました。

計測結果をグラフにまとめたものが上図です。コンパイラを必要とするRust, GoとPython, TypeScriptで実行時間に大きな差があることがわかります。RustとGoの比較については、CPU性能を上げた場合はGoほうが実行時間が短くなる傾向にあったそうですが、逆にRustはCPU性能が低くても高速な実行が可能だったとのことです。

また実行時間のグラフではどの言語でもピークが二つ登場していますが、Rustはそのばらつきが小さいことも特徴といえそうです。
この測定結果から、やはりRustはLambdaでの利用に適していると言えそうです。なかなか定量的に測定を行ったデータはないと思うので、とても興味深いデータだと思います。

LT4 | Rustの自作API検索エンジンRoogleについて | hkmatsumotoさん

LT4人目はhkmatsumotoさんから、Rustの関数を型を用いて検索できる自作の検索エンジン「Roogle」について紹介いただきました。
コーディングの最中に「こんな挙動の関数が使いたいんだけど、なんて名前だっけ？」と思う場面は多々あると思います。しかし関数の名前がわからないと、ネットで検索するのも一苦労です。そんな時、関数の名前ではなく引数と返り値の型をもとに検索ができるのが、今回紹介していただいたRoogleです。私はそのような検索を初めて聞きましたが、Haskellにはすでに Hoogleという同様のサービスがあるようです。そのRust版を現在作成中とのことでした。

検索の仕組みは、クエリで指定した引数・返り値の型と、各関数の引数・返り値の型との一致度を計算し、一致度が高いものから順に表示するというものだそうです。関数の名前も追加で指定して検索することもできるとのこと。

今後の展望として、クレートをまたいだ関数の検索、検索サーバーを立てて検索インデックスの読み込みを高速化する、などを検討されているそうです。
さらにRustの公式コミュニティからも声がかかっているようで、今後共同開発などもあり得るかもしれないとのことでした。今後にますます期待ですね！

次回のShinjuku.rs #18は 10/26(火)に開催予定です

次回のイベントへは以下のページからお申込みいただけます！

RustのLT会 Shinjuku.rs #18 @オンライン

Rustを商用利用した話、Rustでこんなものを開発した、Rustの面白い仕様を紹介したい、Rustにcontributeしたなど、Rustに関連する内容ならなんでもWelcomeです。皆様からのLTをお待ちしています！