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/11(日) 09:33:37.86

オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。

**デフォルトの名無しさん** · 2024/02/11(日) 09:47:23.19

>>627
レポジトリはドメインレイヤーがやるところでしょ

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

>>627
delegationとforwardingの区別が付いてないね

**デフォルトの名無しさん** · 2024/02/11(日) 12:18:42.79

ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向

**デフォルトの名無しさん** · 2024/02/11(日) 13:10:55.53

オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある

だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる

**デフォルトの名無しさん** · 2024/02/11(日) 13:30:06.52

>>627
それは委譲ではない
継承と委譲とインターフェースは違うもの

**デフォルトの名無しさん** · 2024/02/11(日) 14:12:49.22

自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない

**デフォルトの名無しさん** · 2024/02/11(日) 14:28:55.59

>>634
“賢い”の定義が違うんだろ
察してやれ

**デフォルトの名無しさん** · 2024/02/11(日) 14:35:31.96

定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている

**デフォルトの名無しさん** · 2024/02/11(日) 15:00:23.67

Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ

**デフォルトの名無しさん** · 2024/02/11(日) 15:56:01.57

>>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ

**デフォルトの名無しさん** · 2024/02/11(日) 16:06:16.13

オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね

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

>>639
(^_^)ﾉ

**デフォルトの名無しさん** · 2024/02/11(日) 16:21:31.17

時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる

**デフォルトの名無しさん** · 2024/02/11(日) 16:24:12.02

>>637
型理論においてはどちらも同じ

**デフォルトの名無しさん** · 2024/02/11(日) 16:30:25.25

なんかみんな単発だからレスバできないなあ

**デフォルトの名無しさん** · 2024/02/11(日) 20:46:34.90

RustがJSを滅ぼしてくれるのはいつになるかいのう……

**デフォルトの名無しさん** · 2024/02/11(日) 21:26:37.41

まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる

**デフォルトの名無しさん** · 2024/02/11(日) 21:51:44.10

DOMはJSに依存しないしいろんな言語のインターフェースがあるが。

**デフォルトの名無しさん** · 2024/02/11(日) 22:42:14.41

>>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない

**デフォルトの名無しさん** · 2024/02/11(日) 22:47:25.71

>>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ

**デフォルトの名無しさん** · 2024/02/11(日) 22:56:40.04

>>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない

そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく

**デフォルトの名無しさん** · 2024/02/11(日) 23:09:37.71

自演ええて

**デフォルトの名無しさん** · 2024/02/11(日) 23:36:32.19

>>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要

**デフォルトの名無しさん** · 2024/02/12(月) 00:40:57.30

tree構造以外である程度の汎用性あるデータ構造なんてないわ。

**デフォルトの名無しさん** · 2024/02/12(月) 01:04:43.36

DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話

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

>>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。

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

>>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実

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

DOMの設計と全然関係ない話。

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

>>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人

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

domなしでのナビゲーションの方法があってもいいとは思う

**デフォルトの名無しさん** · 2024/02/12(月) 11:08:30.75

いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる

**デフォルトの名無しさん** · 2024/02/12(月) 11:23:28.89

>>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね

DOMが欠陥品？
で？君はどうしたいんだい？

**デフォルトの名無しさん** · 2024/02/12(月) 11:28:30.41

>>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った

**デフォルトの名無しさん** · 2024/02/12(月) 11:38:53.51

DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと

**デフォルトの名無しさん** · 2024/02/12(月) 11:41:30.45

やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい

**デフォルトの名無しさん** · 2024/02/12(月) 13:30:26.12

DOMの代替の候補って存在するのかな

**デフォルトの名無しさん** · 2024/02/12(月) 13:49:21.10

>>662
Windowsはゴミだから個人も仕事からも排除した
しかしネットがWebベースのこの時代にWebブラウザは排除できない
DOMは取り扱わざるを得ない

とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている
まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった
これはJavaScriptグルーコードの削減をもたらしている
さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる
Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ

**デフォルトの名無しさん** · 2024/02/12(月) 15:41:26.64

デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。
「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。

あと、Rustでダックタイピングできたっけ？事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。

**デフォルトの名無しさん** · 2024/02/12(月) 15:46:26.73

デザインパターンって簡単に実装できるとか
自慢するたぐいのものだっけ？

**デフォルトの名無しさん** · 2024/02/12(月) 15:55:33.33

単発NG推奨

**デフォルトの名無しさん** · 2024/02/12(月) 15:56:29.31

ドメインまわりをフレームワークと分離させる設計ならなんでもいいや
今後リファクタリングすることを考えた設計が大事

**デフォルトの名無しさん** · 2024/02/12(月) 15:56:34.13

ここはRustスレです消えてください

**デフォルトの名無しさん** · 2024/02/12(月) 16:00:10.23

>>666
ダックタイピングは動的型付け言語のためのオモチャであり
デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている
ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる
もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない

**デフォルトの名無しさん** · 2024/02/12(月) 16:11:47.85

ダックタイピングというゴミのような方法に対して
Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した
それがtraitのrequired methodsとtrait boundsである
この二つにより全てを解決している

**デフォルトの名無しさん** · 2024/02/12(月) 16:12:19.21

ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ

**デフォルトの名無しさん** · 2024/02/12(月) 16:23:13.06

>>664
ない。結局まともに使えるものを用意しようと思えばああなる。
それも理解せずに馬鹿みたいに文句言ってるだけだわな。

**デフォルトの名無しさん** · 2024/02/12(月) 18:20:41.31

>>667
繰り返されれば飽きる
繰り返されないのはパターンではない

**デフォルトの名無しさん** · 2024/02/12(月) 18:37:22.53

>>671
GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ
nominal/structuralと動的/静的は直交

**デフォルトの名無しさん** · 2024/02/12(月) 18:47:33.19

Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから
静的ではないでしょ？
そんなことはC++やRustでは許されない行為だよ

**デフォルトの名無しさん** · 2024/02/12(月) 19:22:42.84

>>676
TSはanyで型が消えてるときの話じゃないの？

**デフォルトの名無しさん** · 2024/02/12(月) 20:01:03.19

誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく

**デフォルトの名無しさん** · 2024/02/12(月) 20:07:14.69

一言居士の群れ

**デフォルトの名無しさん** · 2024/02/12(月) 20:21:22.17

ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪
Rustは排除しているので大丈夫
そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる

**デフォルトの名無しさん** · 2024/02/12(月) 20:24:19.09

現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな

**デフォルトの名無しさん** · 2024/02/12(月) 20:44:24.28

>>682
そのフレームワークがデザインパターンで出来てるんだけど

**デフォルトの名無しさん** · 2024/02/12(月) 21:02:02.43

アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない

**デフォルトの名無しさん** · 2024/02/12(月) 21:59:54.43

>>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……

Rustのgenericsはどれくらいダックタイピングできているかね。

**デフォルトの名無しさん** · 2024/02/12(月) 22:09:04.93

>>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す

例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる
これは実行時に動的に処理されるためダックタイピングとなる

もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ

**デフォルトの名無しさん** · 2024/02/12(月) 22:14:48.84

C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ

**デフォルトの名無しさん** · 2024/02/12(月) 22:15:23.35

C++のtemplateで正しく関数を呼ぶの難しいよ……

**デフォルトの名無しさん** · 2024/02/12(月) 22:30:02.58

>>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ

**デフォルトの名無しさん** · 2024/02/12(月) 22:30:58.32

C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です

**デフォルトの名無しさん** · 2024/02/12(月) 22:50:06.45

C++のテンプレートは闇深すぎるよね

**デフォルトの名無しさん** · 2024/02/12(月) 22:50:36.74

>>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。

**デフォルトの名無しさん** · 2024/02/12(月) 22:54:09.63

>>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる

**デフォルトの名無しさん** · 2024/02/12(月) 23:33:02.01

>>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある

**デフォルトの名無しさん** · 2024/02/12(月) 23:52:54.50

委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね

静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理

