Rust part23

1 名前：デフォルトの名無しさん [2024/02/23(金) 17:37:52.13 ID:CheDQupm.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 part22 https://mevius.5ch.net/test/read.cgi/tech/1705760500/ ﾜｯﾁｮｲスレ プログラミング言語 Rust 4【ﾜｯﾁｮｲ】 https://mevius.2ch.net/test/read.cgi/tech/1514107621/ 331 名前：デフォルトの名無しさん [2024/03/17(日) 19:33:58.02 ID:1VtyMVPz.net] Rust書けるやつ集めるの大変すぎ 332 名前：デフォルトの名無しさん mailto:sage [2024/03/17(日) 22:06:35.75 ID:BMZldfUE.net] Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな ただしまともなプログラマーしか使い　　こなせない 333 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 09:59:50.17 ID:ySp1yGcK.net] むしろ変なやつしか使ってない感じだけど… 334 名前：デフォルトの名無しさん [2024/03/18(月) 10:20:48.83 ID:JObkxwF0.net] しょーもないこだわり持ってるやつしか使ってない 335 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 13:49:12.09 ID:lCCxn1Q7.net] 今後の仕事考えたらRustだね 336 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:26:36.03 ID:1+ObkRXf.net] メモリ安全性ってなんなの？ 337 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 14:49:59.91 ID:RRSB5dTk.net] 無効なアドレスを参照しない 運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる 無効なアドレスを更新しない 運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる メモリリークは割とどうでもいい 338 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:00:45.39 ID:ZJ4hMg34.net] >>330 メモリ安全性のうち特に重要な一つがメモリ競合の安全性 まだ使っている値を意図せずに書き換えてしまい矛盾してしまう プログラミングで起こるバグの代表的な一つ Rustではこれを防ぐことができる 339 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:02:35.53 ID:1+ObkRXf.net] >>331 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました…… 340 名前：デフォルトの名無しさん mailto:sage [2024/03/18(月) 15:07:28.37 ID:1+ObkRXf.net] >>332 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね… 341 名前：デフォルトの名無しさん [2024/03/18(月) 18:35:36.34 ID:utey1W8X.net] セルフコントならもう少し面白いやつを頼む 342 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 01:19:02.24 ID:6E76csi8.net] WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。 ttps://www.security-next.com/154875 343 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 05:37:59.51 ID:wTR4SIFK.net] デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。 2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。 パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。 344 名前：デフォルトの名無しさん [2024/03/20(水) 12:50:32.15 ID:/slJg93x.net] >>336 そういうのRust関係ないからわざわざここに書かなくてもいいよ 345 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:00:27.22 ID:3fTCja3E.net] 関係無いわけないでしょｗ rustで書かれてたら安全なんじゃなかったん？ｗ 346 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 13:48:07.28 ID:i9d3tzeg.net] ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ 347 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 14:22:40.25 ID:HLjoI2yW.net] これは「メモリ安全」の外の話？中の話？ 348 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 16:11:18.74 ID:sC/F3tDJ.net] unsafe使用箇所だからメモリ安全の外だろうな インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない 349 名前：デフォルトの名無しさん mailto:sage釣 [2024/03/20(水) 16:33:56.60 ID:pz7pPV/0.net] jsonの方も？ 350 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 17:50:49.65 ID:w9jt/Hdz.net] コード見てみたが言語関係なくダメな書き方の見本ってだけだな ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163 修正コードは毎回境界チェックしてるのと同じ extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない 351 名前：デフォルトの名無しさん [2024/03/20(水) 18:13:46.74 ID:ASk8Mk2n.net] extendという名前も実体と違ってバクの素 352 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:19:15.64 ID:sC/F3tDJ.net] 修正コードはhotfixでしょ masterブランチの方は結構手が入ってると思う 353 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 18:27:22.61 ID:ihbrcjwp.net] その知識やスキルを活かして出世して欲しい 354 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:04:41.25 ID:TrbgWl+Z.net] ダメな書き方でもコンパイルが通れば安全なはずなのではｗ 355 名前：デフォルトの名無しさん mailto:sage [2024/03/20(水) 20:32:22.01 ID:sC/F3tDJ.net] んなこたない ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる 356 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:05:26.83 ID:CBfowBe/.net] 直接の原因はunsafeなメソッドをsafeメソッドにしたこと unsafeのsafe wrapperの質は大事 今のコードもunsafeの使い方が怪しくて信頼できない fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue { debug_assert!(index < self.capacity()); // Safety: This is safe since all wasmi bytecode has been validated // during translation and therefore cannot result in out of // bounds accesses. unsafe { self.entries.get_unchecked_mut(index) } } 357 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 01:39:19.40 ID:t5wrhqh7.net] >>350 俺んとこもそのコードはよく書くけれど 今回の敗因は引数のindexが生のusizeであること そこをusize直接ではなくそのラッピングの専用型にする そしてその専用型が動く範囲が必ず範囲内であることを保証する形で get_uncheckefのunsafeを使う関数をsafeに仕上げる 358 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:05:54.93 ID:QWnK+qvS.net] unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？ 359 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 19:57:12.18 ID:7RDAu5V5.net] 全然そういう事 Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい 360 名前：デフォルトの名無しさん [2024/03/21(木) 20:09:58.67 ID:gM/gTjZ5.net] >>353 それ言うなら 無闇に「ヤバい」を使うぐらいヤバい じゃね 361 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:26:53.11 ID:1l7zk65j.net] 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな ガンガンunsafe使ってこーぜ！！ 362 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:28:39.30 ID:7RDAu5V5.net] >>354 それだと単なる自己言及だから352に対する答えとして不十分では 363 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 20:45:04.06 ID:t5wrhqh7.net] 少なくとも>>350のindex: usizeは 何らかラッピング { index: usize }と別型にすべきところ まず範囲外のusizeでうっかり使っても型エラーにできる そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる 364 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:05:14.02 ID:7RDAu5V5.net] NonZeroとかNonNullみたいな固定条件ならいいけど 範囲みたいな可変条件だと型だけじゃ厳しいでしょ 別の条件で作られた同じ型の値を使われるかもしれないし ライフタイム 365 名前：で条件と関連付けるのも限界がある 結局テストパターン増やしてdebug_assert踏むしかない [] [ここ壊れてます] 366 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 21:44:37.76 ID:t5wrhqh7.net] >>358 もちろん二段階 まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける 次にコーディングやレビューやメンテでその専用型の動きに注視できる 367 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:18:44.86 ID:cOunjWn7.net] unsafeをsafeでないのにsafeにしておいて ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです 368 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 22:27:42.27 ID:WuGieKPN.net] 結局プログラマが色々意識してコーディングしないと安全にはならないのね こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど 369 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:07:15.31 ID:7RDAu5V5.net] unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる 実際は安全の為でもpanicで止まると困るから色々注意しないといけないし unsafeで余計なチェック省いたり黒魔術使ったりもする Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない 370 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:12:07.53 ID:v/mpoJJ8.net] >>361 unsafeを使わなれば自動的に安全が保証される unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない 371 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:22:25.34 ID:WuGieKPN.net] いつもの人がきたｗ 結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど 372 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:58:23.31 ID:z414Bs3I.net] > Rustであれば安全と思ってる人が多そう いや一応言っとくけど多くはないよ流石にｗ 一部の人が連呼してるだけ ほかの人はもっと現実的だろな 373 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:21.08 ID:t5wrhqh7.net] 原則はunsafeを使うな！ これだけだ 理解できていてunsafeを使う場合も とにかく閉じ込めろ！ 専用のクレートを作れ 専用のモジュールを作れ 専用の型を作れ 374 名前：デフォルトの名無しさん mailto:sage [2024/03/21(木) 23:59:51.15 ID:XJ9dJAV6.net] unsafe使わなければ安全 375 名前：デフォルトの名無しさん [2024/03/22(金) 09:16:28.77 ID:IQ7X1X+j.net] まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。 それは意識して気をつけた方がいい。 376 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 10:19:34.77 ID:avPqaarP.net] ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。 チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。 そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ…… 普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。 377 名前：デフォルトの名無しさん [2024/03/22(金) 11:58:26.79 ID:7Rs7masV.net] >>358 0〜127の範囲のみを取りうるようなEnumなら作れる wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本 それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない >>359のやり方はそれができてないように感じる 378 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 12:34:01.41 ID:TbCMvv+/.net] 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい そうすればその型に対して常に安全にget_uncheckedを使える 379 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:04:42.65 ID:ZrfX32kv.net] Rustは失敗言語 380 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 14:10:55.04 ID:ceR9yHkM.net] 今回の件でRustの安全性が確実になったのが興味深いよな アンチが必死に探してきた問題も>>350でunsafe利用だった 381 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 16:00:31.63 ID:JqYXTM4B.net] >>371 「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど 実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ unsafeにする意味がない 382 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 17:14:19.13 ID:vuLWDWdh.net] >>374 実行時コストをかけないためにget_uncheckedを使うのが一般的 その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法) 383 名前：デフォルトの名無しさん [2024/03/22(金) 19:27:28.32 ID:G6tKD1fj.net] Adaなら特定の範囲の型作れるみたいよ 384 名前：デフォルトの名無しさん mailto:sage [2024/03/22(金) 20:07:18.97 ID:vuLWDWdh.net] 今回は範囲が固定ではなく変わり得る 385 名前：デフォルトの名無しさん mailto:sage [2024/03/23(土) 23:29:45.64 ID:eeq00BcS.net] 誰にでもunsafeが使えてしまうのが問題なのでは？ 原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。 386 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 00:34:36.37 ID:iaJ2USO3.net] Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。 387 名前：デフォルトの名無しさん [2024/03/24(日) 10:55:06.56 ID:UXqlkypu.net] >>375 「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350の引数のindexをその型に変えたところでsafeにしたらダメだよ 388 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 11:08:34.82 ID:BHU0SFkf.net] なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？ 389 名前：デフォルトの名無しさん [2024/03/24(日) 11:48:11.45 ID:uu8/yG2s.net] indexの境界チェックが律速になるようなコード書いてみてえな 390 名前：デフォルトの名無しさん mailto:sage [2024/03/24(日) 20:37:14.59 ID:YsO86RjG.net] >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。 391 名前：デフォルトの名無しさん [2024/03/24(日) 20:45:58.90 ID:Rrl8qRWO.net] >>383 定数じゃなければ結局実行時にチェックするってことだよね 392 名前：デフォルトの名無しさん [2024/03/25(月) 01:12:47.74 ID:yMlw6u5B.net] >>384 新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。 393 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 07:21:41.59 ID:CNajD+3j.net] >>384 何十年も前なのですまそ array(-2)とかarray(6)をアクセスしたら例外発生　array(-1)はOK type Month is range 1..12 type Month_Array is array(Month) of Integer; ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12); for m in ma'first..ma'last loop // カウンタは1から12 ma(m) = m; end loop; 394 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 14:37:28.19 ID:x/lXcXel.net] 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね 395 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 16:23:44.40 ID:9GDk/VLW.net] How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/ 396 名前：デフォルトの名無しさん [2024/03/25(月) 17:27:16.04 ID:MT/jL+52.net] こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 問題は浮動小数の取り扱いだっての。 397 名前：デフォルトの名無しさん mailto:sage [2024/03/25(月) 21:23:48.62 ID:x/lXcXel.net] unsafeは可能な限り避けるべきで safe Rustでの改善をまずすべき その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える 現実にはsafe Rustでの改善ができてないことが多い 例えばよく見かける例としては iが動いていくのにa[i]でアクセスしてしまう これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern 参照(ポインタ)化することで範囲checkを1回に減らせる 398 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 15:06:55.14 ID:g9hYSxJr.net] unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事 399 名前：デフォルトの名無しさん [2024/03/27(水) 15:29:03.70 ID:pFQTMi8v.net] 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので 400 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:02:47.08 ID:BwG0n/Az.net] unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？ 401 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 16:59:36.71 ID:LwoOYerE.net] >>393 そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。 402 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:05:39.09 ID:6Vj8sISV.net] >>392 センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ 今はそれが全然できてないから>>350のような基本的なミスを犯すやつが後を絶たない 403 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 17:08:09.55 ID:6japDZ8y.net] windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。 404 名前：デフォルトの名無しさん [2024/03/27(水) 18:09:17.85 ID:345wycOn.net] >>395 ～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。 405 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 18:27:03.05 ID:3NgGdhlw.net] >>397 問題点の指摘や解決策の提案と 問題解決のために実際に誰が動くのかという 2つの異なるものを混同したらだめだよ マネジメント101 406 名前：デフォルトの名無しさん [2024/03/27(水) 18:54:43.86 ID:nHNmKGrp.net] その素晴らしい提案がなぜされていないのか考えよう そしてなぜ自分は実行から逃げているのか考えよう 407 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 20:42:45.86 ID:deTzlgug.net] >>394 Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。 408 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:06:58.89 ID:LwoOYerE.net] unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 危険な操作も含まれるけど危険な部分を分けれてるわけではない。 もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。 409 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21 ] [ここ壊れてます] 410 名前：:18:47.87 ID:deTzlgug.net mailto: >>401 安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。 デフォルト禁止でもいいくらい。 [] [ここ壊れてます] 411 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:31:01.25 ID:LwoOYerE.net] >>402 だからそうしたいならそうすりゃいいって話をしてる。 あなたが裁量権をもつプロジェクトでは。 私が反論してるのは「そのためのものだ」という部分に対して。 412 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:44:58.62 ID:deTzlgug.net] >>403 Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。 unsafeはデフォルト禁止でいいよ。 413 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 21:49:49.48 ID:Fy0R0co2.net] 理想をいえばunsafeなんて無いならサイコーだったんだろうね rust陣営もしゃあなしでunsafe導入したんやろうし unsafeなしですべてがセーフで効率的だったら そりゃあrustは本当に素晴らしい文句なしの言語だったやろな 414 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:08:33.46 ID:toZsv7uT.net] 生ポインタすなわちCPUによるメモリアクセスはunsafe そこが出発点 unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる それがsafe Rustの基本原理 つまりunsafeに行き着くためunsafe無しでは何もできない これが真理 一方で unsafeを閉じ込めたライブラリ利用可を前提にすれば unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実 415 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:24:02.18 ID:cgbLYCC5.net] >>406 だったらデフォルトunsafe禁止で良い。 どこでもunsafe okはやっぱりチグハグ。 416 名前：デフォルトの名無しさん [2024/03/27(水) 22:52:47.09 ID:qNf/D02g.net] そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？ 417 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 22:57:38.14 ID:LwoOYerE.net] >>404 「そうであって欲しいと自分は思っている」なら別にいいよ。 ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。 418 名前：デフォルトの名無しさん mailto:sage [2024/03/27(水) 23:02:28.02 ID:toZsv7uT.net] #![forbid(unsafe_code)] を宣言すればいい もちろんすべてはunsafeへ行き着くため unsafeを禁止できるのは自分のコード部分だけ 419 名前：デフォルトの名無しさん [2024/03/27(水) 23:55:45.93 ID:pFQTMi8v.net] unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな 平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する 420 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 07:44:09.91 ID:OabXy/xk.net] >>409 公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。 >>411 拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？ 421 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:15:17.48 ID:wHq/ItvK.net] rustもいろいろ問題を抱えてるんだね プログラマの習熟が必要だっていうなら流行らないだろう メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし 新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう 422 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:34:31.08 ID:5loDhjzb.net] >>412 こう書くだけでunsafeの使用が禁止されます #![forbid(unsafe_code)] >>413 普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません 423 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 08:48:28.49 ID:OabXy/xk.net] >>414 >411みたいなマキャベリガイジが混ざると破綻しますな。 MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。 424 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 09:00:19.29 ID:5loDhjzb.net] >>415 これでunsafeが使用禁止となり安全なsafe Rustになる #![forbid(unsafe_code)] コンパイラがunsafeをエラーとして弾く 425 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 10:37:24.50 ID:dWo+4s1T.net] 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな 426 名前：デフォルトの名無しさん [2024/03/28(木) 14:03:58.90 ID:61/ABBlz.net] まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。 427 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 17:41:01.08 ID:Li+1uESY.net] unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者 一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、 その部分だけを切り出してライブラリ作成者になれる それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない 428 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:27:15.03 ID:OabXy/xk.net] >>419 そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。 Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。 429 名前：デフォルトの名無しさん [2024/03/28(木) 18:35:39.73 ID:2Ez7VURh.net] unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ 430 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 18:56:54.80 ID:Hx0Q8eMq.net] 必要な各企業、各プロジェクトなどで義務付け #![forbid(unsafe_code)] これでunsafeの話はおしまい 他の言語と比べてRustはコーディング規約もAPI規約も公式で楽 Rust公式APIガイドライン https://rust-lang.github.io/api-guidelines/ 431 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 19:45:10.84 ID:OabXy/xk.net] >>422 公式のドキュメントで #![forbid(unsafe_code)] の説明を探しているんだけど、どこにあるのかしらん？ doc.rust-lang.org/nomicon/safe-unsafe-meaning.html の１行でおしまい？ 432 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 20:08:10.91 ID:uNPCtnZO.net] forbidもunsafe_codeもrustcのlintの一部だな doc.rust-lang.org/rustc/lints/levels.html#forbid doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code 433 名前：デフォルトの名無しさん [2024/03/28(木) 21:59:19.02 ID:vhhc95Ef.net] Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。 434 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 22:34:58.42 ID:jTiWvkZ+.net] どの開発でも #![forbid(unsafe_code)]が原則 どうしてもunsafeが必要なら その安全ロジックを関係者で協議後に #![deny(unsafe_code)]へそのモジュールのみ変更し 許可する部分のみを #![allow(unsafe_code)]として監視対象 といった感じが一般的かと 監視対象を極一部に限定できて 全体はコンパイラにより保証できるため 他のプログラミング言語より扱いやすい 435 名前：デフォルトの名無しさん [2024/03/28(木) 22:41:56.41 ID:8+kd1npI.net] >>420 一般とそうでない奴は誰がどうやって区別するのさ？ 436 名前：デフォルトの名無しさん [2024/03/28(木) 22:42:31.88 ID:8+kd1npI.net] >>421 正解 437 名前：デフォルトの名無しさん mailto:sage [2024/03/28(木) 23:58:52.21 ID:KGiLR8kg.net] 時間がない時はunsafe使っていいよ 438 名前：デフォルトの名無しさん [2024/03/29(金) 00:05:51.94 ID:B//2x2dm.net] 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう 439 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:19:58.75 ID:Rgc3qInF.net] >>429 safeで書くのが早くて楽で安全 わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない 440 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 00:24:32.79 ID:Rgc3qInF.net] >>430 unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる safe Rustが楽で早く書けて安全 441 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 01:57:50.63 ID:EplliVDI.net] 壊れたレコードオジ怖い 442 名前：デフォルトの名無しさん [2024/03/29(金) 02:36:16.29 ID:B//2x2dm.net] >>432 安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？ 443 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 07:36:27.65 ID:9Pm5HVgJ.net] 雑にunsafe使って早く書けるのはFFIくらいかな FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い pure Rustでunsafeの方が早いケースはちょっと思いつかないな 444 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:25:13.35 ID:bd1Zch8f.net] >>427 そりゃプロジェクト管理者だろ。 そもそもRust採用するメリットはソースコードの品質管理しか無いし。 デフォルトunsafe禁止は何回か話題に出てきているのな。 445 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:27:22.40 ID:bd1Zch8f.net] >>426 それぐらいやらないとRust採用するメリット無さそうだよな。 446 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 08:41:03.04 ID:ev5kqnbp.net] 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？ 447 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:16:34.82 ID:cTkAvXQI.net] そもそも普通に書いててunsafe使いたいなって場面がない 多人数で書いてるならforbidで落としてもいいけど コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい 448 名前：デフォルトの名無しさん [2024/03/29(金) 09:24:57.68 ID:vaG7EqUh.net] >>436 じゃunsafe使うな、で済む話じゃん。 449 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 09:49:54.05 ID:AosFf04R.net] >>440 そうだね で？ 450 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:01:08.74 ID:8PtB/vi4.net] rustもプログラマがザコだと使いこなせない言語なんだろ？ 人材確保すら苦労するってメジャーになれるのかよ 451 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:23:44.57 ID:34VMnlB4.net] unsafeでサッと書いたほうが出世できるぞ 452 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:49:42.05 ID:ZM8BmiyA.net] たしかにプログラムの品質がいいから出世するって見たことないわ 逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな 453 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:53:12.39 ID:opHbD1qf.net] unsafeは面倒 Rustで書いていてunsafeを使いたい気分になることがない さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない 454 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 11:54:18.08 ID:K6ErCtbZ.net] >>442 メジャーになれなくて何か問題あるの？ 455 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:03.79 ID:6hM9S6Vd.net] 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。 456 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:08:08.24 ID:GuqFwMZD.net] >>440 PMやったこと無いの？ unsafe使うなと管理するより、そもそも使えない方が遥かに楽。 457 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 12:13:58.45 ID:E/kaNL72.net] >>442 C++ とかだと使いこなせてないのになんとなく動いちゃったりするから…… 使えてないなら使えないほうがちょっとマシなんだよ。 458 名前：デフォルトの名無しさん [2024/03/29(金) 12:15:29.32 ID:vaG7EqUh.net] >>448 言語機能的にunsafeって書かなければそもそも使えないじゃん。 459 名前：デフォルトの名無しさん [2024/03/29(金) 13:21:21.11 ID:l8m+nc89.net] >>446 時間の無駄 460 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 13:35:34.69 ID:ZM8BmiyA.net] >>448 そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね 461 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 16:25:54.97 ID:34VMnlB4.net] unsafeでサクッと終わらせてどんどん仕事取ろうぜ safeでチンタラやってる無能に仕事を回すな 462 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:20:13.23 ID:Cl3C8AEw.net] アンチはunsafeを使うと早く書けると誤解しているのが面白い 早くもなければ楽でもないので普通は使わない 463 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:36:40.68 ID:cTkAvXQI.net] 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね 464 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 17:56:14.07 ID:uhU4IUEm.net] このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが 465 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:02:08.48 ID:uhU4IUEm.net] 正常なコミュニケーション力を持った優秀なエンジニア →こいつらは出世するのでプログラミングスキルは生かされない方向に進む 正常なコミュニケーション力がない優秀なエンジニア →こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない どうしたら優秀なエンジニア揃えられるんや… 466 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:06:18.85 ID:fG0MAqjd.net] ｶﾁｮｰ「では進捗を報告してください」 unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」 ｶﾁｮｰ「???」 467 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:22:45.54 ID:TAofIzHh.net] >>457 放っておいても勝手に集まるから心配しなくていいよ そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど 468 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 18:29:23.69 ID:/REVrZ9A.net] >>459 すまん、集まってるとこの実名あげてくれんか？ 469 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:20:01.67 ID:GuqFwMZD.net] >>458 いきなり人格攻撃かよ？Rustらしいな 470 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:31:34.50 ID:wqpOcL9O.net] NとかFとかは優秀な人がいるイメージがない 471 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:54:25.38 ID:M7FjmHlu.net] unsafe使う機会ってほぼないよな よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか 472 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:58:01.23 ID:wqpOcL9O.net] 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人 でunsafeを使いこなせるかどうかなんか無関係 これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人 473 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 19:59:06.31 ID:0Uoml8t7.net] システムプログラミング用途も売りにしてなかった？ Cと同等のことをしてみせようってんなら unsafeくらい当たり前に常用するやろ？しらんけど ボクは使いません！みたいな意見は誰も求めてないからｗ 474 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:37:55.25 ID:TAofIzHh.net] unsafe使うと変更する時にだるくなるからできるだけ使わない グローバル変数使うのと同じ気分 「グローバル変数くらい当たり前に常用するやろ？しらんけど 　ボクは使いません！みたいな意見は誰も求めてないからｗ」 とか言われたら知らん 475 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:41:59.79 ID:wqpOcL9O.net] 誰にも影響及ぼさないなら勝手に使えばいい 476 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 20:47:48.55 ID:0Uoml8t7.net] 使う必要があるからunsafeってもんがあるんであって 使う必要がない人の意見や感想は求められてないんよ 使うべきとか使うべきじゃないとか 普通はどうとか普通はどうじゃないとか 無意味な応酬はやめよう 477 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:08:57.87 ID:bd1Zch8f.net] コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。 478 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:45:08.79 ID:DW6NdCQ6.net] >>451 君の時間の無駄ってこと？ こんなところで毎日無駄な時間過ごしてるのに？ それって君がやらなければいいだけだよね 479 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:46:36.17 ID:wXELlTG7.net] >>468 一連のunsafeコントで初めてまともな意見だな 480 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 21:52:31.85 ID:TAofIzHh.net] エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで Rustが普及する日は来 481 名前：るんだろうか 上の方でも言われてたけどコーダー集まらない問題に直面しそうだが [] [ここ壊れてます] 482 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:06:45.92 ID:wqpOcL9O.net] Rustはコーダーは集まらんだろ 普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる 大手だとこれの繰り返しだがRustはそれが難しい 483 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:29:09.47 ID:wqpOcL9O.net] 意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと 増えるわけがない javaやpythonじゃないんだから 野良Rustコーダーなんて存在しない 使える人間は100%C++使いなので引っ張ってこれない 484 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:30:50.06 ID:UmT7/PmU.net] エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな 485 名前：デフォルトの名無しさん [2024/03/29(金) 22:35:31.54 ID:B//2x2dm.net] まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう 486 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 22:48:02.40 ID:0Uoml8t7.net] それよりもホントにシステムプログラミングできてんのかが興味あるわ CからはOSならばUnixやLinuxやWindowsが生まれてきたけど Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？ Cより書きやすくて？　安全なんだよね？　期待していいんよね？ Systems programming https://en.wikipedia.org/wiki/Systems_programming e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications 487 名前：デフォルトの名無しさん [2024/03/29(金) 23:01:23.64 ID:B//2x2dm.net] 今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある でも期待するのは自由だ Rustファンはみんな期待している 488 名前：デフォルトの名無しさん [2024/03/29(金) 23:11:14.94 ID:JKQcuRe5.net] >>477 interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。 ビジネスになるかはともかく、技術的には余裕なはず。 489 名前：デフォルトの名無しさん mailto:sage [2024/03/29(金) 23:55:56.73 ID:VDRjyKLu.net] 既にネットインフラは次々とRust製 ソースは>>51 490 名前：デフォルトの名無しさん [2024/03/30(土) 00:06:31.16 ID:v9pXWAWc.net] >>472 Rustは仕様や周辺ツールが飛びぬけて優秀な故 JavaやPHP等他の言語と違って素人でも適当に書いても 大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると 大規模開発現場で普及する事はこれからも無いよ。 491 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 01:01:10.58 ID:7ofxl8DK.net] それで守られるのはITコン猿の立ち位置じゃね？ エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが 492 名前：デフォルトの名無しさん [2024/03/30(土) 01:46:17.09 ID:v9pXWAWc.net] 知ってる人間は黙ってRustの恩恵を受けておけば良くて 人売りサル業界は人/月だコミュニケーションスキルだと 喚いていれば良い。 493 名前：デフォルトの名無しさん [2024/03/30(土) 07:28:24.91 ID:6WvjgMqi.net] C++が流行った経緯知ってる奴なら想像できるだろ。 C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。 でも流行ったのはC++。 494 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 13:15:43.05 ID:Kpt9p6/a.net] C++はわかりやすく拡張されたCだからさ ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない 日本語の書籍がないのが一番つらかった 495 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 20:58:56.17 ID:IReUP+am.net] 当時NeXTに触れてたやつおるん？ たまげたなぁ 俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ いつごろだったかなぁ日本語のやつあったけどなぁ まさかmacOSで脚光浴びるとは思いもせずに 496 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 21:08:50.38 ID:Kpt9p6/a.net] 研究室にあったんよ 当時でももう型オチででも予算無いからリプレースも出来ず MOのデータを消しながら使ってた 古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで 自分は図書館に埋もれたModulaの本を読んでた 497 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 21:14:51.55 ID:IReUP+am.net] 羨ましい 俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ あー羨ましい 498 名前：デフォルトの名無しさん mailto:sage [2024/03/30(土) 22:32:19.21 ID:VLAlfJh3.net] モーモーちゃんに入れている人は居たな 499 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 11:42:27.74 ID:lJUXuXT4.net] C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。 結局は C のままでいくと判断した。 良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。 言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。 C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。 Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、 今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。 そもそも ABI が C を基準にした仕様だったりするので 他の言語と接続するときは皆が C に合わせる形になる。 もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。 500 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 15:29:48.98 ID:dXzgmT0X.net] ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う 501 名前：デフォルトの名無しさん [2024/03/31(日) 16:44:42.12 ID:PaHOJUqO.net] >>490 Rustで書いたOSが大流行でもしない限りCと同じようにはならない。 ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。 そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。 もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。 502 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 19:15:56.54 ID:r1rO2LMH.net] ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない 多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する 503 名前：デフォルトの名無しさん [2024/03/31(日) 19:55:09.30 ID:T95JlUSJ.net] ABIこそ良い奴が出たら置き換えられそうだけどな 現状良い奴がないだけで 504 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 21:03:45.67 ID:rhKYEfc8.net] >>493 何言ってんのwww 相変わらず無知が過ぎる 505 名前：デフォルトの名無しさん [2024/03/31(日) 22:06:47.20 ID:HimKkZni.net] いやまあ1%もいないんじゃない？ 506 名前：デフォルトの名無しさん mailto:sage [2024/03/31(日) 23:37:37.59 ID:PUonJ710.net] そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど 507 名前：デフォルトの名無しさん [2024/04/01(月) 19:53:32.69 ID:QJf4H8j7.net] そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。 508 名前：デフォルトの名無しさん mailto:sage [2024/04/01(月) 20:06:07.63 ID:lQvViLVK.net] C++より多いから問題ない 509 名前：デフォルトの名無しさん mailto:sage [2024/04/01(月) 22:56:49.63 ID:wqqAiPYQ.net] 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨 https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html 510 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 08:53:54.00 ID:i0O60K8Z.net] >>500 メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。 c++標準も、Safe Rust に倣って c++ subset for safe programming とか 作ればいいのに。 511 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 09:19:58.94 ID:D6QICSr8.net] メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。 512 名前：デフォルトの名無しさん [2024/04/02(火) 09:39:48.87 ID:EeET/S7r.net] java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。 513 名前：デフォルトの名無しさん [2024/04/02(火) 11:06:55.03 ID:lti1kN7b.net] >>503 安全じゃ無いぞ 514 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 14:49:37.59 ID:b3hi6lw5.net] >>501 C/C++はプログラム全体がunsafe空間なので難しい safeにしようとすると全く別言語になってしまう 結局C/C++を捨てるのが正しい 515 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 17:14:03.69 ID:kERS+9TD.net] >>503 nullポイントがある時点で… 一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ 516 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 17:14:28.23 ID:kERS+9TD.net] nullポインタだ ごめんなさい 517 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:23:13.98 ID:mnREx4SD.net] ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される nullから何かを読み出して動き続けると危険 518 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:43:54.77 ID:0YGJ2wff.net] >>508 Someである保証がある時のみunwrap()を使う 保証がないのにunwrap()する人はクビ 519 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:54:06.54 ID:mnREx4SD.net] メモリ安全の文脈だからそういう次元の話ではないのだが 520 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 18:55:57.61 ID:i0O60K8Z.net] >>505 コーダー向けだから別言語でいいよ。 new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。 operator関数定義も禁止でいいんじゃない？ 521 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:03:35.75 ID:mnREx4SD.net] ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね 522 名前：デフォルトの名無しさん [2024/04/02(火) 19:19:41.72 ID:qL7KDCYj.net] rustって楽しい？ 523 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:20:30.34 ID:kERS+9TD.net] どの言語にも共通するけど，書けるようになってくると楽しいよ 524 名前：デフォルトの名無しさん [2024/04/02(火) 19:40:54.12 ID:lti1kN7b.net] でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね 525 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 19:43:54.71 ID:ptOw8ylO.net] >>512 あ、未定義と定義されているのも全部禁止ね。 526 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 20:13:32.30 ID:+hiVU8fL.net] >>500 これでRustの知名度も上がるし普及も加速しそう 527 名前：デフォルトの名無しさん [2024/04/02(火) 20:26:12.86 ID:lti1kN7b.net] >>517 結構前にもNASAが同じ様な事言って今やんw 528 名前：デフォルトの名無しさん [2024/04/02(火) 20:31:06.25 ID:EeET/S7r.net] rustを無理に使ってまですることがぬるぽ対策とかアホだよね 529 名前：デフォルトの名無しさん [2024/04/02(火) 20:45:15.37 ID:lti1kN7b.net] >>519 まあ戦争によるサイバー攻撃に備えろってのは分かるんよ 日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね 530 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 21:20:14.32 ID:+5bQ5ala.net] >>518 NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね 間違いなく日本も追随することになる 531 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 21:56:04.08 ID:mnREx4SD.net] Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ ONCDは健全なのかな 532 名前：デフォルトの名無しさん [2024/04/02(火) 22:51:50.04 ID:ZP8DsSPi.net] >>518 NASA？NSAじゃなく？ NSAはNASAじゃないぞ。 533 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:24:29.45 ID:JjgiIhmH.net] ワロタ NSAとNASAの区別もできんとはｗｗ メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か 2022/11 NSA 2023/09 CISA 2023/12 CISA+NSA,+FBI+Five Eyesの各機関 2024/02 White House(ONCD) 534 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:39:08.04 ID:/KZzSXx2.net] とりあえず良いcrateが増えまくってほしいな 535 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:51:33.79 ID:DOFjhDY0.net] >>524 あとは日本がどれだけ遅れるかだな 数ヶ月か、1年か、数年か、 536 名前：デフォルトの名無しさん mailto:sage [2024/04/02(火) 23:57:17.27 ID:ULMcj34Q.net] 外部のお墨付きを欲しがる時点でオワっとるんよ 言語として ここでそういう話題使って必死で盛り上げようとして 消えそうな火に風送ってるつもりかしらんけど 537 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 00:07:33.86 ID:xB8sPKZQ.net] IT大手ライバル同士が GAFAMからHUAWEIまで一致団結して Rust Foundationを設立した時点で未来は確定していた そしてRustに対抗できるライバル言語の芽が今も存在しない 538 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 05:31:15.82 ID:SWmJ9bDO.net] >>527 話題にも上がらないよりまし 539 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 07:36:47.52 ID:ClJR5oeK.net] Rustの代替になる思想の言語が全くそれ以降全く見ないからな。 今のところGCレスでメモリ安全に向き合った唯一の言語でねえの？ 後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。 540 名前：デフォルトの名無しさん [2024/04/03(水) 08:17:45.92 ID:OgaFV8I4.net] >>527 欲しがってるかね？ むしろ外部が乗っかろうとしてる感じ。 541 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 08:58:53.93 ID:7dkIXzmY.net] >>530 メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。 過去互換性のせいで徹底できないけど。 それよりもRustはスタックフレーム指向であることに価値がある。 スタック is god, 再帰 is god. 542 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 11:38:42.38 ID:TbyA9/um.net] >>515 まあ標準ライブラリがかなりミニマムだなぁって感じるときはある 乱数くらい用意しておいてよ… 543 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 11:38:56.67 ID:zWYr6uc2.net] >>530 ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている で別の言語Bが作られる その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない 544 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 13:08:37.11 ID:VOIzFFgw.net] >>534 >その言語Bが普及しきっていなければ容易に弱点を変更できる これが真とは限らない 容易に変更できる場合もあればそうでない場合もある 545 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 13:33:20.93 ID:7LWlVk3J.net] Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか wikipedia > 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。 546 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 21:45:24.20 ID:ClJR5oeK.net] GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。 547 名前：デフォルトの名無しさん mailto:sage [2024/04/03(水) 22:40:40.78 ID:7LWlVk3J.net] 後発言語？？？ 548 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 03:50:23.61 ID:6dtGhNgR.net] >>537 所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。 適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。 ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。 549 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 04:13:47.93 ID:KZy/sIny.net] Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ とりあえず動くように雑に書いて動かしてみて 次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など このようなリファクタリング過程で 他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが Rustではコンパイル通せばそれらの心配がなくリファクタリングできる 550 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 08:02:04.20 ID:KuogGH/c.net] そもそもGC無しの言語ってニッチじゃない？ 当面は、Rustで充足されて安泰な気がする。 551 名前：デフォルトの名無しさん [2024/04/04(木) 08:06:01.77 ID:wZ/e8tnl.net] うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。 関数型言語にも良いのあるけど、普及しなさそうだしね…。 （OCamlとか次世代HaskellらしいIdrisとか） それにCとアセンブラしかない分野（C++不可なくらい低スペックな組み込み）でC++以降のモダンな言語が使えるのは大きい。 552 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 08:41:03.15 ID:VIrJEXhK.net] 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。 LLVM が C/C++ を前提にしてるところもあるし、 Rust もそれに合わせる形になってるところもある。 C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。 553 名前：デフォルトの名無しさん [2024/04/04(木) 12:25:37.65 ID:Gnl54rZ8.net] すまんが↓これが動く理由を教えて欲しいんだけどさあ https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w 一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・ これって5行目が借用に推定されてるの？ それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな？ へるぷみい 554 名前：デフォルトの名無しさん [2024/04/04(木) 12:36:31.67 ID:xh1kANkn.net] マクロだからセーフ 555 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 12:40:39.97 ID:yz59nStO.net] >>544 値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる 556 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 12:49:08.15 ID:w8P1RFve.net] 値が複製されて、複製された値の所有権が関数fに渡るだな。 所有権の複製とかいうクソワードは避けてくれ。 557 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 14:09:00.66 ID:VIrJEXhK.net] >>544 i32 は Copy トレイトが実装されてる。 普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。 558 名前：デフォルトの名無しさん [2024/04/04(木) 14:21:30.05 ID:Gnl54rZ8.net] そう言うことなのか、ありがとう！ 理由が分からなかったから不気味だったぜ 559 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 15:21:14.87 ID:AF0jRQyM.net] >>547 >値が複製されて、複製された値の所有権が関数fに渡るだな。 複製された値の所有権は最初から関数fのスコープの中で発生するものなので 「関数f」に渡るという表現には少し違和感を感じる 560 名前：デフォルトの名無しさん [2024/04/04(木) 15:34:13.46 ID:1vyOHDUL.net] 「違和感を感じる」という表現に違和感を感じる 561 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 18:59:50.97 ID:mbQWc9lN.net] >>551 滑ってるぞ 562 名前：デフォルトの名無しさん [2024/04/04(木) 19:04:00.82 ID:mNkWQBjH.net] 感じてるから違和「感」だからね 要は頭痛が痛いと同じ 563 名前：デフォルトの名無しさん [2024/04/04(木) 19:08:09.03 ID:v0TcrcAn.net] 違和感がある。これでどうだ 564 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 19:17:51.63 ID:v7LceGlx.net] >>553 感じるを感じるメタ表現だろ。 ポインタのポインタみたいなもんだ。 565 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 20:07:49.07 ID:xDxHg+AD.net] >>542 embedded 対応アーキ少なくね？ 566 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 23:05:07.77 ID:94OMF7T7.net] >>553 「違和感を感じる」は「頭痛が痛い」とは違って重言ではないよ https://togetter.com/li/2067771 https://www.nhk.or.jp/bunken/research/kotoba/20240101_4.html 567 名前：デフォルトの名無しさん mailto:sage [2024/04/04(木) 23:18:56.70 ID:94OMF7T7.net] >>557 重言ではあるけど間違った日本語ではない といったほうがよかったね 568 名前：デフォルトの名無しさん [2024/04/05(金) 00:09:35.95 ID:Lw8p7kTG.net] >>556 少ないね。 でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。 それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。 569 名前：デフォルトの名無しさん mailto:sage [2024/04/05(金) 00:21:09.11 ID:dub3Z8tI.net] 後発言語？ 570 名前：デフォルトの名無しさん [2024/04/05(金) 00:50:16.55 ID:Lw8p7kTG.net] 少し前まで次世代言語と言われてた程度には後発。 鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。 むしろ崩し始めることすら無理だと思ってた。 571 名前：デフォルトの名無しさん mailto:sage [2024/04/05(金) 05:07:52.53 ID:CPVE6BHF.net] >>559 状況も追い風なのかもね。 二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。 先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな？ 572 名前：デフォルトの名無しさん [2024/04/05(金) 08:11:28.72 ID:Lw8p7kTG.net] Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。 複数言語使えますってだけでもアピールになるしね。 Rustは多分仕事自体はまだ多くない。 これからアピールして増やしていく感じなので、両方使えてた方がいい。 573 名前：デフォルトの名無しさん mailto:sage [2024/04/06(土) 22:48:03.64 ID:4i1Gvjc8.net] rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ 574 名前：デフォルトの名無しさん mailto:sage [2024/04/06(土) 23:06:32.76 ID:7kpWL/Du.net] Rustが実用的になったのは2020年 それ以降の新規案件はRustになっている 575 名前：デフォルトの名無しさん [2024/04/07(日) 01:26:10.29 ID:Hmt7T+4v.net] Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前 576 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 10:55:29.15 ID:QD1FKAnH.net] 絶壁の学習曲線。 貧弱なライブラリと人材。 早すぎる最適化。 しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。 577 名前：デフォルトの名無しさん [2024/04/07(日) 14:17:46.28 ID:vzw88H1n.net] P系言語の糞思考に染まっていない初心者こそ 最初にRustを学ぶべき 578 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:04:59.36 ID:Sj2oLPpI.net] >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 579 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:05:33.79 ID:nD4MmBKu.net] 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか 580 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:09:00.76 ID:Sj2oLPpI.net] >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる Rustでも同様でほとんどがそれら含む新たな案件 581 名前：デフォルトの名無しさん mailto:sage [2024/04/07(日) 18:16:09.73 ID:TV6Dkj8m.net] >>567 早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ そしてRustを叩きたいためにウソを散りばめる 582 名前：デフォルトの名無しさん [2024/04/08(月) 02:24:45.08 ID:BHlkyWwA.net] >>567 貧弱なライブラリとかエアプかよ そしてRustを叩きたいためにウソを散りばめる 583 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 03:09:59.48 ID:BqmMXmQi.net] 単なる感想を必死にウソ扱いして何がしたいんだコイツw 584 名前：デフォルトの名無しさん [2024/04/08(月) 11:48:22.86 ID:hzcejt90.net] ライブラリはPythonと比べると流石に貧弱 特に数値計算とか物理・機械学習系 簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない 585 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 12:32:47.46 ID:64QjhTLf.net] >>575 キチガイアンチ すべての分野でライブラリが充実している言語は存在しない ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前 そういう無意味なことをして叩いて楽しいか？ 586 名前：デフォルトの名無しさん [2024/04/08(月) 13:16:14.61 ID:JoalanBl.net] >>576 貧弱なことを指摘するのは叩きではない 俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ 587 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:02:16.22 ID:7wfBslr8.net] >>576 そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。 588 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:10:54.87 ID:7wfBslr8.net] >>570 絶壁の学習曲線だから無理だろ。 moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない？ 589 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 14:43:36.67 ID:IC0NBj1d.net] Crypto分野はRustが他言語よりも充実してるかもね 590 名前：デフォルトの名無しさん [2024/04/08(月) 15:06:06.34 ID:rjHvzTUw.net] ライブラリの多さってイコールでユーザの多さなんだよ 更にいうとその言語開発者の意欲の表れでもある ライブラリが少ないという事はユーザが少ない 更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね 591 名前：デフォルトの名無しさん [2024/04/08(月) 15:43:54.88 ID:JoalanBl.net] いやまあ数はあるんよ数は 意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな 資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う 592 名前：デフォルトの名無しさん [2024/04/08(月) 16:39:42.51 ID:9qnuy4NE.net] てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。 そんなんで数値計算ライブラリが入るわけがない。 593 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 17:11:27.78 ID:7wfBslr8.net] 初心者向けのSimplified Rustと、 c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。 Safe Rustじゃ難しそうだし。 594 名前：デフォルトの名無しさん [2024/04/08(月) 17:54:43.90 ID:JoalanBl.net] ゼロからプログラム書くならSafe rustが一番簡単だよ こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが 595 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 19:05:28.67 ID:ifgKIXku.net] C++を完全に理解した者のための言語それがRust 故に誰も 596 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 20:39:36.28 ID:cqL1RV99.net] C++を使ったことないけど Rustで困ったことないな Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな 所有権は単なるヒープ解放責任だから大したことではない 所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話 非常にシンプル 597 名前：デフォルトの名無しさん mailto:sage [2024/04/08(月) 21:02:11.65 ID:YkdU7kgc.net] 所有権を複製するとか間違った事を言い続けてる人が良く言うわw 598 名前：デフォルトの名無しさん [2024/04/09(火) 00:09:53.71 ID:pItuq1gX.net] >>588 それは俺じゃないぞ 599 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 02:45:12.09 ID:hsAXyuRl.net] >>589 誰だよお前。 600 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 09:16:17.69 ID:OXfvzIgi.net] 今のところ>>458が一番面白い 601 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 10:16:36.65 ID:Po0ZJOeT.net] 昭和ギャグ？ ちょっと意味がわかりません 602 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 11:01:29.74 ID:cj+QXWpg.net] 今どきイジりを面白いとか、イジメ肯定派かよ。 603 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 13:18:19.32 ID:9AcR/8+u.net] 進化論肯定派じゃないの 人を淘汰することを志している 604 名前：デフォルトの名無しさん mailto:sage [2024/04/09(火) 17:18:23.86 ID:+rnauHt3.net] ｶﾁｮｰ「???」じゃなくて ｶﾁｮｰ「で?」なら共感できたかも 605 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 01:14:02.81 ID:/k7xUJZy.net] rustだいぶ分かってきたつもりだけど ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理 好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる 606 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 08:03:56.89 ID:ltqciZ07.net] >>592 進捗報告相手が課長というのが昭和かもな そんな会社で働きたくない 607 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 11:01:40.54 ID:5Js//1cu.net] >>596 moonbit くらいならどうかな？ 608 名前：デフォルトの名無しさん mailto:sage [2024/0 ] [ここ壊れてます] 609 名前：4/10(水) 11:35:35.51 ID:AS+TZoYk.net mailto: >>596 それぞれ理解していれば組み合わさって困ることはないんじゃないかな Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど [] [ここ壊れてます] 610 名前：デフォルトの名無しさん [2024/04/10(水) 16:55:22.63 ID:yZA7mDLP.net] Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど 611 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:30:31.18 ID:Fk7YBwaR.net] メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。 612 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:38:51.91 ID:t7JkSWKp.net] self/ mut self/&self/&mut selfの区別もいるしな self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では 613 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 17:52:25.08 ID:5Js//1cu.net] C++ の ref-qualifier とか無理のある文法だもんな。 そこに書くんか!? という変な驚きがある。 引数の一種ということにしたほうがかなり単純でよい。 実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された｡ (deducing this) 614 名前：デフォルトの名無しさん [2024/04/10(水) 17:58:48.34 ID:Q64PiueS.net] RustでPython実装すりゃ良いんじゃね 615 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 18:34:01.75 ID:3h5gXXiJ.net] >>602 普通に全部ダサいんだよなあ 何とかならなかったのかとならなかったのかとならなかったのかと… 616 名前：デフォルトの名無しさん [2024/04/10(水) 19:34:40.80 ID:8DE+tVvz.net] selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか 617 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 19:44:04.66 ID:y0DX5npz.net] ぜひとも >>605 の考える最高にイケてる構文を教えてほしい Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし 618 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 19:47:55.68 ID:IjfZ+vUr.net] >>605 nimの関数呼び出しルール 関数名(第一引数,第二引数...) 第一引数.関数名(第二引数...) で第一引数がself相当 が一番スマートかと。 619 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 20:06:03.20 ID:AS+TZoYk.net] >>605 むしろ>>602はそれらの区別のためにもselfは必須と言ってるようにみえる さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい 現状のRustの仕様がベストかな 620 名前：デフォルトの名無しさん [2024/04/10(水) 21:28:15.02 ID:8DE+tVvz.net] selfじゃくてthisならC++マニアも納得 621 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 21:34:35.54 ID:6SjCdg5T.net] >>608 nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね Vec::push(&mut vec, 123); (&mut vec).push(123); vec.push(123); この&mutを省略できてRust便利 622 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 21:37:52.75 ID:Mpv09JwO.net] thisはたまにselfの代理で使われてるな Rc::into_innerとか 623 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 23:19:28.12 ID:AS+TZoYk.net] deref後のinto_inner適用と区別のため 敢えてself使わないことでメソッド呼び出し形式をできなくして 明示的にRc::into_inner呼び出しさせるパターンだね 624 名前：デフォルトの名無しさん mailto:sage [2024/04/10(水) 23:45:41.84 ID:Fk7YBwaR.net] メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は LISP 用に作られたオブジェクトシステム new flavors でやってた。 625 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 02:11:03.37 ID:4f6XcC0j.net] それは同一視というか構文が1つしかないだけでは 626 名前：デフォルトの名無しさん [2024/04/11(木) 02:14:15.06 ID:7FNbL3Xb.net] 呼び出し時には与えない引数って紛らわしくね？ 627 名前：614 mailto:sage [2024/04/11(木) 02:45:03.24 ID:C4qhk0zm.net] >>615 メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。 new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど new flavors で改良 (かどうかわからんけど) された。 628 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 04:57:52.23 ID:r6y9Ju0a.net] >>616 むしろ逆かな target.method(arg1, 629 名前：arg2, ...)という targetへのメソッドコールを実現するのを関数で表すと method(target, arg1, arg2, ...)とする言語が多い Rustでも同じでこのtargetをselfと書く targetは送る側から見た視点 selfは受け取った側から見た視点 各実装は受け取った側でなされるためself [] [ここ壊れてます] 630 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:24:38.80 ID:McLA6Ner.net] UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな レシーバとして扱われるなら構文上も特別であってほしい 631 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:39:59.21 ID:UjbgXeUt.net] >>619 何が気持ち悪いのかさっぱりわからない まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね？ 次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね？ ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう 632 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 08:49:57.16 ID:azFLg2co.net] 言うほどほとんどの言語がこれか？ pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ これがPythonいまいちだなって思うところ c++も似た様な理由でstaticでthis 後発で考慮する余裕あるのにそれを引っ張ってる 633 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:02:17.34 ID:NXydgA7G.net] >>621 君の感性がおかしいんじゃね？ NimもZigもRustもPythonと同じ標準方式 foo(receiver, arg1, arg2, ..) または receiver.foo(arg1, arg2, ..) 634 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:02:43.98 ID:7FNbL3Xb.net] >>618 なるほどちょっと納得した 635 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:11:33.28 ID:azFLg2co.net] >>622 実質Pythonフォロワーを含めて言われても… 636 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:14:09.83 ID:azFLg2co.net] C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた それがOOP言語になって指定不要になった それがまたC言語時代に逆戻り 637 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:15:22.73 ID:NXydgA7G.net] >>624 何を言ってるのかわからん 文句を言うなら望ましい代案を出してみて 638 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:17:05.47 ID:azFLg2co.net] あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは receiverがNullの可能性がある場合でそう設計されてただけ 639 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:20:43.92 ID:NXydgA7G.net] 代案を出せないってことはRustに言いがかりをつけてるだけだな 640 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:24:05.56 ID:azFLg2co.net] 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ その表記は時間をかけて考えたらいい 641 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:30:34.30 ID:cvuvfjXO.net] >>625 レシーバは必ず必要 Goでも func (receiver ReceiverType) Foo(引数…) { 　return receiver.xxx + receiver.yyy } と書く レシーバ指定不要という主張は理解できない 642 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:45:56.75 ID:gYo8nOa5.net] レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい 643 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:51:28.66 ID:azFLg2co.net] いやいやｗ 無知って怖いねとしか… 644 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 09:52:17.20 ID:azFLg2co.net] >>630 645 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 10:19:57.47 ID:UmgPKlgb.net] UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの >>619はそれを分かった上でNimについて書いてるのかもしれないけど>>620や>>622は明らかに誤解してる 646 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 10:33:59.60 ID:Nlu6ipA3.net] >>631 そう言われるとRustの仕様がベストなのかな レシーバに名前を付けないと名前空間の分離ができなくて レシーバに名前を自由に付けられると読みづらくて 647 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:00:57.82 ID:azFLg2co.net] IDころころお爺さんは明らかに話を理解できないな 648 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:23:46.71 ID:CaCoKmZ3.net] Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな 型指定にSelfやSelf::Itemなど使えるだけでなく Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる Selfによって自分自身であるとわかりコードが読みやすい 型名変更の影響も受けず読みやすいメンテしやすい ダメな言語だと以下のダメなパターンがある ・Selfの代わりに型名を書かなくてはいけない言語　(自分自身だとわかりにくくメンテ性も悪い) ・Selfの代わりにself(やthis)を用いてしまう言語　(値と型の区別がつかない) ・Selfを使わずに名前空間の区別がない言語　(間違いが起きやすく自分自身だとわかりくくメンテ性が悪い) 649 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:57:27.19 ID:17a5lmDN.net] 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな…… 650 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 11:57:34.08 ID:6x2Zth+c.net] 複オジは見えてる範囲が狭過ぎる だから長文になればなるほど勘違い度や害悪度が高まる 651 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 12:47:47.10 ID:ZruVErXu.net] 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると 一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない Rustを叩く前に視野を広く持つべきだな Rustの仕様はよく考えられ機能的に洗練されている 652 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 12:59:00.66 ID:AZdBjU6j.net] >>640 Rustに無いからといってUFCS叩くのはさすがにアホかと。 653 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 13:15:55.80 ID:4f6XcC0j.net] そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん 654 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 15:57:20.01 ID:R8LZpbjl.net] >>642 エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない 655 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 15:59:23.14 ID:v1XXdeLJ.net] くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い 656 名前：デフォルトの名無しさん [2024/04/11(木) 16:41:03.54 ID:KhnNkcJ8.net] まともな質問にいつものノリで適当に答えて嘘だったら良くないしね 657 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:01:08.25 ID:TWMZ6q+3.net] そっか 俺の答えも間違ってたしな 正しくはdowncastのために必要らしい 詳しくはfix_errorのRFC見て 658 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:41:58.72 ID:McIjmFt1.net] Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？ 659 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 17:48:38.15 ID:McIjmFt1.net] 動き出した サーバー側の問題っぽいな https://github.com/rust-lang/rust-playground/issues/831 660 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 18:55:11.06 ID:4f6XcC0j.net] downcastなんて別にしないからいらねーよって思ったけど そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか ヒントありがとう 661 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 19:06:32.42 ID:VFM//2+p.net] 複おじはc++も使ってなかったんだな 662 名前：デフォルトの名無しさん [2024/04/11(木) 20:25:23.50 ID:81s1BzdD.net] >>641 UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。 Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。 663 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 20:52:12.80 ID:AZdBjU6j.net] >>651 UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。 それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。 664 名前：デフォルトの名無しさん [2024/04/11(木) 21:02:41.98 ID:81s1BzdD.net] >>652 Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。 そのためUFCSのような愚かな方式を採る必要がない。 665 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:15:01.99 ID:mF0oHAZm.net] 答えを教えてもらっているのにヒントありがとうというオジさんw 666 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:16:29.71 ID:2g+gCFiF.net] メソッド名空間www 667 名前：デフォルトの名無しさん mailto:sage [2024/04/11(木) 21:54:13.50 ID:AZdBjU6j.net] >>653 それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。 もっとUFCSならではの問題点を指摘してくれ。 せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。 668 名前：デフォルトの名無しさん [2024/04/11(木) 23:54:23.85 ID:A4VQpdsZ.net] アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ アラビア語おすすめ 669 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 00:40:05.77 ID:fvGN/jjJ.net] >>656 それはメソッド呼び出しのメリット モジュール化や結合の観点からも最初からメソッド定義していくのが正しい UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる 具体的には歴史的な負の遺産でボロボロなC++が該当する そのためC++ではUFCSを導入しようと今も悪あがきをしている ほとんどの言語にUFCSがないのはそんなものを必要としないためだ 670 名前：デフォルトの名無しさん [2024/04/12(金) 00:44:02.94 ID:tVNhffJ+.net] モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい 671 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 02:47:17.34 ID:DYhqcHWh.net] それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない AddAssignやSubやShlなど多くの演算は非対称 672 名前：デフォルトの名無しさん [2024/04/12(金) 04:21:38.21 ID:tVNhffJ+.net] いや別にSubでもDivでも左のみに紐づいているのはキモい 673 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 04:49:28.47 ID:rUQyilnM.net] >>658 やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。 例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ？ グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。 674 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 05:26:42.25 ID:CIaMPOtu.net] >>662 トレイルではなくトレイト トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ 675 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 07:31:40.11 ID:rUQyilnM.net] >>663 だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。 676 名前：デフォルトの名無しさん [2024/04/12(金) 12:27:40.08 ID:OadUyd3M.net] >>659 ＞モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ 同意 677 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 12:33:34.40 ID:rAepnpk2.net] >>664 Rustはそうやってきちんと管理できつつ便利 678 名前：でいいよなー 他の言語も導入すればいいのに [] [ここ壊れてます] 679 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 12:43:39.99 ID:6xQx5uEa.net] >>665 オブジェクト指向を全否定するキチガイか クラスのある言語もクラスのないGoやRustなどの言語も 一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ 680 名前：デフォルトの名無しさん [2024/04/12(金) 13:04:32.76 ID:qd6Rxygz.net] とりあえず感覚で一行目から罵倒する人 681 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 15:24:23.71 ID:XC+pkKeZ.net] >>667 >一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ オブジェクト指向前提思考？ 682 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 16:22:22.83 ID:RDQRwL9V.net] >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう からの >UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 schizoかな？ 683 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 17:02:05.38 ID:oSrgtnnN.net] それらの件でもRustの仕様が優秀すぎ 684 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 20:51:13.79 ID:NYkXEvAJ.net] >>670 虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ 685 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 22:18:23.28 ID:HgYc1X5O.net] おじいちゃんは昼だけ起きてて 夕方を過ぎると寝てしまう 686 名前：デフォルトの名無しさん mailto:sage [2024/04/12(金) 22:50:23.70 ID:3nYhUDoK.net] RUSTがトレンドに！！ 687 名前：デフォルトの名無しさん [2024/04/12(金) 23:58:18.71 ID:lpyrPPhz.net] >>667 つジェネリック 688 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 04:39:15.20 ID:0YGiYUZr.net] ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか 689 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 07:36:48.57 ID:beXAxXwF.net] トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？ 柔軟性のために外延性は欲しいところ。 690 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 08:07:59.96 ID:S51MIqUj.net] 異なる型間の共通項をトレイトとして切り出すだけでよく コードを美しく整理して保守性を高めやすい 691 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 13:32:34.24 ID:OrtqC7Lq.net] 敬称ないせいで苦労してるんだってな 692 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 13:36:34.54 ID:F3jinTSj.net] 143 デフォルトの名無しさん 2024/04/07(日) 19:27 純関数型言語でなくても モダンなプログラミング言語 Go、Rust、Zig、Nim、Julia、Elixirなどは クラスおよびその継承を言語仕様から排除しておりクラスは存在しない それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である クラスとその継承は悪手であるとプログラミング言語界では結論が出ている 693 名前：デフォルトの名無しさん mailto:sage [2024/04/13(土) 16:56:52.49 ID:L60jXWVE.net] 継承がなくても構造体にメソッドついてたら実質クラスだろ 関数に構造体渡してたらそれはクラスじゃないけど 694 名前：デフォルトの名無しさん mailto:sage [2024/04/14(日) 23:56:10.96 ID:RjsA2T1t.net] >>681 構造体にメソッドが付くことはカプセル化と言う クラス＝カプセル化＋実装継承　なのでクラスとカプセル化は異なる このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった 実装継承とは具体型が別の具体型を継承することを指す クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる 正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する つまりクラスを完全に排除できるためモダンな言語群にクラスはない 695 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 00:05:55.58 ID:R9iMDmBn.net] 用語も色々。 Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、 JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。 極論すればクラスと名付けたものがクラス。 Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。 C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成する� 696 名前：ｯど、 クラスとは何かを定義せずにクラスかどうかを論じても無意味。 [] [ここ壊れてます] 697 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 00:26:07.32 ID:rd9697wK.net] 型クラスとクラスは全く異なるので混乱しない クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す JavaScriptはプロトタイプを親として実装継承するためクラス 一方でRustにクラスはない 698 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 01:47:00.44 ID:YLFAz6O4.net] クラスとは何か？継承とは何か？ こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい >>681が一番まとも 699 名前：デフォルトの名無しさん [2024/04/15(月) 01:58:25.85 ID:CPtYka/u.net] 話は非常に単純 具体的な型から具体的な型への継承が実装継承でこれがよくない classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承 interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない 最近の言語がclassのみ採用しなかった理由はその違い 700 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 02:39:20.65 ID:zOelqs9y.net] RustにはJavaのクラスはありません RustはJavaではないからです あたまいいね 701 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 03:16:04.95 ID:0QcDOjSQ.net] Javaの生みの親であるJames Goslingも、 「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか？」に対して、 「クラスを除外するでしょうね」と答えている。 その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。 702 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 08:31:26.40 ID:Mqs/ngjj.net] クラスのようなものでいいよ 703 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 10:16:50.96 ID:dcBtWsLv.net] バカの一つ覚えの相手をしても時間の無駄 704 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 12:54:52.68 ID:f4iHJAq/.net] クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな 705 名前：デフォルトの名無しさん mailto:sage [2024/04/15(月) 21:09:43.00 ID:97bFGSba.net] それは単に使い分けが出来ない馬鹿な子向けの説明だぞ 706 名前：デフォルトの名無しさん [2024/04/16(火) 07:27:41.72 ID:10PaZXAR.net] >>691 言語仕様としてあった方が良いということ。 707 名前：デフォルトの名無しさん [2024/04/16(火) 07:42:24.51 ID:KU96szRc.net] 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ 708 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 08:43:42.78 ID:OvO8gS8m.net] Javaの生みの親も言ってるようにクラス継承の機能はない方がいい なくても困らない あると問題を引き起こす 709 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:30:25.53 ID:YlYBNC7y.net] そういうのは話半分に聞いておけばいいよ nullを使ったのは失敗だったとか 後からそれらしいことを言ってるだけ javaはクラスと継承が無くなったらまともに機能しない interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず 710 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:50:49.42 ID:pgei3+18.net] >>696 interfaceにデフォルト実装を後から入れたので問題なくなった そうなるとclass継承は不要 711 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 09:55:41.24 ID:YlYBNC7y.net] 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから 今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって 後から○○無くせばよかったと言うのは誤りで浅はか NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ 712 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 10:21:05.77 ID:pgei3+18.net] 今となってはclass継承は廃止でいい 713 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 11:59:36.87 ID:NkOUpCFP.net] インターフェイスにも集合で言うところの外延性は欲しいところ。 714 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 13:49:22.28 ID:DzgCvS5T.net] そういうの使いたいならTSがいいよ 715 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 14:56:34.55 ID:vP0l1V0c.net] 具体的なデメリットって何なの？ 716 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 15:29:25.10 ID:ePcpSD5e.net] ダサい 717 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 20:45:11.55 ID:scEyspJl.net] そういう感覚的なもの？ 718 名前：デフォルトの名無しさん mailto:sage [2024/04/16(火) 22:20:54.32 ID:pbIQ4i0L.net] 基底クラスで保証してる内部条件を継承クラスで壊されやすい Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う 古い知識だから最近の動向は知らない 719 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 08:15:23.25 ID:eua5YI/M.net] Unreal EngineがRist対応するんだってね 720 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 16:42:11.69 ID:eua5YI/M.net] Ristってなんだ、Rustだた 721 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 21:06:33.89 ID:ZcFRYo3q.net] Rast Rist Rest Rost 722 名前：デフォルトの名無しさん mailto:sage [2024/04/17(水) 21:31:42.40 ID:O0zLY4aF.net] Risp 723 名前：デフォルトの名無しさん mailto:sage [2024/04/18(木) 23:48:18.11 ID:mul2o/Jt.net] >>706 時代の流れだな 724 名前：デフォルトの名無しさん [2024/04/19(金) 17:19:41.25 ID:QdSz4ItG.net] 隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん 725 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 17:39:26.03 ID:pCmD4UWo.net] shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない 全部読んでデコードして\nで切り分けるしかないの？ 726 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 17:53:01.46 ID:AAPU1iqE.net] read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう 727 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 22:11:31.95 ID:pZNdwQSZ.net] >>712 encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る あとはreader.lines()で同じ 728 名前：デフォルトの名無しさん mailto:sage [2024/04/20(土) 22:28:20.55 ID:pZNdwQSZ.net] std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines() 729 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 07:15:48.69 ID:QKVewSeW.net] BufReaderもFile::openもそのまま使える点がいいね 730 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 10:23:00.52 ID:Be3/0qjS.net] >>715 ありがとうございます 動作確認しました ちょっと仕組みがむずかしいですね 731 名前：デフォルトの名無しさん mailto:sage [2024/04/21(日) 18:25:05.39 ID:GAd5jyBU.net] decoderが挟まるだけだよ // UTF8の場合 let file = File::open(path)?; let reader = BufReader::new(file); for line in reader.lines() { // SJISの場合 let file = File::open(path)?; let decoder = DecodeReaderBytesBuilder::new() 　.encoding(Some(SHIFT_JIS)) 　.build(file); let reader = BufReader::new(decoder); for line in reader.lines() { 732 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 06:09:19.12 ID:kZ9sSSe5.net] バッファリングせず丸ごと贅沢にメモリ使っていいなら単純 let bytes = fs::read(path)?; let (s, _, _) = SHIFT_JIS.decode(&bytes); let reader = BufReader::new(s.as_bytes()); for line in reader.lines() { 733 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 20:07:02.52 ID:g+YSHIF5.net] コマンドラインからファイル名取るようにしたらパニック windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい 734 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 20:46:10.62 ID:ZfX6SpnE.net] 何を言ってんのw 735 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 21:19:42.71 ID:g+YSHIF5.net] 知らないとそういう反応するんだろうけど std::env::args_osを使ってOsStringを取って対処する必要があるんだよ 勉強になっただろ？ 736 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 21:24:48.26 ID:g+YSHIF5.net] 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている 737 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:12:07.98 ID:ljq3CdpU.net] >>722 チュートリアルレベルの基礎を バッドノウハウwとか 積み重ねでいかないといけないwとか 言ってるから何言ってんのwになる 738 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:32:38.83 ID:cr/ZTax6.net] >>720 Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる まずは基礎知識を身につけよう >>722 std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある さらに対処方法はargs_osを使えと明記されている ドキュメントを見よう 739 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:35:51.77 ID:g+YSHIF5.net] >>724-725 こういう低能がありがたがるんだろうな 信者としか言いようがないｗ 740 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:42:55.88 ID:g+YSHIF5.net] リリースした後の実行時のpanicを有り難がる信者 Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本 741 名前：デフォルトの名無しさん mailto:sage [2024/04/22(月) 23:57:01.81 ID:kZ9sSSe5.net] >>722 Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから その関数のドキュメントのpanicの項目を見れば明記されてる 他の言語と比べても良い環境 742 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:03:29.34 ID:aheV4X/O.net] 馬鹿と話しててもらちが開かない 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実 お前らそれを一個一個プルリク送ったりしてるのか？ 743 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:13:45.98 ID:aheV4X/O.net] 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ 世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる 非合理的 744 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 00:34:48.42 ID:tNw43TTr.net] そんなことより The Embedded Rust 読み始めたんです。 冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね？と言わんばかりの内容。 おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。 745 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 09:44:34.04 ID:SlAsUTut.net] 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す ヤバすぎね？ 746 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 11:06:58.83 ID:PMnHeW+x.net] >>725 なんでコンパイル時にエラーにできないんだろう？ Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは？ c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。 747 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:06:18.33 ID:cfnwg7MD.net] panicは安全ですヨ 748 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:11:09.83 ID:r76fNggU.net] >>734 緊急停止して「安全ですよ」はちょっと…… 749 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 12:14:00.43 ID:jXQ0V2HY.net] >>733 セキュリティホールにならない 異常データに対して止まり動作を続けない 750 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 15:43:54.29 ID:3Xc7JqWG.net] >>733 >なんでコンパイル時にエラーにできないんだろう？ 出来るわけないだろw 実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw バカすぎる 751 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 16:19:44.91 ID:1rwyWp7B.net] しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス もう治る見込みはないからargs_os()を使おうねってだけだけど 752 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 16:52:58.90 ID:Kbb8det7.net] 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど 特に提案もなさそうだし誰も困ってないんじゃないかな そもそもほとんどのケースでclapとか使うだろうし 753 名前：デフォルトの名無しさん [2024/04/23(火) 17:20:16.94 ID:jbFpiEtG.net] >>733 ＞>>725 ＞なんでコンパイル時にエラーにできないんだろう？ むしろ何でできると思ってるんだろう。謎 754 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 17:22:13.22 ID:SM3r9/qB.net] 環境変数もvarとvar_osがあるから慣れろとしか言えない OS標準が全部utf-8になる未来もありえるし 755 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 17:48:20.12 ID:x1LuxzDZ.net] >>741 紛らわしいけどvar/var_osとvars/vars_osは別物だよ varはinvalid UTF-8でもエラーハンドリング可 varsはpanic argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど varsはそんな前提をおける状況はほぼなくてよりたちが悪い 756 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 18:06:35.01 ID:DF4k8ks3.net] >>741 >OS標準が全部utf-8になる未来もありえるし 10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない もう10年経ったとしても状況は変わらないと思う 757 名前：デフォルトの名無しさん [2024/04/23(火) 19:06:07.68 ID:rRGY+2Qg.net] >>732 公式チュートリアルまともに読めるならC++で良いからな 758 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 20:01:34.96 ID:+uJAOtCC.net] よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？ どう考えてもstd::env::argsを非推奨にしろとは思うけどね 欧米人がつくるとこんなことになるんだ 普通は2種類の扱いがある ・実行環境に合わせて自動的に内部での標準形式に変換 か ・何もしない 何もしないならOSから受け取ったままOSに渡して置けば大体問題はない 第三の愚策がRust 受け取ったままそのままOSに渡してもコケる Rustは何もしないように見えるけど何かしてるからコケるのでは？ 759 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 20:52:29.82 ID:xiHKhQOf.net] >>745 間違いだらけだな 世界の標準はUTF8 ウェブももちろんUTF8 RustもUTF8 Rustがこの件でコケることはない きちんと各関数の仕様が明記されていて常に正確に動作している 760 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 21:05:41.35 ID:ykVY4Q8s.net] Rustのパニックは綺麗なパニック いいね？ 761 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 21:12:51.81 ID:xiHKhQOf.net] >>747 一般的なパニックは色んな意味合いがあるけど Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる 762 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 23:35:29.98 ID:v0qt2UCV.net] >>745 勘違いしてることが多すぎてもう笑うしかないwww 763 名前：デフォルトの名無しさん mailto:sage [2024/04/23(火) 23:41:39.78 ID:x1LuxzDZ.net] >>745 >よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？ 30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな？ (UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど) ↓これが15年くらい前のUTF-16に対する一般的な認識 https://softwareengineering.stackexchange.com/questions/102205/ 764 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 00:43:41.33 ID:5EZEwmZn.net] utf-16はUnicode 2.0（1996年7月）のサ 765 名前：ロゲートペア導入でutf-8に逆転されたな しばらくはBMPしか使われなかったから耐えてたけど 1990代前半に始動したJavaは運が悪かった [] [ここ壊れてます] 766 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 01:21:01.63 ID:YBOQY0J9.net] >>749 そう書きながら何もまともなレスすらできないレス乞食 767 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 01:23:24.26 ID:YBOQY0J9.net] Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど Rustが正しいRustが正しいと繰り返すばかり 768 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:36:38.15 ID:A+y4lqIx.net] >>737 >>740 windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。 そもそもargは廃止していい。 769 名前：デフォルトの名無しさん [2024/04/24(水) 12:47:56.41 ID:HIQuAly7.net] すげーどうでもいい話だな 770 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:47:57.96 ID:A+y4lqIx.net] >>746 なるほど。 「RustはWindowsをケアする気が無い」 ということですか。 771 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 12:58:45.05 ID:GRRi3Rgr.net] >>754 Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能 まぁ廃止していいには同意するけども 772 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 13:18:14.84 ID:meF6WBmz.net] Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。 今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。 保証としてはあてにならん。 773 名前：デフォルトの名無しさん [2024/04/24(水) 13:18:30.26 ID:HIQuAly7.net] コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。 774 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 14:25:14.78 ID:up+AoO7k.net] >>754 無知にもほどがある！ unicodeとUTF-8が区別できない Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない 775 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 15:25:54.44 ID:65hs2nTl.net] >>760 そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。 Rustはメモリ安全しか興味無いんかね。 776 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 15:53:48.65 ID:gLaneKFw.net] 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。 777 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:02:42.64 ID:zvblwt+/.net] どうでもいい話でもめてるな Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題 こちらはUTF8環境でしか使われないのでargs()のみ利用している 778 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:05:40.76 ID:AQu1Dr63.net] https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905 関係する議論はこのあたりかな もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが 無視や置換はセキュリティ上問題になる可能性があるので却下 varsは将来的にdeprecatedにするかもと言っている なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね 779 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:26:19.27 ID:MMJHgfnp.net] 正しく使え論は暴論だな それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる 780 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:40:56.16 ID:zvblwt+/.net] >>765 生ポインタは安全ではないから全く違う argsは常に安全 781 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 16:44:59.20 ID:MMJHgfnp.net] 常に自動変換したほうが安全だけどな 開発者が特別コードを書く必要もない 782 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:05:56.77 ID:MMdiZvh6.net] Rustはファイル名も自動変換なんかしていないように 変換するかどうかは各自の自由裁量であるところが非常に良い点だよ 自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど 783 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:17:38.15 ID:MMJHgfnp.net] >>768 ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい 784 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:21:01.52 ID:MMJHgfnp.net] ファイルの引数だけ標準では何もしない 普通のキーボード入力などでは変換している 785 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 17:23:28.05 ID:D1bqYp6J.net] >>770 え？？ 786 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 18:26:14.33 ID:AQu1Dr63.net] >>768 自動変換は正直意味不明だが（変換元の文字コードが判定不能なのに何を変換するのか？） argsは今RFC出したらResultにしろって突っ込まれると思うし 1.0であまり深く考えずに入れちゃった気はするよ 787 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 18:50:02.66 ID:5HDpMmrb.net] Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う argsじゃなくてargs_utf8onlyとか名前をダサくして 逆にargs_osを元のargsに戻しとけば リファレンスをよく読まない人たちがつまづく可能性を下げられる 788 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:00:18.55 ID:65hs2nTl.net] こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。 Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。 789 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:01:34.27 ID:MMJHgfnp.net] >>772 自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない 790 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:14:39.18 ID:9A8KMAyG.net] 自動変換とかそんなアホなこと言ってるのはあんただけやで そんなものは無いし必要ない 791 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:18:07.57 ID:MMJHgfnp.net] こいつOsStringの概念が分かってないのか 本当に知能レベルが低すぎる 792 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:45:20.62 ID:AQu1Dr63.net] OsStringはOSから渡されたバイト列をそのまま格納するだけで EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが… 793 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:49:39.48 ID:MMJHgfnp.net] 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる 結局内部で使う場合は簡単にutf8に変換してる なにからutf8に変化するか指示も必要がない ただのボイラープレート 794 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 19:58:53.67 ID:ArOBrbBE.net] >>777 自動変換なんてものはない むしろ自動変換を避けるために用意されているのがOsString もちろん自動変換は行われない 795 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:02:00.63 ID:MMJHgfnp.net] 人間じゃなくて壊れたロボットに話しているようだな いくつになろうとこんなダメな人間になってはいけないな 796 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:16:20.94 ID:il94IOIF.net] ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって どんなエンコーディングの文字列でも統一的に扱うことができましゅ Rustもまだまだでしゅね 797 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 20:44:42.25 ID:xJ62MSkB.net] ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある 798 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 21:30:38.14 ID:nN1vQ+Ae.net] 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。 799 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 21:49:41.83 ID:tlaf0qkO.net] めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？ 複オジは昔の自分を諭してる気分じゃないか？ 800 名前：デフォルトの名無しさん mailto:sage [2024/04/24(水) 22:41:53. ] [ここ壊れてます] 801 名前：26 ID:MMJHgfnp.net mailto: Rustが正しいの一点張りの狂人 [] [ここ壊れてます] 802 名前：デフォルトの名無しさん [2024/04/25(木) 01:24:12.71 ID:fpMjozoS.net] >>0774 お前の着眼点は凄えよ！感動した。 その通り、Rustは初心者/素人 御用達言語だよ。 803 名前：デフォルトの名無しさん mailto:sage [2024/04/25(木) 07:30:11.27 ID:xsazBswH.net] おじいちゃん誰にも相手にされず寂しくなったんだねw 804 名前：デフォルトの名無しさん [2024/04/27(土) 03:20:12.65 ID:nhA0znD3.net] 聞き分けることができない。 https://kanji.reader.bz/pronunciations/last,lust,rust 805 名前：デフォルトの名無しさん [2024/04/27(土) 21:28:13.67 ID:+PotGQRe.net] crates.io が死んだときはどうすれば良い？ 806 名前：デフォルトの名無しさん mailto:sage [2024/04/27(土) 21:31:55.69 ID:Ik8q0/YE.net] cargo run --offline 807 名前：デフォルトの名無しさん mailto:sage [2024/04/28(日) 09:02:55.08 ID:nHdP2D/h.net] ミラーサイトとか無いんだっけ？ 808 名前：デフォルトの名無しさん [2024/04/29(月) 14:17:37.62 ID:wZNa4EA4.net] 5chが荒らされてる時はどうすれば良い？ 809 名前：デフォルトの名無しさん [2024/04/29(月) 16:10:30.59 ID:E9KMHG2x.net] 取り敢えずアゲとけばいいんじゃね？ 810 名前：デフォルトの名無しさん mailto:sage [2024/04/30(火) 02:47:45.81 ID:Mf3BeDX5.net] したらば掲示板あたりに避難所作っておけばいかが 811 名前：デフォルトの名無しさん [2024/04/30(火) 03:09:09.37 ID:LM/x1iE2.net] 落ち着いてpanicしよう 812 名前：デフォルトの名無しさん mailto:sage [2024/04/30(火) 07:30:51.55 ID:QURaxzoQ.net] core吐きそう 813 名前：デフォルトの名無しさん mailto:sage [2024/05/01(水) 23:17:38.38 ID:7162bhB/.net] python みたいに何でも格納できる辞書型ってC++には無いよね？ 814 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 02:40:57.58 ID:VpjL2uZS.net] enumも弱いなあ 815 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 18:14:15.88 ID:MEkFc6Ha.net] anyとmap組み合わせればいいんじゃね？ ここRustスレだけど 816 名前：デフォルトの名無しさん mailto:sage [2024/05/02(木) 20:59:19.04 ID:AhHSwsoc.net] Rustで辞書型はHashMap 複数の型を格納したかったらenumかdyn Trait TraitをAnyにするならdowncastして使う 実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む 817 名前：デフォルトの名無しさん mailto:sage [2024/05/03(金) 11:35:32.62 ID:nLK8l4in.net] pythonみたいにだからclassがわりなのかも p["name"]="yamada taro"; p["age"]=25; みたいなのかな いずれにしてもC++じゃないので 818 名前：デフォルトの名無しさん mailto:sage [2024/05/03(金) 23:02:14.16 ID:NBKkZegt.net] 静的型付けの有用性が大きく上回るから そのケースならstructにするだろうし 色んな型を横断的に扱いたいケースならtraitかな 819 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 04:23:28.64 ID:hKZu/p+3.net] https://pbs.twimg.com/media/GLs31gXbYAA6xIr.jpg 820 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 09:38:11.89 ID:dspjTuTH.net] GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？ 821 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 12:00:07.75 ID:GFUvMaSe.net] tauri? 822 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 12:04:17.00 ID:WHGnbjEl.net] UIはもうネイティブにこだわらなくてもいいんじゃないかな 昔からwebでしかUI提供してないソフトはゴロゴロある 823 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 15:02:31.51 ID:UtcYFhat.net] 用途次第 WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある 824 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 15:44:19.83 ID:oqQ8V/k0.net] Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽…… みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。 そもそもウェブの世界は変遷が激しい。 Living Standard ってなんやねん。 普通の産業の感覚では信じられんようなことをしやがる。 元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。 ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。 825 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:01:23.73 ID:WHGnbjEl.net] 即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって そうでない場合は普通にhtmlで 826 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:07:02.02 ID:lP1zz7vp.net] 実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい 常駐の軽いアプリを作りたい場合なんかは特に 827 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:07:49.70 ID:oqQ8V/k0.net] UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。 元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。 ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。 828 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:17:08.35 ID:5ROxz5B4.net] UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ MFCやCocoaやGTK的なものが今では逆に「普通」ではない 829 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:22:01.06 ID:WHGnbjEl.net] html5は死んだ もうどこにも存在しない 830 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:22:16.16 ID:oqQ8V/k0.net] >>813 宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。 これが良いとか悪いとか言ってるわけではないよ。 まず第一に選ぶべき「普通」だとする論を否定してる。 831 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 16:58:29.96 ID:uscJJ1KS.net] じゃあslint? 832 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 18:05:18.74 ID:uscJJ1KS.net] 何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな… tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった 833 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 18:12:14.00 ID:WHGnbjEl.net] デスクトップアプリのここにグラフ出してくださいって言われて 対応できる環境は少ない 834 名前：デフォルトの名無しさん [2024/05/04(土) 19:49:33.93 ID:kEH6RwVz.net] 他にいい表現方法があるなら自分で作って使ってりゃいいじゃん 835 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 21:10:45.57 ID:D/qKI/dJ.net] dioxusはあんま使われてない感じ？ 836 名前：デフォルトの名無しさん mailto:sage [2024/05/04(土) 23:00:15.61 ID:ycOsd5I6.net] iced.rs 837 名前：デフォルトの名無しさん [2024/05/05(日) 10:17:39.98 ID:k5d9I+SK.net] >>821 Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね 838 名前：デフォルトの名無しさん mailto:sage [2024/05/05(日) 18:52:14.60 ID:k5d9I+SK.net] 試してみたけど導入のカウンタの例がいきなりビルド出来ない… バージョンの変更にドキュメントが追いついていないのは残念ですね… 839 名前：デフォルトの名無しさん mailto:sage [2024/05/05(日) 23:14:06.38 ID:XwodnLf4.net] freyaはどう？ 840 名前：デフォルトの名無しさん mailto:sage [2024/05/09(木) 16:51:54.63 ID:7kteiv59.net] https://blog.logrocket.com/state-rust-gui-libraries/ 841 名前：デフォルトの名無しさん mailto:sage [2024/05/09(木) 22:53:04.47 ID:mHp10mC4.net] 一覧 https://lib.rs/keywords/cross-platform-gui 842 名前：デフォルトの名無しさん mailto:sage [2024/05/10(金) 22:11:46.56 ID:R/1AnZ57.net] Edera 843 名前：デフォルトの名無しさん [2024/05/11(土) 15:19:35.98 ID:7ZNhzC0A.net] https://loglog.games/blog/leaving-rust-gamedev/ Rustはゲーム開発に向いてないという記事 C/C++を置き換えるという目標がまた一つ遠のいてしまったな 844 名前：デフォルトの名無しさん [2024/05/11(土) 16:10:55.98 ID:cPH9qnwk.net] Rust製ゲームエンジンが未成熟なんだから当たり前だろ😅 845 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 17:53:51.16 ID:PRiIqFBU.net] Web開発は素早い実装と更新が必要だから Rustは向いてない動的型言語が向いてる みたいな記事は昔あった気がする 846 名前：デフォルトの名無しさん mailto:sage [2024/05/11(土) 18:07:19.67 ID:YXABt1rM.net] >>828 ＞Rustが上手くなれば、これらの問題はすべて解消されます。 ＞Rustは大規模なリファクタリングに優れているため、 ＞borrowチェッカーのほとんどが自業自得の問題を解決します。 ＞十分な経験を積めば、ユーザーは考えずにそれらを完全に予測し、生産的になります。 ＞私はRustでさまざまなユーティリティやCLIツールを書くのをとても楽しんでいますが、 ＞数行のコード以外はPythonよりも生産性が高いことがわかりました。 ＞「コンパイラ駆動開発」をどこまで進めて、実際に成功できるのかと驚いたことが何度もあります。 ＞Rustの最大の強みは、Rustにふさわしいコードを書いていると、物事が非常にうまくいき、 ＞言語がユーザーを正しい道に導いてくれることです。 847 名前：デフォルトの名無しさん [2024/05/11(土) 19:27:53.90 ID:3IwrsNfE.net] >>828 この記事、ゲーム開発においていかにUnityがすばらしいかを伝えたいだけじゃん 848 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 06:43:20.67 ID:k1k0SaOB.net] >>831 エキスパート専用、初心者お断り というRustのいつもの欠点。 849 名前：デフォルトの名無しさん [2024/05/12(日) 11:56:37.24 ID:WctoPZ5N.net] ずいぶん過疎ってるけどどんぐりのせいなんかね？ 850 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 12:01:04.30 ID:ReOJFzuL.net] c++を完璧に使いこなせばrustは不要とか いうのは欠点ではないの？ 851 名前：デフォルトの名無しさん [2024/05/12(日) 12:04:43.22 ID:qXz8Kn6F.net] それは本人の練度の問題やんけ 852 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 12:33:17.76 ID:ybg7kEk2.net] >>835 政府レベルで脱C/C++推奨してるのよ ソース記事>>500 853 名前：デフォルトの名無しさん [2024/05/12(日) 13:10:14.91 ID:ytouLwn1.net] 政府のお墨付きは強いカードだ 854 名前： 警備員[Lv.1][新初] mailto:sage [2024/05/12(日) 15:34:04.32 ID:bb5m7yXX.net] 書き込めない 855 名前：デフォルトの名無しさん [2024/05/12(日) 17:53:27.59 ID:YZSMKp1R.net] tauriがだいぶ普及してrustに手を出す人が増えたね いい傾向だ 856 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 23:38:46.27 ID:dSHQVPuW.net] Tauriで流入した人の多くはフロント側 (JavaScript, TypeScript) の技術者な気がする 「ほぼRust書かずにTypeScriptでできますれ」みたいな言説も見かけるくらいだし 実際そのアプローチはありだろうしRustの認知度にも寄与するだろうけど、純Rustのフレームワークも成熟して欲しいところ 857 名前：デフォルトの名無しさん mailto:sage [2024/05/12(日) 23:46:56.69 ID:y8qBeNSM.net] ガワをRustで書いただけで何が嬉しいことでもあるんか？ 私はRust使ってますって言えるから？ 858 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 00:38:30.52 ID:DdLtk1MY.net] 繰り返しになるが GUI 記述として html ベース、ウェブベースの制御はそんなに筋が良くない。 根本的に GUI に対する要求が複雑だから万能を目指したフレームワークはだいたいそうなるものではあるんだが 逆に言えば万能でなくてよいときに使うにはウェブウィジットはリッチすぎる。 それとウェブ世界の living standard という体制に不信感がある。 ウェブ世界ではそれで良いにしてもどこでもその考え方が通用するわけではない。 859 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:02:04.61 ID:TEcr6tUj.net] >>843 抽象的な欠点あげつらうのは役に立たないんで 今普及してるguiツールキットでおすすめと その理由は？ 860 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:21:51.83 ID:DdLtk1MY.net] >>844 Tauri がウェブフレームワークに依存しているのが悪いというのは具体的ではないんか？ それが良い場合もあるので何が良いかは結局のところ場合によるとしか言えない。 そりゃそうだろ。 ウェブフレームワークを活用できることとウェブフレームワークに縛られることは表裏一体で 活用しつつ欠点から逃れるなんていう都合の良い話はないというごく普通のことを言いたいだけ。 861 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 02:31:51.65 ID:TEcr6tUj.net] >>845 ウェブguiの欠点が全く具体的じゃないし 場合によるというなら役に立つ場合に使えばいいよね で話はおしまいなんで何も役に立たない 話だね 862 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:08:04.24 ID:DdLtk1MY.net] >>846 ウェブフレームワークの欠点なんかいまさら説明せなあかんようなこと？ 役に立つ場合には使えばいいってのは当然の大前提で、 話題の流れとしては >>842 に対して「全ての」場合に Tauri がマッチするわけない (ので色々な選択肢が出てくるに越したことは無い) って話じゃん。 これから生まれる (生まれていない) 色々なプロジェクトのどれがどういう状況で役立つかなんか事前にわかったら苦労はないわ。 色々出て来て色々消えるのも当然のことで、 Rust スレなんだから純 Rust で出来るものも有って欲しいという期待は自然なものだろ。 863 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:11:17.53 ID:7xLbVW9j.net] QtレベルのフレームワークがRustで書けるならそれは嬉しいけどね 開発者のモチベが続かないような気がする あまりにもゼロから実装しなきゃならんし 864 名前：デフォルトの名無しさん [2024/05/13(月) 03:11:29.07 ID:To2vSRYZ.net] デザイン系の人の大多数がウェブアプリ開発をできるからTauriは高需要でいいと思う そもTauriはRustが主役のフレームワークじゃないんだからあーだこーだ言う必要なし 世間の知名度が上がる道具になってくれれば十分ってもんよ 865 名前：デフォルトの名無しさん [2024/05/13(月) 03:17:53.91 ID:+k5+3Net.net] デスクトップアプリ自体需要低下が著しいわけで、いまさら新しいGUIフレームワーク作りましたって誰も使わんわ WPFすら将来性が怪しまれてるのに 866 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:26:50.43 ID:7xLbVW9j.net] ちなみに全てゼロから実装してるGoのGUIフレームワークのgokiは6年以上開発しててまだ完成しない 描画から全部作ってる そしてついに開発者が飽きた 同じくgoのfyneも5年ぐらい開発してこちらもOpenGLでゴリゴリやってるようだが すでにOpenGLは時代遅れだし すでに開発者が飽き気味 867 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 03:46:12.80 ID:FJrB7Dif.net] ウェブまわり自体がクソってのには賛同するけど、これまでの莫大な資産や個々の経験の後押しが需要を押し上げるんだから仕方ない どれだけRust由来のGUIフレームワークを望んだとしても負ける未来しかないんだ WPFもWinUI3もFlutterもComposeも頑張ってるけど勝てないんだ 868 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 06:53:31.41 ID:NqUrzczE.net] >>825 Rust GUI framework performance comparison lukaskalbertodt.github.io/2023/02/03/tauri-iced-egui-performance-comparison.html 869 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 08:41:01.54 ID:1UkfuR6U.net] 可能性があるとすると組み込み系かなぁ 車載GUIにUnityとか検討してるとこはあるみたいだけど、多少描画がバグってもいいゲームとは違うし Rustの安定性が求められる領域ではあると思う slintなんかはそちらを目指しているように見える 870 名前：デフォルトの名無しさん [2024/05/13(月) 10:36:48.17 ID:gtcOXaAe.net] フロントについてこういうカッチかちの言語でうまくと思ってるやつは実際にコード書いてないのがバレバレだよ 871 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 11:03:56.17 ID:TEcr6tUj.net] >>847 こういうアプリ作りたいならウェブ技術・ tauriは論外くらい言ってくれよ 872 名前：デフォルトの名無しさん [2024/05/13(月) 11:12:58.92 ID:2BkgcWoG.net] >>848 QtのRustバインディングがもっと進歩すればなあ。 JS系はreact圧倒的に強いからQMLなんて絶対流行らんだろうに 873 名前：デフォルトの名無しさん [2024/05/13(月) 11:14:38.81 ID:BwU1QaNs.net] RustのGUIフレームワークを気になって色々見てたけどどれもよくあるレンダリングエンジンのWebGPU、Vulkan、OpenGL、SkiaをRustラップしてるだけじゃんね 純粋なRust製レンダリングエンジンはどこだよ 874 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 12:01:14.07 ID:7xLbVW9j.net] >>858 今時自前で描画なんてやる訳ないだろ なんのためにGPUがあるんだ 875 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 12:47:01.47 ID:nhWWGTo5.net] WebGPUの参照実装であるwgpuは純Rust製だと思ってるけど違うんかね？ 876 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 13:02:11.22 ID:LO420and.net] >>858 少なくともOpenGLとVulkanはグラフィックAPIなんだからラップするのは普通でしょ 877 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 15:33:49.11 ID:Y2zR27Yz.net] tauriはロジック部分をrustで書きやすいんでしょ？理想的じゃないか フロントとバックで得意分野の棲み分けができてて賢いフレームワーク 878 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 16:08:29.50 ID:DdLtk1MY.net] だから Tauri が悪いという論じゃないんだ。 他の選択肢がいっぱいあると嬉しいねって話なんだってば。 879 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 21:28:07.97 ID:59wZgx8n.net] 神学論争じゃなくてエンジニアリングとして tauriではこんなアプリ作るべきじゃない 理由はこんな欠点があるからという 話してくれれば良いだけなんだが 880 名前：デフォルトの名無しさん mailto:sage [2024/05/13(月) 22:14:06.95 ID:ZPj3lkv2.net] GUIといっても多種多様に分かれて共存しておりRustでも色々なライブラリがある slintのように軽量重視もあれば eguiのように(一般的な保持モードとは異なり)即時モード採用もあったり tauriのようにWebと同じ枠組みを使うことで同じ知識の活用とWebアプリとの共通化をはかるものもあり 他にも様々なものがある 前提環境抜きで特定のものを批判してる人はおかしい 881 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 07:45:48.78 ID:6cY0CvIK.net] みんな違ってみんな良い 882 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 08:57:53.35 ID:xCwyd0xz.net] slintは素直でとっつきやすかったな icedは変化が激しいのか入門もさせてもらえない… 883 名前：デフォルトの名無しさん mailto:sage [2024/05/14(火) 23:21:46.80 ID:hA3mS4wv.net] LambdaはRustで書くのが定番になってきたな 884 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 00:25:29.32 ID:pg7m6itF.net] 何より悲しい一人ランバダ 885 名前：デフォルトの名無しさん [2024/05/15(水) 04:42:11.15 ID:NcaIPB0V.net] わしウェブ系技術ってのが嫌いやねん 886 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 06:07:55.49 ID:HCR4HRqT.net] 具体的に指摘できない人は単なる無知か落ちこぼ� 887 名前：� [] [ここ壊れてます] 888 名前：デフォルトの名無しさん [2024/05/15(水) 09:47:09.65 ID:qxOWZ5PZ.net] tauriは叩く要素が特にない electronのデメリットを克服しつつも既存の普及済み技術を集合させた感じなんだもの tauri導入における敷居の低さはあっぱれとしか言いようがない ウェブ技術やってない人はこれを機会にreactを勉強したらいいよ 889 名前：デフォルトの名無しさん [2024/05/15(水) 11:23:11.20 ID:z848GXEz.net] なんかもう面倒臭いしバックエンドもnode.jsでいい気がしてきた 890 名前：デフォルトの名無しさん [2024/05/15(水) 14:38:34.92 ID:h8Rmia3E.net] 結局最初はrailsでokみたいなのが最近の流れでしょ。 そこから開発規模に沿ってどう分割していくかってのが最近のテーマではあると思うけど。 最初からかっちり開発しましょうなんて20年前のお花畑理論でしかないわな。 891 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 15:28:41.91 ID:aizlqnqQ.net] ネイティブGUIアプリの話にRails関係ないだろ Web開発でもとりあえずRailsのピークは過ぎ去ってるぞ 892 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 15:31:56.50 ID:5ypavdrK.net] tauriはデータの受け渡しが遅すぎる 893 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:29:56.86 ID:0QhUyids.net] モダンなGUIアーキテクチャでRust書きたいよ 今のは全部古すぎる 894 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:33:24.96 ID:V9iVMFnF.net] >>875 ネイティブGUIアプリじゃなくてデスクトップGUIアプリやろ まさかTauriはネイティブ扱いとか言わんよな？ 895 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:39:14.07 ID:aizlqnqQ.net] >>878 何言ってるのか意味わからんので あなたのネイティブGUIアプリと デスクトップGUIアプリの定義と その違いを説明してくれ 896 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 16:42:32.92 ID:0QhUyids.net] デスクトップGUIはWebViewを使ったガワアプリも含まれるって意味だろ 897 名前：デフォルトの名無しさん [2024/05/15(水) 17:30:27.13 ID:hv8buZEp.net] めんどくさいからデスクトップアプリでいいよ 898 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 18:24:29.03 ID:xsUSdCEo.net] >>879 一般的にネイティブアプリとは各プラットフォームでネイティブとされてるUIコンポーネントや開発ツールを使って作られたもの デスクトップアプリはWindows・macOS・Linuxなどのデスクトッププラットフォーム上で実行されるアプリ (どちらも基本的にGUIアプリについてのみ使われる言葉) 例えばJavaで作ったデスクトップアプリは一般的にネイティブアプリとは呼ばれないが Java(とJetpack Compose)で作ったAndroidアプリはネイティブアプリと呼ばれる 899 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 18:30:24.12 ID:4Z0tBK25.net] Visual Studio Codeはネイティブアプリですか？ 900 名前：デフォルトの名無しさん [2024/05/15(水) 18:35:01.39 ID:NOtrSmJC.net] >>883 ガワアプリです 901 名前：デフォルトの名無しさん [2024/05/15(水) 19:01:08.64 ID:xxmBp0ld.net] tauriはフロント側をrustで書けないのがきつい yewとかで頑張ればrustでやれなくはないけど素直にjs使った方がいいし 902 名前：デフォルトの名無しさん [2024/05/15(水) 19:44:27.90 ID:bSYaxLzm.net] フロントは成熟したフレームワークを使いたいからhtmljs仕様なのはむしろ助かることない？ 903 名前：デフォルトの名無しさん [2024/05/15(水) 19:49:50.25 ID:rWGs03Ps.net] TauriはOS付属のWebViewを下地にして動くことを売りにしてるんだからRustでフロント書きたい人は最初からお客様じゃないぞ 本気でYewでひーひー言いながら書くつもりか？ 904 名前：デフォルトの名無しさん mailto:sage [2024/05/15(水) 23:50:43.95 ID:s3H9dEcY.net] フロントエンドをHTML/CSS/JavaScript以外で書く人がもうほとんどいない ただしJavaScriptを直接書かなくてもWebAssemblyで好きな言語で書くのは構わないし同じWeb枠組みの範囲内の話 905 名前：デフォルトの名無しさん [2024/05/16(木) 00:16:06.21 ID:1J3uYj1b.net] >>888 結局これだよな。JS以外のクロスプラットフォームなフロントエンドってほとんど無いんだからそこはもう諦めたほうが 906 名前：デフォルトの名無しさん [2024/05/16(木) 00:39:52.36 ID:OUQcYMxX.net] そもそもrust推すやつはフロントエンドなんて全く好きじゃないだろ。 907 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 00:53:56.65 ID:hXehBl/a.net] フロントエンドだけでは何もできなくて バックエンドや裏はRust採用がリソースコストを最小にできる そのためのクラウドでのコードもクラウドインフラ自体もRustで記述 さらにCDNインフラ自体もCDNエッジでのコードもRustで記述 908 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 01:44:19.55 ID:i/RRcUKc.net] >>872 何にしたって否応なくトレードオフはある。 Electoron のデメリットを克服したといっても その替わりに Electoron に無かったデメリットも生じてる。 たとえば WebView を抱え込まない (実行環境にあるのを使う) のは 実行環境のエコシステムとの連携が必須ってことだ。 基本的にはちゃんとサポートが続いているバージョンの実行環境を使えって話ではあるけどさ、 そうもいかんこともあるのも現実なんよ。 Tauri を叩いてるやつなんていないよ。 まさか「あらゆる」 UI を Tauri でなんとかできると思ってるわけじゃないだろ？ という話。 比較的には有力とは言えるだろうけども。 909 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 01:56:21.83 ID:g8xzkHEo.net] 仮想のtauri狂信者を叩いてるのが一人いるのはわかった 910 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 02:15:18.77 ID:8s3HDjEn.net] そんなに熱くならんでも良い Tauriガワ＋Rustビジネスロジックな本格的定番デスクトップアプリが 未だに存在しないから察しろ 911 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 15:17:12.19 ID:DDVd9f//.net] 察しろって歴史が浅いだけでは 912 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 18:07:35.69 ID:2492rnzS.net] >>891 そこまで行くのに何十年掛かるんだろうなぁ 913 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 18:37:15.15 ID:hXehBl/a.net] >>896 既にRustで記述されているという現在の話だぞ Rustで記述されているソース記事は>>51 914 名前：デフォルトの名無しさん [2024/05/16(木) 23:54:35.57 ID:4W8w/h2s.net] 何十年かかろうがRustが普及するのは事実 乗り遅れるなよ？ 915 名前：デフォルトの名無しさん mailto:sage [2024/05/16(木) 23:57:43.65 ID:sN6tl8jZ.net] 既にそれらクラウドやCDNのインフラはRust製へ切り替わっていってるし その上で動くユーザーコードも従量制コストのためRustが採用されてるね 916 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 00:37:51.70 ID:lOJfePdD.net] Rust2024次第や 917 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 14:37:51.89 ID:R46RaGVX.net] >>898 そうやって何十年騙されてきたんだろう 918 名前：デフォルトの名無しさん [2024/05/17(金) 17:27:00.95 ID:fyAXY6lw.net] Rustって、学習コストていうか、習得難易度が高いらしいね 919 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 18:13:44.03 ID:63RUfPPA.net] 本来ちゃんと考えなきゃいけないものをランタイムがやってくれるからって 思考放棄してた部分が表に出てきただけなんだよね 例えば優秀な人はCでもポインタ一つとってもその意味するところが何か、所有するのか、弱参照なのかを意識するし オブジェクトの管理に参照カウントを実装しているだろう 実際至高のCプログラムであるlinuxカーネルはそのような作りになっている 優秀な人は凡人に見えていないものが見えてるんだよね 920 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 18:50:38.58 ID:x3ZQoGKy.net] >>903 >実際至高のCプログラムであるlinuxカーネルはそのような作りになっている >優秀な人は凡人に見えていないものが見えてるんだよね そして年間数百個の脆弱性を生む結果となっている 真に優秀なら当然そんな結果はもたらさない 自分が優秀だと勘違いしてる人は凡人にすら見える当たり前ことが見えてないんだよね 921 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:03:33.62 ID:63RUfPPA.net] >>904 脆弱性ゼロというのはありえないというのはわかる？ 922 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:06:03.74 ID:FyQgq0p4.net] >>903 そのランタイムに任せて非効率になる道と 人が頑張って効率的になるが脆弱性も生じる道の2つしか従来なかったところに 第3の道として効率的かつ安全が保証されるRustが登場して解決した 923 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 19:45:03.26 ID:S7DVNM0H.net] >>899 Rustが向いてそうなOSやハイパーバイザが まだまだじゃない？ 924 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:17:03.89 ID:Bzly/lr+.net] それなら有志団体のProssimoあたりがRust移植を資金調達しながらやってるじゃない 焦らんでも数十年後にはRustがそれなりに普及してるよ 925 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:33:12.91 ID:Bflq38Ga.net] 初心者向けRustが無ければ無理じゃない？ 926 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:36:48.91 ID:ljCa+132.net] マンガで読むrust入門とか小学生向けの本が出れば本格的普及かな 927 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 20:39:02.47 ID:Bflq38Ga.net] 最初にスタックフレームの説明から入るのか。 胸熱だな。 928 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:01:30.45 ID:xPWhJeFc.net] バカと初心者は遅いバカ向け言語でいいんだよ バカでなければその後にRustに行き着くから 929 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:10:07.25 ID:FOdKNTRJ.net] 単に sudo を rust で書き直すのにもわりかし時間かかってるよな。 930 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:18:42.19 ID:63RUfPPA.net] 昔のCでよくある hoge = update_hoge(hoge); みたいなプログラムはRustに移植するのがクソ大変なんだよ 古いプログラムだとこの手のコードが大量に出てくる 実質データ構造から全て書き直しになって移植に時間がかかる 931 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:23:31.52 ID:MaibK+2h.net] >>914 >クソ大変 なんで? 932 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:25:38.04 ID:ljCa+132.net] rustを選民意識で使ってる奴とかいる？ 933 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:26:53.82 ID:5wpOXFHi.net] インターネットドメインの無償TLS証明書であるLet's Encryptなどを運用している非営利団体ISRG (Internet Security Research Group)のProssimoプロジェクトは二つの目標を掲げている。 「私たちの目標は二つある。1つは、インターネットを支えるソフトウェアインフラをメモリ安全のコードに書き換えること。もう1つは、メモリ安全性に関する人々の考え方を変えることだ。『C』や『C++』のようなメモリ安全ではない言語で書かれたソフトウェアを展開するのは危険だという証拠があるにもかかわらず使われ続けており、人々がそのリスクを十分に認識し、メモリ安全性をソフトウェアの要件と見なすようにしたい。」 このソフトウェアインフラのメモリ安全性向上に向けて取り組むProssimoプロジェクトの一環として、suやsudoなどのセキュリティユーティリティーを「Rust」で再実装して広める活動も行われている。 934 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:29:19.78 ID:qNukMIkl.net] コンピュータリテラシーの低い人を増やしまくった結果セキュリティ事故祭りになっているのでは？ 935 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:44:22.72 ID:GF5EVhbY.net] >>914 >> hoge = update_hoge(hoge); その例だけなら以下で終わるから説明不十分 update_hoge(&mut hoge); もちろんこれはメソッド化して impl Hoge { 　fn update(&mut self) { 呼び出しはhoge.update() これで終わる話だから おそらく元のC言語コードがグローバル変数を使うなど酷い状態なのだろう 936 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 21:49:13.20 ID:6kFr2fm8.net] >>917 C/C++を捨てる方向でどこも同じか >>500で米政府も表明してるしな 937 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:24:35.35 ID:63RUfPPA.net] >>915 当たり前だがhogeはヒープで確保されており あらゆるところで参照、保持、変更されうる場合がある よってRcにて管理する必要がある 当然Rcの中のオブジェクトを変更できないと意味がない つまりCellなりRefCellが必要となる 938 名前： そして循環参照の問題もあるので弱参照を考えなきゃならん このようにちょっとしたコードでも単純に移植することが難しい rust wayな方法で書き直すしかない [] [ここ壊れてます] 939 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:35:22.67 ID:mTdFoxaI.net] sudoが時間かかってるのは単にそれなりの規模だからってだけだと思うけどな あとsudo風の代替品ではなくてそのまま入れ替え可能なものを目指してるから 仕様の把握と一致検証にも時間がかかるだろうし 940 名前：デフォルトの名無しさん [2024/05/17(金) 22:36:32.50 ID:JB0Glcw4.net] ゲーム開発に向かないからC/C++が残ることが確定してしまった 941 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:37:07.66 ID:GF5EVhbY.net] >>921 Rcは必要ない Rcは所有者が複数になった時のみ登場 942 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:38:27.40 ID:5wpOXFHi.net] >>923 そんな話は聞いたことがない 943 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:42:58.17 ID:cCnlY4YV.net] Rustゲームエンジン開発なんざ勝手にやっとけって感じ セキュリティ脆弱性が致命的になる分野でのRustへの移植が大事なんだから 944 名前：デフォルトの名無しさん [2024/05/17(金) 22:44:28.89 ID:JB0Glcw4.net] >>925 ゲーム会社でRustを採用しようとするところが全然出てこない それが答えだよ 945 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 22:58:43.56 ID:BR1qVngc.net] 巨大なC/C++遺産ですぐに動けないだけでおそらく少しずつ進めているのだろう もし何ら対策しないところがあるとすればそのゲーム会社だけ取り残されるのだろう 946 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 23:17:51.68 ID:+PGm3s9t.net] ゲームなんていう表層的な分野でRustは採用なんてされてないだぁ！って駄々をこねられてもねえ 947 名前：デフォルトの名無しさん mailto:sage [2024/05/17(金) 23:57:11.09 ID:BR1qVngc.net] 分野によって対応の時間差が出るだろうけど C/C++排除の流れは止まらない 948 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 00:25:26.98 ID:Hzmk0zu+.net] 少なくともアメリカの軍事分野の制御システムは>>500の声明のとおり最優先でC/C++からRustへの置き換えられるのが確定してるし民間に広まるのは時間の問題 949 名前：デフォルトの名無しさん [2024/05/18(土) 00:35:56.17 ID:woQdAE7H.net] DirectX、OpenGL、Vulkanといった主要なグラフィックスAPIがC/C++で作られてるし ゲーム分野が仮にRustに置き換わるにしろ数十年はかかりそう 950 名前：デフォルトの名無しさん [2024/05/18(土) 06:54:07.34 ID:CGudIpEF.net] ポインタの概念を経由しないでrustから入るってほぼ無理だと思うけどね。 rustから入ればc/c++はいらないって人はその辺を誤魔化しすぎてんだよ。 951 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 09:05:31.34 ID:knMB7JYq.net] ポインタの概念の理解は必要だけど C の構文は理解困難なのよね。 952 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 10:36:57.70 ID:Fx9Rd4Sf.net] rustがメインで使われるようになろうとも、組み込み系の最初の学習教材としてはC言語が一番扱いやすいから大学で組み込み系での実践言語として今後も使われていくよ 一定数ははじめからRustを教えたりJavaを教えるところもあるかもだけど 953 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 10:48:07.73 ID:XduL+8Iy.net] なんか勝手に組み込みの話にされてるけどゲームはC/C++が残り続けるよ Rustでゲームを作るのは流行らない 954 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 18:43:24.68 ID:Olj0jDDg.net] 政府レベルで勧告しているから少なくともビジネスレベルやその製品まではC/C++が排除されてRustへ置き換わる ゲームのような枝葉末節は知らん 955 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 19:54:53.77 ID:JFC2kl3y.net] ゲーム作る人大半の人は、言語じゃなくて、 どんなゲームエンジンを使うかしか意識しないでしょ。 まずは、メジャーなゲームエンジンに、 Rustが採用されるところからじゃない。 956 名前：デフォルトの名無しさん mailto:sage [2024/05/18(土) 20:34:58.97 ID:knMB7JYq.net] Rustでゲームは向かないみたいな記事はあったけど、あれもゲームエンジンのレイヤとかではなくてもっと上のゲーム固有のロジックを記述する時にRustは向かないというだけの話じゃなかったか？ 957 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 08:21:11.59 ID:J8UPACIo.net] ゲーム固有の言語と汎用の低級言語の二つを採用するのが良い でも上のレイヤはGUIとかデータ記述言語とかで置き換えられ ロジックを記述する言語は一つしか採用されないみたいな思想の人もいるかな 958 名前：デフォルトの名無しさん [2024/05/19(日) 13:44:20.88 ID:UOsr9CB4.net] >>938 まともなゲーム会社はエンジンを内製するんで何の言語使うかとても意識するけど 959 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 14:21:47.30 ID:9ppbKK2j.net] 改造とかカスタマイズはするかもしれんが、まともなところイコール内製は成立しないんじゃないかな。 960 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 14:58:26.82 ID:9JWy2KZh.net] 数年前にもRustはゴミ。使う奴なんていないみたいなことを言っている奴がいた気がするが 961 名前：デフォルトの名無しさん mailto:sage [2024/05/19(日) 15:44:35.31 ID:J8UPACIo.net] じつはLLVMのインフラを捨てずカスタマイズしたのがRust 逆に、プロトコルの互換性はあっても 古い実装と古いコンテンツを捨ててしまうのがインターネットでしょ 962 名前：デフォルトの名無しさん [2024/05/20(月) 11:59:29.58 ID:yyhnuWrn.net] でもお前ミドルウェアとか全く書かないじゃんってやつばっかなのになぜかrust使おうとするやつ 963 名前：デフォルトの名無しさん mailto:sage [2024/05/20(月) 18:43:29.11 ID:4ugUfB32.net] 似たような理屈で 循環参照を全くやらないやつはmark&sweepを禁止される 964 名前：デフォルトの名無しさん mailto:sage [2024/05/22(水) 21:52:53.58 ID:0G81pYpr.net] JetBrains開発Rust用IDEのRustRoverが安定版リリースに向けてライセンス体系を発表したけど非商用無料で使わせて貰えるみたい ttps://blog.jetbrains.com/rust/2024/05/21/rustrover-is-released-and-includes-a-free-non-commercial-option/ 965 名前：デフォルトの名無しさん [2024/05/23(木) 02:03:24.72 ID:zV267ZMC.net] おお　(^－^) 966 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 06:59:30.95 ID:nsNudoX6.net] RustRover 優秀そうだけど、デファクトになってほしくないんだよなぁ。LSPベースの rust-analyzer と開発体験を分断されたくない。 Kotlin みたいに JetBrains 製品にお布施しないとまともな開発者体験を得られない言語に成り下がられるのはゴメンだ。 967 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 07:38:03.27 ID:gde9MjoR.net] JetBrainsのRustIDE、完全有料になるかと思ってたわ 968 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 08:30:48.75 ID:nvuBPJ3U.net] どうせ頃合いを見て有料化するだろ 969 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 09:03:01.21 ID:pOxW5wqV.net] > 開発体験を分断されたくない。 後発にしては厳しい無料条件なので心配しなくても良いかと 正式な開発でなくても(リモートワークも含めて)仕事時間中に使えば "regular direct or indirect income"に該当するから"non-commercial license"は適用違反 "non-commercial license"はテレメトリーをオプトアウト出来ないので要注意 970 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 11:44:30.79 ID:on9rPJCX.net] >>949 KotlinはintellijのCommunity版では駄目なの？ 971 名前：デフォルトの名無しさん [2024/05/23(木) 19:28:45.95 ID:BdcLV1xd.net] >>912 とバカが申しております 972 名前：デフォルトの名無しさん [2024/05/23(木) 19:58:53.15 ID:6Gn5p/CD.net] バカにはスクリプト言語でまともなコードを書くのは難しい 973 名前：デフォルトの名無しさん mailto:sage [2024/05/23(木) 22:37:27.54 ID:jrJOBQ7e.net] >>831の反Rustの人ですら 数行のコード以外はスクリプト言語よりもRustの生産性が高いと認めてるもんな 974 名前：デフォルトの名無しさん [2024/05/24(金) 11:24:20.14 ID:56Y1qcJr.net] 10行以内かつ実行時間10秒以内のスクリプトだけはPythonの方が生産性が高い 975 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 12:56:31.70 ID:nrXjP27l.net] 四半期に一回、特定のひと一人で、実行時間1分みたいな、た 976 名前：くさん動かないやつはJVMか.NET系で買いてるかな〜 Rustで書くスキルも無いが。 [] [ここ壊れてます] 977 名前：デフォルトの名無しさん [2024/05/24(金) 17:03:15.24 ID:2N4ieM97.net] >>956 んなこたない。適当なAPI叩いて結果保存するくらいのことでわざわざrustなんか使わねーよ。 978 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:06:34.32 ID:kgcJienR.net] シェルスクリプトでいいわな 979 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:25:46.80 ID:/GRQnPSE.net] 俺もbashスクリプトで辛くなったらRust使ってる 980 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 18:33:51.22 ID:4a8mskew.net] シェルスクリプトはもう古い クソ文法すぎる これからは google/zx だよ 981 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 20:29:44.37 ID:JvVkOY+P.net] いまawsやるならrustがベスト？ 982 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 20:31:15.62 ID:wR0icTOd.net] 何でもシェルスクリプトでやろうとするガイジが昔湧いてたなぁ 983 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 21:19:59.79 ID:XJ5j6TX/.net] AppImageはギルティ？ 984 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 21:51:51.21 ID:/GRQnPSE.net] >>963 CPUメモリリソース料金を下げるためにRust利用がベストチョイス 985 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:15:30.97 ID:s3G1nQRJ.net] やりたいこと次第だけどシェルの代替はPythonでほぼ事足りると思う ファイル操作、文字列のパースやフォーマット、プロセスの呼び出しなどは簡単にできるし読みやすい 986 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:15:34.63 ID:s3G1nQRJ.net] やりたいこと次第だけどシェルの代替はPythonでほぼ事足りると思う ファイル操作、文字列のパースやフォーマット、プロセスの呼び出しなどは簡単にできるし読みやすい 987 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:31:06.67 ID:y1+3vies.net] シェルスクリプトとRustで十分 Pythonは不要 988 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:53:57.26 ID:fBactBUY.net] wslが使い物になるようになってから全部シェルスクリプトでよくね？ってなっちゃった 989 名前：デフォルトの名無しさん mailto:sage [2024/05/24(金) 23:59:24.64 ID:y1+3vies.net] ある程度以上はRust利用 990 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 06:44:35.86 ID:J0svnUgO.net] >>967 Pythonは文法がなぁ。Python使うならNimの方がいい。 RustScriptとかどうなんかね。 991 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 08:48:10.16 ID:vDhIrX/5.net] Pythonってライブラリ資産が豊富でマルチプラットフォームなスクリプトだから使われてるだけでしょ 992 名前：デフォルトの名無しさん [2024/05/25(土) 09:34:12.56 ID:q+P8yrMm.net] >>973 その通りだけどそれが重要じゃん だからRustはユーザ少ないし流行らないし消えそうじゃん 993 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 09:57:20.38 ID:0KAJWBX2.net] これだけネットインフラのRust化が進んでいて「流行らない」と言い出す人 994 名前：デフォルトの名無しさん [2024/05/25(土) 10:30:11.54 ID:q+P8yrMm.net] じゃあ数字で出してよ pythonが流行ってるとしてRustはどうなのか？ ユーザ数でもプロダクト数でも何でも良いから比較数値を出して見てよ 995 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 10:45:29.87 ID:Ok/Wj9Ar.net] >>976 分野に定着すれば数が少ないことは「消えそう」という根拠にはならない。 総合的な判断なので一部の数値を見るのはあまり意味がないが……。 事実上の標準であるリポジトリ PyPI と crates.io のパッケージ数はそれぞれ 543556 と 146503 。 Python のほうがかなり数は多いが Rust が消えそうなほど弱小ということはない。 エンドユーザーに近いほうが数は多いのが自然だし。 996 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 10:57:59.92 ID:566/PNRT.net] The Best Blogs and Websites - Feedly ttps://feedly.com/i/top/rust-blogs 997 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:20:17.33 ID:jCqkIMgy.net] TIOBEとかgithubとか色々でてるじゃん どう判断するかはあるけどそれくらい探せよ 998 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:24:55.77 ID:CqoBbhiM.net] >>973 十分普及しているからさらに使われれるという面もあるな。 配布するスクリプトは昔ならわざわざ実行環境入れてもらうハードルがあるから標準の sh 999 名前： や bat を書いてたけど 今は安心して python 一本だな。 [] [ここ壊れてます] 1000 名前：デフォルトの名無しさん [2024/05/25(土) 11:48:54.94 ID:q+P8yrMm.net] >>980 数は正義だからね 1001 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 11:49:54.05 ID:7FqN5d/t.net] ここはRustスレだ バカはクズ言語Pythonを使っていろ しかしバカはここから出て行け 1002 名前：デフォルトの名無しさん [2024/05/25(土) 11:57:26.64 ID:q+P8yrMm.net] 俺がRustを使ってないと何時から錯覚した？ 他の言語も使うがRustも普通に使ってるぞ 1003 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 12:08:10.83 ID:0t71UrW4.net] 例えばJavaが消える最大の原因はKotlinだろうから JavaとPythonを比較するのは無意味だと思う RustとPythonも同じ 1004 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 21:06:08.47 ID:KcOF6HNo.net] >>972 rust-scriptってあったんだな なんかpostscriptみたいな響き 1005 名前：デフォルトの名無しさん mailto:sage [2024/05/25(土) 23:37:23.93 ID:0t71UrW4.net] >>983 それは投票する側が2倍以上努力してるだけだからね 投票される側の正義とは言えないよ 1006 名前：デフォルトの名無しさん [2024/05/26(日) 05:37:36.04 ID:3cUpvkRQ.net] pythonが定着するとかイヤだなぁ・・・ pythonとかjsとか使わざるをえないからイヤイヤ使う言語ってほんとイヤ 1007 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 11:36:19.22 ID:7yHeuCrc.net] ネイティブコンパイラはOS依存を強制される説があって javaとかjavascriptとかは強制がないとされていた 最近はネイティブではなくunsafeが悪いみたいな話になってるね 1008 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 16:24:52.23 ID:yRNPjL2P.net] >>987 残念ながら普通の人はpython使ってる その中身をrustで書く こうなっていくと思う 普通の人が直接rust書くのは無理かと C/C++とおんなじ 1009 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 17:48:00.24 ID:VjGSgwTY.net] プログラムを書くのがプログラミングの専門家ってわけじゃないのが現代だからね。 学者ならどの分野にしても多少はプログラミングも (専門家レベルでは全くないにしても) 学んで欲しいが 事務員とかアーティストが使うことを想定したらかなりハードルを下げるのはしょうがない。 1010 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 19:02:26.55 ID:hB5FbGHx.net] Pythonの最も速くて使いやすいパッケージ管理ツールRye+uvはRust製 Python⇔RustはPyO3で相互呼び出し可能 今後のPythonはツール面でもライブラリ面でもRustの助けを得て進んでいく 1011 名前：デフォルトの名無しさん [2024/05/26(日) 21:48:57.66 ID:qVdh8/fj.net] CPythonじゃなくてRustPythonになるのは歓迎 1012 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 22:56:51.38 ID:XmfdYoG9.net] つまりPythonを使っていると思ったら実はRustを使っているということか 1013 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 23:19:03.24 ID:E+Olvt9B.net] PythonもJavaScriptも今どきのイケてるパッケージはRustで書かれてるよ RubyやPHPは知らん 1014 名前：デフォルトの名無しさん mailto:sage [2024/05/26(日) 23:47:36.53 ID:qyBtaRPy.net] X言語でX言語用のツールを作ってたけど 遅いとか色々問題が出てきたのでrustで作り直しました という事例がそこそこ出てきたけどそこで c++という事例あるかな？ 1015 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 00:44:37.08 ID:5v+U6kmL.net] >>994 RubyのYJITはRust製でしょ 1016 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 00:45:25.77 ID:5v+U6kmL.net] >>980 スレ立てよろ 1017 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:40:16.06 ID:T4AFD1f4.net] 立てるよ？ 1018 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:41:53.55 ID:T4AFD1f4.net] 次 Rust part24 https://mevius.5ch.net/test/read.cgi/tech/1716759686/ 1019 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:43:57.69 ID:T4AFD1f4.net] 馬 1020 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 93日 13時間 6分 6秒 1021 名前：過去ログ ★ [[過去ログ]] ■ このスレッドは過去ログ倉庫に格納されています

---

---

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

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