■ このスレッドは過去ログ倉庫に格納されています
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 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2024/01/20(土) 23:30:59.71 ID:YXP1l1jf.net
- Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
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/
- 4 ：デフォルトの名無しさん：2024/01/21(日) 19:52:38.28 ID:/dcZ0aWP.net
- Rustを理解していく順序 (文法以外)
ownership
↓
lifetime (これ以前でも参照を持ち越さない範囲で可)
↓
trait (これ以前でもライブラリ既存traitメソッド使用は可)
generic (これ以前でもライブラリ既存genericメソッド使用は可)
↓
macro (これ以前でも既存macro使用は可)
async (これ以前でも同期で使用可)
↓
unsafe (ほとんどのことはunsafeを使わずに可能)
もしunsafeを使わないと効率よく実装できない安全なパターンを見つけて、
かつ、それが既存ライブラリに存在しない新たなパターンならば、
それは大発見だから皆のためにそのcrateを公開すべし
- 5 ：デフォルトの名無しさん：2024/01/21(日) 20:27:09.29 ID:D3jVm/Ct.net
- 今、refと&で混乱してるとこ！
- 6 ：デフォルトの名無しさん：2024/01/21(日) 20:58:34.51 ID:RjmgKxew.net
- オーナーシップとかAIにやらせればOK
意識して時間割く必要なし
- 7 ：デフォルトの名無しさん：2024/01/21(日) 21:23:48.87 ID:/dcZ0aWP.net
- >>5
パターンマッチングはCopy実装型はcopyされてそれ以外はmoveされる
copyやmoveを避けるには
マッチング対象を参照にすれば
全て参照として受け取れる
しかしある部分はcopyである部分は参照で受け取りたいことがよくある
(例えば数値とStringで構成されてる場合)
その時は参照で受け取りたい部分のみrefを付けるとそこは参照で受け取れる
- 8 ：デフォルトの名無しさん：2024/01/21(日) 21:33:08.24 ID:LhOQKlqN.net
- >>5
refはbind by reference
左辺(相当)でのみ使う(binding生成時のみ)
右辺で&を使うのと同じだけど右辺で&を指定できない場面で使う
&を左辺で使うとパターンマッチでデリファレンス
右辺で*を使うのと基本同じ
- 9 ：デフォルトの名無しさん：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
- 10 ：デフォルトの名無しさん：2024/01/21(日) 22:51:42.90 ID:w4jDa8WO.net
- >>9
無意味な揚げ足取りをしてRustを叩きたい人はアンチスレへ
棲み分けしてください
Rustアンチスレ
https://mevius.5ch.net/test/read.cgi/tech/1509028624/
- 11 ：デフォルトの名無しさん：2024/01/22(月) 00:47:14.54 ID:jqH5vdYX.net
- 仕様バグだから直せないじゃなくて
厳密なチェックをする実装は0から作ったほうが早いから
今使ってる確率的(笑)な実装は変更しないんだよね？
- 12 ：デフォルトの名無しさん：2024/01/22(月) 03:17:34.54 ID:laN06gwL.net
- これマジ？ どれくらいの確率で踏むんけ？ コンパイルのバクはケアしたくないなあ
- 13 ：デフォルトの名無しさん：2024/01/22(月) 04:28:43.80 ID:DrvqbiCd.net
- >>12
意図的にvarianceの穴を突く無意味なコードを書かないと発生しないため>>9は無害
- 14 ：デフォルトの名無しさん：2024/01/22(月) 09:21:43.10 ID:k43UrEGh.net
- >>9
こんなコンパイラの脆弱性を突くようなコードを普通なら書かない定期
- 15 ：デフォルトの名無しさん：2024/01/22(月) 21:22:44.12 ID:m6FRVxec.net
- >>9は9年前の2015年から既知の有名なパターン
意味のあるプログラミングで絶対に踏むことはないため害はない
その特殊ケースに対応するデメリットの方が大きいため対策されていない
それらを踏まえたうえでIT大手が揃ってRustを採用しRust Foundationも設立された
- 16 ：デフォルトの名無しさん：2024/01/22(月) 21:31:04.02 ID:l2He84BH.net
- 9のコードの意味が理解できないんだが何が問題なのか説明してくれ
- 17 ：デフォルトの名無しさん：2024/01/22(月) 22:53:37.35 ID:6ImN7JeY.net
- c++のテンプレートはチューリングマシンだから
無限ループを起こせるのは仕様の欠陥がどうか聞きたい
- 18 ：デフォルトの名無しさん：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 () の部分で変なことが起きてそうと言っとるな。
- 19 ：デフォルトの名無しさん：2024/01/22(月) 23:14:04.77 ID:T1sqP3ZB.net
- >>17
C++ の仕様ではテンプレートの展開深度に上限を設定することを認めているのでチューリングマシンではない。
非現実的な回数のループが起こるのならそれは処理系の欠陥。
- 20 ：デフォルトの名無しさん：2024/01/22(月) 23:41:39.76 ID:NA4FP1NO.net
- >>15
1.65.0で新しく導入された回帰バグですって書いてあるし
2015年の#25860とも別だねってコメントも付いてますやん
- 21 ：デフォルトの名無しさん：2024/01/23(火) 00:35:34.27 ID:AizsfBYE.net
- >>18
文脈無視してその引用だけで言えそうなことは
&'static &'s T 型が存在するならば 's も 'static でなければならない
このルールに反しない限り &'s str を &'static str に変換してよい
- 22 ：デフォルトの名無しさん：2024/01/25(木) 23:09:32.35 ID:iPN7/qe+.net
- 安全にこれで&'staticへ変換できる
fn to_static_str(s: &str) -> &'static str {
s.to_owned().leak()
}
- 23 ：デフォルトの名無しさん：2024/01/26(金) 23:31:43.19 ID:ZBdWgzp4.net
- 最後までずっと使うものやあるいは
あるメモリ限度内に収まる使い方ならば
リークさせて扱いが楽になるメリット享受を選ぶのもありかもな
- 24 ：デフォルトの名無しさん：2024/01/27(土) 23:34:17.17 ID:kvD8ZR3g.net
- >>22
それ&'static strではなく&'static mut strを返してもええねんで
- 25 ：デフォルトの名無しさん：2024/01/28(日) 02:18:12.19 ID:tZGISO28.net
- >>22
leakって安全なの？
- 26 ：デフォルトの名無しさん：2024/01/28(日) 04:27:59.88 ID:2343IlJN.net
- leakは安全
そのプログラム終了まではその部分のメモリを解放しないだけ
- 27 ：デフォルトの名無しさん：2024/01/28(日) 08:32:52.16 ID:hRRbWEE/.net
- >>25
Rust の定義ではメモリリークは安全性を損なわないことになってる。
言語の機能として積極的に阻止しなければならないような動作ではないが、
だからといってむやみにリークさせていいわけでもないのは当然なので
そこらへんはロジック上の必要性を鑑みて「正しく」運用するのはプログラマの責任だよ。
- 28 ：デフォルトの名無しさん：2024/01/28(日) 12:34:08.20 ID:tZGISO28.net
- leakは参照を削除するとメモリリークになると書いてあった（機械翻訳）けど参照って削除できるの
- 29 ：デフォルトの名無しさん：2024/01/28(日) 13:17:17.43 ID:lA5rY1V0.net
- >>28
原文は何て書いてるのさ
- 30 ：デフォルトの名無しさん：2024/01/28(日) 14:30:03.90 ID:WlHw4mUK.net
- 期待した通りの結果になるのは危険ではないという知見は合理的だ
期待や願望よりも地獄のような厳しい現実にこだわるバイアスがかかってない
- 31 ：デフォルトの名無しさん：2024/01/28(日) 15:17:37.40 ID:2343IlJN.net
- >>28
leak()は所有者がいなくなるだけ
つまりそのメモリ領域が解放されなくなるだけで安全な行為
そこを指す参照だけになる
一般的に参照は指しているだけ
その参照を表す変数もしくは一時的な値が消えればその参照は消えたことになる
参照が消えても実体には何ら影響なく解放なども生じない
- 32 ：デフォルトの名無しさん：2024/01/28(日) 18:26:28.82 ID:WlHw4mUK.net
- メモリリークにならない＝参照がデストラクタを呼び出せる
ではなく
参照はデストラクタを呼べないが、参照が永久に残ればメモリリークにならない
- 33 ：デフォルトの名無しさん：2024/01/29(月) 23:08:47.69 ID:GnLHDaEQ.net
- メモリリークは多義なので
GC言語でも、今後は使わないオブジェクト等をどこが参照しているため解放されない、これもメモリリークと言う
つまり参照が残っているからメモリリークじゃないとは言えない
逆にRustの場合は、leak()を適用した時点でそこは永久に解放されないのだから、既にメモリリークとも言える
もちろんそれで困らない時に意図的にリークを可能とするものなので、その機能や行為自体に問題はなく、そのプログラムの性質や環境や方針次第
- 34 ：デフォルトの名無しさん：2024/01/30(火) 02:10:08.22 ID:gYzmItMj.net
- 多義である事実に人間が従うのではなく、定義を変えたいので変えまくった人間に事実が従う
利己主義の結果を予想するのではなく結果を予想できる範囲内で利己的になる
- 35 ：デフォルトの名無しさん：2024/01/30(火) 06:01:38.95 ID:lXERqUpG.net
- きちんとメモリ確保・解放する
ただそれだけのことだけどうまく行かないものだね
- 36 ：デフォルトの名無しさん：2024/01/30(火) 07:11:49.27 ID:g++Pj77W.net
- >>35
Rustならそれができるし保証される
ただしその基本に加えて融通を利かせることもできる
意図的にリークさせる(解放しない)こともできるしそれを使わないこともできる
意図的に循環参照を作ってリークさせることもできるしそれを避けるための手段も用意している
- 37 ：デフォルトの名無しさん：2024/01/30(火) 11:19:29.95 ID:LgX6lgq1.net
- それくらいできてくれないと習得に対して割に合わない
- 38 ：デフォルトの名無しさん：2024/01/30(火) 23:08:46.90 ID:shd55QRp.net
- >>35
二回以上解放しない保証は大成功した
一回以上解放する保証をやる気がない
与えられた問題を勝手に分割してやりたい部分だけやってる
- 39 ：デフォルトの名無しさん：2024/01/31(水) 05:41:08.45 ID:XSmS7DeM.net
- Rustでは意図的にリークもしくは意図的に循環参照作成の場合を除いて必ず解放される
- 40 ：デフォルトの名無しさん：2024/01/31(水) 22:24:17.87 ID:rU+aRD+l.net
- スポーツでも五輪だけが目的のプロがいたら割に合わないが
なんか目的をあやふやにすれば五輪に出ても破産しないよね
- 41 ：デフォルトの名無しさん：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化が増えてきたな
- 42 ：デフォルトの名無しさん：2024/02/01(木) 17:28:29.31 ID:xcOmoIH1.net
- しかしRust流行らんな
- 43 ：デフォルトの名無しさん：2024/02/01(木) 19:27:48.94 ID:6WtKOSai.net
- Pythonやkotlinみたいな手軽さで堅牢で高いパフォーマンスが出れば最高なんだけどなかなかね
- 44 ：デフォルトの名無しさん：2024/02/01(木) 20:38:04.52 ID:XOfXRWXD.net
- from C to Rust へのマイグレーションは時間がかかるからしゃあない
- 45 ：デフォルトの名無しさん：2024/02/01(木) 21:16:53.56 ID:E1I2Gvr8.net
- >>43
Pythonはスクリプトを書く程度ならいいけどプログラミングには不向き
- 46 ：デフォルトの名無しさん：2024/02/01(木) 21:44:37.29 ID:Nzd8TkB/.net
- きちんとガベコレしてるのに見下されてるなあPythonは
きちんとしても割に合わない
- 47 ：デフォルトの名無しさん：2024/02/01(木) 21:53:27.11 ID:7aZ9tAiW.net
- 動的型は堅牢とかきちんとやるみたいなのと相反するんだよな
書き捨てならいいけど長期的にメンテするやつには向いてない
- 48 ：デフォルトの名無しさん：2024/02/01(木) 21:55:25.71 ID:9CL84hYM.net
- Rust、言うほどPythonと比べて手軽でないか？
- 49 ：デフォルトの名無しさん：2024/02/01(木) 22:17:59.13 ID:B5mxz6YT.net
- プログラマの意図を書かないと、意図を表せる言語じゃないと「正しい」かどうかは検証しようがない。
だから意図の表現方法として型やライフタイム注釈やらの形を確立したのであって、お手軽に柔軟に動かす言語では実行時に不都合があれば止まるという形にならざるを得ない。
静的型があれば全部が解決ってわけではないけどごく基本的な整合性検査すらせずに実行するまでわからんというのはメンタル的にきつい。動的型はきつい。
自分で把握できる程度の小さな規模なら動的型のほうが楽ってこともあるといえばあるけど、人類は駄目なのでちゃんと把握できる規模は自分で思っているよりだいぶん小さい。
- 50 ：デフォルトの名無しさん：2024/02/01(木) 22:29:20.68 ID:wp2DoW25.net
- Pythonはやっぱり行列を扱うのに長けてる気がするな
ただ静的には何の変数を見ても(Variable)xxx: Anyみたいな型推定しかされていなくて、自分の書いたコードですら訳がわからなくなる
他人の書いたライブラリを使うときはまるで魔法を使ってるかのようだ
- 51 ：デフォルトの名無しさん：2024/02/01(木) 22:40:37.81 ID:Nzd8TkB/.net
- Pythonというかインタプリタは部分的にCを使うことを認めざるをえない
それを大多数に納得させるコストが激安
- 52 ：デフォルトの名無しさん：2024/02/01(木) 22:42:10.75 ID:tu2Yd+rZ.net
- >Pythonはやっぱり行列を扱うのに長けてる気がするな
pythonのどこが？numpyがあるだけじゃね。
- 53 ：デフォルトの名無しさん：2024/02/01(木) 22:45:58.52 ID:E1I2Gvr8.net
- PythonはC/C++/Rustで書いたライブラリを呼び出すスクリプト言語として使っている限りは問題ない
プログラミング言語としては不向きで使うべきではない
- 54 ：デフォルトの名無しさん：2024/02/01(木) 22:54:05.96 ID:Nzd8TkB/.net
- OSのカーネルにはPythonは不向きだからクソどうでもいい生存競争をしなくてすむ
- 55 ：デフォルトの名無しさん：2024/02/01(木) 23:06:17.91 ID:0Yigz0zQ.net
- 使い分けが出来ない人はスキルが低いだけ
言語に限らずどの技術でも同じこと
- 56 ：デフォルトの名無しさん：2024/02/01(木) 23:13:02.07 ID:iVey9ypb.net
- 各種カーネルのRust移植に時間かかってるけどC/C++からRustへの書き直しってそんなに大変なの？
- 57 ：デフォルトの名無しさん：2024/02/01(木) 23:14:24.05 ID:h0D2/F6d.net
- Pythonもプログラミング言語だしシェルスクリプトも立派なプログラミング言語だよ
- 58 ：デフォルトの名無しさん：2024/02/01(木) 23:23:51.23 ID:itS/z8tN.net
- プログラミング言語はそれに付随するフレームワークの質で需要が変わってくるけど、
C/C++/Rust/アセンブラなど低水準言語はガべコレのランタイムが不要というアドバンテージがある
だからカーネル用途での需要が高い
- 59 ：デフォルトの名無しさん：2024/02/01(木) 23:26:15.91 ID:B5mxz6YT.net
- Ruby もだいぶん長いことバイトコード化すらせずに木を辿るクソ遅い設計だったんだぞ。
でもなあ、使い分けといってもやっぱり慣れたらもうちょっと他の場所でも使いたくなるし、速度の要求も静的検証の要求も出てくる。
今の Ruby は Jit で速くなったし型チェックのサポートも本格的になった。
使い分けは要るがせずにすむならそれに越したこともないんよ。
- 60 ：デフォルトの名無しさん：2024/02/01(木) 23:26:33.20 ID:8nChHaP8.net
- >>56
そのまま移植はほぼ不可能でしょ
データ構造から設計しなおさらないと
クソコードになりがち
- 61 ：デフォルトの名無しさん：2024/02/01(木) 23:33:40.62 ID:B5mxz6YT.net
- C の世界の文字列はゼロ終端やんか。
カーネルのインターフェイスにもその規約がそのまま現れてる。
内部的な設計は Rust 的にしつつも外向きのインターフェイスは変えないように置き換えるなら微妙な変換があらゆるところに出てくるよ。
まあそのへんは適当な専用フレームワークを確立させればたいしたことでもないが、そういう地味なことの積み重ねがいっぱい要るよ。
- 62 ：デフォルトの名無しさん：2024/02/02(金) 00:29:39.63 ID:wYh3cvfE.net
- C/C++からJavaってのはすげー移植しやすかったのよ
その利点はほとんどないと多くの人が気がつくのに20年もかかってしまったけど
- 63 ：デフォルトの名無しさん：2024/02/02(金) 00:36:47.62 ID:iO9F+zBT.net
- >>56
書き直しさえすれば何でもいいというのは大変だろうね
何でもいいというのは嘘で
本当は好き嫌いがあるから
- 64 ：デフォルトの名無しさん：2024/02/02(金) 01:16:00.31 ID:fEMhv+T7.net
- コード移植なんてつまらなくて言語差で面倒なだけ
守るべき仕様さえはっきりしてるならゼロから書いたほうが結果的に早くて質も良くて楽しい
- 65 ：デフォルトの名無しさん：2024/02/02(金) 01:28:41.76 ID:iO9F+zBT.net
- 仕様とか契約とか目的とかは未来を予測する根拠としてはイマイチ科学的でない
- 66 ：デフォルトの名無しさん：2024/02/02(金) 01:38:03.89 ID:ZFQgO+dm.net
- Linux だとバイナリ互換性もかなり大事にしてる。
(Windows ほどじゃないが。)
仕様として明文化してない挙動に依存するアプリケーションであっても今まで動いていたものが動かなくなるのは良くないという方針。
「守るべき仕様がはっきりしていれば」という前提がなりたたないから困るんだよ。
そしてそれはよくあること。
- 67 ：デフォルトの名無しさん：2024/02/02(金) 01:40:32.02 ID:fEMhv+T7.net
- ときどき仕様も要件定義もはっきりせず発注者が把握できていないものの言語移植ケースがあるがその仕事を引き受けないほうがいい
バグらしきもの含めて現存コードと同じ動作をするよう求めてくるためムダな面倒に精神力が奪われる
- 68 ：デフォルトの名無しさん：2024/02/02(金) 11:04:47.16 ID:VI0tbigR.net
- 仕様さえ守っていればいいみたいな考えに従うと最近はお役所系でもちらほら見るクローム以外を
排除する極右Webサイトが出来上がったりするんだろうな。発注側でも受注側でもね
- 69 ：デフォルトの名無しさん：2024/02/02(金) 11:10:52.47 ID:BQKaaqcl.net
- ちゃんと充分な調査費用も出るならやらんでもないけどな。
大きなシステムの一部をリライトする場合には一から作る場合より数倍のコストがかかっても
全体をやり直すよりはマシだから「同じもの」を求めるのはそれなりに合理性がある。
全部をリプレイスするのに前と同じという要求するやつがいたら、
前と同じがいいならそのまま使っとけやという気持ちになる。
- 70 ：デフォルトの名無しさん：2024/02/02(金) 11:38:15.79 ID:cSpiCBqt.net
- C/C++→Rust 安全化とそのデバッグ開発効率化
C/C++以外→Rust 高速化と省メモリ化
これらの恩恵があるため
安全でないことによるバグ発生で困っているならC/C++→Rustを
CPUメモリリソース削減が求められてあるならC/C++以外→Rustを
たとえ同じ仕様のままでもやる意味が生じる
- 71 ：デフォルトの名無しさん：2024/02/02(金) 12:27:55.82 ID:ndCfDt6c.net
- >>70
費用対効果考えると厳しいな。
c++のプロジェクトをRustに切り替えるよりか、コーティング規約組んでlint用意して強制したほうが効果高そう。
既存コードの扱いが難しいけど。
- 72 ：デフォルトの名無しさん：2024/02/02(金) 13:20:50.14 ID:ujySZ5KU.net
- Webアプリ用途でもAxumやActixがフレームワークとして十分使いやすいから、もっとRustは普及していい
- 73 ：デフォルトの名無しさん：2024/02/02(金) 13:32:21.68 ID:gukHO/4I.net
- c++ から rust に移すなら、その前に c++ コードのリファクタリングとしてmove使用コードに直すだろうし、
それやったらもうそれで良くね？ってなると思うわな。
- 74 ：デフォルトの名無しさん：2024/02/02(金) 15:02:39.89 ID:SOk2CQ22.net
- 言語移植はそのうちAIがなんとかしてくれるんじゃなかろうか
- 75 ：デフォルトの名無しさん：2024/02/02(金) 17:43:40.65 ID:wsXMOW5f.net
- 所有権があるから GC 言語からの移行でも安全になる恩恵はあるんだよなぁ。
ほんとエポックメイキングな言語だよ。
- 76 ：デフォルトの名無しさん：2024/02/02(金) 19:12:44.91 ID:6TGLHO8E.net
- rustの最大のメリットは、絶対では無いけどコンパイルさえ通ってれば他人のクソコードに悩まされずに済む点じゃないかね。
- 77 ：デフォルトの名無しさん：2024/02/02(金) 21:11:58.02 ID:K0BmHg5g.net
- >>76
なんで悩まされないの？
- 78 ：デフォルトの名無しさん：2024/02/02(金) 21:33:43.48 ID:ya0nDY0I.net
- Rustでも糞コード見かける
たとえば非常に単純な例でいうと元の部分strを返せば済むのにString作っちゃうなど無駄にヒープ使ってしまうケース
でも見抜きやすく手直しもしやすい
- 79 ：デフォルトの名無しさん：2024/02/02(金) 21:34:56.76 ID:ya0nDY0I.net
- Rust以外でよく見かけるのはど
こで書き換わっているかわかりにくく副作用や競合が心配なケース
Rustではデータ競合が起きないしグローバル変数も制限があるためこの手の類には悩まされない
- 80 ：デフォルトの名無しさん：2024/02/02(金) 22:24:30.77 ID:BZlEVlBD.net
- メリットが欲しいと思ったことはないな
新しいジャンルで唯一の選択肢なのでメリットの大きさを比較する必要がない
異なるジャンルでは比較する意味がわからない
- 81 ：デフォルトの名無しさん：2024/02/02(金) 22:27:27.20 ID:ASeaHMD6.net
- >>78
1周回ってString返したほうが良くなる状況もあるからそんなに単純じゃないよ
- 82 ：デフォルトの名無しさん：2024/02/02(金) 22:29:00.17 ID:ASeaHMD6.net
- >メリットが欲しいと思ったことはないな
誰もメリットが欲しいかどうかについては話してないよｗ
- 83 ：デフォルトの名無しさん：2024/02/02(金) 22:34:00.04 ID:ya0nDY0I.net
- >>81
それは絶対にない
部分str返しで済むなら必ずそうすべき
それを返された側がString化が必要な時のみ行なう
- 84 ：デフォルトの名無しさん：2024/02/02(金) 22:36:34.16 ID:BZlEVlBD.net
- 欲しくないものを供給している可能性を誰も想定していないのか
- 85 ：デフォルトの名無しさん：2024/02/02(金) 22:47:15.09 ID:P1ceRtbI.net
- わかりやすいのがstr.trim()かな
前後のスペースを取り除く関数だけど当然Stringではなくstrの一部分を返す
Stringがほしい人はstr.trim().to_string()
- 86 ：デフォルトの名無しさん：2024/02/02(金) 22:52:35.98 ID:SRUTe3RO.net
- >>85
欲しい人にもそうでない人にも対応できるように&strがベストとは思わんか？
- 87 ：デフォルトの名無しさん：2024/02/02(金) 22:55:20.18 ID:P1ceRtbI.net
- >>86
同じ主張だよ
str返しが可能ならStringを返してはいけない
slice返しが可能ならVecを返してはいけない
- 88 ：デフォルトの名無しさん：2024/02/02(金) 23:19:45.92 ID:BZlEVlBD.net
- 上書きされる前に別の場所にコピーした方が比較的安全というメリットが消えた
Rustが消した
- 89 ：デフォルトの名無しさん：2024/02/02(金) 23:26:54.37 ID:ya0nDY0I.net
- >>88
Rust以外ではいつ書き換えられたりor解放されたりするかわからないから
安全なプログラミングということで(無駄になる恐れもあるけど)コピーしておく安全策をとることがあった
Rustでは知らぬ間に書き換えられたりor解放されたりすることはないので
安全策を保ったままで無駄なコピーが不要となった
- 90 ：デフォルトの名無しさん：2024/02/02(金) 23:26:59.82 ID:9Dc3A0qD.net
- Stringを使うことで無駄に専有されるヒープメモリはそこまで悪に感じないわ
カーネル作ってるわけでも競技やってるわけでもないんだったらね
可読性のために型を統一させるほうを優先する
- 91 ：デフォルトの名無しさん：2024/02/02(金) 23:34:55.21 ID:v5+jJWMk.net
- >>90
主張がよくわかりません
&strを渡せば済むところをString渡しで統一したりしてるのですか？
それで可読性が上がるとは思えません
- 92 ：デフォルトの名無しさん：2024/02/03(土) 00:06:15.17 ID:zqTPQxFe.net
- >>90
そのためにムダにto_string()やそのclone()をするのは間違い
他の言語やスクリプト言語ですらそんな酷いことは行われずにコピーオンライトやインターン化でムダを防いでいる
Rustではまずは&strで行ける範囲は&strで行き次にCow併用そして同じ中身のStringが複数できるならstring_cacheなどでインターン化など
- 93 ：デフォルトの名無しさん：2024/02/03(土) 00:06:54.99 ID:26gTKyDM.net
- C++でもstring_viewとstringは使い分けるぞ
- 94 ：デフォルトの名無しさん：2024/02/03(土) 00:39:47.95 ID:x4y7pcy2.net
- &strでいいなら&strで返すのが基本だけどプログラム全体を見たときにStringで返したほうがものすごくコードを単純にできる場合がある
アロケーションコストが全く問題にならない状況であれば&strに固執する必要はない
無駄なヒープアロケーションは増えるけど違う観点の無駄を削減してる
トレードオフだよ
型を統一するって話はよくわからんけど
- 95 ：デフォルトの名無しさん：2024/02/03(土) 00:41:39.18 ID:26gTKyDM.net
- そこ気にしないなら普通にスクリプト言語でも使っとけば良いと思うよ
- 96 ：デフォルトの名無しさん：2024/02/03(土) 00:44:03.79 ID:zqTPQxFe.net
- >>94
そんな例は起きない
strを返された側でString化が必要な時のみするのがベスト
- 97 ：デフォルトの名無しさん：2024/02/03(土) 05:44:40.82 ID:/t14gmUC.net
- >>96
そりゃベストはそうだろうけどさ…
c++で言うchar型で良いところをわざわざstdのStringを使うなって話でしょ？
動的メモリ確保になってようがその程度の誤差くらい動けばどっちでもいいわ…
- 98 ：デフォルトの名無しさん：2024/02/03(土) 06:03:57.16 ID:HSW3HPjS.net
- >>95
Rustから一気にスクリプト言語は飛躍しすぎだからスクリプト言語より先にガべコレ付き言語を薦めてくれ
ガべコレ付き言語はヒープメモリを気にしない人にはおすすめだよ
- 99 ：デフォルトの名無しさん：2024/02/03(土) 06:28:46.54 ID:zqTPQxFe.net
- >>97
文字列だけでなく一般的な話
部分スライスを返せば済むところをわざわざVecにして返すことが許されるのか？という話だぞ
これを誤差だと言い張るならRustを使う資格はない
- 100 ：デフォルトの名無しさん：2024/02/03(土) 06:58:55.64 ID:SxNvW1DJ.net
- こだわりの強い人がおるなあ
- 101 ：デフォルトの名無しさん：2024/02/03(土) 07:31:56.62 ID:0zMBHAmc.net
- sliceやstrですむのにVecやStringを使ってしまう人はlifetime parameterを習得できていなくて使えこなせないからだと思うよ
structやfnでlifetime parameterを付けたことのない初心者に多いね
- 102 ：デフォルトの名無しさん：2024/02/03(土) 07:36:46.05 ID:Sa0HPxlU.net
- こういうふうに面倒くさい人がRust使いには多いから普及しないんだろうなあ
アルゴリズムとデータ構造の分野からみてもクッソどうでもいい議論だよ
- 103 ：デフォルトの名無しさん：2024/02/03(土) 07:41:20.05 ID:0zMBHAmc.net
- >>102
アルゴリズムとデータ構造の一番の基本が無駄なコピーをしないこと
- 104 ：デフォルトの名無しさん：2024/02/03(土) 09:16:17.07 ID:EvhZrc0+.net
- strで返せるがあえてStringで返すと良い具体例を出せばいいのではと思った。
- 105 ：デフォルトの名無しさん：2024/02/03(土) 11:13:51.22 ID:26gTKyDM.net
- 富豪的プログラミングしたいならrustは向いてないよ
普通にpythonで十分
- 106 ：デフォルトの名無しさん：2024/02/03(土) 11:17:22.51 ID:3G/0wdmC.net
- でもPythonのDjangoは遅くてゴミじゃん
省メモリ最速のWebアプリ作るならRust一択だわ
- 107 ：デフォルトの名無しさん：2024/02/03(土) 11:17:53.18 ID:JbxU5Bja.net
- 例えばsplitみたいなのはstrで返せるけど、それを大量に呼んで受け側でto_stringをつける場合、
コードがto_stringだらけで見づらくなるとかはあるかな
そういう時にsplit_to_stringみたいな名前でString返すようにしたりはするけど
自分の場合、どっちかっていうとパフォーマンス云々より関数名から内部でアロケーションが連想されるかどうかを重視してる気はする
- 108 ：デフォルトの名無しさん：2024/02/03(土) 11:24:32.59 ID:e0i4PPZm.net
- rustでwebアプリなんてコストかかりすぎでは？ふつーにgoかjava/kotlinかc#で作ればいいじゃん
- 109 ：デフォルトの名無しさん：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だから意識してないのだろうけどさ
本来は意味のないアロケーションであることが多い
- 110 ：デフォルトの名無しさん：2024/02/03(土) 11:32:33.77 ID:XsYnyWq4.net
- >>107
大量であっても&strのままでよいものはString化しない
String化が避けられない場合でも大量ならばイテレータで処理してるはずなので.into()の数は少ないはず
いずれの場合でも関数は&strを返せばすむ
- 111 ：デフォルトの名無しさん：2024/02/03(土) 11:33:55.72 ID:AHA4uyfa.net
- 正しいことが必ずしも正義とはならない、とだけ言っとくわ
- 112 ：デフォルトの名無しさん：2024/02/03(土) 11:36:04.38 ID:XsYnyWq4.net
- >>108
RustでWebは容易かつ向いている
Rustの公式アンケート世界調査でも最多利用はWeb分野
- 113 ：デフォルトの名無しさん：2024/02/03(土) 11:47:22.41 ID:TZcb9n30.net
- rustあんま使ってない人だけど、strはImmutableでstringはMutableなんでしょ？
文字列配列を柔軟に扱いたいときだけstringで色々して、データを受け渡しするときは当然strを使うのがモラルってもんでしょ
immutable_stringはよく知らん
- 114 ：デフォルトの名無しさん：2024/02/03(土) 11:50:08.77 ID:3gDommQf.net
- 今現在Rustが実際に多く使われてる分野って、スクリプト言語の下まわり、ライブラリ高速化だよね
だからそれはWeb用だと言われたらまぁそう
- 115 ：デフォルトの名無しさん：2024/02/03(土) 11:51:38.36 ID:gN1hlXLs.net
- >>112
108だけどそれはasm.jsの代替のwebアセンブリってやつをrustでやってるんでしょ
webアプリとは違うねん
- 116 ：デフォルトの名無しさん：2024/02/03(土) 11:53:33.66 ID:gN1hlXLs.net
- 単なるWebサイトの演算処理の補助用途とWebアプリ用途を一緒にしてほしくない
全然違うねん
- 117 ：デフォルトの名無しさん：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アプリのサーバーサイドとして使われています
- 118 ：デフォルトの名無しさん：2024/02/03(土) 12:09:03.48 ID:3gDommQf.net
- >>117
スクリプト言語のライブラリとしてRust使ってる人はそんなアンケートに答えないし
自分がRust使ってる自覚もないよ
- 119 ：デフォルトの名無しさん：2024/02/03(土) 12:13:31.67 ID:KLdOqrmk.net
- rust開発チーム直々の調査結果なんね
ちゃんとぎひょう記事urlも貼ってくれ
https://gihyo.jp/article/2022/09/rust-monthly-topics-01
- 120 ：デフォルトの名無しさん：2024/02/03(土) 12:17:34.02 ID:XsYnyWq4.net
- >>118
Rustで何を開発しているか？だからそれら別言語の人は関係ない
PythonやJavaScriptなどのライブラリが最近はRustで書かれることが増えたが
その開発者たちもRust利用者全体から見れば少数
一番多いのはWebのサーバーサイド・バックエンド・クラウド
- 121 ：デフォルトの名無しさん：2024/02/03(土) 12:35:09.79 ID:VMbwu+xF.net
- WASMはRustに限らずそんなに大っぴらに普及しないと思う
ゲームエンジンかエンコーダーデコーダーくらいにしか需要がない
GUIとしてのWASMはDOM操作を直接できない時点でゲーム操作用途にしか使えないゴミ、終わっとる
- 122 ：デフォルトの名無しさん：2024/02/03(土) 12:55:06.68 ID:S1lIKTmM.net
- wasmは触ってみりゃ分かるけどjavascriptの演算処理を単にrustで書いてコンパイルしてみると、rustのstdがバイナリに同梱されるせいで移植前のスクリプト状態よりファイルサイズが増加するんだよね
wasmテキスト形式で書くかstdレスなrustで書かなくちゃ本末転倒になる
まあファイルサイズが増加してでも演算処理を高速化したいならいいんだろうけど俺は吐いた
- 123 ：デフォルトの名無しさん：2024/02/03(土) 13:12:09.54 ID:py1fYTT7.net
- >>117
組み込みシステム開発者なんていう有能が溢れるほどいるわけないし妥当な結果ね
にしてもRustがサーバー開発でこんなに占めてるんだねえ
- 124 ：デフォルトの名無しさん：2024/02/03(土) 13:17:12.24 ID:5inMqUOs.net
- >>121
WASMはWebブラウザ内用途だけではないよ
CDNエッジでの利用も増えているね
WASIなどによる拡張でできることは無数に増えてく
>>122
stdは無くてもRustは機能するようにできているよ
例えばスライスやstrはcoreにあるし
VecやStringはallocにあるよ
- 125 ：デフォルトの名無しさん：2024/02/03(土) 13:45:54.96 ID:KLdOqrmk.net
- WASIはモバイルOSあるいはデスクトップOS業界がどう動くかだね
wasmerみたいなWASIランタイムをOSが標準装備してくれるなら、WASIの注目度が上がるし、OSに依らないアプリを手軽に作れる
特にモバイルOSではランタイム同梱によるアプリの肥大化を阻止できる
WASIは今のままではJVMのようにマルチプラットフォームなランタイムの上で動くアプリでしかないから、どっかの有名なプラットフォームが積極的に土台として採用しないと忘れ去られる
UnityでもAndroidでもどこでもいい
- 126 ：デフォルトの名無しさん：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
- 127 ：デフォルトの名無しさん：2024/02/03(土) 14:54:43.97 ID:Xm89AN74.net
- wasm,wasiはコンテナ界隈とかも期待はしてるようだけど確かにまだ早い。
- 128 ：デフォルトの名無しさん：2024/02/03(土) 15:14:19.35 ID:nibYeb0/.net
- あ、俺みたいに用意されたものを使う的な人間の場合ね。
- 129 ：デフォルトの名無しさん：2024/02/03(土) 15:32:51.57 ID:8/wI1v6d.net
- 重さが気になるほどの人気サイト作ってから言えよな。。クソしょーもねーわ。
- 130 ：デフォルトの名無しさん：2024/02/03(土) 18:14:49.92 ID:X6BgdPzu.net
- wasmはブラウザでffmpeg動かすときに使ったことある
- 131 ：デフォルトの名無しさん：2024/02/03(土) 20:39:34.60 ID:em0HMTKL.net
- rustはもっとC#みたいなクラスの書き方が出来れば最高なのになー
- 132 ：デフォルトの名無しさん：2024/02/03(土) 20:58:14.42 ID:JrVgBiwL.net
- >>131
クラスはプログラミング言語の歴史では大失敗作と言われていて
モダンな新言語(Rust, Go, Zig, Nim, etc.)ではいずれもクラスを排除している
既存のクラスのある言語でもカプセル化以外のクラスの機能は使わずにインターフェース等を使うことが推奨されている
Rustのtraitはその中でも最も優れたものなのでRustで困ることはないよ
- 133 ：デフォルトの名無しさん：2024/02/03(土) 21:06:51.84 ID:93RdYvh2.net
- Rustはtraitのドキュメント見た時に
とっ散らかって見えるんだよなぁ
- 134 ：デフォルトの名無しさん：2024/02/03(土) 21:20:55.82 ID:Uoo5j+2b.net
- 何事もタダでは手に入らない
良い面だけしか見ない人はいつまで経っても素人
- 135 ：デフォルトの名無しさん：2024/02/03(土) 21:29:31.74 ID:W4j87Z5e.net
- 本当にいいの？僕は…黒人だよ？
- 136 ：デフォルトの名無しさん：2024/02/03(土) 22:04:08.76 ID:OoEMTWx+.net
- クラス排除はJavaの生みの親ですら主張しているほどプログラミング言語界での共通認識
＞以前Javaのユーザグループミーティングに出席した際、James Gosling（Javaの生みの親）がメインの講演者として招かれていました。
＞すばらしいQ&Aセッションの途中に、こんな質問が出ました。
＞「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」
＞答えは「クラスを除外するでしょうね」というものでした。
＞笑いが静まった後、彼が説明したのは、本当の問題はクラス自体ではなく実装継承(extendsの関係)なのだということでした。
＞インターフェースによる継承（implementsの関係）のほうが望ましいのです。
＞できる限り実装継承は避けたほうがよいでしょう。
- 137 ：デフォルトの名無しさん：2024/02/03(土) 23:17:23.21 ID:g7D12qls.net
- クラスを排除した代わりにRustでは実装継承の実現に4種類もの異なる方法が導入されている
もちろんGoでもNimでもクラスとは違う形で実装継承が実現されている
にもかかわらず物事の表面しか見ない人はそれに気づけないし今でも実装継承が絶対悪だと信じて疑わない
これが所謂バカの壁
- 138 ：デフォルトの名無しさん：2024/02/03(土) 23:26:38.80 ID:9NPgrYKr.net
- >>137
Rustに実装継承はないよ
どのやり方でも必ず委譲が発生する健全な方法を採っていて実装継承の問題を排除している
- 139 ：デフォルトの名無しさん：2024/02/03(土) 23:35:45.23 ID:EvhZrc0+.net
- クラスが悪いのか継承とかの機能が悪いのか
- 140 ：デフォルトの名無しさん：2024/02/03(土) 23:45:39.46 ID:1FnNRIIs.net
- 大雑把に クラス＝カプセル化＋実装継承
よくないのは実装継承
カプセル化だけなら構造体の範囲内
つまり実装継承を伴うクラス自体が要らないというのがモダン言語
- 141 ：デフォルトの名無しさん：2024/02/04(日) 00:25:24.84 ID:gRgK5+vi.net
- Kotlinのsealed interfaceはマジで超使いやすい
- 142 ：デフォルトの名無しさん：2024/02/04(日) 00:27:54.98 ID:woXOEkq4.net
- Rocketってフレームワーク試してみたんだけどこれホストを127.0.0.1以外にできないんかな
なんかハードコーディングでlocalhost指定になってる気がしないでもない
- 143 ：デフォルトの名無しさん：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というフレームワークは使ったことないので悪しからず
- 144 ：デフォルトの名無しさん：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))
がそれっぽくはあるけどどう書き換えたもんか
- 145 ：デフォルトの名無しさん：2024/02/04(日) 02:04:25.32 ID:1c78Jpm9.net
- https://rocket.rs/v0.5/guide/configuration/
読んだ感じだとRocket.tomlって設定ファイルで指定するのが簡単みたい
下の方にプログラムで設定する方法も書いてあるけど
こういうフレームワーク系はプロキシサーバーの裏側で動かすのが理想かもしれない
- 146 ：デフォルトの名無しさん：2024/02/04(日) 03:52:57.49 ID:58NiwoAK.net
- Rustを書けるようになると、C/C++でも行儀よく実装できるようになるから
するとドキュメントの充実しているC/ C++でいいかとなりそう
- 147 ：デフォルトの名無しさん：2024/02/04(日) 05:28:12.54 ID:Qwt1SmMN.net
- >>105
Python信者か？ 富豪プログラミングでもRustの方が書きやすいが
- 148 ：デフォルトの名無しさん：2024/02/04(日) 07:20:12.68 ID:IOFBpciC.net
- 動的型付けのPythonは論外でプログラミングには向いておらずスクリプトを書く程度に使う言語
静的型付けの言語の中では過去の様々な問題点を踏まえて洗練された設計となっているRustがプログラミングに最適
>>146
それはない
例えば今では必須な非同期プログラミングでもC++は出遅れていて使いにくいだけでなくRustのtokioに相当する基盤もない
- 149 ：デフォルトの名無しさん：2024/02/04(日) 08:23:06.79 ID:Iky4lKs4.net
- >>146
ドキュメントの数は多いけど、自動生成もない時代のが多くてソースコードと乖離してたり
古いLinuxディストリ前提だったりして役に立たない率がめちゃ高いんだよな
ドキュメンテーションテストとかdocs.rsとかそういう仕組がちゃんとしてるのに慣れると
わざわざ古代の遺物的なのを発掘しに行く気にはなれない
- 150 ：デフォルトの名無しさん：2024/02/04(日) 08:29:53.11 ID:qR3d7cra.net
- Cは構わないけど、C++はあり得ない
絶対に二度と触りたくないし、積極的に見たくもない
- 151 ：デフォルトの名無しさん：2024/02/04(日) 08:46:56.47 ID:gRgK5+vi.net
- Cにdeferが来たら、もうC++を触らなくてよくなるんだ🥰
…C23でのdeferの実装、見送られたけどね
- 152 ：デフォルトの名無しさん：2024/02/04(日) 09:04:42.24 ID:gRgK5+vi.net
- ああ、zigを本番環境で使いたいなあ
- 153 ：デフォルトの名無しさん：2024/02/04(日) 10:02:40.29 ID:woXOEkq4.net
- >>145
それもやったけど変わらなかった
まぁver0.xだし正式リリースになったらもうちょいマシになるんだろうから
今はまだ使い時じゃないって事で
- 154 ：デフォルトの名無しさん：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])
}
- 155 ：デフォルトの名無しさん：2024/02/04(日) 11:21:21.48 ID:lyxub88e.net
- >>146
自分で書く分ではどっちでも。
でもお前の職場のプログラミングセンス無いやつにもc/c++で書いてて欲しいと思う？
- 156 ：デフォルトの名無しさん：2024/02/04(日) 11:36:41.94 ID:BT7dzCU3.net
- >>153
rocketを使う理由が特にあるわけではないならば
一番ダウンロード数も多くRustで本流のaxumを使うといいよ
https://github.com/tokio-rs/axum
このURLを見てもわかるようにtokio開発チームが直接手掛けているWebアプリフレームワーク
- 157 ：デフォルトの名無しさん：2024/02/04(日) 12:24:56.19 ID:RfkvOVf2.net
- >>148
それはあなたの主観だよ
世界中で流行っているpythonをそのように評価をすること自体がナンセンスだとは思わないか？
- 158 ：デフォルトの名無しさん：2024/02/04(日) 12:55:23.59 ID:twXVw8X/.net
- >>157
前にも書いたけど例えばPythonのDjangoは遅い
PythonがRustに勝ってる点はローコストでコーディングできる、それのみ
学習コスト、開発時間などを投資できるならRustのようなlow-levelな言語を用いた製品のほうがコンピュータに優しいのは既知の事実
- 159 ：デフォルトの名無しさん：2024/02/04(日) 13:07:03.82 ID:BT7dzCU3.net
- >>157
Pythonでプログラミングを実際にすればわかるけど
ある程度の大きさのものを作るには開発デバッグ効率が非常に悪いね
数ある諸言語と比べてもPythonのメリットは普及していること以外には何も無いかと
- 160 ：デフォルトの名無しさん：2024/02/04(日) 13:22:50.87 ID:RfkvOVf2.net
- >>158
つまりpythonはプログラミングに向いていないというのは間違いということで良い？
>>159
そうは思わないな
開発ツールやエディタが進化してるから差は感じない
- 161 ：デフォルトの名無しさん：2024/02/04(日) 13:45:38.68 ID:gf/EWl58.net
- インタプリタ言語はプログラミングに値しないってか？流石に言いすぎだぞ
うちの小学生の子どもにScratchをプログラミング学習として遊ばせてるけど、そのScratchもれっきとしたプログラミング言語だし
- 162 ：デフォルトの名無しさん：2024/02/04(日) 13:54:00.15 ID:qLwuX6da.net
- >>147
メモリ管理をランタイムに任せることを富豪的プログラミングというのでは？書き易さなんて単に個人の言語の習得度の差でしかない
- 163 ：デフォルトの名無しさん：2024/02/04(日) 14:07:26.71 ID:vIcGZtFX.net
- お前のDjangoは遅い？ならサーバーのスペックを10倍にしろやゴラァ
ってのが富豪的プログラミングの理念ね
- 164 ：デフォルトの名無しさん：2024/02/04(日) 16:31:03.43 ID:ZDSbtwdo.net
- Rustと比べるとPythonはプログラミングに向いていない
スクリプト程度ではなく普通にある程度の規模があるプログラムを対象とする
- 165 ：デフォルトの名無しさん：2024/02/04(日) 16:54:18.26 ID:lyxub88e.net
- 特定領域の話と一般論をごっちゃにしてるやつ多いな。
- 166 ：デフォルトの名無しさん：2024/02/04(日) 16:54:55.07 ID:RSs6aSR/.net
- 実際にPythonで書くと実行時デバッグがどうしても多くなるね
後から機能追加したりリファクタリングしたりする時も再び実行時デバッグに陥りやすいね
その点Rustは静的型付けであるだけでなくデータ競合もコンパイル時点で防いでくれるから優れているね
- 167 ：デフォルトの名無しさん：2024/02/04(日) 16:55:36.99 ID:3vZBpwTn.net
- >>162
文脈的に文字列を無駄にヒープに置いただけで富豪扱いなんだよな
あと習熟度に依存するのはそれはそうなんだけど、Pythonに習熟した人間ほどRustの方が書きやすいという傾向がある気がする
少なくとも俺の身の回りではそう
- 168 ：デフォルトの名無しさん：2024/02/04(日) 17:00:11.71 ID:p+8ZNFQ1.net
- 書きやすかろうが何だろうがユーザ数が全てやろ
Rustは流行ってない それだけは確か
- 169 ：デフォルトの名無しさん：2024/02/04(日) 17:01:42.98 ID:3vZBpwTn.net
- ユーザー数が全てはまあそれはそう
- 170 ：デフォルトの名無しさん：2024/02/04(日) 17:06:47.57 ID:ktccjMxJ.net
- そこは単純な話だろう
PythonとRustの両方をそこそこ使いこなせる人たちに
どちらの言語でも開発可能な領域の案件をどちらで開発したいか尋ねる
100%の人たちがRustで開発したいと答える
つまりPythonは劣った言語
- 171 ：デフォルトの名無しさん：2024/02/04(日) 17:07:47.85 ID:3vZBpwTn.net
- Pythonにも確かに良い所があって、Qiitaの記事が多いから入門が簡単
- 172 ：デフォルトの名無しさん：2024/02/04(日) 17:11:51.24 ID:p+8ZNFQ1.net
- そもそもお前らの勘違いはpythonを取り上げてること
寧ろ比較するというかライバルはJavaScriptだぞ
バックグラウンドや速度求められる所でも使われてる
実際にJavaScriptは以外とは失礼かもだけど高速だしな
- 173 ：デフォルトの名無しさん：2024/02/04(日) 17:14:25.77 ID:RfkvOVf2.net
- >>172
ライバルがJavaScript()
- 174 ：デフォルトの名無しさん：2024/02/04(日) 17:15:47.77 ID:p+8ZNFQ1.net
- >>170
何でワザと複雑化させるの？
ユーザ数って言う最もシンプルなので良い
いざ開発で人集めたらRust出来る人が居ませんでした
居ても単価がバカ高い人でした
pythonならこちらが選び放題で報酬も安く済みます
どう考えてもpython優位だよね
言語が劣ってるとか優秀とか関係無い
目的のシステムが短期間で安く作れるかどうか
でもってそれが出来るのが優秀な言語
- 175 ：デフォルトの名無しさん：2024/02/04(日) 17:20:38.23 ID:ktccjMxJ.net
- >>172
バックエンドではJavaScriptは遅い
フロントエンドのDOMアクセスはJavaScriptでしかできないため使わざるをえない
DOMアクセスを頻繁に伴わない処理ならばWasmが圧倒的に速くJavaScriptは遅い
- 176 ：デフォルトの名無しさん：2024/02/04(日) 17:26:06.18 ID:ZDSbtwdo.net
- >>174
それはPythonしか知らないプログラマーが多いだけでどうでもいい話だな
両方を使えるプログラマーはRustを選ぶからプログラミング言語の優劣ははっきりしている
- 177 ：デフォルトの名無しさん：2024/02/04(日) 17:32:07.47 ID:3vZBpwTn.net
- 単価の話し始めたらまだPythonよりJavaの方が優位そう
- 178 ：デフォルトの名無しさん：2024/02/04(日) 17:33:28.37 ID:p+8ZNFQ1.net
- >>176
両方というかRustのユーザ数が少ないから人が集まらないって話してるのにバカなのかなw
- 179 ：デフォルトの名無しさん：2024/02/04(日) 17:35:51.36 ID:3vZBpwTn.net
- 目的の設定からコーティングまで自分でやらないといけない局面があって、そういう時に良いんだよな。Rust。
仕事が定型化されていたり、専門知識が要らなかったりして外注出来るならJavaで良さそう
- 180 ：デフォルトの名無しさん：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/
- 181 ：デフォルトの名無しさん：2024/02/04(日) 18:05:48.16 ID:gRgK5+vi.net
- ユーザー数が全てと言うならJavaが最強って話をしたくなってくる
- 182 ：デフォルトの名無しさん：2024/02/04(日) 18:27:51.72 ID:p+8ZNFQ1.net
- そういう話じゃ無いんだよなぁ
Rust使いたいなら流行らせてユーザ数増やすしか無い
他の言語と比較して云々を語る暇があるならライブラリ作って充実させて流行らせる努力すれば良い
- 183 ：デフォルトの名無しさん：2024/02/04(日) 18:38:38.86 ID:JoIfCUOf.net
- >>180
分野によって変わるし一概にそうとは言えんよ
例えば機械学習の分野でRustを使うメリットはゼロ
開発保守性に関しても速度的にも利便性的にもツールチェインの連携にしても
今や汎用言語は以前に比べると遥かに有用性は低くなってる
だからrustが流行り切らないのだと分析してる
一昔前なら一斉に移ってたと思うよ
- 184 ：デフォルトの名無しさん：2024/02/04(日) 18:55:04.87 ID:h39TGQDK.net
- >>183
本気で言ってるなら常識を疑う
機械学習分野は各社の競争が激しくて記述言語はC/C++/Rust
Pythonはライブラリ呼び出しスクリプトに使われることがあるだけの存在
- 185 ：デフォルトの名無しさん：2024/02/04(日) 18:55:55.93 ID:gRgK5+vi.net
- >>183
あの、機械学習はプログラミングじゃないとは言わないけど分類としてはデータサイエンスだからな？😅数学系だからな？あんだすたん？
機械学習は理論がメイン、プログラミングはただの手段
- 186 ：デフォルトの名無しさん：2024/02/04(日) 18:59:22.83 ID:gRgK5+vi.net
- libtorchとかてんさーふろーの実装の話ならオープンソースを見ればわかるがC/C++やで
演算処理がメイン機能なんだから当たり前だよね
- 187 ：デフォルトの名無しさん：2024/02/04(日) 19:01:58.80 ID:gRgK5+vi.net
- Rustはサーバー系、組み込み系が用途なのに、
Pythonのが優秀だのなんだの言うのいい加減に鬱陶しいぞ
- 188 ：デフォルトの名無しさん：2024/02/04(日) 19:04:22.03 ID:woXOEkq4.net
- Pythonとか他の言語が分かれば数時間の勉強であとか感覚で読み書きできる言語だけど
Rustはそうはいかんと思うし
優れた言語と手軽に習得できる言語って比べても仕方ないと思う
- 189 ：デフォルトの名無しさん：2024/02/04(日) 19:13:30.94 ID:gRgK5+vi.net
- 言い方が悪かったかな
Pythonはさ、演算結果を得るために使うものであって、サーバーや組み込みのような常時駆動するようなものには向かないんですよ
考えてみなよ、お手軽さを求めるときは大抵は結果を求めたいときだろ？
numpyの行列計算がお手軽で便利～ってのと一緒だろ？
- 190 ：デフォルトの名無しさん：2024/02/04(日) 19:17:47.24 ID:JoIfCUOf.net
- >>184
それを言えばpytorchのラッパーがrustにあるから同じ存在だよ
- 191 ：デフォルトの名無しさん：2024/02/04(日) 19:18:07.74 ID:VbPJH2i6.net
- Pythonにキレててｸｶ
- 192 ：デフォルトの名無しさん：2024/02/04(日) 19:18:31.47 ID:JoIfCUOf.net
- >>189
じゃあrustじゃなくCで良いって話になるけど
- 193 ：デフォルトの名無しさん：2024/02/04(日) 19:24:46.98 ID:gRgK5+vi.net
- >>192
俺、1度目もRustじゃないとダメだとか言ったか？
俺の意見はちゃんとサーバー、組み込みに適した言語、Java、Kotlin（大好き）、C#、Go、C、C++（きらい）、Rust、Zig（流行ってほしい）を使えってこと
PythonやRubyをサーバーや組み込みに使ってほしくない
- 194 ：デフォルトの名無しさん：2024/02/04(日) 19:30:56.06 ID:gRgK5+vi.net
- あと機械学習の話が出てきたから追加で言うけど、演算処理するなら、極力オーバーヘッドを減らしたいわけで、ガべコレなんていう敵はいないほうがいいわけだから、C/C++/Rustを実装言語に使う
俺ら末端ユーザーが演算処理装置の実装なんてする機会がないからどうでもいい話だけど
- 195 ：デフォルトの名無しさん：2024/02/04(日) 19:37:05.95 ID:3vZBpwTn.net
- 機械学習でガベコレが気になるってかなりアプリケーションよりっぽい感じがするな
実装コストとかより推論速度が重要という人間が出てきたのを見ると、機械学習もここまで来たんだなあって感慨深くなる
- 196 ：デフォルトの名無しさん：2024/02/04(日) 19:42:57.90 ID:ccceg+j6.net
- pythonの使われ方は1番にデータサイエンスとして、2番にプログラミング学習のお手本言語として、3番にシェルスクリプトの代替として。
実装言語としては使われてないよ。
- 197 ：デフォルトの名無しさん：2024/02/04(日) 19:46:45.59 ID:gRgK5+vi.net
- >>195
逆に聞きたいんだけど、ただ単に線形代数の計算がしたいだけなのに、ガべコレいるの？
- 198 ：デフォルトの名無しさん：2024/02/04(日) 19:49:37.34 ID:gRgK5+vi.net
- 昔からあるeigen使っても機械学習できるし
- 199 ：デフォルトの名無しさん：2024/02/04(日) 19:53:25.16 ID:woXOEkq4.net
- 言語として普及させるならやっぱ母数的にはまずWebのバックエンドだろうけど
それならそれでフルスタックフレームワーク欲しいところなんだよなあ
MoonZoonってのがヒットするけどあんまドキュメントが充実してないな
- 200 ：デフォルトの名無しさん：2024/02/04(日) 19:54:33.10 ID:3vZBpwTn.net
- >>197
いるかいらないかで言えばいらないけど、実行時間のほとんどは線形代数演算だからガベコレの時間は誤差だし、高速化したいならモデルをチューニングする方がはるかに効果が大きいので誰もガベコレなんか気にしていないという時代が長かった印象
- 201 ：デフォルトの名無しさん：2024/02/04(日) 19:55:05.28 ID:JoIfCUOf.net
- いつのまにか実装言語の話に流れてるけど
そういう議論はしてないからな
- 202 ：デフォルトの名無しさん：2024/02/04(日) 19:55:34.23 ID:yS+PPAz5.net
- ここはRustのスレです
開発プログラミング言語として劣っているPythonの話題は他所でしてください
- 203 ：デフォルトの名無しさん：2024/02/04(日) 19:56:07.95 ID:JoIfCUOf.net
- 機械学習で得たモデルを組み込みデバイスで使いたいってことなんじゃない？
それもう機械学習を終えて、ただのアプリの設計と実装な気がするけど笑
- 204 ：デフォルトの名無しさん：2024/02/04(日) 19:59:28.23 ID:JoIfCUOf.net
- どれもダメ
pythonに勝てる理由にはなってない
実装言語の話をしたいならC/C++で良いし現状そうなってる事実は覆らない
速度だけ欲しいならrustはいらない
- 205 ：デフォルトの名無しさん：2024/02/04(日) 20:00:34.78 ID:gRgK5+vi.net
- >>200
それはそう
行列演算ライブラリがC/C++ばっかなのはたまたまだとも言える
- 206 ：デフォルトの名無しさん：2024/02/04(日) 20:02:02.46 ID:gRgK5+vi.net
- >>201
このスレはRustスレなんだから実装の話になるのは当たり前だろ
データサイエンスの話がしたいなら他所に行ってくれ
- 207 ：デフォルトの名無しさん：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
- 208 ：デフォルトの名無しさん：2024/02/04(日) 20:06:59.78 ID:uCVo+TKx.net
- >>206
じゃあこういう視点から聞くが下回りがrustの機械学習ライブラリはありますか？
- 209 ：デフォルトの名無しさん：2024/02/04(日) 20:11:29.25 ID:gRgK5+vi.net
- >>204
Rustを組み込み業界が推してる理由はセキュリティ、メモリ安全の観点でRustがC/C++より優秀っていう理由
実際にカーネルはRustにマイグレーションされはじめてるでしょ
Rustがサーバー用途で使われだしてるのはtokio等のRustライブラリ、Webフレームワークが優秀なおかげでJavaのSpringBootのような有名どころに機能面でそこまで劣らず使えて、省メモリ高速に使えるから
- 210 ：デフォルトの名無しさん：2024/02/04(日) 20:16:35.93 ID:woXOEkq4.net
- >>209
そういやJVM使うから同じゲーム動かすにしてもAndroidはｉPhoneよりメモリとかのハード要件上がるとか言われてたな
- 211 ：デフォルトの名無しさん：2024/02/04(日) 20:16:54.38 ID:JoIfCUOf.net
- >>209
少なくとも下回り使う分にはそのような要求は必要ないと思うが
rustであってもunsafeだらけになるよ
非同期ライブラリに関してはpythonもasyncioというtokioに勝るとも劣らないつよつよライブラリがある
よってその点でも不足はない
Webフレームワークに関しては言わずもがな
- 212 ：デフォルトの名無しさん：2024/02/04(日) 20:17:19.77 ID:gRgK5+vi.net
- >>208
だからなんでそんなにデータサイエンスの話をしたがるの？
ライブラリ？libtorchのrustラッパーでコード書いてコンパイルすりゃいいだけやんか頭悪すぎでは？
機械学習は演算処理して類似度を求める作業なんだからコンパイルなんて手間かけずにスクリプト言語でやったほうが手軽だろうが
長時間動作させたいサーバーや組み込みとはわけが違う
インタプリタ言語とコンパイル言語の使い分けもできないの？
- 213 ：デフォルトの名無しさん：2024/02/04(日) 20:22:45.50 ID:woXOEkq4.net
- 負けず嫌いが多いのか知らんが相手にするから居付くんやで
- 214 ：デフォルトの名無しさん：2024/02/04(日) 20:24:07.63 ID:gRgK5+vi.net
- >>211
システムコール書くんだからそらunsafeだらけになるわな
逆に言えばそのシステムコールまわりの部分さえ厳重に書けばいいじゃんか
Webフレームワークでインタプリタ言語を使うのは、上で言われてた典型的な富豪的プログラミングだよね>>163
サーバーに重課金できるならPythonでどうぞ実装やってください
ふつうの神経を持ってたら少なくともJavaとかC#とかGoとかをサーバーに使うと思う
- 215 ：デフォルトの名無しさん：2024/02/04(日) 20:24:27.23 ID:JoIfCUOf.net
- >>212
いやそもそもの議論の出発点が「機械学習においてはpythonがrustより優れている」というところだからでしょ
- 216 ：デフォルトの名無しさん：2024/02/04(日) 20:28:31.70 ID:gRgK5+vi.net
- >>215
機械学習はプログラミングじゃないとは言わないがデータサイエンスの分野だよ（2回目）
だから「機械学習においてPythonがRustより優れてる」がそもそもおかしい
Rustはデータサイエンスをやる言語ではない
- 217 ：デフォルトの名無しさん：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.
- 218 ：デフォルトの名無しさん：2024/02/04(日) 20:31:39.88 ID:JoIfCUOf.net
- >>217
いや一覧を出せって意味じゃないぞw
python以上に使われてる例を出せって意味だよ
- 219 ：デフォルトの名無しさん：2024/02/04(日) 20:32:36.67 ID:JoIfCUOf.net
- >>216
そういう逃げはいいから
データサイエンスも普通にプログラミングです
- 220 ：デフォルトの名無しさん：2024/02/04(日) 20:33:09.36 ID:gRgK5+vi.net
- >>219
違います、数学です
- 221 ：デフォルトの名無しさん：2024/02/04(日) 20:34:08.77 ID:woXOEkq4.net
- データサイエンスやるならPythonよりJuliaの方がいいな
- 222 ：デフォルトの名無しさん：2024/02/04(日) 20:34:15.03 ID:JoIfCUOf.net
- 結局論破できないんか
じゃあ絡んでくるなよ
機械学習においてはpythonに負けていますでいいだろ
そしてそれはrustがダメということにはならん
何と戦ってるのか
- 223 ：デフォルトの名無しさん：2024/02/04(日) 20:36:35.51 ID:gRgK5+vi.net
- >>222
機械学習の論文読んだことある？プログラミングなんてどうでもいいことは「～のPCスペックでPytorchを用いて実装しました」くらいしか書かれないぞ
- 224 ：デフォルトの名無しさん：2024/02/04(日) 20:36:58.01 ID:tlFdYVQb.net
- >>222
Rustは機械学習のライブラリもRustで書かれているものも多いです
PythonはC/C++依存だから同じ土俵にすら立てないと思います
- 225 ：デフォルトの名無しさん：2024/02/04(日) 20:37:34.97 ID:JoIfCUOf.net
- >>223
いやそれは今関係ないでしょ
- 226 ：デフォルトの名無しさん：2024/02/04(日) 20:39:06.92 ID:gRgK5+vi.net
- >>225
機械学習は理論が大事ということを語る上で関係大アリなんだが…
- 227 ：デフォルトの名無しさん：2024/02/04(日) 20:41:07.00 ID:wL3YnJ62.net
- 元々学生の勉強用としてPythonが利用されてて、
その学生が勉強の一環で機械学習したことで機械学習用のライブラリが増えた
その過去の資産(遺産？)の上に乗っかって今のAIブームがあるだけ
言語的な優位なんてものはPythonになくて
ただライブラリが充実してるだけの話
- 228 ：デフォルトの名無しさん：2024/02/04(日) 20:46:55.32 ID:7/eIVGRy.net
- 機械学習なら†darknet†だよね
- 229 ：デフォルトの名無しさん：2024/02/04(日) 20:48:06.01 ID:tlFdYVQb.net
- Rustで機械学習はRustだけで完結できるアドバンテージもありあります
新たに出て来て必要となる実装ライブラリもRustだけ習得すれば作れます
- 230 ：デフォルトの名無しさん：2024/02/04(日) 20:56:21.39 ID:gRgK5+vi.net
- うーん、機械学習する上で必須となる行列演算ライブラリの実装の話こそRustでやるかやらないかで盛り上がるところなのに、なぜ頑なに機械学習自体を取り上げて話をしてきたのか
理解不能だ
- 231 ：デフォルトの名無しさん：2024/02/04(日) 21:15:10.60 ID:woXOEkq4.net
- そういやJuliaだと行列演算言語単位でサポートしてたな
- 232 ：デフォルトの名無しさん：2024/02/04(日) 21:22:05.81 ID:wL3YnJ62.net
- そもそもの話になるけども
なんでPythonが教育目的で使われたのかって話になる
Pythonはキレイに書くことを強制されるってのもあるけど
電池内蔵とか言われるぐらい標準ライブラリが充実していた
だから学習に利用されやすかった
行列計算も然り
結局ライブラリが充実してたって話に帰結するよ
尤もライブラリの大半はCで書かれてるがね
- 233 ：デフォルトの名無しさん：2024/02/04(日) 21:24:14.42 ID:wL3YnJ62.net
- ちなみにnumpyの開発者も大学生だったんじゃないかな
とにかく欧米の学生はPythonで勉強してたから
Pythonのライブラリは大学生が作ったものが多いよ
- 234 ：デフォルトの名無しさん：2024/02/04(日) 21:33:51.15 ID:7hkEeikC.net
- その昔は perl もライブラリが豊富といわれていたんだがな
perl, ruby, python の中ではオフサイドルールがある分だけ
python の方がプログラムがごちゃごちゃになりにくい
もっとも今となっては自動フォーマッターがあるので
どれで書いてもあまり変わらないが
- 235 ：デフォルトの名無しさん：2024/02/04(日) 21:44:00.36 ID:MUvkIiW8.net
- >>233
>>234
ここはRustスレ
Rustがらみの話以外は別スレでしろ
- 236 ：デフォルトの名無しさん：2024/02/04(日) 22:16:24.24 ID:3vZBpwTn.net
- Rustはプログラム言語の王なのでRustスレではどの言語の話をしても良い
- 237 ：デフォルトの名無しさん：2024/02/04(日) 22:24:24.75 ID:gRgK5+vi.net
- 他の言語を知ることでRustの良し悪しが分かる、他の言語を学ぶことは巡り回ってRustの勉強になるって寸法よ
もちろんRustの文法やフレームワークの話題や議論があればそちらを優先すべきね
- 238 ：デフォルトの名無しさん：2024/02/04(日) 23:02:06.01 ID:FrLSpZU4.net
- Rustが『いま』流行ってなくても、Rustの協賛企業らが『無理やり』流行らすから5-10年後には日本でもサーバーサイドにRustを使う企業が増えている
20年後にはLinuxカーネルのRust化がほぼ完了してるだろうよ
- 239 ：デフォルトの名無しさん：2024/02/04(日) 23:16:12.06 ID:woXOEkq4.net
- 結局相手にするヤツがいるから居付くわけで
- 240 ：デフォルトの名無しさん：2024/02/04(日) 23:21:49.89 ID:MUvkIiW8.net
- >>238
Rustは「安全かつエコ」という流れが生じつつあるから日本でもそうなる
エコとは他の言語より消費電力を減らしCo2排出量も減ること
- 241 ：デフォルトの名無しさん：2024/02/04(日) 23:24:52.22 ID:X8VPJ+Rl.net
- rustとpythonではなく、tomlとpythonを比較すればいい
スクリプトを追放するたんびにマークアップ言語が増える歴史が繰り返される
- 242 ：デフォルトの名無しさん：2024/02/04(日) 23:32:42.46 ID:srfzNHU5.net
- >>239
相手にしなかったら自演して自分に安価つけ始めるけどな
- 243 ：デフォルトの名無しさん：2024/02/04(日) 23:55:39.05 ID:gRgK5+vi.net
- >>241
tomlはマークアップ言語じゃなくてデータ記述言語
スクリプトうんぬんは知らんが、シリアライズ効率のより良いデータ記述言語を求めるのはいい事だよ
自分のところはjson+gzipで落ち着いてるけど、goでよく使われるprotobufにいずれ移行できればなって考えてる
- 244 ：デフォルトの名無しさん：2024/02/05(月) 00:06:05.32 ID:xY09uWcV.net
- >>230
数値演算ライブラリはC言語で十分な気がする。理由を言語化するのは難しいけど
- 245 ：デフォルトの名無しさん：2024/02/05(月) 00:06:28.07 ID:8h9X84j9.net
- オッやっとるな
- 246 ：デフォルトの名無しさん：2024/02/05(月) 00:06:30.26 ID:8h9X84j9.net
- オッやっとるな
- 247 ：デフォルトの名無しさん：2024/02/05(月) 00:11:45.07 ID:qpTlAoHG.net
- 一番向いてるのはミドルウェアとか少数のガチ勢が作ったらいいような部分なんだよな。
だから普及はしない。
- 248 ：デフォルトの名無しさん：2024/02/05(月) 00:14:26.70 ID:Uc3vGql0.net
- >>244
並列処理まわりの仕様をよく検討した上でRustかCかC++のどれを選択するべきとは思うな
- 249 ：デフォルトの名無しさん：2024/02/05(月) 00:18:35.26 ID:qpTlAoHG.net
- アルゴリズム周りなんて共有のオンパレードなのにrustが向いてると思ってるのはちょっと素人感がすごいね。
- 250 ：デフォルトの名無しさん：2024/02/05(月) 00:25:50.11 ID:Uc3vGql0.net
- 日本語おかしくなった
並列処理まわりの仕様をよく検討した上でRust、C、C++のうちどれを使うか選ぶべき
個人的には並列処理の安全性の面でRustを使うべきだと思う
- 251 ：デフォルトの名無しさん：2024/02/05(月) 00:31:12.78 ID:Uc3vGql0.net
- まあ実情は演算処理にCUDAを使うだろうからC++で全部設計したほうが都合がいいのかな
難しい
- 252 ：デフォルトの名無しさん：2024/02/05(月) 00:39:33.82 ID:xSwz3MFP.net
- 並列処理？tokioの出番だな
- 253 ：デフォルトの名無しさん：2024/02/05(月) 00:52:01.28 ID:i8NFM5TB.net
- 機械学習はPython？Rust？いやいや争わずに両方使えばいいじゃん。
Rustを使って機械学習アルゴリズムを実装しPythonから呼び出す: k-meansクラスタリング
https://zenn.dev/skwbc/articles/rust_python_kmeans
- 254 ：デフォルトの名無しさん：2024/02/05(月) 00:57:54.10 ID:Ml8drJRq.net
- 機械学習だの演算処理だの、いつまでそんなつまらない話をしてるの？
rustはゴミってことで結論が出てるんだけど
- 255 ：デフォルトの名無しさん：2024/02/05(月) 01:03:32.12 ID:l3kMSpNc.net
- 荒らしに構うキチガイを追い出したいね
ID:gRgK5+vi → ID:Uc3vGql0 （違ったらごめんね）
- 256 ：デフォルトの名無しさん：2024/02/05(月) 01:04:43.04 ID:4uXpM/Ax.net
- >>253
わざわざ生でunsafeなコードを書かなくてもPyO3とか使えば楽にできるよ
- 257 ：デフォルトの名無しさん：2024/02/05(月) 03:14:48.13 ID:6VJ4TLXv.net
- >>243
Protocol Buffers古いし、MessagePack(古い)やCBORのほうがいいんじゃない？ 使ったことないけど。
- 258 ：デフォルトの名無しさん：2024/02/05(月) 03:40:05.05 ID:d3c/QlU3.net
- Protocol buffersは仕様変更に強いしフォーマットを別ファイルに定義出来るという特徴があるから、msgpackやcbor とは使うべきケースが違いそう
- 259 ：デフォルトの名無しさん：2024/02/05(月) 06:01:25.37 ID:ip7v+BR3.net
- >>247
もちろん少人数ガチ勢による開発もRustが向いてるのはおっしゃる通りだけど
大人数による開発もRust向いてるでしょう
特にC++で次から次に穴の発生が尽きない各大規模プロジェクトたちは作り直しや新規ならRust一択だね
- 260 ：デフォルトの名無しさん：2024/02/05(月) 06:45:17.21 ID:bXI/bbyn.net
- >>247
Rustはサーバーサイドで最もよく使われているっていう調査結果がすでに出ているが>>117,119
- 261 ：デフォルトの名無しさん：2024/02/05(月) 06:55:14.99 ID:qjaRN2nq.net
- >>253
どうでもいいがこの記事では非同期処理ライブラリにtokioじゃなくてrayonを使ってるんだな
気になってぐぐったら「rayonのスレッド プールは、CPU を集中的に使用する作業、つまり大規模なデータ セットの大規模な並列処理向けに設計されています。」らしい
https://www.reddit.com/r/rust/comments/xec77k/rayon_or_tokio_for_heavy_filesystem_io_workloads/
- 262 ：デフォルトの名無しさん：2024/02/05(月) 07:04:12.02 ID:ip7v+BR3.net
- >>261
rayonは非同期を使わない並列に特化した時に速い
tokioは非同期で並行＆並列で万能
- 263 ：デフォルトの名無しさん：2024/02/05(月) 08:21:40.19 ID:kahA1Glb.net
- >>227
なら言語的に優れていてPythonライブラリを使えるNim最強だな。
- 264 ：デフォルトの名無しさん：2024/02/05(月) 08:36:20.41 ID:ip7v+BR3.net
- Rust⇔PythonはPyO3で相互に呼び出せるのでRustだけあれば十分
- 265 ：デフォルトの名無しさん：2024/02/05(月) 09:57:56.35 ID:3fgxGQeI.net
- 他の言語スレに乗り込んできて居座るとかやってる事ルビガイジとなんら変わらんっていう
- 266 ：デフォルトの名無しさん：2024/02/05(月) 12:16:47.03 ID:Uc3vGql0.net
- >>263
Nimは速いしCへのトランスパイルも賛否あれど個人的には好き
- 267 ：デフォルトの名無しさん：2024/02/05(月) 12:56:18.45 ID:WdhGREbJ.net
- >>211
お前や俺らがそのunsafe部分を書く。
で職場の他の今動きゃいいってコード書いてる奴らにはunsafe部分は利用させても書かせない。
そういう分け方できるのはメリットじゃないかね。
- 268 ：デフォルトの名無しさん：2024/02/05(月) 13:02:02.94 ID:WdhGREbJ.net
- >>266
同意
- 269 ：デフォルトの名無しさん：2024/02/05(月) 22:28:07.58 ID:UHwE0rib.net
- >>259
もう5年くらいこんなこと言ってる人いるけど一向に普及してないよね。
- 270 ：デフォルトの名無しさん：2024/02/05(月) 22:40:04.70 ID:5g9amV19.net
- >>269
カーネルのRustへのマイグレーションの成果が各所で出てるの知らない？
- 271 ：デフォルトの名無しさん：2024/02/05(月) 22:49:23.20 ID:dxOzlQzX.net
- >>269
AWS SDKにRustが正式登場して、色んなところがRustを触りだしてるぞ
- 272 ：デフォルトの名無しさん：2024/02/05(月) 23:29:16.62 ID:bm3rzOD2.net
- AWSやCloudflareが大規模に使ってるからインターネットのトラフィックの結構な分量をRustが捌いてるはず
この5年でこういう人目には触れないけど基礎的な部分にずいぶん普及したよ
- 273 ：デフォルトの名無しさん：2024/02/06(火) 00:09:13.25 ID:gR/xoQQt.net
- Rust のユーザ規模はもはや小さくはないが仮に小さかったとしても、それが無用のものということを意味するわけではない。
Cobol や Fortran だって一般には化石のような印象を持たれつつも近年にも規格改定などの発展はあるし、それが求められる程度の利用シーンはある。
Lisp がインフラの中に潜んでいたりするし、Caml で書かれたプログラムがあなたがたのパソコンにインストールされていたりするのもそれなりに高い確率でありうる。
普及するっていうのはそれを不必要なところにまで押し付けたいわけじゃないだろう。
- 274 ：デフォルトの名無しさん：2024/02/06(火) 00:25:40.67 ID:oam+zbbU.net
- 物を作ってから普及するまでの時間で評価されれば
まだ作ってない物を売るようになったり、評価を信じなくなったりする
- 275 ：デフォルトの名無しさん：2024/02/06(火) 00:35:44.14 ID:QhlaBKsr.net
- >>271
あれすげー使いにくいよ
そもそもがAWSのAPI自体が非同期の作りですぐに返ってくるものばかりだから
ライブラリ側は同期的で良いのにtokio使っちゃってるし
- 276 ：デフォルトの名無しさん：2024/02/06(火) 00:39:31.81 ID:OWeq/GHS.net
- >>272
現在のネットのインフラであるクラウドとCDNがRust製になっていってるから
Rustがネットインフラを支えるようになって来たと言っても過言ではないんだね
- 277 ：デフォルトの名無しさん：2024/02/06(火) 01:36:56.00 ID:bbDh9Fvv.net
- >>275
割と何言ってるかよくわからないので
どのあたりが使いにくいのか詳しく
- 278 ：デフォルトの名無しさん：2024/02/06(火) 08:02:11.78 ID:TiTcC6K4.net
- >>275
javascriptでただの同期functionだったものが非同期のasync awaitに変わった経緯がある
同期functionだとブラウザから呼び出した時に待ち状態がフリーズみたいになって不便だった
- 279 ：デフォルトの名無しさん：2024/02/06(火) 08:41:24.69 ID:Lhg6cl8R.net
- >>275
それはキミの非同期処理に関する知識が欠如してるだけ
- 280 ：デフォルトの名無しさん：2024/02/06(火) 10:42:58.91 ID:rmP9tpon.net
- まあわざわざライブラリ側で非同期にしなくても、必要ならユーザーが勝手に非同期にすればいいってのはあるかもな
- 281 ：デフォルトの名無しさん：2024/02/06(火) 11:02:01.98 ID:viYUZILO.net
- お前らはawait禁止縛りでもしてるの？
- 282 ：デフォルトの名無しさん：2024/02/06(火) 11:12:37.31 ID:tyBWuvJT.net
- tokioの非同期って
async fn、spawn、async、await
を最低限使えればなんも不自由なくね？
同期じゃないといけない理由あんの？
- 283 ：デフォルトの名無しさん：2024/02/06(火) 11:17:49.52 ID:gR/xoQQt.net
- 同期的に使うだけの場合でも tokio をリンクするってのが気分よくないというのはわかる。
- 284 ：デフォルトの名無しさん：2024/02/06(火) 11:19:55.73 ID:g9hJ5hPW.net
- >>282
同期じゃないといけない理由？非同期の使い方がわからないからじゃないか？
ちなみにRustがダメだとアンチが言うのはアンチがRustコードのコンパイルを成功できないから
- 285 ：デフォルトの名無しさん：2024/02/06(火) 11:23:28.54 ID:YZW9kbIH.net
- AWS SDKを同期的に使いたいってそれAWS CLIじゃだめなん？w
- 286 ：デフォルトの名無しさん：2024/02/06(火) 11:25:05.20 ID:BOUvQi0K.net
- >>280
そこの今まで独自にそれぞれが用意してた部分を async await 等のAPIとして整理されたことに意義があるんと思う。
- 287 ：デフォルトの名無しさん：2024/02/06(火) 11:26:18.87 ID:J68o5uRN.net
- AWS CLIはcargo installで入ってこないから……
- 288 ：デフォルトの名無しさん：2024/02/06(火) 11:28:28.70 ID:DRX9b4l9.net
- そもそもRustを使う意味がないよね
AWS SDK for Pythonがあるんだから
- 289 ：デフォルトの名無しさん：2024/02/06(火) 11:28:33.03 ID:J68o5uRN.net
- >>286
async awaitへの統合に意義があるのはわかるけど、tokioにまで限定されるのはダルイという気持ちがある
- 290 ：デフォルトの名無しさん：2024/02/06(火) 11:33:54.88 ID:GPQIFWbx.net
- >>289
そこはしょうがないでしょ
tokioはAWSが積極的に支援してるライブラリだからね
https://tokio.rs/
https://i.imgur.com/NSjb82s.png
- 291 ：デフォルトの名無しさん：2024/02/06(火) 11:35:59.00 ID:J68o5uRN.net
- >>290
説教的に支援って資金的な支援じゃなくてAWSがtokioの営業することだったのか……
- 292 ：デフォルトの名無しさん：2024/02/06(火) 11:38:49.18 ID:GPQIFWbx.net
- あ、AWSがtokioを運営してんのか
単なるスポンサーだと思ってた
- 293 ：デフォルトの名無しさん：2024/02/06(火) 11:40:13.71 ID:J68o5uRN.net
- マジか
- 294 ：デフォルトの名無しさん：2024/02/06(火) 11:42:17.61 ID:4dmbx6OY.net
- 説教的な支援は5chの担当
- 295 ：デフォルトの名無しさん：2024/02/06(火) 11:42:20.07 ID:4dmbx6OY.net
- 説教的な支援は5chの担当
- 296 ：デフォルトの名無しさん：2024/02/06(火) 11:53:48.52 ID:9gL8Mjmo.net
- Rustで非同期やるライブラリって昔からたくさんあるけど最近はtokioしか使ってないや
すごく重い処理があるプロジェクトはtokioとrayonで使い分けてるけどそれでも両方のライブラリをプロジェクトで共存させてる
- 297 ：デフォルトの名無しさん：2024/02/06(火) 12:09:35.30 ID:eJTRS9Cw.net
- 非同期と言いつつ出来てない奴って8割いるよね
- 298 ：デフォルトの名無しさん：2024/02/06(火) 13:54:11.58 ID:oam+zbbU.net
- 非同期のそのデメリットを消す方法は
まだ作ってないことにしよう
- 299 ：デフォルトの名無しさん：2024/02/06(火) 14:05:46.01 ID:QhlaBKsr.net
- >>277
まずAWSのAPIってのは基本的にすぐ返ってるの
この辺はわかる？
例えばインスタンスを作るAPIってのはインスタンスを作り終わるまでブロックするんじゃなくてインスタンス生成命令を出してすぐに返ってくるわけ
実際にインスタンスが生成完了したかはインスタンスの状態取得APIを使って確認するわけ
だから常に同期的に呼び出しで問題ないの
pythonのboto3ってライブラリが1番使いやすい
- 300 ：デフォルトの名無しさん：2024/02/06(火) 14:08:10.63 ID:9MgF8+tA.net
- Boto3、あんま補完されなくて馬鹿にはキツい
- 301 ：デフォルトの名無しさん：2024/02/06(火) 14:39:52.97 ID:HfVCyUAp.net
- >>299
AWSが鯖落ちしてたらどーすんの？
- 302 ：デフォルトの名無しさん：2024/02/06(火) 14:47:03.29 ID:bbDh9Fvv.net
- >>299
あなたが何言ってるかわかるけどnodejsでも
似たような使い方だしrust sdkの欠点と言われても
広く同意は得られないんじゃないかなあ
- 303 ：デフォルトの名無しさん：2024/02/06(火) 14:52:06.28 ID:QhlaBKsr.net
- >>302
欠点というか使い方を難しくしてるだけな気がするんだよな
普通にCLIでええやんって思う
- 304 ：デフォルトの名無しさん：2024/02/06(火) 14:59:31.38 ID:bbDh9Fvv.net
- >>303
awsに限らずweb apiのライブラリは
非同期にするのが主流だから
頑張って勉強してねとしか…
- 305 ：デフォルトの名無しさん：2024/02/06(火) 15:05:27.46 ID:eJTRS9Cw.net
- AWSのSDKは.NETのが1番だな
- 306 ：デフォルトの名無しさん：2024/02/06(火) 16:38:39.75 ID:m1uPeMIU.net
- AWS SDK for Rustはsend()がめちゃくちゃダサい
そのうち大幅に改修されるだろうけど
>>299
ネットワークI/Oを同期で書くのはさすがにどうかと
- 307 ：デフォルトの名無しさん：2024/02/06(火) 16:55:31.82 ID:/Z6uowCt.net
- >>300
今から見ると微妙だがCLIと対応がつけやすいし
余計なことはしなくて良いから楽だよ
- 308 ：デフォルトの名無しさん：2024/02/06(火) 17:04:11.45 ID:/Z6uowCt.net
- >>306
どう書くか？はユーザーのユースケースによるからそうとも言えないよ
例えばAzureのCLIは--no-waitというオプションがあり
処理が成功するまで待つか待たないかを決められる
これこそユーザー視点の設計だよ
- 309 ：デフォルトの名無しさん：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
- 310 ：デフォルトの名無しさん：2024/02/06(火) 17:08:19.95 ID:/Z6uowCt.net
- 非同期を押し付けることはユーザーのメリットにはならない
Rust SDKは作り直して欲しい
- 311 ：デフォルトの名無しさん：2024/02/06(火) 17:21:49.29 ID:HJO9dxnA.net
- prostもblocking版の関数ないのかよってびっくりした記憶があるわ
C#版もPython版もasyncとblockingの両方あるのにな
- 312 ：デフォルトの名無しさん：2024/02/06(火) 17:23:58.68 ID:pGyPKkef.net
- >>299
>>まずAWSのAPIってのは基本的にすぐ返ってるの
>>この辺はわかる？
初心者でもそんなウソはつかないぞ
AWSに限らず任意のサービスに言えるが通信時間がかかる
さらに各サービス内で状態取得だけであっても実行時間がかかる
>>だから常に同期的に呼び出しで問題ないの
本気で言ってる？
通信時間と向こうでの実行時間の間こちらはずっと何もせずに待つわけ？
非同期プログラミングの意味すら理解できていてないのか？
- 313 ：デフォルトの名無しさん：2024/02/06(火) 17:27:07.44 ID:eJTRS9Cw.net
- >>312
コンピューターにとって1秒待つって事がどれだけ長いかを理解してないんだろ
- 314 ：デフォルトの名無しさん：2024/02/06(火) 17:28:50.84 ID:2AaBK8OM.net
- 非同期の方が良いことが多いのは同意するが、非同期を押し付けられると「こんなプログラムのためにTokio入れるのかよ」って思ってしまうケースは存在する
- 315 ：デフォルトの名無しさん：2024/02/06(火) 17:48:41.35 ID:Izyc/wZS.net
- API が非同期で設計されてるのに、それを呼び出す側もさらに非同期でハンドリングするのは正直無駄じゃない？
ってのはわりと自然な感想だと思うけどな。
AWS の API なんてクライアント側で並列に呼び出したいユースケースも無いだろ。
バカスカ叩いてもスロットリングされるだけだし。
- 316 ：デフォルトの名無しさん：2024/02/06(火) 18:00:53.30 ID:eyCZAgqI.net
- >>315
APIの向こう側で非同期なのとこちらの処理を
同期か非同期化は関係ないよね
- 317 ：デフォルトの名無しさん：2024/02/06(火) 18:18:54.67 ID:w99V6zNl.net
- それな
無関係ではないけど分けて考えないと
- 318 ：デフォルトの名無しさん：2024/02/06(火) 18:33:39.13 ID:nmitk2Uo.net
- >>308
非同期APIが提供されてれば同期化は簡単にできるから必要ないんだよ
- 319 ：デフォルトの名無しさん：2024/02/06(火) 18:36:16.19 ID:2AaBK8OM.net
- 同期化ってasyncでない関数から呼べるようにするって解釈で合ってるだろうか
もしそうだとしたらasyncでない関数の中でtokioランタイム作ってawsよんでruntime終わらせるみたいな処理になっちゃわないか
- 320 ：デフォルトの名無しさん：2024/02/06(火) 19:56:13.91 ID:kbEH5D0U.net
- AWSの同期的APIの機能リクエストあるのね
https://github.com/awslabs/aws-sdk-rust/issues/505
- 321 ：デフォルトの名無しさん：2024/02/06(火) 20:03:24.75 ID:Dpp0fICO.net
- AWSのAPIの呼び出しが非同期になるのはAPIの内部で効率化のために非同期処理をやってるからでしょ？
- 322 ：デフォルトの名無しさん：2024/02/06(火) 20:17:12.09 ID:7oKTbIPT.net
- うちはAWS SDK RustはAxumベースのWebアプリでDynamoDB接続に使ってるけど、みんなはなににAWS SDK使ってるん？
- 323 ：デフォルトの名無しさん：2024/02/06(火) 20:38:04.56 ID:NQvIuvVx.net
- >>312
だからーなーんにもわかってない発言丸出しはやめよ？
通信の時間なんてかからんのやって
すぐ返ってくるから
そこちゃんと読もう？
- 324 ：デフォルトの名無しさん：2024/02/06(火) 20:44:38.46 ID:NQvIuvVx.net
- AWS APIを生のRESTで実装してみろよ
すぐわかるぞ
- 325 ：デフォルトの名無しさん：2024/02/06(火) 20:45:53.99 ID:NQvIuvVx.net
- 言っておくが俺は一般論として非同期がダメと言ってるわけじゃないぞ
もちろんその用途としての方が便利なことは多い
あくまでAWS SDKのRust版については不満があるということよ
- 326 ：デフォルトの名無しさん：2024/02/06(火) 20:50:46.76 ID:dKDdJveN.net
- >>325
web apiの実装として相手側が非同期処理で
手元も非同期なんてのはawsだけじゃないというか
それが主流だけど他はいいの？
- 327 ：デフォルトの名無しさん：2024/02/06(火) 20:50:52.38 ID:2AaBK8OM.net
- このスレにはRust関連の悪い所の指摘を見ると自分が全否定されたように怒り出す人間がいるっぽいので
- 328 ：デフォルトの名無しさん：2024/02/06(火) 20:57:52.50 ID:NQvIuvVx.net
- tokioが素晴らしいのは間違いない
しかし今回のREST APIの呼び出しで程度で必要かな？と思う
非同期が必要ならtokio::process::commandでCLIを非同期で呼ぶ方が良くないか？とか色々考えてしまう
- 329 ：デフォルトの名無しさん：2024/02/06(火) 21:04:51.51 ID:pGyPKkef.net
- >>323
>>通信の時間なんてかからんのやって
>>すぐ返ってくるから
呆れた
敢えてウソをついているのか？
それとも本当に無知な初心者なのか？
- 330 ：デフォルトの名無しさん：2024/02/06(火) 21:08:56.44 ID:rmP9tpon.net
- Web通信ですぐ返ってくることなんかあるのか？ と思ったけど、AWSのAIPの中身知らんから何とも言えんくなってしまった
そういえばファイルIOはすぐ返ってくるって言って良いんだろうか
- 331 ：デフォルトの名無しさん：2024/02/06(火) 21:12:11.34 ID:NQvIuvVx.net
- >>330
サイズが小さいファイルに対して非同期呼び出しをするか？という話
- 332 ：デフォルトの名無しさん：2024/02/06(火) 21:14:41.84 ID:rmP9tpon.net
- >>331
まあ「ファイルIOにTokioが必要です」って言われたらちょっと嫌な気分になるな
- 333 ：デフォルトの名無しさん：2024/02/06(火) 21:15:39.21 ID:pGyPKkef.net
- >>330
Web通信は通信時間だけで大きく時間を要する
さらにWebサーバ側で処理時間がかかる
- 334 ：デフォルトの名無しさん：2024/02/06(火) 21:56:45.71 ID:Z39zy7L3.net
- >>323
cpuのナノ秒単位の処理速度に比べたら通信はとてつもなく遅いけど
レスポンスを受け取るまでの時間は処理を中断させたほうがコンピュータに優しい
tokioのグリーンスレッドを活かせ
- 335 ：デフォルトの名無しさん：2024/02/06(火) 22:05:59.23 ID:wkt5OFgc.net
- >>334
tokioのランタイムが裏で動くとか気持ち悪すぎだろ
同期でやらせろ
- 336 ：デフォルトの名無しさん：2024/02/06(火) 22:13:28.77 ID:IqTcjswh.net
- 他のSDKのようにv3くらいになれば使いやすくなってるかもね
- 337 ：デフォルトの名無しさん：2024/02/06(火) 22:16:42.98 ID:GPQIFWbx.net
- aws sdk for rust ってwebフレームワークでサーバーサイドやってる人向けだから当然のようにみんなtokioを既に組み込んでるもんじゃないの？なにがそんなに気に入らないのか理解ができない
まあtokio以外の非同期ランタイムを使わせろって人はドンマイだけど
- 338 ：デフォルトの名無しさん：2024/02/06(火) 22:17:52.75 ID:GPQIFWbx.net
- 「rustのwebフレームワーク」が抜けてた
- 339 ：デフォルトの名無しさん：2024/02/06(火) 22:21:16.54 ID:1nslx8NY.net
- >>337
そういう話じゃないけど
- 340 ：デフォルトの名無しさん：2024/02/06(火) 22:24:12.00 ID:DARHuXMe.net
- >>337
実装の話に逸らさないで
AWSのAPIくらい同期で十分なのにわざわざ非同期にする理由を言えよ
- 341 ：デフォルトの名無しさん：2024/02/06(火) 22:24:15.12 ID:UMLcFsAo.net
- いくらすぐ返ってくるっていってもネットワーク通信なんだから
不通だったりレイテンシが長くなることはありうるし、
タイムアウトやリトライをtokioのエコシステムに乗っかってやれるメリットはあると思うけどな
そりゃ軽量な同期版があるに越したことはないけど、優先順位は落ちるだろう
- 342 ：デフォルトの名無しさん：2024/02/06(火) 22:27:24.19 ID:QhlaBKsr.net
- JavaScript SDKも内部は非同期だけど使いやすいよ
単なるコールバックで同期的に書けるし
- 343 ：デフォルトの名無しさん：2024/02/06(火) 22:33:38.08 ID:QhlaBKsr.net
- どうも最近tokioがでしゃばってきて気持ちが悪い
ここまできたらもうコアをtokioに入れてWeb用の専用言語としてフォークしたほうがよいのでは？
- 344 ：デフォルトの名無しさん：2024/02/06(火) 22:35:03.21 ID:GPQIFWbx.net
- >>340
はぁ？そんなに同期でやりたいなら同期のある言語のSDKを使うかAWS CLIでコマンド実行しててくれよ
同期同期言ってるやつはRustでAWS触るアプリ作ってねえだろ
こちとらつい先日ようやく待ちに詫びたAWS SDK for Rustが正式版になって、ようやく、ようやくこれを本番投入できるって喜んだのによ
- 345 ：デフォルトの名無しさん：2024/02/06(火) 22:36:26.88 ID:QhlaBKsr.net
- まあ俺はCLI使ってるw
ぶっちゃけコードで書くメリットがわからない
- 346 ：デフォルトの名無しさん：2024/02/06(火) 22:36:30.11 ID:UMLcFsAo.net
- というか同期版もランタイム切り替えも別にissueとしては却下されてるわけじゃないんだし
欲しい人は実装してPR出せばいいんだよ
それがされてないってことは結局需要がないんでは？
- 347 ：デフォルトの名無しさん：2024/02/06(火) 22:38:18.90 ID:YgjIpfMr.net
- >>344
はい、じゃあお前の負けね
もう二度と口答えすんなよ
- 348 ：デフォルトの名無しさん：2024/02/06(火) 22:40:20.30 ID:QhlaBKsr.net
- >>341
不通だろうが普通はソケットのタイムアウト値設定するから許容できる範囲内の値を設定すればよろしい
どちらにしろリトライすることになるのだ
- 349 ：デフォルトの名無しさん：2024/02/06(火) 22:44:11.89 ID:oodj9UUv.net
- 「そんなに××したいなら○○使えば良いんじゃないの？ 」→をはい○○使っています」っていう流れ、最強言語たるRustのスレの流れとしてはあまりにも敗北感がある
- 350 ：デフォルトの名無しさん：2024/02/06(火) 22:50:36.48 ID:QhlaBKsr.net
- まとめると
tokio使わない同期API作れ
非同期版はランタイム切り替えできるようにしろ
ってことでオッケー？
- 351 ：デフォルトの名無しさん：2024/02/06(火) 22:53:13.82 ID:j3cHqQGJ.net
- >>340
コンマ1秒～1秒の頻度でデータベースクエリするWebアプリとかだったら非同期のが次々に処理できると思うけど
- 352 ：デフォルトの名無しさん：2024/02/06(火) 22:56:34.96 ID:LdUhtiaW.net
- >>351
なんだそれ？
お前そんなにバカみたいな頻度でAWS APIを使うの？笑うわ
- 353 ：デフォルトの名無しさん：2024/02/06(火) 22:57:34.03 ID:MUGS3GDn.net
- >>351
クエックエッ
笑笑
- 354 ：デフォルトの名無しさん：2024/02/06(火) 22:58:56.15 ID:QhlaBKsr.net
- >>352
それくらいの頻度で呼び出す可能性があるのってGAFAMクラスの会社ぐらいじゃね？w
- 355 ：デフォルトの名無しさん：2024/02/06(火) 23:04:22.29 ID:JKYjZJJo.net
- >>351
ゲームサーバーとかかな？
- 356 ：デフォルトの名無しさん：2024/02/06(火) 23:06:26.14 ID:6KaTvZBM.net
- >>354
それな笑笑
>>351は負けず嫌いの単発の敗者笑笑
- 357 ：デフォルトの名無しさん：2024/02/06(火) 23:08:14.09 ID:IqTcjswh.net
- 使ってる用途が違うから噛み合わないんだな
CLIで十分な用途とAPIが必要な用途くらいは区別しようぜ
- 358 ：デフォルトの名無しさん：2024/02/06(火) 23:08:21.31 ID:1CYgky+r.net
- あ、もしかしてガーファ勤めなんかな笑笑？
なわけねえだろ笑笑
- 359 ：デフォルトの名無しさん：2024/02/06(火) 23:09:19.34 ID:nVMpMpiW.net
- ガーファ最強笑笑
- 360 ：デフォルトの名無しさん：2024/02/06(火) 23:10:22.99 ID:fZ7dPHD5.net
- >>351はバカです
- 361 ：デフォルトの名無しさん：2024/02/06(火) 23:12:04.80 ID:N6+r1oq4.net
- >>355
ゲームサーバーってなに？マインクラフトでもやってるの？ガキんちょか？
- 362 ：デフォルトの名無しさん：2024/02/06(火) 23:15:06.92 ID:aJWngw7a.net
- >>357
うるさいな
非同期じゃないといけない理由を具体的に言ってみろよ？あ？
- 363 ：デフォルトの名無しさん：2024/02/06(火) 23:16:25.72 ID:QhlaBKsr.net
- >>351
GAFAM社員age
- 364 ：デフォルトの名無しさん：2024/02/06(火) 23:26:25.88 ID:qbDsNmRG.net
- 自分用のツールなら一々tokioとかめんどくさいとか
わからんでもないけどそういう人をターゲットに
してないからなあ
- 365 ：デフォルトの名無しさん：2024/02/06(火) 23:26:55.98 ID:IqTcjswh.net
- GAFAMの規模を舐めすぎだろ
10リクエスト/秒程度なら中堅企業の社内向けシステムでも普通にあるレベル
- 366 ：デフォルトの名無しさん：2024/02/06(火) 23:35:03.14 ID:O9rpVDxS.net
- 実際ゲームサーバーって大変そうよね
最近話題になったパルワールドってやつもサーバー要素があるけど、ゲームデータをどこかしらのクラウドサービスをレンタルしてやってるわけで、>>351よりもすごいレベルで行われてそう
パルワールドのサーバーはどの言語のWebフレームワークでやってるのか知らんがJavaとかC#、GoあたりならRustのが高速、省メモリでサーバー代を節約できただろうな
- 367 ：デフォルトの名無しさん：2024/02/06(火) 23:43:25.52 ID:ZEorkRES.net
- ゲームサーバーってプログラミング関係あるの？サーバーを借りてるだけなんじゃないの？
- 368 ：デフォルトの名無しさん：2024/02/06(火) 23:56:44.33 ID:7jT2HGcX.net
- 無知は恥ってよくわかるね
- 369 ：デフォルトの名無しさん：2024/02/07(水) 00:00:36.36 ID:/3r7f4vo.net
- >>366
人気ゲームだと桁が3つ4つ違う
- 370 ：デフォルトの名無しさん：2024/02/07(水) 00:02:07.90 ID:HSCt9mfq.net
- >>368
無知自体は何も恥じることではない
- 371 ：デフォルトの名無しさん：2024/02/07(水) 00:25:18.71 ID:ZYweHa7T.net
- まさかゲームサーバーがなんなのかわからない人がこのスレにいるとは
- 372 ：デフォルトの名無しさん：2024/02/07(水) 00:29:20.89 ID:HhW4UiiT.net
- AWSはCLIでいい、非同期はゴミって結論出たね
- 373 ：デフォルトの名無しさん：2024/02/07(水) 00:41:54.53 ID:O61WTlOm.net
- 通信時間＋向こうでの処理時間はCPUにとって莫大な待ち時間
async/awaitによる非同期プログラミングをすれば同期と同じようにプログラムを組めつつその莫大な待ち時間を有効活用できる
これは特定のプログラミング言語に関係なく対応しているすべての言語で成り立つ話
もちろんRustでも同じ
- 374 ：デフォルトの名無しさん：2024/02/07(水) 00:51:24.66 ID:EnTbeTL9.net
- AWS Lambdaだと同時実行数の制限があるから、同期処理をするのは犯罪的。
- 375 ：デフォルトの名無しさん：2024/02/07(水) 00:58:32.65 ID:p1o31ALH.net
- 現状のasync/awaitの使いやすさは
Swift > C# > JavaScript >>> Rust
- 376 ：デフォルトの名無しさん：2024/02/07(水) 00:59:45.05 ID:p1o31ALH.net
- KotlinやF#は使ったこと無いのでわからない
- 377 ：デフォルトの名無しさん：2024/02/07(水) 01:07:53.33 ID:p1o31ALH.net
- >>375
Python忘れてたわ
Swift > C# > JavaScript/Python >>> Rust
- 378 ：デフォルトの名無しさん：2024/02/07(水) 01:10:26.42 ID:O61WTlOm.net
- >>375
Rustが最もきめ細かく扱えて便利
- 379 ：デフォルトの名無しさん：2024/02/07(水) 01:13:21.82 ID:O61WTlOm.net
- もちろん性能面でもRustが最も有利
だからインフラに至るまで採用されている
- 380 ：デフォルトの名無しさん：2024/02/07(水) 01:20:07.41 ID:R4SwjTOT.net
- >>377
c++は？
- 381 ：デフォルトの名無しさん：2024/02/07(水) 02:44:08.20 ID:7skGlnTk.net
- >>377
swiftってそんなに書きやすいんか？
- 382 ：デフォルトの名無しさん：2024/02/07(水) 04:57:14.90 ID:uDrK2oQi.net
- >>375
asyncもRxもC#が発祥だけどこの言語だけ異常だよな
- 383 ：デフォルトの名無しさん：2024/02/07(水) 06:30:56.86 ID:EnTbeTL9.net
- Pythonはスレッドが擬似的なので並行処理の性能が低い。
- 384 ：デフォルトの名無しさん：2024/02/07(水) 06:35:55.67 ID:5V24VW//.net
- >>375
Kotlinが抜けてる
Kotlin>（越えられない壁）>Swift > C# > JavaScript/Python >>> Rust
- 385 ：デフォルトの名無しさん：2024/02/07(水) 06:52:43.34 ID:r0kpHnB4.net
- Rustを叩きたいだけのアンチさんだから無茶苦茶や
- 386 ：デフォルトの名無しさん：2024/02/07(水) 07:15:51.00 ID:Z0+c6VxI.net
- >>380
C++は論外
アンチではなく本当に書きにくい
さらにtokioのような高性能な基盤も整備されていない
- 387 ：デフォルトの名無しさん：2024/02/07(水) 07:16:35.05 ID:0B0Tt2Zv.net
- 非同期はC#GoKotlinRustのどれも同等に使いやすいと感じる
JavaはSpringありき、Swiftはつかったことない、C/C++は考えたくない
- 388 ：デフォルトの名無しさん：2024/02/07(水) 07:25:44.75 ID:qmafesNd.net
- swiftやdartはモバイルアプリ開発以外で全く使われてない
- 389 ：デフォルトの名無しさん：2024/02/07(水) 07:30:51.78 ID:KVAhvvz+.net
- SwiftはApple製ってだけで使う価値なし
開発環境の依存があまりに高すぎる
- 390 ：デフォルトの名無しさん：2024/02/07(水) 07:38:16.28 ID:2LChEtDL.net
- 出来ればJVMも使わずに済みたい
なんとなく
- 391 ：デフォルトの名無しさん：2024/02/07(水) 07:40:43.27 ID:lxo2szIV.net
- >>375,377,384
なんか言語のラインナップ見るにバリバリのフロントエンド開発屋さんかな？
そらRustを使うことなんてないわな
なんでこのスレにいるのか
- 392 ：デフォルトの名無しさん：2024/02/07(水) 07:53:07.34 ID:q5vZGjA+.net
- Rustはフロントエンドも取り込むのでRustスレはフロントエンド屋も書き込んで良い
- 393 ：デフォルトの名無しさん：2024/02/07(水) 08:12:27.93 ID:gKkOyEKn.net
- まぁRustの非同期の良いところはランタイムを言語から切り離したので
Webでも組み込みベアメタルでも非同期が使えるところなんだけど
使い勝手としてWebのユースケースに特化した他言語に負けるのはしょうがない
これは時間がたっても根本的には改善されないから
不満があるなら早く他言語に移ったほうがいいよ
- 394 ：デフォルトの名無しさん：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は無限に始まってる
- 395 ：デフォルトの名無しさん：2024/02/07(水) 09:03:48.96 ID:7skGlnTk.net
- 静的言語ではkotlinが個人的には1番かな
コルーチンスコープを作れるから既存の処理の中に非同期を唐突に入れられる
これが理想
ただしクラスありきなのが微妙なところ
クラスなしでkotlinのような使い心地がある言語が欲しい
- 396 ：デフォルトの名無しさん：2024/02/07(水) 09:09:08.81 ID:oJ2HGwP7.net
- >>373
その時間有効に使えるのかって話なんだよ。
例えばRDSを休止したい場合に、休止するAPIを呼んで、状態を確認するAPIで休止を確認してすると思うけど、
そういう処理を自動化する時に非同期でハンドリングする意味あるかっていう。
DynamoDB のデータ操作とか業務トランザクション扱う系は非同期あっていいとは思うけどね。
- 397 ：デフォルトの名無しさん：2024/02/07(水) 09:21:27.90 ID:+r3v4OXU.net
- 既存の処理の中に非同期を唐突に入れられるのってランタイムがグローバルで一意じゃないと出来なそう
ランタイムいくらでも作れるし複数種類存在しうるRustでは無理そうね
- 398 ：デフォルトの名無しさん：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ランタイムは必要ない
- 399 ：デフォルトの名無しさん：2024/02/07(水) 09:42:26.35 ID:x+YpU8Xz.net
- async{}.await
- 400 ：デフォルトの名無しさん：2024/02/07(水) 09:45:13.70 ID:kuiQPbhX.net
- >>380
C++ はその性質上、システムとの連携が必要な標準ライブラリは薄い。
幅広いシステムで実現可能なように配慮するから。
必要ならサードパーティライブラリでやれというスタンス。
ただそこで強力な誰もが認めるサードパーティライブラリが結局は現れなかったというのが C++ のあかんかったところなんやわ。
個人的には C++/WinRT の非同期処理は好きなんだがね。
- 401 ：デフォルトの名無しさん：2024/02/07(水) 10:36:03.38 ID:0B0Tt2Zv.net
- >>395
KotlinはデフォルトでclassがJavaでいうfinal classで定義されてて
・クラス継承禁止
・やってることはCの構造体と同じ
だから、自分はclassであるデメリットを感じてないかな
Kotlinでクラス継承するにはご存知の通りclassをopen classやabstract classと書くから見て分かるのがヨシ
- 402 ：デフォルトの名無しさん：2024/02/07(水) 10:46:44.24 ID:rJGaKMx5.net
- >>396
>その時間有効に使えるのかって話なんだよ。
非同期にすることでawsに関係なく別の処理を同じリソースで走らせられる
もしその時間を有効に使えないような用途なら省リソース高性能とは無縁だからわざわざRustを選ぶ必要ない
- 403 ：デフォルトの名無しさん：2024/02/07(水) 10:52:51.94 ID:ndvPWcVf.net
- なんかプログラミング言語総合スレみたいになってんな
いやちゃんと説明してくれて勉強になるから別にいいんだけど
- 404 ：デフォルトの名無しさん：2024/02/07(水) 11:05:20.92 ID:tO9J4ky9.net
- >>402
Rustはプログラム言語の王だから理由がなくてもRustを使って良い
- 405 ：デフォルトの名無しさん：2024/02/07(水) 11:12:27.12 ID:dhCR1KyQ.net
- >>398
え、tokioランタイム無しで非同期関数呼べるんだ？ 知らんかった
でもクレートの依存は付いてきてビルド遅くなるよね
- 406 ：デフォルトの名無しさん：2024/02/07(水) 11:34:03.35 ID:A5F8kPnc.net
- >>405
tokioに依存してない非同期関数ならクレートの依存もなく自分でFuture::pollを呼べばいい
例えばpollsterってクレートはそれ専用で、block_onだけ呼べる最小限の実装になってるよ
- 407 ：デフォルトの名無しさん：2024/02/07(水) 11:48:56.31 ID:EgwSQeAh.net
- 自分でFuture::poll呼ぶとか罰ゲームすぎるやろ
- 408 ：デフォルトの名無しさん：2024/02/07(水) 12:13:10.25 ID:DO0hQq6L.net
- >>361
ゲームサーバーはユーザーの操作ログを逐一集めてるよ。
- 409 ：デフォルトの名無しさん：2024/02/07(水) 12:15:26.39 ID:DO0hQq6L.net
- >>370
いや、無知は恥だよ。ただ罪では無い。
無知のままでいようとすることは罪だけど。
あ、実際の法律云々じゃなくて技術者としてね。
- 410 ：デフォルトの名無しさん：2024/02/07(水) 12:39:51.49 ID:3p2K3Rhv.net
- >>407
自分で呼んでもいいし自分で呼ばなくてもいい
それは何をやりたいかどこまでやりたいかなどに依存
>>405
軽いものなら例えばこれだけ
fn main() {
let val = futures_lite::future::block_on(async {
...
});
}
- 411 ：デフォルトの名無しさん：2024/02/07(水) 13:49:24.53 ID:hXp0LcUB.net
- pollを自分で呼ぶコードは悪手とかなんとか主張する人間と
そのコードに警告もしないコンパイラを
比較できるのがRustの楽しいところで
リソースを節約する話などは人間と人間の論争でありRustに責任はない
- 412 ：デフォルトの名無しさん：2024/02/07(水) 19:07:50.52 ID:tO9J4ky9.net
- C++に安全の責任はない
Pythonに動作速度の責任はない
Brainfuckにリソース節約の責任はない
Rustにリソース節約の責任はない
- 413 ：デフォルトの名無しさん：2024/02/07(水) 19:08:11.49 ID:tO9J4ky9.net
- うーん
- 414 ：デフォルトの名無しさん：2024/02/07(水) 19:08:14.90 ID:e4qAQ6ae.net
- >>366
ゲームのミドルウェアがUE4だから、サーバー側もC++で書いてるんじゃないかな。
- 415 ：デフォルトの名無しさん：2024/02/07(水) 19:15:08.54 ID:p3QVKrD0.net
- >>412
リソース節約の責任って何？
リソース節約の責任があるプログラミング言語が存在するの？
- 416 ：デフォルトの名無しさん：2024/02/07(水) 19:30:42.71 ID:DWMhsuR7.net
- >>412
何の面白味もないな
- 417 ：デフォルトの名無しさん：2024/02/07(水) 19:49:16.82 ID:tO9J4ky9.net
- >>415
リソース節約の責任の定義は>>411に聞くべきでは？
- 418 ：デフォルトの名無しさん：2024/02/07(水) 20:05:00.19 ID:oFnccM2b.net
- そもそもRustとそのエコシステムを同一視してるんじゃないか。もちろん不可分なところはあるにせよ、分けて考えないとね。
- 419 ：デフォルトの名無しさん：2024/02/07(水) 23:23:34.90 ID:BkEIpOIl.net
- 言語の形式的なルールと実利を同一視するのは
ルールを守れば必ず報われるべきってことじゃないか
でもルールを守ることと勝つことは難易度が全然違う
- 420 ：デフォルトの名無しさん：2024/02/07(水) 23:47:29.64 ID:Y7NjV+uy.net
- Rustの駄目なところ
コンパイルが遅い
コンパイル時間を含めたらPythonのが圧倒的に速い
- 421 ：デフォルトの名無しさん：2024/02/08(木) 00:07:22.21 ID:5/bJ8Q79.net
- >>420
すごいでちゅねー
- 422 ：デフォルトの名無しさん：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
- 423 ：デフォルトの名無しさん：2024/02/08(木) 04:23:52.18 ID:vwr7y0Aq.net
- >>420
みっともないからルビガイジみたいなレス乞食やめろよ
- 424 ：デフォルトの名無しさん：2024/02/08(木) 04:49:47.24 ID:TVrzLD8V.net
- ルビガイジって何？
- 425 ：デフォルトの名無しさん：2024/02/08(木) 07:47:36.74 ID:guCqNZzs.net
- 何にでもruby推してくる変な人の事じゃね？
- 426 ：デフォルトの名無しさん：2024/02/08(木) 10:03:29.26 ID:5zPu7Sf5.net
- >>414
フロントとサーバーは間にネットワーク通信が挟まるんだから言語をフロントとサーバーで統一するメリットなし
- 427 ：デフォルトの名無しさん：2024/02/08(木) 10:24:35.32 ID:TVrzLD8V.net
- >>426
直接に通信するあたりは言語を統一しておくと共通のライブラリを使えたりするので便利。
少人数で運用しているシステムだとクライアントとサーバーがある程度に
共通のスキルセットで構築できたほうがいいってこともある。
それがデメリットを上回るほどのメリットかどうかは状況によるけど。
- 428 ：デフォルトの名無しさん：2024/02/08(木) 12:09:04.39 ID:ug5u5xxX.net
- gRPCやRESTなら主要言語のほぼ全てで対応されてるんだから別に同じ言語に囚われる必要無いと思うけどなあ
- 429 ：デフォルトの名無しさん：2024/02/08(木) 12:31:37.22 ID:LLz4mv+z.net
- シリアライズフォーマットの話とプロトコルの話も区別できないのかぁ
- 430 ：デフォルトの名無しさん：2024/02/08(木) 12:39:36.57 ID:+yfo15bd.net
- スキルセットが一番発揮されるのはコード実装前の設計段階だよ
アルゴリズムとデータ構造、各種言語の各種フレームワークの知見を活かして設計してるだろ？
実装段階に入ったらあとは作業
フロント担当サーバー担当それぞれが実装する
フロントとサーバーはお互いに入出力のAPIだけ知ってればいい
言語の書き方そのものに対するスキルセットは納入期間の短縮にでも活かしてくれ
- 431 ：デフォルトの名無しさん：2024/02/08(木) 12:43:32.12 ID:ug5u5xxX.net
- >>429
そんなんprotobufかjsonのどっちかだろ
当たり前すぎてデータをどう送受信するかの話をしてたわすまん
- 432 ：デフォルトの名無しさん：2024/02/08(木) 12:47:52.48 ID:ug5u5xxX.net
- あっごめんzstdかgzipのどっちでデータ圧縮するかの話もしたほうがいいの？
- 433 ：デフォルトの名無しさん：2024/02/08(木) 12:58:22.52 ID:L2e7Z7sZ.net
- それら全て些細な問題でどうでもいい
通信でもファイルでも何でも
APIやフォーマットさえ決められていればよい
どの言語かどのフレームワークやライブラリかなんて一切関係なく自由
- 434 ：デフォルトの名無しさん：2024/02/08(木) 13:08:16.93 ID:aB2xl6fL.net
- >>426
一応、lddで確認したけれど、Epicのオンラインライブラリリンクしてたから、>>427 も言うように、クライアント側のゲームエンジンに引っ張られてると思う。
- 435 ：デフォルトの名無しさん：2024/02/08(木) 13:14:50.58 ID:ug5u5xxX.net
- 自社規格のデータをシリアライズ、デシリアライズするのに自社ライブラリを使うのと、サーバーやフロントをどの言語で実装するかは全くの別問題でしょ
>>414が言ってる、サーバーをC++で実装するだなんて効率の悪いことはするもんじゃない
- 436 ：デフォルトの名無しさん：2024/02/08(木) 13:16:12.56 ID:L2e7Z7sZ.net
- もちろんサーバとクライアントで同じ言語を利用すると有利な場合もある
もっと複雑なデータを別な形のデータに変換する同じ動作(コード)がサーバでもクライアントでも求められる場合がそれにそれに相当する
具体例としてはサーバサイドレンダリングをしつつフロントエンドでもシングルページのためレンダリングをする場合
従来はサーバサイドをNode.jsにすることで両側JavaScriptにしてコード共有が行われてきたが両側Rustでの動きもある
- 437 ：デフォルトの名無しさん：2024/02/08(木) 13:27:14.44 ID:21XfFHH6.net
- 人によっては使用言語を統一したほうが数多なるデメリットを単一のメリットが上回ることもある
このご時世、簡略化されたプログラミング言語で溢れたなかで、単一言語しかできないというのは珍しいとは思うが、誰しもがバイリンガルプログラマというわけではない
- 438 ：デフォルトの名無しさん：2024/02/08(木) 13:39:56.20 ID:557abryP.net
- unreal engineってフレームワークでサーバーアプリも作れるけど、自前でAPI組んでサーバーやったほうが圧倒的に軽量なんだよね
- 439 ：デフォルトの名無しさん：2024/02/08(木) 13:40:27.02 ID:wg4U7wDf.net
- バイリンガルでないプログラマ、Javaしか書けなそう
- 440 ：デフォルトの名無しさん：2024/02/08(木) 14:05:04.22 ID:u09hDjq1.net
- Java界隈では未だにXMLが現役なのかな
一時期は全てがXMLだったけど最近触れる機会がない
- 441 ：デフォルトの名無しさん：2024/02/08(木) 14:06:53.53 ID:0U3NNgcj.net
- jsonの後にxml使うとデータの無駄が気になる
- 442 ：427：2024/02/08(木) 14:06:56.11 ID:TVrzLD8V.net
- >>430
「少人数で」と但し書きを入れたのは一人が色々と担当する状況であるという意味だよ。
- 443 ：デフォルトの名無しさん：2024/02/08(木) 14:22:34.49 ID:TVrzLD8V.net
- ウェブまわりはいろんな規格が入れ子状態だから名前空間で分離する仕組みも要るところでは要る。
XML の万能さは他には代えられない便利さはある。
ただ、それが要らないところでは負担がデカいのも本当だし、多くの場合には要らんかったわという気づきがあったんだよ。
XML もスキーマがあれば大幅に情報を短縮できるバイナリXMLの規格も出てるんで、
そういうのを活用すればそれほど過剰に冗長なわけではない。
- 444 ：デフォルトの名無しさん：2024/02/08(木) 14:33:58.18 ID:d7zFncjn.net
- >>436
例えがフロントエンドって急にレベル下がってワロタ
- 445 ：デフォルトの名無しさん：2024/02/08(木) 14:44:36.25 ID:K+TPHqwf.net
- >>431
ゲームサーバーでも性能を極限まで高めることが要求されるような場合はprotobufやJSONはあまり使われない
↓ここでいうRaw Struct的なものが今でも使われてる
https://flatbuffers.dev/md__benchmarks.html
言語ニュートラルじゃないしサーバーとクライアントと同時アップデートしないといけないとかいろいろ制約あるけど性能が必要ならそれらの手間を惜しまない
- 446 ：デフォルトの名無しさん：2024/02/08(木) 14:50:39.80 ID:L2e7Z7sZ.net
- >>444
ならばプロコトル以外で
サーバとクライアントで同じコードを実行するために同じ言語であることが求められる例を挙げろよ
- 447 ：デフォルトの名無しさん：2024/02/08(木) 14:52:06.22 ID:ZTHDKZhp.net
- >>440
早くxmlは滅んで欲しい。
- 448 ：デフォルトの名無しさん：2024/02/08(木) 14:52:54.34 ID:TVrzLD8V.net
- シリアライズやパースのコストは小さくはないけど、
メモリコピーのコストが多くを占めているという発見から
なるべくコピーを減らしたシリアライズの規格として message pack が
実行性能と可搬性を (ある程度に) 両立したものとして人気がある。
まあ要するにそれぞれに利点があるんでこれが決定版とはなかなか言えないんだよな。
ある程度の収斂はしたにしても両立不可能なトレードオフってものはある。
- 449 ：デフォルトの名無しさん：2024/02/08(木) 14:58:14.76 ID:ug5u5xxX.net
- >>445
まあゲームだとデータの規格のバージョン互換性を考えなくていいし独自規格で暗号化も兼ねたシリアライズをしたほうが悪意あるデータの改ざん防止のための対策にもなりそう
てかデータ記述言語の話なんざクソほどどうでもいいんだが
- 450 ：デフォルトの名無しさん：2024/02/08(木) 15:04:17.46 ID:2EtcR70r.net
- xmlだろうがjsonだろうがrest通すときはgzipするからどっちでもいいわ
- 451 ：デフォルトの名無しさん：2024/02/08(木) 15:04:23.12 ID:d7zFncjn.net
- >>446
一昔前の分散オブジェクトシステムは大抵それだぞ
COBRAとか
そういう設計古くさいから基本的にやらない
- 452 ：デフォルトの名無しさん：2024/02/08(木) 15:14:54.75 ID:ug5u5xxX.net
- >>438
ああ、なるほど、UEはゲームレンダリングエンジンとしてではなくそれ単体でサーバーサイドもできるってことね知らんかった
小規模サーバー用途ならそれで十分そう
- 453 ：デフォルトの名無しさん：2024/02/08(木) 15:16:59.91 ID:ZTHDKZhp.net
- クライアントとサーバーで同じ "プログラミング言語" 使うことの話が、いつのにかプロトコルとデータシリアライズの話にすり変わってるし。
発端は >>426 あたりかな。
- 454 ：デフォルトの名無しさん：2024/02/08(木) 15:26:56.26 ID:L2e7Z7sZ.net
- >>451
分散オブジェクトの話とは状況が全く異なる
ウェブのサーバーサイドとクライアントサイドでのコード共通化は現在使われている最新技術
これを片側でしか行なわないと速度面すなわちブラウザを使う人間の体感面で不利となってしまう
両側ともにJavaScriptにするのが主流だがサーバーリソースコスト面で不利なため両側Rust化
- 455 ：デフォルトの名無しさん：2024/02/08(木) 15:32:31.05 ID:d7zFncjn.net
- >>454
別にお前のお気持ちは聞いてないよ
- 456 ：デフォルトの名無しさん：2024/02/08(木) 15:34:25.91 ID:L2e7Z7sZ.net
- >>455
気持ち？
理解していないようなので現在のウェブ界での動向を伝えただけだが
- 457 ：デフォルトの名無しさん：2024/02/08(木) 15:39:43.48 ID:lShPsUxC.net
- >>454
それwasmってやつ？ファイルサイズがjavascriptより大きくならない？
- 458 ：デフォルトの名無しさん：2024/02/08(木) 15:46:12.86 ID:rcfTmCHH.net
- フロントエンドってAPI受け取ってReactで画面描いてAPI送りつけるだけじゃん、これのどこがサーバーサイドとコード共通にすなるん？？
- 459 ：デフォルトの名無しさん：2024/02/08(木) 15:52:25.19 ID:VkQAw5RB.net
- javascriptでサーバーサイドって言ってる時点で頭がおかしいからスルーでおけ
- 460 ：デフォルトの名無しさん：2024/02/08(木) 15:57:01.04 ID:z3sGsuBj.net
- nodejsで済むサーバーって自宅サーバーか何かか?
- 461 ：デフォルトの名無しさん：2024/02/08(木) 16:06:02.61 ID:34mhb8ps.net
- >>457
一般的には何をするかに拠る
レンダリングコード共通化の話ならばその部分については誤差範囲
>>458
あまりにも基礎知識が無さすぎるようなので
SSRとCSRの違いと両者のメリットとデメリット及びコード共通化によるメリットを勉強しなさい
- 462 ：デフォルトの名無しさん：2024/02/08(木) 16:07:53.03 ID:d7zFncjn.net
- >>456
いやそれが余計なんだって
next.js app router+rust使ってる俺に対してする説明ではない
- 463 ：デフォルトの名無しさん：2024/02/08(木) 16:08:25.23 ID:34mhb8ps.net
- >>459
>>460
そこはPHPでもRubyでもPythonでもJavaScriptでも変わらない
しかしそれらは遅いからサーバーサイドはRust化すべきだろう
つまりレンダリング共通コードもRustで統一すべき
- 464 ：デフォルトの名無しさん：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を頑張る人は頑張って
- 465 ：デフォルトの名無しさん：2024/02/08(木) 16:54:49.99 ID:GUaqsUfs.net
- >>459 >>460
今は企業サイトでもサーバーサイドでJavaScriptが動く時代よ
Next.jsやNuxt.jsなどの名前を聞いたことないですか？
- 466 ：デフォルトの名無しさん：2024/02/08(木) 17:10:13.67 ID:ug5u5xxX.net
- だめだ、WASM specを見直してるけど相変わらず何書いてあるのかわからん
- 467 ：デフォルトの名無しさん：2024/02/08(木) 17:15:11.69 ID:TVrzLD8V.net
- >>464
規模がデカいアプリケーションは std の大きさなんてどうでもよくなるくらいにデカい。
大規模化するウェブアプリケーションが想定されているから
JavaScript のほうが軽量であるときは JavaScript を使えばいいよ。
そうじゃないときがあるって話なんだよ。
- 468 ：デフォルトの名無しさん：2024/02/08(木) 17:20:27.37 ID:K+TPHqwf.net
- 1コアで毎秒数万リクエスト処理するようなゲームサーバー的なものの話をしてると思ってたらSSRとかReactとか全く違うユースケースの話をしてる人達がいたのか
そりゃ話が噛み合わないわなぁ
- 469 ：デフォルトの名無しさん：2024/02/08(木) 17:26:24.69 ID:Z/Y0D/hR.net
- 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
- 470 ：デフォルトの名無しさん：2024/02/08(木) 17:26:27.02 ID:Z/Y0D/hR.net
- 話を合わせようとしたら負け
駄文乱文を量産し続けて最後まで圧倒したやつの勝ち
- 471 ：デフォルトの名無しさん：2024/02/08(木) 17:33:18.45 ID:wPAPAJoC.net
- >>467
その規模のデカいアプリケーションとやらがffmpegとかゲームとかをやるwasmならファイルサイズが大きくなる以上のメリットがあるからいいが、きれいなUIを表現するためにjavascriptよりファイルサイズの大きくなったwasmを使うのはアホとだけ言っておくわ
- 472 ：デフォルトの名無しさん：2024/02/08(木) 17:42:32.82 ID:EBOg13nx.net
- >>464
Wasmではfsなど必要ないのだから
no_stdで全く問題なくプログラミングできます
Rustの基本はほとんどcoreに入っています
allocを使えばVecやStringも使えます
あと欲しくなるのはHashMapあたりでしょうがこれもhashbrownで使えます
一度no_stdでプログラミングしてみることをオススメします
- 473 ：デフォルトの名無しさん：2024/02/08(木) 17:44:09.24 ID:EBOg13nx.net
- >>471
いえいえ
Wasmのファイルサイズはそんな巨大になりません
- 474 ：デフォルトの名無しさん：2024/02/08(木) 17:55:44.80 ID:TVrzLD8V.net
- Rust で簡易アセンブラっぽいものを作ったことがあった (特に std を避けるとかしてない) ので
wasm で出力してみたけどだいたい 140kb くらいな感じ。
たぶん JavaScript で書いて最適化もすればもっと小さくは出来そうな感触はあるが
だからといって Rust でやって深刻に巨大すぎるということはない。
小さいプログラムのときでも Wasm は使い物になる。
いや、もちろん比較したら JavaScript で書いたほうがよいことも多いのだろうけど、
全くのアンチパターンってことはない。
- 475 ：デフォルトの名無しさん：2024/02/08(木) 17:56:24.51 ID:ug5u5xxX.net
- >>472
いやー、watでいいかな
- 476 ：デフォルトの名無しさん：2024/02/08(木) 18:26:36.73 ID:d7zFncjn.net
- Figmaはecmascripten使ってるそうだよ
C++で書いてWebGL用にコンパイル
おそらく世界最大のwasmコードだろう
https://www.figma.com/ja/blog/webassembly-cut-figmas-load-time-by-3x/
- 477 ：デフォルトの名無しさん：2024/02/08(木) 18:29:10.38 ID:d7zFncjn.net
- 今のところrustよりはecmascriptenの方が既存コードを活かせる
- 478 ：デフォルトの名無しさん：2024/02/08(木) 18:37:22.37 ID://05Mhwl.net
- >>462
Next.js使ってるならサーバーサイドでSSGやSSRのためにJavaScriptを動かしてるってことだね
そこをRust化したいと思わないの？
- 479 ：デフォルトの名無しさん：2024/02/08(木) 18:41:39.17 ID:d7zFncjn.net
- >>478
next.jsはUI部分だけでバックエンドはRustだから特に必要性は感じないね
- 480 ：デフォルトの名無しさん：2024/02/08(木) 18:54:05.90 ID://05Mhwl.net
- >>479
Next.jsでSSRなら毎回JavaScriptのコードが動くわけだけど
「バックエンドはRustだから」って？
外から受ける部分のサーバはRustでもそこからNext.jsを動かすためのNode.jsなどを呼び出すことになるよね
- 481 ：デフォルトの名無しさん：2024/02/08(木) 19:25:31.03 ID:QINBs586.net
- 単にNext.jsがデータをフェッチする先のAPIエンドポイントがRust製ってだけだろ。
LBやらWebサーバーのような低レイヤがRust製かどうかみたいなのはそんなにユーザーに近いWeb屋が気にかけて手をいれる場所でもない。
- 482 ：デフォルトの名無しさん：2024/02/08(木) 19:29:46.46 ID:0U3NNgcj.net
- 途中にビルド嚙ませれば同じにできるけど一般的にはCommonJSとECMAScriptで違う方言のJSでやり取りする事になるけどね
TypeScriptは使ってないから知らん
- 483 ：デフォルトの名無しさん：2024/02/08(木) 19:34:55.22 ID:XA34Vq7w.net
- >>480
Next.jsがまるで悪かのように言ってるけど、そんな遅いと思わんな
自分が求めてるレベルが低いだけなのかな
- 484 ：デフォルトの名無しさん：2024/02/08(木) 19:38:03.57 ID:XODN4PGj.net
- next.jsは普通に速いよ
ビルドがクソ遅いだけで
他のエコシステムはもっと高速なんだけどねえ
- 485 ：デフォルトの名無しさん：2024/02/08(木) 19:54:29.48 ID:vWC2S6ww.net
- サーバーサイドは可能な限りリソースコスト(クラウド代/ハード代電気代)を下げたい
Next.jsに限らずJavaScriptを含めた遅い言語の実行は避けたい
すべてをRust化するのが最善案
- 486 ：デフォルトの名無しさん：2024/02/08(木) 20:01:51.28 ID:ZqeEswjg.net
- Next.js(Nuxt.js)はどんなにクソだとしても使わざるをえないものなんだよね
Next.js以上のものはもはや作れんよ
- 487 ：デフォルトの名無しさん：2024/02/08(木) 20:03:16.79 ID:XODN4PGj.net
- それな
App Routerが神過ぎるんよ
これのおかげでサーバーサイドエンジニアが全てコントロールできるようになった
- 488 ：デフォルトの名無しさん：2024/02/08(木) 20:29:26.04 ID:ZTHDKZhp.net
- >>464
forthみたいで面白くない？
- 489 ：デフォルトの名無しさん：2024/02/08(木) 21:09:57.90 ID:iGefvq8R.net
- Next.jsがRailsの息の根を止めたわけだが、
React+Next.js+〇〇
このバックエンド部分の〇〇がRustが活かせるところ
- 490 ：デフォルトの名無しさん：2024/02/08(木) 21:15:13.68 ID:fAoXwANU.net
- >>486
>>487
ReactとNextの大改革されてきた歴史を知っていれば
数年後にはまた改善されて新たな導入が必ずある
- 491 ：デフォルトの名無しさん：2024/02/08(木) 22:03:30.31 ID:z3hLjd3o.net
- もう大きくは変わらないんじゃないか？
正直俺はPages Routerまでのnext.jsはゴミだと思ってたから使ってなかった
しかしApp Routerを見たときまさに俺の求めているものだと感じた
多分これが最高地点だよ
- 492 ：デフォルトの名無しさん：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に取られたシェアを回復する
- 493 ：デフォルトの名無しさん：2024/02/09(金) 06:07:49.74 ID:79P7yOqB.net
- >>492
javascript使ったほうがラクなのになんでわざわざhtml縛りするの？
- 494 ：デフォルトの名無しさん：2024/02/09(金) 07:43:30.04 ID:uUxbU3bY.net
- Ruby信者はズレてるから仕方ない
- 495 ：デフォルトの名無しさん：2024/02/09(金) 07:53:26.10 ID:cmMrL7Ws.net
- SSRのsvelteはWebオーサリングツールから実画面に持っていきやすい
WebページのスクリプトにRust使えるブラウザとRust実装のsvelteを作ってもらいたい
- 496 ：デフォルトの名無しさん：2024/02/09(金) 08:55:44.38 ID:so08h4Qi.net
- SvelteもNext.jsもサーバーサイドでJavaScriptを動かすためエコじゃないのでいずれ新たなものに置き換えられるでしょう
- 497 ：デフォルトの名無しさん：2024/02/09(金) 09:34:26.12 ID:Kdv0HxUE.net
- std::any::type_name_of_val()は学習時にも良さそ
- 498 ：デフォルトの名無しさん：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>()
}
- 499 ：デフォルトの名無しさん：2024/02/09(金) 10:27:55.96 ID:C39eXNkM.net
- >>493
JS使った方が楽という感覚は理解できんわ
- 500 ：デフォルトの名無しさん：2024/02/09(金) 13:19:22.70 ID:YdTAf9YB.net
- >>496
next.jsのapp routerがサーバーサイドフレームワークになったの知らないの？
- 501 ：デフォルトの名無しさん：2024/02/09(金) 13:59:04.29 ID:wfDAL7tm.net
- リソースコストがかかるスクリプト言語をサーバーサイドで動かしてる連中はいずれ消えるさ
- 502 ：デフォルトの名無しさん：2024/02/09(金) 14:16:42.17 ID:YdTAf9YB.net
- >>495
app routerの登場によりSSRだとかCSRとかややこしい概念は必要ない
あるのサーバーコンポーネントとクライアントコンポーネントとサーバーアクションのみ
極めてシンプルになった
- 503 ：デフォルトの名無しさん：2024/02/09(金) 15:05:02.67 ID:7wM1u29W.net
- どんどんrustの話から離れていってんな
- 504 ：デフォルトの名無しさん：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みたいなのも仕組みとしての基本的な考え方は同じ
- 505 ：デフォルトの名無しさん：2024/02/09(金) 15:26:09.73 ID:wyTCEkUp.net
- Rustで引数の数を可変にしたいと思っただけでマクロが必要になるの、どういう思想なんだ
- 506 ：デフォルトの名無しさん：2024/02/09(金) 15:36:06.60 ID:gZOHhCrR.net
- >>505
型システムとの兼ね合い。
- 507 ：デフォルトの名無しさん：2024/02/09(金) 15:38:36.69 ID:ixshWTAh.net
- >>505
オプショナル引数 → 数が少ないならOption多いならbuilder
可変長の引数 → スライス
マクロを使うのは個々の引数の扱いがそれぞれ異なりそれぞれをコンパイル時に型をチェックしたい場合などに使う
- 508 ：デフォルトの名無しさん：2024/02/09(金) 15:52:26.69 ID:IKpgt5UR.net
- next.jsはRustフレンドリーなフレームワークだから実質Rustなんだよね
- 509 ：デフォルトの名無しさん：2024/02/09(金) 16:25:40.87 ID:YdTAf9YB.net
- >>504
その発想だとサーバーアクションは説明できないよ
- 510 ：デフォルトの名無しさん：2024/02/09(金) 16:28:31.07 ID:YdTAf9YB.net
- >>508
俺は将来的にnext.jsは全部rustで書きなおされると思ってる
- 511 ：デフォルトの名無しさん：2024/02/09(金) 16:37:49.82 ID:DOCRBofH.net
- >>504
概念自体はそっかという感じだけどそれを実装する方法があまりにもいけてなさすぎたんでしょ
App Routerはどこで実行されるか？だけを意識すればよろしい
- 512 ：デフォルトの名無しさん：2024/02/09(金) 17:13:49.98 ID:wfDAL7tm.net
- >>510
同感
- 513 ：デフォルトの名無しさん：2024/02/09(金) 18:59:39.30 ID:wyTCEkUp.net
- C++であれば関数のオーバーロードで実現していたようなことをRustでは全部封じてしまった結果、ライブラリは至る所マクロだらけ
これはRustの目指したいところなのか？
- 514 ：デフォルトの名無しさん：2024/02/09(金) 19:22:48.34 ID:6IeD8Xf6.net
- 実行時の分岐ではなくコンパイル時のコード生成に置き換わるんだから
ゼロコスト抽象化という観点ではC++のほうがそちらを目指さなければいけなかったんじゃないでしょうか。
- 515 ：デフォルトの名無しさん：2024/02/09(金) 19:24:12.28 ID:6IeD8Xf6.net
- あ、可変長引数の話とオーバーロードの話を混同してしまっていた。
- 516 ：デフォルトの名無しさん：2024/02/09(金) 19:32:53.51 ID:RpHX5dqz.net
- https://qiita.com/buntafujikawa/items/1bd808f5f55eb63df7c4
こういうの知ってたら
オーバーロードもデフォルト引数もいらね〜
どうしてもほしけりゃ別名の関数作るわ
ってならん？
- 517 ：デフォルトの名無しさん：2024/02/09(金) 19:45:04.86 ID:qkcXaSLH.net
- 別名の関数を作りたくなるのはわからんでもないけど、実際crates.ioはそうならずにマクロだらけなので
- 518 ：デフォルトの名無しさん：2024/02/09(金) 20:35:29.36 ID:gZOHhCrR.net
- 田舎者は十年間使わない道具でも納屋にしまいっぱなしってことがまあまああるけど都会だとどんどん捨てるじゃん。
都会では物より空間のほうが高くつくから。
何が大事か、何を大事ということにするかで判断が変わる。
名前を考えるってのは人にとって思ったより負荷が高いということに対する解がオーバーロードなんだよ。
でもまあオーバーロードにもデメリットは当然ながらあるので結局は何を重視するかの問題。
- 519 ：デフォルトの名無しさん：2024/02/09(金) 23:53:50.41 ID:qm1w3dJY.net
- オーバーロードは無くてもいいけどキーワード引数は欲しいかな
- 520 ：デフォルトの名無しさん：2024/02/09(金) 23:59:48.02 ID:D/1cks9J.net
- >>519
あるよ
X { name: "foo", num: 123, ... }
- 521 ：デフォルトの名無しさん：2024/02/10(土) 02:54:22.21 ID:rfU+NtYa.net
- >>520
いちいちstructを定義しなくてもいいようにするためにキーワード引数って存在してるんだよ
- 522 ：デフォルトの名無しさん：2024/02/10(土) 09:13:20.91 ID:KcmgHb9l.net
- >>521
同じことだろ
関数の引数で列挙するか構造体で列挙するかで差はない
構造体で列挙しておけば関数の引数はその構造体名だけ出せばよい
他の関数でも使い回せるメリットもある
- 523 ：デフォルトの名無しさん：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/
- 524 ：デフォルトの名無しさん：2024/02/10(土) 09:50:58.48 ID:lXB6J68A.net
- 構造体を使うかビルダーパターンで困ることはないからね
もし技術的に矛盾のない他の良い方法があれば提案してみるべきだけど既出だと思うよ
- 525 ：デフォルトの名無しさん：2024/02/10(土) 09:54:14.05 ID:Lf9bQLCg.net
- ビルダーパターンは自分で書くならめんどい
- 526 ：デフォルトの名無しさん：2024/02/10(土) 10:07:03.72 ID:iJNhxzEm.net
- >>525
でも可視性があがるよ、あと保守が楽ちん
メリットいっぱいなんだよ✌
- 527 ：デフォルトの名無しさん：2024/02/10(土) 10:08:52.95 ID:QvZInASK.net
- ADAってどう？
- 528 ：デフォルトの名無しさん：2024/02/10(土) 10:22:50.56 ID:iJNhxzEm.net
- Adaってなんだと思って調べたら米国国防総省が主導のもとで開発されたプログラミング言語なんだね
後に開発されたC++やJavaに影響を与えたんだって
- 529 ：デフォルトの名無しさん：2024/02/10(土) 10:33:01.11 ID:VP+Iax6j.net
- >>490
OSSはなんだって始め数年は大改革されるもんよ
良くない作りは早めに治さんと後になったら大変になるから
逆にズルズル引きずって大変な事になったのがPython2&3だったりyum辺りだな
- 530 ：デフォルトの名無しさん：2024/02/10(土) 10:33:37.95 ID:2jz47bNZ.net
- パターンとかきしょすぎ
Javaみてえな文化
- 531 ：デフォルトの名無しさん：2024/02/10(土) 10:36:17.39 ID:VP+Iax6j.net
- >>501
スクリプト言語は人員が集めやすいから消えはしない
世の中は理想論じゃなく現実で回ってるんだから
- 532 ：デフォルトの名無しさん：2024/02/10(土) 11:15:35.75 ID:6T66/lvp.net
- >>522
えっ、マジで違いがわからないの？
キーワード引数の価値を理解できない人がいるとは
- 533 ：デフォルトの名無しさん：2024/02/10(土) 11:20:28.46 ID:iJNhxzEm.net
- >>530
悪いがデザインパターンの考えは大事だと主張させてもらうよ
可読性、保守性至上主義なので
- 534 ：デフォルトの名無しさん：2024/02/10(土) 11:21:55.77 ID:xcSAMi5J.net
- キーワード引数のような劣った方法より構造体あるいはビルダーパターンが絶対にいいぞ
デフォルト値はまとめてDefault実装でがっちりコードも書けるしな
- 535 ：デフォルトの名無しさん：2024/02/10(土) 11:24:20.16 ID:iJNhxzEm.net
- キーワード引数は>>523に書いてあるように、いまだ有用な実装が挙がってないから無い
数年後には有用な実装が提言されてるかもしれないから待て
- 536 ：デフォルトの名無しさん：2024/02/10(土) 11:32:26.22 ID:iJNhxzEm.net
- パターンにアンチ的な考えを持つのはお門違い
Webアプリにしてもコア部分のライブラリにしても、一般的なデザインパターンに基づいて設計されていればあとから雇った技術者に引き継がせるのが楽ちん
デザインパターンのうちのひとつ、ビルダーパターンだって可読性、保守性に優れてるから使われているんだ
- 537 ：デフォルトの名無しさん：2024/02/10(土) 11:53:44.03 ID:H5a70urg.net
- >>533
構文が優れていないからパターンみたいなキショいものが必要になる
誰が書いても同じようなコードになることを目指して開発されたPythonにはデザインパターンは必要ない
- 538 ：デフォルトの名無しさん：2024/02/10(土) 11:54:44.92 ID:H5a70urg.net
- 可読性・保守性のために追加のパターンの勉強が必要だなんて信じられない
まるでJavaみたいだ
- 539 ：デフォルトの名無しさん：2024/02/10(土) 11:57:02.97 ID:iJNhxzEm.net
- >>537
だってPythonはデザインパターンを意識しないと保守が面倒になるような複雑に設計すること自体がアンチパターンじゃんか
- 540 ：デフォルトの名無しさん：2024/02/10(土) 12:00:29.93 ID:iJNhxzEm.net
- >>539 アンチパターンは言い過ぎか、Pythonにだってデザインパターンの基本的な原則はあるんだから
- 541 ：デフォルトの名無しさん：2024/02/10(土) 12:04:27.79 ID:09Czk/ru.net
- >>537
Pythonは欠陥プログラミング言語として知られているように酷い状況だよ
特に酷いと言われてるのはPythonにはinterface機能がないこと
抽象クラスで無理に実現しても劣りコードも汚い
Pythonはプログラミングはせずにあくまでもスクリプトとして用いる範囲内で使うのがよい
- 542 ：デフォルトの名無しさん：2024/02/10(土) 12:09:31.06 ID:H5a70urg.net
- まあでも言われて考えてみればbuilder patternなんてせいぜい「Pythonらしいコード」とかの範疇か
- 543 ：デフォルトの名無しさん：2024/02/10(土) 12:12:05.42 ID:X5MB5Dp7.net
- >>541
pythonにインターフェースがないのは、インターフェースが必要になるような製品にpythonで設計するなってことだぞ
- 544 ：デフォルトの名無しさん：2024/02/10(土) 12:13:49.11 ID:H5a70urg.net
- Pythonで抽象クラス使うくらいならProtocolでも使うかな
まあtrait使う方が良いのはそうかも
- 545 ：デフォルトの名無しさん：2024/02/10(土) 12:18:46.21 ID:Gv6WNLHY.net
- デザインパターンとかいうオブシコ要素をRustに持ち込むの迷惑だからやめろ
- 546 ：デフォルトの名無しさん：2024/02/10(土) 12:30:54.19 ID:iJNhxzEm.net
- パターンアンチが多いのか知らんけど、デザインパターンのうちクリーンアーキテクチャの考えは最低限習得しとくべきよ
フレームワークやライブラリと疎結合に実装しておけば保守性はばっちり
フレームワーク入れ替えのリファクタリングだって容易にできる
- 547 ：デフォルトの名無しさん：2024/02/10(土) 12:33:11.47 ID:lBFnzKPs.net
- いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
そのためRustに持ち込んでも意味がないものやRustに持ち込む必要がそもそもないことが多い
Rustを理解していない人がRustを批判しようとして逆に失敗する一因にもなっている
- 548 ：デフォルトの名無しさん：2024/02/10(土) 13:01:44.04 ID:YTHRY4oL.net
- >>546
オブジェクト指向ありきのあの本はもうオワコン
読み返すとオブジェクト指向だらけで胸焼けするよ
- 549 ：デフォルトの名無しさん：2024/02/10(土) 13:16:33.29 ID:8ut+BFv7.net
- Rustスレにオブシコアンチの居場所はないぞ
Rustはオブシコの主要機能の2/3を取り入れてるんだから
- 550 ：デフォルトの名無しさん：2024/02/10(土) 13:20:09.17 ID:LlCsSE+Z.net
- >>537
Pythonもデザインパターン盛り盛りで作られてる
必要ないとか思っちゃってるのは経験が浅いだけ
- 551 ：デフォルトの名無しさん：2024/02/10(土) 13:24:24.95 ID:RZD3J/dp.net
- >>547
>いわゆる従来のデザインパターンと呼ばれているものは前提としてクラスやクラス継承を前提としているものが多い
この考えが間違ってるんだよなぁ
デザインパターンの特定の実装しか理解してない人とデザインパターンの実装例から導き出される原則まで理解してる人では見えてる景色が正反対になってしまう例だね
- 552 ：デフォルトの名無しさん：2024/02/10(土) 13:42:15.57 ID:bXBK2+hH.net
- >>541
Pythonではインターフェースを抽象クラスで代替できるってのと
Rustではキーワード引数を構造体で代替できるってのと全く同じことなんだよな
一言で言えばどちらも低DX
- 553 ：デフォルトの名無しさん：2024/02/10(土) 13:57:43.35 ID:UK9hi/1i.net
- >>552
それは全く違う
C++とRustにキーワード引数がないのは
リソース管理の問題があるためだ
つまり引数部分で色々やると
リソース獲得問題と解放問題などが生じてしまう
だからキーワード引数ではなぬ分離したほうが好ましい
- 554 ：デフォルトの名無しさん：2024/02/10(土) 13:58:54.16 ID:iJNhxzEm.net
- >>548
クリーンアーキテクチャはアーキテクチャパターンの中でもすごくシンプルだと思うぞ
とにかく関心の分離にこだわる、この考えに尽きる
まあ、これこそオブシコの中のオブシコの考えだからアンチは大嫌いなんだろうけど
- 555 ：デフォルトの名無しさん：2024/02/10(土) 14:03:55.89 ID:lW9Vkr52.net
- >>551
言いたいことはわかるがデザインパターンといえば
GoFと言われてるようではダメで
今のパラダイムに合った本が出ないとつらいかな
- 556 ：デフォルトの名無しさん：2024/02/10(土) 14:05:28.57 ID:iJNhxzEm.net
- デザインパターンといえばGoFは流石に古くないか？？
- 557 ：デフォルトの名無しさん：2024/02/10(土) 14:05:43.92 ID:AU1t0rvZ.net
- デザインパターンという言葉はGoFに汚染されているからな
デザインパターンという言葉を使うこと自体がアンチパターン
- 558 ：デフォルトの名無しさん：2024/02/10(土) 14:08:00.40 ID:iJNhxzEm.net
- デザインパターンが広義的すぎるのは分かる
デザインパターンではなくアーキテクチャパターンと表すべきだというのなら、まさにごもっともでございます
- 559 ：デフォルトの名無しさん：2024/02/10(土) 14:23:27.48 ID:Aed3I3PZ.net
- 話がそれてるけどデフォルト引数（キーワード引数）がRustに無いのは現時点での仕様
デフォルト引数を使える点はPythonの勝ちだねおめでとう、じゃあPythonくんはブラウザバックしようか
- 560 ：デフォルトの名無しさん：2024/02/10(土) 14:40:14.16 ID:XEL9SE6k.net
- 出来ることが多いほどいいってわけじゃないからなぁ。
「構造化は好きな場所にジャンプできないから欠陥のあるパラダイム！」とは言わんでしょ。
そんでそういうのは他の言語機能との連携とか諸事情を考えて決めるべきことだから
Rust でキーワード引数がないのは「今のところは」よいバランスの仕様が思いつかないでいるってだけ。
これから良いアイデアが出るかもしれないし出ないかもしれない。
- 561 ：デフォルトの名無しさん：2024/02/10(土) 14:40:53.07 ID:b8HpDXca.net
- >>559
いつからブラウザで見ていると勘違いしていた
- 562 ：デフォルトの名無しさん：2024/02/10(土) 14:42:22.10 ID:YTHRY4oL.net
- >>551
その導き出される原則がデザインパターンなんだが何か勘違いしてない？
- 563 ：デフォルトの名無しさん：2024/02/10(土) 14:46:24.04 ID:VP+Iax6j.net
- Javarが考えた設計は根本的に汚い
- 564 ：デフォルトの名無しさん：2024/02/10(土) 14:49:44.24 ID:WFGhMJhr.net
- オブジェクト指向におけるリスコフの置換原則もクラス継承を前提にしているように
一時期のオブジェクト指向はクラス継承を使うことが前提の狭い話が多かった
元々のオブジェクト指向はオブジェクトに値がカプセル化されてメソッドが公開されてればいい
クラスやクラス継承はオブジェクト指向に必須ではなく害悪のほうが大きい
そのためRustやGoなど多くのモダン言語がクラスを排除している
- 565 ：デフォルトの名無しさん：2024/02/10(土) 14:56:46.66 ID:iJNhxzEm.net
- >>563
Java？古いぞKotlinでだいぶキレイになった
>>401にも書いたけどclassに継承まわりの制限が設けられたのは可読性保守性においてgood
- 566 ：デフォルトの名無しさん：2024/02/10(土) 14:58:45.32 ID:VP+Iax6j.net
- いや、デザインパターンとかいうワードを声高に主張してたのって昔から大体Javarだったって話
- 567 ：デフォルトの名無しさん：2024/02/10(土) 14:59:40.15 ID:iJNhxzEm.net
- ついJavaという言葉に反応しちゃったけどよく見たらJavarだった…
- 568 ：デフォルトの名無しさん：2024/02/10(土) 15:00:30.74 ID:iJNhxzEm.net
- >>566
ごめん勘違いした>>565はスルーしてほしい
- 569 ：デフォルトの名無しさん：2024/02/10(土) 15:16:47.93 ID:+PSgdWvA.net
- ・コンストラクタと関数を区別するのが面倒臭い
・関数とオブジェクトを区別するのが面倒臭い
・引数リストと普通のリストを区別するのが面倒臭い
デザパタの原則を導き出せばまあこうなる
- 570 ：デフォルトの名無しさん：2024/02/10(土) 16:24:25.37 ID:YTHRY4oL.net
- 今こそ新しいソフトウェア設計の本が必要かもな
オブジェクト指向でも関数型でもない「ふつうのソフトウェア設計入門」みたいな
- 571 ：デフォルトの名無しさん：2024/02/10(土) 16:37:42.00 ID:LPOrO1iz.net
- 継承抜きオブシコで十分っす
- 572 ：デフォルトの名無しさん：2024/02/10(土) 16:45:54.10 ID:8zmdFTlm.net
- なんでrustスレで他言語の雑談始まってしもたん
- 573 ：デフォルトの名無しさん：2024/02/10(土) 16:58:53.57 ID:WFGhMJhr.net
- >>572
他言語の話ではなく
デザインパターンの多くがクラスとその継承を前提あるいは例示していて
Rustなどのクラスを排除した最近のプログラミング言語に対して手法もしくは例示が適さない話かと
- 574 ：デフォルトの名無しさん：2024/02/10(土) 17:00:23.08 ID:9OXXn/no.net
- 継承なんざインターフェースでいくらでも代用できるやん
応用力ないん？
- 575 ：デフォルトの名無しさん：2024/02/10(土) 17:09:17.38 ID:qHcm0B3l.net
- 従来は継承を使ってカプセル化とポリモーフィズムを実現してたけど、最近は継承を使わずにカプセル化とポリモーフィズムやるのが主流よね
継承をサポートしないならクラスいらないし
- 576 ：デフォルトの名無しさん：2024/02/10(土) 17:37:53.51 ID:lWs+b/Tw.net
- Rustの型クラスは最強
- 577 ：デフォルトの名無しさん：2024/02/10(土) 17:45:44.24 ID:cODs5/To.net
- rustのデザインパターン本こそ現代のソフトウェア開発に必要なものだ
誰か出してくれ
- 578 ：デフォルトの名無しさん：2024/02/10(土) 17:48:42.70 ID:7r8QxWN2.net
- >>546
クリーンアーキテクチャとかアーキテクチャ設計レベルの話はデザインパターンの範疇ではないよ
デザイン(設計)のパターンではあるけど「デザインパターン」という言葉はもう一段階詳細レベルの話
- 579 ：デフォルトの名無しさん：2024/02/10(土) 18:00:46.16 ID:5OwpQQMY.net
- >>578
デザイン(設計)のパターンの中のひとつにGoFデザインパターンがあるのでは？
- 580 ：デフォルトの名無しさん：2024/02/10(土) 18:18:59.99 ID:cODs5/To.net
- >>578
クリーンアーキテクチャとかもろにオブジェクト指向だろ
- 581 ：デフォルトの名無しさん：2024/02/10(土) 18:20:18.08 ID:iJNhxzEm.net
- >>578
うん>>558でも言ったけどアーキテクチャパターンと言うべきだったすまん
- 582 ：デフォルトの名無しさん：2024/02/10(土) 18:22:04.19 ID:/ZC4Oa+s.net
- 只の道具なんで、向いていれば適応するし、向いてなければ使わない。
宗教的な正しさなんてどうでも良いんですよ。
おまいらは政治将校か？
- 583 ：デフォルトの名無しさん：2024/02/10(土) 18:23:43.39 ID:7r8QxWN2.net
- 実装パターン < デザインパターン < アーキテクチャパターン
すべてデザイン(設計)のパターンではあるけど対象とする粒度の違いで呼び名が違う
- 584 ：デフォルトの名無しさん：2024/02/10(土) 18:25:26.70 ID:iJNhxzEm.net
- Rustでよく使われてるパターンは
レイヤードアーキテクチャ
DDD
クリーンアーキテクチャ
なのかな？他にある？
- 585 ：デフォルトの名無しさん：2024/02/10(土) 18:26:30.51 ID:iJNhxzEm.net
- >>583
勉強になる👍
- 586 ：デフォルトの名無しさん：2024/02/10(土) 18:27:23.64 ID:7r8QxWN2.net
- >>580
そう感じるのはクリーンアーキテクチャをオブジェクト指向で実装した例だけを見て
クリーンアーキテクチャをオブジェクト指向の文脈でしか理解できてないからだと思う
- 587 ：デフォルトの名無しさん：2024/02/10(土) 18:29:37.58 ID:+PSgdWvA.net
- >>570
暴力でも寛容でもないふつうの非暴力闘争がいいのに
非暴力的な二項対立まで否定するのは行き過ぎだよ
- 588 ：デフォルトの名無しさん：2024/02/10(土) 18:50:48.17 ID:cODs5/To.net
- >>586
そういう逃げは良くないぞ
例えばDDDはオブジェクト指向じゃなくても実現できる！と言ってるのと同じ
実質そのような原典は存在しない
独自解釈によるものにすぎない
- 589 ：デフォルトの名無しさん：2024/02/10(土) 19:06:04.16 ID:kzqqrU6F.net
- オブジェクト指向、スタック指向、手続き型しか知らないんだけど他になにがあるの？勉強したいから教えてくれ
- 590 ：デフォルトの名無しさん：2024/02/10(土) 19:08:51.93 ID:kzqqrU6F.net
- あと関数型と手続き型の区別がつかない
- 591 ：デフォルトの名無しさん：2024/02/10(土) 19:19:34.87 ID:IjP+HezS.net
- 関数型はオブジェクト指向において部分的に使うもの
高階関数とかラムダ式とかはそんなに難しくない
- 592 ：デフォルトの名無しさん：2024/02/10(土) 19:31:34.99 ID:76r5Dddg.net
- >>590
一緒だよ
- 593 ：デフォルトの名無しさん：2024/02/10(土) 19:44:00.53 ID:6ZZO7tOM.net
- 高階関数は「人間にとって」わかりにくくなるので使うなと
言われているね
あと論理型というのがあったなあ
- 594 ：デフォルトの名無しさん：2024/02/10(土) 19:47:12.54 ID:IoMlesHJ.net
- >>589
フロントエンド用途でコンポーネント指向
あと関数型というのは名前の通り関数に型を持たせたってだけ
高階関数と呼ばれてるね
オブジェクト指向に成り代わるものはいまだ出てきていない
- 595 ：デフォルトの名無しさん：2024/02/10(土) 19:50:32.36 ID:H74b4wDc.net
- オブジェクト指向信者の人達、その時々の優れたものをオブジェクト指向認定してるイメージがある
あるいはオブジェクト指向とはオブジェクト指向を名乗った言語の良いところどりおよびそれと重なる全てと定義していそう
オブジェクト指向信者もJavaは嫌いそう
- 596 ：デフォルトの名無しさん：2024/02/10(土) 19:52:30.82 ID:IoMlesHJ.net
- それはそうと継承の省かれたオブジェクト指向はオブジェクト指向と名乗るべきではないと思うんだが、新しい名前は無いの？
- 597 ：デフォルトの名無しさん：2024/02/10(土) 19:57:03.35 ID:iu2BL++f.net
- むしろ継承を省かれたぐらいでオブジェクト指向を名乗れなくなる方が意味不明なんだが。
- 598 ：デフォルトの名無しさん：2024/02/10(土) 20:00:09.44 ID:lgwlEc8K.net
- オブジェクト指向は単なる理論であって言語がどう実装するかは言語の勝手
- 599 ：デフォルトの名無しさん：2024/02/10(土) 20:03:05.61 ID:6ZZO7tOM.net
- 狭義のオブジェクト指向言語は
データと操作を一つにまとめて型として使えるよ
ということだけ
カプセル化、継承、多態性をオブジェクト指向に入れるかどうかは
昔から諸説ある
- 600 ：デフォルトの名無しさん：2024/02/10(土) 20:03:30.97 ID:WFGhMJhr.net
- >>596
オブジェクト指向はオブジェクトの中に値(異種複数可)を閉じ込めてオブジェクトへの公開メソッドのみ公開すること
継承なんて概念はない
- 601 ：デフォルトの名無しさん：2024/02/10(土) 20:05:33.42 ID:2iG7gUv6.net
- なんかオブジェクト指向といいデザインパターンといい一般的な意味とは違うふうに捉えてる人が多いね
- 602 ：デフォルトの名無しさん：2024/02/10(土) 20:10:54.41 ID:VlV2WaeL.net
- オブジェクト指向かどうかはどうでもよくてどういうアーキテクチャで設計して実装するかが重要なんだけど
- 603 ：デフォルトの名無しさん：2024/02/10(土) 20:13:45.74 ID:o2x+aGn+.net
- 関数型プログラミングがどこで使われてるのか調べてみたけどコンピューターサイエンス分野しか見つからない
- 604 ：デフォルトの名無しさん：2024/02/10(土) 20:22:15.34 ID:6cZfMrU8.net
- >>603
関数型プログラミングはただの手続き型プログラミングなんだから当たり前だろ
- 605 ：デフォルトの名無しさん：2024/02/10(土) 20:30:09.19 ID:xWWw0qe+.net
- フロントエンド屋か単にスクリプト組むくらいしかやらない人はオブジェクト指向に触れない
実装屋は逆にオブジェクト指向をベースにしたものばっかりやる
オブジェクト指向アンチの正体が分かっちゃうね
- 606 ：デフォルトの名無しさん：2024/02/10(土) 20:39:26.86 ID:U5vUZCjE.net
- 手続き型を文芸的にしたのがオブジェクト指向で、数学的にしたのが関数型
- 607 ：デフォルトの名無しさん：2024/02/10(土) 20:46:30.71 ID:lnD8LNvj.net
- オブジェクト指向も関数型も確固たる定義がないバズワードだからな
話題にするだけ無駄
- 608 ：デフォルトの名無しさん：2024/02/10(土) 20:54:14.59 ID:XEL9SE6k.net
- グラデーション的だわな。
常識的な分類として「かなりこっち寄り」くらいに言えるものはあるけど。
文句なく関数型といえる汎用プログラミング言語は Haskell くらいか。
- 609 ：デフォルトの名無しさん：2024/02/10(土) 21:00:12.52 ID:2fVxDtyX.net
- オブシコアンチってなんでアンチやってるの？オブシコへのただならぬ恨みを感じるけど
- 610 ：デフォルトの名無しさん：2024/02/10(土) 21:04:41.79 ID:hNXhuidE.net
- 勉強になるような知識どんどん書き込んでくれ
- 611 ：デフォルトの名無しさん：2024/02/10(土) 21:20:25.37 ID:wHWIBAUz.net
- オブジェクトを指向指向したら汚いコードがいっぱい出た
- 612 ：デフォルトの名無しさん：2024/02/10(土) 21:34:14.43 ID:t6h0tc+k.net
- オブジェクト指向自体には問題はなにもない
問題とされているのはオブジェクト指向ではなくクラス継承
これは実装継承となるアンチパターンなので使ってはいけない
- 613 ：デフォルトの名無しさん：2024/02/10(土) 22:00:16.03 ID:EoWeXpbc.net
- >>612
ここはRustスレで継承問題はクラス機能ごと排除することでとうに解決されているんだがなんで継承問題を擦ってるんです？
- 614 ：デフォルトの名無しさん：2024/02/10(土) 22:03:08.49 ID:TERvB2uZ.net
- みんながRustを使えば解決だね
- 615 ：デフォルトの名無しさん：2024/02/10(土) 22:07:13.96 ID:a08tomEu.net
- 一部のRust信者の布教活動がひどかったせいで他スレ住人からさんざんヘイトを買い
普通のRust使いもクソどうでもいいこだわりを押し付けられるばっかりで
有益な情報が集まらないと判断しここを見限った
結果、ここが雑談部屋になることを止めようという勢力はRust信者だけになってしまった
- 616 ：デフォルトの名無しさん：2024/02/10(土) 22:12:14.65 ID:Bpk68K+1.net
- 今どきRustだけしか使えない実装屋なんているわけなくて他の言語の雑談がちゃんと通じるからなにも問題ない
バイリンガルプログラマな姿こそ実装屋が目指すべきところ
- 617 ：デフォルトの名無しさん：2024/02/10(土) 22:14:50.40 ID:XEL9SE6k.net
- べつに実装継承でもそれ自体が問題ってわけではない。
実装継承が依存を強める (密結合) といったって実際に依存があるものが依存するのは当たり前だし仕方がない。
ただ問題なのは事前に適切な設計をすることもまた出来ないという現実があるってことだ。
プログラムを書き進めたら思ってのと違うかったというときに強固な依存があると軌道修正がしんどい。
- 618 ：デフォルトの名無しさん：2024/02/10(土) 22:26:31.80 ID:ewSY5W0Q.net
- 継承は廃れた技術だから議論する意味がない
関心の分離を意識したプログラミングをしていこう
- 619 ：デフォルトの名無しさん：2024/02/10(土) 22:29:03.46 ID:Lf9bQLCg.net
- >>613
前にこのスレで話題になってただろ
Servoではポインタを使って無理矢理DOMの継承を実装してるとかなんとか
- 620 ：デフォルトの名無しさん：2024/02/10(土) 22:30:28.98 ID:HLmY2iS7.net
- >>619
なにそのアンチパターンww
俺らはこれを反面教師として頑張ろうな
- 621 ：デフォルトの名無しさん：2024/02/10(土) 22:42:16.36 ID:+PSgdWvA.net
- >>604
手続き型には関数とデータ構造がある
関数しか(抽象化され)ないというのはオブジェクト指向の視点からそう見えるだけだ
- 622 ：デフォルトの名無しさん：2024/02/10(土) 22:56:15.78 ID:XEL9SE6k.net
- 関数型言語が言う関数ってのは数学用語の関数のことで、
引数と評価結果の関係で表現される。
C とか Rust とかがいう関数のことではないよ。
関数とは呼ばれていても値を返すサブルーチンであって関数ではない。
- 623 ：デフォルトの名無しさん：2024/02/10(土) 22:57:32.43 ID:YTHRY4oL.net
- いやマジレスすなw
- 624 ：デフォルトの名無しさん：2024/02/10(土) 23:01:02.32 ID:2CpL/1KO.net
- Deref使った継承もどきは委譲と変わらんよ
継承が敬遠されるのは変数、関数単位でfinalとかsealedで修飾したりprivate/protectedを使い分けないと
基底クラスで満たすべき不変条件を継承クラスでぶっ壊されてしんどいって話だから
基底クラスをブラックボックスで抱えて公開機能だけをそのまま公開する形なら全部委譲してるのと同じ
- 625 ：デフォルトの名無しさん：2024/02/10(土) 23:23:00.37 ID:+PSgdWvA.net
- 正しい責任転嫁と悪い責任転嫁を区別するのが面倒臭いと思えば全部委譲でいい
正当化が必要と感じる人には継承が必要なのだろう
- 626 ：デフォルトの名無しさん：2024/02/11(日) 08:17:40.00 ID:Jcf8p7/N.net
- 委譲やるよりインターフェースで共通項をもたせてポリモーフィズムできるほうがスッキリ実装できる
- 627 ：デフォルトの名無しさん：2024/02/11(日) 08:28:38.26 ID:8+WjthrU.net
- インターフェースでやるときこそ委譲の使いどころでは？
データレイヤーでのインターフェースRepositoryのImplからDataSourceの各メゾットを呼び出すのはまさしく委譲の考え
- 628 ：デフォルトの名無しさん：2024/02/11(日) 09:33:37.86 ID:QXc2iF2X.net
- オブシコ＝オブジェクト指向
で使ってるとやっとわかった。「あたしこ」の「しこ」かと勘違いして訳がわからなかったよ。
- 629 ：デフォルトの名無しさん：2024/02/11(日) 09:47:23.19 ID:mQVY2wVN.net
- >>627
レポジトリはドメインレイヤーがやるところでしょ
- 630 ：デフォルトの名無しさん：2024/02/11(日) 12:10:09.20 ID:xzgPE83s.net
- >>627
delegationとforwardingの区別が付いてないね
- 631 ：デフォルトの名無しさん：2024/02/11(日) 12:18:42.79 ID:eNn3abAv.net
- ここで数学用語ではなく、学校では評価されない用語を使うのがオブジェクト指向
- 632 ：デフォルトの名無しさん：2024/02/11(日) 13:10:55.53 ID:5cbdJqGT.net
- オブジェクト指向の良い所は真に賢い人は真面目に勉強しないしょうもなさと多彩な用語の数にある
だからオブジェクト指向言語を勉強した人間は真に賢い人間と競合することなくマウントを取ることが出来るようになる
- 633 ：デフォルトの名無しさん：2024/02/11(日) 13:30:06.52 ID:UTHxd4xs.net
- >>627
それは委譲ではない
継承と委譲とインターフェースは違うもの
- 634 ：デフォルトの名無しさん：2024/02/11(日) 14:12:49.22 ID:tvA72CFJ.net
- 自分の使っている用語の定義に無頓着な人が賢いwとか有り得ない
- 635 ：デフォルトの名無しさん：2024/02/11(日) 14:28:55.59 ID:FmT3HYkV.net
- >>634
“賢い”の定義が違うんだろ
察してやれ
- 636 ：デフォルトの名無しさん：2024/02/11(日) 14:35:31.96 ID:eNn3abAv.net
- 定義を後出しすることに罪悪感がない人はたぶんもっとリアルな悪を見慣れている
- 637 ：デフォルトの名無しさん：2024/02/11(日) 15:00:23.67 ID:p0mJmxcL.net
- Rustにはインターフェースは無くて型クラスはある
型クラスを推してけ
- 638 ：デフォルトの名無しさん：2024/02/11(日) 15:56:01.57 ID:EVWrf4kv.net
- >>634
その用語、定義ありませんよｗ
君が勝手に思い込んでるだけｗ
- 639 ：デフォルトの名無しさん：2024/02/11(日) 16:06:16.13 ID:nNzLNGzY.net
- オブシコ用語って掛け算順序界隈の主張する「等分除と包含除」とかの仲間だよね
- 640 ：デフォルトの名無しさん：2024/02/11(日) 16:16:18.76 ID:+E66gntj.net
- >>639
(^_^)ﾉ
- 641 ：デフォルトの名無しさん：2024/02/11(日) 16:21:31.17 ID:cP74y9AE.net
- 時代はオブシコではなく関数型プログラミング
オブシコは時代遅れ
例えば機械学習は関数型プログラミングやってる
- 642 ：デフォルトの名無しさん：2024/02/11(日) 16:24:12.02 ID:aCOYKxUA.net
- >>637
型理論においてはどちらも同じ
- 643 ：デフォルトの名無しさん：2024/02/11(日) 16:30:25.25 ID:O/MMVA2r.net
- なんかみんな単発だからレスバできないなあ
- 644 ：デフォルトの名無しさん：2024/02/11(日) 20:46:34.90 ID:XOn8R4o/.net
- RustがJSを滅ぼしてくれるのはいつになるかいのう……
- 645 ：デフォルトの名無しさん：2024/02/11(日) 21:26:37.41 ID:M/VumamL.net
- まず先にDOMを滅ぼしてくれないとRustがウェブを乗っ取れない
DOMがJS依存すぎる
- 646 ：デフォルトの名無しさん：2024/02/11(日) 21:51:44.10 ID:XOPhWcHA.net
- DOMはJSに依存しないしいろんな言語のインターフェースがあるが。
- 647 ：デフォルトの名無しさん：2024/02/11(日) 22:42:14.41 ID:575tRfGH.net
- >>646
肝心のWasmにDOM操作を許可しないんじゃ意味ない
- 648 ：デフォルトの名無しさん：2024/02/11(日) 22:47:25.71 ID:YLWTi6Ka.net
- >>647
DOM操作自体はwasmでもできるぞ
オーバーヘッドが大きすぎて遅いだけ
- 649 ：デフォルトの名無しさん：2024/02/11(日) 22:56:40.04 ID:Ij1X5KaV.net
- >>648
Wasmから直接DOM操作は不可能
JavaScriptにやってもらうしかない
つまりJavaScriptしかできない
そのため単純なDOM操作だとJavaScriptが有利だが
Wasmで何らかの処理をしつつのDOM操作だとWasmが勝つことが増えていく
- 650 ：デフォルトの名無しさん：2024/02/11(日) 23:09:37.71 ID:bi52uRem.net
- 自演ええて
- 651 ：デフォルトの名無しさん：2024/02/11(日) 23:36:32.19 ID:BuG8Esm8.net
- >>649
645だけど、だからDOM自体が欠陥品なんだって
JS依存の現状から脱却するにはDOMに変わるものが必要
- 652 ：デフォルトの名無しさん：2024/02/12(月) 00:40:57.30 ID:cVfqqlnc.net
- tree構造以外である程度の汎用性あるデータ構造なんてないわ。
- 653 ：デフォルトの名無しさん：2024/02/12(月) 01:04:43.36 ID:tgn3NuIP.net
- DOMに文句言ったところで何かが変わるわけじゃないからな
どうでもいい話
- 654 ：デフォルトの名無しさん：2024/02/12(月) 10:19:02.60 ID:Autq7Dxb.net
- >>651
現状JSからしか使えないってのとDOMに欠陥があるかどうかってのは全然別の話だと思うが。
- 655 ：デフォルトの名無しさん：2024/02/12(月) 10:33:25.13 ID:QcKWCRm/.net
- >>654
DOMには安全性のためにJavaScriptでしか触れないのは、DOMの出た当初は良かったが、JavaScript以外の言語も幅広く使われるようになった今ではその設計が古くなって欠陥品になってるのは事実
- 656 ：デフォルトの名無しさん：2024/02/12(月) 10:41:33.86 ID:Autq7Dxb.net
- DOMの設計と全然関係ない話。
- 657 ：デフォルトの名無しさん：2024/02/12(月) 10:51:22.86 ID:dpV2oNnW.net
- >>653
他人に文句を言うより自分で労働するという正義感は過労死の原因だよ
クレーマーはこの正義感を変えるじゃなくて既に変化した人
- 658 ：デフォルトの名無しさん：2024/02/12(月) 11:07:16.48 ID:UiVeSAOt.net
- domなしでのナビゲーションの方法があってもいいとは思う
- 659 ：デフォルトの名無しさん：2024/02/12(月) 11:08:30.75 ID:CTu12wXT.net
- いい加減にDOMはXMLをやめようぜ
無駄な構文が莫大な通信ロスを生んでる
- 660 ：デフォルトの名無しさん：2024/02/12(月) 11:23:28.89 ID:u1N968/b.net
- >>657
正義感w
自分でコントロールできないこととコントロールできることの判別こそ過労死しないためには最重要なんだけどね
DOMが欠陥品？
で？君はどうしたいんだい？
- 661 ：デフォルトの名無しさん：2024/02/12(月) 11:28:30.41 ID:e3JrcLqa.net
- >>655
昔DOMは他の言語からでも直接触れたがほぼ全て淘汰されてJSだけが生き残った
- 662 ：デフォルトの名無しさん：2024/02/12(月) 11:38:53.51 ID:nlvJBCEb.net
- DOMをゴミと言うのはWindowsをゴミと言ってるのと同等で無駄なこと
- 663 ：デフォルトの名無しさん：2024/02/12(月) 11:41:30.45 ID:dpV2oNnW.net
- やりたいことを先に固定してからそれに合わせて物事をコントロール可能にするという順序は逆にしたい
- 664 ：デフォルトの名無しさん：2024/02/12(月) 13:30:26.12 ID:UkU83gVN.net
- DOMの代替の候補って存在するのかな
- 665 ：デフォルトの名無しさん：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側の内部に閉じたデータのみメモリ管理すればよくなるからだ
- 666 ：デフォルトの名無しさん：2024/02/12(月) 15:41:26.64 ID:QicyHe7E.net
- デザインパターンはあくまで定石集なんだから、Rust用のデザインパターン作ればいいだけの話。
「Rustならこんなに簡単にできる」と自慢できるから、信者にとってもいいことかと。
あと、Rustでダックタイピングできたっけ？ 事前にTraitで定義しなきゃいけないんだったら面倒だなぁ。
- 667 ：デフォルトの名無しさん：2024/02/12(月) 15:46:26.73 ID:FSKnAMMD.net
- デザインパターンって簡単に実装できるとか
自慢するたぐいのものだっけ？
- 668 ：デフォルトの名無しさん：2024/02/12(月) 15:55:33.33 ID:Jqge1vnq.net
- 単発NG推奨
- 669 ：デフォルトの名無しさん：2024/02/12(月) 15:56:29.31 ID:9yTkyF6j.net
- ドメインまわりをフレームワークと分離させる設計ならなんでもいいや
今後リファクタリングすることを考えた設計が大事
- 670 ：デフォルトの名無しさん：2024/02/12(月) 15:56:34.13 ID:Jqge1vnq.net
- ここはRustスレです消えてください
- 671 ：デフォルトの名無しさん：2024/02/12(月) 16:00:10.23 ID:nHDMmyKy.net
- >>666
ダックタイピングは動的型付け言語のためのオモチャであり
デメリットも多いためまともな言語はダックタイピングを排除して別の形を取っている
ダックタイピングは規律のない無政府状態であり可読性も下げデバッグもしにくくなり最悪となる
もちろん実行時の動的型付けの問題もはらんでおり自然の静的なチェックができない
- 672 ：デフォルトの名無しさん：2024/02/12(月) 16:11:47.85 ID:KZYjz35/.net
- ダックタイピングというゴミのような方法に対して
Rustはダックタイピングを採用せずに代わりに完璧な方法を用意した
それがtraitのrequired methodsとtrait boundsである
この二つにより全てを解決している
- 673 ：デフォルトの名無しさん：2024/02/12(月) 16:12:19.21 ID:9yTkyF6j.net
- ダックタイピングなんて荒業ではなく、ポリモーフィズムをやりましょ
- 674 ：デフォルトの名無しさん：2024/02/12(月) 16:23:13.06 ID:cVfqqlnc.net
- >>664
ない。結局まともに使えるものを用意しようと思えばああなる。
それも理解せずに馬鹿みたいに文句言ってるだけだわな。
- 675 ：デフォルトの名無しさん：2024/02/12(月) 18:20:41.31 ID:g0MzjlGR.net
- >>667
繰り返されれば飽きる
繰り返されないのはパターンではない
- 676 ：デフォルトの名無しさん：2024/02/12(月) 18:37:22.53 ID:NJ55srXB.net
- >>671
GoやTypeScriptみたいな静的片付け言語でもダックタイピング採用してるよ
nominal/structuralと動的/静的は直交
- 677 ：デフォルトの名無しさん：2024/02/12(月) 18:47:33.19 ID:0RqNbR5g.net
- Goは実行時にランタイムが動的にvtableを生成してメソッドlookupするわけだから
静的ではないでしょ？
そんなことはC++やRustでは許されない行為だよ
- 678 ：デフォルトの名無しさん：2024/02/12(月) 19:22:42.84 ID:QavMz5Qe.net
- >>676
TSはanyで型が消えてるときの話じゃないの？
- 679 ：デフォルトの名無しさん：2024/02/12(月) 20:01:03.19 ID:uYjIYqfU.net
- 誰も定義の擦り合わせをしないのでどんどん意思疎通が困難になっていく
- 680 ：デフォルトの名無しさん：2024/02/12(月) 20:07:14.69 ID:uYjIYqfU.net
- 一言居士の群れ
- 681 ：デフォルトの名無しさん：2024/02/12(月) 20:21:22.17 ID:oZv/D2wt.net
- ダックタイピングは一見するとお手軽に見えるけどプログラミング開発の足を引っ張る悪
Rustは排除しているので大丈夫
そしてRustではトレイト境界により確実に使えるものだけを呼び出せることを静的に保証しつつ用いる
- 682 ：デフォルトの名無しさん：2024/02/12(月) 20:24:19.09 ID:H9LyWZwk.net
- 現代はデザインパターンで設計するんじゃなくフレームワークで作る時代だけどな
- 683 ：デフォルトの名無しさん：2024/02/12(月) 20:44:24.28 ID:5CWzyU2K.net
- >>682
そのフレームワークがデザインパターンで出来てるんだけど
- 684 ：デフォルトの名無しさん：2024/02/12(月) 21:02:02.43 ID:g0MzjlGR.net
- アルゴリズムはライブラリを一個作れば終わり
もう一個作ったら車輪の再発明
だがデザインのレベルではワンパターンが続いてもなぜか攻撃されない
- 685 ：デフォルトの名無しさん：2024/02/12(月) 21:59:54.43 ID:QicyHe7E.net
- >>673 >>677
c++ templateは静的ポリモーフィズムのダックタイピングの代表例だろ……
Rustのgenericsはどれくらいダックタイピングできているかね。
- 686 ：デフォルトの名無しさん：2024/02/12(月) 22:09:04.93 ID:h7gv4DVB.net
- >>685
C++の静的ポリモーフィズムはダックタイピングではない
ダックタイピングは実行時に動的に処理されるものだけを指す
例えばGoはinterfaceでダックタイピングするが実行時にランタイムが動的にitable (interface table)を生成して用いる
これは実行時に動的に処理されるためダックタイピングとなる
もちろん実行時に動的に処理するためダックタイピングはどの言語でも問題を孕んでいる
手軽さとの引き換えだ
- 687 ：デフォルトの名無しさん：2024/02/12(月) 22:14:48.84 ID:YxZv/CkW.net
- C++のtemplate（concepts無し）のダックタイピングが好きなら
genericsよりmacro_rules!の方がいいよ
- 688 ：デフォルトの名無しさん：2024/02/12(月) 22:15:23.35 ID:JpOX7sRf.net
- C++のtemplateで正しく関数を呼ぶの難しいよ……
- 689 ：デフォルトの名無しさん：2024/02/12(月) 22:30:02.58 ID:DrV/13x2.net
- >>677
静的型付けの意味から解説せなあかんのんか？
勘弁してくれよ
- 690 ：デフォルトの名無しさん：2024/02/12(月) 22:30:58.32 ID:9yTkyF6j.net
- C++はちゃんとコンセプト使わないとだめだよ
黒魔術は禁止です
- 691 ：デフォルトの名無しさん：2024/02/12(月) 22:50:06.45 ID:kWCXoXun.net
- C++のテンプレートは闇深すぎるよね
- 692 ：デフォルトの名無しさん：2024/02/12(月) 22:50:36.74 ID:4VueJhli.net
- >>686
C++ のテンプレートが受け入れる型は型同士の関係ではなくその性質に依存する。
一般的にもダッタイピングの典型例として挙げられることは多いし、静的か動的かで区別するという理屈を私が見たのはここがはじめてだ。
- 693 ：デフォルトの名無しさん：2024/02/12(月) 22:54:09.63 ID:RSTU7X98.net
- >>685
Rustのgenericsはtrait boundsにより完璧に静的に安全安心にチェックされ保証できる
- 694 ：デフォルトの名無しさん：2024/02/12(月) 23:33:02.01 ID:g0MzjlGR.net
- >>692
ダックタイピングの言い回しに前例はなくても原因はあるんだろう
そして原因はおれじゃない、あいつがやったという理屈は何度も見たことがある
- 695 ：デフォルトの名無しさん：2024/02/12(月) 23:52:54.50 ID:Dj37TM3K.net
- 委譲やダックタイピングを理解してないのもどうかと思ったけど
↓これらの区別ができてないのは致命的だと思うので勉強しようね
静的型付け/動的型付け
静的ポリモーフィズム/動的ポリモーフィズム
静的処理/動的処理
- 696 ：デフォルトの名無しさん：2024/02/13(火) 00:30:00.87 ID:xtMg5XLl.net
- 確固たる誰しもが認める定義のない言葉を勝手に定義してマウントとるのはやめよう？
- 697 ：デフォルトの名無しさん：2024/02/13(火) 02:23:26.95 ID:vbRTXFPD.net
- ファクトチェック界隈では事実かデマかが確固たる論点だよね
公式ルールか、ローカルルールか、という発想はそれ自体がマイノリティ
- 698 ：デフォルトの名無しさん：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
英語版が一番詳しいかね。
- 699 ：デフォルトの名無しさん：2024/02/13(火) 07:31:17.64 ID:KlTxxkJG.net
- >>683
フレームワークがデザインパターンのセオリー通りにできてるかって言ったら意外とセオリーを破って新しいムーブを作ったりするのはよくある
結局パターン通りに作る云々が論じられるのはフレームワークを使う側
- 700 ：デフォルトの名無しさん：2024/02/13(火) 08:18:01.41 ID:EJGfS3Xj.net
- >>699
アンチパターンや亜種になるだけで全部パターンだぞ
- 701 ：デフォルトの名無しさん：2024/02/13(火) 08:30:13.65 ID:eXWviQcC.net
- はじめにパターンありき、ではない
- 702 ：デフォルトの名無しさん：2024/02/13(火) 09:29:40.48 ID:d0oThnC1.net
- ダックタイピングはお手軽さを上回るデメリットだらけの悪手法
問題もなく安全で高速なRustのトレイト方式が最善策
トレイト境界により安全に呼び出せる範囲を明確にしてる点が要所
- 703 ：デフォルトの名無しさん：2024/02/13(火) 10:20:47.32 ID:yeb3oliP.net
- うちの講師が全てにおいてPythonに劣った言語って言ってるけどマ？
- 704 ：デフォルトの名無しさん：2024/02/13(火) 10:23:31.22 ID:T85IlqBy.net
- >>703
そんなわけないでしょ
- 705 ：デフォルトの名無しさん：2024/02/13(火) 10:29:29.95 ID:iVxwtbvh.net
- >>703
Pythonは遅いし本質でない実行時デバッグも大変だし
速くて実行前に静的に解決できるRustがベストな言語だよ
- 706 ：デフォルトの名無しさん：2024/02/13(火) 10:30:11.10 ID:ep9QvdZW.net
- >>703
その講師はメインでなにを教えてるん？データサイエンス？少なくともコンピュータ工学やメカトロニクスではなさそう
- 707 ：デフォルトの名無しさん：2024/02/13(火) 10:31:44.87 ID:mnEJD8Sx.net
- >>703
その講師優秀やな
- 708 ：デフォルトの名無しさん：2024/02/13(火) 11:11:21.55 ID:mXdLEMzy.net
- >>705
その講師も大概だがお前もデバッグをまともにやったことないだろ。
- 709 ：デフォルトの名無しさん：2024/02/13(火) 11:16:14.81 ID:iVxwtbvh.net
- >>708
Pythonは実行時に発覚するエラーが多すぎてプログラミング言語として辛いんよ
- 710 ：デフォルトの名無しさん：2024/02/13(火) 11:22:46.51 ID:BKo58x30.net
- ここまで俺の自演
- 711 ：デフォルトの名無しさん：2024/02/13(火) 11:32:02.27 ID:mXdLEMzy.net
- >>709
よっぽどレベル低いことしてない限りそこまでキツくはないわ。
むしろrustのビルド時間分使えばよっぽど楽にテスト構築もできるまである。
- 712 ：デフォルトの名無しさん：2024/02/13(火) 11:43:25.76 ID:bOFev+sF.net
- >>703
どーせデータ分析やデータサイエンスの講師だろ
くだらない釣りやめろ
- 713 ：デフォルトの名無しさん：2024/02/13(火) 11:46:14.62 ID:bOFev+sF.net
- まあどうせ荒らしのたぐいだろうから安価つけても無視されて無駄なんだろうな
くだらねえほんと
- 714 ：デフォルトの名無しさん：2024/02/13(火) 11:53:02.08 ID:rA+hqhZ3.net
- 荒らしに構った時点でお前らの負け
- 715 ：デフォルトの名無しさん：2024/02/13(火) 11:57:48.21 ID:qvC4XjeP.net
- >>703が荒らし判定されてて草ww
- 716 ：デフォルトの名無しさん：2024/02/13(火) 12:05:17.83 ID:n6Gkr1cM.net
- >>702
trait boundはgenerics と型パラメータの相互依存が重たい気が。
c++ template & conceptみたいに、templateから型パラメータへの一方向依存になるように(型パラメータに指定される型はtemplateから独立するように)できたっけ？
- 717 ：デフォルトの名無しさん：2024/02/13(火) 12:09:09.09 ID:IxuyFkNI.net
- わかる→ Pythonで簡単なスクリプトを書く
キチガイ→ Pythonでプログラミング開発する
- 718 ：デフォルトの名無しさん：2024/02/13(火) 12:12:34.52 ID:KvZIg8uL.net
- Pythonでプログラム書くのもちゃんと型書いてlintしたら出来なくもないよ
- 719 ：デフォルトの名無しさん：2024/02/13(火) 12:15:32.69 ID:1UgkqCq+.net
- よく分からんが画像生成系のフロントエンドでrubyベースのってあったっけ？
- 720 ：デフォルトの名無しさん：2024/02/13(火) 13:03:33.72 ID:X5Whr4lm.net
- 単発NG推奨
- 721 ：デフォルトの名無しさん：2024/02/13(火) 13:04:48.12 ID:X5Whr4lm.net
- 単発NG推奨
連鎖あぼーん推奨
- 722 ：デフォルトの名無しさん：2024/02/13(火) 13:49:44.45 ID:BKo58x30.net
- スレNG推奨では？
- 723 ：デフォルトの名無しさん：2024/02/13(火) 14:10:44.85 ID:q0xfm82v.net
- また境界知能が暴れてんのか
いい加減諦めろよ
- 724 ：デフォルトの名無しさん：2024/02/13(火) 15:09:27.64 ID:j+0n3+gu.net
- C++20のコンセプトはゴミみたいなenable_if_tを使わなくてよくなって見やすくなったよね
まだまともに使う機会が来なくて慣れてないけど
- 725 ：デフォルトの名無しさん：2024/02/13(火) 19:22:36.57 ID:ui4ZrT7T.net
- XML大嫌い
- 726 ：デフォルトの名無しさん：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の型パラメータでやろうとするとカオスになる
- 727 ：デフォルトの名無しさん：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
その二種類の混合も可能
- 728 ：デフォルトの名無しさん：2024/02/13(火) 21:08:42.27 ID:4D6oEUgV.net
- ごめん
>>727はこうね
型パラメタResponseとErrorはこのtraitを実装する各型に依存して決まり
型パラメタRequestは依存しない
- 729 ：デフォルトの名無しさん：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が必要になるのは過剰な相互依存になる。
クラスの継承もそうだけど、余計な依存性は面倒だからできるだけ排除したいところ。
- 730 ：デフォルトの名無しさん：2024/02/13(火) 23:17:32.55 ID:RVgq5WHA.net
- それはgeneric constraintがnominalかstructuralかという違い
Rustはnominalのみでstructural generic constraintはサポートしてないよ
- 731 ：デフォルトの名無しさん：2024/02/13(火) 23:20:56.53 ID:KlTxxkJG.net
- Pythonは全てにおいてJuliaに劣った言語だな
- 732 ：デフォルトの名無しさん：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()で別の実装するし
- 733 ：デフォルトの名無しさん：2024/02/13(火) 23:28:48.94 ID:RVgq5WHA.net
- >>726
>traitを実装するときに内部で自動的に決まる ⇒ association type（例：Deref::Target）
ある型に対するtrait実装をただ一つだけにしたいものや
自然と一つだけになるような性質のものはassciated typesを使う
使う側はassociated typesのほうが使いやすいので
悩んだらとりあえずassociated typesからはじめてみる
- 734 ：デフォルトの名無しさん：2024/02/13(火) 23:30:39.22 ID:9eHJiOzP.net
- >>729
そこはtrait介在させなきゃいけないところでしょ
Rustの方針が正しいと思うよ
- 735 ：デフォルトの名無しさん：2024/02/13(火) 23:32:24.97 ID:RaqlAe+S.net
- traitとかいうつまらない機能にこだわってないでPython極めろよ
時代はAIだぞ
- 736 ：デフォルトの名無しさん：2024/02/13(火) 23:35:00.89 ID:8wj/C7pB.net
- >>735
Rustをただ貶したいだけのやつは黙っとけよ雑魚
- 737 ：デフォルトの名無しさん：2024/02/14(水) 05:05:25.04 ID:uLd8jazY.net
- Pythonはスクリプト言語のクセにメソッドチェーンもロクに使えないうんこだからなぁ。
比較で持ち出すならせめてNimにしろよ。
- 738 ：デフォルトの名無しさん：2024/02/14(水) 05:28:01.52 ID:uLd8jazY.net
- >732 >734
Rustのtrait boundはあらかじめ型の方でtraitを準備しておかなきゃいけない。
これはRustが嫌っているクラスの継承みたいなもので、genericsやるごとに元の型/traitを弄くり回す必要が出てこない？
呼び出し元が真に必要なのは機能だけなんだから、同じ名前で互換性のある引数型・戻り値型ならそのまま利用できる方が良い。
まあ、ダックタイプみたいに手を抜かずにAdapter作れ、と言う方針でも良いけど、それならAdapter helperをもっと充実して欲しいところ。
AdapterパターンとかDecorator パターンて重要なのに言語側のサポート薄いよなぁ。
- 739 ：デフォルトの名無しさん：2024/02/14(水) 06:58:38.09 ID:t2TEYrx/.net
- >>738
>>これはRustが嫌っているクラスの継承みたいなもの
クラス継承は基底クラスの実装をそのまま継承する実装継承になっていることが問題点
一方でRustはトレイト境界となるトレイトに対して自分で実装を用意する
したがってRustでは実装継承とはならず問題が生じない
- 740 ：デフォルトの名無しさん：2024/02/14(水) 07:00:00.30 ID:HWQ4xiFb.net
- 自演きもいなあ
- 741 ：デフォルトの名無しさん：2024/02/14(水) 07:00:27.71 ID:523CbVaw.net
- 実装継承はゴミ
- 742 ：デフォルトの名無しさん：2024/02/14(水) 07:05:57.04 ID:Uwd6Wtce.net
- >>737
Ninはコンパイル時間の無駄があるからゴミ
Pythonは実行までの速度が一番早い
- 743 ：デフォルトの名無しさん：2024/02/14(水) 07:33:52.24 ID:uLd8jazY.net
- >>739
全然理解できていないね。
継承の問題点は、コンパイラ都合で早い段階で設計を固定しなきゃいけない「早すぎる最適化」。
機能とか実装の問題じゃなくて設計の問題。
- 744 ：デフォルトの名無しさん：2024/02/14(水) 08:08:30.71 ID:b46uhNiQ.net
- >>742
実運用はビルド済だから関係ないな。
- 745 ：デフォルトの名無しさん：2024/02/14(水) 08:09:58.02 ID:t2TEYrx/.net
- >>743
それは継承の問題点
Rustのトレイトは各型が自分で実装するため継承ではない
- 746 ：デフォルトの名無しさん：2024/02/14(水) 08:41:45.06 ID:W3PM5KGQ.net
- >>745
早すぎる最適化が問題なんだから、トレイトもその問題を引き継いでるぞ
- 747 ：デフォルトの名無しさん：2024/02/14(水) 08:51:32.74 ID:t2TEYrx/.net
- >>746
早すぎる最適化が問題になるのは継承
Rustのトレイトは継承ではなく合成で用いる
- 748 ：デフォルトの名無しさん：2024/02/14(水) 08:55:57.66 ID:b46uhNiQ.net
- >>745
全然理解できていないね。
>>743根は設計の問題で実装関係無いし、継承特有の問題というわけでもない。
>729というとfはDrawable以外のトレイトのdrawが使えない制限あるし、Circleも、問題領域に関する知識の少ない設計初期にtrait Drawableを実装するという仕様固定を行う必要がある。
c++のtemplate concept はあくまでdrawのみに依存するという違いがある。
- 749 ：デフォルトの名無しさん：2024/02/14(水) 09:07:35.89 ID:L7EuZktb.net
- 真面目に理解したいなら>>730が正解だからstructural typingとnominal typingの意味を調べてくればいいよ
- 750 ：デフォルトの名無しさん：2024/02/14(水) 09:20:06.07 ID:BSRmwKLd.net
- >>729
C++は酷いな
struct定義の時点でdraw()宣言を要求してしまうのか
Rustなら
struct定義の時点でdraw()宣言を要求せずに済む
後からdraw()という機能(＝Drawableトレイト)が必要になった時点で
structに対してDrawableを実装すればいい
Rustの方が優れてるな
- 751 ：デフォルトの名無しさん：2024/02/14(水) 09:36:07.02 ID:48k6rT3Y.net
- >>738
複オジに毒されすぎ
オジが一つ覚えで繰り返し書いてる内容がRust開発陣の見解だと勘違いしないようにね
- 752 ：デフォルトの名無しさん：2024/02/14(水) 09:47:17.10 ID:c6aYZ04m.net
- >>738
根本的な理解がおかしいので説明すると
Rustのtraitは機能を抽象化している
各型はその機能が必要になった時にそのtraitを実装(impl)すればよい
必要な分の各機能(trait)を実装することで結果的に各機能の合成となる
- 753 ：デフォルトの名無しさん：2024/02/14(水) 09:59:07.19 ID:YhuSf3ik.net
- 細かな実装上の違いはあるけど概念レベルでは Rustのトレイトも他言語のインターフェースも同じ
実装上の違いを見て異なる概念だと勘違いしてると本質を見失う
- 754 ：デフォルトの名無しさん：2024/02/14(水) 10:10:46.95 ID:Z6/Yikm0.net
- >>750
そりゃダックタイピングでdrawを使いたいんだから、drawの無い型は対象外。
>>752
もともとの話はダックタイピングでtraitじゃないよ。
Rustで静的ダックタイピング・ダックテストする方法はあるかしらん？
- 755 ：デフォルトの名無しさん：2024/02/14(水) 10:17:10.59 ID:naKe/3pl.net
- ダックタイピングという問題ありまくりのものを有り難がるのはバカだけ
- 756 ：デフォルトの名無しさん：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を実装するかまで指定できるから混同の心配がなくなる
- 757 ：デフォルトの名無しさん：2024/02/14(水) 10:44:54.87 ID:AzS2pw5X.net
- ダックタイピングは使う側が気をつければなにも問題ないんだよなあ
そこらへん理解してないあたり実装をやったことのないエアプなんだろうな
かわいそう
- 758 ：デフォルトの名無しさん：2024/02/14(水) 10:53:25.15 ID:naKe/3pl.net
- >>757
その「使う側が気をつければ問題ない」が最悪
ミスが入り込んだ時に気付かず問題を引き起こす
ダックタイピングを持ち上げるのはバカだけ
- 759 ：デフォルトの名無しさん：2024/02/14(水) 11:07:38.32 ID:RfRsJx+N.net
- 使う側が気をつけるならC++も問題ないからな
- 760 ：デフォルトの名無しさん：2024/02/14(水) 11:17:22.43 ID:NjTyhCIW.net
- >>756
これがいわゆる実装継承の再発明
このケースはマクロよりも同じ実装継承のデフォルト実装のほうがベター
- 761 ：デフォルトの名無しさん：2024/02/14(水) 11:23:15.20 ID:FEB+PUkj.net
- >>759
そゆこと
だからRustは不要
- 762 ：デフォルトの名無しさん：2024/02/14(水) 11:28:02.15 ID:naKe/3pl.net
- ダメ人間の思想「使う側が気をつければ問題ない」によって
今まで数多のなかなか見つからないバグやセキュリティホールを生じてきたのがプログラミング言語の黒歴史
今後はそのような言語を用いてはいけない
- 763 ：デフォルトの名無しさん：2024/02/14(水) 11:51:49.92 ID:L7EuZktb.net
- ここで>>9-20の流れを振り返ってみましょう
- 764 ：デフォルトの名無しさん：2024/02/14(水) 11:52:42.46 ID:3OoaoCBc.net
- C の後置 ++ 演算子のようなことをする Rust の関数が標準で有ったりしますか？
リファレンスマニュアルをざっとみた感じでは見つけられないのですが……。
具体的に言えば
fn increment(dest: &mut u32) -> u32 {
let t = *dest;
*dest += 1;
t
}
みたいなことをしたくて、いかにもよくありそうなパターンなので標準内にあってもよさそうなもんだと思った次第です。
- 765 ：デフォルトの名無しさん：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するだけなら大袈裟すぎる気がする
- 766 ：デフォルトの名無しさん：2024/02/14(水) 12:19:27.37 ID:Cdw7DngV.net
- >>761
だから の文が全然繋がってなくてワラタw
こういう低能はプログラミングしちゃダメだよ。
- 767 ：デフォルトの名無しさん：2024/02/14(水) 12:25:13.12 ID:b46uhNiQ.net
- >>755
そうして無駄な依存関係を負の遺産として引きずるか、設計が破綻して再構築するか。
DbCとか勉強したほうがいいよ。
- 768 ：デフォルトの名無しさん：2024/02/14(水) 12:29:23.30 ID:naKe/3pl.net
- >>767
ダックタイピングが負の遺産であることは自明だが
ダックタイピングを使わないことが負の遺産だと主張する君は破綻している
- 769 ：デフォルトの名無しさん：2024/02/14(水) 12:49:07.16 ID:b46uhNiQ.net
- >>768
自明だと検証できる証明を示して頂戴。
検証可能性の無い主張は単なる疑似科学だし。
- 770 ：デフォルトの名無しさん：2024/02/14(水) 12:52:16.39 ID:KpCwABm3.net
- 欠点がない言語なんて無いから言い争ってもね。
- 771 ：デフォルトの名無しさん：2024/02/14(水) 12:57:57.69 ID:p6Tfi6cJ.net
- そもそも人間自体が欠陥なんだからその人間の作った言語に欠陥があるのは自明
- 772 ：デフォルトの名無しさん：2024/02/14(水) 13:07:28.33 ID:L7EuZktb.net
- たし🦀
- 773 ：デフォルトの名無しさん：2024/02/14(水) 13:09:31.24 ID:aR1xhX8a.net
- おれたちは欠陥と共存してよりよいプログラミングスタイルを目指すべき
- 774 ：デフォルトの名無しさん：2024/02/14(水) 13:16:05.40 ID:eD+V22zq.net
- drawという名前のメソッドを作ったらそれらが全部ダックタイピングとして使われうることを想定しないといけないのきつすぎる
適当な名前つけたら想定外の使われ方をすることをケアしないといけないわけだ
- 775 ：デフォルトの名無しさん：2024/02/14(水) 13:33:10.33 ID:Q08aEmFz.net
- 境界知能が可視化されてる
- 776 ：デフォルトの名無しさん：2024/02/14(水) 13:53:52.28 ID:Z6/Yikm0.net
- >>774
当たり前だろ。
インターフェイスは利用者に対する契約だからな。使わせる気が無ければ公開するな。
- 777 ：デフォルトの名無しさん：2024/02/14(水) 13:55:32.21 ID:eD+V22zq.net
- >>776
ダックタイピングはその契約書が定義されてないのが良くない
Traitは契約書の定義みたいなもんだ
ダックタイピングは白紙の契約書にサインするようなものだ
- 778 ：デフォルトの名無しさん：2024/02/14(水) 13:57:04.55 ID:s22bd+Hs.net
- >>775
お前のこと？
- 779 ：デフォルトの名無しさん：2024/02/14(水) 14:31:04.48 ID:h4S8S2sP.net
- >>777
これな
- 780 ：デフォルトの名無しさん：2024/02/14(水) 14:41:15.13 ID:3OoaoCBc.net
- >>765
replace だと借用規則に引っかかってエラーになるようです。
まあ自分で書いてもたいしたものじゃないのでなければなくても困りはしないんですが……
- 781 ：デフォルトの名無しさん：2024/02/14(水) 15:12:12.70 ID:s2Ev9A6j.net
- >>780
Copy型だから通りそうな気がしたけど無理だったか
何か技がありそうだけどそこまでするほどの問題じゃないよな
- 782 ：デフォルトの名無しさん：2024/02/14(水) 15:36:36.14 ID:S2bQYQek.net
- >>764
Rustで++は排除されている
理由はたくさんあるようだが
例えば今回のそのCコードは*dst++では動かず(*dst)++とする必要があるようにミスが増えるとか
前置と後置の間違いミスも多いことに加えて
生ポインタはsafe Rustから排除されたため*ptr++の形が出て来ないことや
move/copy問題もあったかな
- 783 ：デフォルトの名無しさん：2024/02/14(水) 16:02:27.29 ID:3OoaoCBc.net
- >>782
そんな話はしてないです。
役に立つことを言えないなら余計な茶々入れるな。
- 784 ：デフォルトの名無しさん：2024/02/14(水) 16:29:39.74 ID:ona7PgM1.net
- >>783
おまえ質問してる分際でキチガイなのか？
そういう態度を改めないなら二度と教えてやらんぞ
fn increment(dest: &mut u32) -> u32 {
std::mem::replace(dest, *dest + 1)
}
- 785 ：デフォルトの名無しさん：2024/02/14(水) 16:36:51.93 ID:b+wxXawK.net
- 質問している人間相手なら関係ないことを書いて良いわけではない
- 786 ：デフォルトの名無しさん：2024/02/14(水) 16:42:22.39 ID:3OoaoCBc.net
- >>784
結果的に役に立たないことがあってもしょうがないですが、関係ないことをアンカーで書くのは正当化できない迷惑行為です。
質問者 (特に初心者？) には迷惑をかけてよいと考えているのだとしたらそれは改めるべき悪です。
- 787 ：デフォルトの名無しさん：2024/02/14(水) 16:46:13.61 ID:L7EuZktb.net
- ついに存在しないCコードの幻覚が見えるようになってしまった複製おじさん……
- 788 ：デフォルトの名無しさん：2024/02/14(水) 16:46:26.67 ID:b+wxXawK.net
- 一方、質問文を誤読して解答してしまった人間に対して強く当たって良いわけでもない
- 789 ：デフォルトの名無しさん：2024/02/14(水) 16:51:03.66 ID:3OoaoCBc.net
- >>788
あれは誤読 (?) なんでしょうか。
茶化しているように受け取ったので腹立たしかったのですが、
そうだとしたら >>783 は言い過ぎですね。
ID:S2bQYQek さん、すいません
- 790 ：デフォルトの名無しさん：2024/02/14(水) 17:05:32.23 ID:ZK4bCcm/.net
- 人間の注意力読解力は実際この程度なので、人間にC++を扱うことは難しい
- 791 ：デフォルトの名無しさん：2024/02/14(水) 17:06:20.11 ID:Q08aEmFz.net
- だから境界知能なんでしょ
- 792 ：デフォルトの名無しさん：2024/02/14(水) 17:19:45.82 ID:qgmjNVo3.net
- 腹立てるのもわからなくはないがそんなにキレてレスするようなことではないだろ
気に入らなかったらスルーする程度には心に余裕を持っておこう
- 793 ：デフォルトの名無しさん：2024/02/14(水) 17:26:03.70 ID:h4S8S2sP.net
- tmuxよりscreen派だよ。
- 794 ：デフォルトの名無しさん：2024/02/14(水) 17:50:47.59 ID:6CXfQ6Kw.net
- 個人的には後置インクリメントだけを関数化するのは微妙に感じる
fetch_addとかは必要性を理解できるけど単純なpost_addやpost_incrementは一段階上の処理を関数化するので十分でそのほうが見通しがいいように思う
- 795 ：デフォルトの名無しさん：2024/02/14(水) 19:51:05.67 ID:7rKeAYke.net
- >>762
こういう偉そうなこと散々言ってたhaskellがなぜ流行らなかったのかすら理解できてないというのが愚かだよね。
- 796 ：デフォルトの名無しさん：2024/02/14(水) 19:57:21.78 ID:b46uhNiQ.net
- >>777
c++ template conceptも碌に知らないでダックタイピングをけなしているのか。なかなか……
ダックタイピングは契約の主体・時期・範囲が違うという話だかね。
- 797 ：デフォルトの名無しさん：2024/02/14(水) 20:14:14.28 ID:yh2p7tDo.net
- >>796
C++では機能の異なる同名メソッドを区別できないから欠陥品
- 798 ：デフォルトの名無しさん：2024/02/14(水) 20:52:10.35 ID:b46uhNiQ.net
- >>797
引数・戻り値で区別できるだろ。
- 799 ：デフォルトの名無しさん：2024/02/14(水) 21:01:37.45 ID:yh2p7tDo.net
- >>798
それに依存してしまうのがC++の限界
- 800 ：デフォルトの名無しさん：2024/02/14(水) 21:18:41.79 ID:b46uhNiQ.net
- >>799
名前も引数も戻り値も区別できないんだったら、ダックタイピングで呼び出す側はそもそも区別する必要あるんですかねぇ。
- 801 ：デフォルトの名無しさん：2024/02/14(水) 21:58:58.38 ID:H5X+9PTs.net
- >>796
それだとRustでいうところのトレイト境界を課すことができないな
つまりC++では安全に呼び出すことができない
呼び出したメソッド内で出来ること出来ないことが定まらないため
- 802 ：デフォルトの名無しさん：2024/02/14(水) 22:13:29.10 ID:uLd8jazY.net
- >>801
「呼び出したメソッド内で出来ること出来ないこと」
て何？
Rustのtraitて、副作用のコントロールできたっけ？
- 803 ：デフォルトの名無しさん：2024/02/14(水) 22:26:20.82 ID:8gvFvpJ5.net
- traitのprovided methodのdefault実装で呼び出せるのはrequired methodと
trait境界がある場合はそのtraitのmethod
そしてそれらで構成された他のprovided methodのみ
って制限をC++でどうするんだろ
- 804 ：デフォルトの名無しさん：2024/02/14(水) 23:19:42.33 ID:3OoaoCBc.net
- >>803
コンセプト。
- 805 ：デフォルトの名無しさん：2024/02/14(水) 23:20:56.22 ID:3OoaoCBc.net
- >>792
毎度毎度のことで余裕を削られた最後だったんだよ。
- 806 ：デフォルトの名無しさん：2024/02/15(木) 00:20:11.01 ID:AyUC+mx+.net
- 毎度毎度のことという認識を持っていながらなぜここに書き込むのか
- 807 ：デフォルトの名無しさん：2024/02/15(木) 00:23:07.31 ID:x2y7hFPc.net
- >>806
せやな。
けど日本で比較的活発な Rust コミュニティというとここなんよ。
- 808 ：デフォルトの名無しさん：2024/02/15(木) 07:06:08.60 ID:13EQhuxe.net
- >>804
concept記述が多すぎて書いててイヤになるな
普及しそうにない仕様がまたC++に増えた感じ
Rustが必要な機能を洗練して提供しているのと対照的
- 809 ：デフォルトの名無しさん：2024/02/15(木) 07:43:10.62 ID:j4EJcuA3.net
- >>808
洗練されすぎてて「早すぎる最適化」がバンバン起きるけどな。
枯れた既存プログラムの置き換え用途が無難なところかと。
コード破棄前提のプロトタイピングはコスト的にキツイか。問題領域の知識がほとんど無い開発初期で使えるのは未来を予測できる天才ぐらいだろ。
- 810 ：デフォルトの名無しさん：2024/02/15(木) 07:55:56.64 ID:hKdVOM0D.net
- >>809
Netflixの天才プログラマーが丸2年間Rustに全力費やして周りに吹聴した挙句に
RustやめてGoにする宣言してる
理由を真面目に話してるから一見の価値のあり
- 811 ：デフォルトの名無しさん：2024/02/15(木) 08:11:38.37 ID:j4EJcuA3.net
- >>810
検索したけど見つからなかった……
リンクある？
- 812 ：デフォルトの名無しさん：2024/02/15(木) 08:17:50.82 ID:Me0Wd39H.net
- [Why I Use Golang In 2024](https://www.youtube.com/watch?v=6gwF8mG3UUY)
- 813 ：デフォルトの名無しさん：2024/02/15(木) 08:19:40.94 ID:j4EJcuA3.net
- >>812
サンクス。
家帰ったら見るわ。
- 814 ：デフォルトの名無しさん：2024/02/15(木) 08:48:36.69 ID:UeUfm3Ct.net
- >>812
見た
ほとんどの話がプログラミング言語の比較よりももっと抽象的な話で中身が薄い
そして批判されてるのはなぜかTypeScrpt
Goについてはシンプルなのが好きでジェネリックが導入されてワクワク
Rustはifに括弧がないのたスネークケースが嫌いだけどGoもifに括弧がないよ
Rustの型システムはとても素晴らしいけど、
- 815 ：デフォルトの名無しさん：2024/02/15(木) 09:52:51.93 ID:x2y7hFPc.net
- >>808
過去のコードと矛盾しない形での後付けだからな。
C++ を根本から変えるような大革新なのに (ほとんど) 互換性を損なわないように出来ているという意味ではかなり気が利いた設計ではある。
簡単に互換性を切り捨てていると資産が蓄積されないし、かといって変わらないままでもいられないのは宿命というもんだよ。
Rust だって歴史が積み重なればいずれそうなる。
「綺麗なのは使われないもの」という格言を聞いたことないか？
Rust は C++ の歴史のグダグダから学んだ反省としてエディションという概念を導入したが、これがどれくらい上手く機能するかは現時点では未知数だ。
規格策定・処理系保守のリソースは無限なわけではないしな。
- 816 ：デフォルトの名無しさん：2024/02/15(木) 09:55:25.99 ID:LYiZEs3M.net
- エディションはすでに複数あるけど
あっても無理とか問題起きるとか
実例あるの？
- 817 ：デフォルトの名無しさん：2024/02/15(木) 10:07:56.04 ID:x2y7hFPc.net
- >>816
問題が抑えられているのは問題がないように保守されているからで、
その体制を「ずっと」続けられるものかどうかはずっと続けてみないとわからない。
今問題があるとかそういう話じゃないから未知数と述べてる。
- 818 ：デフォルトの名無しさん：2024/02/15(木) 10:11:47.35 ID:9MXGquuv.net
- C++は貧弱な家を土台に増築工事をしまくって部屋数は多いが使われていない部屋だらけ
C++プログラマーの多くが知らない部屋、見たことない部屋、たどり着けない部屋が多数あるまま、さらに増築工事が進んでいる
- 819 ：デフォルトの名無しさん：2024/02/15(木) 10:21:13.40 ID:qaCOVcST.net
- まあいうてもRustも将来的には増築されたバケモノになるか途中で破壊的変更的なものを入れるかするかの選択になるのでは
Cから呼べてCを呼べる限りはどの言語を使っても良いとする立場であれば今一番使いたい言語はRustではある
- 820 ：デフォルトの名無しさん：2024/02/15(木) 10:32:36.57 ID:LYiZEs3M.net
- >>817
今は良くても未来は何が起こるかわからない論法は
何にでも使えるから意味ある話とは思えないけど…
- 821 ：デフォルトの名無しさん：2024/02/15(木) 10:37:24.02 ID:x2y7hFPc.net
- 「出来る」ということを大前提として確信できて、
その上で「上手く出来る」ならより良いってのが産業的な考え方だ。
おおよその場合に上手く出来ても
ちょっとした想定外に直面したときに破綻するようでは使い物にならない。
現実の問題ってのは想定してないところから出てくるものだから
そういうことも乗り越えられることを証明するには
実績 (歴史) を重ねるしかしょうがないんだ。
C++ は上手くやったとは言えなくても、汚くても打てる手が有る道具として信頼を得た。
Rust は今の時点では実に使いやすいように見えるが、
本当の意味で現実の使用に耐えうるものなのかは現実に使い倒してみるまでわからない。
- 822 ：デフォルトの名無しさん：2024/02/15(木) 10:38:37.60 ID:TrooctNX.net
- 今の時点で使いやすければなんでもいいんだYO
- 823 ：デフォルトの名無しさん：2024/02/15(木) 10:45:22.07 ID:9MXGquuv.net
- C++コンパイラが諸問題を指摘してコンパイルエラーにしてくれる状況は来そうにない
これだけ増築工事を重ねてもまだ見込みが立たないまま
- 824 ：デフォルトの名無しさん：2024/02/15(木) 11:47:28.36 ID:olqTmpaN.net
- C++の知識は大いに再利用されているので現実世界の変化は小さい
想定外かもしれないのは変化の大きさではなく
現実世界を定義できないことだ
定義できるのは理論だけ
- 825 ：デフォルトの名無しさん：2024/02/15(木) 12:02:34.79 ID:oxTsPXaA.net
- >>821
今の想定が甘いとか具体的指摘なかったら
想定外の対処ができてないから駄目は無敵論法
- 826 ：デフォルトの名無しさん：2024/02/15(木) 14:40:35.94 ID:wvzNp0zm.net
- そりゃWeb系だとGoのほうが使いやすいに決まってるでしょ
パフォーマンスもスクリプト言語よりはめちゃくちゃ速いから十分
- 827 ：デフォルトの名無しさん：2024/02/15(木) 14:47:01.34 ID:z+RD4XEG.net
- サーバーサイドは群雄割拠時代よね
Rust、Go、Java/Kotlin、C#いっぱいある
- 828 ：デフォルトの名無しさん：2024/02/15(木) 16:20:13.71 ID:x2y7hFPc.net
- >>825
駄目とは言ってない。
駄目かどうかも「わからない」ことが産業的なハードルだよねって話なんだが、わからんかな。
- 829 ：デフォルトの名無しさん：2024/02/15(木) 16:46:19.25 ID:606b12LT.net
- >>828
あなたの話相手してもrustでも他言語でもいいけど
問題回避のためにこういう仕様や実装にすべきじゃないか
みたいな議論が成り立たないのでそちらがおよそ産業的じゃないね
- 830 ：デフォルトの名無しさん：2024/02/15(木) 16:50:52.01 ID:olqTmpaN.net
- すべてを疑っても産業だけは疑いようがないって話なら
想定内と想定外の境界がどの辺にあるのかはなんとなくわかる
- 831 ：デフォルトの名無しさん：2024/02/15(木) 17:21:54.77 ID:SzbBTI0k.net
- >>814
Rustは型〇ナニーで長時間バトルだったと言ってるぞw
>>812動画の人がいくら天才でも2年間かき回したのは頂けない
- 832 ：デフォルトの名無しさん：2024/02/15(木) 17:26:25.25 ID:BHoNDVf7.net
- Rustは非同期処理がC++より扱いやすいおかげでサーバー方面に進出したのは良い
さすがにフロントでRustは微妙そうだけど、このままどんどん多方面に普及してほしい
- 833 ：デフォルトの名無しさん：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
- 834 ：デフォルトの名無しさん：2024/02/15(木) 17:35:21.87 ID:eOw5Ad1t.net
- >>832 夢見てないで現実見ては？
https://active.nikkeibp.co.jp/atcl/act/19/00546/011500001/
- 835 ：デフォルトの名無しさん：2024/02/15(木) 17:41:41.98 ID:wvzNp0zm.net
- >>812
流し聞きしたけど複雑だとかしょーもない構文の好き嫌いみたいな話しかしてなくて草
- 836 ：デフォルトの名無しさん：2024/02/15(木) 17:53:07.04 ID:8jpdfcc8.net
- >>835
Rustインフルエンサーの成れの果てですなw
- 837 ：デフォルトの名無しさん：2024/02/15(木) 18:08:05.70 ID:uSGIT3N+.net
- >>834
せめて用途別のプログラミング順位を挙げてくれ
…単発に言っても無駄か😭
- 838 ：デフォルトの名無しさん：2024/02/15(木) 18:08:23.00 ID:giVh/goG.net
- Goは２年も続けられるだろうか
大分前に少し使ってみたけど例外投げずにResult（タプル）で返す言語設計を採用しながら
返されたResultを無視してもコンパイラが警告出さないからやめた
Cで戻り値のエラーをスルーする事案が多発したから後発言語で例外が作られたのに
↓を見て気持ち悪さを感じる人には向かない
file, err = os.Open(path) // ← fileと一緒にエラーの受け取りを強要される
os.Chdir(path) // ←エラーしか返さないから戻り値を無視して処理を継続できる
- 839 ：デフォルトの名無しさん：2024/02/15(木) 18:11:15.85 ID:x2y7hFPc.net
- >>829
情報が充分じゃない (から議論を始めることさえできない) ことが
リスクだという話をしているつもりなんだが、伝わってないのか？
どんな問題が起こるのか事前にわかれば苦労しないよ。
起きたことに対処し続けるしか仕方がないが
可能なら自分が対処する当事者にはなりたくない。
- 840 ：デフォルトの名無しさん：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
- 841 ：デフォルトの名無しさん：2024/02/15(木) 18:24:55.60 ID:x2y7hFPc.net
- >>838
悪いほうがよい (Worse is Better) 原則というものも知られている。
正しさと単純さを天秤にかけてどちらが良いかという点で Rust とは異なる重みづけをしたのが Go だと思う。
問題をコンパイラが検出できる設計はもちろんありがたいが、そのために持ち込む構造は人間が把握しやすいものだろうか。
正直言って Go が良いとは全然思わないが一貫した理念に基づく判断であって、不備でそうなってるわけではない。
- 842 ：デフォルトの名無しさん：2024/02/15(木) 18:31:33.80 ID:j4EJcuA3.net
- >>829 >>839
このあたりは設計の根深い問題で、「変化を抱擁する」を標語としたアジャイル開発とかインクリメンタル開発とかで色々議論されたな。
あんまり目立った成果は無かったような気もするけど、機能間の疎結合と可換性は重要な指摘だと思うわ。
- 843 ：デフォルトの名無しさん：2024/02/15(木) 18:34:16.56 ID:3rKktGL8.net
- >>817
これはごもっともな意見
50年後にRust 2072エディションがある状況で最新コンパイラが2015エディションをサポートし続けてるとは思えないからどこかでは切ることになる
それでもRustのモデルとC++のモデルとどちらのほうが相対的によさそうかという選択の問題
- 844 ：デフォルトの名無しさん：2024/02/15(木) 19:40:03.38 ID:TrooctNX.net
- 50年後にC++23はサポートされているのだろうか
というかC++は50年後もアップデートしているのだろうか
- 845 ：デフォルトの名無しさん：2024/02/15(木) 19:52:43.98 ID:flxKbqvK.net
- >>843
cargo fix --edition
のあるRustは至れり尽くせりだよ
- 846 ：デフォルトの名無しさん：2024/02/15(木) 20:00:49.77 ID:nijJOd3e.net
- >>844
既にC++17とC++20で以前導入の機能の削除が大量に行われている
- 847 ：デフォルトの名無しさん：2024/02/15(木) 20:11:12.94 ID:Zy70aZMD.net
- じゃあもうRustで良いじゃん
- 848 ：デフォルトの名無しさん：2024/02/15(木) 20:27:48.49 ID:Y7OgkdHD.net
- CになかったC++の機能は削除してもチューリング完全が保証される
逆に、削除したらチューリング完全ではない保証をするならミニマリズムがベター
- 849 ：デフォルトの名無しさん：2024/02/15(木) 22:27:00.96 ID:MX4y8Eg+.net
- >>840
Kotlinが上がってきてるのうれしい
Fortranも上がってるのはなぜだ
- 850 ：デフォルトの名無しさん：2024/02/15(木) 22:56:46.83 ID:x2y7hFPc.net
- C++ は欠陥報告という制度で過去の規格に遡って修正が加えられることがある。
たとえば C++11 発行当時の C++11 と今の C++11 は内容が異なるわけ。
基本的には過去の仕様に新機能を追加したりはしないが微妙な挙動の変なところを直すような保守は続いている。
実質的には Rust のエディションみたいなことにはなってるんだよなあ。
- 851 ：デフォルトの名無しさん：2024/02/15(木) 23:13:05.86 ID:17JkefKn.net
- llvmも実装はc++だし。
- 852 ：デフォルトの名無しさん：2024/02/15(木) 23:33:02.83 ID:CqGYBNeH.net
- >>850
Rustは必ずeditionを明示しないといけないから
あるソースコードがどのeditionなら確実に動くのか明確にわかる
そしてそのeditionを指定してコンパイルも通り実行もできる
しかしC++は当初のC++11に従いコンパイルできて動いていたものが
今はC++11の機能のいくつかは削除されてしまっているために
- 853 ：デフォルトの名無しさん：2024/02/15(木) 23:44:16.83 ID:x2y7hFPc.net
- >>852
C++11 は C++11 として存在し続けているので問題になってないという話をしてるんだが
- 854 ：デフォルトの名無しさん：2024/02/15(木) 23:57:58.06 ID:m2l7AKkd.net
- 一般人と同等の読解力を複オジに期待しないこと
- 855 ：デフォルトの名無しさん：2024/02/16(金) 01:17:00.51 ID:2uzjzXJf.net
- cppreference.comの下のほうにちょろっと書いてあるdefect reportってそういうことだったんだ
勉強になるわ〜
- 856 ：デフォルトの名無しさん：2024/02/16(金) 02:58:58.82 ID:T31Boec7.net
- >>853
名前が同じならなんでも良い…… ってこと！？
- 857 ：デフォルトの名無しさん：2024/02/16(金) 05:29:44.45 ID:VnZfCvN7.net
- >>856
「規格が同じなら」ということだよ。
c++11とかはあくまで規格なので各実装の準拠率とか注意するポイントはあるけど、メジャーな機能を保守的に使えばそれなりに互換性を維持できる。
- 858 ：デフォルトの名無しさん：2024/02/16(金) 06:06:29.14 ID:VMcEA5aE.net
- RustのEdition方式が優秀すぎる
新たな機能の規格で分けるのではなく
各Editionは後方互換性の変化で分けているため
過去に書かれたコードも必ず動く
- 859 ：デフォルトの名無しさん：2024/02/16(金) 08:50:06.12 ID:T31Boec7.net
- >>857
規格が同じといいつつ機能消してんだから同じなのは規格の名前だけじゃん
- 860 ：デフォルトの名無しさん：2024/02/16(金) 08:50:57.44 ID:T31Boec7.net
- 規格から機能ごと消えるんならよう
- 861 ：デフォルトの名無しさん：2024/02/16(金) 08:57:09.07 ID:MpEo3rxP.net
- >>859
消してないけど何いってんの？
- 862 ：デフォルトの名無しさん：2024/02/17(土) 07:36:35.11 ID:pKHDV/cx.net
- ID:T31Boec7
流石にこいつ日本語能力なさすぎだろ
ガイジかな？
- 863 ：デフォルトの名無しさん：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
早口なので大変だろうけどちょとした言葉の節々に情報があるからリスニングがんばれ
- 864 ：デフォルトの名無しさん：2024/02/17(土) 08:38:43.36 ID:P+bU7/QC.net
- >>863
copilotで要約して貰うのが時間も短縮できるのに無能だなw
- 865 ：デフォルトの名無しさん：2024/02/17(土) 11:31:52.42 ID:/wuPDCL7.net
- >>864
この天才同士のディスカッションを楽しめないなんて損してんね🥲
- 866 ：デフォルトの名無しさん：2024/02/17(土) 11:55:10.10 ID:wfN7KjH7.net
- Netflixの天才とかいうのが胡散臭くて信頼性がないんだけどどういう人なのよ。
- 867 ：デフォルトの名無しさん：2024/02/17(土) 12:54:06.77 ID:p6Fewl3N.net
- >>863
この人の英語聞き取りにくい
もうちょっとゆっくり喋って欲しい
中身うっすいのにさ
- 868 ：デフォルトの名無しさん：2024/02/17(土) 12:58:21.47 ID:p6Fewl3N.net
- >>862
普通に境界性知能ってやつでは？
この手のは全部そうだと思うようにしてる
- 869 ：デフォルトの名無しさん：2024/02/17(土) 17:40:44.30 ID:SxaDWram.net
- >>863
ベンチマーク試してみたところ以外はブログ記事のまんまなのでわざわざ動画で見なくてもいいなこれ
公式ブログに書くならもうちょっとちゃんとしたベンチマークやれよって感じ
見識を疑うレベル
- 870 ：デフォルトの名無しさん：2024/02/17(土) 18:56:01.48 ID:bc7xcSj4.net
- Netflixの天才がいかがでしたかブログレベルの動画を出すとは
- 871 ：デフォルトの名無しさん：2024/02/17(土) 19:01:49.62 ID:hd6B0gbf.net
- >>863
動画内の指摘が記事に反映されてMojoがRustの3倍速いじゃん!!
Mojoコンパイラ賢いな
- 872 ：デフォルトの名無しさん：2024/02/17(土) 19:07:25.89 ID:1+LtKHMi.net
- 以前からMojoがCより何倍も速い！とかやってるけど
ベンチ方法や条件などが何かおかしい
- 873 ：デフォルトの名無しさん：2024/02/17(土) 20:11:15.92 ID:lHr0QJnq.net
- SIMDが効くような恣意的なベンチだしな
- 874 ：デフォルトの名無しさん：2024/02/17(土) 21:00:37.77 ID:QWthdRCX.net
- でもデータを見てから断罪するのは俗っぽいから
データを見ないでロジハラするのがベター
- 875 ：デフォルトの名無しさん：2024/02/17(土) 21:16:16.12 ID:lHr0QJnq.net
- DynamicVectorは最適化でSIMD使うように最適化されるってだけだろ
あと末尾最適化する
くだらなすぎる
- 876 ：デフォルトの名無しさん：2024/02/17(土) 21:40:36.38 ID:WeOJL5ES.net
- え？ Rustって末尾最適化できんの？
- 877 ：デフォルトの名無しさん：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
- 878 ：デフォルトの名無しさん：2024/02/18(日) 09:43:13.97 ID:2fU6EVDD.net
- >>873,875
同じLLVM系なのにRustが3倍遅いのかよ!!
Mojoがコンパイラ賢いのかRustコンパイラが...
- 879 ：デフォルトの名無しさん：2024/02/18(日) 10:23:17.76 ID:8VIVYK48.net
- あれを見て本当にRustが遅いと思っちゃう層の人にRustは向いてない
- 880 ：デフォルトの名無しさん：2024/02/18(日) 10:24:13.10 ID:8VIVYK48.net
- ちなみにSIMD云々は本質じゃないよ
- 881 ：デフォルトの名無しさん：2024/02/18(日) 10:33:07.03 ID:diN1NxZN.net
- >>879が3倍速いRustコードを出すってよ
- 882 ：デフォルトの名無しさん：2024/02/18(日) 10:46:23.01 ID:fnRzA2e2.net
- これはGoの方が速いんじゃないか？
- 883 ：デフォルトの名無しさん：2024/02/18(日) 11:13:09.56 ID:NoFg1fuK.net
- GoはGCを伴う言語だから論外
MojoはC/C++/Rustより3倍速い
- 884 ：デフォルトの名無しさん：2024/02/18(日) 11:27:28.89 ID:YdXgtYKq.net
- >>878
同じLLVMといってもMLIRという数値計算に最適化されたIRを使ってるから速い
恣意的な例である
- 885 ：デフォルトの名無しさん：2024/02/18(日) 11:36:55.83 ID:a/PaZk8n.net
- そういえば昔Delphiがコンパイルの速さを売りにしてたの思い出した
なんか懐かしい
- 886 ：デフォルトの名無しさん：2024/02/18(日) 12:18:39.29 ID:Wi99yBdV.net
- 20年後にRustを懐かしむスレはここですか？
- 887 ：デフォルトの名無しさん：2024/02/18(日) 14:55:22.54 ID:LhS8zjp4.net
- 20年後には流石にもっと良い言語が登場して流行っていることを期待している
- 888 ：デフォルトの名無しさん：2024/02/18(日) 15:22:23.80 ID:L2mk1x1a.net
- >>885
アンダースヘルスバーグ天才だよな
ボーランドでDelphi作って
マイクロソフトでC#とTypeScript作って
- 889 ：デフォルトの名無しさん：2024/02/18(日) 15:34:23.48 ID:CKqOMEmo.net
- >>888
MAUIくん！病室に戻るんだ！
- 890 ：デフォルトの名無しさん：2024/02/19(月) 09:27:30.10 ID:JlpPRp2V.net
- >>888
俺は天才とは思わない
この人ってお手本となる言語があって
それをよりよくすることは得意な気がする
- 891 ：デフォルトの名無しさん：2024/02/19(月) 10:19:49.07 ID:j7eyydGe.net
- 普通の人が実務で使うような汎用プログラミング言語は
とびぬけた画期的なパラダイムで構成しても使い難いし、
ひとつひとつはどうということはない要素を上手く組み合わせる
バランス感覚が重要って感じはあるね。
天才的な閃きでどうにかするようなものではない。
- 892 ：デフォルトの名無しさん：2024/02/19(月) 11:58:45.15 ID:r1DaNm3S.net
- 既存のものをうまく組み合わせたりリーダーシップをとったりするのに天賦の才があったという意味なら天才かな
- 893 ：デフォルトの名無しさん：2024/02/19(月) 12:07:19.13 ID:BnjhEPJH.net
- 自分は何も出来ない無才なのによく言うわw
- 894 ：デフォルトの名無しさん：2024/02/19(月) 14:11:02.99 ID:JlpPRp2V.net
- C#→Javaのビミョーなところを直す
Delphi→Pascalのビミョーなところを直す
TypeScript→JSに型付け
- 895 ：デフォルトの名無しさん：2024/02/19(月) 14:41:59.29 ID:FfoO1n86.net
- Rustのビミョーなところを直して欲しい
- 896 ：デフォルトの名無しさん：2024/02/19(月) 15:33:58.75 ID:BnjhEPJH.net
- R#だすかー
- 897 ：デフォルトの名無しさん：2024/02/19(月) 16:37:49.01 ID:pyxz0P7h.net
- Turbo PascalやDelphiやVisual J++は彼か作ったと言えるがTypeScriptはHejlsbergが作ったわけじゃないからな
広報+コントリビューター+社外との政治的調整役
- 898 ：デフォルトの名無しさん：2024/02/19(月) 18:10:38.68 ID:VthC7yJG.net
- R#とか絶対統計処理用の言語じゃん
- 899 ：デフォルトの名無しさん：2024/02/19(月) 18:20:06.89 ID:BnjhEPJH.net
- そうだな
じゃあRustyNailって名前にするか
- 900 ：デフォルトの名無しさん：2024/02/19(月) 18:38:07.38 ID:j7eyydGe.net
- ビミョーなところをどうにかしたってどうせ別のビミョーなところが出てくるに決まってるんだよ。
だましだまし発展させて行き詰まったあたりでまた新しい何かが登場するのが世の中のサイクルというもんだ。
- 901 ：デフォルトの名無しさん：2024/02/19(月) 18:50:17.05 ID:JlpPRp2V.net
- 割とマジでヘルスバーグ動きますの可能性はある
Carbon、Go→Google
Rust→Mozilla
？→Microsoft
この流れは確かにある
- 902 ：デフォルトの名無しさん：2024/02/19(月) 20:05:38.11 ID:gidehIA9.net
- GoogleもMicrosoftもRust支持で
Carbonの公式FAQにはRustが使えるならRustが良いと明記されている
- 903 ：デフォルトの名無しさん：2024/02/19(月) 20:34:12.24 ID:VthC7yJG.net
- Rust支持というより、現状最良の選択肢がRustであると認めているだけでは
なのでもっと良い選択肢を作ることが出来たら嬉々として打ち出してくる可能性はあると思う
- 904 ：デフォルトの名無しさん：2024/02/19(月) 20:55:09.09 ID:WSW9DaUh.net
- 代替の芽が今ないから早くて十数年以上先
MojoはPythonベースで関心が数値計算に向いていて違う
- 905 ：デフォルトの名無しさん：2024/02/19(月) 20:57:44.38 ID:34j+4tJw.net
- Netflixの天才は2年かけて右端の住人になったのか
https://pbs.twimg.com/media/GDa2G6iWIAAsyh3.jpg:orig
これからは目立った実績が無いのにRust歴が長いと
型〇ナニーで時間溶かしてると認定される
- 906 ：デフォルトの名無しさん：2024/02/19(月) 21:23:20.71 ID:MW9zngaI.net
- >>905
Go？
Goはランタイムが大きくGCベースの言語だからRustの代わりにならんよ
- 907 ：デフォルトの名無しさん：2024/02/19(月) 21:38:55.37 ID:BnjhEPJH.net
- >>906
結局さ一周回ってAdaで良いんじゃ？
- 908 ：デフォルトの名無しさん：2024/02/19(月) 21:46:39.06 ID:VDl5KQ6V.net
- オーガスタちゃんが平伏せと命令する言語？
- 909 ：デフォルトの名無しさん：2024/02/19(月) 22:19:23.32 ID:hvnIqBoW.net
- Web用途だとRustはtokioと関連ライブラリが必須だからGoよりランタイム大きくなるけどね
- 910 ：デフォルトの名無しさん：2024/02/19(月) 22:41:42.37 ID:+OQMy10I.net
- >>909
Rustバイナリが小さい
tokio+hyper他で特別な指定もなく普通に作ったweb server実行バイナリがstrip後に1.3MB
- 911 ：デフォルトの名無しさん：2024/02/19(月) 23:17:36.45 ID:aeOZND98.net
- サーバーエンドでバイナリサイズなんてどうでもいいけど専有メモリ量がJavaやGoより小さいのはよい
- 912 ：デフォルトの名無しさん：2024/02/20(火) 03:09:16.36 ID:sgoVzbhC.net
- Rustってcargo buildとかやると通信量結構えげつない
- 913 ：デフォルトの名無しさん：2024/02/20(火) 08:39:03.07 ID:VuVDzPkr.net
- 依存関係があるライブラリをダウンロードすれば Rust に限らず
それなりにたいくさんひっついてくるのはよくあること。
- 914 ：デフォルトの名無しさん：2024/02/20(火) 08:51:21.95 ID:HobPlk1l.net
- C++でビルドする前にapt-getしてね、ってのも同じことだしな
- 915 ：デフォルトの名無しさん：2024/02/20(火) 09:54:42.94 ID:avQkuhyK.net
- Rustだと依存ライブラリの数が桁違いに多くなるのが原因
- 916 ：デフォルトの名無しさん：2024/02/20(火) 10:20:25.82 ID:VuVDzPkr.net
- お前それ、 JavaScript の前でも同じこと言えるの？
- 917 ：デフォルトの名無しさん：2024/02/20(火) 10:20:33.45 ID:kmanQ674.net
- >>903
その通り
Rustの次に期待
- 918 ：デフォルトの名無しさん：2024/02/20(火) 13:00:59.06 ID:MPPpoDC+.net
- >>907
ブロックが波カッコだったらなぁと思ったことある。
- 919 ：デフォルトの名無しさん：2024/02/20(火) 13:46:52.53 ID:sgoVzbhC.net
- 一回DLしたパッケージOSにキャッシュしてくれればいいんだけど
そうじゃないから学習でやってると無尽蔵に取りにいくのはなんとかならんのか
- 920 ：デフォルトの名無しさん：2024/02/20(火) 14:05:25.22 ID:VuVDzPkr.net
- >>919
えっ、普通にキャッシュしますが……。
- 921 ：デフォルトの名無しさん：2024/02/20(火) 14:18:44.11 ID:YaBXE8T+.net
- >>919
1回しかダウンロードしない
その後はそのキャッシュを用いる
- 922 ：デフォルトの名無しさん：2024/02/20(火) 14:47:39.06 ID:NZma60kC.net
- それよりディスク使いすぎだろ
ビルドの中間生成物が簡単にギガ単位になる
- 923 ：デフォルトの名無しさん：2024/02/20(火) 15:44:30.40 ID:s70xdtq8.net
- >>922
それな
複雑なコンパイラでインクリメンタルビルドを高速化するには空間性能を犠牲にするしかないんだろ
- 924 ：デフォルトの名無しさん：2024/02/20(火) 15:54:29.36 ID:VuVDzPkr.net
- 大きなライブラリは動的リンクすることにしてもいいけど、
そしたら実行環境の管理と開発環境の管理を分離しづらくて面倒くさくなる。
どうやったってどこかに負担はかかるならストレージさえあれば
だいたい解決ってほうがいいという戦略なんだろ。
- 925 ：デフォルトの名無しさん：2024/02/20(火) 18:32:02.94 ID:NZma60kC.net
- Rustほどディスク使う言語他にあるの？
桁違いに多いと思うんだが
- 926 ：デフォルトの名無しさん：2024/02/20(火) 18:32:44.23 ID:pzacWR0B.net
- ディスクはまあTB行かなければ何をやっても良いわ
- 927 ：デフォルトの名無しさん：2024/02/20(火) 18:46:34.01 ID:2x98KEBQ.net
- ビルドキャッシュの一部を何もしなくてもプロジェクト跨いで共有してくれればまだいいんだけどね
用途的に外部ストレージやNASに置くようなものじゃないというのが困るところ
- 928 ：デフォルトの名無しさん：2024/02/20(火) 18:56:04.80 ID:qhUDP5tY.net
- Rust (cargo)のソースダウンロードしてすべて同一マシンでビルドする前提の設計はいいと思う。
soとかdllとかjarみたいなの、あまり信頼したくないというか。
- 929 ：デフォルトの名無しさん：2024/02/20(火) 19:01:23.73 ID:aUCxPGU2.net
- Crates.ioを信頼してどうせ落ちてきたもの毎回ソース全行確認したりはしないんだから、落ちてくるものがバイナリになっても別に良いかな
- 930 ：デフォルトの名無しさん：2024/02/20(火) 19:12:55.50 ID:HobPlk1l.net
- so使ってsymbol not foundとかよくあるしな
基本的にC++ソフトのビルドは作者が使ってるディストリでしか再現しないと思ったほうがいいくらい
しょうがないからDockerでビルド環境作ったりするけど面倒だしディスクも食うし
結局ディスクキャッシュが多少多いくらいで済んでるRustが一番マシな気がする
- 931 ：デフォルトの名無しさん：2024/02/20(火) 19:56:43.04 ID:hRyg00SZ.net
- soが悪いのではなくまともなパッケージマネージャーもまともな依存解決ツールもないのが悪い
- 932 ：デフォルトの名無しさん：2024/02/20(火) 20:07:01.59 ID:+of8n4/M.net
- 確かにOS非依存のC++標準パッケージマネージャと中央レジストリがあれば良かったかもね
ただその場合でもABIが不安定なのはどうしょうもないから
Rustと同じく手元で全部コンパイルする方式になったと思うけど
- 933 ：デフォルトの名無しさん：2024/02/20(火) 20:11:30.03 ID:VuVDzPkr.net
- Cargo 風の管理をする C++ 用パッケージマネージャはある。
最初からそのパッケージマネージャ用に構成してくれてないと
なかなか素直にはビルドできないことに変わりないんだけど。
パッケージマネージャが優秀でも C++ 世界では
「統一されていない」ことが面倒くささになってる。
- 934 ：デフォルトの名無しさん：2024/02/20(火) 21:39:15.46 ID:1smOJz8O.net
- そう考えると中間言語形式で配布できてAOTコンパイルもできる.NETがさいつよって話？
- 935 ：デフォルトの名無しさん：2024/02/20(火) 21:43:07.30 ID:BYbBGAeA.net
- NuGetが使いやすいと感じた事がないし、充実していると感じたこともない
- 936 ：デフォルトの名無しさん：2024/02/20(火) 21:59:58.18 ID:VuVDzPkr.net
- >>934
dotNET は事前コンパイルしてもランタイムサポートの分厚さ (にかかる実行コスト) は避けられないので
コンピュータの性能を絞りきるようなつよつよ最適化は無理じゃないかなぁ。
いろんな方式の良いところを上手く取り入れて総合的には良いものに仕上がってるとは思うけど
それが最強かというと状況によるんじゃないの。
- 937 ：デフォルトの名無しさん：2024/02/20(火) 22:14:04.42 ID:sgoVzbhC.net
- >>921
チャプターサンプル毎にプロジェクト作ったら毎回DLしてるように見えるけど
- 938 ：デフォルトの名無しさん：2024/02/20(火) 22:16:27.29 ID:FbkkUU+G.net
- パッケージの使い勝手という意味ではdocs.rsの存在も大きい気がするな
どんな野良ライブラリでも決まった場所に決まったフォーマットのAPI一覧が確実に存在するというのはかなり便利
- 939 ：デフォルトの名無しさん：2024/02/20(火) 22:30:04.17 ID:VuVDzPkr.net
- ドキュメントを全く書かなくても少なくとも公開されている一覧はわかるってのは強い。
最悪の場合でもコードへのリンクもあるし。
Haskell のリポジトリがこういう感じだったので他の言語でもこれくらいやればいいのにと思ってたから
Rust で取り入れてくれたのはかなり嬉しい。
- 940 ：デフォルトの名無しさん：2024/02/20(火) 22:37:39.60 ID:NZma60kC.net
- >>926
いや、スマホでセルフ開発する時に困るだろ？
- 941 ：デフォルトの名無しさん：2024/02/20(火) 22:45:53.34 ID:VuVDzPkr.net
- >>940
そんなやつはおらんで〜〜
- 942 ：デフォルトの名無しさん：2024/02/20(火) 22:47:07.61 ID:1CgxDriU.net
- ス、スマホ？
- 943 ：デフォルトの名無しさん：2024/02/20(火) 23:05:21.55 ID:YDnp1LJs.net
- procマクロとかコンパイル環境で展開したいものを除くとtarget指定した環境に依存するだけだから手元でコンパイルする必要性は全くない
いずれにしろどこでビルドするかと中間生成物のサイズが異常にデカくなる話とは別の話だよね
- 944 ：デフォルトの名無しさん：2024/02/20(火) 23:07:55.15 ID:VuVDzPkr.net
- もしスマホで開発する人がいたとしても
レンタルサーバに接続して表面上の操作にスマホを使うだけで、
実質的なストレージ・計算リソースはサーバのものを使う形にするのが普通。
スマホ内で完結させようとしたらツールチェインをセットアップするだけでもクソ面倒くさい話になるぞ。
- 945 ：デフォルトの名無しさん：2024/02/21(水) 00:35:56.53 ID:ax8uXPdD.net
- 働いてないとスマホで開発するとかいう前代未聞の人間がいるんだな
- 946 ：デフォルトの名無しさん：2024/02/21(水) 01:44:30.82 ID:q3i686zw.net
- スマホで開発はむしろ最先端
- 947 ：デフォルトの名無しさん：2024/02/21(水) 05:17:16.65 ID:cGlapTzK.net
- iPhoneが出たばかりの頃から、脱獄して開発環境を入れてObjective-Cでプログラミングしてる人は一定数居ただろ。
最近では、どのプログラミング言語でも使えてLinux（Android）と遜色ないよ。
今のスマホは、外部モニターも外部SSDも繋げるし、外部グラボのGPUでLLM開発だってできる。ほぼほぼRaspberryPi5と変わらないよ。
だからこそ組み込みにも強いRustが注目されてるんｼﾞｬﾏｲｶ
- 948 ：デフォルトの名無しさん：2024/02/21(水) 05:44:41.84 ID:cGlapTzK.net
- スマホでRustformersからLLM開発する場合、ローカルにOllama入れとくか、サーバにGPT-4やLlama2を入れとくかぐらいの違いしかない。
Google Coralもスマホでも使える前提の製品で、このチップは発熱量が減ればスマホに内蔵されるだろう。
実際、Vision Transformerのような技術を応用しているApple Vision Proが製品化されたから、スマホからこういった機器に移行するのかもしれない。
今後数年間、これらの技術動向から目が離せない状況が続くんだろう。
- 949 ：デフォルトの名無しさん：2024/02/21(水) 08:28:43.22 ID:/iiJfWDN.net
- ダウンロードしたクレートキャッシュの自動削除はもうすぐ来そう
ビルドキャッシュの自動削除はその後実装予定っぽい
https://blog.rust-lang.org/2023/12/11/cargo-cache-cleaning.html
- 950 ：デフォルトの名無しさん：2024/02/21(水) 08:31:36.21 ID:/iiJfWDN.net
- グローバルなビルドキャッシュ共有の話も予定には挙がってるね
- 951 ：デフォルトの名無しさん：2024/02/21(水) 09:05:07.84 ID:33Eh81yS.net
- >>934
何を基準でさいつよかの定義による
デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC#だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC#使えれば何でも作れるという意味ではさいつよ
- 952 ：デフォルトの名無しさん：2024/02/21(水) 09:19:16.71 ID:VUY6mIOu.net
- >>951
.netの毎年の長文blog最適化レポートを見ると2年後くらいでNativeAOT最適化がC/C++に肉薄すると思う
- 953 ：デフォルトの名無しさん：2024/02/21(水) 10:25:34.81 ID:ygn/feiE.net
- デスクトップ
Web
バックエンド
iOS/Android
ゲーム
とC言語だけで全部作れる
各分野でベストな選択肢では無いけど平均点以上のベターではある
とりあえずC言語使えれば何でも作れるという意味ではさいつよ
チューリング完全なので
- 954 ：デフォルトの名無しさん：2024/02/21(水) 10:33:55.14 ID:3B94ePzU.net
- 無能なやつほどゴールデンハンマー症候群に罹患しやすい
- 955 ：デフォルトの名無しさん：2024/02/21(水) 10:37:42.60 ID:33Eh81yS.net
- >>953
嘘ばっかりだなw
- 956 ：デフォルトの名無しさん：2024/02/21(水) 12:23:52.50 ID:FRHKNAr+.net
- >>949
さすがに問題として認識はしてたんだな
スマホセルフ開発の日は近い
- 957 ：デフォルトの名無しさん：2024/02/21(水) 12:50:43.67 ID:ax8uXPdD.net
- マジでスマホしか持ってないの？
クソワロタ
- 958 ：デフォルトの名無しさん：2024/02/21(水) 13:41:48.13 ID:s/93fWsg.net
- ウェアラブル系の機器には失望した。
どこへでも持っていけるよりどこへも往く必要のないインフラこそ目指すべき未来だろ。
- 959 ：デフォルトの名無しさん：2024/02/21(水) 14:32:00.13 ID:T2E+AzfY.net
- >>954
同意
- 960 ：デフォルトの名無しさん：2024/02/21(水) 15:10:22.61 ID:KvtS9dqN.net
- >>958
背もたれ付きベッド
- 961 ：デフォルトの名無しさん：2024/02/21(水) 15:11:12.28 ID:KvtS9dqN.net
- >>953
Rustはチューリング安全だぞ
- 962 ：デフォルトの名無しさん：2024/02/21(水) 16:06:34.40 ID:RjxZ1GsP.net
- >>957
働いてないと「スマホで開発==スマホしか持ってない」という発想になるんだなww
- 963 ：デフォルトの名無しさん：2024/02/21(水) 16:15:10.41 ID:cGlapTzK.net
- >>960
ベッドといえばフランスベッドが取り扱ってるAI 視覚支援機器『オーカム マイアイ2』(OrCam MyEye 2)は、
イスラエルのオーカムテクノロジーズ（OrCam Technologies Ltd）の製品だったな。
これは活字の読み上げみたいだけど、寝具メーカーは、どこへも往く必要のない未来インフラをAI使って目指してるんだろう。
ウェアラブル系が狩猟型・動物型とすれば、寝具系は農耕型・植物型なんだろうな。人間は生活の約３割は寝てるんだから当然だけど。
- 964 ：デフォルトの名無しさん：2024/02/21(水) 16:30:25.40 ID:vYwp44u6.net
- 表向きはどうであれたぶん寝たきり用だから話を膨らませるのはそのくらいにしとけ
- 965 ：デフォルトの名無しさん：2024/02/21(水) 16:47:28.48 ID:OHlXXLmE.net
- いくらなんでもスマホでコーデングはせんやろ
- 966 ：デフォルトの名無しさん：2024/02/21(水) 16:49:23.05 ID:1mshJDzd.net
- 寝たきりで親指しか動かないとかならスマホでコーディングするかもしれん
- 967 ：デフォルトの名無しさん：2024/02/21(水) 16:54:05.86 ID:s/93fWsg.net
- 性能がどうこうよりもシンプルに画面が狭いのはすごくつらい。
無理。
- 968 ：デフォルトの名無しさん：2024/02/21(水) 18:17:59.27 ID:ax8uXPdD.net
- >>962
いやお前に当てはめてるだけだぞ
何言ってんだ？
- 969 ：デフォルトの名無しさん：2024/02/21(水) 21:37:40.46 ID:4F0o6gVI.net
- はちみつ餃子氏最近見ないからRust関連は触れないことにしたのかと思ったらコテ外して書き込みに来ててわろた
- 970 ：デフォルトの名無しさん：2024/02/22(木) 16:00:18.09 ID:o0M/RgFs.net
- >>969
新スレ立ったときに名前欄に入力するのを忘れてたままやな
- 971 ：デフォルトの名無しさん：2024/02/22(木) 23:42:55.14 ID:1e40BABA.net
- >>949
毎晩ならその機能もう使えるのか
- 972 ：デフォルトの名無しさん：2024/02/23(金) 12:05:46.18 ID:vPqrWVzU.net
- 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうが。
- 973 ：デフォルトの名無しさん：2024/02/23(金) 12:05:51.79 ID:vPqrWVzU.net
- 今のスマホって値段はPC並みなんだから、スマホでの開発環境出てこいと思わなくも無い。
もちろんその場合は外付けのディスプレイとキーボードつけるだろうけど。
- 974 ：デフォルトの名無しさん：2024/02/23(金) 15:12:44.34 ID:z6SHyxko.net
- iPadでXcode使えるからそれで遊んでみれば
- 975 ：デフォルトの名無しさん：2024/02/23(金) 15:20:09.67 ID:CheDQupm.net
- Rustが使えないとな
- 976 ：デフォルトの名無しさん：2024/02/23(金) 15:21:05.22 ID:jTrUecQ5.net
- クソスレまで立てちゃってw
素直に中古のノートPCでも買えよ
- 977 ：デフォルトの名無しさん：2024/02/23(金) 16:04:17.89 ID:02Kw336h.net
- traitの種類多すぎて把握しきれん
使い分けもようわからんし
- 978 ：デフォルトの名無しさん：2024/02/23(金) 16:18:25.67 ID:NJWNbZ5N.net
- Pythonのpep20みたいなってRustにもあるの？
- 979 ：デフォルトの名無しさん：2024/02/23(金) 16:32:06.33 ID:eHVJk53E.net
- スマホやタブレットなどのモバイルOS上に開発環境用意するのは主に2つユースケースがある
1つはモバイルOS上で実行させる小さなユーティリティを作るため
だいたいlinux emulatorみたいなアプリ内環境で稼働させる
もう一つは出先の空いた時間や障害対応等の緊急時にノートPCを持ち歩かなくても簡易的な作業なら対応できるようにしておくため
前者はスマホだけで作るやつもいるにはいるが少数派
なので今のところはメイン開発環境は別に用意してるのが大半
- 980 ：デフォルトの名無しさん：2024/02/23(金) 17:15:31.94 ID:kgcjkDLJ.net
- PEP20って何だよと思ったらあのウンコポエムだった
- 981 ：デフォルトの名無しさん：2024/02/23(金) 17:26:44.63 ID:kgcjkDLJ.net
- 次スレタイトル間違えてしまったのですまんが誰か立て直してくれ
規制食らってもう立てられなくなった
- 982 ：デフォルトの名無しさん：2024/02/23(金) 17:35:21.56 ID:CheDQupm.net
- >>977
traitとは機能を抽象化した抽象型だから使いたい機能のtraitを選ぶか作ればよい
structなどの具象型は各々必要な各機能(trait)を実装しているもしくは実装すればよい
そして抽象型(trait)を用いてプログラミングすることでその機能を実装する全ての具象型を対象とした共通コードにできる
- 983 ：デフォルトの名無しさん：2024/02/23(金) 17:38:39.47 ID:CheDQupm.net
- 次スレ
Rust part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/
- 984 ：デフォルトの名無しさん：2024/02/23(金) 17:45:54.27 ID:kgcjkDLJ.net
- >>983
ありがとう
- 985 ：デフォルトの名無しさん：2024/02/23(金) 17:51:32.20 ID:jYYzpIEX.net
- >>978
こういうのをまとめようとはしているよ
https://smallcultfollowing.com/babysteps/blog/2023/12/07/rust-design-axioms/
- 986 ：デフォルトの名無しさん：2024/02/23(金) 20:10:18.94 ID:1IK2X2kO.net
- >>982
FromとかAsRefとかDerefとかの時点でもうようわからんぜ
- 987 ：デフォルトの名無しさん：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
など
- 988 ：デフォルトの名無しさん：2024/02/23(金) 23:50:59.87 ID:1IK2X2kO.net
- あー。それぞれの比較はまあそうなのかもしれないんだけど、そもそもどういうtraitがあってどういう時に使うべきなのかを全て把握できてないせいで実際にコード書く時にどれを使うとRustらしいコードになるのかわからなくなるってのがしんどいんだよね
- 989 ：デフォルトの名無しさん：2024/02/23(金) 23:59:41.76 ID:hX/YHnPg.net
- >>988
どの分野のどんな話でも基本パターンの学習による慣れ
問題
match std::env::args().XXXXX {
Some("yes") => ...,
Some("no") => ...,
_ => ..., // エラー
}
- 990 ：デフォルトの名無しさん：2024/02/24(土) 02:12:39.95 ID:YQ3M0cmx.net
- 梅
- 991 ：デフォルトの名無しさん：2024/02/24(土) 04:00:00.27 ID:felFEjYK.net
- 「当然こういうのが標準ライブラリにあって然るべきだろう」みたいな感覚ができるから結局は慣れ。
常識的に考えてあるだろうと思ったら nightly だったみたいなこともよく経験するから俺が欲しいようなものはみんな欲しいんだなと思う。
実質的に言語の一部みたいなくらいのやつは嫌でも避けられないから何度もドキュメントを読み返すはめになるし、そのうち自然に使えるようになる。
- 992 ：デフォルトの名無しさん：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の役割ではない
- 993 ：デフォルトの名無しさん：2024/02/24(土) 12:57:43.72 ID:Sbx59RJL.net
- AsRefとBorrowは未だにわからんなあ
調べてもHashMapがBorrow要求するならそこだけBorrow使っておけばいいか……で思考停止してる
- 994 ：デフォルトの名無しさん：2024/02/24(土) 13:58:08.04 ID:Q2pRspv0.net
- 埋
- 995 ：デフォルトの名無しさん：2024/02/24(土) 13:58:23.94 ID:Q2pRspv0.net
- 生め
- 996 ：デフォルトの名無しさん：2024/02/24(土) 13:58:40.99 ID:Q2pRspv0.net
- 、埋め
- 997 ：デフォルトの名無しさん：2024/02/24(土) 13:58:46.56 ID:Q2pRspv0.net
- ！埋め
- 998 ：デフォルトの名無しさん：2024/02/24(土) 13:58:52.17 ID:Q2pRspv0.net
- ？埋め
- 999 ：デフォルトの名無しさん：2024/02/24(土) 13:59:00.55 ID:Q2pRspv0.net
- ○埋め
- 1000 ：デフォルトの名無しさん：2024/02/24(土) 13:59:07.65 ID:Q2pRspv0.net
- 〜埋め
- 1001 ：2ch.net投稿限界：Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1001
259 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★