ディスカッション
久松氏：
公式のドキュメントだけでは現場レベルの特徴や利便性を十分に把握するのは難しいと思います。そこで、GoやRustがどのように現場で活用されているのか、お二人にお話しいただきたいと考えています。
今回は100名以上の方々が参加されています。自走式での言語活用や、転職を機に新しい言語でのプロジェクトを考えている方々にとって、参考になれば幸いです。
では早速、一つ目のテーマにいきましょう。
GoとRustを主な言語として選んだ最大の理由や動機は何ですか？
久松氏：
プログラミング言語やその特性、利点、プロジェクトでの役割、パフォーマンス、セキュリティなど、多角的な視点からお二人の話を聞きたいと思います。まずはyukiさんからお願いします。
yuki氏：
Rustに出会ったのは2017年頃のことです。当時は金融機関向けのリスク管理計算システムをJavaで開発していました。その中で並行処理を多用する場面が多かったのですが、そこで多くの問題が発生していました。
そんな中、ある日はてなブックマークなどを眺めていたとき、Rustは並行処理や変数の可変性の制限などを言語レベルで厳密に管理してくれるという記事を発見し、それがRustに興味を持ったきっかけです。JVMだけでは達成できないような高パフォーマンスや、Javaの言語仕様ではカバーできない特定の制約に対処できるとのことで、Rustを使い始めました。
久松氏：
tenntennさんはいかがでしょうか。
tenntenn氏：
私が初めてGoに触れたのは、多くの人がGoを知るよりもずっと前、おそらく2011年か2010年頃です。当時はまだ正式にリリースされていなく、Goの具体的な用途も明確ではありませんでした。私がGoを始めた理由は二つあります。
一つ目は、Googleが開発したという点に興味があったからです。二つ目は、当時大学院生で、研究で使えるかもしれないと思ったからです。Javaでも開発をしていましたが、何か新しい言語を試してみたいと思い、D言語も検討しましたが、結局はGoを選びました。
久松氏：
ありがとうございます。では、ここからはさらにディスカッションを深めていきましょう。
それぞれの言語を比較した時に、シチュエーションごとにどちらが適正などはありますか？
久松氏：
GoとRustを比較する際に、どちらがどのようなシチュエーションで適しているのかについてお聞きしたいと思っています。プロジェクトの性質、スピード、安定性、平行性、メンテナンスといった多角的な観点が考えられると思います。以前別のイベントで他のプログラミング言語の比較についても話したことがあり、その際には参加者のバックボーンについても触れられました。
お二人とも、プロジェクトリードや言語選定に関わった経験があると思うので、その点についてもぜひお聞きしたいと考えています。次に進む前に、tenntennさんからお話をいただければと思います。
tenntenn氏：
Rustについては詳しくないので直接比較は難しいですが、Goは最近よく選ばれる言語です。Goは開発効率に焦点を当てて設計されているため、チームでの開発が非常にしやすいという点が採用される大きな理由です。また、クラウドやミドルウェアでGoが多く使用されているので、スケーラビリティを求めるシステム、特にバックエンドでよく使われています。
久松氏：
ありがとうございます。それでは、yukiさんはいかがでしょうか。
yuki氏：
まず、Rustが一番力を発揮するのはシステムプログラミングの領域です。これには組み込みOS、ブラウザのようなメモリ管理が非常に重要なアプリケーションが含まれます。
一方で、RustをWeb開発など他の用途で使おうとすると、他の言語では経験しないような困難があることは確かです。
ソフトウェアの中で、とくに高速化が必要であったり、あるいはハードウェア側の制限などの理由で使用可能なメモリ量が少ないなどの理由で、C++が用いられている箇所にRustを代用することは十分可能です。実際、私たちの会社でもC++を使っていた部分をRustで置き換えるような作業を最近行っています。
Goに関してですが、私自身、『ISUCON（イスコン）』というイベントにおいて、ベンチマーカーと呼ばれるリクエストを送ってスコアを測定するアプリケーションの実装でGoを使った経験があります。このアプリケーションでは多くの並行処理が必要ですが、Goの並行処理のプリミティブが非常に良く設計されているため、書きやすかったです。Goは並行処理が多用されるような場面に特に向いているという印象を持っています。
Goでのプログラミングは手軽で、高いパフォーマンスを出せるアプリケーションを作成することが可能です。この手軽さとパフォーマンスのバランスがGoを特徴付けるポイントだと思います。
久松氏：
C++の一部をRustに替えた場合、パフォーマンスはどれくらい向上するのでしょうか？
yuki氏：
パフォーマンスに大きな変化はないと考えられます。C++をRustに替える主な理由は、ビルドツールの利便性やコードの安全性、さらには開発者の好みが影響していると思います。速度面で言えば、完全に計測環境や条件依存で、条件次第ではC++もRustもそれぞれ優れているケースがありますが、Rustに変えたからといってC++よりかなりパフォーマンスが向上するといったような、劇的な変化は期待しない方が良いと思います。
久松氏：
ありがとうございます。tenntennさん、Goの選定とマイクロサービスについてよく議論されると思いますが、これらを一緒に考慮するべきですか？それとも、yukiさんが言ったように部分的な変更から始めてもいいのでしょうか。この点で何かアドバイスがありますか？
tenntenn氏：
新しいプログラミング言語を導入しながらマイクロサービスを入れ替えるのは、非常に困難だと考えています。例えば、現在PHPを使用している組織がGoを採用する場合、コマンドラインツールなど、Goで比較的簡単に作成できる部分から始めることをお勧めします。
久松氏：
ありがとうございます。それでは、質問が一つ来ていますので、それに移りたいと思います。
RustをWebAPIで使用するのは過度だと感じますか？
yuki氏：
ポジショントークをするならば、Rustを使って開発してみたいと思ったらやってみるのが一番だと思います。ただ、Rustに詳しい方が一人いると、そのプロダクトへのRustの導入が円滑に進みやすいとは思います。
もちろん、RustのWebサーバーの実装への導入は、余計な苦労をたくさん持ち込み「やりすぎ」と感じることもあるとは思います。重要なのは、きちんとRustを導入する目的や狙いを定め、導入によってどのようなペインを回避できるかを考え、チームに伝えてから導入することです。
WebAPIの場合であっても速度が求められるケースもありますので、速度面での期待をこめてRustを導入するのは理にかなっています。私が聞いている限り、Rustの言語仕様の豊富さを期待して導入する人も多いようです。パフォーマンスや言語仕様から来る堅牢で保守運用のしやすいアプリケーションの構築が目的なのであれば、「やりすぎ」ではなくなる可能性があります。
重要なのは導入する目的で、その目的によって当然ですが、Rustの使用に対する印象は大きく変わるでしょう。
久松氏：
ありがとうございます。先ほど触れたように、前回KotlinとScalaについて、専門家を招き話をした際、どのような組織やエンジニアがこれらの言語に向いているか、逆に向いていないかについての議論が盛り上がりました。tenntennさん、Goについての意見はいかがでしょうか？
tenntenn氏：
Goは難しい言語ではありません。正しく使えば、多くの組織や場面で適していると思います。ただ、例えばモバイルアプリの開発などは適していないかもしれません。私の所属しているスタートアップもGoを利用していますし、大手企業、例えばGoogleなど海外の大きな企業でも使われています。
組織の規模による影響は少ないと感じます。ただ、特定の言語にこだわりがある場合は、移行は難しいかもしれません。
久松氏：
ありがとうございます。yukiさん、Rustについて、何かご意見はありますか？
yuki氏：
私たちの会社でも、組織規模が大きくないチームでRustを使用しており、大きな問題は生じていません。組織の規模はRustの使用に直接的な影響はないと感じています。しかし、RustでWebアプリケーションを一度作成・運用した経験がある人が少なくとも1人は必要だと感じます。そうでなければ、実際の運用が難しいという印象です。
ただ一方で、私も経験があるのですが、Rustを使用したいと考え実際に採用したものの、チーム内全員がRust初心者だったようなチームがありました。そのようなチームはやはり苦戦していました。
その理由として、ネット上のRustのサンプルコードが少ないこと、国内の出版物に実用レベルのアプリケーションのコードサンプルを含むものが少ないこと、そしてRust特有の言語機能（所有権、ライフタイム、トレイトなど）に初心者がつまずく傾向があるためです。
これらの理由から、少なくとも1人はRust経験者（少なくともプライベートでRustを使って一度アプリケーションを構築した経験がある人）がいる組織だとうまくワークするだろうと考えます。これはどのプログラミング言語の導入時であっても言われる話かもしれませんが、Rustでも同じです。
久松氏：
ありがとうございます。確かに、誰も経験がないままプロジェクトを進めると、どのプログラミング言語でも完成後のイメージが難しいですね。Q&Aから関連性の高そうな質問をピックアップしてみたいと思います。
セキュリティの観点で、RustとGoどちらが適しているか
yuki氏：
「セキュリティの観点」の「セキュリティ」という言葉が何を指すかによって大きく答えが変わります。例えばセキュリティでよく問題になるメモリ安全性の一例としてダングリングポインタを防ぎたい場合、Rustは静的解析でそのような問題が起こらないように設計されています。その点で言えば、Rustが強いと言えます。
tenntenn氏：
個人的な印象ですが、セキュリティの面ではRustが適しているように思います。しかし、どちらにせよ、重要なコードを変更することはリスキーです。
久松氏：
ありがとうございます。それでは、メインテーマの第3項目に進みたいと思います。
現場ではGoまたはRustではウェブアプリケーションフレームワークを利用されますか？
どのようなフレームワークが使われているのか、また、フレームワーク選択に影響を与える要因は何かという点ですね。特に、選定する際のポイントや注意点についても詳しく知りたいとのこと。tenntennさん、どうぞお答えいただけますか。
tenntenn氏：
WebフレームワークはGoにも存在し、Gin、Echoなどがよく利用されています。しかし、Goはマイクロサービスの文脈でよく一緒に議論されるgRPCといったテクノロジーともよく組み合わされるため、RESTfulなWebフレームワークを使用していない組織も多いです。
GoのWebフレームワークは一般的に薄く、標準ライブラリのnet/httpパッケージを直接使うケースが多いです。次のバージョンでは標準ライブラリが大幅に改善される予定なので、将来的にはフレームワークが必要なくなる可能性もあります。
久松氏：
はい、ありがとうございます。次にyukiさん、いかがでしょう。
yuki氏：
RustではWebアプリケーション用のサードパーティライブラリを使用することになります。Rustは標準ライブラリが薄いため、Goとは違い、標準ライブラリで簡単にWebアプリケーションを扱うことできません。
業務でよく使われるのはactix-webとwarpです。warpはactix-webと比較するとマイナーですが、TwitterのScalaフレームワークFinchにインスパイアされています。最近人気が出ているのはAxumというクレートで、使いやすさが重視されています。
Axumは特に、コンパイルエラーメッセージをカスタマイズする機能があり、それが使いやすさに寄与しています。ただ、Axumはまだ開発途中で、マイナーバージョンが変わるとAPIも変わる可能性があります。そのため、現在は安定性のあるactix-webを主に業務では使用しています。
Rustの非同期処理は、サードパーティの非同期ランタイムライブラリ、例えばtokioやasync-stdに依存しています。非同期処理に関するライブラリは多数ありますので、興味があれば調べてみてください。
※各リンク
tenntenn氏：
RustとGoは思想が違うなと感じました。Goは標準ライブラリを非常に重視しており、一般的に必要な機能は基本的には標準ライブラリでカバーされている傾向があります。これは、みんなが同じものを使うという文化が根付いているからです。一方で、Rustはよりミニマリストなアプローチをとっていると感じました。どちらが良いか悪いかは一概には言えないと思いますが、それぞれが持つ特性は面白いです。
yuki氏：
Rustの標準ライブラリが薄い主な理由は互換性の問題を回避するためと言われていますが、さらに加えて個人的に思うのは、Rustは使用される領域が非常に広いことも要因のひとつなのではないか、ということです。
ベアメタルな環境（OSやそのほかのソフトウェアがインストールされていない環境）でも動かさなければならない場合もあるため、必要に応じて標準ライブラリを剥がすこともあります。
たとえばHTTPのルーティングなどは、そうした環境では使わない可能性が高く、使わないにも関わらず標準として用意しておくと無駄になります。Rustのメンテナンスの観点から考えても、標準ライブラリのメンテナンスコストが上がっていくことになります。
そのような理由から、Rustのライブラリは意図的に小さく設計されているように思います。この点はGoとは確かに異なります。
久松氏：
ありがとうございます。それでは、次のテーマに移りましょう。
他の言語からGoやRustに移行する際の経験や、その際の課題、学びは何でしたか？
yuki氏：
業務での経験は主にJavaとScalaですが、Rustについて学んだ最大のポイントは、同じ処理を行ってもRustのリソース使用量が非常に少ないという点です。特にメモリ使用量がかなり減る印象を持っています。
また、Rustではメモリ制御が非常に細かくできます。例えば、JVMのガベージコレクション（GC）ではオブジェクトの解放タイミングが不明瞭な場面がありますが、Rustではそのタイミングがはっきりとわかる（不要になったらすぐに解放する）ので、それが非常に良い点だだと感じています。
一方で、課題としてはRustのエコシステムがまだ成熟していない面があります。他の言語にはあるライブラリがRustにはなく、自分で実装する必要がある場面もしばしばあります。しかし、ユーザー数が増えればこの問題も解消されると期待しています。
久松氏：
スタックオーバーフローで見ると、若い人たちが学びたい言語ランキングでRustが1位になっていることがあるようですが、このトレンドについてどう思いますか。ユーザーが増えているように感じますか。
yuki氏：
はい、最近その傾向があると思います。前職で新卒の採用も行っていたのですが、「Rustを使っています」という学生が増えている印象を受けました。
久松氏：
ありがとうございます。tenntennさんが学生と交流する際、Rustを使用しているというコメントを頻繁に聞くそうですが、GoやRustの使用が増えていると感じる点はありますか？
tenntenn氏：
Goの使用が増えてきたのは以前から感じていますが、特にRustの使用も増えていると感じます。学生に利用しているプログラミング言語について尋ねると、Rustを勉強しているという方が多いようです。
久松氏：
ありがとうございました。次の質問はyukiさんに特に向けています。Rustでガベージコレクション（GC）がないことのメリットを実感した経験はありますか？
yuki氏：
先ほども述べたとおり、オブジェクトの解放タイミングがわかりやすい点です。ただ、GCがないことによって、たとえばRustでは所有権やライフタイムなどの別の複雑性を持ち込んでいることは確かなので、GCのあるなしにはメリットとデメリットがあり、一概にあらゆる場面でそれが良いと言い切れないのもまた事実です。
久松氏：
ありがとうございます、それでは次の話題に進みましょう。
今後、GoやRustの技術やエコシステムがどのように進化していくと予想しますか？また、それに伴い現場での使用シーンにどのような変化が起こると考えますか？
久松氏：
新たな機能、ツール、ライブラリ、パフォーマンスとセキュリティの向上、さらには将来のトレンドと影響についての意見をお聞きしたいと思います。yukiさん、お願いします。
yuki氏：
Rustには低レイヤーとそれ以外の用途で異なる考慮点があると思います。例えば、OSやブラウザの開発においては、すでにRustは多く使用されています。国内では、自動運転に関連する企業がRustでOSを作っているという話も聞きます。
さらにGoogle Chromeにも部分的にRustが採用されているようです。最近では、Linuxのデバイスドライバーにも使われ始めています。こうした分野でのRustの使用が今後も拡大していくでしょう。
こうした分野では、メモリの安全性に関しての課題が多かったようです。例えば、Googleが発表する資料では、メモリに関する脆弱性が取り上げられています。Rustはこの問題を効果的に解決できるので、これを大きな理由として採用が進むと考えられます。
Web側に関して、Webサーバーの開発では、使用するプログラミング言語によらず期待する結果は得られると感じます。私自身もScalaやJavaでの開発経験があり、特に大きな問題に直面したことはなかったので、結果が大きく変わることはないと思います。そのため、この分野でRustが主流になることは、一定の課題があるかと思います。
アプリケーションの大部分を構築するような使われ方をするかは疑問です。一部のコンポーネントの高速化など、特定の目的でRustが採用されることが多いと感じます。私が見る会社内の状況からも、このような限定的な使用が主流だと思います。
久松氏：
わかりました。tenntennさん、いかがでしょうか？
tenntenn氏：
Goが使われるシーンは増えており、Go Conferenceのスポンサー企業も50社ほどに増えています。これはGoエンジニアを求めている企業が増えている証拠です。
Goの進化については、公式ブログで報告されているように、基本的にはGoのバージョン2というバージョンは出ない予定です。後方互換性を崩すような大きなバージョンアップが必要な場合のみGoのバージョン2が考慮されるとされていますが、そうなる可能性は低いと言われています。
そのため、Goは後方互換性を保ちながら進化すると見られ、これが言語の安定性につながっていると思われます。
新しい機能が追加されることに制限はありません。例えば、最近のGoのツールチェーンでは、新しいバージョンが必要な場合はツールチェインが自動で新しいバージョンをダウンロードしてインストールされる機能が追加されました。
さらに、for文のループ変数の扱いが変わるアップデートがあったり、新しいfor range文のいわゆるイテレータと呼ばれる仕様の追加が提案されたりと、攻めた仕様も多くなっています。
標準ライブラリにも新機能が増えており、例えば構造化ログのライブラリが追加されたり、バージョン1.18からはジェネリクスが導入されるなど、機能が急速に増加しています。新機能が後方互換を保ちながらも追加されている流れがあります。
これらの変化に対して、現場のエンジニアはしっかりとキャッチアップする必要があります。新しい機能が次々と追加されているので、その波に乗り遅れる可能性もあります。
GoとRustそれぞれに欲しい機能などあれば教えていただきたいです
久松氏：
ありがとうございます。関連するQ&Aで「GoとRustそれぞれに欲しい機能などあれば教えていただきたいです」という質問が来ています。tenntennさん、お願いできますか？
tenntenn氏：
実は私が望んでいたジェネリクスとイテレーターは既に取り込まれていたり、導入される予定がありますので、大体の要望は満たされています。ただ、エラー処理についてはまだ改善の余地があると感じています。
久松氏：
ありがとうございます。yukiさん、いかがでしょうか？
yuki氏：
ビギナーのレベルを越えた話になりますが、私が注目しているのは主にふたつです。ひとつめは「Async Iterator」と呼ばれる非同期ストリーミング処理です。ふたつめは非同期処理におけるキャンセル機能です。Goではこのキャンセル処理がかなりスムーズに行えるのですが、Rustで同じことをすると非常に手間がかかります。
特にISUCONのベンチマーカーをRustで書くのは、Goのような手軽なキャンセル機能がないと厳しいと感じています。そのため、非同期処理周りの機能が今後も充実していくと嬉しいです。
非同期処理、特にRustでのasync/awaitについてですが、この機能は2018年頃に新しく追加されました。しかし、実装がまだ完全ではなく、いくつもの未実現の機能や解決すべき問題点が存在します。
Rustでの非同期処理には特有の困難があり、特にメモリ安全性を確保したり、コンパイラレベルで並行処理の安全性を守る必要があるため、他のプログラミング言語に比べてその対処が大変です。これらの課題が解決されたら、非常に助かると個人的には思います。
久松氏：
了解しました。それでは、このテーマについての説明をここで終わりにして、次に質疑応答のセッションに進んでいきましょう。
質疑応答
各言語と機械学習との相性はどう思いますか？ディープラーニングとかでも使われてますか？
tenntenn氏：
Goにも確かに機械学習の基礎的なライブラリや数学系のライブラリは存在します。しかし、すでに構築されたエコシステムがあるため、機械学習の文脈ではPythonが主流だと思います。多くの企業がGoを主要な言語としていても、機械学習に関してはPythonを使っているケースが多いです。
久松氏：
ありがとうございます。yukiさん、いかがでしょうか。
yuki氏：
確かに、表面的には機械学習の計算などをPythonで書くことが多いですが、その裏にはRustが使われているケースが結構あります。一般にこの種のライブラリはC++で書かれることが多いのですが、例えばPolarsというPythonのデータフレームのライブラリなどは、実際には裏でRustが動いていたりします。
この点は機械学習とは直接関係ないかもしれませんが、我々の会社でも、検索エンジンの部分などはRustで書かれています。
RustとGoをどのように学習していくのが良いでしょうか
tenntenn氏：
Goの学習書籍は最近1,2年で増加しています。柴田さんによる翻訳本もあり、年間におおよそ3冊ぐらい新しい本が出ているという印象です。ただ、Javaのように多種多様な本があるわけではないので、自分にぴったりの教材が見つからないかもしれません。
Goを学びたい方には、私自身が制作した動画教材もあります。「Gopher道場」というキーワードで検索していただくと、約10時間分の資料が出てきますので、それを参考にしてもらうのも一つの方法だと思います。
久松氏：
ありがとうございます。yukiさん、Rustについてどう思いますか？
yuki氏：
Rustの入門書は確かに多く出版されています。私自身もそうした入門書を書いたことがありますが、これらの入門書やWebサイトで基本的な文法は簡単に学べます。ただ、問題はそれ以降です。
Rustの言語機能をどのように活用して実際のアプリケーションを作るか、という点については、まだ十分な資料や本が出ていないと感じています。特に、Rustに特有の機能やパターンが他のプログラミング言語とは異なるケースが多々あるのですが、その使い方を説明する資料は少ないです。
実は、そのような内容に焦点を当てた本を現在書いており、来年には出版される予定です。この本が役に立てばと思っています。
Rustは、CやC++の言語知識が前提にあった方が、学習速度や便利な点に気づきやすいのではないでしょうか。Rustから低レベルプログラミングの勉強はあまり適していないでしょうか
yuki氏：
この質問は非常に興味深いものだと思います。CやC++に既存の知識があると、Rustに入門しやすかったり、Rustが解決する点に気づきやすかったりするというのは、確かにその通りです。
次に、「Rustから低レベルプログラミングを学ぶのは適していないか？」という質問に対しては、一概には言えません。個人的には、RustでOSの教材が存在する場合、それを用いるのは悪い選択ではないと考えます。OSについての概念や動作原理を学びたいのであれば、教材がしっかりと解説していれば、使用する言語がRustであってもCであっても、目的は達成できるのではないかと思います。
一方で、低レイヤーの実装には、C言語の知識が不可欠な場面もしばしばあります。Rustも非常に有用ですが、このような状況を考慮すると、CとRustの両方に習熟しておくことが最も理想的だと個人的には考えます。
C言語との接続性の特徴はありますか
yuki氏：
RustにはForeign Function Interface（FFI）という機能があり、これによりC言語の関数を簡単に呼び出すことができます。
tenntenn氏：
GoにもCGOという機能がありますが、CとGoは基本的には異なる言語です。特にメモリ管理については、Goの範囲を超えている部分もあるので注意が必要です。
久松氏：
これらの機能はよく使われているのでしょうか？
tenntenn氏：
実際には結構使われています。特にCで書かれているライブラリのラッパーや低レイヤーの領域では、それをGoで書き直すのは現実的ではありません。そのような場合には、Cを介して他の言語と連携することがよくあります。
RustとGoのライブラリをどうやって探していますか。ウォッチしておいた方がいい開発者の方などいますか？
yuki氏：
ライブラリの情報収集方法として、RedditのRust専用スレッドを利用しています。また、Rustには「This Week in Rust」というマガジンがあり、毎週開発者が記事を投稿しています。このマガジンで興味を引かれる記事をチェックしていますが、英語で書かれているため読解が必要です。
特に注目している開発者としては、John Titorさんとdtolnayさんの2人がいます。ジョンタイターさんはRustのコミッターで、日本人です。DトルネイさんはRustの「serde」などのライブラリを手掛けています。2人の公開するクレートや、ジョンタイターさんのGitHubのスター履歴などをチェックしています。彼らはRustコミュニティでも有名で、私も頻繁に見ています。
久松氏：
了解しました、tenntennさん、お願いします。
tenntenn氏：
Goのライブラリを探す際には、「pkg.go.dev」というサイトがあり、そこで検索するのが一つの方法です。私自身の情報収集方法はかなり特化しているので、一般的な参考にはならないかもしれません。具体的には、Goチームの内部で行われる次の機能に関するミーティングの結果を参照したり、ソースコードを直接見たりしています。
いきなりだと難しいと感じるかもしれませんが、実は私は週に一度、木曜日の朝に勉強会を開いています。早起きが得意な方は、そこで最新の情報を得ることができます。
Rustでこれまでどういったものを作ってきましたか
yuki氏：
CPUのエミュレーターやプログラミング言語の実装に参加しています。自分自身でライブラリを作成して公開するような活動はあまりしていません。
それよりも「車輪の再発明」が好きです。最近ではDNSリゾルバの実装も手がけました。幅広いプロジェクトに挑戦しています。
最近のプロジェクトとしては、Schemeのコンパイラを開発しています。現在は一時停止していますが、次に時間ができたら続けたいと考えています。
GoでもRustでも、DB操作を行うライブラリに迷うのですが、採用理由なども含めてどのように選定されていますか
tenntenn氏：
GORMというライブラリは多くの会社で使われていますが、個人的にはおすすめしません。
私が推奨するのはBunというライブラリです。その理由は、Goらしいシンプルな使い方ができるからです。シンプルに使えるライブラリを選ぶ方が良いと考えています。
yuki氏：
実用的なオプションとしては主に2つあり、一つ目は「diesel」というライブラリで、これはオブジェクトリレーショナルマッピング（ORM）を提供します。我々の会社でも使用しているのですが、一つ問題点がありまして、それはasync/awaitにまだ対応していないことです。
老舗のプロダクトである「diesel」ですが、現行バージョンではasync/await対応はなく、この点が時としてボトルネックになる可能性があります。
二つ目は「sqlx」という名前のライブラリで、これはGo言語にも同名のライブラリが存在しますが、Rust版がこちらです。sqlxはORMではなく、クエリービルダーとして機能します。
このライブラリはasyncに対応しているうえ、Rustコード内に書いたSQLコードをコンパイル時にデータベースに問い合わせて、そのSQLが正しいかどうかを静的に解析するという驚くべき機能も有しています。この点が特に有用で、多くの開発者がsqlxを採用していると感じています。
さらに、自分はまだ使ったことはないのですが、「SeaORM」という新たなORMも出てきています。
このライブラリは「sqlx」を基盤として作成されていて、『パーフェクトRust』という入門書で紹介されているなど、徐々に注目を集めているようです。
GoやRustで開発する中で、多言語と開発パラダイムが変わったなと思うようなポイントはありますか
tenntenn氏：
Goで特に印象的なのは、ゴールーチンとチャネルの存在です。他の言語にはあまりこのような機能はありません。私がGoを始めた当初、これらの概念は非常に難しく感じました。今でも、平行処理は一般に難しいと感じていますが、Goにおけるこれらの機能は特に他の言語と異なると思います。
yuki氏：
私はJavaからRustに移行した経験がありますが、いくつか大きな違いがありました。まず、Rustではより論理的にプログラミングする必要があります。特に集合論的な考え方を用いる場面が増えました。
さらに、Rust特有の「所有権」と「ライフタイム」という概念があり、これによってメモリ管理についても新たな考慮が必要になりました。これらの変更点は、JavaからRustへの移行において、かなり大きなジャンプを必要としたと感じています。
Cや++は今後Rustに置き換えられてしまうと思いますか？
yuki氏：
確かに、一部のコミュニティではRustがC++を置き換えるとしきりに主張されているようにも見受けられますが、私自身はそのようには考えていません。
大規模なアプリケーション、例えばChromiumはC++で作られている場合が多いです。
そういった大規模なプロジェクトのコードベースをすべてRustで置き換えるのは、時間的な意味やかかるコスト的な意味で非現実的です。セキュリティやメモリ安全性が特に重視されるコンポーネントについてはRustを使用する可能性があるとは思いますが、全体としてはC++がRustに完全に置き換わることはないと考えています。
Rustでデスクトップアプリ、WebAPIなどを書いていますが、ビルド時間が気になります。対策はございますか
yuki氏：
Rustでのビルド時間に関しては、高性能なマシンやサーバーを導入するのが効果的です。Rustはコンパイル時に多くの問題を解決するため、ビルド時間が長くなることは避けられません。特にマクロと呼ばれる機能を使用したライブラリはビルドに時間がかかります。
CIの場合、ローカルマシンとは異なり、インクリメンタルコンパイルやキャッシュを効果的に利用することで改善することができます。このような情報は既にいくつかの記事で取り上げられているので、それらを参考にすると良いでしょう。
Goのビルド速度のような高速さは期待できませんが、Rustのビルド速度に関する改善は継続的に行われています。そのため、今後のアップデートや改善を期待してください。もし可能であれば、Rustのコミュニティに参加し、直接改善に貢献してもらえると嬉しいです。
WasmとWASIを利用する場合、GoとRustのどちらが向いてますか
tenntenn氏：
GoでのWebAssembly（Wasm）の利用は現時点ではあまりおすすめしません。Wasmのサポートはまだ不十分で、生成されるファイルも大きいです。WASI（WebAssembly System Interface）に関しても、最近のバージョンアップでようやくプレビュー版のサポートが追加された程度です。
Goに関しては、少なくとも直近ではWasmのサポートに期待しない方がよいと思います。一方で、TinyGoは期待できるかもしれません。
yuki氏：
RustはWasmとの相性が良いとされています。私が以前チュートリアルをやってみた限り、問題なく動作しました。
Goのフレームワークでよく使われているライブラリを教えてください
tenntenn氏：
Gin、Echoは確かによく使われています。もし追加するとすれば、Chiなどが挙げられます。しかし、Goのバージョン1.22や1.23でのアップデートにより、標準ライブラリが使いやすくなります。
技術選定段階であれば、重たいフレームワークの採用は控えるべきだと感じています。もし可能であれば、2024年の2月まで待ってみてください。
過去にDiscordがGoからRustに移行した事例がありました。WebAPIの初期開発においては最初からRustで実装するか、チューニングの余地がなくなってからRustに移行するか、どちらが良いかとも良いと思いますか
yuki氏：
私は現在もこの問題に悩んでいます。一部だけを切り出してRustで改善することができるなら、その方が良いと思います。
こちらの話は、アプリケーションをフルリプレイスしたいという趣旨ですか？それとも一部のコンポーネントに関することでしょうか？話の内容は、これによって変わります。
フルリプレイスは現実的ではないかもしれません。特に会社で実施する場合、リプレイスしている間の開発者リソースやビジネス上の収益の問題が生じる可能性があるため、容易にはおすすめできません。
要件定義時点からパフォーマンス要件が厳しい場合や、Rustを選ぶことはおすすめできると思います。
いずせにせよこの問題はケースバイケースですので、一概にはいえません。
tenntenn氏：
Discordに関する話がよく出ると思いますが、現在の最新版が以前と同じ状況かどうかは、再計測が必要だと考えています。特にGoは、パフォーマンス面で多くの改善がされていますので、以前のデータをそのまま引用することには疑問があります。
プログラミング言語の選択は、プロジェクトの要件だけでなく、チームメンバーのスキルセットも大きな要素であると思います。特に、ビジネスの目的がサービスを立ち上げることなら、チームが開発しやすく、将来的に言語をリプレイスする必要が少ないものを選ぶべきだと考えています。
究極的には、どの言語を選んでも問題はないと思います。たとえば、Rustのスペシャリストが集まっているチームなら、Rustが適しているでしょう。逆にGoのスペシャリストが多いチームでは、Goが良いという結論になります。このような選択はチームに大きく依存しています。
最後に、GoもRustも採用するにはそれなりに労力が必要であると感じています。それを考慮することも重要です。
yuki氏：
採用について言えば、Rustエンジニアは市場で少ないという印象がありますが、Rustを使いたいと考えている人は意外と多いです。ただし、実際にRustの経験があるエンジニアは少ないので、この点は採用時に慎重に考慮するべきです。
さらに、Discordに関する記事には注意が必要です。その記事は広く拡散しているものの、実情としては最近のGoを用いればそのような結果にはならない、といった疑義が唱えられています。この件については、Russ Coxという人が詳しく分析しています。その内容を翻訳しているので、興味があればぜひご一読ください。
参加いただいている皆様に向けてのコメント
yuki氏：
コマンドラインツールの簡単なアプリケーションを作成するのが、Rustを始めるのにおすすめです。例えば、grepコマンドの基本的な実装から始めるとよいのではないかと思います。
Rustを用いて何かを作成してみて、その使い勝手や可能性を実感してみてください。もし良さを感じたら、ぜひ実際の現場でも導入を検討してみてください。
tenntenn氏：
Goについては、すでに多くの方が知っていると思います。資料も多く提供されているので、ぜひ参照してください。12月には京都で「Go Conference mini」というイベントがあり、Kyoto.goのメンバーが主催していますので、参加をおすすめします。
私も様々なイベントに参加していますし、私が所属するナレッジワークではGoエンジニアを積極的に募集しています。他の会社でもGoエンジニアの需要は高いです。興味があれば、Googleで「Goエンジニア募集」と検索すると多くの情報が出てきます。この機会にGoエンジニアとしてのキャリアをスタートさせてみてはいかがでしょうか。
久松氏：
お二人とも、ありがとうございました。