Rust part22

**デフォルトの名無しさん** · 2024/01/20(土) 23:21:40.08

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part21
https://mevius.5ch.net/test/read.cgi/tech/1692105879/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/02/07(水) 00:59:45.05

KotlinやF#は使ったこと無いのでわからない

**デフォルトの名無しさん** · 2024/02/07(水) 01:07:53.33

>>375
Python忘れてたわ
Swift > C# > JavaScript/Python >>> Rust

**デフォルトの名無しさん** · 2024/02/07(水) 01:10:26.42

>>375
Rustが最もきめ細かく扱えて便利

**デフォルトの名無しさん** · 2024/02/07(水) 01:13:21.82

もちろん性能面でもRustが最も有利
だからインフラに至るまで採用されている

**デフォルトの名無しさん** · 2024/02/07(水) 01:20:07.41

>>377
c++は？

**デフォルトの名無しさん** · 2024/02/07(水) 02:44:08.20

>>377
swiftってそんなに書きやすいんか？

**デフォルトの名無しさん** · 2024/02/07(水) 04:57:14.90

>>375
asyncもRxもC#が発祥だけどこの言語だけ異常だよな

**デフォルトの名無しさん** · 2024/02/07(水) 06:30:56.86

Pythonはスレッドが擬似的なので並行処理の性能が低い。

**デフォルトの名無しさん** · 2024/02/07(水) 06:35:55.67

>>375
Kotlinが抜けてる
Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust

**デフォルトの名無しさん** · 2024/02/07(水) 06:52:43.34

Rustを叩きたいだけのアンチさんだから無茶苦茶や

**デフォルトの名無しさん** · 2024/02/07(水) 07:15:51.00

>>380
C++は論外
アンチではなく本当に書きにくい
さらにtokioのような高性能な基盤も整備されていない

**デフォルトの名無しさん** · 2024/02/07(水) 07:16:35.05

非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる
JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない

**デフォルトの名無しさん** · 2024/02/07(水) 07:25:44.75

swiftやdartはモバイルアプリ開発以外で全く使われてない

**デフォルトの名無しさん** · 2024/02/07(水) 07:30:51.78

SwiftはApple製ってだけで使う価値なし
開発環境の依存があまりに高すぎる

**デフォルトの名無しさん** · 2024/02/07(水) 07:38:16.28

出来ればJVMも使わずに済みたい
なんとなく

**デフォルトの名無しさん** · 2024/02/07(水) 07:40:43.27

>>375,377,384
なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？
そらRustを使うことなんてないわな
なんでこのスレにいるのか

**デフォルトの名無しさん** · 2024/02/07(水) 07:53:07.34

Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い

**デフォルトの名無しさん** · 2024/02/07(水) 08:12:27.93

まぁRustの非同期の良いところはランタイムを言語から切り離したので
Webでも組み込みベアメタルでも非同期が使えるところなんだけど
使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない
これは時間がたっても根本的には改善されないから
不満があるなら早く他言語に移ったほうがいいよ

**デフォルトの名無しさん** · 2024/02/07(水) 08:15:11.44

>>390
ならGoかC#のASP.NETでいんじゃね？
さまざまな導入コストを払えるなら事実上クラウドネイティブ言語のRust一択

それとJVMがダメという理由が、Oracle JVMのLTSサポート期間が短縮されJVMのイメージが悪化したってことに依るものなら、
Kotlin/JVMだとJDK8をベースに、どのJDKバージョンでも動くようにサポートされ続けられるから、JDK8から最新のJDK21までのLTSバージョンで難なく動く
https://kotlinlang.org/docs/faq.html#which-versions-of-jvm-does-kotlin-target
OracleのJavaは終わってるがJetBrainsのKotlinは無限に始まってる

**デフォルトの名無しさん** · 2024/02/07(水) 09:03:48.96

静的言語ではkotlinが個人的には1番かな
コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる
これが理想
ただしクラスありきなのが微妙なところ
クラスなしでkotlinのような使い心地がある言語が欲しい

**デフォルトの名無しさん** · 2024/02/07(水) 09:09:08.81

>>373
その時間有効に使えるのかって話なんだよ。
例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、
そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。

DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。

**デフォルトの名無しさん** · 2024/02/07(水) 09:21:27.90

既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう
ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね

**デフォルトの名無しさん** · 2024/02/07(水) 09:33:38.70

>>395
それはRustも同じ
Rustのasyncもコルーチンでありtrait Futureによって抽象化されている
Future::pollの引数であるContextがKotlinでのコルーチンコンテキストに相当する

