Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

公式
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/

**デフォルトの名無しさん** · 2023/09/15(金) 12:03:53.15

しっかりやってる人の意見
https://kerkour.com/should-i-rust-or-should-i-go

Goと比較した場合のRust一番大きいメリットはエラー処理やバグ検知だけどasyncのデメリットが大きいのも確か

**デフォルトの名無しさん** · 2023/09/15(金) 12:13:34.28

むしろNimのネガキャンにしかなってないって話題になってた記憶が

**デフォルトの名無しさん** · 2023/09/15(金) 12:13:50.38

>>205
Rustの一番の課題が絶壁の学習曲線なんだから、３日目の感想は重要だろ。
それを無視するならHaskell化待ったなしだな。

**デフォルトの名無しさん** · 2023/09/15(金) 12:52:21.36

情報密度が違っててワロス
https://www.ossnews.jp/compare/Rust/Nim

**デフォルトの名無しさん** · 2023/09/15(金) 12:58:36.85

>>207
むしろasyncが容易かつ効率的なことがRustの利点だよ
そして軽い非同期タスクを大量にマルチスレッド上でいわゆるM:Nスケジューリングできるのは、
RustとGoしかないためその両者の比較になるのはその通りだが出来る範囲はRustが広くきめ細かい
もちろん非同期以外の言語仕様も同様でGoは貧弱すぎる

**デフォルトの名無しさん** · 2023/09/15(金) 13:33:46.47

Go は貧弱だが Go くらいで十分な範囲をカバーできるだろ……という割り切りで設計されているように見える。

**デフォルトの名無しさん** · 2023/09/15(金) 14:58:25.08

Goは構文が簡素なのは割り切りとしていいと思うんだけど
参照周りの扱いとかCの頃から進歩してなくて
「こんなこと今どき人間が気をつけて書くの？」という気持ちにはなる

**デフォルトの名無しさん** · 2023/09/15(金) 16:57:51.41

>>210
こういう役に立たない一般論に比べれば>>204のような薄っぺらい個人の感想のほうが実践知なのでまだ価値がある

**デフォルトの名無しさん** · 2023/09/15(金) 19:05:24.10

>>210
スマホからは何も見えない……
なんかあるの？

**デフォルトの名無しさん** · 2023/09/15(金) 19:11:49.50

>>215
RustとNimを比較してるサイト

**デフォルトの名無しさん** · 2023/09/15(金) 20:05:41.52

Goは構文簡素にしてても内部のGCとかは複雑にしてるイメージ。

**デフォルトの名無しさん** · 2023/09/15(金) 20:39:40.02

>>214
どちらのページも意味のある情報がなにもない
くだらない揚げ足取り

>>215
PCからしか内容が見えないダメサイト
内容に意味はないため見る必要ない

**デフォルトの名無しさん** · 2023/09/15(金) 22:34:16.16

そのRust批判を書いてる人もそうだが
意味のあるプログラミング経験の少ない人はmutを毛嫌いしてるよな

言語に関係なくミュータブルか否かの区別がある方が好ましく
ミュータブルの使用は必要最小限が好ましい
という当たり前のことに沿う仕様なのに理解できなくて批判

**デフォルトの名無しさん** · 2023/09/15(金) 23:11:51.65

>>219
ミュータブルか否かの区別があるのは煩雑になるだけで好ましくない。WindowsやLinuxのソースコードに
Rustが採用されたと言ってもごく一部でメモリ安全性が特に重視される部分だけ。全部をRustで書くなんて
煩雑な作業には人間はとても耐えられない。

**デフォルトの名無しさん** · 2023/09/15(金) 23:17:03.67

>>219
>ミュータブルか否かの区別がある方が好ましく
当たり前では

mojo調べでlet/var区別が好ましいと決着ついた
https://docs.modular.com/mojo/manual/basics/index.html#variables

rust mutが好まれてないだけ

>>220
let/varだと区別がありつつ煩雑じゃない、という事ですね

**デフォルトの名無しさん** · 2023/09/15(金) 23:24:01.30

