Rust part22

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/26 16:41 / Filesize : 258 KB / Number-of Response : 1021
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part22

1 名前：デフォルトの名無しさん [2024/01/20(土) 23:21:40.08 ID:wyzQTwgG.net]: 公式
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/
559 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:01:44.04 ID:YTHRY4oL.net]: >>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ
560 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:16:33.29 ID:8ut+BFv7.net]: Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから
561 名前：デフォルトの名無しさん [2024/02/10(土) 13:20:09.17 ID:LlCsSE+Z.net]: >>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ
562 名前：デフォルトの名無しさん [2024/02/10(土) 13:24:24.95 ID:RZD3J/dp.net]: >>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね
563 名前：デフォルトの名無しさん [2024/02/10(土) 13:42:15.57 ID:bXBK2+hH.net]: >>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな

一言で言えばどちらも低DX
564 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:57:43.35 ID:UK9hi/1i.net]: >>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい
565 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 13:58:54.16 ID:iJNhxzEm.net]: >>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど
566 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:03:55.89 ID:lW9Vkr52.net]: >>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな
567 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:05:28.57 ID:iJNhxzEm.net]: デザインパターンといえばGoFは流石に古くないか？？
568 名前：デフォルトの名無しさん [2024/02/10(土) 14:05:43.92 ID:AU1t0rvZ.net]: デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン
569 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:08:00.40 ID:iJNhxzEm.net]: デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます
570 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:23:27.48 ID:Aed3I3PZ.net]: 話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか
571 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:40:14.16 ID:XEL9SE6k.net]: 出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。
572 名前：デフォルトの名無しさん [2024/02/10(土) 14:40:53.07 ID:b8HpDXca.net]: >>559
いつからブラウザで見ていると勘違いしていた
573 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:42:22.10 ID:YTHRY4oL.net]: >>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？
574 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:46:24.04 ID:VP+Iax6j.net]: Javarが考えた設計は根本的に汚い
575 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:49:44.24 ID:WFGhMJhr.net]: オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった

元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している
576 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:56:46.66 ID:iJNhxzEm.net]: >>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood
577 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:58:45.32 ID:VP+Iax6j.net]: いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話
578 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 14:59:40.15 ID:iJNhxzEm.net]: ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…
579 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 15:00:30.74 ID:iJNhxzEm.net]: >>566
ごめん勘違いした>>565はスルーしてほしい
580 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 15:16:47.93 ID:+PSgdWvA.net]: ・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる
581 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:24:25.37 ID:YTHRY4oL.net]: 今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな
582 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:37:42.00 ID:LPOrO1iz.net]: 継承抜きオブシコで十分っす
583 名前：デフォルトの名無しさん [2024/02/10(土) 16:45:54.10 ID:8zmdFTlm.net]: なんでrustスレで他言語の雑談始まってしもたん
584 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 16:58:53.57 ID:WFGhMJhr.net]: >>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと
585 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:00:23.08 ID:9OXXn/no.net]: 継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？
586 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:09:17.38 ID:qHcm0B3l.net]: 従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし
587 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:37:53.51 ID:lWs+b/Tw.net]: Rustの型クラスは最強
588 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:45:44.24 ID:cODs5/To.net]: rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ
589 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 17:48:42.70 ID:7r8QxWN2.net]: >>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話
590 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:00:46.16 ID:5OwpQQMY.net]: >>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？
591 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:18:59.99 ID:cODs5/To.net]: >>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ
592 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:20:18.08 ID:iJNhxzEm.net]: >>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん
593 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:22:04.19 ID:/ZC4Oa+s.net]: 只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。

おまいらは政治将校か？
594 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:23:43.39 ID:7r8QxWN2.net]: 実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う
595 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:25:26.70 ID:iJNhxzEm.net]: Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？
596 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:26:30.51 ID:iJNhxzEm.net]: >>583
勉強になる👍
597 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:27:23.64 ID:7r8QxWN2.net]: >>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う
598 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:29:37.58 ID:+PSgdWvA.net]: >>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項対立まで否定するのは行き過ぎだよ
599 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 18:50:48.17 ID:cODs5/To.net]: >>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない
600 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:06:04.16 ID:kzqqrU6F.net]: オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ
601 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:08:51.93 ID:kzqqrU6F.net]: あと関数型と手続き型の区別がつかない
602 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:19:34.87 ID:IjP+HezS.net]: 関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない
603 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:31:34.99 ID:76r5Dddg.net]: >>590
一緒だよ
604 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:44:00.53 ID:6ZZO7tOM.net]: 高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね

あと論理型というのがあったなあ
605 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:47:12.54 ID:IoMlesHJ.net]: >>589
フロントエンド用途でコンポーネント指向

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

オブジェクト指向に成り代わるものはいまだ出てきていない
606 名前：デフォルトの名無しさん [2024/02/10(土) 19:50:32.36 ID:H74b4wDc.net]: オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう

オブジェクト指向信者もJavaは嫌いそう
607 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:52:30.82 ID:IoMlesHJ.net]: それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？
608 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 19:57:03.35 ID:iu2BL++f.net]: むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。
609 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:00:09.44 ID:lgwlEc8K.net]: オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手
610 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:03:05.61 ID:6ZZO7tOM.net]: 狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ

カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある
611 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:03:30.97 ID:WFGhMJhr.net]: >>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない
612 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:05:33.42 ID:2iG7gUv6.net]: なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね
613 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:10:54.41 ID:VlV2WaeL.net]: オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど
614 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:13:45.74 ID:o2x+aGn+.net]: 関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない
615 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:22:15.34 ID:6cZfMrU8.net]: >>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ
616 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:30:09.19 ID:xWWw0qe+.net]: フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね
617 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 20:39:26.86 ID:U5vUZCjE.net]: 手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型
618 名前：デフォルトの名無しさん [2024/02/10(土) 20:46:30.71 ID:lnD8LNvj.net]: オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄
619 名前：デフォルトの名無しさん mailto:sage [2024/02/10 ]: [ここ壊れてます]
620 名前：(土) 20:54:14.59 ID:XEL9SE6k.net mailto: グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。 []: [ここ壊れてます]
621 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:00:12.52 ID:2fVxDtyX.net]: オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど
622 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:04:41.79 ID:hNXhuidE.net]: 勉強になるような知識どんどん書き込んでくれ
623 名前：デフォルトの名無しさん [2024/02/10(土) 21:20:25.37 ID:wHWIBAUz.net]: オブジェクトを指向指向したら汚いコードがいっぱい出た
624 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 21:34:14.43 ID:t6h0tc+k.net]: オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない
625 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:00:16.03 ID:EoWeXpbc.net]: >>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？
626 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:03:08.49 ID:TERvB2uZ.net]: みんながRustを使えば解決だね
627 名前：デフォルトの名無しさん [2024/02/10(土) 22:07:13.96 ID:a08tomEu.net]: 一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った

結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった
628 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:12:14.65 ID:Bpk68K+1.net]: 今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ
629 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:14:50.40 ID:XEL9SE6k.net]: べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。
630 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:26:31.80 ID:ewSY5W0Q.net]: 継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう
631 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:29:03.46 ID:Lf9bQLCg.net]: >>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか
632 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:30:28.98 ID:HLmY2iS7.net]: >>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな
633 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:42:16.36 ID:+PSgdWvA.net]: >>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ
634 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:56:15.78 ID:XEL9SE6k.net]: 関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。
635 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 22:57:32.43 ID:YTHRY4oL.net]: いやマジレスすなw
636 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 23:01:02.32 ID:2CpL/1KO.net]: Deref使った継承もどきは委譲と変わらんよ