>>397
Rustでも既存の処理に唐突に非同期を取り扱える
Rustでtokioのようなランタイムが必要になるのはspawnして完全に制御外へ切り離すときのみ
制御内ならば複数のFutureを取り扱う場合でもjoinなど様々な方法で取り扱うことができる
もちろんtokioランタイムは必要ない

**デフォルトの名無しさん** · 2024/02/07(水) 09:42:26.35

async{}.await

**デフォルトの名無しさん** · 2024/02/07(水) 09:45:13.70

>>380
C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。
幅広いシステムで実現可能なように配慮するから。
必要ならサードパーティライブラリでやれというスタンス。
ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。

個人的には C++/WinRT の非同期処理は好きなんだがね。

**デフォルトの名無しさん** · 2024/02/07(水) 10:36:03.38

>>395
KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて
・クラス継承禁止
・やってることはCの構造体と同じ
だから、自分はclassであるデメリットを感じてないかな

Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ

**デフォルトの名無しさん** · 2024/02/07(水) 10:46:44.24

>>396
>その時間有効に使えるのかって話なんだよ。
非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる

もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない

**デフォルトの名無しさん** · 2024/02/07(水) 10:52:51.94

なんかプログラミング言語総合スレみたいになってんな
いやちゃんと説明してくれて勉強になるから別にいいんだけど

**デフォルトの名無しさん** · 2024/02/07(水) 11:05:20.92

>>402
Rustはプログラム言語の王だから理由がなくてもRustを使って良い

**デフォルトの名無しさん** · 2024/02/07(水) 11:12:27.12

>>398
え、tokioランタイム無しで非同期関数呼べるんだ？　知らんかった
でもクレートの依存は付いてきてビルド遅くなるよね

**デフォルトの名無しさん** · 2024/02/07(水) 11:34:03.35

>>405
tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい
例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ

**デフォルトの名無しさん** · 2024/02/07(水) 11:48:56.31

自分でFuture::poll呼ぶとか罰ゲームすぎるやろ

**デフォルトの名無しさん** · 2024/02/07(水) 12:13:10.25

>>361
ゲームサーバーはユーザーの操作ログを逐一集めてるよ。

**デフォルトの名無しさん** · 2024/02/07(水) 12:15:26.39

>>370
いや、無知は恥だよ。ただ罪では無い。
無知のままでいようとすることは罪だけど。
あ、実際の法律云々じゃなくて技術者としてね。

**デフォルトの名無しさん** · 2024/02/07(水) 12:39:51.49

>>407
自分で呼んでもいいし自分で呼ばなくてもいい
それは何をやりたいかどこまでやりたいかなどに依存

>>405
軽いものなら例えばこれだけ
fn main() {
　let val = futures_lite::future::block_on(async {
　　...
　});
}

**デフォルトの名無しさん** · 2024/02/07(水) 13:49:24.53

pollを自分で呼ぶコードは悪手とかなんとか主張する人間と
そのコードに警告もしないコンパイラを
比較できるのがRustの楽しいところで
リソースを節約する話などは人間と人間の論争でありRustに責任はない

**デフォルトの名無しさん** · 2024/02/07(水) 19:07:50.52

C++に安全の責任はない
Pythonに動作速度の責任はない
Brainfuckにリソース節約の責任はない

Rustにリソース節約の責任はない

**デフォルトの名無しさん** · 2024/02/07(水) 19:08:11.49

うーん

**デフォルトの名無しさん** · 2024/02/07(水) 19:08:14.90

>>366
ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。

**デフォルトの名無しさん** · 2024/02/07(水) 19:15:08.54

>>412
リソース節約の責任って何？
リソース節約の責任があるプログラミング言語が存在するの？

**デフォルトの名無しさん** · 2024/02/07(水) 19:30:42.71

>>412
何の面白味もないな

**デフォルトの名無しさん** · 2024/02/07(水) 19:49:16.82

>>415
リソース節約の責任の定義は>>411に聞くべきでは？

**デフォルトの名無しさん** · 2024/02/07(水) 20:05:00.19

そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。

**デフォルトの名無しさん** · 2024/02/07(水) 23:23:34.90

言語の形式的なルールと実利を同一視するのは
ルールを守れば必ず報われるべきってことじゃないか
でもルールを守ることと勝つことは難易度が全然違う

**デフォルトの名無しさん** · 2024/02/07(水) 23:47:29.64

Rustの駄目なところ
コンパイルが遅い
コンパイル時間を含めたらPythonのが圧倒的に速い

**デフォルトの名無しさん** · 2024/02/08(木) 00:07:22.21

>>420
すごいでちゅねー

