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/10(土) 10:08:52.95

ADAってどう？

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

Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって

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

>>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな

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

パターンとかきしょすぎ
Javaみてえな文化

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

>>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから

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

>>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは

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

>>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので

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

キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな

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

キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て

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

パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ

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

>>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない

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

可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ

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

>>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか

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

>>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから

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

>>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい

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

まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か

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

>>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ

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

Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも

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

デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ

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

パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる

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

いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている

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

>>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ

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

Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから

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

>>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ

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

>>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね

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

>>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな

一言で言えばどちらも低DX

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

>>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい

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

>>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど

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

>>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな

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

デザインパターンといえばGoFは流石に古くないか？？

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

デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン

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

デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます

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

話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか

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

出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。

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

>>559
いつからブラウザで見ていると勘違いしていた

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

>>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？

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

Javarが考えた設計は根本的に汚い

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

オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった

元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している

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

>>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood

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

いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話

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

ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…

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

>>566
ごめん勘違いした>>565はスルーしてほしい

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

・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる

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

今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな

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

継承抜きオブシコで十分っす

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

なんでrustスレで他言語の雑談始まってしもたん

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

>>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと

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

継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？

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

従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし

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

Rustの型クラスは最強

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

rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ

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

>>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話

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

>>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？

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

>>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ

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

>>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん

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

只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。

おまいらは政治将校か？

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

実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う

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

Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？

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

>>583
勉強になる👍

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

>>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う

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

>>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項対立まで否定するのは行き過ぎだよ

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

>>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない

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

オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ

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

あと関数型と手続き型の区別がつかない

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

関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない

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

>>590
一緒だよ

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

高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね

あと論理型というのがあったなあ

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

>>589
フロントエンド用途でコンポーネント指向

あと関数型というのは名前の通り関数に型を持たせたってだけ
高階関数と呼ばれてるね

オブジェクト指向に成り代わるものはいまだ出てきていない

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

オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう

オブジェクト指向信者もJavaは嫌いそう

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

それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？

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

むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。

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

オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手

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

狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ

カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある

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

>>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない

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

なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね

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

オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど

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

関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない

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

>>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ

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

フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね

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

手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型

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

オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄

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

グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。

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

オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど

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

勉強になるような知識どんどん書き込んでくれ

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

オブジェクトを指向指向したら汚いコードがいっぱい出た

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

オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない

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

>>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？

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

みんながRustを使えば解決だね

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

一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った

結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった

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

今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ

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

べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。

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

継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう

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

>>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか

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

>>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな

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

>>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ

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

関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。

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

いやマジレスすなw

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

Deref使った継承もどきは委譲と変わらんよ

継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ

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

正しい責任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい
正当化が必要と感じる人には継承が必要なのだろう

**デフォルトの名無しさん** · 2024/02/11(日) 08:17:40.00

委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる