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/
2 名前：デフォルトの名無しさん mailto:sage [2024/01/20(土) 23:30:24.59 ID:YXP1l1jf.net]: Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust async book (日本語版)
https://async-book-ja.netlify.app/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/
Rust Design Patterns (日本語版)
https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651
https://qiita.com/Yappii_111/items/654717e6a6a980722189
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
3 名前：デフォルトの名無しさん mailto:sage [2024/01/20(土) 23:30:59.71 ID:YXP1l1jf.net]: Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
4 名前： https://doc.rust-lang.org/std/ Rust rustc Book https://doc.rust-lang.org/rustc/ Rust rustdoc Book https://doc.rust-lang.org/rustdoc/ Rust rustup Book https://rust-lang.github.io/rustup/ Rust Cargo Book https://doc.rust-lang.org/cargo/ Rust unstable Book https://doc.rust-lang.org/nightly/unstable-book/ Rust macro Book https://danielkeep.github.io/tlborm/book/ Rust CLI (Command Line Interface) apps Book https://rust-cli.github.io/book/ Rust Future Book https://cfsamson.github.io/books-futures-explained/ Rust async-std Book https://book.async.rs/ Rust tokio Book https://tokio.rs/tokio/tutorial Rust serde Book https://serde.rs/ []: [ここ壊れてます]
5 名前：デフォルトの名無しさん mailto:sage [2024/01/21(日) 19:52:38.28 ID:/dcZ0aWP.net]: Rustを理解していく順序　(文法以外)
ownership　
↓
lifetime　(これ以前でも参照を持ち越さない範囲で可)
↓
trait　(これ以前でもライブラリ既存traitメソッド使用は可)
generic　(これ以前でもライブラリ既存genericメソッド使用は可)
↓
macro　(これ以前でも既存macro使用は可)
async　(これ以前でも同期で使用可)
↓
unsafe　(ほとんどのことはunsafeを使わずに可能)

もしunsafeを使わないと効率よく実装できない安全なパターンを見つけて、
かつ、それが既存ライブラリに存在しない新たなパターンならば、
それは大発見だから皆のためにそのcrateを公開すべし
6 名前：デフォルトの名無しさん mailto:sage [2024/01/21(日) 20:27:09.29 ID:D3jVm/Ct.net]: 今、refと&で混乱してるとこ！
7 名前：デフォルトの名無しさん [2024/01/21(日) 20:58:34.51 ID:RjmgKxew.net]: オーナーシップとかAIにやらせればOK
意識して時間割く必要なし
8 名前：デフォルトの名無しさん mailto:sage [2024/01/21(日) 21:23:48.87 ID:/dcZ0aWP.net]: >>5
パターンマッチングはCopy実装型はcopyされてそれ以外はmoveされる

copyやmoveを避けるには
マッチング対象を参照にすれば
全て参照として受け取れる

しかしある部分はcopyである部分は参照で受け取りたいことがよくある
(例えば数値とStringで構成されてる場合)
その時は参照で受け取りたい部分のみrefを付けるとそこは参照で受け取れる
9 名前：デフォルトの名無しさん [2024/01/21(日) 21:33:08.24 ID:LhOQKlqN.net]: >>5
refはbind by reference
左辺(相当)でのみ使う(binding生成時のみ)
右辺で&を使うのと同じだけど右辺で&を指定できない場面で使う

&を左辺で使うとパターンマッチでデリファレンス
右辺で*を使うのと基本同じ
10 名前：デフォルトの名無しさん mailto:sage [2024/01/21(日) 22:36:05.82 ID:/n8yifEU.net]: >>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990
一応知らない人のために書いておくけど

「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる
特定の機能導入のタイミングでコードが発見されたけど、
「Rustの仕様バグ」だと認識されていて直せない

>>4
そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ

最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから
たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな
(githubの議論でも矮小化して放置)
気を付けろよ

https://github.com/rust-lang/rust/issues/114936
11 名前：デフォルトの名無しさん mailto:sage [2024/01/21(日) 22:51:42.90 ID:w4jDa8WO.net]: >>9
無意味な揚げ足取りをしてRustを叩きたい人はアンチスレへ
棲み分けしてください

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/
12 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 00:47:14.54 ID:jqH5vdYX.net]: 仕様バグだから直せないじゃなくて
厳密なチェックをする実装は0から作ったほうが早いから
今使ってる確率的(笑)な実装は変更しないんだよね？
13 名前：デフォルトの名無しさん [2024/01/22(月) 03:17:34.54 ID:laN06gwL.net]: これマジ？　どれくらいの確率で踏むんけ？　コンパイルのバクはケアしたくないなあ
14 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 04:28:43.80 ID:DrvqbiCd.net]: >>12
意図的にvarianceの穴を突く無意味なコードを書かないと発生しないため>>9は無害
15 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 09:21:43.10 ID:k43UrEGh.net]: >>9
こんなコンパイラの脆弱性を突くようなコードを普通なら書かない定期
16 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 21:22:44.12 ID:m6FRVxec.net]: >>9は9年前の2015年から既知の有名なパターン
意味のあるプログラミングで絶対に踏むことはないため害はない
その特殊ケースに対応するデメリットの方が大きいため対策されていない
それらを踏まえたうえでIT大手が揃ってRustを採用しRust Foundationも設立された
17 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 21:31:04.02 ID:l2He84BH.net]: 9のコードの意味が理解できないんだが何が問題なのか説明してくれ
18 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 22:53:37.35 ID:6ImN7JeY.net]: c++のテンプレートはチューリングマシンだから
無限ループを起こせるのは仕様の欠陥がどうか聞きたい
19 名前：デフォルトの名無しさん [2024/01/22(月) 23:05:33.08 ID:YajFhzWL.net]: f: impl for<'s> FnOnce(&'s str) -> (&'static str, [&'static &'s (); 0])　の説明だけ。
ライフタイム 's の str を引数にして、&'static str 型と、[&'static &'s (); 0] 型のタプルを返すクロージャが f ということ。
[&'static &'s (); 0] は &'static &'s () 型の長さ 0 の配列。
&'static &'s () は、ユニット型() のライフタイム 's の参照のライフタイム 'static の参照。

この &'static &'s () の部分で変なことが起きてそうと言っとるな。
20 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 23:14:04.77 ID:T1sqP3ZB.net]: >>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。
21 名前：デフォルトの名無しさん mailto:sage [2024/01/22(月) 23:41:39.76 ID:NA4FP1NO.net]: >>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん
22 名前：デフォルトの名無しさん mailto:sage [2024/01/23(火) 00:35:34.27 ID:AizsfBYE.net]: >>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい
23 名前：デフォルトの名無しさん mailto:sage [2024/01/25(木) 23:09:32.35 ID:iPN7/qe+.net]: 安全にこれで&'staticへ変換できる

fn to_static_str(s: &str) -> &'static str {
　　s.to_owned().leak()
}
24 名前：デフォルトの名無しさん mailto:sage [2024/01/26(金) 23:31:43.19 ID:ZBdWgzp4.net]: 最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな
25 名前：デフォルトの名無しさん mailto:sage [2024/01/27(土) 23:34:17.17 ID:kvD8ZR3g.net]: >>22
それ&'static strではなく&'static mut strを返してもええねんで
26 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 02:18:12.19 ID:tZGISO28.net]: >>22
leakって安全なの？
27 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 04:27:59.88 ID:2343IlJN.net]: leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ
28 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 08:32:52.16 ID:hRRbWEE/.net]: >>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。
29 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 12:34:08.20 ID:tZGISO28.net]: leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの
30 名前：デフォルトの名無しさん [2024/01/28(日) 13:17:17.43 ID:lA5rY1V0.net]: >>28
原文は何て書いてるのさ
31 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 14:30:03.90 ID:WlHw4mUK.net]: 期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない
32 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 15:17:37.40 ID:2343IlJN.net]: >>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる

一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない
33 名前：デフォルトの名無しさん mailto:sage [2024/01/28(日) 18:26:28.82 ID:WlHw4mUK.net]: メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない
34 名前：デフォルトの名無しさん mailto:sage [2024/01/29(月) 23:08:47.69 ID:GnLHDaEQ.net]: メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第
35 名前：デフォルトの名無しさん mailto:sage [2024/01/30(火) 02:10:08.22 ID:gYzmItMj.net]: 多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる
36 名前：デフォルトの名無しさん mailto:sage [2024/01/30(火) 06:01:38.95 ID:lXERqUpG.net]: きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね
37 名前：デフォルトの名無しさん mailto:sage [2024/01/30(火) 07:11:49.27 ID:g++Pj77W.net]: >>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している
38 名前：デフォルトの名無しさん mailto:sage [2024/01/30(火) 11:19:29.95 ID:LgX6lgq1.net]: それくらいできてくれないと習得に対して割に合わない
39 名前：デフォルトの名無しさん mailto:sage [2024/01/30(火) 23:08:46.90 ID:shd55QRp.net]: >>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる
40 名前：デフォルトの名無しさん mailto:sage [2024/01/31(水) 05:41:08.45 ID:XSmS7DeM.net]: Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される
41 名前：デフォルトの名無しさん mailto:sage [2024/01/31(水) 22:24:17.87 ID:rU+aRD+l.net]: スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね
42 名前：デフォルトの名無しさん [2024/02/01(木) 16:48:45.42 ID:ernnY6oF.net]: Microsoft seeks Rust developers to rewrite core C# code
https://www.theregister.com/2024/01/31/microsoft_seeks_rust_developers/

でかいところのバックエンドRust化が増えてきたな
43 名前：デフォルトの名無しさん [2024/02/01(木) 17:28:29.31 ID:xcOmoIH1.net]: しかしRust流行らんな
44 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 19:27:48.94 ID:6WtKOSai.net]: Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね
45 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 20:38:04.52 ID:XOfXRWXD.net]: from C to Rust へのマイグレーションは時間がかかるからしゃあない
46 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 21:16:53.56 ID:E1I2Gvr8.net]: >>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き
47 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 21:44:37.29 ID:Nzd8TkB/.net]: きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない
48 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 21:53:27.11 ID:7aZ9tAiW.net]: 動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない
49 名前：デフォルトの名無しさん [2024/02/01(木) 21:55:25.71 ID:9CL84hYM.net]: Rust、言うほどPythonと比べて手軽でないか？
50 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 22:17:59.13 ID:B5mxz6YT.net]: プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。
51 名前：デフォルトの名無しさん [2024/02/01(木) 22:29:20.68 ID:wp2DoW25.net]: Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ
52 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 22:40:37.81 ID:Nzd8TkB/.net]: Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安
53 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 22:42:10.75 ID:tu2Yd+rZ.net]: >Pythonはやっぱり行列を扱うのに長けてる気がするな

pythonのどこが？numpyがあるだけじゃね。
54 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 22:45:58.52 ID:E1I2Gvr8.net]: PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない
55 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 22:54:05.96 ID:Nzd8TkB/.net]: OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ
56 名前：デフォルトの名無しさん [2024/02/01(木) 23:06:17.91 ID:0Yigz0zQ.net]: 使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと
57 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:13:02.07 ID:iVey9ypb.net]: 各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？
58 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:14:24.05 ID:h0D2/F6d.net]: Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ
59 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:23:51.23 ID:itS/z8tN.net]: プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い
60 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:26:15.91 ID:B5mxz6YT.net]: Ruby もだいぶん長いことバイトコード化すらせずに木を辿るクソ遅い設計だったんだぞ。
でもなあ、使い分けといってもやっぱり慣れたらもうちょっと他の場所でも使いたくなるし、速度の要求も静的検証の要求も出てくる。
今の Ruby は Jit で速くなったし型チェックのサポートも本格的になった。
使い分けは要るがせずにすむならそれに越したこともないんよ。
61 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:26:33.20 ID:8nChHaP8.net]: >>56
そのまま移植はほぼ不可能でしょ
データ構造から設計しなおさらないと
クソコードになりがち
62 名前：デフォルトの名無しさん mailto:sage [2024/02/01(木) 23:33:40.62 ID:B5mxz6YT.net]: C の世界の文字列はゼロ終端やんか。
カーネルのインターフェイスにもその規約がそのまま現れてる。
内部的な設計は Rust 的にしつつも外向きのインターフェイスは変えないように置き換えるなら微妙な変換があらゆるところに出てくるよ。
まあそのへんは適当な専用フレームワークを確立させればたいしたことでもないが、そういう地味なことの積み重ねがいっぱい要るよ。
63 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 00:29:39.63 ID:wYh3cvfE.net]: C/C++からJavaってのはすげー移植しやすかったのよ
その利点はほとんどないと多くの人が気がつくのに20年もかかってしまったけど
64 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 00:36:47.62 ID:iO9F+zBT.net]: >>56
書き直しさえすれば何でもいいというのは大変だろうね
何でもいいというのは嘘で
本当は好き嫌いがあるから
65 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 01:16:00.31 ID:fEMhv+T7.net]: コード移植なんてつまらなくて言語差で面倒なだけ
守るべき仕様さえはっきりしてるならゼロから書いたほうが結果的に早くて質も良くて
66 名前：楽しい []: [ここ壊れてます]
67 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 01:28:41.76 ID:iO9F+zBT.net]: 仕様とか契約とか目的とかは未来を予測する根拠としてはイマイチ科学的でない
68 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 01:38:03.89 ID:ZFQgO+dm.net]: Linux だとバイナリ互換性もかなり大事にしてる。
(Windows ほどじゃないが。)
仕様として明文化してない挙動に依存するアプリケーションであっても今まで動いていたものが動かなくなるのは良くないという方針。
「守るべき仕様がはっきりしていれば」という前提がなりたたないから困るんだよ。
そしてそれはよくあること。
69 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 01:40:32.02 ID:fEMhv+T7.net]: ときどき仕様も要件定義もはっきりせず発注者が把握できていないものの言語移植ケースがあるがその仕事を引き受けないほうがいい
バグらしきもの含めて現存コードと同じ動作をするよう求めてくるためムダな面倒に精神力が奪われる
70 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 11:04:47.16 ID:VI0tbigR.net]: 仕様さえ守っていればいいみたいな考えに従うと最近はお役所系でもちらほら見るクローム以外を
排除する極右Webサイトが出来上がったりするんだろうな。発注側でも受注側でもね
71 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 11:10:52.47 ID:BQKaaqcl.net]: ちゃんと充分な調査費用も出るならやらんでもないけどな。
大きなシステムの一部をリライトする場合には一から作る場合より数倍のコストがかかっても
全体をやり直すよりはマシだから「同じもの」を求めるのはそれなりに合理性がある。
全部をリプレイスするのに前と同じという要求するやつがいたら、
前と同じがいいならそのまま使っとけやという気持ちになる。
72 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 11:38:15.79 ID:cSpiCBqt.net]: C/C++→Rust　安全化とそのデバッグ開発効率化
C/C++以外→Rust　高速化と省メモリ化

