Rust part28

**デフォルトの名無しさん** · 2025/03/24(月) 17:37:00.15

公式
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 part27
https://mevius.5ch.net/test/read.cgi/tech/1733146370/

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

**デフォルトの名無しさん** · 2025/04/28(月) 09:22:16.38

>>739
30年前と違って今はweb系から先にプログラミング入門しちゃう人がいるんだな

**デフォルトの名無しさん** · 2025/04/28(月) 09:27:48.27

>>780
ずっと境界知能だが

**デフォルトの名無しさん** · 2025/04/28(月) 09:38:56.02

>>782
Rustを学ぶのにC++の知識は全く不要
Rustはムーブも所有権もあっさり単純化されてる
むしろ複雑化しているC++の知識があるとかえって混乱する人もいれば
すぐにRustでは非常にシンプルになってると気付く人もいる

スタック領域とヒープ領域の違いといった現在のコンピューターの基本常識を身に着けていればRustの学習は大丈夫
ただし何のためにそんなことしているのか必要性の納得がいかない人は自分でCでmalloc()とfree()を使ってプログラムを書いてみる体験するしかないね

**デフォルトの名無しさん** · 2025/04/28(月) 09:41:49.31

>>781
英語圏のエンジニアはどっかの島猿と違って図表より文章を好む傾向があるから、メインストリームがそっちに行くことはないよ
ひたすら構造化されたプロンプトを書く形になると思う

**デフォルトの名無しさん** · 2025/04/28(月) 10:06:05.66

英語圏のパッケージソフトやOSS等のドキュメントを読んでると日本がITで勝てない理由がよくわかるよね
論理的な言語能力が段違い
奴らRedditの便所の落書きですら関心するくらい論理的かつ丁寧だからな

**デフォルトの名無しさん** · 2025/04/28(月) 10:34:28.00

時間の使い方がおかしいんじゃないの
プロが1分で思いついたムーブが、アマチュアが何時間か探索した手に勝てる保証は全くない

**デフォルトの名無しさん** · 2025/04/28(月) 13:19:02.28

>>783
今はそんな子ばかりだよ。Javaも触ってないから型付き言語に憧れる。GoぐらいにしとけばいいのにRustやって恨み言を言ってるようだが、それはそう

**デフォルトの名無しさん** · 2025/04/28(月) 21:56:45.28

スレ読んでたら、今更Trait制約などと宣う馬鹿が居て驚いた

**デフォルトの名無しさん** · 2025/04/28(月) 22:03:15.48

制約でも境界でもどちらでもいいからとっととthe rust book 最新版を翻訳して用語を統一しとけ。

最初に翻訳した方を使うことにするわ。

**デフォルトの名無しさん** · 2025/04/28(月) 23:45:26.03

>>779
そういう段階を踏んだ学習をすればRustをほとんどの人が理解できるだろうけど下層プログラマーだけは理解できないと思う
下層プログラマーは既に現在のAIでもうすぐ不要となる人たちだから問題はなさそう

**デフォルトの名無しさん** · 2025/04/29(火) 00:00:51.63

プログラミングの学習ってそれだけじゃないからな
ジュニアクラスのエンジニアに仕事を教える上で、メモリ管理などの低レベルの技術を教えるよりも、Webの仕組み (インフラだったり、フロントエンドのフレームワークだったり) を教えた方が戦力として役立つという組織も多いだろう
もちろんRustが必要な分野もあるけど、そうでないならRustに時間をかけるより、もっと製品やサービスの開発に直結するものを学んだ方が効率が良い場面も多い

**デフォルトの名無しさん** · 2025/04/29(火) 00:15:51.93

自分はWeb系詳しくないから分からんけど、他の言語に比べて特筆して使いやすいフレームワーク (ツールが揃ってるとか、学習リソースが多いなどの点も含めて) があるわけでもないでしょ？
言語の構文よりも、フレームワークの使いやすさや導入しやすさの方が技術選定の上では重要なはず