継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ
637 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 23:23:00.37 ID:+PSgdWvA.net]: 正しい責
638 名前：任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい 正当化が必要と感じる人には継承が必要なのだろう []: [ここ壊れてます]
639 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 08:17:40.00 ID:Jcf8p7/N.net]: 委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる
640 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 08:28:38.26 ID:8+WjthrU.net]: インターフェースでやるときこそ委譲の使いどころでは？
データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え
641 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 09:33:37.86 ID:QXc2iF2X.net]: オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。
642 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 09:47:23.19 ID:mQVY2wVN.net]: >>627
レポジトリはドメインレイヤーがやるところでしょ
643 名前：デフォルトの名無しさん [2024/02/11(日) 12:10:09.20 ID:xzgPE83s.net]: >>627
delegationとforwardingの区別が付いてないね
644 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 12:18:42.79 ID:eNn3abAv.net]: ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向
645 名前：デフォルトの名無しさん [2024/02/11(日) 13:10:55.53 ID:5cbdJqGT.net]: オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある

だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる
646 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 13:30:06.52 ID:UTHxd4xs.net]: >>627
それは委譲ではない
継承と委譲とインターフェースは違うもの
647 名前：デフォルトの名無しさん [2024/02/11(日) 14:12:49.22 ID:tvA72CFJ.net]: 自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない
648 名前：デフォルトの名無しさん [2024/02/11(日) 14:28:55.59 ID:FmT3HYkV.net]: >>634
“賢い”の定義が違うんだろ
察してやれ
649 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 14:35:31.96 ID:eNn3abAv.net]: 定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている
650 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 15:00:23.67 ID:p0mJmxcL.net]: Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ
651 名前：デフォルトの名無しさん [2024/02/11(日) 15:56:01.57 ID:EVWrf4kv.net]: >>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ
652 名前：デフォルトの名無しさん [2024/02/11(日) 16:06:16.13 ID:nNzLNGzY.net]: オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね
653 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 16:16:18.76 ID:+E66gntj.net]: >>639
(^_^)ﾉ
654 名前：デフォルトの名無しさん [2024/02/11(日) 16:21:31.17 ID:cP74y9AE.net]: 時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる
655 名前：デフォルトの名無しさん [2024/02/11(日) 16:24:12.02 ID:aCOYKxUA.net]: >>637
型理論においてはどちらも同じ
656 名前：デフォルトの名無しさん [2024/02/11(日) 16:30:25.25 ID:O/MMVA2r.net]: なんかみんな単発だからレスバできないなあ
657 名前：デフォルトの名無しさん [2024/02/11(日) 20:46:34.90 ID:XOn8R4o/.net]: RustがJSを滅ぼしてくれるのはいつになるかいのう……
658 名前：デフォルトの名無しさん [2024/02/11(日) 21:26:37.41 ID:M/VumamL.net]: まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる
659 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 21:51:44.10 ID:XOPhWcHA.net]: DOMはJSに依存しないしいろんな言語のインターフェースがあるが。
660 名前：デフォルトの名無しさん [2024/02/11(日) 22:42:14.41 ID:575tRfGH.net]: >>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない
661 名前：デフォルトの名無しさん [2024/02/11(日) 22:47:25.71 ID:YLWTi6Ka.net]: >>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ
662 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 22:56:40.04 ID:Ij1X5KaV.net]: >>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない

そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく
663 名前：デフォルトの名無しさん mailto:sage [2024/02/11(日) 23:09:37.71 ID:bi52uRem.net]: 自演ええて
664 名前：デフォルトの名無しさん [2024/02/11(日) 23:36:32.19 ID:BuG8Esm8.net]: >>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要
665 名前：デフォルトの名無しさん [2024/02/12(月) 00:40:57.30 ID:cVfqqlnc.net]: tree構造以外である程度の汎用性あるデータ構造なんてないわ。
666 名前：デフォルトの名無しさん [2024/02/12(月) 01:04:43.36 ID:tgn3NuIP.net]: DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話
667 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:19:02.60 ID:Autq7Dxb.net]: >>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。
668 名前：デフォルトの名無しさん [2024/02/12(月) 10:33:25.13 ID:QcKWCRm/.net]: >>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実
669 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:41:33.86 ID:Autq7Dxb.net]: DOMの設計と全然関係ない話。
670 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 10:51:22.86 ID:dpV2oNnW.net]: >>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人
671 名前：デフォルトの名無しさん [2024/02/12(月) 11:07:16.48 ID:UiVeSAOt.net]: domなしでのナビゲーションの方法があってもいいとは思う
672 名前：デフォルトの名無しさん [2024/02/12(月) 11:08:30.75 ID:CTu12wXT.net]: いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる
673 名前：デフォルトの名無しさん [2024/02/12(月) 11:23:28.89 ID:u1N968/b.net]: >>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね

DOMが欠陥品？
で？君はどうしたいんだい？
674 名前：デフォルトの名無しさん [2024/02/12(月) 11:28:30.41 ID:e3JrcLqa.net]: >>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った
675 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 11:38:53.51 ID:nlvJBCEb.net]: DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと
676 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 11:41:30.45 ID:dpV2oNnW.net]: やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい
677 名前：デフォルトの名無しさん [2024/02/12(月) 13:30:26.12 ID:UkU83gVN.net]: DOMの代替の候補って存在するのかな
678 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 13:49:21.10 ID:3NLsFenn.net]: >>662
Windowsはゴミだから個人も仕事からも排除した
しかしネットがWebベースのこの時代にWebブラウザは排除できない
DOMは取り扱わざるを得ない

とはいえRustによるWasmからの取り扱いは以前よりかなり状況が良くなってきている
まずReference Types の導入によりJavaScriptのオブジェクトをそのまま透過的にだがRust(Wasm)側でも持ったり返したりできるようになった
これはJavaScriptグルーコードの削減をもたらしている
さらにGC対応もメモリ管理のうちJavaScript側依存のものの扱いを任せられるようになりRustでも取り扱いが楽になる
Rust側の内部に閉じたデータのみメモリ管理すればよくなるからだ
679 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:41:26.64 ID:QicyHe7E.net]: デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。
「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。

あと、Rustでダックタイピングできたっけ？事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。
680 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:46:26.73 ID:FSKnAMMD.net]: デザインパターンって簡単に実装できるとか
自慢するたぐいのものだっけ？
681 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:55:33.33 ID:Jqge1vnq.net]: 単発NG推奨
682 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:56:29.31 ID:9yTkyF6j.net]: ドメインまわりをフレームワークと分離させる設計ならなんでもいいや
今後リファクタリングすることを考えた設計が大事
683 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 15:56:34.13 ID:Jqge1vnq.net]: ここはRustスレです消えてください
684 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:00:10.23 ID:nHDMmyKy.net]: >>666
ダックタイピングは動的型付け言語のためのオモチャであり
デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている
ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる
もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない
685 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:11:47.85 ID:KZYjz35/.net]: ダックタイピングというゴミのような方法に対して
Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した
それがtraitのrequired methodsとtrait boundsである
この二つにより全てを解決している
686 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 16:12:19.21 ID:9yTkyF6j.net]: ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ
687 名前：デフォルトの名無しさん [2024/02/12(月) 16:23:13.06 ID:cVfqqlnc.net]: >>664
ない。結局まともに使えるものを用意しようと思えばああなる。
それも理解せずに馬鹿みたいに文句言ってるだけだわな。
688 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 18:20:41.31 ID:g0MzjlGR.net]: >>667
繰り返されれば飽きる
繰り返されないのはパターンではない
689 名前：デフォルトの名無しさん [2024/02/12(月) 18:37:22.53 ID:NJ55srXB.net]: >>671
GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ
nominal/structuralと動的/静的は直交
690 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 18:47:33.19 ID:0RqNbR5g.net]: Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから
静的ではないでしょ？
そんなことはC++やRustでは許されない行為だよ
691 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 19:22:42.84 ID:QavMz5Qe.net]: >>676
TSはanyで型が消えてるときの話じゃないの？
692 名前：デフォルトの名無しさん [2024/02/12(月) 20:01:03.19 ID:uYjIYqfU.net]: 誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく
693 名前：デフォルトの名無しさん [2024/02/12(月) 20:07:14.69 ID:uYjIYqfU.net]: 一言居士の群れ
694 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 20:21:22.17 ID:oZv/D2wt.net]: ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪
Rustは排除しているので大丈夫
そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる
695 名前：デフォルトの名無しさん [2024/02/12(月) 20:24:19.09 ID:H9LyWZwk.net]: 現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな
696 名前：デフォルトの名無しさん [2024/02/12(月) 20:44:24.28 ID:5CWzyU2K.net]: >>682
そのフレームワークがデザインパターンで出来てるんだけど
697 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 21:02:02.43 ID:g0MzjlGR.net]: アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない
698 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 21:59:54.43 ID:QicyHe7E.net]: >>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……

Rustのgenericsはどれくらいダックタイピングできているかね。
699 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:09:04.93 ID:h7gv4DVB.net]: >>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す

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

もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ
700 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:14:48.84 ID:YxZv/CkW.net]: C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ
701 名前：デフォルトの名無しさん [2024/02/12(月) 22:15:23.35 ID:JpOX7sRf.net]: C++のtemplateで正しく関数を呼ぶの難しいよ……
702 名前：デフォルトの名無しさん [2024/02/12(月) 22:30:02.58 ID:DrV/13x2.net]: >>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ
703 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:30:58.32 ID:9yTkyF6j.net]: C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です
704 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:50:06.45 ID:kWCXoXun.net]: C++のテンプレートは闇深すぎるよね
705 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:50:36.74 ID:4VueJhli.net]: >>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。
706 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 22:54:09.63 ID:RSTU7X98.net]: >>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる
707 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 23:33:02.01 ID:g0MzjlGR.net]: >>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある
708 名前：デフォルトの名無しさん mailto:sage [2024/02/12(月) 23:52:54.50 ID:Dj37TM3K.net]: 委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね

静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理
709 名前：デフォルトの名無しさん [2024/02/13(火) 00:30:00.87 ID:xtMg5XLl.net]: 確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？
710 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 02:23:26.95 ID:vbRTXFPD.net]: ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ
711 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 03:26:01.95 ID:s0kRtfrq.net]: オレオレ定義で擬似問題作るの止めろ。

ダックタイピングについては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
英語版が一番詳しいかね。
712 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 07:31:17.64 ID:KlTxxkJG.net]: >>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側
713 名前：デフォルトの名無しさん [2024/02/13(火) 08:18:01.41 ID:EJGfS3Xj.net]: >>699
アンチパターンや亜種になるだけで全部パターンだぞ
714 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 08:30:13.65 ID:eXWviQcC.net]: はじめにパターンありき、ではない
715 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 09:29:40.48 ID:d0oThnC1.net]: ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所
716 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:20:47.32 ID:yeb3oliP.net]: うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？
717 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:23:31.22 ID:T85IlqBy.net]: >>703
そんなわけないでしょ
718 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:29:29.95 ID:iVxwtbvh.net]: >>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ
719 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:30:11.10 ID:ep9QvdZW.net]: >>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう
720 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 10:31:44.87 ID:mnEJD8Sx.net]: >>703
その講師優秀やな
721 名前：デフォルトの名無しさん [2024/02/13(火) 11:11:21.55 ID:mXdLEMzy.net]: >>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。
722 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:16:14.81 ID:iVxwtbvh.net]: >>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ
723 名前：デフォルトの名無しさん [2024/02/13(火) 11:22:46.51 ID:BKo58x30.net]: ここまで俺の自演
724 名前：デフォルトの名無しさん [2024/02/13(火) 11:32:02.27 ID:mXdLEMzy.net]: >>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。
725 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:43:25.76 ID:bOFev+sF.net]: >>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ
726 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:46:14.62 ID:bOFev+sF.net]: まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと
727 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:53:02.08 ID:rA+hqhZ3.net]: 荒らしに構った時点でお前らの負け
728 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 11:57:48.21 ID:qvC4XjeP.net]: >>703が荒らし判定されてて草ww
729 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:05:17.83 ID:n6Gkr1cM.net]: >>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。

c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？
730 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:09:09.09 ID:IxuyFkNI.net]: わかる→　Pythonで簡単なスクリプトを書く
キチガイ→　Pythonでプログラミング開発する
731 名前：デフォルトの名無しさん [2024/02/13(火) 12:12:34.52 ID:KvZIg8uL.net]: Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ
732 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 12:15:32.69 ID:1UgkqCq+.net]: よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？
733 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:03:33.72 ID:X5Whr4lm.net]: 単発NG推奨
734 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 13:04:48.12 ID:X5Whr4lm.net]: 単発NG推奨
連鎖あぼーん推奨
735 名前：デフォルトの名無しさん [2024/02/13(火) 13:49:44.45 ID:BKo58x30.net]: スレNG推奨では？
736 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 14:10:44.85 ID:q0xfm82v.net]: また境界知能が暴れてんのか
いい加減諦めろよ
737 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 15:09:27.64 ID:j+0n3+gu.net]: C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど
738 名前：デフォルトの名無しさん [2024/02/13(火) 19:22:36.57 ID:ui4ZrT7T.net]: XML大嫌い
739 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 20:34:52.16 ID:u8WS3GIa.net]: >>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の型パラメータでやろうとするとカオスになる
740 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:06:36.86 ID:4D6oEUgV.net]: >>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
その二種類の混合も可能
741 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 21:08:42.27 ID:4D6oEUgV.net]: ごめん
>>727はこうね

型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない
742 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 22:37:37.84 ID:s0kRtfrq.net]: ちょっと違うなぁ。

c++ template & conceptだと
wandbox.org/permlink/74j79ZQ3mbPb2cLO
みたいな感じでCircleはf()の影響を受けずに独立させることができる。
draw()メソッドというダックテストを満たせば他はどうでも良い。

Rustのgenericsだと
wandbox.org/permlink/CvepQKXOXaNTJoJm
みたいにCircleとf()の間にtrait Dという相互依存ができて、Circleを好き勝手に定義できなくなる。

f()が欲しいのはあくまでdraw()メソッドだけだから、双方にtrait Dが必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。
743 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:17:32.55 ID:RVgq5WHA.net]: それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ
744 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:20:56.53 ID:KlTxxkJG.net]: Pythonは全てにおいてJuliaに劣った言語だな
745 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:47.57 ID:u8WS3GIa.net]: >>729
Circleを
fn f<T: Drawable>(t: &T) -> f64 { t.draw() }
に渡したいなら普通に
impl Drawable for Circle {
fn draw(&self) -> f64 { <Circle as D>::draw(self) }
}
を追加するな
コントラクトの明示を余計な依存関係だとは思わない