これらの恩恵があるため
安全でないことによるバグ発生で困っているならC/C++→Rustを
CPUメモリリソース削減が求められてあるならC/C++以外→Rustを
たとえ同じ仕様のままでもやる意味が生じる
73 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 12:27:55.82 ID:ndCfDt6c.net]: >>70
費用対効果考えると厳しいな。

c++のプロジェクトをRustに切り替えるよりか、コーティング規約組んでlint用意して強制したほうが効果高そう。
既存コードの扱いが難しいけど。
74 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 13:20:50.14 ID:ujySZ5KU.net]: Webアプリ用途でもAxumやActixがフレームワークとして十分使いやすいから、もっとRustは普及していい
75 名前：デフォルトの名無しさん [2024/02/02(金) 13:32:21.68 ID:gukHO/4I.net]: c++ から rust に移すなら、その前に c++ コードのリファクタリングとしてmove使用コードに直すだろうし、
それやったらもうそれで良くね？ってなると思うわな。
76 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 15:02:39.89 ID:SOk2CQ22.net]: 言語移植はそのうちAIがなんとかしてくれるんじゃなかろうか
77 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 17:43:40.65 ID:wsXMOW5f.net]: 所有権があるから GC 言語からの移行でも安全になる恩恵はあるんだよなぁ。

ほんとエポックメイキングな言語だよ。
78 名前：デフォルトの名無しさん [2024/02/02(金) 19:12:44.91 ID:6TGLHO8E.net]: rustの最大のメリットは、絶対では無いけどコンパイルさえ通ってれば他人のクソコードに悩まされずに済む点じゃないかね。
79 名前：デフォルトの名無しさん [2024/02/02(金) 21:11:58.02 ID:K0BmHg5g.net]: >>76
なんで悩まされないの？
80 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 21:33:43.48 ID:ya0nDY0I.net]: Rustでも糞コード見かける
たとえば非常に単純な例でいうと元の部分strを返せば済むのにString作っちゃうなど無駄にヒープ使ってしまうケース
でも見抜きやすく手直しもしやすい
81 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 21:34:56.76 ID:ya0nDY0I.net]: Rust以外でよく見かけるのはど
こで書き換わっているかわかりにくく副作用や競合が心配なケース
Rustではデータ競合が起きないしグローバル変数も制限があるためこの手の類には悩まされない
82 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:24:30.77 ID:BZlEVlBD.net]: メリットが欲しいと思ったことはないな
新しいジャンルで唯一の選択肢なのでメリットの大きさを比較する必要がない
異なるジャンルでは比較する意味がわからない
83 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:27:27.20 ID:ASeaHMD6.net]: >>78
1周回ってString返したほうが良くなる状況もあるからそんなに単純じゃないよ
84 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:29:00.17 ID:ASeaHMD6.net]: >メリットが欲しいと思ったことはないな
誰もメリットが欲しいかどうかについては話してないよｗ
85 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:34:00.04 ID:ya0nDY0I.net]: >>81
それは絶対にない
部分str返しで済むなら必ずそうすべき
それを返された側がString化が必要な時のみ行なう
86 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:36:34.16 ID:BZlEVlBD.net]: 欲しくないものを供給している可能性を誰も想定していないのか
87 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:47:15.09 ID:P1ceRtbI.net]: わかりやすいのがstr.trim()かな
前後のスペースを取り除く関数だけど当然Stringではなくstrの一部分を返す
Stringがほしい人はstr.trim().to_string()
88 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:52:35.98 ID:SRUTe3RO.net]: >>85
欲しい人にもそうでない人にも対応できるように&strがベストとは思わんか？
89 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 22:55:20.18 ID:P1ceRtbI.net]: >>86
同じ主張だよ
str返しが可能ならStringを返してはいけない
slice返しが可能ならVecを返してはいけない
90 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 23:19:45.92 ID:BZlEVlBD.net]: 上書きされる前に別の場所にコピーした方が比較的安全というメリットが消えた
Rustが消した
91 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 23:26:54.37 ID:ya0nDY0I.net]: >>88
Rust以外ではいつ書き換えられたりor解放されたりするかわからないから
安全なプログラミングということで(無駄になる恐れもあるけど)コピーしておく安全策をとることがあった

Rustでは知らぬ間に書き換えられたりor解放されたりすることはないので
安全策を保ったままで無駄なコピーが不要となった
92 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 23:26:59.82 ID:9Dc3A0qD.net]: Stringを使うことで無駄に専有されるヒープメモリはそこまで悪に感じないわ
カーネル作ってるわけでも競技やってるわけでもないんだったらね
可読性のために型を統一させるほうを優先する
93 名前：デフォルトの名無しさん mailto:sage [2024/02/02(金) 23:34:55.21 ID:v5+jJWMk.net]: >>90
主張がよくわかりません
&strを渡せば済むところをString渡しで統一したりしてるのですか？
それで可読性が上がるとは思えません
94 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 00:06:15.17 ID:zqTPQxFe.net]: >>90
そのためにムダにto_string()やそのclone()をするのは間違い
他の言語やスクリプト言語ですらそんな酷いことは行われずにコピーオンライトやインターン化でムダを防いでいる
Rustではまずは&strで行ける範囲は&strで行き次にCow併用そして同じ中身のStringが複数できるならstring_cacheなどでインターン化など
95 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 00:06:54.99 ID:26gTKyDM.net]: C++でもstring_viewとstringは使い分けるぞ
96 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 00:39:47.95 ID:x4y7pcy2.net]: &strでいいなら&strで返すのが基本だけどプログラム全体を見たときにStringで返したほうがものすごくコードを単純にできる場合がある
アロケーションコストが全く問題にならない状況であれば&strに固執する必要はない
無駄なヒープアロケーションは増えるけど違う観点の無駄を削減してる
トレードオフだよ

型を統一するって話はよくわからんけど
97 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 00:41:39.18 ID:26gTKyDM.net]: そこ気にしないなら普通にスクリプト言語でも使っとけば良いと思うよ
98 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 00:44:03.79 ID:zqTPQxFe.net]: >>94
そんな例は起きない
strを返された側でString化が必要な時のみするのがベスト
99 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 05:44:40.82 ID:/t14gmUC.net]: >>96
そりゃベストはそうだろうけどさ…
c++で言うchar型で良いところをわざわざstdのStringを使うなって話でしょ？
動的メモリ確保になってようがその程度の誤差くらい動けばどっちでもいいわ…
100 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 06:03:57.16 ID:HSW3HPjS.net]: >>95
Rustから一気にスクリプト言語は飛躍しすぎだからスクリプト言語より先にガべコレ付き言語を薦めてくれ
ガべコレ付き言語はヒープメモリを気にしない人にはおすすめだよ
101 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 06:28:46.54 ID:zqTPQxFe.net]: >>97
文字列だけでなく一般的な話
部分スライスを返せば済むところをわざわざVecにして返すことが許されるのか？という話だぞ
これを誤差だと言い張るならRustを使う資格はない
102 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 06:58:55.64 ID:SxNvW1DJ.net]: こだわりの強い人がおるなあ
103 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 07:31:56.62 ID:0zMBHAmc.net]: sliceやstrですむのにVecやStringを使ってしまう人はlifetime parameterを習得できていなくて使えこなせないからだと思うよ
structやfnでlifetime parameterを付けたことのない初心者に多いね
104 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 07:36:46.05 ID:Sa0HPxlU.net]: こういうふうに面倒くさい人がRust使いには多いから普及しないんだろうなあ
アルゴリズムとデータ構造の分野からみてもクッソどうでもいい議論だよ
105 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 07:41:20.05 ID:0zMBHAmc.net]: >>102
アルゴリズムとデータ構造の一番の基本が無駄なコピーをしないこと
106 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 09:16:17.07 ID:EvhZrc0+.net]: strで返せるがあえてStringで返すと良い具体例を出せばいいのではと思った。
107 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:13:51.22 ID:26gTKyDM.net]: 富豪的プログラミングしたいならrustは向いてないよ
普通にpythonで十分
108 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:17:22.51 ID:3G/0wdmC.net]: でもPythonのDjangoは遅くてゴミじゃん
省メモリ最速のWebアプリ作るならRust一択だわ
109 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:17:53.18 ID:JbxU5Bja.net]: 例えばsplitみたいなのはstrで返せるけど、それを大量に呼んで受け側でto_stringをつける場合、
コードがto_stringだらけで見づらくなるとかはあるかな
そういう時にsplit_to_stringみたいな名前でString返すようにしたりはするけど
自分の場合、どっちかっていうとパフォーマンス云々より関数名から内部でアロケーションが連想されるかどうかを重視してる気はする
110 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:24:32.59 ID:e0i4PPZm.net]: rustでwebアプリなんてコストかかりすぎでは？ふつーにgoかjava/kotlinかc#で作ればいいじゃん
111 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:28:03.29 ID:26gTKyDM.net]: >>104
ないでしょ
少なくともその関数側で判断できるものではない
帰ってきた文字列をどうするかは使う側が決める
これはrustに限った話ではなくプログラミングのお作法の話
文字列を変更したいという意図で所有権を持った文字列を作りたいならto_ownedすべきだし
そうでないならライフタイムを意識してそのまま使えばよろしい
C/C++でも全く同じ話よ
C++ならstring_viewを返す
そこであえてstringを返す意味はライブラリ提供者側にはない
例えば10000回のループの中でそのような関数が呼ばれたらどうなるか？
恐ろしいことになる
C/C++だと常にそういうことを考えてる
pythonとかだと全部stringだから意識してないのだろうけどさ
本来は意味のないアロケーションであることが多い
112 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:32:33.77 ID:XsYnyWq4.net]: >>107
大量であっても&strのままでよいものはString化しない
String化が避けられない場合でも大量ならばイテレータで処理してるはずなので.into()の数は少ないはず
いずれの場合でも関数は&strを返せばすむ
113 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:33:55.72 ID:AHA4uyfa.net]: 正しいことが必ずしも正義とはならない、とだけ言っとくわ
114 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:36:04.38 ID:XsYnyWq4.net]: >>108
RustでWebは容易かつ向いている
Rustの公式アンケート世界調査でも最多利用はWeb分野
115 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:47:22.41 ID:TZcb9n30.net]: rustあんま使ってない人だけど、strはImmutableでstringはMutableなんでしょ？
文字列配列を柔軟に扱いたいときだけstringで色々して、データを受け渡しするときは当然strを使うのがモラルってもんでしょ
immutable_stringはよく知らん
116 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:50:08.77 ID:3gDommQf.net]: 今現在Rustが実際に多く使われてる分野って、スクリプト言語の下まわり、ライブラリ高速化だよね
だからそれはWeb用だと言われたらまぁそう
117 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:51:38.36 ID:gN1hlXLs.net]: >>112
108だけどそれはasm.jsの代替のwebアセンブリってやつをrustでやってるんでしょ
webアプリとは違うねん
118 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 11:53:33.66 ID:gN1hlXLs.net]: 単なるWebサイトの演算処理の補助用途とWebアプリ用途を一緒にしてほしくない
全然違うねん
119 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:03:32.16 ID:XsYnyWq4.net]: >>114 >>115
Rustの利用で最も多いのは
Webサーバーサイド・バックエンド・クラウド
https://gihyo.jp/assets/images/article/2022/09/rust-monthly-topics/in_what_technology_domain_is_Rust_used_at_your_company.png