高パフォーマンスが必要な分野でC++よりもすっと開発しやすい言語だというのはそう

**デフォルトの名無しさん** · 2025/04/29(火) 00:48:55.50

合格ラインギリギリを狙うのが最高に効率が良い
多分AIもギリギリ驚いてあげてもいいレベルで止まる

**デフォルトの名無しさん** · 2025/04/29(火) 01:09:26.08

効率最重視なら当然ギリギリ合格するかどうかという水準がベスト
でも効率最重視より突き詰めて設計したいよね
マージンあった方が安心だぜ

**デフォルトの名無しさん** · 2025/04/29(火) 02:08:43.12

>>794
RustのWebフレームワークね。
どの言語でも同じようなもんだし、非同期やると余計に難しいから、Rust選ぶ利点少ないと思うよ

**デフォルトの名無しさん** · 2025/04/29(火) 02:43:09.44

>>794
クラウドでは CPU やメモリに課金される。
クラウド上のサービスは経営者から金の動きの形で観測できるので高パフォーマンスを求める圧力が強くなってる。
ユーザから見た性能としては必要なくてもコストというわかりやすいビジネス的要因が絡んでる。
サービスの規模によるがウェブは高パフォーマンスが必要な分野なんだよ。

**デフォルトの名無しさん** · 2025/04/29(火) 02:47:28.58

アクセス多いサービスはいいなあ
サーバ代10万くらいで済むと経営からの圧力など無い🥺

**デフォルトの名無しさん** · 2025/04/29(火) 02:57:41.06

>>690 >>797
スタートアップを含めてWebバックエンドでRustを採用すべき理由としてよくまとまってるとされてるのがこれ

https://dockyard.com/blog/2025/03/18/why-rust-is-winning-backend-systems-startup-must-know

Web関係はフロントエンドのJS/TS部分を除いてRustが最善解

**デフォルトの名無しさん** · 2025/04/29(火) 07:14:39.79

Rustが辛いという記事も同様に見つかるね
3年間使った上で最終的にRustを手放したという話なんかは、多分あなたよりもずっと真面目にRustに向き合った上でこの結論を出してると思うよ

https://www.propelauth.com/post/i-love-building-a-startup-in-rust-i-wouldnt-pick-it-again
https://loglog.games/blog/leaving-rust-gamedev/
https://deadmoney.gg/news/articles/migrating-away-from-rust