それと
>>220
Linuxカーネル本体は当分Cのままで
デバイスドライバをrustで書く準備が出来た、だけですよ

**デフォルトの名無しさん** · 2023/09/15(金) 23:26:04.83

>>220
mutableとimmutableの区別は必須
それを煩雑という者は初心者のみ

>>221
色んなプログラミング言語をやってきてる者にとってそんな些細な記述方法を問題にするやつはいない
参照のある言語でmutableを区別するならばmut付加方式が合理的
例)　let mut x: &mut Type = ...

**デフォルトの名無しさん** · 2023/09/15(金) 23:28:27.24

あと前スレで出ていた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

**デフォルトの名無しさん** · 2023/09/15(金) 23:30:46.42

letの後に識別子しか書けないならlet/varでいいんじゃね
パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする

**デフォルトの名無しさん** · 2023/09/15(金) 23:31:04.61

ここはRustのスレ
的外れなRust叩きをしているバカはアンチスレへ移動しろ

**デフォルトの名無しさん** · 2023/09/15(金) 23:35:09.11

sudo-rsも v0.2.0でstableと言い切って知らないdistributionに
ねじ込んだようですがその後どうなるのか要チェックです

**デフォルトの名無しさん** · 2023/09/15(金) 23:43:02.23

mojoの所有権周りの構文ってRustより重い感じなんだな
これPython書きたいような人に受け入れられるんだろうか…

**デフォルトの名無しさん** · 2023/09/15(金) 23:44:55.11

>>225
>パターンが書けるならlet/varよりlet/let mutの方が合理的な気がする
気がする、ではなく
合理的だという説明が聞きたい

**デフォルトの名無しさん** · 2023/09/15(金) 23:47:42.54

>>221
たとえばRustでよくあるこういうパターンはmojoでどうするんだろう
let (tx, mut rx) = channel(100);
そもそも可変参照はどう区別するんだろうね
あと関数の引数変数のmutable性はどうやって表すんだろう
Rustのmutを添える方式が自由度が高くてわかりやすいよね

**デフォルトの名無しさん** · 2023/09/15(金) 23:48:06.93

>>228
どの辺りが重い感じ？

**デフォルトの名無しさん** · 2023/09/15(金) 23:52:51.61

>>231
borrowed, inout, owenedって全部キーワード指定だし結構長くない？
自分はRustみたいに明示的なのが好きだから多少長くてもいいけど
Python好きな人だとどうなんだろうって

**デフォルトの名無しさん** · 2023/09/15(金) 23:54:33.01

パターンマッチの場合束縛する変数が複数になり得るので、それぞれの変数に対して異なるmutabilityを宣言できる

あと、Rustは変数への束縛にmove/refの区別もあることも関係してるかもね
letやvarのように別構文を用意するなら、それぞれに対してmove版、ref版が必要になってしまう

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:25.63

let (foo, ref mut bar) = とかよく使うもんね
mutやrefが分離キーワードになっているRustが便利

**デフォルトの名無しさん** · 2023/09/15(金) 23:59:43.71

>>230
なるほどね
mojoでunpackがどうなるのか知らないけど
unpack用のlet/varシンタックスはあった方が良いね

let/var方式の他の言語を参考にするんだろうな

**デフォルトの名無しさん** · 2023/09/16(土) 00:02:44.62

>>234
>mutやrefが分離キーワードになっているRustが便利

これを突き詰めるとponyになるって5chで聞いたよw

**デフォルトの名無しさん** · 2023/09/16(土) 00:03:10.36

>>234
いや、今となってはrefはほとんど使わん

**デフォルトの名無しさん** · 2023/09/16(土) 00:26:11.63

TauriとTauri Mobileが別々の実装として統合されないの悪手だと思うんだがな
せっかくRustでロジック書けてネイティブ呼び出しまで簡単で手頃なフロントエンド実装で期待してたのにわざわざコミュニティ分断する必要あるんか？
なんかXamarinみたいな結末迎えそうで残念だわ

**デフォルトの名無しさん** · 2023/09/16(土) 09:10:27.83