ちなみに
impl Circle {
fn draw() -> f64 {...}
}
みたいに本体のimplに定義するとCircleのself.draw()は全部こっちで解決されるから
impl Drawable for Circle {
fn draw(&self) -> f64 { self.draw() }
}
って書ける

１つの型に複数のtraitで同じ名前の関数を持たせるのはRustだとたまに見かける
impl Debugとimpl Displayはどっちもfn fmt()で別の実装するし
746 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:28:48.94 ID:RVgq5WHA.net]: >>726
>traitを実装するときに内部で自動的に決まる　⇒　association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う

使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる
747 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:30:39.22 ID:9eHJiOzP.net]: >>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ
748 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:32:24.97 ID:RaqlAe+S.net]: traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ
749 名前：デフォルトの名無しさん mailto:sage [2024/02/13(火) 23:35:00.89 ID:8wj/C7pB.net]: >>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚
750 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:05:25.04 ID:uLd8jazY.net]: Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。
751 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 05:28:01.52 ID:uLd8jazY.net]: >732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。

まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。
752 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 06:58:38.09 ID:t2TEYrx/.net]: >>738
>>これはRustが嫌っているクラスの継承みたいなもの

クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない
753 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:00.30 ID:HWQ4xiFb.net]: 自演きもいなあ
754 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:00:27.71 ID:523CbVaw.net]: 実装継承はゴミ
755 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:05:57.04 ID:Uwd6Wtce.net]: >>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い
756 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 07:33:52.24 ID:uLd8jazY.net]: >>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。
757 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:08:30.71 ID:b46uhNiQ.net]: >>742
実運用はビルド済だから関係ないな。
758 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:09:58.02 ID:t2TEYrx/.net]: >>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない
759 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:41:45.06 ID:W3PM5KGQ.net]: >>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ
760 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:51:32.74 ID:t2TEYrx/.net]: >>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる
761 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 08:55:57.66 ID:b46uhNiQ.net]: >>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。
762 名前：デフォルトの名無しさん [2024/02/14(水) 09:07:35.89 ID:L7EuZktb.net]: 真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ
763 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:20:06.07 ID:BSRmwKLd.net]: >>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか

Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな
764 名前：デフォルトの名無しさん [2024/02/14(水) 09:36:07.02 ID:48k6rT3Y.net]: >>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね
765 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 09:47:17.10 ID:c6aYZ04m.net]: >>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装する�
766 名前：ｱとで結果的に各機能の合成となる []: [ここ壊れてます]
767 名前：デフォルトの名無しさん [2024/02/14(水) 09:59:07.19 ID:YhuSf3ik.net]: 細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う
768 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:10:46.95 ID:Z6/Yikm0.net]: >>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。

>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？
769 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:17:10.59 ID:naKe/3pl.net]: ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ
770 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:27:45.39 ID:s2Ev9A6j.net]: >>738
言語側のサポートならマクロで十分でしょ

macro_rules! impl_drawable {
($type:ty) => {
impl $crate::path::to::Drawable for $type {
fn draw(&self) -> f64 { self.draw() }
}
}}

を定義すれば

impl_drawable!(Circle);

だけでimpl Drawable for Cirle {...}を生成できる
渡された型が同じ引数＆戻り値のself.draw()をもってないとコンパイルできないから実質ダックタイピング
Drawableに関数を追加したらマクロにも追加すればいい

draw関数の有無だけで照合するのは別の意味のdrawも対象になるから危なっかしい
impl traitだとどのモジュールのDrawableを実装するかまで指定できるから混同の心配がなくなる
771 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:44:54.87 ID:AzS2pw5X.net]: ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう
772 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 10:53:25.15 ID:naKe/3pl.net]: >>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ
773 名前：デフォルトの名無しさん [2024/02/14(水) 11:07:38.32 ID:RfRsJx+N.net]: 使う側が気をつけるならC++も問題ないからな
774 名前：デフォルトの名無しさん [2024/02/14(水) 11:17:22.43 ID:NjTyhCIW.net]: >>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター
775 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:23:15.20 ID:FEB+PUkj.net]: >>759
そゆこと
だからRustは不要
776 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:28:02.15 ID:naKe/3pl.net]: ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない
777 名前：デフォルトの名無しさん [2024/02/14(水) 11:51:49.92 ID:L7EuZktb.net]: ここで>>9-20の流れを振り返ってみましょう
778 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 11:52:42.46 ID:3OoaoCBc.net]: C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば

fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}

みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。
779 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:13:59.14 ID:s2Ev9A6j.net]: >>760
どこをどう曲解しても実装継承にはならんだろ
すべてのケースでマクロ使うとでも思ってるの？
〇〇の思考回路はよく分からん

>>764
Atomic系統ならfetch_addがあるけど普通のincrementは単純＆限定的すぎて逆にないな
std::mem::replace使えば
replace(&mut t, t+1)
とかできるけど+1するだけなら大袈裟すぎる気がする
780 名前：デフォルトの名無しさん [2024/02/14(水) 12:19:27.37 ID:Cdw7DngV.net]: >>761
だからの文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。
781 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:25:13.12 ID:b46uhNiQ.net]: >>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。
782 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:29:23.30 ID:naKe/3pl.net]: >>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している
783 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:49:07.16 ID:b46uhNiQ.net]: >>768
自明だと�
784 名前：沛ﾘできる証明を示して頂戴。 検証可能性の無い主張は単なる疑似科学だし。 []: [ここ壊れてます]
785 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:52:16.39 ID:KpCwABm3.net]: 欠点がない言語なんて無いから言い争ってもね。
786 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 12:57:57.69 ID:p6Tfi6cJ.net]: そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明
787 名前：デフォルトの名無しさん [2024/02/14(水) 13:07:28.33 ID:L7EuZktb.net]: たし🦀
788 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:09:31.24 ID:aR1xhX8a.net]: おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき
789 名前：デフォルトの名無しさん [2024/02/14(水) 13:16:05.40 ID:eD+V22zq.net]: drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ
790 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:33:10.33 ID:Q08aEmFz.net]: 境界知能が可視化されてる
791 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:53:52.28 ID:Z6/Yikm0.net]: >>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。
792 名前：デフォルトの名無しさん [2024/02/14(水) 13:55:32.21 ID:eD+V22zq.net]: >>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ

ダックタイピングは白紙の契約書にサインするようなものだ
793 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 13:57:04.55 ID:s22bd+Hs.net]: >>775
お前のこと？
794 名前：デフォルトの名無しさん [2024/02/14(水) 14:31:04.48 ID:h4S8S2sP.net]: >>777
これな
795 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 14:41:15.13 ID:3OoaoCBc.net]: >>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……
796 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:12:12.70 ID:s2Ev9A6j.net]: >>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな
797 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 15:36:36.14 ID:S2bQYQek.net]: >>764
Rustで++は排除されている

理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな
798 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:02:27.29 ID:3OoaoCBc.net]: >>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。
799 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:29:39.74 ID:ona7PgM1.net]: >>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ

fn increment(dest: &mut u32) -> u32 {
　std::mem::replace(dest, *dest + 1)
}
800 名前：デフォルトの名無しさん [2024/02/14(水) 16:36:51.93 ID:b+wxXawK.net]: 質問している人間相手なら関係ないことを書いて良いわけではない
801 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:42:22.39 ID:3OoaoCBc.net]: >>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。
802 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:13.61 ID:L7EuZktb.net]: ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……
803 名前：デフォルトの名無しさん [2024/02/14(水) 16:46:26.67 ID:b+wxXawK.net]: 一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない
804 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 16:51:03.66 ID:3OoaoCBc.net]: >>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。