当然だけど「最高の言語」なんてものは無い
それは組織やプロジェクトの特性によるし、開発者が個々に判断すべき話
(Rustがそうでないのと同様に、Goが最高だとかC#が最高だとか、そんなものもあり得ない)

**デフォルトの名無しさん** · 2025/04/29(火) 07:59:59.47

>>801
英語サイト苦手で読めないけどこれワラタ
96 minute read

一ブログ記事は2分ぐらいで読めないと最適化した記事書けるプログラマーとは思ってもらえない世の中で長文な

**デフォルトの名無しさん** · 2025/04/29(火) 08:10:37.04

コンパイルの遅さ、中間生成物のでかさ、データ構造の変更に弱い、並列性周りのキャッチアップ
このあたりはRustの弱点よな

**デフォルトの名無しさん** · 2025/04/29(火) 08:11:53.11

>>801
ちゃんとそれらの記事を読んだか？
それらを読んだが全てRustは素晴らしいという話だったぞ

1つ目の記事はRustの良い点を列挙してくれている
ただし最後に
「in Rust, for our use case, they both require at least a rough understanding of pinning」
RustだとPin留めについての理解が必要になるというだけの話だった

2つ目の記事の結論は
「Once you get good at Rust all of these problems will go away」
Rustを上達してしまえばこれらの問題はすべて解消されます

3つ目の記事はRustの問題ではない
今回のゲーム作りのタイプが(Rust製の)BevyよりUnityが向いていたというだけの話だった
そしてRustとBevyについても
「 I have immense respect for both and may well use them again for different projects.」
別のプロジェクトでは使う可能性があると書いている

**デフォルトの名無しさん** · 2025/04/29(火) 09:07:02.50

やっぱRustは清書用だな、気楽にバグ有りでも良いから作る分には役割が重すぎる

**デフォルトの名無しさん** · 2025/04/29(火) 09:07:31.63

この決めつけで他人に圧を掛けるレスをずっとしてる病人はなんなんだろ？

**デフォルトの名無しさん** · 2025/04/29(火) 09:08:03.86

>>805
何を根拠にそんな頓珍漢な主張を？

**デフォルトの名無しさん** · 2025/04/29(火) 09:09:59.77

rustが使えない人間の方がこの世に多いし今後もそれは変わらない

こんな単純な事実を否定して使えないやつは馬鹿だみたいな圧を掛ける馬鹿

**デフォルトの名無しさん** · 2025/04/29(火) 09:12:09.63

>>807
Pythonみたいなスクリプト言語と比べて気楽さはないでしょ

**デフォルトの名無しさん** · 2025/04/29(火) 09:21:01.67

>>809
Python笑と比べるの？？
不適切なPythonなんかでプログラミングする方が本当に良いと思い込んでるならそうしていれば？
なぜこのRustスレに来てるの？

**デフォルトの名無しさん** · 2025/04/29(火) 09:25:37.97

801の一番目の記事で言われている、
> Perf is easy when you have AWS credits.
これはWeb分野固有の事情として極めてクリティカル
スタートアップ向けの無料クレジット云々はともかく、金さえ出せば解決するのは事実だからな
そして多くの場合、人間の時間の方が高い

**デフォルトの名無しさん** · 2025/04/29(火) 09:27:24.85

>>808
そのRustが使えない人間はよほど下級のプログラマなのだから無視して良い存在だと思いますよ
特にAI活用時代には不要となる人間でしょう

**デフォルトの名無しさん** · 2025/04/29(火) 09:33:07.30

熊を生け捕りにする「圧」がもし本当にあるなら猟銃は必要なくなる

**デフォルトの名無しさん** · 2025/04/29(火) 09:34:23.44

>>811
Pythonで作って例えば10倍くらい高い料金をその後ずっと支払い続けるのかね？
しかも料金が高いだけでなく動作も遅いから不利だよね

**デフォルトの名無しさん** · 2025/04/29(火) 09:37:59.27

>>814
実際に10倍高く、かつそれが機会損失コストと人件費を上回ることが予測できた段階で置き換えればよい
君が実際にプロダクションのWeb開発をやったことがあればわかるはずだが、そんな状況は滅多にお目にかかれない

**デフォルトの名無しさん** · 2025/04/29(火) 09:40:09.63

>>811
記事その部分の前提を見てごらん。
every new employee that isn’t familiar with Rust will run into this. You’ll either need to prioritize Rust experience when hiring or get good at training people.
つまりRustに不慣れな人にとっては、Rustを使わずにAWSに高い料金を払った方が良い場合がある、というだけであって、Rustに慣れてしまえばRustで書いた方が良いね。

**デフォルトの名無しさん** · 2025/04/29(火) 09:43:15.06

やっぱりRustを使える自分，にアイデンティティの拠り所を求めてるやつがいるなぁ
あるいは知識だけあって使えない反動で書いてるのかな

**デフォルトの名無しさん** · 2025/04/29(火) 09:43:33.48

>>815
それはクラウドに高い料金を支払い続けることになり損でしょう。
Web利用側にとっても、反応が速いほうがうれしいでしょう。
Rustに慣れてしまえば解決する問題なのだから、Rustで書くのが正解だと思うよ。

**デフォルトの名無しさん** · 2025/04/29(火) 09:50:15.06

Rustを使える者、の集合がどうしても必要なのは統計学者だよ
個人のアイデンティティではなく集合の定義が必要なのだ

**デフォルトの名無しさん** · 2025/04/29(火) 09:52:34.33

こいつなんでいつもIDコロコロしてんの？

**デフォルトの名無しさん** · 2025/04/29(火) 09:53:09.96

>>818
経験があるなら当然知っているはずだが、残念ながらWebのボトルネックはほとんどの場合IOとDBなのです

**デフォルトの名無しさん** · 2025/04/29(火) 10:00:39.70

「俺はRustが使えないから遅くてもPythonで書いたほうが効率がいいんだ！」と言う主張にも一理ある
しかしそれは個人の事情だろう
Rustスレに書き込んでここを荒らす必要があるのか？

今後はどうしてもRustを叩きたいならば専用のRustアンチスレに書き込みなさい

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/

**デフォルトの名無しさん** · 2025/04/29(火) 10:03:44.71

>>822
自分らみたいにrust使いたい人間は普通に使うけど使わない人を勝手に馬鹿にするのは違うだろ
病人

**デフォルトの名無しさん** · 2025/04/29(火) 10:08:41.96

>>821
だからこそRustが有利というのがこの業界の常識
RustならばそのWebのIOとDB待ちの間に並行かつ並列でいくらでも他を安全に捌くことができる
そのためWebの世界はどんどんRust化が進んでいる
ちなみにRustの側でも最も使われている分野がWebサーバーサイドとアンケート結果が出ている

**デフォルトの名無しさん** · 2025/04/29(火) 10:09:02.51

>>804
Rustへの称賛以外の文章が目に見えない病気なんですかね…
1番目は最後の締めくくりで
But if I look back at it, as much as I love Rust, I absolutely would not choose Rust again.
と言ってるのだけど

開発者が個人としてRustが好きというのと、自分のチームでRustを選ぶべきかというのは別問題
自分もRustは好きだけど、会社だと現状ごく一部のプロジェクトでしか使えないと思ってるし、全てRustという主張は馬鹿だと分かる程度の良識はあるぞ

**デフォルトの名無しさん** · 2025/04/29(火) 10:15:18.14

Rustを使えない人がいるからRustを使えないケースがあるというのは当たり前だけどそのチームの問題だからここで取り上げても意味ないんじゃないかな
このスレはRustを使いたい人や学びたい人だけで十分
例えばC++のスレでC++を使えない人もいるんだ！とか言い出したら完全に荒らし行為だぞ

**デフォルトの名無しさん** · 2025/04/29(火) 10:20:15.08

c++はほぼ誰でも普通に使えるだろ
メモリリークなどが発生するだけで

**デフォルトの名無しさん** · 2025/04/29(火) 10:25:53.49

>>824
結局それは金を積んで水平スケールさせれば解決する問題だからズレてる
コストを正当化するだけの十分なスケールがあるならRustを採用すべきであることは誰も否定していない

**デフォルトの名無しさん** · 2025/04/29(火) 10:27:02.06

>>827
C++使えるならRustも使える
そんなことよりもだな
Rustを使えない人が、Rustを使えないからRustを使うのはよくない！反対！とRustスレに書き込みに来るのはおかしい
荒らし行為だ

**デフォルトの名無しさん** · 2025/04/29(火) 10:29:40.74

>>828
そんなムダな金を使わなくてもRustを使えば解決してしまう
なぜRustのスレでRustを使わないように持って行く主張を延々としているのかい

**デフォルトの名無しさん** · 2025/04/29(火) 10:29:40.82

>>829
c++使えてもrustは使えない
コンパイルも通らないだろう

**デフォルトの名無しさん** · 2025/04/29(火) 10:31:19.04

>>831
Rustを使えなくて使いたくない人はRustスレに来るなよ
ここはRustを使いたい人や学びたい人のためのスレだよ

**デフォルトの名無しさん** · 2025/04/29(火) 10:32:07.53

普通にストローマン論法だね
相手の主張を捻じ曲げてそれに対して批判するやり方

**デフォルトの名無しさん** · 2025/04/29(火) 10:33:11.40

＞　C++使えるならRustも使え
これは間違い

**デフォルトの名無しさん** · 2025/04/29(火) 10:36:53.75

スレを荒らしてる人は自覚ないのかな
ここはRustを使いたい人のためのRustスレ
Rustアンチスレがちゃんと別にあるのだから棲み分けしよう

**デフォルトの名無しさん** · 2025/04/29(火) 10:48:01.46

Rustは好きだけど、Rustを過剰に持ち上げるカルティストは嫌い
こういう輩のせいでRustは信者がうざいとか言われるし、まともな開発者にも迷惑がかかる
良い点も悪い点も含めて、言語の特性や現状を正しく認識しようというのがなぜできないのか

**デフォルトの名無しさん** · 2025/04/29(火) 10:54:37.77

>>836
それは100点満点を狙うやつがやること
0でも100でもないグレーなやつはそんなことをしない

**デフォルトの名無しさん** · 2025/04/29(火) 10:59:16.54

>>836
そんなどうでもいい話は専用スレを立ててやったら？
一般的に言語XのスレでX信者があーだこーだ言い続けて許されるとは思えないので

**デフォルトの名無しさん** · 2025/04/29(火) 11:00:35.07

狂信者がrustの地位や評判を落としてるのでその他の人間には迷惑

**デフォルトの名無しさん** · 2025/04/29(火) 11:03:29.06

言語にアイデンティティを求めてる人の極論はともかく、他は別にRustを叩いているようにも荒らしているようにも見えないな
議論をするときには自己のポジションとアイデンティティを自分の中で区別しておいた方がいい
このスレは優しい方で、特にRustを採用できるような分野でやってきたいならそれができないと辛い思いするよ

**デフォルトの名無しさん** · 2025/04/29(火) 11:07:36.96

>>839
そういう陰謀論的な話は専用スレを立ててやるべきかな
ここでやるのは荒らし行為

**デフォルトの名無しさん** · 2025/04/29(火) 11:13:28.83

陰暴論でなんでもない

＞　C++使えるならRustも使える

これが間違いだと理解できないのは狂信者だろ
C++は型あり言語からやってきたらだいたいの人はコードを書ける
ただ危険なコードも容易に書ける
Rustはそれを阻止するために縛りがある　危険でない部分でもそれが必要になる

その概念を理解しないとコンパイルエラーから抜け出せないので実用的な成果物は作れない

**デフォルトの名無しさん** · 2025/04/29(火) 11:21:05.72

>>842
Rust初心者がコンパイル通らなくて困ってるのかな
どの言語でもその言語の決まりを守らないとコンパイルエラーだよ
C++に関して言えば弱い型付け言語で未定義動作もエラーにしないからコンパイルエラーは少なくなるけど
今は強い型付けで未定義動作を許さない言語のほうが主流になってるよ

**デフォルトの名無しさん** · 2025/04/29(火) 11:35:49.34

>危険でない部分でもそれが必要になる

ギリギリ危険でないコードを不合格にするんだな
極めてなにか効率にたいする侮辱を感じます

**デフォルトの名無しさん** · 2025/04/29(火) 11:50:27.89

可変参照の排他性なんかは場合によっては効率性を犠牲にしても安全側に倒してる例だね。

**デフォルトの名無しさん** · 2025/04/29(火) 11:58:15.87

>>845
あれは参照の競合スパゲッティプログラムを避けることに繋がって良い判断かな
他にもC++のvectorの要素へ参照を持ったままpushしてヒープ移動になる典型的バグも防止できているね

**デフォルトの名無しさん** · 2025/04/29(火) 12:02:19.93

C++ を使えている人なら Rust のチュートリアルを読めば簡単な実務を始められるくらいにはなれそうな感覚があるんだけどなぁ。
難易度の高さをしきりに主張する人がずっといるのがなんだかよくわからない。
いや、難しいと感じる人だっているというのを否定するつもりはないんだけどさ……

C++ はかなり面倒な部類だぞ。
その面倒な C++ を使いこなせるくらいの能力という前提を付けられるときに Rust がそこまで激烈にしんどいか？

**デフォルトの名無しさん** · 2025/04/29(火) 12:13:51.06

C++からの移行についてはそれほど議論の余地はなくて、周辺環境が許せば移行すればよい、で終わり
C++の開発というのは比較的ニッチかつ保守的なので、C++を使っていて、かつ周辺環境が移行を許す状況というのがそもそも稀

**デフォルトの名無しさん** · 2025/04/29(火) 12:50:13.98

C++が分かるならRustは学びやすい、というのはその通り
だけどそもそもC/C++をやらずに仕事できてる人も今はずっと多いわけで

> C++ はかなり面倒な部類だぞ。
> その面倒な C++ を使いこなせるくらいの能力という前提を付けられるときに
の「前提」というのが既に世間一般の感覚とズレてるのでないかと思う

**デフォルトの名無しさん** · 2025/04/29(火) 13:27:22.82

C++は学んだことないけど
スタック領域とヒープ領域の違いは理解できていたからRustを学ぶうえで特に困ったことはなかったよ
ライフタイムも関数を抜けたら消えちゃうスタック領域とその変数に管理されて依存するヒープ領域
関数の呼び出し入れ子で祖先側のスタック領域は子孫側のスタック領域より長生きというだけの話だった

**デフォルトの名無しさん** · 2025/04/29(火) 13:56:05.54

>>849
このトピックは >>842 などに対する反論なのであくまでも C++ は使えることを前提にしたときという限定的なもので、平均的なプログラマにとっての Rust の難易度については全く述べてない。
C++ を充分に使いこなせている人が多くないことは認識しているよ。

C++ を使うときは C++ が必要なときなので C++ みたいなことをもっと楽に出来るなら喜ばしいだろう。
C++ や Rust みたいなものが必要ないなら使えとは言わんよ。だって必要ないんだから。

**デフォルトの名無しさん** · 2025/04/29(火) 14:28:41.68

Rustは脳死で使えるイディオムが豊富なので楽
C++は時代によって流儀が変わりすぎる

**デフォルトの名無しさん** · 2025/04/29(火) 14:32:21.54

昔からム板は平均より遥かに上のひとしかおらんがな
平均的なプログラマーは3年目ぐらいからは勉強すらしてないし

**デフォルトの名無しさん** · 2025/04/29(火) 16:32:22.17

>>852
C++ は設計理念のひとつとしてプログラマに選択の余地を与える (間違いの可能性があっても) というものを含んでいるので意図通りの結果ではある。
分野ごとの流儀や時代の要請が言語の流儀と噛み合わなくなると単にその言語が使われなくなるだけなので長く生き残るには (汚くても) 色々とできるように詰め込むしか仕方がないんだ。

**デフォルトの名無しさん** · 2025/04/29(火) 16:32:23.99

ム板が平均よりはるかに上？

**デフォルトの名無しさん** · 2025/04/29(火) 16:48:30.04

大半の人は情報収集しないしコミュニティに属さないのは本当だ。
そういう意味では多少なりとも交流を持とうとしているのは平均以上の可能性が高い。
その一方で、ガチの上級者はガチの業務をしてるしガチなコミュニティに属しているからこんなとこにいない。

**デフォルトの名無しさん** · 2025/04/29(火) 17:51:47.71

>>854
Rustはどうしても必要不可欠ならばその汚いもの(unsafe)を関数やモジュールやクレートの中に閉じ込めて清らかな(safe)インターフェイスを公開する枠組みを持たせたね
そのように閉じ込めることでコンパイラによる自動保証の外の範囲も限定して管理できるようになり安全性と柔軟性や高速性の両立バランスをRustは手に入れた

**デフォルトの名無しさん** · 2025/04/29(火) 18:17:31.81

交流しているのは評論家だけ
クリエイターの能力値はDS並に謎に包まれている

**デフォルトの名無しさん** · 2025/04/29(火) 18:25:25.23

いちいち訳語につっかかったり普及してるかどうかのレスバしかしてない奴らの集団が平均以上なわけないじゃん

**デフォルトの名無しさん** · 2025/04/29(火) 18:37:35.61

Rustでイディオムっぽく感じるのって個人的にはビルダーくらいな気がする
オプション引数やオーバーロードが無いから慣習的にビルダーを多様する、みたいなもので
他は割と言語デザインに沿って素直に書けるという感じ

**デフォルトの名無しさん** · 2025/04/29(火) 18:45:02.43

どっかでビルダーパターンは良くないぞ、考え直せって記事を読んだ気がするが
内容を忘れてしまった
誰か教えて

**デフォルトの名無しさん** · 2025/04/29(火) 19:13:59.81

ウェブショッピンクサービス ViaWeb (後に Yahoo に買われた) の創設者であるポール・グレアムはイディオム (デザインパターン) が必要とされる言語は悪い言語だと述べてる。
頻繁に使われるパターンがあるならそのパターンは言語機能やライブラリになっているべきで、ユーザがパターンに沿って書くのはあほくさいという話。

**デフォルトの名無しさん** · 2025/04/29(火) 19:30:07.84

>>857
汚い部分を隠して残る綺麗な部分は Rust の流儀だ。
Rust では Rust 的ではない抽象化ができないようになっている。

C++ 的な混沌よりは Rust の流儀を強制されたほうが今のところはマシなんだが、そうはいっても未来がどうなるかはわからんからなぁ……という現実が理想的ではないという話。

**デフォルトの名無しさん** · 2025/04/29(火) 19:30:23.61

リスパーの言うことなんか聞くな

**デフォルトの名無しさん** · 2025/04/29(火) 19:40:07.38

BufWriterとかでnewにinnerを丸呑みさせて用が済んだらinto_innerで摘出するパターンもRust特有だと思う
他の言語だとinnerは参照で渡しそうだけどRustでそれやると可変参照のライフタイムでカオスになる
このパターンに慣れるまで何回かカオスを経験した

**デフォルトの名無しさん** · 2025/04/29(火) 19:41:32.29

Common Lisp は有用な選択肢だと思うけどなあ。
ガッとラフに作れるというのと機械語レベルでのチューニングもできるという良いとこ取りだ。
ただ、ユーザが少ないと使えるライブラリも少なくて、だからユーザが伸びないというスパイラルがある。
物量が正義というのが現実なんだよね……。

**デフォルトの名無しさん** · 2025/04/29(火) 19:45:09.79

builder嫌い
たかが構造体にパラメータ詰めるだけのことにいちいちオリジナリティを出すな

**デフォルトの名無しさん** · 2025/04/29(火) 19:52:58.08

>>848
RustとC++の相性は最悪

**デフォルトの名無しさん** · 2025/04/29(火) 20:05:56.08

>>865
それ分かる
なんか名前無いのかな？

**デフォルトの名無しさん** · 2025/04/29(火) 21:09:44.91

>>861
これかな？
ビルダーの代わりにinit struct pattern というのを提案してる
https://xaeroxe.github.io/init-struct-pattern/

ボイラープレートが少なくて簡単だけど、初期化用の構造体のフィールドがpublicなのは好みが分かれる
現状はビルダーの方が主流
外部に公開するライブラリのAPIとして使うのは微妙だけど、自分たちのコードの内部で使う分にはアリかもしれない

**デフォルトの名無しさん** · 2025/04/29(火) 21:30:51.12

>>870
それだ！
追記された結論は、マクロでビルダーを生成させましょう、なのか……

**デフォルトの名無しさん** · 2025/04/29(火) 22:02:39.41

車オブジェクトに高度を変えるメソッドがあったらおかしい
空飛ぶ車オブジェクトは一時的にメソッドの存在自体を消すシステムをもつべき

**デフォルトの名無しさん** · 2025/04/30(水) 01:02:26.08

こっち見といたほうがいいと思う
https://kerkour.com/rust-abolish-the-builder-pattern

YakShaverInitをinitしてYakShaver返すとかいろんな意味で微妙
YakShaverBuilderをbuildしてYakShaver返す癖が抜けてない

**デフォルトの名無しさん** · 2025/04/30(水) 01:03:45.45

どっちかが絶対いいというものではなくて使い分けるもの

**デフォルトの名無しさん** · 2025/04/30(水) 01:38:53.14

>>873
the best code is no code at all か、なるほどね

構造体更新記法を使ってもらわないと、メンバー追加したときにコンパイル通らなくなるけど
それを問題視する人としない人がいるって感じ？

個人的には、今のRustはその程度の軽い互換性破壊は日常茶飯事だから別にいいのでは？って気がするけど

**デフォルトの名無しさん** · 2025/04/30(水) 06:24:04.68

内部用は自由だが
少なくとも公開ライブラリの構造体の初期化の結論は出ている

まず各フィールド個別のpub化は以下の点で良くない
・構造体の値個別や全体の制約による無矛盾性を保証できない
・内部実装の改善による構造の変化に対応できない
・今後の機能拡張によるフィールド増加に弱い

したがってどうしてもビルダーパターンを使いたくないのならば
Foo初期化指定用の構造体FooConfigを更に用意してそれはpubを許して
Foo::init(FooConfig { FooConfig:: default(), i: 123, s: "abc" })?
またはこうする
FooConfig { FooConfig:: default(), i: 123, s: "abc" }.init()?
そしてinit()内で指定値チェックと本当の内部構造への変換をする形になる

同じことはビルダーパターンだとderive_builderを用いると提供側は簡単
使う側はおなじみの以下の形になる
FooBuilder::default().i(123).s("abc").build()?
どちらの方式も指定の構文が異なるだけで同じような形になってることがわかる

個人的にはビルダーパターンの方がよりシンプルだと思う
そしてRustでの主流となっている

**デフォルトの名無しさん** · 2025/04/30(水) 10:08:02.30

強制すれば良いのに

**デフォルトの名無しさん** · 2025/04/30(水) 11:07:06.59

ビルダー自体が便利だとは思えないんだよな
オプション引数やオーバーロードが無いのを解決するためのもので、他の言語から来ると戸惑うと思う
(型で遷移を表現するなど、パターン自体は Rust らしいし、理解自体は容易だけど)

オーバーロードは別の面倒を生むから無くて良いと思うけど、オプション引数は個人的にはあると嬉しい気がする

実はGoもオプション引数が無い言語で、代わりに functional option パターンというのを使うんだけど、これもイディオムを知らない人にとって直観的でないと言われがち
同時期に登場した言語がどちらも採用しなかったんだから、多分それなりの理由があるんだろうな

**デフォルトの名無しさん** · 2025/04/30(水) 11:52:30.40

簡単に言えば、virtualを使ってないデザインパターンは追放されない

**デフォルトの名無しさん** · 2025/04/30(水) 12:05:47.96

ム板全体が限界過疎集落化してるのに
Rustスレだけ人が居るのはなぜ？
他に交流の場が無いのかな？

**デフォルトの名無しさん** · 2025/04/30(水) 12:11:54.22

自作自演

**デフォルトの名無しさん** · 2025/04/30(水) 12:21:33.61

規模が大きくなるにつれてbestよりconsistentの重要性が高まるものだ
将来的な変更容易性がどうのと言って必要以上に凝ろうとする奴に限って、
革新的で最高にクールなニュースタイルのビルダーが出てきたらすぐにちゃぶ台返しをする
まあ初期化時のパラメータの与え方なんて壊滅的変更されたところで大した問題じゃないから、
そういう奴に自由にオナニーさせて発散させておくにはいいのかもね