>>116
Webアプリのサーバーサイドとして使われています
120 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:09:03.48 ID:3gDommQf.net]: >>117
スクリプト言語のライブラリとしてRust使ってる人はそんなアンケートに答えないし
自分がRust使ってる自覚もないよ
121 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:13:31.67 ID:KLdOqrmk.net]: rust開発チーム直々の調査結果なんね
ちゃんとぎひょう記事urlも貼ってくれ
https://gihyo.jp/article/2022/09/rust-monthly-topics-01
122 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:17:34.02 ID:XsYnyWq4.net]: >>118
Rustで何を開発しているか？だからそれら別言語の人は関係ない
PythonやJavaScriptなどのライブラリが最近はRustで書かれることが増えたが
その開発者たちもRust利用者全体から見れば少数
一番多いのはWebのサーバーサイド・バックエンド・クラウド
123 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:35:09.79 ID:VMbwu+xF.net]: WASMはRustに限らずそんなに大っぴらに普及しないと思う
ゲームエンジンかエンコーダーデコーダーくらいにしか需要がない
GUIとしてのWASMはDOM操作を直接できない時点でゲーム操作用途にしか使えないゴミ、終わっとる
124 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 12:55:06.68 ID:S1lIKTmM.net]: wasmは触ってみりゃ分かるけどjavascriptの演算処理を単にrustで書いてコンパイルしてみると、rustのstdがバイナリに同梱されるせいで移植前のスクリプト状態よりファイルサイズが増加するんだよね
wasmテキスト形式で書くかstdレスなrustで書かなくちゃ本末転倒になる
まあファイルサイズが増加してでも演算処理を高速化したいならいいんだろうけど俺は吐いた
125 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 13:12:09.54 ID:py1fYTT7.net]: >>117
組み込みシステム開発者なんていう有能が溢れるほどいるわけないし妥当な結果ね

にしてもRustがサーバー開発でこんなに占めてるんだねえ
126 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 13:17:12.24 ID:5inMqUOs.net]: >>121
WASMはWebブラウ�
127 名前：U内用途だけではないよ CDNエッジでの利用も増えているね WASIなどによる拡張でできることは無数に増えてく >>122 stdは無くてもRustは機能するようにできているよ 例えばスライスやstrはcoreにあるし VecやStringはallocにあるよ []: [ここ壊れてます]
128 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 13:45:54.96 ID:KLdOqrmk.net]: WASIはモバイルOSあるいはデスクトップOS業界がどう動くかだね
wasmerみたいなWASIランタイムをOSが標準装備してくれるなら、WASIの注目度が上がるし、OSに依らないアプリを手軽に作れる
特にモバイルOSではランタイム同梱によるアプリの肥大化を阻止できる

WASIは今のままではJVMのようにマルチプラットフォームなランタイムの上で動くアプリでしかないから、どっかの有名なプラットフォームが積極的に土台として採用しないと忘れ去られる
UnityでもAndroidでもどこでもいい
129 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 14:00:52.18 ID:KLdOqrmk.net]: まあ数日前にWASI 0.2.0の仕様が確定したばっかだから時期尚早と言われればそのとおりなんだが

WebAssemblyを進化させる「WASI Preview 2」が安定版に到達。OSや言語に依存しないコンポーネントモデルを実現
https://www.publickey1.jp/blog/24/webassemblywasi_preview_2os.html
130 名前：デフォルトの名無しさん [2024/02/03(土) 14:54:43.97 ID:Xm89AN74.net]: wasm,wasiはコンテナ界隈とかも期待はしてるようだけど確かにまだ早い。
131 名前：デフォルトの名無しさん [2024/02/03(土) 15:14:19.35 ID:nibYeb0/.net]: あ、俺みたいに用意されたものを使う的な人間の場合ね。
132 名前：デフォルトの名無しさん [2024/02/03(土) 15:32:51.57 ID:8/wI1v6d.net]: 重さが気になるほどの人気サイト作ってから言えよな。。クソしょーもねーわ。
133 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 18:14:49.92 ID:X6BgdPzu.net]: wasmはブラウザでffmpeg動かすときに使ったことある
134 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 20:39:34.60 ID:em0HMTKL.net]: rustはもっとC#みたいなクラスの書き方が出来れば最高なのになー
135 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 20:58:14.42 ID:JrVgBiwL.net]: >>131
クラスはプログラミング言語の歴史では大失敗作と言われていて
モダンな新言語(Rust, Go, Zig, Nim, etc.)ではいずれもクラスを排除している
既存のクラスのある言語でもカプセル化以外のクラスの機能は使わずにインターフェース等を使うことが推奨されている
Rustのtraitはその中でも最も優れたものなのでRustで困ることはないよ
136 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 21:06:51.84 ID:93RdYvh2.net]: Rustはtraitのドキュメント見た時に
とっ散らかって見えるんだよなぁ
137 名前：デフォルトの名無しさん [2024/02/03(土) 21:20:55.82 ID:Uoo5j+2b.net]: 何事もタダでは手に入らない
良い面だけしか見ない人はいつまで経っても素人
138 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 21:29:31.74 ID:W4j87Z5e.net]: 本当にいいの？僕は…黒人だよ？
139 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 22:04:08.76 ID:OoEMTWx+.net]: クラス排除はJavaの生みの親ですら主張しているほどプログラミング言語界での共通認識

＞以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく�
140 名前：ﾀ装継承(extendsの関係)なのだということでした。 ＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。 ＞できる限り実装継承は避けたほうがよいでしょう。 []: [ここ壊れてます]
141 名前：デフォルトの名無しさん [2024/02/03(土) 23:17:23.21 ID:g7D12qls.net]: クラスを排除した代わりにRustでは実装継承の実現に4種類もの異なる方法が導入されている
もちろんGoでもNimでもクラスとは違う形で実装継承が実現されている
にもかかわらず物事の表面しか見ない人はそれに気づけないし今でも実装継承が絶対悪だと信じて疑わない

これが所謂バカの壁
142 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 23:26:38.80 ID:9NPgrYKr.net]: >>137
Rustに実装継承はないよ
どのやり方でも必ず委譲が発生する健全な方法を採っていて実装継承の問題を排除している
143 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 23:35:45.23 ID:EvhZrc0+.net]: クラスが悪いのか継承とかの機能が悪いのか
144 名前：デフォルトの名無しさん mailto:sage [2024/02/03(土) 23:45:39.46 ID:1FnNRIIs.net]: 大雑把に　クラス＝カプセル化＋実装継承
よくないのは実装継承
カプセル化だけなら構造体の範囲内
つまり実装継承を伴うクラス自体が要らないというのがモダン言語
145 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 00:25:24.84 ID:gRgK5+vi.net]: Kotlinのsealed interfaceはマジで超使いやすい
146 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 00:27:54.98 ID:woXOEkq4.net]: Rocketってフレームワーク試してみたんだけどこれホストを127.0.0.1以外にできないんかな
なんかハードコーディングでlocalhost指定になってる気がしないでもない
147 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 00:33:31.21 ID:iIxOCdCp.net]: そのRocketというフレームワークは使ったことないが、GitHubレポジトリで「127.0.0.1」で検索したら、
https://github.com/search?q=repo%3Arwf2%2FRocket%20127.0.0.1&type=code
exampleでなんか設定ファイルでadressを指定してるけどこれは違うの？
https://github.com/rwf2/Rocket/blob/master/examples/config/Rocket.toml

繰り返すがRocketというフレームワークは使ったことないので悪しからず
148 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 00:59:56.12 ID:woXOEkq4.net]: その辺grep置換で全部置き換えたけどダメだった

core\lib\src\listener\endpoint.rs にある
Endpoint::Tcp(TcpAddr::new(Ipv4Addr::LOCALHOST.into(), 8000))
がそれっぽくはあるけどどう書き換えたもんか
149 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 02:04:25.32 ID:1c78Jpm9.net]: https://rocket.rs/v0.5/guide/configuration/
読んだ感じだとRocket.tomlって設定ファイルで指定するのが簡単みたい
下の方にプログラムで設定する方法も書いてあるけど

こういうフレームワーク系はプロキシサーバーの裏側で動かすのが理想かもしれない
150 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 03:52:57.49 ID:58NiwoAK.net]: Rustを書けるようになると、C/C++でも行儀よく実装できるようになるから
するとドキュメントの充実しているC/ C++でいいかとなりそう
151 名前：デフォルトの名無しさん [2024/02/04(日) 05:28:12.54 ID:Qwt1SmMN.net]: >>105
Python信者か？　富豪プログラミングでもRustの方が書きやすいが
152 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 07:20:12.68 ID:IOFBpciC.net]: 動的型付けのPythonは論外でプログラミングには向いておらずスクリプトを書く程度に使う言語
静的型付けの言語の中では過去の様々な問題点を踏まえて洗練された設計となっているRustがプログラミングに最適

>>146
それはない
例えば今では必須な非同期プログラミングでもC++は出遅れていて使いにくいだけでなくRustのtokioに相当する基盤もない
153 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 08:23:06.79 ID:Iky4lKs4.net]: >>146
ドキュメントの数は多いけど、自動生成
154 名前：もない時代のが多くてソースコードと乖離してたり 古いLinuxディストリ前提だったりして役に立たない率がめちゃ高いんだよな ドキュメンテーションテストとかdocs.rsとかそういう仕組がちゃんとしてるのに慣れると わざわざ古代の遺物的なのを発掘しに行く気にはなれない []: [ここ壊れてます]
155 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 08:29:53.11 ID:qR3d7cra.net]: Cは構わないけど、C++はあり得ない
絶対に二度と触りたくないし、積極的に見たくもない
156 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 08:46:56.47 ID:gRgK5+vi.net]: Cにdeferが来たら、もうC++を触らなくてよくなるんだ🥰
…C23でのdeferの実装、見送られたけどね
157 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 09:04:42.24 ID:gRgK5+vi.net]: ああ、zigを本番環境で使いたいなあ
158 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 10:02:40.29 ID:woXOEkq4.net]: >>145
それもやったけど変わらなかった
まぁver0.xだし正式リリースになったらもうちょいマシになるんだろうから
今はまだ使い時じゃないって事で
159 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 10:56:28.64 ID:Iky4lKs4.net]: >>153

これでなんの問題もなく動いたけど…

#[launch]
fn rocket() -> _ {
let config = rocket::Config {
port: 7777,
address: std::net::Ipv4Addr::new(0, 0, 0, 0).into(),
..rocket::Config::default()
};
rocket::custom(&config).mount("/", routes![index])
}
160 名前：デフォルトの名無しさん [2024/02/04(日) 11:21:21.48 ID:lyxub88e.net]: >>146
自分で書く分ではどっちでも。
でもお前の職場のプログラミングセンス無いやつにもc/c++で書いてて欲しいと思う？
161 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 11:36:41.94 ID:BT7dzCU3.net]: >>153
rocketを使う理由が特にあるわけではないならば
一番ダウンロード数も多くRustで本流のaxumを使うといいよ
https://github.com/tokio-rs/axum
このURLを見てもわかるようにtokio開発チームが直接手掛けているWebアプリフレームワーク
162 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 12:24:56.19 ID:RfkvOVf2.net]: >>148
それはあなたの主観だよ
世界中で流行っているpythonをそのように評価をすること自体がナンセンスだとは思わないか？
163 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 12:55:23.59 ID:twXVw8X/.net]: >>157
前にも書いたけど例えばPythonのDjangoは遅い
PythonがRustに勝ってる点はローコストでコーディングできる、それのみ
学習コスト、開発時間などを投資できるならRustのようなlow-levelな言語を用いた製品のほうがコンピュータに優しいのは既知の事実
164 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 13:07:03.82 ID:BT7dzCU3.net]: >>157
Pythonでプログラミングを実際にすればわかるけど
ある程度の大きさのものを作るには開発デバッグ効率が非常に悪いね
数ある諸言語と比べてもPythonのメリットは普及していること以外には何も無いかと
165 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 13:22:50.87 ID:RfkvOVf2.net]: >>158
つまりpythonはプログラミングに向いていないというのは間違いということで良い？

>>159
そうは思わないな
開発ツールやエディタが進化してるから差は感じない
166 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 13:45:38.68 ID:gf/EWl58.net]: インタプリタ言語はプログラミングに値しないってか？流石に言いすぎだぞ
うちの小学生の子どもにScratchをプログラミング学習として遊ばせてるけど、そのScratchもれっきとしたプログラミング言語だし
167 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 13:54:00.15 ID:qLwuX6da.net]: >>147
メモリ管理をランタイムに任せることを富豪的プログラミングというのでは？書き易さなんて単に個人の言語の習得度の差でしかない
168 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 14:07:26.71 ID:vIcGZtFX.net]: お前のDjangoは遅い？ならサーバーのスペックを10倍
169 名前：にしろやゴラァ ってのが富豪的プログラミングの理念ね []: [ここ壊れてます]
170 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 16:31:03.43 ID:ZDSbtwdo.net]: Rustと比べるとPythonはプログラミングに向いていない
スクリプト程度ではなく普通にある程度の規模があるプログラムを対象とする
171 名前：デフォルトの名無しさん [2024/02/04(日) 16:54:18.26 ID:lyxub88e.net]: 特定領域の話と一般論をごっちゃにしてるやつ多いな。
172 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 16:54:55.07 ID:RSs6aSR/.net]: 実際にPythonで書くと実行時デバッグがどうしても多くなるね
後から機能追加したりリファクタリングしたりする時も再び実行時デバッグに陥りやすいね
その点Rustは静的型付けであるだけでなくデータ競合もコンパイル時点で防いでくれるから優れているね
173 名前：デフォルトの名無しさん [2024/02/04(日) 16:55:36.99 ID:3vZBpwTn.net]: >>162
文脈的に文字列を無駄にヒープに置いただけで富豪扱いなんだよな
あと習熟度に依存するのはそれはそうなんだけど、Pythonに習熟した人間ほどRustの方が書きやすいという傾向がある気がする
少なくとも俺の身の回りではそう
174 名前：デフォルトの名無しさん [2024/02/04(日) 17:00:11.71 ID:p+8ZNFQ1.net]: 書きやすかろうが何だろうがユーザ数が全てやろ
Rustは流行ってないそれだけは確か
175 名前：デフォルトの名無しさん [2024/02/04(日) 17:01:42.98 ID:3vZBpwTn.net]: ユーザー数が全てはまあそれはそう
176 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 17:06:47.57 ID:ktccjMxJ.net]: そこは単純な話だろう
PythonとRustの両方をそこそこ使いこなせる人たちに
どちらの言語でも開発可能な領域の案件をどちらで開発したいか尋ねる
100%の人たちがRustで開発したいと答える
つまりPythonは劣った言語
177 名前：デフォルトの名無しさん [2024/02/04(日) 17:07:47.85 ID:3vZBpwTn.net]: Pythonにも確かに良い所があって、Qiitaの記事が多いから入門が簡単
178 名前：デフォルトの名無しさん [2024/02/04(日) 17:11:51.24 ID:p+8ZNFQ1.net]: そもそもお前らの勘違いはpythonを取り上げてること
寧ろ比較するというかライバルはJavaScriptだぞ
バックグラウンドや速度求められる所でも使われてる
実際にJavaScriptは以外とは失礼かもだけど高速だしな
179 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 17:14:25.77 ID:RfkvOVf2.net]: >>172
ライバルがJavaScript()
180 名前：デフォルトの名無しさん [2024/02/04(日) 17:15:47.77 ID:p+8ZNFQ1.net]: >>170
何でワザと複雑化させるの？
ユーザ数って言う最もシンプルなので良い