T,o,k（迷惑という方は←をあぼーんしてください。）

更に家族に教えて加えて￥4000×人数をGET。
https://i.imgur.com/p75gBok.jpg

**デフォルトの名無しさん** · 2023/09/16(土) 09:55:59.18

>>238
無理に一つにしようとすると条件分岐増えてごちゃごちゃしてわかりにくくなる、というのはありそう。知らんけど。

**デフォルトの名無しさん** · 2023/09/16(土) 10:40:22.96

>>239
もう現金化してアンインスコしてる

**デフォルトの名無しさん** · 2023/09/16(土) 11:27:20.46

RustRoverを試してみる
https://zenn.dev/helloyuki/scraps/a0241df49b2556

**デフォルトの名無しさん** · 2023/09/16(土) 11:55:36.71

ウェブ系の奴らがやけにJetBrains推してくるけどAndroid Studio使ったら如何にゴミIDEなのかよくわかった
しかも個人使用でも買い切り数百ドルもしたのに今はサブスク月額1300円とかぼったくりもいいところ
VSCodeがあって本当によかったVSもCEならデバッガに制限あるけど無料だしこれほどMSに感謝したことはないね

**デフォルトの名無しさん** · 2023/09/16(土) 12:20:19.81

mut よりもShared XOR Mutableの方が難しいだろ。

**デフォルトの名無しさん** · 2023/09/16(土) 12:41:23.41

>>243
Android Studio は IntelliJ IDEA がベースになっていて無料の community 版があるが?
ていうか Android Studio の方は最初から無料じゃなかったか? 金取るやつあるの?

**デフォルトの名無しさん** · 2023/09/16(土) 12:57:41.63

>>223
let x: &mut Type = ...
でよくね？

**デフォルトの名無しさん** · 2023/09/16(土) 13:00:07.59

>>244
lifetimeが難しいというのも大体がshared xor mutableの話だしな

**デフォルトの名無しさん** · 2023/09/16(土) 13:07:54.84

>>246
それだとimmutableとなり変数値を書き換えできないから根本から違う

**デフォルトの名無しさん** · 2023/09/16(土) 13:23:53.43

描き替え出来るから問題無い

**デフォルトの名無しさん** · 2023/09/16(土) 13:57:40.01

>>249
ポインタ値の書き換えと
ポインタが指す先の書き換えの
区別がついていないのはCでも初心者レベル

**デフォルトの名無しさん** · 2023/09/16(土) 14:05:34.65

うん
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:06:34.42

refとmoveの区別がある言語とそうでない言語の構文比較しても仕方なかろう

**デフォルトの名無しさん** · 2023/09/16(土) 14:10:34.38

>>246
ダメです
全く異なります
let mut x: &mut Type = ...　←xの値を書き換えられる
let x: &mut Type = ...　←xの値を書き換えられない

**デフォルトの名無しさん** · 2023/09/16(土) 14:24:43.82

>>253
だから付ける必要無い所まで描く必要無いよね

**デフォルトの名無しさん** · 2023/09/16(土) 14:32:47.40

>>239
絶対に試すべきだね。

**デフォルトの名無しさん** · 2023/09/16(土) 14:37:19.47

>>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を欠くことはできません

**デフォルトの名無しさん** · 2023/09/16(土) 14:43:13.66

ほんまジャップはアホやな
しょーもない重箱の隅をつつきあって知識自慢のマウント合戦
そして出来上がった成果物は誰も使わないクソゴミ
ジャップがオナニーしてる間にソフトウェアは中国に30年遅れているという現実
お前ら見てるとマジで日本人がソフトウェアで土人の未開レベルな理由がよーくわかる

**デフォルトの名無しさん** · 2023/09/16(土) 17:08:24.37

まともなプログラミング言語ならばそれら四つの区別がある
例えば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を付けるかの些細な違いにすぎない

**デフォルトの名無しさん** · 2023/09/16(土) 17:14:29.95

参照の可変性という概念を持つ言語がそもそも少ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:15:13.87

概念が異なるのに構文の話だけをしても仕方ない