ID:S2bQYQek さん、すいません
805 名前：デフォルトの名無しさん [2024/02/14(水) 17:05:32.23 ID:ZK4bCcm/.net]: 人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい
806 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 17:06:20.11 ID:Q08aEmFz.net]: だから境界知能なんでしょ
807 名前：デフォルトの名無しさん [2024/02/14(水) 17:19:45.82 ID:qgmjNVo3.net]: 腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう
808 名前：デフォルトの名無しさん [2024/02/14(水) 17:26:03.70 ID:h4S8S2sP.net]: tmuxよりscreen派だよ。
809 名前：デフォルトの名無しさん [2024/02/14(水) 17:50:47.59 ID:6CXfQ6Kw.net]: 個人的には後置インクリメントだけを関数化するのは微妙に感じる

fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う
810 名前：デフォルトの名無しさん [2024/02/14(水) 19:51:05.67 ID:7rKeAYke.net]: >>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。
811 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 19:57:21.78 ID:b46uhNiQ.net]: >>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。
812 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:14:14.28 ID:yh2p7tDo.net]: >>796
C++では機能の異なる同名メソッドを区別できないから欠陥品
813 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 20:52:10.35 ID:b46uhNiQ.net]: >>797
引数・戻り値で区別できるだろ。
814 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:01:37.45 ID:yh2p7tDo.net]: >>798
それに依存してしまうのがC++の限界
815 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:18:41.79 ID:b46uhNiQ.net]: >>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。
816 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 21:58:58.38 ID:H5X+9PTs.net]: >>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため
817 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:13:29.10 ID:uLd8jazY.net]: >>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？

Rustのtraitて、副作用のコントロールできたっけ？
818 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 22:26:20.82 ID:8gvFvpJ5.net]: traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ
819 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:19:42.33 ID:3OoaoCBc.net]: >>803
コンセプト。
820 名前：デフォルトの名無しさん mailto:sage [2024/02/14(水) 23:20:56.22 ID:3OoaoCBc.net]: >>792
毎度毎度のことで余裕を削られた最後だったんだよ。
821 名前：デフォルトの名無しさん [2024/02/15(木) 00:20:11.01 ID:AyUC+mx+.net]: 毎度毎度のことという認識を持っていながらなぜここに書き込むのか
822 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 00:23:07.31 ID:x2y7hFPc.net]: >>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。
823 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:06:08.60 ID:13EQhuxe.net]: >>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的
824 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:43:10.62 ID:j4EJcuA3.net]: >>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。
825 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 07:55:56.64 ID:hKdVOM0D.net]: >>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり
826 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:11:38.37 ID:j4EJcuA3.net]: >>810
検索したけど見つからなかった……
リンクある？
827 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:17:50.82 ID:Me0Wd39H.net]: [Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)
828 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:19:40.94 ID:j4EJcuA3.net]: >>812
サンクス。
家帰ったら見るわ。
829 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 08:48:36.69 ID:UeUfm3Ct.net]: >>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、
830 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:52:51.93 ID:x2y7hFPc.net]: >>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。
831 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 09:55:25.99 ID:LYiZEs3M.net]: エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？
832 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:07:56.04 ID:x2y7hFPc.net]: >>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。
833 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:11:47.35 ID:9MXGquuv.net]: C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる
834 名前：デフォルトの名無しさん [2024/02/15(木) 10:21:13.40 ID:qaCOVcST.net]: まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは

Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある
835 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:32:36.57 ID:LYiZEs3M.net]: >>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…
836 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:37:24.02 ID:x2y7hFPc.net]: 「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。

現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。

C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。

Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。
837 名前：デフォルトの名無しさん [2024/02/15(木) 10:38:37.60 ID:TrooctNX.net]: 今の時点で使いやすければなんでもいいんだYO
838 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 10:45:22.07 ID:9MXGquuv.net]: C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま
839 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 11:47:28.36 ID:olqTmpaN.net]: C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ
840 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 12:02:34.79 ID:oxTsPXaA.net]: >>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法
841 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:40:35.94 ID:wvzNp0zm.net]: そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分
842 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 14:47:01.34 ID:z+RD4XEG.net]: サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある
843 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:20:13.71 ID:x2y7hFPc.net]: >>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。
844 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:46:19.25 ID:606b12LT.net]: >>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね
845 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 16:50:52.01 ID:olqTmpaN.net]: すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる
846 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:21:54.77 ID:SzbBTI0k.net]: >>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない
847 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:26:25.25 ID:BHoNDVf7.net]: Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい
848 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:31:26.55 ID:dtRRoOMy.net]: Ruby は、Go/Rust/Elixir の3大言語を超えた！
Rust の上昇は止まったか？

Stack Overflow 米国年収。2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5～7 -> 7.3～7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6
849 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:35:21.87 ID:eOw5Ad1t.net]: >>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/
850 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:41:41.98 ID:wvzNp0zm.net]: >>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草
851 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 17:53:07.04 ID:8jpdfcc8.net]: >>835
Rustインフルエンサーの成れの果てですなw
852 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:05.70 ID:uSGIT3N+.net]: >>834
せめて用途別のプログラミング順位を挙げてくれ

…単発に言っても無駄か😭
853 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:08:23.00 ID:giVh/goG.net]: Goは２年も続けられるだろうか

大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに

↓を見て気持ち悪さを感じる人には向かない

file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる
854 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:11:15.85 ID:x2y7hFPc.net]: >>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。

起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。
855 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:19:47.46 ID:SZiIKMeC.net]: 「Go」、2月のTIOBE指標で過去最高8位に
https://japan.zdnet.com/article/35215159/
https://japan.zdnet.com/storage/2024/02/13/0ee0eaf7a75e201ad2ee580740569609/240213_tiobe.png
856 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:24:55.60 ID:x2y7hFPc.net]: >>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。
857 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:31:33.80 ID:j4EJcuA3.net]: >>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。
858 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 18:34:16.56 ID:3rKktGL8.net]: >>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題
859 名前：デフォルトの名無しさん [2024/02/15(木) 19:40:03.38 ID:TrooctNX.net]: 50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか
860 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 19:52:43.98 ID:flxKbqvK.net]: >>843
cargo fix --edition
のあるRustは至れり尽くせりだよ
861 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:00:49.77 ID:nijJOd3e.net]: >>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている
862 名前：デフォルトの名無しさん [2024/02/15(木) 20:11:12.94 ID:Zy70aZMD.net]: じゃあもうRustで良いじゃん
863 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 20:27:48.49 ID:Y7OgkdHD.net]: CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター
864 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:27:00.96 ID:MX4y8Eg+.net]: >>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ
865 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 22:56:46.83 ID:x2y7hFPc.net]: C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。
866 名前：デフォルトの名無しさん [2024/02/15(木) 23:13:05.86 ID:17JkefKn.net]: llvmも実装はc++だし。
867 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:33:02.83 ID:CqGYBNeH.net]: >>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる

しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために
868 名前：デフォルトの名無しさん mailto:sage [2024/02/15(木) 23:44:16.83 ID:x2y7hFPc.net]: >>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが
869 名前：デフォルトの名無しさん [2024/02/15(木) 23:57:58.06 ID:m2l7AKkd.net]: 一般人と同等の読解力を複オジに期待しないこと
870 名前：デフォルトの名無しさん [2024/02/16(金) 01:17:00.51 ID:2uzjzXJf.net]: cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜
871 名前：デフォルトの名無しさん [2024/02/16(金) 02:58:58.82 ID:T31Boec7.net]: >>853
名前が同じならなんでも良い…… ってこと！？
872 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 05:29:44.45 ID:VnZfCvN7.net]: >>856
「規格が同じなら」ということだよ。

c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。
873 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 06:06:29.14 ID:VMcEA5aE.net]: RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く
874 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:06.12 ID:T31Boec7.net]: >>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん
875 名前：デフォルトの名無しさん [2024/02/16(金) 08:50:57.44 ID:T31Boec7.net]: 規格から機能ごと消えるんならよう
876 名前：デフォルトの名無しさん mailto:sage [2024/02/16(金) 08:57:09.07 ID:MpEo3rxP.net]: >>859
消してないけど何いってんの？
877 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:36:35.11 ID:pKHDV/cx.net]: ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？
878 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 07:58:38.87 ID:y2U3e6uM.net]: mojo vs rustでmojo公式とnetflix天才とRust本著者で盛り上がっている
https://www.youtube.com/watch?v=MDblUyz0PtQ

>>814,835
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ
879 名前：デフォルトの名無しさん [2024/02/17(土) 08:38:43.36 ID:P+bU7/QC.net]: >>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw
880 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:31:52.42 ID:/wuPDCL7.net]: >>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲
881 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 11:55:10.10 ID:wfN7KjH7.net]: Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。
882 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:54:06.77 ID:p6Fewl3N.net]: >>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ
883 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 12:58:21.47 ID:p6Fewl3N.net]: >>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる
884 名前：デフォルトの名無しさん [2024/02/17(土) 17:40:44.30 ID:SxaDWram.net]: >>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ

公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル
885 名前：デフォルトの名無しさん [2024/02/17(土) 18:56:01.48 ID:bc7xcSj4.net]: Netflixの天才がいかがでしたかブログレベルの動画を出すとは
886 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:01:49.62 ID:hd6B0gbf.net]: >>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな
887 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 19:07:25.89 ID:1+LtKHMi.net]: 以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい
888 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 20:11:15.92 ID:lHr0QJnq.net]: SIMDが効くような恣意的なベンチだしな
889 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:00:37.77 ID:QWthdRCX.net]: でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター
890 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:16:16.12 ID:lHr0QJnq.net]: DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる
891 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 21:40:36.38 ID:WeOJL5ES.net]: え？　Rustって末尾最適化できんの？
892 名前：デフォルトの名無しさん mailto:sage [2024/02/17(土) 23:56:23.75 ID:uU5eCENW.net]: Rust Reserved keywords

KW_ABSTRACT : abstract
KW_BECOME : become
KW_BOX : box
KW_DO : do
KW_FINAL : final
KW_MACRO : macro
KW_OVERRIDE : override
KW_PRIV : priv
KW_TRY : try
KW_TYPEOF : typeof
KW_UNSIZED : unsized
KW_VIRTUAL : virtual
KW_YIELD : yield
893 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 09:43:13.97 ID:2fU6EVDD.net]: >>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが...
894 名前：デフォルトの名無しさん [2024/02/18(日) 10:23:17.76 ID:8VIVYK48.net]: あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない
895 名前：デフォルトの名無しさん [2024/02/18(日) 10:24:13.10 ID:8VIVYK48.net]: ちなみにSIMD云々は本質じゃないよ
896 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:33:07.03 ID:diN1NxZN.net]: >>879が3倍速いRustコードを出すってよ
897 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 10:46:23.01 ID:fnRzA2e2.net]: これはGoの方が速いんじゃないか？
898 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:13:09.56 ID:NoFg1fuK.net]: GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い
899 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:27:28.89 ID:YdXgtYKq.net]: >>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である
900 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 11:36:55.83 ID:a/PaZk8n.net]: そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい
901 名前：デフォルトの名無しさん mailto:sage [2024/02/18(日) 12:18:39.29 ID:Wi99yBdV.net]: 20年後にRustを懐かしむスレはここですか？
902 名前：デフォルトの名無しさん [2024/02/18(日) 14:55:22.54 ID:LhS8zjp4.net]: 20年後には流石にもっと良い言語が登場して流行っていることを期待している
903 名前：デフォルトの名無しさん [2024/02/18(日) 15:22:23.80 ID:L2mk1x1a.net]: >>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って
904 名前：デフォルトの名無しさん [2024/02/18(日) 15:34:23.48 ID:CKqOMEmo.net]: >>888
MAUIくん！病室に戻るんだ！
905 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 09:27:30.10 ID:JlpPRp2V.net]: >>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする
906 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 10:19:49.07 ID:j7eyydGe.net]: 普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。
907 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 11:58:45.15 ID:r1DaNm3S.net]: 既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな
908 名前：デフォルトの名無しさん [2024/02/19(月) 12:07:19.13 ID:BnjhEPJH.net]: 自分は何も出来ない無才なのによく言うわw
909 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 14:11:02.99 ID:JlpPRp2V.net]: C#→Javaのビミョーなところを直す
Delphi�
910 名前：ｨPascalのビミョーなところを直す TypeScript→JSに型付け []: [ここ壊れてます]
911 名前：デフォルトの名無しさん [2024/02/19(月) 14:41:59.29 ID:FfoO1n86.net]: Rustのビミョーなところを直して欲しい
912 名前：デフォルトの名無しさん [2024/02/19(月) 15:33:58.75 ID:BnjhEPJH.net]: R#だすかー
913 名前：デフォルトの名無しさん [2024/02/19(月) 16:37:49.01 ID:pyxz0P7h.net]: Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな

広報+コントリビューター+社外との政治的調整役
914 名前：デフォルトの名無しさん [2024/02/19(月) 18:10:38.68 ID:VthC7yJG.net]: R#とか絶対統計処理用の言語じゃん
915 名前：デフォルトの名無しさん [2024/02/19(月) 18:20:06.89 ID:BnjhEPJH.net]: そうだな
じゃあRustyNailって名前にするか
916 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:38:07.38 ID:j7eyydGe.net]: ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。
917 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 18:50:17.05 ID:JlpPRp2V.net]: 割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft

この流れは確かにある
918 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:05:38.11 ID:gidehIA9.net]: GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている
919 名前：デフォルトの名無しさん [2024/02/19(月) 20:34:12.24 ID:VthC7yJG.net]: Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う
920 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:55:09.09 ID:WSW9DaUh.net]: 代替の芽が今ないから早くて十数年以上先
MojoはPythonベースで関心が数値計算に向いていて違う
921 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 20:57:44.38 ID:34j+4tJw.net]: Netflixの天才は2年かけて右端の住人になったのか
https://pbs.twimg.com/media/GDa2G6iWIAAsyh3.jpg:orig