いざ開発で人集めたらRust出来る人が居ませんでした
居ても単価がバカ高い人でした
pythonならこちらが選び放題で報酬も安く済みます

どう考えてもpython優位だよね
言語が劣ってるとか優秀とか関係無い
目的のシステムが短期間で安く作れるかどうか
でもってそれが出来るのが優秀な言語
181 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 17:20:38.23 ID:ktccjMxJ.net]: >>172
バックエンドではJavaScriptは遅い
フロントエンドのDOMアクセスはJavaScriptでしかできないため使わざるをえない
DOMアクセスを頻繁に伴わない処理ならばWasmが圧倒的に速くJavaScriptは遅い
182 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 17:26:06.18 ID:ZDSbtwdo.net]: >>174
それはPythonしか知らないプログラマーが多いだけでどうでもいい話だな
両方を使えるプログラマーはRustを選ぶからプログラミング言語の優劣ははっきりしている
183 名前：デフォルトの名無しさん [2024/02/04(日) 17:32:07.47 ID:3vZBpwTn.net]: 単価の話し始めたらまだPythonよりJavaの方が優位そう
184 名前：デフォルトの名無しさん [2024/02/04(日) 17:33:28.37 ID:p+8ZNFQ1.net]: >>176
両方というかRustのユーザ数が少ないから人が集まらないって話してるのにバカなのかなw
185 名前：デフォルトの名無しさん [2024/02/04(日) 17:35:51.36 ID:3vZBpwTn.net]: 目的の設定からコーティングまで自分でやらないといけない局面があって、そういう時に良いんだよな。Rust。
仕事が定型化されていたり、専門知識が要らなかったりして外注出来るならJavaで良さそう
186 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 17:44:55.37 ID:kqDQxPDl.net]: 開発保守効率の良さ　Rust＞Python
実行速度や省メモリ　Rust＞Python
この状況でPythonの方が優れてると主張してるやつはスレ荒らししたいだけだろうからここから出ていきなさい
専用スレへどうぞ

Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/
187 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 18:05:48.16 ID:gRgK5+vi.net]: ユーザー数が全てと言うならJavaが最強って話をしたくなってくる
188 名前：デフォルトの名無しさん [2024/02/04(日) 18:27:51.72 ID:p+8ZNFQ1.net]: そういう話じゃ無いんだよなぁ

Rust使いたいなら流行らせてユーザ数増やすしか無い
他の言語と比較して云々を語る暇があるならライブラリ作って充実させて流行らせる努力すれば良い
189 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 18:38:38.86 ID:JoIfCUOf.net]: >>180
分野によって変わるし一概にそうとは言えんよ
例えば機械学習の分野でRustを使うメリットはゼロ
開発保守性に関しても速度的にも利便性的にもツールチェインの連携にしても
今や汎用言語は以前に比べると遥かに有用性は低くなってる
だからrustが流行り切らないのだと分析してる
一昔前なら一斉に移ってたと思うよ
190 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 18:55:04.87 ID:h39TGQDK.net]: >>183
本気で言ってるなら常識を疑う
機械学習分野は各社の競争が激しくて記述言語はC/C++/Rust
Pythonはライブラリ呼び出しスクリプトに使われることがあるだけの存在
191 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 18:55:55.93 ID:gRgK5+vi.net]: >>183
あの、機械学習はプログラミングじゃないとは言わないけど分類としてはデータサイエンスだからな？😅数学系だからな？あんだすたん？
機械学習は理論がメイン、プログラミングはただの手段
192 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 18:59:22.83 ID:gRgK5+vi.net]: libtorchとかてんさーふろーの実装の話ならオープンソースを見ればわかるがC/C++やで
演算処理がメイン機能なんだから当たり前だよね
193 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:01:58.80 ID:gRgK5+vi.net]: Rustはサーバー系、組み込み系が用途なのに、
Pythonのが優秀だのなんだの言うのいい加減に鬱陶しいぞ
194 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:04:22.03 ID:woXOEkq4.net]: Pythonとか他の言語が分かれば数時間の勉強であとか感覚で読み書きできる言語だけど
Rustはそうはいかんと思うし
優れた言語と手軽に習得できる言語って比べても仕方ないと思う
195 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:13:30.94 ID:gRgK5+vi.net]: 言い方が悪かったかな
Pythonはさ、演算結果を得るために使うものであって、サーバーや組み込みのような常時駆動するようなものには向かないんですよ

考えてみなよ、お手軽さを求めるときは大抵は結果を求めたいときだろ？
numpyの行列計算がお手軽で便利～ってのと一緒だろ？
196 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:17:47.24 ID:JoIfCUOf.net]: >>184
それを言えばpytorchのラッパーがrustにあるから同じ存在だよ
197 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:18:07.74 ID:VbPJH2i6.net]: Pythonにキレててｸｶ
198 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:18:31.47 ID:JoIfCUOf.net]: >>189
じゃあrustじゃなくCで良いって話になるけど
199 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:24:46.98 ID:gRgK5+vi.net]: >>192
俺、1度目もRustじゃないとダメだとか言ったか？
俺の意見はちゃんとサーバー、組み込みに適した言語、Java、Kotlin（大好き）、C#、Go、C、C++（きらい）、Rust、Zig（流行ってほしい）を使えってこと
PythonやRubyをサーバーや組み込みに使ってほしくない
200 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:30:56.06 ID:gRgK5+vi.net]: あと機械学習の話が出てきたから追加で言うけど、演算処理するなら、極力オーバーヘッドを減らしたいわけで、ガべコレなんていう敵はいないほうがいいわけだから、C/C++/Rustを実装言語に使う
俺ら末端ユーザーが演算処理装置の実装なんてする機会がないからどうでもいい話だけど
201 名前：デフォルトの名無しさん [2024/02/04(日) 19:37:05.95 ID:3vZBpwTn.net]: 機械学習でガベコレが気になるってかなりアプリケーションよりっぽい感じがするな
実装コストとかより推論速度が重要という人間が出てきたのを見ると、機械学習もここまで来たんだなあって感慨深くなる
202 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:42:57.90 ID:ccceg+j6.net]: pythonの使われ方は1番にデータサイエンスとして、2番にプログラミング学習のお手本言語として、3番にシェルスクリプトの代替として。
実装言語としては使われてないよ。
203 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:46:45.59 ID:gRgK5+vi.net]: >>195
逆に聞きたいんだけど、ただ単に線形代数の計算がしたいだけなのに、ガべコレいるの？
204 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:49:37.34 ID:gRgK5+vi.net]: 昔からあるeigen使っても機械学習できるし
205 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:53:25.16 ID:woXOEkq4.net]: 言語として普及させるならやっぱ母数的にはまずWebのバックエンドだろうけど
それならそれでフルスタックフレームワーク欲しいところなんだよなあ
MoonZoonってのがヒットするけどあんまドキュメントが充実してないな
206 名前：デフォルトの名無しさん [2024/02/04(日) 19:54:33.10 ID:3vZBpwTn.net]: >>197
いるかいらないかで言えばいらないけど、実行時間のほとんどは線形代数演算だからガベコレの時間は誤差だし、高速化したいならモデルをチューニングする方がはるかに効果が大きいので誰もガベコレなんか気にしていないという時代が長かった印象
207 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:55:05.28 ID:JoIfCUOf.net]: いつのまにか実装言語の話に流れてるけど
そういう議論はしてないからな
208 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:55:34.23 ID:yS+PPAz5.net]: ここはRustのスレです
開発プログラミング言語として劣っているPythonの話題は他所でしてください
209 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:56:07.95 ID:JoIfCUOf.net]: 機械学習で得たモデルを組み込みデバイスで使いたいってことなんじゃない？
それもう機械学習を終えて、ただのアプリの設計と実装な気がするけど笑
210 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 19:59:28.23 ID:JoIfCUOf.net]: どれもダメ
pythonに勝てる理由にはなってない
実装言語の話をしたいならC/C++で良いし現状そうなってる事実は覆らない
速度だけ欲しいならrustはいらない
211 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:00:34.78 ID:gRgK5+vi.net]: >>200
それはそう
行列演算ライブラリがC/C++ばっかなのはたまたまだとも言える
212 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:02:02.46 ID:gRgK5+vi.net]: >>201
このスレはRustスレなんだから実装の話になるのは当たり前だろ
データサイエンスの話がしたいなら他所に行ってくれ
213 名前：デフォルトの名無しさん [2024/02/04(日) 20:03:49.73 ID:woXOEkq4.net]: MoonZoonってfront/backを一括で開発するBlazorみたいな感じか
https://github.com/MoonZoon/MoonZoon
https://zenn.dev/etoal83/articles/2de0fcde17cc01
214 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:06:59.78 ID:uCVo+TKx.net]: >>206
じゃあこういう視点から聞くが下回りがrustの機械学習ライブラリはありますか？
215 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:11:29.25 ID:gRgK5+vi.net]: >>204
Rustを組み込み業界が推してる理由はセキュリティ、メモリ安全の観点でRustがC/C++より優秀っていう理由
実際にカーネルはRustにマイグレーションされはじめてるでしょ
Rustがサーバー用途で使われだしてるのはtokio等のRustライブラリ、Webフレームワークが優秀なおかげでJavaのSpringBootのような有名どころに機能面でそこまで劣らず使えて、省メモリ高速に使えるから
216 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:16:35.93 ID:woXOEkq4.net]: >>209
そういやJVM使うから同じゲーム動かすにしてもAndroidはｉPhoneよりメモリとかのハード要件上がるとか言われてたな
217 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:16:54.38 ID:JoIfCUOf.net]: >>209
少なくとも下回り使う分にはそのような要求は必要ないと思うが
rustであってもunsafeだらけになるよ
非同期ライブラリに関してはpythonもasyncioというtokioに勝るとも劣らないつよつよライブラリがある
よってその点でも不足はない
Webフレームワークに関しては言わずもがな
218 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:17:19.77 ID:gRgK5+vi.net]: >>208
だからなんでそんなにデータサイエンスの話をしたがるの？
ライブラリ？libtorchのrustラッパーでコード書いてコンパイルすりゃいいだけやんか頭悪すぎでは？
機械学習は演算処理して類似度を求める作業なんだからコンパイルなんて手間かけずにスクリプト言語でやったほうが手軽だろうが
長時間動作させたいサーバーや組み込みとはわけが違う
インタプリタ言語とコンパイル言語の使い分けもできないの？
219 名前：デフォルトの名無しさん [2024/02/04(日) 20:22:45.50 ID:woXOEkq4.net]: 負けず嫌いが多いのか知らんが相手にするから居付くんやで
220 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:24:07.63 ID:gRgK5+vi.net]: >>211
システムコール書くんだからそらunsafeだらけになるわな
逆に言えばそのシステムコールまわりの部分さえ厳重に書けばいいじゃんか