**デフォルトの名無しさん** · 2023/09/16(土) 17:34:04.75

参照先の値がread onlyかwritableかはプログラミングで極めて重要だよね
間違えて意図せず書き換えてしまっていたバグなどの減少にも繋がるから必要な機能じゃないかな

**デフォルトの名無しさん** · 2023/09/16(土) 17:37:07.29

>>258
2番目と4番目はRustだとsmellyなのでリファクタリング検討候補

**デフォルトの名無しさん** · 2023/09/16(土) 19:41:48.63

>>204が言ってるのはmutの区別が不要じゃなくて
良く使うmutable側でタイプさせんなってことでしょ

**デフォルトの名無しさん** · 2023/09/16(土) 20:04:56.12

ほとんどのプログラムではmutと記述すべきところが少ない
もしmutが多いならレアケースを除いてコードを改善すべき可能性が高い

**デフォルトの名無しさん** · 2023/09/16(土) 20:10:22.45

>>263
＞良く使うmutable側でタイプさせんなってことでしょ

お前、それプログラミングのセンス無いわ。
あ、もしかして使い捨てのコードしか書いたこと無い？

**デフォルトの名無しさん** · 2023/09/16(土) 20:12:22.58

>>263
慣れてきたらmutあんま使わなくて書けるようになるよｗ
関数型言語やってるとmut相当のもんなんて基本使わんのだし

**デフォルトの名無しさん** · 2023/09/16(土) 20:31:44.89

>>266
その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん

mut祭りで読みづらい代わりに高速でメモリ効率が良いのがRustの売りでしょ

**デフォルトの名無しさん** · 2023/09/16(土) 20:37:59.24

多い少ないの話したいなら定量的な根拠持ってきてくれ
根拠ないなら断言するのはやめて

**デフォルトの名無しさん** · 2023/09/16(土) 20:45:23.05

>>267
それは関係ない
まずRustのほとんどのプログラムでmut祭りになることはなくmutの出現は少ない
その上でRustはCとほぼ同じ程度速い

**デフォルトの名無しさん** · 2023/09/16(土) 20:50:47.30

どちらがより目立つべきかを考えたら
mutable なほうが目立つべきだし
目立って欲しい方に指定をつける文法が自然だ。

良く使うほうが短く書けるべきという視点だって
もちろん間違いではないし、評価軸は無数にある。

定量化したところでそれぞれの重みをどう捉えるかは
感性の問題だろ。

**デフォルトの名無しさん** · 2023/09/17(日) 12:16:37.26

>>211
Goでできない非同期処理って何？
channelとselectとgoroutineとsyncパッケージでなんでもできるけど

**デフォルトの名無しさん** · 2023/09/17(日) 13:48:53.24

>>271
例えばベアメタル環境での非同期とか？
まぁ大抵の環境でだいたい上手く行くってのがGoのいいところだから
別に悪くはないと思うけど

**デフォルトの名無しさん** · 2023/09/17(日) 17:36:59.55

毎日ちょっとずつ課題でてそれを解いていくようなRust勉強サイトってないの？
ナンプレ毎日１問クリアしていく感じなやつ

**デフォルトの名無しさん** · 2023/09/18(月) 01:48:58.76

>>273
exercism.org どうかな

**デフォルトの名無しさん** · 2023/09/18(月) 10:51:29.83

>>267
>その代償としてイミュータブルをコピーしまくってメモリ浪費して関数型言語遅いじゃん

Rustのことなら#[derive(Copy)]とか.clone()とか描いちゃだめだよ絶対

**デフォルトの名無しさん** · 2023/09/18(月) 12:04:31.40

>>267
エイリアス解析がやりやすくなって本質的に同じものなのか
複製が必須なのか自動で判断して最適化される。
プログラマが判断するよりたぶん賢い。

mut を付けるかどうかは性能じゃなくてロジック的な妥当さで決めるもんだよ。

**デフォルトの名無しさん** · 2023/09/18(月) 12:15:08.64

techempowerベンチ見るとrustと比較してgoがしょぼいけど
こんなものなの?

