この記事は、Zennにも投稿しています。
Rustが嫌いです。
zenn.dev

この記事を読んで1Rustユーザーとして思ったことを書いた。
全体を通して
- WASM固有の問題にハマってしまっている
- Rustをスクリプト言語と同じ枠で見てしまっている
の2点が辛さの原因であると感じた。
前者について、この方はフロントエンドにRustを使っているようだがここは確かに整備が行き届いてない分野でWASM特有の問題とJSとのFFIの辛さがもろに感じられて辛いと思う。
割となんでもかんでもRustを使う自分であってもWebフロントエンドにはおとなしくTSを使うようにしている(ただ、dioxusはホットリロードを開発中だったりと結構頑張っているようなのでいつかはRustでフロントエンドも現実的になるかもしれない)。
割となんでもかんでもRustを使う自分であってもWebフロントエンドにはおとなしくTSを使うようにしている(ただ、dioxusはホットリロードを開発中だったりと結構頑張っているようなのでいつかはRustでフロントエンドも現実的になるかもしれない)。
後者について、この記事では全体的に「JSやPythonではこんなに簡単だったのにRustでは難しい/エラーが出る」という評価が多いが、これは後述するようにRustが提供するものと期待のずれが原因だと感じた。
各節について
1
「所有権の概念を理解すれば、あとは簡単です」は事実かも知れないがそこに行き着くのはかなり難しいと思う。(自分もライフタイムエラーで苦しむことはよくある)
1.1についてはコメントに指摘がある通りleakを使わずStringを入れればよいと思う。
1.2は周りのコードをちゃんと見てみないとなんとも言えないがそれこそ所有権を理解していればそこまで苦労はしないはず。
1.2は周りのコードをちゃんと見てみないとなんとも言えないがそれこそ所有権を理解していればそこまで苦労はしないはず。
2
2.1のcfgまみれについてはtraitを使うことで軽減される可能性があるが型システムの表現力不足や定義の煩雑さゆえににcfgを使うことも多い。これはある程度仕方のないことかなと思う。またJSと違いプラットフォームに適合しないコードは大抵コンパイルすらできないので実行時の分岐は困難。
2.2のCargoのfeatureシステムが分かりづらいというのは正当な批判だと思う。自分は最近組み込み向けRustを弄っているがfeature滅茶苦茶になることがある。ただこれより良い解決策があるかとも言われると…
2.2のCargoのfeatureシステムが分かりづらいというのは正当な批判だと思う。自分は最近組み込み向けRustを弄っているがfeature滅茶苦茶になることがある。ただこれより良い解決策があるかとも言われると…
3
3.1の問題は自分もこのエラーに出会ったことがあり、確かにドキュメントが不足気味だった記憶がある。ただ「準必須ツールがインストールできないことが日常茶飯事」だとは思わない。また、nodejsと比較されているがWebが前提となっているJSと比較するのはフェアではない。
3.2についてはそのドキュメントの問題だと思う。
3.2についてはそのドキュメントの問題だと思う。
4
コンパイル時間の遅さについてはその通りで、これはたびたびRustコミュニティでも話題になっている。ただ「開発環境でも動くことを祈って書いた呪文」がこの
4.2についてはこのような事例に当たったことがないのでよくわからない。
.cargo/config.toml
なのは解せない感じはある。このconfigだとビルドは通常よりさらに遅くなるだろう(ただし良いバイナリができる)。4.2についてはこのような事例に当たったことがないのでよくわからない。
5
Rustでも意味不明なエラーメッセージが出ることは確かにあるがこの例で示されたエラーは「Copyトレイトが実装されていない値がmoveされた → なのでその値はもうborrowできませんよ」と明確に示しており特に冗長であるとは感じない。
6
このコードはRustのwasmチュートリアルに出てくるコードで、確かに最初見ればゲッとなりそう。こういう場合はlogクレートとwasm-loggerなど外部クレートを使う事が多いと思う。
現在Rustのwasmターゲット(wasm32-unknown-uknown)はブラウザ向けであるとは定まっていないためstdのprintからブラウザに出力といったようなことはできない。そういうターゲットを追加すべきかどうかについては意見が分かれるところかもしれない。
ただ通常のRustでは
println!
やdbg!
があるのにwasmの事例をもって「デバッグ=苦行」というのは言いすぎではないかとは思う。少なくともロギングに関してはlog
やtracing
など優れたクレートが存在している。7
まず、RustはTypeScriptやPythonやGoに比べてメモリ安全性が特に向上するわけではない。ただそれに付随する機能によりプログラムが堅牢になる可能性は高い。
また、「おそらく半分の時間で2倍の機能を実装できていただろう」については結局のところ個人の感想でしか語れないがRustで記述することによって最初は時間がかかるものの設計が一度できあがるとリファクタリングやバグの発見が容易になり生産性が向上すると感じている。
また、「おそらく半分の時間で2倍の機能を実装できていただろう」については結局のところ個人の感想でしか語れないがRustで記述することによって最初は時間がかかるものの設計が一度できあがるとリファクタリングやバグの発見が容易になり生産性が向上すると感じている。
感想
wasm関連やビルドが遅いことについては自分も共感できる部分が多かったが、他の部分についてはこの記事の筆者が期待しているものとRustが提供するものにズレがあるからこうなってしまったのではないかと感じた。
Rustが存在する背景、メモリ管理について理解するとこの記事で出るようなエラーについてもある程度納得してもらえるのではないかと思う。
Rustが存在する背景、メモリ管理について理解するとこの記事で出るようなエラーについてもある程度納得してもらえるのではないかと思う。
「メモリ管理を安全かつ効率的に行う」「コンパイル時にできるだけ多くのエラーを検知し、正しいコードを書かせる」がRustにとっての最重要課題だが、Rustではそれらを達成するためにいくつかの枷がはめられており、特に一つ目の目標を達成するためのものが所有権やライフタイムである。
ただし高レイヤでは必ずしもRustが提供するGCなしのメモリ安全性が必要なわけではない。
自分はメモリ安全性以外にもRustの高パフォーマンスさ、豊富な型システムによる間違いの犯しにくさ、エコシステムの豊富さを魅力だと感じて通常のアプリケーションなど比較的高いレイヤにおいてもRustを使っている。
そう考えているのは自分だけというわけではなく、だからこそ最近ではRustはWebサーバや果てはWebフロントエンドのような高レイヤにも進出している。
自分はメモリ安全性以外にもRustの高パフォーマンスさ、豊富な型システムによる間違いの犯しにくさ、エコシステムの豊富さを魅力だと感じて通常のアプリケーションなど比較的高いレイヤにおいてもRustを使っている。
そう考えているのは自分だけというわけではなく、だからこそ最近ではRustはWebサーバや果てはWebフロントエンドのような高レイヤにも進出している。
高レイヤでも使えるとは言え、RustはCやC++などのシステムプログラミング言語と同種のものであり、JSやPythonとは違う問題を解決しようとして生まれたということを知らずに「なんか性能の高い言語」とだけ思って使うと、Rustにより課される制限がただただ鬱陶しいものと感じてしまうだろう。