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/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でいいかな

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

Figmaはecmascripten使ってるそうだよ
C++で書いてWebGL用にコンパイル
おそらく世界最大のwasmコードだろう

https://www.figma.com/ja/blog/webassembly-cut-figmas-load-time-by-3x/

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

今のところrustよりはecmascriptenの方が既存コードを活かせる

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

>>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？

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

>>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね

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

>>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね

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

単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。

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

途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん

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

>>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな

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

next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ

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

サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案

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

Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ

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

それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった

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

>>464
forthみたいで面白くない？

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

Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ

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

>>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある

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

もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ

**デフォルトの名無しさん** · 2024/02/09(金) 00:17:38.71

今はRuby on Rails でも、React/Next.js, TypeScript が転職で必須。
少し前は、Vue.js だったけど、Vue 3 は流行らなかった

Rails 7 からは、Hotwire に変わった。
HotwireはHTML Over The Wireの略で、
SPAの開発において、JavaScriptのコーディングを極力必要としない。
脱node.js, webpack

JSONではなく、HTMLベース。
サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信する

これで、Reactに取られたシェアを回復する

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

>>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？

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

Ruby信者はズレてるから仕方ない

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

SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい

**デフォルトの名無しさん** · 2024/02/09(金) 08:55:44.38

SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう

**デフォルトの名無しさん** · 2024/02/09(金) 09:34:26.12

std::any::type_name_of_val()は学習時にも良さそ

**デフォルトの名無しさん** · 2024/02/09(金) 09:59:55.75

昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
　std::any::type_name::<T>()
}

**デフォルトの名無しさん** · 2024/02/09(金) 10:27:55.96

>>493
JS使った方が楽という感覚は理解できんわ

**デフォルトの名無しさん** · 2024/02/09(金) 13:19:22.70

>>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？

**デフォルトの名無しさん** · 2024/02/09(金) 13:59:04.29

リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ

**デフォルトの名無しさん** · 2024/02/09(金) 14:16:42.17

>>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった

**デフォルトの名無しさん** · 2024/02/09(金) 15:05:02.67

どんどんrustの話から離れていってんな

**デフォルトの名無しさん** · 2024/02/09(金) 15:19:56.77

SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ

ReactのサーバーコンポーネントはNext..jsではサーバーサイドでレンダリング(HTML生成される)、つまりSSR
クライアントコンポーネントはクライアントサイドでレンダリングされる、つまりCSR

ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ

**デフォルトの名無しさん** · 2024/02/09(金) 15:26:09.73

Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ

**デフォルトの名無しさん** · 2024/02/09(金) 15:36:06.60

>>505
型システムとの兼ね合い。

**デフォルトの名無しさん** · 2024/02/09(金) 15:38:36.69

>>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス

マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う

**デフォルトの名無しさん** · 2024/02/09(金) 15:52:26.69

next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね

**デフォルトの名無しさん** · 2024/02/09(金) 16:25:40.87

>>504
その発想だとサーバーアクションは説明できないよ

**デフォルトの名無しさん** · 2024/02/09(金) 16:28:31.07

>>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる

**デフォルトの名無しさん** · 2024/02/09(金) 16:37:49.82

>>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい

**デフォルトの名無しさん** · 2024/02/09(金) 17:13:49.98

>>510
同感

**デフォルトの名無しさん** · 2024/02/09(金) 18:59:39.30

C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？

**デフォルトの名無しさん** · 2024/02/09(金) 19:22:48.34

実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。

**デフォルトの名無しさん** · 2024/02/09(金) 19:24:12.28

あ、可変長引数の話とオーバーロードの話を混同してしまっていた。

**デフォルトの名無しさん** · 2024/02/09(金) 19:32:53.51

https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4
こういうの知ってたら
オーバーロードもデフォルト引数もいらね～
どうしてもほしけりゃ別名の関数作るわ
ってならん？

**デフォルトの名無しさん** · 2024/02/09(金) 19:45:04.86

別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので

**デフォルトの名無しさん** · 2024/02/09(金) 20:35:29.36

田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。

**デフォルトの名無しさん** · 2024/02/09(金) 23:53:50.41

オーバーロードは無くてもいいけどキーワード引数は欲しいかな

**デフォルトの名無しさん** · 2024/02/09(金) 23:59:48.02

>>519
あるよ
X { name: "foo", num: 123, ... }

**デフォルトの名無しさん** · 2024/02/10(土) 02:54:22.21

>>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ

**デフォルトの名無しさん** · 2024/02/10(土) 09:13:20.91

>>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある

**デフォルトの名無しさん** · 2024/02/10(土) 09:40:29.45

Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく
https://www.reddit.com/r/rust/comments/fi6nov/why_does_rust_not_support_default_arguments/

**デフォルトの名無しさん** · 2024/02/10(土) 09:50:58.48

構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ

**デフォルトの名無しさん** · 2024/02/10(土) 09:54:14.05

ビルダーパターンは自分で書くならめんどい

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

>>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