Ruby on Railsの伝説的開発者がRustで挑む、サーバーアプリの限界突破
Topcoat is pushing the boundary of server applications with Rust
TokioのCarl Lerche氏とJulien氏が、フルスタックRustフレームワーク「Topcoat」のv0.9を公開。サーバーサイドレンダリングを軸に、シグナルとshardによるクライアント反応性、live!とemit!によるストリーミングUI更新、WebSocketでのサーバープッシュを実現。ORMのToastyもupdate!マクロやドキュメントフィールド、ポリモーフィック関連を強化し、RustでのWebアプリ開発を生産的にする。
Rustは他のモダン言語ほどエレガントではないと最初に言っておくが、それでも目の穴に酸を注ぐよりはRustで作業したい。
HNでの議論
85- muglug
> RustはAI駆動開発の新時代における最高の汎用言語だ。
面白いね、Pythonの人たちはPythonがAIにとって最高の汎用言語だと言うし、Goの人たちはGoがAIにとって最高の汎用言語だと言う、などなど。
- excsn
以前はLeptosを書いていたが、やめてしまった。もっと快適になることを期待していたが、特に言語サーバーが検証するだけで大量のメモリを消費した。Webアプリは、迅速なフィードバックを求める大規模な分散チームでは、維持するのが面倒になりすぎる。純粋なRustでWebアプリを書くのは常にニッチだろうと思う。安全性やパフォーマンスのためだけに、ReactやVueを書いているフロントエンド開発者が純粋なRustを書きたいと思う人は多くない。
だから私はSnapFire FSR（https://www.snapfirers.com）を作った。多くの例もある。フロントエンド開発者がお気に入りのフレームワーク（またはその組み合わせ）で開発できるようにするためだ。私がよくやるようにフレームワークを持ち込みたくないなら、TeraテンプレートやWeb Componentsを書けばいい。たとえAIがあっても楽しくないような、大きなスイッチングコストを払う必要はない。
Webアプリは、それが生まれたマークアップと言語の近くで作成・維持する方がずっと良いとわかった。もう必要がない限り、Webアプリのために純粋なRustを書くことはないだろう。
私はこれを続けて開発し、すべてのleptosとsvelteのサイトを切り替えるつもりだ。
- lackoftactics
Rails開発者として、Topcoatが向かっている方向性はとても好きだ。ただ、目には少しチクチクするが、酸レベルの刺激ではない。
素晴らしいと思うのはLiveViewと、クライアントサイドのリアクティビティのためのボイラープレートを排除している点だ。
- jazzypants
本当に素晴らしい仕事だが、なぜサーバーコンポーネントに新しい用語（shard）を考え出すのか理解できない。新規ユーザーに新しい用語を定義する必要がないように、明らかなクライアント/サーバーのアノテーションを使えばいいのではないか？
- cogman10
私の主な批判は、ORMが嫌いだということだ。
個人的には、ORMを使うなら、自分が書いているクエリにもっと近く、より明示的であってほしい。ORMは多大な複雑さを加える割に、ほとんど利益がない。SQLxはToastyよりもずっと私の好みに近い。
基盤となるDBはそれぞれ異なる特性を持っているので、複数のDB（ドキュメントにはNoSQLも含む）のための抽象化レイヤーを作ろうとすると、解決が難しい制限や抽象化の漏れに遭遇することになる。例えば、DynamoDBを正しく使うことは、Postgresを正しく使うこととは全く異なる。