Webフレームワークでインタプリタ言語を使うのは、上で言われてた典型的な富豪的プログラミングだよね>>163
サーバーに重課金できるならPythonでどうぞ実装やってください
ふつうの神経を持ってたら少なくともJavaとかC#とかGoとかをサーバーに使うと思う
221 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:24:27.23 ID:JoIfCUOf.net]: >>212
いやそもそもの議論の出発点が「機械学習においてはpythonがrustより優れている」というところだからでしょ
222 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:28:31.70 ID:gRgK5+vi.net]: >>215
機械学習はプログラミングじゃないとは言わないがデータサイエンスの分野だよ（2回目）
だから「機械学習においてPythonがRustより優れてる」がそもそもおかしい
Rustはデータサイエンスをやる言語ではない
223 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:28:47.77 ID:tlFdYVQb.net]: >>208
【機械学習 by Rust】
・autumnai/leaf — Open Machine Intelligence framework.. Abandoned project. The most updated fork is spearow/juice.
・burn - A Flexible and Comprehensive Deep Learning Framework in Rust.
・coreylowman/dfdx — CUDA accelearted machine learning framework that leverages many of Rust's unique features. Crates.io
・huggingface/candle - a minimalist ML framework with a focus on easiness of use and on performance (including GPU support)
・huggingface/tokenizers - Hugging Face's tokenizers for modern NLP pipelines written in Rust (original implementation) with bindings for Python. Build Status
・LaurentMazare/tch-rs — Rust language bindings for PyTorch.
・maciejkula/rustlearn — Machine learning crate for Rust. Circle CI
・rust-ml/linfa — Machine learning framework.
・smartcorelib/smartcore — Machine Learning Library In Rust Build Status
・tensorflow/rust — Rust language bindings for TensorFlow.
224 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:31:39.88 ID:JoIfCUOf.net]: >>217
いや一覧を出せって意味じゃないぞw
python以上に使われてる例を出せって意味だよ
225 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:32:36.67 ID:JoIfCUOf.net]: >>216
そういう逃げはいいから
データサイエンスも普通にプログラミングです
226 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:33:09.36 ID:gRgK5+vi.net]: >>219
違います、数学です
227 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:34:08.77 ID:woXOEkq4.net]: データサイエンスやるならPythonよりJuliaの方がいいな
228 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:34:15.03 ID:JoIfCUOf.net]: 結局論破できないんか
じゃあ絡んでくるなよ
機械学習においてはpythonに負けていますでいいだろ
そしてそれはrustがダメということにはならん
何と戦ってるのか
229 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:36:35.51 ID:gRgK5+vi.net]: >>222
機械学習の論文読んだことある？プログラミングなんてどうでもいいことは「～のPCスペックでPytorchを用いて実装しました」くらいしか書かれないぞ
230 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:36:58.01 ID:tlFdYVQb.net]: >>222
Rustは機械学習のライブラリもRustで書かれているものも多いです
PythonはC/C++依存だから同じ土俵にすら立てないと思います
231 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:37:34.97 ID:JoIfCUOf.net]: >>223
いやそれは今関係ないでしょ
232 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:39:06.92 ID:gRgK5+vi.net]: >>225
機械学習は理論が大事ということを語る上で関係大アリなんだが…
233 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:41:07.00 ID:wL3YnJ62.net]: 元々学生の勉強用としてPythonが利用されてて、
その学生が勉強の一環で機械学習したことで機械学習用のライブラリが増えた
その過去の資産(遺産？)の上に乗っかって今のAIブームがあるだけ

言語的な優位なんてものはPythonになくて
ただライブラリが充実してるだけの話
234 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:46:55.32 ID:7/eIVGRy.net]: 機械学習なら†darknet†だよね
235 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:48:06.01 ID:tlFdYVQb.net]: Rustで機械学習はRustだけで完結できるアドバンテージもありあります
新たに出て来て必要となる実装ライブラリもRustだけ習得すれば作れます
236 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 20:56:21.39 ID:gRgK5+vi.net]: うーん、機械学習する上で必須となる行列演算ライブラリの実装の話こそRustでやるかやらないかで盛り上がるところなのに、なぜ頑なに機械学習自体を取り上げて話をしてきたのか
理解不能だ
237 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:15:10.60 ID:woXOEkq4.net]: そういやJuliaだと行列演算言語単位でサポートしてたな
238 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:22:05.81 ID:wL3YnJ62.net]: そもそもの話になるけども
なんでPythonが教育目的で使われたのかって話になる
Pythonはキレイに書くことを強制されるってのもあるけど
電池内蔵とか言われるぐらい標準ライブラリが充実していた
だから学習に利用されやすかった
行列計算も然り

結局ライブラリが充実してたって話に帰結するよ
尤もライブラリの大半はCで書かれてるがね
239 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:24:14.42 ID:wL3YnJ62.net]: ちなみにnumpyの開発者も大学生だったんじゃないかな
とにかく欧米の学生はPythonで勉強してたから
Pythonのライブラリは大学生が作ったものが多いよ
240 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:33:51.15 ID:7hkEeikC.net]: その昔は perl もライブラリが豊富といわれていたんだがな
perl, ruby, python の中ではオフサイドルールがある分だけ
python の方がプログラムがごちゃごちゃになりにくい
もっとも今となっては自動フォーマッターがあるので
どれで書いてもあまり変わらないが
241 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 21:44:00.36 ID:MUvkIiW8.net]: >>233
>>234
ここはRustスレ
Rustがらみの話以外は別スレでしろ
242 名前：デフォルトの名無しさん [2024/02/04(日) 22:16:24.24 ID:3vZBpwTn.net]: Rustはプログラム言語の王なのでRustスレではどの言語の話をしても良い
243 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 22:24:24.75 ID:gRgK5+vi.net]: 他の言語を知ることでRustの良し悪しが分かる、他の言語を学ぶことは巡り回ってRustの勉強になるって寸法よ
もちろんRustの文法やフレームワークの話題や議論があればそちらを優先すべきね
244 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:02:06.01 ID:FrLSpZU4.net]: Rustが『いま』流行ってなくても、Rustの協賛企業らが『無理やり』流行らすから5-10年後には日本でもサーバーサイドにRustを使う企業が増えている
20年後にはLinuxカーネルのRust化がほぼ完了してるだろうよ
245 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:16:12.06 ID:woXOEkq4.net]: 結局相手にするヤツがいるから居付くわけで
246 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:21:49.89 ID:MUvkIiW8.net]: >>238
Rustは「安全かつエコ」という流れが生じつつあるから日本でもそうなる
エコとは他の言語より消費電力を減らしCo2排出量も減ること
247 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:24:52.22 ID:X8VPJ+Rl.net]: rustとpythonではなく、tomlとpythonを比較すればいい
スクリプトを追放するたんびにマークアップ言語が増える歴史が繰り返される
248 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:32:42.46 ID:srfzNHU5.net]: >>239
相手にしなかったら自演して自分に安価つけ始めるけどな
249 名前：デフォルトの名無しさん mailto:sage [2024/02/04(日) 23:55:39.05 ID:gRgK5+vi.net]: >>241
tomlはマークアップ言語じゃなくてデータ記述言語
スクリプトうんぬんは知らんが、シリアライズ効率のより良いデータ記述言語を求めるのはいい事だよ
自分のところはjson+gzipで落ち着いてるけど、goでよく使われるprotobufにいずれ移行できればなって考えてる
250 名前：デフォルトの名無しさん [2024/02/05(月) 00:06:05.32 ID:xY09uWcV.net]: >>230
数値演算ライブラリはC言語で十分な気がする。理由を言語化するのは難しいけど
251 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:06:28.07 ID:8h9X84j9.net]: オッやっとるな
252 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:06:30.26 ID:8h9X84j9.net]: オッやっとるな
253 名前：デフォルトの名無しさん [2024/02/05(月) 00:11:45.07 ID:qpTlAoHG.net]: 一番向いてるのはミドルウェアとか少数のガチ勢が作ったらいいような部分なんだよな。
だから普及はしない。
254 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:14:26.70 ID:Uc3vGql0.net]: >>244
並列処理まわりの仕様をよく検討した上でRustかCかC++のどれを選択するべきとは思うな
255 名前：デフォルトの名無しさん [2024/02/05(月) 00:18:35.26 ID:qpTlAoHG.net]: アルゴリズム周りなんて共有のオンパレードなのにrustが向いてると思ってるのはちょっと素人感がすごいね。
256 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:25:50.11 ID:Uc3vGql0.net]: 日本語おかしくなった
並列処理まわりの仕様をよく検討した上でRust、C、C++のうちどれを使うか選ぶべき
個人的には並列処理の安全性の面でRustを使うべきだと思う
257 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:31:12.78 ID:Uc3vGql0.net]: まあ実情は演算処理にCUDAを使うだろうからC++で全部設計したほうが都合がいいのかな
難しい
258 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:39:33.82 ID:xSwz3MFP.net]: 並列処理？tokioの出番だな
259 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:52:01.28 ID:i8NFM5TB.net]: 機械学習はPython？Rust？いやいや争わずに両方使えばいいじゃん。

Rustを使って機械学習アルゴリズムを実装しPythonから呼び出す: k-meansクラスタリング
https://zenn.dev/skwbc/articles/rust_python_kmeans
260 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 00:57:54.10 ID:Ml8drJRq.net]: 機械学習だの演算処理だの、いつまでそんなつまらない話をしてるの？
rustはゴミってことで結論が出てるんだけど
261 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 01:03:32.12 ID:l3kMSpNc.net]: 荒らしに構うキチガイを追い出したいね
ID:gRgK5+vi　→　ID:Uc3vGql0　（違ったらごめんね）
262 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 01:04:43.04 ID:4uXpM/Ax.net]: >>253
わざわざ生でunsafeなコードを書かなくてもPyO3とか使えば楽にできるよ
263 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 03:14:48.13 ID:6VJ4TLXv.net]: >>243
Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？使ったことないけど。
264 名前：デフォルトの名無しさん [2024/02/05(月) 03:40:05.05 ID:d3c/QlU3.net]: Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう
265 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:01:25.37 ID:ip7v+BR3.net]: >>247
もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど
大人数による開発もRust向いてるでしょう
特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね
266 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:45:17.21 ID:bXI/bbyn.net]: >>247
Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119
267 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 06:55:14.99 ID:qjaRN2nq.net]: >>253
どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな
気になってぐぐったら「rayonのスレッドプールは、CPU を集中的に使用する
268 名前：作業、つまり大規模なデータセットの大規模な並列処理向けに設計されています。」らしい https://www.reddit.com/r/rust/comments/xec77k/rayon_or_tokio_for_heavy_filesystem_io_workloads/ []: [ここ壊れてます]
269 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 07:04:12.02 ID:ip7v+BR3.net]: >>261
rayonは非同期を使わない並列に特化した時に速い
tokioは非同期で並行＆並列で万能
270 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 08:21:40.19 ID:kahA1Glb.net]: >>227
なら言語的に優れていてPythonライブラリを使えるNim最強だな。
271 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 08:36:20.41 ID:ip7v+BR3.net]: Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分
272 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 09:57:56.35 ID:3fgxGQeI.net]: 他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう
273 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 12:16:47.03 ID:Uc3vGql0.net]: >>263
Nimは速いしCへのトランスパイルも賛否あれど個人的には好き
274 名前：デフォルトの名無しさん [2024/02/05(月) 12:56:18.45 ID:WdhGREbJ.net]: >>211
お前や俺らがそのunsafe部分を書く。
で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。
そういう分け方できるのはメリットじゃないかね。
275 名前：デフォルトの名無しさん [2024/02/05(月) 13:02:02.94 ID:WdhGREbJ.net]: >>266
同意
276 名前：デフォルトの名無しさん [2024/02/05(月) 22:28:07.58 ID:UHwE0rib.net]: >>259
もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。
277 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 22:40:04.70 ID:5g9amV19.net]: >>269
カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？
278 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 22:49:23.20 ID:dxOzlQzX.net]: >>269
AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ
279 名前：デフォルトの名無しさん mailto:sage [2024/02/05(月) 23:29:16.62 ID:bm3rzOD2.net]: AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず
この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ
280 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:09:13.25 ID:gR/xoQQt.net]: Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。
Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。
Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。
普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。
281 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:25:40.67 ID:oam+zbbU.net]: 物を作ってから普及するまでの時間で評価されれば
まだ作ってない物を売るようになったり、評価を信じなくなったりする
282 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:35:44.14 ID:QhlaBKsr.net]: >>271
あれすげー使いにくいよ
そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから
ライブラリ側は同期的で良いのにtokio使っちゃってるし
283 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 00:39:31.81 ID:OWeq/GHS.net]: >>272
現在のネットのインフラであるクラウドとCDNがRust製になっていってるから
Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね
284 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 01:36:56.00 ID:bbDh9Fvv.net]: >>275
割と何言ってるかよくわからないので
どのあたりが使いにくいのか詳しく
285 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 08:02:11.78 ID:TiTcC6K4.net]: >>275
javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある
同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった
286 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 08:41:24.69 ID:Lhg6cl8R.net]: >>275
それはキミの非同期処理に関する知識が欠如してるだけ
287 名前：デフォルトの名無しさん [2024/02/06(火) 10:42:58.91 ID:rmP9tpon.net]: まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな
288 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:02:01.98 ID:viYUZILO.net]: お前らはawait禁止縛りでもしてるの？
289 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:12:37.31 ID:tyBWuvJT.net]: tokioの非同期って
async fn、spawn、async、await
を最低限使えればなんも不自由なくね？
同期じゃないといけない理由あんの？
290 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:17:49.52 ID:gR/xoQQt.net]: 同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。
291 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:19:55.73 ID:g9hJ5hPW.net]: >>282
同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？
ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから
292 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:23:28.54 ID:YZW9kbIH.net]: AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w
293 名前：デフォルトの名無しさん [2024/02/06(火) 11:25:05.20 ID:BOUvQi0K.net]: >>280
そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。
294 名前：デフォルトの名無しさん [2024/02/06(火) 11:26:18.87 ID:J68o5uRN.net]: AWS CLIはcargo installで入ってこないから……
295 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:28:28.70 ID:DRX9b4l9.net]: そもそもRustを使う意味がないよね
AWS SDK for Pythonがあるんだから
296 名前：デフォルトの名無しさん [2024/02/06(火) 11:28:33.03 ID:J68o5uRN.net]: >>286
async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある
297 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:33:54.88 ID:GPQIFWbx.net]: >>289
そこはしょうがないでしょ
tokioはAWSが積極的に支援してるライブラリだからね
https://tokio.rs/
https://i.imgur.com/NSjb82s.png
298 名前：デフォルトの名無しさん [2024/02/06(火) 11:35:59.00 ID:J68o5uRN.net]: >>290
説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか……
299 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:38:49.18 ID:GPQIFWbx.net]: あ、AWSがtokioを運営してんのか
単なるスポンサーだと思ってた
300 名前：デフォルトの名無しさん [2024/02/06(火) 11:40:13.71 ID:J68o5uRN.net]: マジか
301 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:42:17.61 ID:4dmbx6OY.net]: 説教的な支援は5chの担当
302 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:42:20.07 ID:4dmbx6OY.net]: 説教的な支援は5chの担当
303 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 11:53:48.52 ID:9gL8Mjmo.net]: Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや
すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる
304 名前：デフォルトの名無しさん [2024/02/06(火) 12:09:35.30 ID:eJTRS9Cw.net]: 非同期と言いつつ出来てない奴って8割いるよね
305 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 13:54:11.58 ID:oam+zbbU.net]: 非同期のそのデメリットを消す方法は
まだ作ってないことにしよう
306 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:05:46.01 ID:QhlaBKsr.net]: >>277
まずAWSのAPIってのは基本的にすぐ返ってるの
この辺はわかる？
例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ
実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ
だから常に同期的に呼び出しで問題ないの
pythonのboto3ってライブラリが1番使いやすい
307 名前：デフォルトの名無しさん [2024/02/06(火) 14:08:10.63 ID:9MgF8+tA.net]: Boto3、あんま補完されなくて馬鹿にはキツい
308 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:39:52.97 ID:HfVCyUAp.net]: >>299
AWSが鯖落ちしてたらどーすんの？
309 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:47:03.29 ID:bbDh9Fvv.net]: >>299
あなたが何言ってるかわかるけどnodejsでも
似たような使い方だしrust sdkの欠点と言われても
広く同意は得られないんじゃないかなあ
310 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:52:06.28 ID:QhlaBKsr.net]: >>302
欠点というか使い方を難しくしてるだけな気がするんだよな
普通にCLIでええやんって思う
311 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 14:59:31.38 ID:bbDh9Fvv.net]: >>303
awsに限らずweb apiのライブラリは
非同期にするのが主流だから
頑張って勉強してねとしか…
312 名前：デフォルトの名無しさん [2024/02/06(火) 15:05:27.46 ID:eJTRS9Cw.net]: AWSのSDKは.NETのが1番だな
313 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 16:38:39.75 ID:m1uPeMIU.net]: AWS SDK for Rustはsend()がめちゃくちゃダサい
そのうち大幅に改修されるだろうけど

