Rust part21

1 名前：デフォルトの名無しさん [2023/08/15(火) 22:24:39.45 ID:xzxy4cgp.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 part20 https://mevius.2ch.net/test/read.cgi/tech/1677771928/ ﾜｯﾁｮｲスレ プログラミング言語 Rust 4【ﾜｯﾁｮｲ】 https://mevius.2ch.net/test/read.cgi/tech/1514107621/ 226 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:17:03.67 ID:/YAD597I.net] >>219 >ミュータブルか否かの区別がある方が好ましく 当たり前では mojo調べでlet/var区別が好ましいと決着ついた https://docs.modular.com/mojo/manual/basics/index.html#variables rust mutが好まれてないだけ >>220 let/varだと区別がありつつ煩雑じゃない、という事ですね 227 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:24:01.30 ID:/YAD597I.net] それと >>220 Linuxカーネル本体は当分Cのままで デバイスドライバをrustで書く準備が出来た、だけですよ 228 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:26:04.83 ID:6F2DK256.net] >>220 mutableとimmutableの区別は必須 それを煩雑という者は初心者のみ >>221 色んなプログラミング言語をやってきてる者にとってそんな些細な記述方法を問題にするやつはいない 参照のある言語でmutableを区別するならばmut付加方式が合理的 例)　let mut x: &mut Type = ... 229 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:28:27.24 ID:/YAD597I.net] あと前スレで出ていたcurlですが rust TLS backendを使う選択肢があるのに配布用には採用されてませんね $ curl -V ... libcurl/8.3.0 OpenSSL/3.1.2 (Schannel) zlib/1.3 brotli/1.1.0 zstd/1.5.5 libidn2/2.3.4 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.11.0 nghttp2/1.56.0 Release-Date: 2023-09-13 230 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:30:46.42 ID:Mq8zEA1a.net] letの後に識別子しか書けないならlet/varでいいんじゃね パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする 231 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:31:04.61 ID:ksZUfg69.net] ここはRustのスレ 的外れなRust叩きをしているバカはアンチスレへ移動しろ 232 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:35:09.11 ID:/YAD597I.net] sudo-rsも v0.2.0でstableと言い切って知らないdistributionに ねじ込んだようですがその後どうなるのか要チェックです 233 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:43:02.23 ID:4Db3FasG.net] mojoの所有権周りの構文ってRustより重い感じなんだな これPython書きたいような人に受け入れられるんだろうか… 234 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:44:55.11 ID:/YAD597I.net] >>225 >パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする 気がする、ではなく 合理的だという説明が聞きたい 235 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:47:42.54 ID:cnhK/Rr/.net] >>221 たとえばRustでよくあるこういうパターンはmojoでどうするんだろう let (tx, mut rx) = channel(100); そもそも可変参照はどう区別するんだろうね あと関数の引数変数のmutable性はどうやって表すんだろう Rustのmutを添える方式が自由度が高くてわかりやすいよね 236 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:48:06.93 ID:/YAD597I.net] >>228 どの辺りが重い感じ？ 237 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:52:51.61 ID:4Db3FasG.net] >>231 borrowed, inout, owenedって全部キーワード指定だし結構長くない？ 自分はRustみたいに明示的なのが好きだから多少長くてもいいけど Python好きな人だとどうなんだろうって 238 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:54:33.01 ID:Mq8zEA1a.net] パターンマッチの場合束縛する変数が複数になり得るので、それぞれの変数に対して異なるmutabilityを宣言できる あと、Rustは変数への束縛にmove/refの区別もあることも関係してるかもね letやvarのように別構文を用意するなら、それぞれに対してmove版、ref版が必要になってしまう 239 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:59:25.63 ID:cnhK/Rr/.net] let (foo, ref mut bar) = とかよく使うもんね mutやrefが分離キーワードになっているRustが便利 240 名前：デフォルトの名無しさん mailto:sage [2023/09/15(金) 23:59:43.71 ID:/YAD597I.net] >>230 なるほどね mojoでunpackがどうなるのか知らないけど unpack用のlet/varシンタックスはあった方が良いね let/var方式の他の言語を参考にするんだろうな 241 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 00:02:44.62 ID:A/Og/XEu.net] >>234 >mutやrefが分離キーワードになっているRustが便利 これを突き詰めるとponyになるって5chで聞いたよw 242 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 00:03:10.36 ID:e71CP5Wp.net] >>234 いや、今となってはrefはほとんど使わん 243 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 00:26:11.63 ID:h6vfr2ug.net] TauriとTauri Mobileが別々の実装として統合されないの悪手だと思うんだがな せっかくRustでロジック書けてネイティブ呼び出しまで簡単で手頃なフロントエンド実装で期待してたのにわざわざコミュニティ分断する必要あるんか？ なんかXamarinみたいな結末迎えそうで残念だわ 244 名前：デフォルトの名無しさん [2023/09/16(土) 09:10:27.83 ID:FQ6fYHli.net] T,o,k（迷惑という方は←をあぼーんしてください。） 更に家族に教えて加えて￥4000×人数をGET。 https://i.imgur.com/p75gBok.jpg 245 名前：デフォルトの名無しさん [2023/09/16(土) 09:55:59.18 ID:ZJLR+eYH.net] >>238 無理に一つにしようとすると条件分岐増えてごちゃごちゃしてわかりにくくなる、というのはありそう。知らんけど。 246 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 10:40:22.96 ID:FZJflFW6.net] >>239 もう現金化してアンインスコしてる 247 名前：デフォルトの名無しさん [2023/09/16(土) 11:27:20.46 ID:8u+hT5wA.net] RustRoverを試してみる https://zenn.dev/helloyuki/scraps/a0241df49b2556 248 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 11:55:36.71 ID:jG7brSLe.net] ウェブ系の奴らがやけにJetBrains推してくるけどAndroid Studio使ったら如何にゴミIDEなのかよくわかった しかも個人使用でも買い切り数百ドルもしたのに今はサブスク月額1300円とかぼったくりもいいところ VSCodeがあって本当によかったVSもCEならデバッガに制限あるけど無料だしこれほどMSに感謝したことはないね 249 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 12:20:19.81 ID:E7jGhtqP.net] mut よりもShared XOR Mutableの方が難しいだろ。 250 名前：デフォルトの名無しさん [2023/09/16(土) 12:41:23.41 ID:8u+hT5wA.net] >>243 Android Studio は IntelliJ IDEA がベースになっていて無料の community 版があるが? ていうか Android Studio の方は最初から無料じゃなかったか? 金取るやつあるの? 251 名前：デフォルトの名無しさん [2023/09/16(土) 12:57:41.63 ID:RATZO/gi.net] >>223 let x: &mut Type = ... でよくね？ 252 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 13:00:07.59 ID:XaZSJ/up.net] >>244 lifetimeが難しいというのも大体がshared xor mutableの話だしな 253 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 13:07:54.84 ID:2emM+tnC.net] >>246 それだとimmutableとなり変数値を書き換えできないから根本から違う 254 名前：デフォルトの名無しさん [2023/09/16(土) 13:23:53.43 ID:RATZO/gi.net] 描き替え出来るから問題無い 255 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 13:57:40.01 ID:2emM+tnC.net] >>249 ポインタ値の書き換えと ポインタが指す先の書き換えの 区別がついていないのはCでも初心者レベル 256 名前：デフォルトの名無しさん [2023/09/16(土) 14:05:34.65 ID:RATZO/gi.net] うん だから付ける必要無い所まで描く必要無いよね 257 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 14:06:34.42 ID:XaZSJ/up.net] refとmoveの区別がある言語とそうでない言語の構文比較しても仕方なかろう 258 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 14:10:34.38 ID:nUKpqsu7.net] >>246 ダメです 全く異なります let mut x: &mut Type = ...　←xの値を書き換えられる let x: &mut Type = ...　←xの値を書き換えられない 259 名前：デフォルトの名無しさん [2023/09/16(土) 14:24:43.82 ID:RATZO/gi.net] >>253 だから付ける必要無い所まで描く必要無いよね 260 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 14:32:47.40 ID:F5t5l7vC.net] >>239 絶対に試すべきだね。 261 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 14:37:19.47 ID:nUKpqsu7.net] >>254 mutabilityを必要とする分に応じてmutを付ける必覧vがあります そのため以下4種類がコードに応じて使い分けされています let mut x: &mut Type = ... let x: &mut Type = ... let mut x: &Type = ... let x: &Type = ... 前者のmutは変数xの値を更新するならば不可欠です 後者のmutはType型の可変参照で参照先の値を更新するならば不可欠です それぞれの値を更新するためにはそれぞれのmutを欠くことはできません 262 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 14:43:13.66 ID:BFCePFCu.net] ほんまジャップはアホやな しょーもない重箱の隅をつつきあって知識自慢のマウント合戦 そして出来上がった成果物は誰も使わないクソゴミ ジャップがオナニーしてる間にソフトウェアは中国に30年遅れているという現実 お前ら見てるとマジで日本人がソフトウェアで土人の未開レベルな理由がよーくわかる 263 名前：デフォルトの名無しさん [2023/09/16(土) 17:08:24.37 ID:DWW8ClN4.net] まともなプログラミング言語ならばそれら四つの区別がある 例えばC/C++ではこのように対応する // 変数値は不変で参照先も不変 Rust: let p1: &i32 = ... C/C++: const int* const p1 = ... // 変数値は可変で参照先は不変 Rust: let mut p2: &i32 = ... C/C++: const int* p2 = ... // 変数値は不変で参照先は可変 Rust: let p3: &mut i32 = ... C/C++: int* const p3 = ... // 変数値は可変で参照先も可変 Rust: let mut p4: &mut i32 =... C/C++: int* p4 = ... つまり可変な時にmutを付けるか 不変な時にconstを付けるかの些細な違いにすぎない 264 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 17:14:29.95 ID:AP//fjNl.net] 参照の可変性という概念を持つ言語がそもそも少ない 265 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 17:15:13.87 ID:AP//fjNl.net] 概念が異なるのに構文の話だけをしても仕方ない 266 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 17:34:04.75 ID:nlb2ovML.net] 参照先の値がread onlyかwritableかはプログラミングで極めて重要だよね 間違えて意図せず書き換えてしまっていたバグなどの減少にも繋がるから必要な機能じゃないかな 267 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 17:37:07.29 ID:sqsrY/cP.net] >>258 2番目と4番目はRustだとsmellyなのでリファクタリング検討候� 268 名前：� [] [ここ壊れてます] 269 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 19:41:48.63 ID:OLEDwioO.net] >>204が言ってるのはmutの区別が不要じゃなくて 良く使うmutable側でタイプさせんなってことでしょ 270 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:04:56.12 ID:DWW8ClN4.net] ほとんどのプログラムではmutと記述すべきところが少ない もしmutが多いならレアケースを除いてコードを改善すべき可能性が高い 271 名前：デフォルトの名無しさん [2023/09/16(土) 20:10:22.45 ID:TlXhcaWs.net] >>263 ＞良く使うmutable側でタイプさせんなってことでしょ お前、それプログラミングのセンス無いわ。 あ、もしかして使い捨てのコードしか書いたこと無い？ 272 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:12:22.58 ID:b0KnMHZf.net] >>263 慣れてきたらmutあんま使わなくて書けるようになるよｗ 関数型言語やってるとmut相当のもんなんて基本使わんのだし 273 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:31:44.89 ID:/CtnFWfv.net] >>266 その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん mut祭りで読みづらい代わりに高速でメモリ効率が良いのがRustの売りでしょ 274 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:37:59.24 ID:EG7NJZsJ.net] 多い少ないの話したいなら定量的な根拠持ってきてくれ 根拠ないなら断言するのはやめて 275 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:45:23.05 ID:DWW8ClN4.net] >>267 それは関係ない まずRustのほとんどのプログラムでmut祭りになることはなくmutの出現は少ない その上でRustはCとほぼ同じ程度速い 276 名前：デフォルトの名無しさん mailto:sage [2023/09/16(土) 20:50:47.30 ID:bcC3Efve.net] どちらがより目立つべきかを考えたら mutable なほうが目立つべきだし 目立って欲しい方に指定をつける文法が自然だ。 良く使うほうが短く書けるべきという視点だって もちろん間違いではないし、評価軸は無数にある。 定量化したところでそれぞれの重みをどう捉えるかは 感性の問題だろ。 277 名前：デフォルトの名無しさん mailto:sage [2023/09/17(日) 12:16:37.26 ID:ju6VviWZ.net] >>211 Goでできない非同期処理って何？ channelとselectとgoroutineとsyncパッケージでなんでもできるけど 278 名前：デフォルトの名無しさん mailto:sage [2023/09/17(日) 13:48:53.24 ID:4koi4/xu.net] >>271 例えばベアメタル環境での非同期とか？ まぁ大抵の環境でだいたい上手く行くってのがGoのいいところだから 別に悪くはないと思うけど 279 名前：デフォルトの名無しさん mailto:sega [2023/09/17(日) 17:36:59.55 ID:FEktRC8x.net] 毎日ちょっとずつ課題でてそれを解いていくようなRust勉強サイトってないの？ ナンプレ毎日１問クリアしていく感じなやつ 280 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 01:48:58.76 ID:u21D7vuy.net] >>273 exercism.org どうかな 281 名前：デフォルトの名無しさん [2023/09/18(月) 10:51:29.83 ID:+ud3D/1q.net] >>267 >その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん Rustのことなら#[derive(Copy)]とか.clone()とか描いちゃだめだよ絶対 282 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 12:04:31.40 ID:X+wkGtcX.net] >>267 エイリアス解析がやりやすくなって本質的に同じものなのか 複製が必須なのか自動で判断して最適化される。 プログラマが判断するよりたぶん賢い。 mut を付けるかどうかは性能じゃなくてロジック的な妥当さで決めるもんだよ。 283 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 12:15:08.64 ID:eKGbn4o/.net] techempowerベンチ見るとrustと比較してgoがしょぼいけど こんなものなの? 284 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 12:28:49.50 ID:X+wkGtcX.net] つよつよプログラマがチューニングすれば際限なく性能を挙げられるという意味での性能の良さと 非プログラマがテキトーに書いても及第点程度の性能が出るというのは言語として両立しにくい。 仮にしょぼいのが本当だとしてもトレードオフになる何かがあったりするから 総合的な使用感は実際に使ってみないとよくわからん。 285 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 12:39:00.83 ID:b4Z9xD4H.net] >>277 GoはGC内蔵言語だから本質的に遅い GC内蔵言語はGCするから遅いわけではなくGCのためにヒープメインにならざるをえないため遅い 286 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 12:44:14.37 ID:AWdb6cD0.net] なんでもイミュータブルじゃなくて必要な時にミュータブルにしつつ安全性をコンパイラが保証してくれるのがいいんだよなぁ。 287 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 13:13:11.65 ID:eKGbn4o/.net] そもそも、goはc#にすら負けてね? 1番高速じゃなくても2番目あたりでいいかなと思ってるんだけど どれがいいのかなと ななやむぐらいならわかりやすい1番にしとけばいいのか? 288 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 13:16:25.44 ID:eKGbn4o/.net] goのgc調べてみましたが参照カウントとかじゃないのか 289 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 13:54:07.10 ID:1tuWbz8L.net] Rustは見た目が汚いのが困る もういっそCの方がきれいで安全で保守性が高いまである 290 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 14:01:16.96 ID:6k3cBrAf.net] Cは大きなプロジェクトが汚すぎる モジュールで名前空間分けられないから 291 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 14:04:02.95 ID:DByXMqbY.net] C言語は"安全装置のない銃"に徹しているからな シンプルなだけに危険いっぱいだ 292 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 14:43:26.49 ID:EhgpbTsZ.net] C#はunsafeやSpanがあるので頑張れば結構速い ネイティブコンパイルもできるようになってきたからとにかく速度を求めるようなアプリじゃなければ十分 293 名前：デフォルトの名無しさん [2023/09/18(月) 15:27:10.56 ID:orcKBY2S.net] Rustもcrateのダウンロード数に応じて crate開発者が課金される時代か メシウマじゃなかった胸熱 294 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 15:57:52.35 ID:qN+5vY8o.net] 何の話かと思えばunityか 295 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 16:04:36.29 ID:2MGtTYvZ.net] とりあえずミュータブルの話をするならshared xor mutable に触れなきゃ意味ないし、それなら元ネタのトランザクション分離レベルぐらいは勉強しとかんといかん。 296 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 16:05:47.88 ID:7BUJ27i/.net] >>285 C(C++含む)の真のヤバさはそれが周知されていないことだと思う セキュリティ、セキュリティ吠えながら妄信的にC/C++使っているところとか普通にあるし 297 名前：デフォルトの名無しさん [2023/09/18(月) 17:52:28.36 ID:yZdHYJJu.net] >>283 ＞もういっそCの方がきれいで 前置宣言だからそれは無い。 298 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 22:02:21.17 ID:1tuWbz8L.net] >>291 前置宣言だから綺麗に書けるまである 299 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 22:29:41.23 ID:b4Z9xD4H.net] >>283 Rustは普通というか見た目キレイ側 300 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 23:41:51.16 ID:X+wkGtcX.net] >>290 ロジックが正しくてもバイナリレベルでは脆弱性になることがある。 分かりやすい例では、言語の理屈では寿命を終えたはずのオブジェクトでも再利用される機会がなくて内容が残り続けるとかね。 そういうときにでもどうにかする知見が C/C++ では積み上がってる。 普通に書いて脆弱性が発生しにくいに越したことはないが、脆弱性が発生していることがわかったときに直せる確信があるというのはセキュリティが重要な場面で C/C++ を使う理由になる。 C/C++ が「自分の足を撃つ」ことになるなんてのは百も二百も承知の上で、「自分の足を撃つことも出来る」ことに価値を見いだしてるんだよ。 もともと自分の足を撃つというのは戦争に行かなくて済むようにわざと撃つことがあるというのを下敷きにした言い回しで、危険であると同時にそれが必要なこともあるというニュアンスを含んでいる。 301 名前：デフォルトの名無しさん mailto:sage [2023/09/18(月) 23:47:04.73 ID:h2SSCK+Z.net] >>294 それRustに対するアドバンテージになってないな むしろディスアドバンテージ 302 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 07:20:03.69 ID:H6NF4sQp.net] >>294 目的のために敢えてUB引き起こすってこと？ 303 名前：デフォルトの名無しさん [2023/09/19(火) 11:44:23.57 ID:B2l8DHRh.net] >>294 ＞そういうときにでもどうにかする知見が C/C++ では積み上がってる。 所謂、バッドノウハウね。 そりゃさんざん今までやりまくって、なんなら現在進行形だったりするんだからノウハウも積み上がるさ。 304 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 13:23:13.06 ID:Gn3exU3j.net] データベースのデータファイルの中の構造は、 C言語の「全部生メモリ」状態で、ポインタの 変わりにファイルポジションになっていて 普通に相互リンクトリンクやファイルポジション をデータの位置を表現するのに使われていたりする。 だから、実行中のプログラムの RAM のメモリー安全 は確保されたとしても、ファイルの中は安全には ならない。 305 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 13:27:32.55 ID:Gn3exU3j.net] >>298 [補足] ・ポインターの代わりにファイルポジションが使用され、 　古来の plain C と同様のプロググラミングが行なわれている。 ・LockFile や fnctl で「部分ロック」が当たり前 　のように使用されており、非常に複雑な 　配慮が必要なプログラミングになっている。 もっといえば、DBMS を使うアプリケーションも、非常に 配慮が必要な場合も多く、どのようなテーブルやカラム構造 にするかは難しい。ID番号をリンクしたり、どうやって データを参照しあうかなどが生ポインタと同様の難しさ を持っていて、わずかでも間違えば、全データが論理破損 してしまう可能性を持っている。 306 名前：デフォルトの名無しさん [2023/09/19(火) 14:54:41.30 ID:rHe1cSmV.net] だれか巻き込まれてないか？ https://www.youtube.com/watch?v=SzpaDEhm-8Q 307 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 15:58:16.52 ID:H6NF4sQp.net] 形式検証をrustに組み込むのってどれくらい現実的なんだろ 言語本体ではなくてproc macroで実現できるのかね 308 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 16:39:15.02 ID:p1GkLls0.net] >>299 一般的なDBMSは中央集権でページアクセスを一元管理してるから生ポインタとは全く質が異なる 309 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 17:37:47.80 ID:/HqZkxNe.net] >>302 ただ、購入履歴などは「誰が購入したか」のIDを 購入項目テーブルとユーザーテーブルを結びつける 必要があるので、IDがポインタの役割になる。 わずかでも狂うと、別人が買った項目が結び付け られてしまう。 値が1つ、または、行が一行でもずれるとほぼ全体が破綻する。 310 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 18:14:50.54 ID:mxtPnJ5/.net] DBでも何でもそうだけどshared xor mutableも必要 311 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 18:23:26.80 ID:/HqZkxNe.net] 販売サイトなどのバグって怖くて、500円のものが バグれば5000円になったりする可能性ある。 そういうものは、プログラミングを気をつける しかなくて、Rustの安全対策でも防げない。 312 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 18:32:19.28 ID:gvKDfDmE.net] 「気を付ける」の内訳にはテストを書く習慣とかが含まれてる。 気を付けないとしょうがないけど 気を付けるのに使える道具はそれなりに揃ってる。 313 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 18:34:24.73 ID:mxtPnJ5/.net] すべてのバグをなくせる言語がないのは当たり前 データ競合により起こるそういう値のバグも現実にあるのだからRustでその手のバグをなくせるのも事実 314 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 18:55:07.79 ID:p1GkLls0.net] >>303 そのレイヤーの話でもDBMSはトランザクション管理されてるから生ポインタとは状況が全く異なる トランザクショナルメモリで管理された共有メモリと生ポインタの違い(実際はそれよりもまだ差がある) 315 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 19:02:27.03 ID:p1GkLls0.net] >>304 同時実行制御には大きく楽観的制御と悲観的制御があるがshared xor mutableは後者 高い同時実行性能が求められる場合には楽観的同時実行制御を使うことが増えている DBの話だけでなくロックフリーアルゴリズムも基本は楽観的制御 316 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 19:54:07.45 ID:/x1C5Bro.net] >>309 楽観的排他制御を用いることができる現実的ケースが狭い 衝突した時の処理やり直しコストも考慮する必要がある その一般的な話とは別にポインタ(参照)の話の方は必ず衝突するためsingle writer xor multiple readersが必須 317 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 21:00:27.72 ID:BGD+Lo74.net] 排他制御も凄く奥深い話ではあるが、そういう ものだけでなく、単なるプログラムミスで、 ID番号が1つずれたり、行がなんらかの事が 原因で1ぎょうずれたりしても、大変な問題 を巻き起こす。だからテストは必須。 318 名前：デフォルトの名無しさん [2023/09/19(火) 21:30:53.89 ID:cyrWzrEE.net] RDBMSで物理的な一行とか関係ない テキストファイルに永続化してる素人だな 319 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 21:34:30.39 ID:BGD+Lo74.net] >>312 DBMS自体をプログラムする場合には関係ある。 320 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 21:41:37.42 ID:BGD+Lo74.net] それと、DBMSを使うに徹する場合でも、行に 付ける ID 番号の管理がまた問題になる。 それも慎重に良く考える必要がある。 321 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 21:50:10.01 ID:LcWw/5IR.net] それサロゲートキー義務で設計したらの話でしょ 322 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 21:55:08.52 ID:BGD+Lo74.net] >>315 色々な機能を実装する上で、色々有り得る。 323 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 22:32:18.55 ID:e2nf9Krk.net] >それと、DBMSを使うに徹する場合でも、行に >付ける ID 番号の管理がまた問題になる。 DB板にもそういうのいるけどRDBにID必要と考えてるやつはもっかい勉強してこい 324 名前：デフォルトの名無しさん [2023/09/19(火) 22:44:03.77 ID:5k6OZf8O.net] >>310 >楽観的排他制御を用いることができる現実的ケースが狭い MVCCやCASが楽観的制御 分散非同期が前提の世界では楽観的制御がデフォルト じゃないとスケールしないから Rustがコンパイル時悲観的制御にしてるのは実行時の管理を無くしたいからであってポインタだとshared xor mutableが必須だからではない トランザクショナルメモリがその一例 325 名前：デフォルトの名無しさん [2023/09/19(火) 22:57:59.75 ID:cyrWzrEE.net] DBMSをプログラムする場合には当然関係ある でも1行ずれたら大変とかいう下手くそは任されないので関係ない 326 名前：デフォルトの名無しさん mailto:sage [2023/09/19(火) 23:03:17.25 ID:BGD+Lo74.net] >>319 下手クソとか上手いとかっていうより、 そうならないようなアルゴリズムやデータ構造を ちゃんと考える能力があるかどうかなん だろうけどな。

---

---

[ 続きを読む ] / [ 携帯版 ]

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