**デフォルトの名無しさん** · 2024/02/13(火) 00:30:00.87

確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？

**デフォルトの名無しさん** · 2024/02/13(火) 02:23:26.95

ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ

**デフォルトの名無しさん** · 2024/02/13(火) 03:26:01.95

オレオレ定義で擬似問題作るの止めろ。

ダックタイピングについてはWikipediaの解説でいいか。
ja.m.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0
英語版が一番詳しいかね。

**デフォルトの名無しさん** · 2024/02/13(火) 07:31:17.64

>>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側

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

>>699
アンチパターンや亜種になるだけで全部パターンだぞ

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

はじめにパターンありき、ではない

**デフォルトの名無しさん** · 2024/02/13(火) 09:29:40.48

ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所

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

うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？

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

>>703
そんなわけないでしょ

**デフォルトの名無しさん** · 2024/02/13(火) 10:29:29.95

>>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ

**デフォルトの名無しさん** · 2024/02/13(火) 10:30:11.10

>>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう

**デフォルトの名無しさん** · 2024/02/13(火) 10:31:44.87

>>703
その講師優秀やな

**デフォルトの名無しさん** · 2024/02/13(火) 11:11:21.55

>>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。

**デフォルトの名無しさん** · 2024/02/13(火) 11:16:14.81

>>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ

**デフォルトの名無しさん** · 2024/02/13(火) 11:22:46.51

ここまで俺の自演

**デフォルトの名無しさん** · 2024/02/13(火) 11:32:02.27

>>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。

**デフォルトの名無しさん** · 2024/02/13(火) 11:43:25.76

>>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ

**デフォルトの名無しさん** · 2024/02/13(火) 11:46:14.62

まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと

**デフォルトの名無しさん** · 2024/02/13(火) 11:53:02.08

荒らしに構った時点でお前らの負け

**デフォルトの名無しさん** · 2024/02/13(火) 11:57:48.21

>>703が荒らし判定されてて草ww

**デフォルトの名無しさん** · 2024/02/13(火) 12:05:17.83

>>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。

c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？

**デフォルトの名無しさん** · 2024/02/13(火) 12:09:09.09

わかる→　Pythonで簡単なスクリプトを書く
キチガイ→　Pythonでプログラミング開発する

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

Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ

**デフォルトの名無しさん** · 2024/02/13(火) 12:15:32.69

よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？

**デフォルトの名無しさん** · 2024/02/13(火) 13:03:33.72

単発NG推奨

**デフォルトの名無しさん** · 2024/02/13(火) 13:04:48.12

単発NG推奨
連鎖あぼーん推奨

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

スレNG推奨では？

**デフォルトの名無しさん** · 2024/02/13(火) 14:10:44.85

また境界知能が暴れてんのか
いい加減諦めろよ

**デフォルトの名無しさん** · 2024/02/13(火) 15:09:27.64

C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど

**デフォルトの名無しさん** · 2024/02/13(火) 19:22:36.57

XML大嫌い

**デフォルトの名無しさん** · 2024/02/13(火) 20:34:52.16

>>716
やりたいことがよく分からないけどtraitのassociation typeで解決しない？
I: Iteratorだと要素の型はI::Item（正確には<I as Iterator>::Item）になるみたいな
C++のconceptだとtypenameに相当するのかな

traitにgenericsの型パラメータ持たせるかassociation type使うかの判断は慣れるまで難しいけど
選択肢が複数あって外部から決められる　⇒　generics型パラメータ（例：AsRef<T>）
traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
みたいに使い分けるといい
全部をgenericsの型パラメータでやろうとするとカオスになる

**デフォルトの名無しさん** · 2024/02/13(火) 21:06:36.86

>>716
できる
例えばこのように

https://docs.rs/hyper/latest/hyper/service/trait.Service.html

pub trait Service<Request> {
　type Response;
　type Error;
　type Future: Future<Output = Result<Self::Response, Self::Error>>;
　
　// Required method
　fn call(&self, req: Request) -> Self::Future;
}

ここで型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタResponseは依存しない

>>726
その二種類の混合も可能