>>299
ネットワークI/Oを同期で書くのはさすがにどうかと
314 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 16:55:31.82 ID:/Z6uowCt.net]: >>300
今から見ると微妙だがCLIと対応がつけやすいし
余計なことはしなくて良いから楽だよ
315 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:04:11.45 ID:/Z6uowCt.net]: >>306
どう書くか？はユーザーのユースケースによるからそうとも言えないよ
例えばAzureのCLIは--no-waitというオプションがあり
処理が成功するまで待つか待たないかを決められる
これこそユーザー視点の設計だよ
316 名前：デフォルトの名無しさん [2024/02/06(火) 17:08:06.92 ID:8tVnzyvy.net]: Google規模の会社が$1 million渡したくらいでわざわざアナウンスするなよな
タイトル詐欺じゃん

Improving Interoperability Between Rust and C++
https://security.googleblog.com/2024/02/improving-interoperability-between-rust-and-c.html
317 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:08:19.95 ID:/Z6uowCt.net]: 非同期を押し付けることはユーザーのメリットにはならない
Rust SDKは作り直して欲しい
318 名前：デフォルトの名無しさん [2024/02/06(火) 17:21:49.29 ID:HJO9dxnA.net]: prostもblocking版の関数ないのかよってびっくりした記憶があるわ
C#版もPython版もasyncとblockingの両方あるのにな
319 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:23:58.68 ID:pGyPKkef.net]: >>299
>>まずAWSのAPIってのは基本的にすぐ返ってるの
>>この辺はわかる？

初心者でもそんなウソはつかないぞ
AWSに限らず任意のサービスに言えるが通信時間がかかる
さらに各サービス内で状態取得だけであっても実行時間がかかる

>>だから常に同期的に呼び出しで問題ないの

本気で言ってる？
通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？
非同期プログラミングの意味すら理解できていてないのか？
320 名前：デフォルトの名無しさん [2024/02/06(火) 17:27:07.44 ID:eJTRS9Cw.net]: >>312
コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ
321 名前：デフォルトの名無しさん [2024/02/06(火) 17:28:50.84 ID:2AaBK8OM.net]: 非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する
322 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 17:48:41.35 ID:Izyc/wZS.net]: API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？
ってのはわりと自然な感想だと思うけどな。

AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。
バカスカ叩いてもスロットリングされるだけだし。
323 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 18:00:53.30 ID:eyCZAgqI.net]: >>315
APIの向こう側で非同期なのとこちらの処理を
同期か非同期化は関係ないよね
324 名前：デフォルトの名無しさん [2024/02/06(火) 18:18:54.67 ID:w99V6zNl.net]: それな
無関係ではないけど分けて考えないと
325 名前：デフォルトの名無しさん [2024/02/06(火) 18:33:39.13 ID:nmitk2Uo.net]: >>308
非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ
326 名前：デフォルトの名無しさん [2024/02/06(火) 18:36:16.19 ID:2AaBK8OM.net]: 同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか
もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか
327 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 19:56:13.91 ID:kbEH5D0U.net]: AWSの同期的APIの機能リクエストあるのね
https://github.com/awslabs/aws-sdk-rust/issues/505
328 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:03:24.75 ID:Dpp0fICO.net]: AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？
329 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:17:12.09 ID:7oKTbIPT.net]: うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？
330 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:38:04.56 ID:NQvIuvVx.net]: >>312
だからーなーんにもわかってない発言丸出しはやめよ？
通信の時間なんてかからんのやって
すぐ返ってくるから
そこちゃんと読もう？
331 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:44:38.46 ID:NQvIuvVx.net]: AWS APIを生のRESTで実装してみろよ
すぐわかるぞ
332 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:45:53.99 ID:NQvIuvVx.net]: 言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ
もちろんその用途としての方が便利なことは多い
あくまでAWS SDKのRust版については不満があるということよ
333 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:50:46.76 ID:dKDdJveN.net]: >>325
web apiの実装として相手側が非同期処理で
手元も非同期なんてのはawsだけじゃないというか
それが主流だけど他はいいの？
334 名前：デフォルトの名無しさん [2024/02/06(火) 20:50:52.38 ID:2AaBK8OM.net]: このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので
335 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 20:57:52.50 ID:NQvIuvVx.net]: tokioが素晴らしいのは間違いない
しかし今回のREST APIの呼び出しで程度で必要かな？と思う

非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう
336 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:04:51.51 ID:pGyPKkef.net]: >>323
>>通信の時間なんてかからんのやって
>>すぐ返ってくるから

呆れた
敢えてウソをついているのか？
それとも本当に無知な初心者なのか？
337 名前：デフォルトの名無しさん [2024/02/06(火) 21:08:56.44 ID:rmP9tpon.net]: Web通信ですぐ返ってくることなんかあるのか？　と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった

そういえばファイルIOはすぐ返ってくるって言って良いんだろうか
338 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:12:11.34 ID:NQvIuvVx.net]: >>330
サイズが小さいファイルに対して非同期呼び出しをするか？という話
339 名前：デフォルトの名無しさん [2024/02/06(火) 21:14:41.84 ID:rmP9tpon.net]: >>331
まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな
340 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:15:39.21 ID:pGyPKkef.net]: >>330
Web通信は通信時間だけで大きく時間を要する
さらにWebサーバ側で処理時間がかかる
341 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 21:56:45.71 ID:Z39zy7L3.net]: >>323
cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど
レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい
tokioのグリーンスレッドを活かせ
342 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:05:59.23 ID:wkt5OFgc.net]: >>334
tokioのランタイムが裏で動くとか気持ち悪すぎだろ
同期でやらせろ
343 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:13:28.77 ID:IqTcjswh.net]: 他のSDKのようにv3くらいになれば使いやすくなってるかもね
344 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:16:42.98 ID:GPQIFWbx.net]: aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない
まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど
345 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:17:52.75 ID:GPQIFWbx.net]: 「rustのwebフレームワーク」が抜けてた
346 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:21:16.54 ID:1nslx8NY.net]: >>337
そういう話じゃないけど
347 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:24:12.00 ID:DARHuXMe.net]: >>337
実装の話に逸らさないで
AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ
348 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:24:15.12 ID:UMLcFsAo.net]: いくらすぐ返ってくるっていってもネットワーク通信なんだから
不通だったりレイテンシが長くなることはありうるし、
タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな
そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう
349 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:27:24.19 ID:QhlaBKsr.net]: JavaScript SDKも内部は非同期だけど使いやすいよ
単なるコールバックで同期的に書けるし
350 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:33:38.08 ID:QhlaBKsr.net]: どうも最近tokioがでしゃばってきて気持ちが悪い
ここまできたらもうコアをtokioに入れてWeb用の専用言語としてフォークしたほうがよいのでは？
351 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:35:03.21 ID:GPQIFWbx.net]: >>340
はぁ？そんなに同期でやりたいなら同期のある言語のSDKを使うかAWS CLIでコマンド実行しててくれよ
同期同期言ってるやつはRustでAWS触るアプリ作ってねえだろ
こちとらつい先日ようやく待ちに詫びたAWS SDK for Rustが正式版になって、ようやく、ようやくこれを本番投入できるって喜んだのによ
352 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:36:26.88 ID:QhlaBKsr.net]: まあ俺はCLI使ってるw
ぶっちゃけコードで書くメリットがわからない
353 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:36:30.11 ID:UMLcFsAo.net]: というか同期版もランタイム切り替えも別にissueとしては却下されてるわけじゃないんだし
欲しい人は実装してPR出せばいいんだよ
それがされてないってことは結局需要がないんでは？
354 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:38:18.90 ID:YgjIpfMr.net]: >>344
はい、じゃあお前の負けね
もう二度と口答えすんなよ
355 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:40:20.30 ID:QhlaBKsr.net]: >>341
不通だろうが普通はソケットのタイムアウト値設定するから許容できる範囲内の値を設定すればよろしい
どちらにしろリトライすることになるのだ
356 名前：デフォルトの名無しさん [2024/02/06(火) 22:44:11.89 ID:oodj9UUv.net]: 「そんなに××したいなら○○使えば良いんじゃないの？」→をはい○○使っています」っていう流れ、最強言語たるRustのスレの流れとしてはあまりにも敗北感がある
357 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:50:36.48 ID:QhlaBKsr.net]: まとめると
tokio使わない同期API作れ
非同期版はランタイム切り替えできるようにしろ
ってことでオッケー？
358 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:53:13.82 ID:j3cHqQGJ.net]: >>340
コンマ1秒～1秒の頻度でデータベースクエリするWebアプリとかだったら非同期のが次々に処理できると思うけど
359 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:56:34.96 ID:LdUhtiaW.net]: >>351
なんだそれ？
お前そんなにバカみたいな頻度でAWS APIを使うの？笑うわ
360 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:57:34.03 ID:MUGS3GDn.net]: >>351
クエックエッ
笑笑
361 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 22:58:56.15 ID:QhlaBKsr.net]: >>352
それくらいの頻度で呼び出す可能性があるのってGAFAMクラスの会社ぐらいじゃね？w
362 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:04:22.29 ID:JKYjZJJo.net]: >>351
ゲームサーバーとかかな？
363 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:06:26.14 ID:6KaTvZBM.net]: >>354
それな笑笑
>>351は負けず嫌いの単発の敗者笑笑
364 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:08:14.09 ID:IqTcjswh.net]: 使ってる用途が違うから噛み合わないんだな
CLIで十分な用途とAPIが必要な用途くらいは区別しようぜ
365 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:08:21.31 ID:1CYgky+r.net]: あ、もしかしてガーファ勤めなんかな笑笑？
なわけねえだろ笑笑
366 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:09:19.34 ID:nVMpMpiW.net]: ガーファ最強笑笑
367 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:10:22.99 ID:fZ7dPHD5.net]: >>351はバカです
368 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:12:04.80 ID:N6+r1oq4.net]: >>355
ゲームサーバーってなに？マインクラフトでもやってるの？ガキんちょか？
369 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:15:06.92 ID:aJWngw7a.net]: >>357
うるさいな
非同期じゃないといけない理由を具体的に言ってみろよ？あ？
370 名前：デフォルトの名無しさん [2024/02/06(火) 23:16:25.72 ID:QhlaBKsr.net]: >>351
GAFAM社員age
371 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:26:25.88 ID:qbDsNmRG.net]: 自分用のツールなら一々tokioとかめんどくさいとか
わからんでもないけどそういう人をターゲットに
してないからなあ
372 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:26:55.98 ID:IqTcjswh.net]: GAFAMの規模を舐めすぎだろ
10リクエスト/秒程度なら中堅企業の社内向けシステムでも普通にあるレベル
373 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:35:03.14 ID:O9rpVDxS.net]: 実際ゲームサーバーって大変そうよね
最近話題になったパルワールドってやつもサーバー要素があるけど、ゲームデータをどこかしらのクラウドサービスをレンタルしてやってるわけで、>>351よりもすごいレベルで行われてそう
パルワールドのサーバーはどの言語のWebフレームワークでやってるのか知らんがJavaとかC#、GoあたりならRustのが高速、省メモリでサーバー代を節約できただろうな
374 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:43:25.52 ID:ZEorkRES.net]: ゲームサーバーってプログラミング関係あるの？サーバーを借りてるだけなんじゃないの？
375 名前：デフォルトの名無しさん mailto:sage [2024/02/06(火) 23:56:44.33 ID:7jT2HGcX.net]: 無知は恥ってよくわかるね
376 名前：デフォルトの名無しさん [2024/02/07(水) 00:00:36.36 ID:/3r7f4vo.net]: >>366
人気ゲームだと桁が3つ4つ違う
377 名前：デフォルトの名無しさん [2024/02/07(水) 00:02:07.90 ID:HSCt9mfq.net]: >>368
無知自体は何も恥じることではない
378 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:25:18.71 ID:ZYweHa7T.net]: まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは
379 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:29:20.89 ID:HhW4UiiT.net]: AWSはCLIでいい、非同期はゴミって結論出たね
380 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:41:54.53 ID:O61WTlOm.net]: 通信時間＋向こうでの処理時間はCPUにとって莫大な待ち時間
async/awaitによる非同期プログラミングをすれば同期と同じようにプログラムを組めつつその莫大な待ち時間を有効活用できる
これは特定のプログラミング言語に関係なく対応しているすべての言語で成り立つ話
もちろんRustでも同じ
381 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:51:24.66 ID:EnTbeTL9.net]: AWS Lambdaだと同時実行数の制限があるから、同期処理をするのは犯罪的。
382 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:58:32.65 ID:p1o31ALH.net]: 現状のasync/awaitの使いやすさは
Swift > C# > JavaScript >>> Rust
383 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 00:59:45.05 ID:p1o31ALH.net]: KotlinやF#は使ったこと無いのでわからない
384 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:07:53.33 ID:p1o31ALH.net]: >>375
Python忘れてたわ
Swift > C# > JavaScript/Python >>> Rust
385 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:10:26.42 ID:O61WTlOm.net]: >>375
Rustが最もきめ細かく扱えて便利
386 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:13:21.82 ID:O61WTlOm.net]: もちろん性能面でもRustが最も有利
だからインフラに至るまで採用されている
387 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 01:20:07.41 ID:R4SwjTOT.net]: >>377
c++は？
388 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 02:44:08.20 ID:7skGlnTk.net]: >>377
swiftってそんなに書きやすいんか？
389 名前：デフォルトの名無しさん [2024/02/07(水) 04:57:14.90 ID:uDrK2oQi.net]: >>375
asyncもRxもC#が発祥だけどこの言語だけ異常だよな
390 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:30:56.86 ID:EnTbeTL9.net]: Pythonはスレッドが擬似的なので並行処理の性能が低い。
391 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:35:55.67 ID:5V24VW//.net]: >>375
392 名前：Kotlinが抜けてる Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust []: [ここ壊れてます]
393 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 06:52:43.34 ID:r0kpHnB4.net]: Rustを叩きたいだけのアンチさんだから無茶苦茶や
394 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:15:51.00 ID:Z0+c6VxI.net]: >>380
C++は論外
アンチではなく本当に書きにくい
さらにtokioのような高性能な基盤も整備されていない
395 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:16:35.05 ID:0B0Tt2Zv.net]: 非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる
JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない
396 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:25:44.75 ID:qmafesNd.net]: swiftやdartはモバイルアプリ開発以外で全く使われてない
397 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:30:51.78 ID:KVAhvvz+.net]: SwiftはApple製ってだけで使う価値なし
開発環境の依存があまりに高すぎる
398 名前：デフォルトの名無しさん [2024/02/07(水) 07:38:16.28 ID:2LChEtDL.net]: 出来ればJVMも使わずに済みたい
なんとなく
399 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 07:40:43.27 ID:lxo2szIV.net]: >>375,377,384
なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？
そらRustを使うことなんてないわな
なんでこのスレにいるのか
400 名前：デフォルトの名無しさん [2024/02/07(水) 07:53:07.34 ID:q5vZGjA+.net]: Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い
401 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 08:12:27.93 ID:gKkOyEKn.net]: まぁRustの非同期の良いところはランタイムを言語から切り離したので
Webでも組み込みベアメタルでも非同期が使えるところなんだけど
使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない
これは時間がたっても根本的には改善されないから
不満があるなら早く他言語に移ったほうがいいよ
402 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 08:15:11.44 ID:0B0Tt2Zv.net]: >>390
ならGoかC#のASP.NETでいんじゃね？
さまざまな導入コストを払えるなら事実上クラウドネイティブ言語のRust一択