**デフォルトの名無しさん** · 2024/02/08(木) 01:41:05.03

Googleがプログラミング言語「Rust」に100万米ドルを助成、「C++」との併存・置き換えを図る
https://forest.watch.impress.co.jp/docs/news/1566662.html

**デフォルトの名無しさん** · 2024/02/08(木) 04:23:52.18

>>420
みっともないからルビガイジみたいなレス乞食やめろよ

**デフォルトの名無しさん** · 2024/02/08(木) 04:49:47.24

ルビガイジって何？

**デフォルトの名無しさん** · 2024/02/08(木) 07:47:36.74

何にでもruby推してくる変な人の事じゃね？

**デフォルトの名無しさん** · 2024/02/08(木) 10:03:29.26

>>414
フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし

**デフォルトの名無しさん** · 2024/02/08(木) 10:24:35.32

>>426
直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。
少人数で運用しているシステムだとクライアントとサーバーがある程度に
共通のスキルセットで構築できたほうがいいってこともある。
それがデメリットを上回るほどのメリットかどうかは状況によるけど。

**デフォルトの名無しさん** · 2024/02/08(木) 12:09:04.39

gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ

**デフォルトの名無しさん** · 2024/02/08(木) 12:31:37.22

シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ

**デフォルトの名無しさん** · 2024/02/08(木) 12:39:36.57

スキルセットが一番発揮されるのはコード実装前の設計段階だよ
アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？
実装段階に入ったらあとは作業
フロント担当サーバー担当それぞれが実装する
フロントとサーバーはお互いに入出力のAPIだけ知ってればいい
言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ

**デフォルトの名無しさん** · 2024/02/08(木) 12:43:32.12

>>429
そんなんprotobufかjsonのどっちかだろ
当たり前すぎてデータをどう送受信するかの話をしてたわすまん

**デフォルトの名無しさん** · 2024/02/08(木) 12:47:52.48

あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？

**デフォルトの名無しさん** · 2024/02/08(木) 12:58:22.52

それら全て些細な問題でどうでもいい
通信でもファイルでも何でも
APIやフォーマットさえ決められていればよい
どの言語かどのフレームワークやライブラリかなんて一切関係なく自由

**デフォルトの名無しさん** · 2024/02/08(木) 13:08:16.93

>>426
一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。

**デフォルトの名無しさん** · 2024/02/08(木) 13:14:50.58

自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ
>>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない

**デフォルトの名無しさん** · 2024/02/08(木) 13:16:12.56

もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある
もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する
具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合
従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある

**デフォルトの名無しさん** · 2024/02/08(木) 13:27:14.44

人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある
このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない

**デフォルトの名無しさん** · 2024/02/08(木) 13:39:56.20

unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね

**デフォルトの名無しさん** · 2024/02/08(木) 13:40:27.02

バイリンガルでないプログラマ、Javaしか書けなそう

**デフォルトの名無しさん** · 2024/02/08(木) 14:05:04.22

Java界隈では未だにXMLが現役なのかな
一時期は全てがXMLだったけど最近触れる機会がない

**デフォルトの名無しさん** · 2024/02/08(木) 14:06:53.53

jsonの後にxml使うとデータの無駄が気になる

**427** · 2024/02/08(木) 14:06:56.11

>>430
「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。

**デフォルトの名無しさん** · 2024/02/08(木) 14:22:34.49

ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。
XML の万能さは他には代えられない便利さはある。
ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。

XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、
そういうのを活用すればそれほど過剰に冗長なわけではない。

**デフォルトの名無しさん** · 2024/02/08(木) 14:33:58.18

>>436
例えがフロントエンドって急にレベル下がってワロタ

**デフォルトの名無しさん** · 2024/02/08(木) 14:44:36.25

>>431
ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない
↓ここでいうRaw Struct的なものが今でも使われてる
https://flatbuffers.dev/md__benchmarks.html

言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しまない

**デフォルトの名無しさん** · 2024/02/08(木) 14:50:39.80

>>444
ならばプロコトル以外で
サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ

**デフォルトの名無しさん** · 2024/02/08(木) 14:52:06.22

>>440
早くxmlは滅んで欲しい。

**デフォルトの名無しさん** · 2024/02/08(木) 14:52:54.34

シリアライズやパースのコストは小さくはないけど、
メモリコピーのコストが多くを占めているという発見から
なるべくコピーを減らしたシリアライズの規格として message pack が
実行性能と可搬性を (ある程度に) 両立したものとして人気がある。

まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。
ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。

**デフォルトの名無しさん** · 2024/02/08(木) 14:58:14.76

>>445
まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう

てかデータ記述言語の話なんざクソほどどうでもいいんだが

**デフォルトの名無しさん** · 2024/02/08(木) 15:04:17.46

xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ

**デフォルトの名無しさん** · 2024/02/08(木) 15:04:23.12

>>446
一昔前の分散オブジェクトシステムは大抵それだぞ
COBRAとか
そういう設計古くさいから基本的にやらない

**デフォルトの名無しさん** · 2024/02/08(木) 15:14:54.75

>>438
ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった
小規模サーバー用途ならそれで十分そう

**デフォルトの名無しさん** · 2024/02/08(木) 15:16:59.91

クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。
発端は >>426 あたりかな。

**デフォルトの名無しさん** · 2024/02/08(木) 15:26:56.26

>>451
分散オブジェクトの話とは状況が全く異なる
ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術
これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう
両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化

**デフォルトの名無しさん** · 2024/02/08(木) 15:32:31.05

>>454
別にお前のお気持ちは聞いてないよ

**デフォルトの名無しさん** · 2024/02/08(木) 15:34:25.91

>>455
気持ち？
理解していないようなので現在のウェブ界での動向を伝えただけだが

**デフォルトの名無しさん** · 2024/02/08(木) 15:39:43.48

>>454
それwasmってやつ？ファイルサイズがjavascriptより大きくならない？

**デフォルトの名無しさん** · 2024/02/08(木) 15:46:12.86

フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？

**デフォルトの名無しさん** · 2024/02/08(木) 15:52:25.19

javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ

**デフォルトの名無しさん** · 2024/02/08(木) 15:57:01.04

nodejsで済むサーバーって自宅サーバーか何かか?

**デフォルトの名無しさん** · 2024/02/08(木) 16:06:02.61

>>457
一般的には何をするかに拠る
レンダリングコード共通化の話ならばその部分については誤差範囲

>>458
あまりにも基礎知識が無さすぎるようなので
SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい

**デフォルトの名無しさん** · 2024/02/08(木) 16:07:53.03

>>456
いやそれが余計なんだって
next.js app router+rust使ってる俺に対してする説明ではない

**デフォルトの名無しさん** · 2024/02/08(木) 16:08:25.23

>>459
>>460
そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない
しかしそれらは遅いからサーバーサイドはRust化すべきだろう
つまりレンダリング共通コードもRustで統一すべき

**デフォルトの名無しさん** · 2024/02/08(木) 16:43:53.73

WASMはあまりにアセンブリ言語すぎる
watで直接WASMを書いてコンパイルするのが一番バイナリのファイルサイズを抑えられるけど大変
watじゃなくて他の言語で書くにしてもstd使うとファイルサイズが爆増する
既存のライブラリをWASM化するならともかく、既存のJavaScriptコードをstd有りで書き直すのは、ファイルサイズがJavaScriptのときと比較して増えて本末転倒だからJavaScriptのままでいい
watやRust with no-stdでWASMを頑張る人は頑張って

**デフォルトの名無しさん** · 2024/02/08(木) 16:54:49.99

>>459 >>460
今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ
Next.jsやNuxt.jsなどの名前を聞いたことないですか？

**デフォルトの名無しさん** · 2024/02/08(木) 17:10:13.67

だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん

**デフォルトの名無しさん** · 2024/02/08(木) 17:15:11.69

>>464
規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。
大規模化するウェブアプリケーションが想定されているから
JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。
そうじゃないときがあるって話なんだよ。

**デフォルトの名無しさん** · 2024/02/08(木) 17:20:27.37

1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか
そりゃ話が噛み合わないわなぁ

**デフォルトの名無しさん** · 2024/02/08(木) 17:26:24.69

話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち

**デフォルトの名無しさん** · 2024/02/08(木) 17:26:27.02

話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち

**デフォルトの名無しさん** · 2024/02/08(木) 17:33:18.45

>>467
その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ

**デフォルトの名無しさん** · 2024/02/08(木) 17:42:32.82

>>464
Wasmではfsなど必要ないのだから
no_stdで全く問題なくプログラミングできます
Rustの基本はほとんどcoreに入っています
allocを使えばVecやStringも使えます
あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます
一度no_stdでプログラミングしてみることをオススメします

**デフォルトの名無しさん** · 2024/02/08(木) 17:44:09.24

>>471
いえいえ
Wasmのファイルサイズはそんな巨大になりません

**デフォルトの名無しさん** · 2024/02/08(木) 17:55:44.80

Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。

いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。

**デフォルトの名無しさん** · 2024/02/08(木) 17:56:24.51

>>472
いやー、watでいいかな