**デフォルトの名無しさん** · 2023/09/18(月) 12:28:49.50

つよつよプログラマがチューニングすれば際限なく性能を挙げられるという意味での性能の良さと
非プログラマがテキトーに書いても及第点程度の性能が出るというのは言語として両立しにくい。

仮にしょぼいのが本当だとしてもトレードオフになる何かがあったりするから
総合的な使用感は実際に使ってみないとよくわからん。

**デフォルトの名無しさん** · 2023/09/18(月) 12:39:00.83

>>277
GoはGC内蔵言語だから本質的に遅い
GC内蔵言語はGCするから遅いわけではなくGCのためにヒープメインにならざるをえないため遅い

**デフォルトの名無しさん** · 2023/09/18(月) 12:44:14.37

なんでもイミュータブルじゃなくて必要な時にミュータブルにしつつ安全性をコンパイラが保証してくれるのがいいんだよなぁ。

**デフォルトの名無しさん** · 2023/09/18(月) 13:13:11.65

そもそも、goはc#にすら負けてね?
1番高速じゃなくても2番目あたりでいいかなと思ってるんだけど
どれがいいのかなと

ななやむぐらいならわかりやすい1番にしとけばいいのか?

**デフォルトの名無しさん** · 2023/09/18(月) 13:16:25.44

goのgc調べてみましたが参照カウントとかじゃないのか

**デフォルトの名無しさん** · 2023/09/18(月) 13:54:07.10

Rustは見た目が汚いのが困る
もういっそCの方がきれいで安全で保守性が高いまである

**デフォルトの名無しさん** · 2023/09/18(月) 14:01:16.96

Cは大きなプロジェクトが汚すぎる
モジュールで名前空間分けられないから

**デフォルトの名無しさん** · 2023/09/18(月) 14:04:02.95

C言語は"安全装置のない銃"に徹しているからな
シンプルなだけに危険いっぱいだ

**デフォルトの名無しさん** · 2023/09/18(月) 14:43:26.49

C#はunsafeやSpanがあるので頑張れば結構速い
ネイティブコンパイルもできるようになってきたからとにかく速度を求めるようなアプリじゃなければ十分

**デフォルトの名無しさん** · 2023/09/18(月) 15:27:10.56

Rustもcrateのダウンロード数に応じて
crate開発者が課金される時代か
メシウマじゃなかった胸熱

**デフォルトの名無しさん** · 2023/09/18(月) 15:57:52.35

何の話かと思えばunityか

**デフォルトの名無しさん** · 2023/09/18(月) 16:04:36.29

とりあえずミュータブルの話をするならshared xor mutable に触れなきゃ意味ないし、それなら元ネタのトランザクション分離レベルぐらいは勉強しとかんといかん。

**デフォルトの名無しさん** · 2023/09/18(月) 16:05:47.88

>>285
C(C++含む)の真のヤバさはそれが周知されていないことだと思う
セキュリティ、セキュリティ吠えながら妄信的にC/C++使っているところとか普通にあるし

**デフォルトの名無しさん** · 2023/09/18(月) 17:52:28.36

>>283
＞もういっそCの方がきれいで

前置宣言だからそれは無い。

**デフォルトの名無しさん** · 2023/09/18(月) 22:02:21.17

>>291
前置宣言だから綺麗に書けるまである

**デフォルトの名無しさん** · 2023/09/18(月) 22:29:41.23

>>283
Rustは普通というか見た目キレイ側

**デフォルトの名無しさん** · 2023/09/18(月) 23:41:51.16

>>290
ロジックが正しくてもバイナリレベルでは脆弱性になることがある。
分かりやすい例では、言語の理屈では寿命を終えたはずのオブジェクトでも再利用される機会がなくて内容が残り続けるとかね。
そういうときにでもどうにかする知見が C/C++ では積み上がってる。