これからは目立った実績が無いのにRust歴が長いと
型〇ナニーで時間溶かしてると認定される
922 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:23:20.71 ID:MW9zngaI.net]: >>905
Go？
Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ
923 名前：デフォルトの名無しさん [2024/02/19(月) 21:38:55.37 ID:BnjhEPJH.net]: >>906
結局さ一周回ってAdaで良いんじゃ？
924 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 21:46:39.06 ID:VDl5KQ6V.net]: オーガスタちゃんが平伏せと命令する言語？
925 名前：デフォルトの名無しさん [2024/02/19(月) 22:19:23.32 ID:hvnIqBoW.net]: Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね
926 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 22:41:42.37 ID:+OQMy10I.net]: >>909
Rustバイナリが小さい
tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB
927 名前：デフォルトの名無しさん mailto:sage [2024/02/19(月) 23:17:36.45 ID:aeOZND98.net]: サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい
928 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 03:09:16.36 ID:sgoVzbhC.net]: Rustってcargo buildとかやると通信量結構えげつない
929 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:39:03.07 ID:VuVDzPkr.net]: 依存関係があるライブラリをダウンロードすれば Rust に限らず
それなりにたいくさんひっついてくるのはよくあること。
930 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 08:51:21.95 ID:HobPlk1l.net]: C++でビルドする前にapt-getしてね、ってのも同じことだしな
931 名前：デフォルトの名無しさん [2024/02/20(火) 09:54:42.94 ID:avQkuhyK.net]: Rustだと依存ライブラリの数が桁違いに多くなるのが原因
932 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 10:20:25.82 ID:VuVDzPkr.net]: お前それ、 JavaScript の前でも同じこと言えるの？
933 名前：デフォルトの名無しさん [2024/02/20(火) 10:20:33.45 ID:kmanQ674.net]: >>903
その通り
Rustの次に期待
934 名前：デフォルトの名無しさん [2024/02/20(火) 13:00:59.06 ID:MPPpoDC+.net]: >>907
ブロックが波カッコだったらなぁと思ったことある。
935 名前：デフォルトの名無しさん [2024/02/20(火) 13:46:52.53 ID:sgoVzbhC.net]: 一回DLしたパッケージOSにキャッシュしてくれればいいんだけど
そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか
936 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:05:25.22 ID:VuVDzPkr.net]: >>919
えっ、普通にキャッシュしますが……。
937 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:18:44.11 ID:YaBXE8T+.net]: >>919
1回しかダウンロードしない
その後はそのキャッシュを用いる
938 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 14:47:39.06 ID:NZma60kC.net]: それよりディスク使いすぎだろ
ビルドの中間生成物が簡単にギガ単位になる
939 名前：デフォルトの名無しさん [2024/02/20(火) 15:44:30.40 ID:s70xdtq8.net]: >>922
それな
複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ
940 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 15:54:29.36 ID:VuVDzPkr.net]: 大きなライブラリは動的リンクすることにしてもいいけど、
そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。
どうやったってどこかに負担はかかるならストレージさえあれば
だいたい解決ってほうがいいという戦略なんだろ。
941 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:32:02.94 ID:NZma60kC.net]: Rustほどディスク使う言語他にあるの？
桁違いに多いと思うんだが
942 名前：デフォルトの名無しさん [2024/02/20(火) 18:32:44.23 ID:pzacWR0B.net]: ディスクはまあTB行かなければ何をやっても良いわ
943 名前：デフォルトの名無しさん [2024/02/20(火) 18:46:34.01 ID:2x98KEBQ.net]: ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね
用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ
944 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 18:56:04.80 ID:qhUDP5tY.net]: Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。
soとかdllとかjarみたいなの、あまり信頼したくないというか。
945 名前：デフォルトの名無しさん [2024/02/20(火) 1 ]: [ここ壊れてます]
946 名前：9:01:23.73 ID:aUCxPGU2.net mailto: Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな []: [ここ壊れてます]
947 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 19:12:55.50 ID:HobPlk1l.net]: so使ってsymbol not foundとかよくあるしな
基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい
しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし
結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする
948 名前：デフォルトの名無しさん [2024/02/20(火) 19:56:43.04 ID:hRyg00SZ.net]: soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い
949 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:07:01.59 ID:+of8n4/M.net]: 確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね
ただその場合でもABIが不安定なのはどうしょうもないから
Rustと同じく手元で全部コンパイルする方式になったと思うけど
950 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 20:11:30.03 ID:VuVDzPkr.net]: Cargo 風の管理をする C++ 用パッケージマネージャはある。
最初からそのパッケージマネージャ用に構成してくれてないと
なかなか素直にはビルドできないことに変わりないんだけど。
パッケージマネージャが優秀でも C++ 世界では
「統一されていない」ことが面倒くささになってる。
951 名前：デフォルトの名無しさん [2024/02/20(火) 21:39:15.46 ID:1smOJz8O.net]: そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？
952 名前：デフォルトの名無しさん [2024/02/20(火) 21:43:07.30 ID:BYbBGAeA.net]: NuGetが使いやすいと感じた事がないし、充実していると感じたこともない
953 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 21:59:58.18 ID:VuVDzPkr.net]: >>934
dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので
コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。
いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど
それが最強かというと状況によるんじゃないの。
954 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:14:04.42 ID:sgoVzbhC.net]: >>921
チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど
955 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:16:27.29 ID:FbkkUU+G.net]: パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな
どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利
956 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:30:04.17 ID:VuVDzPkr.net]: ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。
最悪の場合でもコードへのリンクもあるし。
Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから
Rust で取り入れてくれたのはかなり嬉しい。
957 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:37:39.60 ID:NZma60kC.net]: >>926
いや、スマホでセルフ開発する時に困るだろ？
958 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:45:53.34 ID:VuVDzPkr.net]: >>940
そんなやつはおらんで～～
959 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 22:47:07.61 ID:1CgxDriU.net]: ス、スマホ？
960 名前：デフォルトの名無しさん [2024/02/20(火) 23:05:21.55 ID:YDnp1LJs.net]: procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない

いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね
961 名前：デフォルトの名無しさん mailto:sage [2024/02/20(火) 23:07:55.15 ID:VuVDzPkr.net]: もしスマホで開発する人がいたとしても
レンタルサーバに接続して表面上の操作にスマホを使うだけで、
実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。
スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。
962 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 00:35:56.53 ID:ax8uXPdD.net]: 働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな
963 名前：デフォルトの名無しさん [2024/02/21(水) 01:44:30.82 ID:q3i686zw.net]: スマホで開発はむしろ最先端
964 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:17:16.65 ID:cGlapTzK.net]: iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。
最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。
今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。
だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ
965 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 05:44:41.84 ID:cGlapTzK.net]: スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。
Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。
実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。
今後数年間、これらの技術動向から目が離せない状況が続くんだろう。
966 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:28:43.22 ID:/iiJfWDN.net]: ダウンロードしたクレートキャッシュの自動削除はもうすぐ来そう
ビルドキャッシュの自動削除はその後実装予定っぽい
https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning.html
967 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 08:31:36.21 ID:/iiJfWDN.net]: グローバルなビルドキャッシュ共有の話も予定には挙がってるね
968 名前：デフォルトの名無しさん [2024/02/21(水) 09:05:07.84 ID:33Eh81yS.net]: >>934
何を基準でさいつよかの定義による

デスクトップ
Web
バックエンド
iOS/Android
ゲーム

とC#だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC#使えれば何でも作れるという意味ではさいつよ
969 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 09:19:16.71 ID:VUY6mIOu.net]: >>951
.netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う
970 名前：デフォルトの名無しさん [2024/02/21(水) 10:25:34.81 ID:ygn/feiE.net]: デスクトップ
Web
バックエンド
iOS/Android
ゲーム