それとJVMがダメという理由が、Oracle JVMのLTSサポート期間が短縮されJVMのイメージが悪化したってことに依るものなら、
Kotlin/JVMだとJDK8をベースに、どのJDKバージョンでも動くようにサポートされ続けられるから、JDK8から最新のJDK21までのLTSバージョンで難なく動く
https://kotlinlang.org/docs/faq.html#which-versions-of-jvm-does-kotlin-target
OracleのJavaは終わってるがJetBrainsのKotlinは無限に始まってる
403 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:03:48.96 ID:7skGlnTk.net]: 静的言語ではkotlinが個人的には1番かな
コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる
これが理想
ただしクラスありきなのが微妙なところ
クラスなしでkotlinのような使い心地がある言語が欲しい
404 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:09:08.81 ID:oJ2HGwP7.net]: >>373
その時間有効に使えるのかって話なんだよ。
例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、
そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。

DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。
405 名前：デフォルトの名無しさん [2024/02/07(水) 09:21:27.90 ID:+r3v4OXU.net]: 既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう
ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね
406 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:33:38.70 ID:3p2K3Rhv.net]: >>395
それはRustも同じ
Rustのasyncもコルーチンでありtrait Futureによって抽象化されている
Future::pollの引数であるContextがKotlinでのコルーチンコンテキストに相当する

>>397
Rustでも既存の処理に唐突に非同期を取り扱える
Rustでtokioのようなランタイムが必要になるのはspawnして完全に制御外へ切り離すときのみ
制御内ならば複数のFutureを取り扱う場合でもjoinなど様々な方法で取り扱うことができる
もちろんtokioランタイムは必要ない
407 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:42:26.35 ID:x+YpU8Xz.net]: async{}.await
408 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 09:45:13.70 ID:kuiQPbhX.net]: >>380
C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。
幅広いシステムで実現可能なように配慮するから。
必要ならサードパーティライブラリでやれというスタンス。
ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。

個人的には C++/WinRT の非同期処理は好きなんだがね。
409 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 10:36:03.38 ID:0B0Tt2Zv.net]: >>395
KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて
・クラス継承禁止
・やってることはCの構造体と同じ
だから、自分はclassであるデメリットを感じてないかな

Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ
410 名前：デフォルトの名無しさん [2024/02/07(水) 10:46:44.24 ID:rJGaKMx5.net]: >>396
>その時間有効に使えるのかって話なんだよ。
非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる

もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない
411 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 10:52:51.94 ID:ndvPWcVf.net]: なんかプログラミング言語総合スレみたいになってんな
いやちゃんと説明してくれて勉強になるから別にいいんだけど
412 名前：デフォルトの名無しさん [2024/02/07(水) 11:05:20.92 ID:tO9J4ky9.net]: >>402
Rustはプログラム言語の王だから理由がなくてもRustを使って良い
413 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 11:12:27.12 ID:dhCR1KyQ.net]: >>398
え、tokioランタイム無しで非同期関数呼べるんだ？　知らんかった
でもクレートの依存は付いてきてビルド遅くなるよね
414 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 11:34:03.35 ID:A5F8kPnc.net]: >>405
tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい
例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ
415 名前：デフォルトの名無しさん [2024/02/07(水) 11:48:56.31 ID:EgwSQeAh.net]: 自分でFuture::poll呼ぶとか罰ゲームすぎるやろ
416 名前：デフォルトの名無しさん [2024/02/07(水) 12:13:10.25 ID:DO0hQq6L.net]: >>361
ゲームサーバーはユーザーの操作ログを逐一集めてるよ。
417 名前：デフォルトの名無しさん [2024/02/07(水) 12:15:26.39 ID:DO0hQq6L.net]: >>370
いや、無知は恥だよ。ただ罪では無い。
無知のままでいようとすることは罪だけど。
あ、実際の法律云々じゃなくて技術者としてね。
418 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 12:39:51.49 ID:3p2K3Rhv.net]: >>407
自分で呼んでもいいし自分で呼ばなくてもいい
それは何をやりたいかどこまでやりたいかなどに依存

>>405
軽いものなら例えばこれだけ
fn main() {
　let val = futures_lite::future::block_on(async {
　　...
　});
}
419 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 13:49:24.53 ID:hXp0LcUB.net]: pollを自分で呼ぶコードは悪手とかなんとか主張する人間と
そのコードに警告もしないコンパイラを
比較できるのがRustの楽しいところで
リソースを節約する話などは人間と人間の論争でありRustに責任はない
420 名前：デフォルトの名無しさん [2024/02/07(水) 19:07:50.52 ID:tO9J4ky9.net]: C++に安全の責任はない <
421 名前：br> Pythonに動作速度の責任はない Brainfuckにリソース節約の責任はない Rustにリソース節約の責任はない []: [ここ壊れてます]
422 名前：デフォルトの名無しさん [2024/02/07(水) 19:08:11.49 ID:tO9J4ky9.net]: うーん
423 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 19:08:14.90 ID:e4qAQ6ae.net]: >>366
ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。
424 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 19:15:08.54 ID:p3QVKrD0.net]: >>412
リソース節約の責任って何？
リソース節約の責任があるプログラミング言語が存在するの？
425 名前：デフォルトの名無しさん [2024/02/07(水) 19:30:42.71 ID:DWMhsuR7.net]: >>412
何の面白味もないな
426 名前：デフォルトの名無しさん [2024/02/07(水) 19:49:16.82 ID:tO9J4ky9.net]: >>415
リソース節約の責任の定義は>>411に聞くべきでは？
427 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 20:05:00.19 ID:oFnccM2b.net]: そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。
428 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 23:23:34.90 ID:BkEIpOIl.net]: 言語の形式的なルールと実利を同一視するのは
ルールを守れば必ず報われるべきってことじゃないか
でもルールを守ることと勝つことは難易度が全然違う
429 名前：デフォルトの名無しさん mailto:sage [2024/02/07(水) 23:47:29.64 ID:Y7NjV+uy.net]: Rustの駄目なところ
コンパイルが遅い
コンパイル時間を含めたらPythonのが圧倒的に速い
430 名前：デフォルトの名無しさん [2024/02/08(木) 00:07:22.21 ID:5/bJ8Q79.net]: >>420
すごいでちゅねー
431 名前：デフォルトの名無しさん [2024/02/08(木) 01:41:05.03 ID:2eX+Xi95.net]: Googleがプログラミング言語「Rust」に100万米ドルを助成、「C++」との併存・置き換えを図る
https://forest.watch.impress.co.jp/docs/news/1566662.html
432 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 04:23:52.18 ID:vwr7y0Aq.net]: >>420
みっともないからルビガイジみたいなレス乞食やめろよ
433 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 04:49:47.24 ID:TVrzLD8V.net]: ルビガイジって何？
434 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 07:47:36.74 ID:guCqNZzs.net]: 何にでもruby推してくる変な人の事じゃね？
435 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 10:03:29.26 ID:5zPu7Sf5.net]: >>414
フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし
436 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 10:24:35.32 ID:TVrzLD8V.net]: >>426
直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。
少人数で運用しているシステムだとクライアントとサーバーがある程度に
共通のスキルセットで構築できたほうがいいってこともある。
それがデメリットを上回るほどのメリットかどうかは状況によるけど。
437 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:09:04.39 ID:ug5u5xxX.net]: gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ
438 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:31:37.22 ID:LLz4mv+z.net]: シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ
439 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:39:36.57 ID:+yfo15bd.net]: スキルセットが一番発揮されるのはコード実装前の設計段階だよ
アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？
実装段階に入ったらあとは作業
フロント担当サーバー担当それぞれが実装する
フロントとサーバーはお互いに入出力のAPIだけ知ってればいい
言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ
440 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:43:32.12 ID:ug5u5xxX.net]: >>429
そんなんprotobufかjsonのどっちかだろ
当たり前すぎてデータをどう送受信するかの話をしてたわすまん
441 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:47:52.48 ID:ug5u5xxX.net]: あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？
442 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 12:58:22.52 ID:L2e7Z7sZ.net]: それら全て些細な問題でどうでもいい
通信でもファイルでも何でも
APIやフォーマットさえ決められていればよい
どの言語かどのフレームワークやライブラリかなんて一切関係なく自由
443 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:08:16.93 ID:aB2xl6fL.net]: >>426
一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。
444 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:14:50.58 ID:ug5u5xxX.net]: 自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ
>>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない
445 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:16:12.56 ID:L2e7Z7sZ.net]: もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある
もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する
具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合
従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある
446 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:27:14.44 ID:21XfFHH6.net]: 人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある
このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない
447 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 13:39:56.20 ID:557abryP.net]: unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね
448 名前：デフォルトの名無しさん [2024/02/08(木) 13:40:27.02 ID:wg4U7wDf.net]: バイリンガルでないプログラマ、Javaしか書けなそう
449 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:05:04.22 ID:u09hDjq1.net]: Java界隈では未だにXMLが現役なのかな
一時期は全てがXMLだったけど最近触れる機会がない
450 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:06:53.53 ID:0U3NNgcj.net]: jsonの後にxml使うとデータの無駄が気になる
451 名前：427 mailto:sage [2024/02/08(木) 14:06:56.11 ID:TVrzLD8V.net]: >>430
「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。
452 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:22:34.49 ID:TVrzLD8V.net]: ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。
XML の万能さは他には代えられない便利さはある。
ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。

XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、
そういうのを活用すればそれほど過剰に冗長なわけではない。
453 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:33:58.18 ID:d7zFncjn.net]: >>436
例えがフロントエンドって急にレベル下がってワロタ
454 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:44:36.25 ID:K+TPHqwf.net]: >>431
ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない
↓ここでいうRaw Struct的なものが今でも使われてる
https://flatbuffers.dev/md__benchmarks.html

言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しま
455 名前：ない []: [ここ壊れてます]
456 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:50:39.80 ID:L2e7Z7sZ.net]: >>444
ならばプロコトル以外で
サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ
457 名前：デフォルトの名無しさん [2024/02/08(木) 14:52:06.22 ID:ZTHDKZhp.net]: >>440
早くxmlは滅んで欲しい。
458 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:52:54.34 ID:TVrzLD8V.net]: シリアライズやパースのコストは小さくはないけど、
メモリコピーのコストが多くを占めているという発見から
なるべくコピーを減らしたシリアライズの規格として message pack が
実行性能と可搬性を (ある程度に) 両立したものとして人気がある。

まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。
ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。
459 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 14:58:14.76 ID:ug5u5xxX.net]: >>445
まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう

てかデータ記述言語の話なんざクソほどどうでもいいんだが
460 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:04:17.46 ID:2EtcR70r.net]: xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ
461 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:04:23.12 ID:d7zFncjn.net]: >>446
一昔前の分散オブジェクトシステムは大抵それだぞ
COBRAとか
そういう設計古くさいから基本的にやらない
462 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:14:54.75 ID:ug5u5xxX.net]: >>438
ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった
小規模サーバー用途ならそれで十分そう
463 名前：デフォルトの名無しさん [2024/02/08(木) 15:16:59.91 ID:ZTHDKZhp.net]: クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。
発端は >>426 あたりかな。
464 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:26:56.26 ID:L2e7Z7sZ.net]: >>451
分散オブジェクトの話とは状況が全く異なる
ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術
これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう
両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化
465 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:32:31.05 ID:d7zFncjn.net]: >>454
別にお前のお気持ちは聞いてないよ
466 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:34:25.91 ID:L2e7Z7sZ.net]: >>455
気持ち？
理解していないようなので現在のウェブ界での動向を伝えただけだが
467 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:39:43.48 ID:lShPsUxC.net]: >>454
それwasmってやつ？ファイルサイズがjavascriptより大きくならない？
468 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:46:12.86 ID:rcfTmCHH.net]: フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？
469 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:52:25.19 ID:VkQAw5RB.net]: javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ
470 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 15:57:01.04 ID:z3sGsuBj.net]: nodejsで済むサーバーって自宅サーバーか何かか?
471 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:06:02.61 ID:34mhb8ps.net]: >>457
一般的には何をするかに拠る
レンダリングコード共通化の話ならばその部分については誤差範囲

>>458
あまりにも基礎知識が無さすぎるようなので
SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい
472 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:07:53.03 ID:d7zFncjn.net]: >>456
いやそれが余計なんだって
next.js app router+rust使ってる俺に対してする説明ではない
473 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:08:25.23 ID:34mhb8ps.net]: >>459
>>460
そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない
しかしそれらは遅いからサーバーサイドはRust化すべきだろう
つまりレンダリング共通コードもRustで統一すべき
474 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:43:53.73 ID:ug5u5xxX.net]: WASMはあまりにアセンブリ言語すぎる
watで直接WASMを書いてコンパイルするのが一番バイナリのファイルサイズを抑えられるけど大変
watじゃなくて他の言語で書くにしてもstd使うとファイルサイズが爆増する
既存のライブラリをWASM化するならともかく、既存のJavaScriptコードをstd有りで書き直すのは、ファイルサイズがJavaScriptのときと比較して増えて本末転倒だからJavaScriptのままでいい
watやRust with no-stdでWASMを頑張る人は頑張って
475 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 16:54:49.99 ID:GUaqsUfs.net]: >>459 >>460
今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ
Next.jsやNuxt.jsなどの名前を聞いたことないですか？
476 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:10:13.67 ID:ug5u5xxX.net]: だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん
477 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:15:11.69 ID:TVrzLD8V.net]: >>464
規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。
大規模化するウェブアプリケーションが想定されているから
JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。
そうじゃないときがあるって話なんだよ。
478 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:20:27.37 ID:K+TPHqwf.net]: 1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか
そりゃ話が噛み合わないわなぁ
479 名前：デフォルトの名無しさん [2024/02/08(木) 17:26:24.69 ID:Z/Y0D/hR.net]: 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
480 名前：デフォルトの名無しさん [2024/02/08(木) 17:26:27.02 ID:Z/Y0D/hR.net]: 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
481 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:33:18.45 ID:wPAPAJoC.net]: >>467
その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ
482 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:42:32.82 ID:EBOg13nx.net]: >>464
Wasmではfsなど必要ないのだから
no_stdで全く問題なくプログラミングできます
Rustの基本はほとんどcoreに入っています
allocを使えばVecやStringも使えます
あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます
一度no_stdでプログラミングしてみることをオススメします
483 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:44:09.24 ID:EBOg13nx.net]: >>471
いえいえ
Wasmのファイルサイズはそんな巨大になりません
484 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:55:44.80 ID:TVrzLD8V.net]: Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。

いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。
485 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 17:56:24.51 ID:ug5u5xxX.net]: >>472
いやー、watでいいかな
486 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:26:36.73 ID:d7zFncjn.net]: Figmaはecmascripten使ってるそうだよ
C++で書いてWebGL用にコンパイル
おそらく世界最大のwasmコードだろう

https://www.figma.com/ja/blog/webassembly-c
487 名前：ut-figmas-load-time-by-3x/ []: [ここ壊れてます]
488 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:29:10.38 ID:d7zFncjn.net]: 今のところrustよりはecmascriptenの方が既存コードを活かせる
489 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:37:22.37 ID://05Mhwl.net]: >>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？
490 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:41:39.17 ID:d7zFncjn.net]: >>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね
491 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 18:54:05.90 ID://05Mhwl.net]: >>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね
492 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:25:31.03 ID:QINBs586.net]: 単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。
493 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:29:46.46 ID:0U3NNgcj.net]: 途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん
494 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:34:55.22 ID:XA34Vq7w.net]: >>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな
495 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:38:03.57 ID:XODN4PGj.net]: next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ
496 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 19:54:29.48 ID:vWC2S6ww.net]: サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案
497 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 20:01:51.28 ID:ZqeEswjg.net]: Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ
498 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 20:03:16.79 ID:XODN4PGj.net]: それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった
499 名前：デフォルトの名無しさん [2024/02/08(木) 20:29:26.04 ID:ZTHDKZhp.net]: >>464
forthみたいで面白くない？
500 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 21:09:57.90 ID:iGefvq8R.net]: Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ
501 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 21:15:13.68 ID:fAoXwANU.net]: >>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある
502 名前：デフォルトの名無しさん mailto:sage [2024/02/08(木) 22:03:30.31 ID:z3hLjd3o.net]: もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ
503 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 00:17:38.71 ID:tjbjc/kZ.net]: 今はRuby on Rails でも、React/Next.js, TypeScript が転職で必須。
少し前は、Vue.js だったけど、Vue 3 は流行らなかった

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

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

これで、Reactに取られたシェアを回復する
504 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 06:07:49.74 ID:79P7yOqB.net]: >>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？
505 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 07:43:30.04 ID:uUxbU3bY.net]: Ruby信者はズレてるから仕方ない
506 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 07:53:26.10 ID:cmMrL7Ws.net]: SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい
507 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 08:55:44.38 ID:so08h4Qi.net]: SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう
508 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 09:34:26.12 ID:Kdv0HxUE.net]: std::any::type_name_of_val()は学習時にも良さそ
509 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 09:59:55.75 ID:so08h4Qi.net]: 昔から使えるよ
fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str {
　std::any::type_name::<T>()
}
510 名前：デフォルトの名無しさん [2024/02/09(金) 10:27:55.96 ID:C39eXNkM.net]: >>493
JS使った方が楽という感覚は理解できんわ
511 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 13:19:22.70 ID:YdTAf9YB.net]: >>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？
512 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 13:59:04.29 ID:wfDAL7tm.net]: リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ
513 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 14:16:42.17 ID:YdTAf9YB.net]: >>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった
514 名前：デフォルトの名無しさん [2024/02/09(金) 15:05:02.67 ID:7wM1u29W.net]: どんどんrustの話から離れていってんな
515 名前：デフォルトの名無しさん [2024/02/09(金) 15:19:56.77 ID:d4LbU2O8.net]: SSRやCSRがややこしいと感じる意味がわからん
Next.jsのPage Router時代の区別がややこしかったと感じてるだけとちゃう？
特定の実装とは関係のない概念としてのSSRやCSRは別にややこしくも何ともないでしょ

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

ついでに言うとHotwireみたいなのも仕組みとしての基本的な考え方は同じ
516 名前：デフォルトの名無しさん [2024/02/09(金) 15:26:09.73 ID:wyTCEkUp.net]: Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ
517 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 15:36:06.60 ID:gZOHhCrR.net]: >>505
型システムとの兼ね合い。
518 名前：デフォルトの名無しさん [2024/02/09(金) 15:38:36.69 ID:ixshWTAh.net]: >>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス

マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う
519 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 15:52:26.69 ID:IKpgt5UR.net]: next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね
520 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:25:40.87 ID:YdTAf9YB.net]: >>504
その発想だとサーバーアクションは説明できないよ
521 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:28:31.07 ID:YdTAf9YB.net]: >>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる
522 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 16:37:49.82 ID:DOCRBofH.net]: >>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい
523 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 17:13:49.98 ID:wfDAL7tm.net]: >>510
同感
524 名前：デフォルトの名無しさん [2024/02/09(金) 18:59:39.30 ID:wyTCEkUp.net]: C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？
525 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 19:22:48.34 ID:6IeD8Xf6.net]: 実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。
526 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 19:24:12.28 ID:6IeD8Xf6.net]: あ、可変長引数の話とオーバーロードの話を混同してしまっていた。
527 名前：デフォルトの名無しさん [2024/02/09(金) 19:32:53.51 ID:RpHX5dqz.net]: https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4
こういうの知ってたら
オーバーロードもデフォルト引数もいらね～
どうしてもほしけりゃ別名の関数作るわ
ってならん？
528 名前：デフォルトの名無しさん [2024/02/09(金) 19:45:04.86 ID:qkcXaSLH.net]: 別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので
529 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 20:35:29.36 ID:gZOHhCrR.net]: 田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。
530 名前：デフォルトの名無しさん [2024/02/09(金) 23:53:50.41 ID:qm1w3dJY.net]: オーバーロードは無くてもいいけどキーワード引数は欲しいかな
531 名前：デフォルトの名無しさん mailto:sage [2024/02/09(金) 23:59:48.02 ID:D/1cks9J.net]: >>519
あるよ
X { name: "foo", num: 123, ... }
532 名前：デフォルトの名無しさん [2024/02/10(土) 02:54:22.21 ID:rfU+NtYa.net]: >>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ
533 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:13:20.91 ID:KcmgHb9l.net]: >>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある
534 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:40:29.45 ID:d2BF2Jtb.net]: Rustでなぜデフォルト引数がサポートされてないのかはここでよろしく
https://www.reddit.com/r/rust/comments/fi6nov/why_does_rust_not_support_default_arguments/
535 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:50:58.48 ID:lXB6J68A.net]: 構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ
536 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 09:54:14.05 ID:Lf9bQLCg.net]: ビルダーパターンは自分で書くならめんどい
537 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:07:03.72 ID:iJNhxzEm.net]: >>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌
538 名前：デフォルトの名無しさん [2024/02/10(土) 10:08:52.95 ID:QvZInASK.net]: ADAってどう？
539 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:22:50.56 ID:iJNhxzEm.net]: Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって
540 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:33:01.11 ID:VP+Iax6j.net]: >>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな
541 名前：デフォルトの名無しさん [2024/02/10(土) 10:33:37.95 ID:2jz47bNZ.net]: パターンとかきしょすぎ
Javaみてえな文化
542 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 10:36:17.39 ID:VP+Iax6j.net]: >>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから
543 名前：デフォルトの名無しさん [2024/02/10(土) 11:15:35.75 ID:6T66/lvp.net]: >>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは
544 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:20:28.46 ID:iJNhxzEm.net]: >>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので
545 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:21:55.77 ID:xcSAMi5J.net]: キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな
546 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:24:20.16 ID:iJNhxzEm.net]: キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て
547 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:32:26.22 ID:iJNhxzEm.net]: パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ
548 名前：デフォルトの名無しさん [2024/02/10(土) 11:53:44.03 ID:H5a70urg.net]: >>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない
549 名前：デフォルトの名無しさん [2024/02/10(土) 11:54:44.92 ID:H5a70urg.net]: 可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ
550 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 11:57:02.97 ID:iJNhxzEm.net]: >>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか
551 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:00:29.93 ID:iJNhxzEm.net]: >>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから
552 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:04:27.79 ID:09Czk/ru.net]: >>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい
553 名前：デフォルトの名無しさん [2024/02/10(土) 12:09:31.06 ID:H5a70urg.net]: まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か
554 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:12:05.42 ID:X5MB5Dp7.net]: >>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ
555 名前：デフォルトの名無しさん [2024/02/10(土) 12:13:49.11 ID:H5a70urg.net]: Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも
556 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:18:46.21 ID:Gv6WNLHY.net]: デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ
557 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:30:54.19 ID:iJNhxzEm.net]: パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる
558 名前：デフォルトの名無しさん mailto:sage [2024/02/10(土) 12:33:11.47 ID:lBFnzKPs.net]: いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている
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