普通に書いて脆弱性が発生しにくいに越したことはないが、脆弱性が発生していることがわかったときに直せる確信があるというのはセキュリティが重要な場面で C/C++ を使う理由になる。
C/C++ が「自分の足を撃つ」ことになるなんてのは百も二百も承知の上で、「自分の足を撃つことも出来る」ことに価値を見いだしてるんだよ。
もともと自分の足を撃つというのは戦争に行かなくて済むようにわざと撃つことがあるというのを下敷きにした言い回しで、危険であると同時にそれが必要なこともあるというニュアンスを含んでいる。

**デフォルトの名無しさん** · 2023/09/18(月) 23:47:04.73

>>294
それRustに対するアドバンテージになってないな
むしろディスアドバンテージ

**デフォルトの名無しさん** · 2023/09/19(火) 07:20:03.69

>>294
目的のために敢えてUB引き起こすってこと？

**デフォルトの名無しさん** · 2023/09/19(火) 11:44:23.57

>>294
＞そういうときにでもどうにかする知見が C/C++ では積み上がってる。

所謂、バッドノウハウね。
そりゃさんざん今までやりまくって、なんなら現在進行形だったりするんだからノウハウも積み上がるさ。

**デフォルトの名無しさん** · 2023/09/19(火) 13:23:13.06

データベースのデータファイルの中の構造は、
C言語の「全部生メモリ」状態で、ポインタの
変わりにファイルポジションになっていて
普通に相互リンクトリンクやファイルポジション
をデータの位置を表現するのに使われていたりする。
だから、実行中のプログラムの RAM のメモリー安全
は確保されたとしても、ファイルの中は安全には
ならない。

**デフォルトの名無しさん** · 2023/09/19(火) 13:27:32.55

>>298
[補足]
・ポインターの代わりにファイルポジションが使用され、
　古来の plain C と同様のプロググラミングが行なわれている。
・LockFile や fnctl で「部分ロック」が当たり前
　のように使用されており、非常に複雑な
　配慮が必要なプログラミングになっている。

もっといえば、DBMS を使うアプリケーションも、非常に
配慮が必要な場合も多く、どのようなテーブルやカラム構造
にするかは難しい。ID番号をリンクしたり、どうやって
データを参照しあうかなどが生ポインタと同様の難しさ
を持っていて、わずかでも間違えば、全データが論理破損
してしまう可能性を持っている。

**デフォルトの名無しさん** · 2023/09/19(火) 14:54:41.30

だれか巻き込まれてないか？
https://www.youtube.com/watch?v=SzpaDEhm-8Q

**デフォルトの名無しさん** · 2023/09/19(火) 15:58:16.52

形式検証をrustに組み込むのってどれくらい現実的なんだろ
言語本体ではなくてproc macroで実現できるのかね

**デフォルトの名無しさん** · 2023/09/19(火) 16:39:15.02

>>299
一般的なDBMSは中央集権でページアクセスを一元管理してるから生ポインタとは全く質が異なる

**デフォルトの名無しさん** · 2023/09/19(火) 17:37:47.80

>>302
ただ、購入履歴などは「誰が購入したか」のIDを
購入項目テーブルとユーザーテーブルを結びつける
必要があるので、IDがポインタの役割になる。
わずかでも狂うと、別人が買った項目が結び付け
られてしまう。
値が1つ、または、行が一行でもずれるとほぼ全体が破綻する。

**デフォルトの名無しさん** · 2023/09/19(火) 18:14:50.54

DBでも何でもそうだけどshared xor mutableも必要

**デフォルトの名無しさん** · 2023/09/19(火) 18:23:26.80

販売サイトなどのバグって怖くて、500円のものが
バグれば5000円になったりする可能性ある。
そういうものは、プログラミングを気をつける
しかなくて、Rustの安全対策でも防げない。

**デフォルトの名無しさん** · 2023/09/19(火) 18:32:19.28

「気を付ける」の内訳にはテストを書く習慣とかが含まれてる。
気を付けないとしょうがないけど
気を付けるのに使える道具はそれなりに揃ってる。

**デフォルトの名無しさん** · 2023/09/19(火) 18:34:24.73

すべてのバグをなくせる言語がないのは当たり前
データ競合により起こるそういう値のバグも現実にあるのだからRustでその手のバグをなくせるのも事実