とC言語だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC言語使えれば何でも作れるという意味ではさいつよ
チューリング完全なので
971 名前：デフォルトの名無しさん [2024/02/21(水) 10:33:55.14 ID:3B94ePzU.net]: 無能なやつほどゴールデンハンマー症候群に罹患しやすい
972 名前：デフォルトの名無しさん [2024/02/21(水) 10:37:42.60 ID:33Eh81yS.net]: >>953
嘘ばっかりだなw
973 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:23:52.50 ID:FRHKNAr+.net]: >>949
さすがに問題として認識はしてたんだな
スマホセルフ開発の日は近い
974 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 12:50:43.67 ID:ax8uXPdD.net]: マジでスマホしか持ってないの？
クソワロタ
975 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 13:41:48.13 ID:s/93fWsg.net]: ウェアラブル系の機器には失望した。
どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。
976 名前：デフォルトの名無しさん [2024/02/21(水) 14:32:00.13 ID:T2E+AzfY.net]: >>954
同意
977 名前：デフォルトの名無しさん [2024/02/21(水) 15:10:22.61 ID:KvtS9dqN.net]: >>958
背もたれ付きベッド
978 名前：デフォルトの名無しさん [2024/02/21(水) 15:11:12.28 ID:KvtS9dqN.net]: >>953
Rustはチューリング安全だぞ
979 名前：デフォルトの名無しさん [2024/02/21(水) 16:06:34.40 ID:RjxZ1GsP.net]: >>957
働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww
980 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:15:10.41 ID:cGlapTzK.net]: >>960
ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカムマイアイ2』(OrCam MyEye 2)は、
イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。
これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。
ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。
981 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:30:25.40 ID:vYwp44u6.net]: 表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ
982 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:47:28.48 ID:OHlXXLmE.net]: いくらなんでもスマホでコーデングはせんやろ
983 名前：デフォルトの名無しさん [2024/02/21(水) 16:49:23.05 ID:1mshJDzd.net]: 寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん
984 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 16:54:05.86 ID:s/93fWsg.net]: 性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。
無理。
985 名前：デフォルトの名無しさん mailto:sage [2024/02/21(水) 18:17:59.27 ID:ax8uXPdD.net]: >>962
いやお前に当てはめてるだけだぞ
何言ってんだ？
986 名前：デフォルトの名無しさん [2024/02/21(水) 21:37:40.46 ID:4F0o6gVI.net]: はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた
987 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 16:00:18.09 ID:o0M/RgFs.net]: >>969
新スレ立ったときに名前欄に入力するのを忘れてたままやな
988 名前：デフォルトの名無しさん mailto:sage [2024/02/22(木) 23:42:55.14 ID:1e40BABA.net]: >>949
毎晩ならその機能もう使えるのか
989 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:46.18 ID:vPqrWVzU.net]: 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。
990 名前：デフォルトの名無しさん [2024/02/23(金) 12:05:51.79 ID:vPqrWVzU.net]: 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。
991 名前：デフォルトの名無しさん [2024/02/23(金) 15:12:44.34 ID:z6SHyxko.net]: iPadでXcode使えるからそれで遊んでみれば
992 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:20:09.67 ID:CheDQupm.net]: Rustが使えないとな
993 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 15:21:05.22 ID:jTrUecQ5.net]: クソスレまで立てちゃってw
素直に中古のノートPCでも買えよ
994 名前：デフォルトの名無しさん [2024/02/23(金) 16:04:17.89 ID:02Kw336h.net]: traitの種類多すぎて把握しきれん
使い分けもようわからんし
995 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 16:18:25.67 ID:NJWNbZ5N.net]: Pythonのpep20みたいなってRustにもあるの？
996 名前：デフォルトの名無しさん [2024/02/23(金) 16:32:06.33 ID:eHVJk53E.net]: スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある
1つはモバイルOS上で実行させる小さなユーティリティを作るため
だいたいlinux emulatorみたいなアプリ内環境で稼働させる
もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため

前者はスマホだけで作るやつもいるにはいるが少数派
なので今のところはメイン開発環境は別に用意してるのが大半
997 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:15:31.94 ID:kgcjkDLJ.net]: PEP20って何だよと思ったらあのウンコポエムだった
998 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:26:44.63 ID:kgcjkDLJ.net]: 次スレタイトル間違えてしまったのですまんが
999 名前：誰か立て直してくれ 規制食らってもう立てられなくなった []: [ここ壊れてます]
1000 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:35:21.56 ID:CheDQupm.net]: >>977
traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい
structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい
そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる
1001 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:38:39.47 ID:CheDQupm.net]: 次スレ
Rust part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/
1002 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:45:54.27 ID:kgcjkDLJ.net]: >>983
ありがとう
1003 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 17:51:32.20 ID:jYYzpIEX.net]: >>978
こういうのをまとめようとはしているよ
https://smallcultfollowing.com/babysteps/blog/2023/12/07/rust-design-axioms/
1004 名前：デフォルトの名無しさん [2024/02/23(金) 20:10:18.94 ID:1IK2X2kO.net]: >>982
FromとかAsRefとかDerefとかの時点でもうようわからんぜ
1005 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 22:42:10.08 ID:oukljDwS.net]: Fromは汎用的な変換だよ
変換に失敗する可能性を含む時はTryFromを使う

AsRefは参照から(別型の)参照への読み替え変換
コストがかからない場合が対象
コストがかかるものはFromを使う

Derefは変換ではなく演算子
変換は複数の型への変換を実装できるけど
演算子なので各型で決められた一つの型へderefできる
&T→T
Box<T>→T
Rc<T>→T
Vec<T>→[T]
String→str
PathBuf→Path
など
1006 名前：デフォルトの名無しさん [2024/02/23(金) 23:50:59.87 ID:1IK2X2kO.net]: あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね
1007 名前：デフォルトの名無しさん mailto:sage [2024/02/23(金) 23:59:41.76 ID:hX/YHnPg.net]: >>988
どの分野のどんな話でも基本パターンの学習による慣れ
問題

match std::env::args().XXXXX {
　Some("yes") => ...,
　Some("no") => ...,
　_ => ..., // エラー
}
1008 名前：デフォルトの名無しさん [2024/02/24(土) 02:12:39.95 ID:YQ3M0cmx.net]: 梅
1009 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 04:00:00.27 ID:felFEjYK.net]: 「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。
常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。
実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。
1010 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 12:21:57.67 ID:lhpjpr9r.net]: >>987
Derefは演算子でも利用されるがDerefそのものが演算子(や演算子の実装)というわけではない
Type Coercionというのは型変換(Type Conversion)の一種なのでDerefは変換ではないというのもやや言い過ぎ

各型で決められた一つの型にderefされるのは演算子だからという理由ではなくて
Derefはスマートポインタが包んでる値へのアクセスを便利にするために用意されたものだからderef先の型は自然と一つに決まるため(>>733)

&T→TはDerefの役割ではない
1011 名前：デフォルトの名無しさん [2024/02/24(土) 12:57:43.72 ID:Sbx59RJL.net]: AsRefとBorrowは未だにわからんなあ
調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる
1012 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:08.04 ID:Q2pRspv0.net]: 埋
1013 名前：デフォルトの名無しさん [2024/02/24(土) 13:58:23.94 ID:Q2pRspv0.net]: 生め
1014 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:40.99 ID:Q2pRspv0.net]: 、埋め
1015 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:46.56 ID:Q2pRspv0.net]: ！埋め
1016 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:58:52.17 ID:Q2pRspv0.net]: ？埋め
1017 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:00.55 ID:Q2pRspv0.net]: ○埋め
1018 名前：デフォルトの名無しさん mailto:sage [2024/02/24(土) 13:59:07.65 ID:Q2pRspv0.net]: ～埋め
1019 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 34日 14時間 37分 28秒
1020 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef