Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

前スレ
Rust part9
https://mevius.5ch.net/test/read.cgi/tech/1598112455/

◆QZaw55cn4c · 2021/05/05(水) 16:50:12.99

>>416
＞炎上学習法

懐かしい言葉ですね‥‥

**デフォルトの名無しさん** · 2021/05/05(水) 16:59:13.24

>>425
varにするようになったら全部varにするだろ？

**デフォルトの名無しさん** · 2021/05/05(水) 17:40:56.63

>>416
相手してるお前も同罪やぞ
すぐ見分けつくだろ

**デフォルトの名無しさん** · 2021/05/05(水) 18:09:53.05

VSCode + rust-analyzer だとletやメソッドチェーンのところに型が表示されるし
今時の開発環境使っていればローカル変数の型がぱっと見で分からなくて苦労することは少ないのでは

**デフォルトの名無しさん** · 2021/05/05(水) 18:14:24.50

>>427
何を言っとるんだお前は？
右辺値と同じ型で「困る」時は型を書くに決まってるだろ
下手するとvarの仕様も理解せずに混乱した事を書いてんじゃないだろうな

**デフォルトの名無しさん** · 2021/05/05(水) 18:51:20.46

ゲェーQZ居着いてんのかよこのスレ
バカなくせに出しゃばりでウザいからC++スレから出てくんなよ

**デフォルトの名無しさん** · 2021/05/05(水) 19:01:51.22

>>430
後から右辺値の型が変わったら気が付かないうちに影響が波及するじゃん

**デフォルトの名無しさん** · 2021/05/05(水) 19:41:05.57

var xの型が何であるかはxの初期化のときただ一度きりの右辺の型で決まるんｼﾞｬﾈｰﾉ
だとしたら後から右辺値の型が変わることに関して
varの導入で傷口が広がったことにはならない

**デフォルトの名無しさん** · 2021/05/05(水) 19:44:32.97

二回目以降の右辺値はxに対する代入でしかありえない
それらはxに対して（暗黙の型変換等を経て）代入可能ならコンパイルが通るし、
代入不可能ならエラーになる。
xの初期化時にvarを使おうが使うまいが（明示的に型を書こうが）変わらない話

**デフォルトの名無しさん** · 2021/05/05(水) 20:38:12.35

せめてletの話をしろよ

**デフォルトの名無しさん** · 2021/05/05(水) 20:48:36.67

RustのletはJS由来？　それともHaskell？

**デフォルトの名無しさん** · 2021/05/05(水) 21:09:59.09

JavaScriptにもletあるけど語源調べたら普通に英単語のletで短縮形ってわけじゃないらしい

**デフォルトの名無しさん** · 2021/05/05(水) 21:24:20.68

BASICの時代からletはあったけどな

**デフォルトの名無しさん** · 2021/05/05(水) 21:31:43.51

letはlisp系から始まったイメージ。

**デフォルトの名無しさん** · 2021/05/05(水) 22:26:24.94

RustのletはML系由来だろ

**デフォルトの名無しさん** · 2021/05/05(水) 22:44:48.04

最初のrustcはocamlで書かれてたくらいだしML系の影響は色濃そう

◆QZaw55cn4c · 2021/05/05(水) 22:49:49.94

>>431
https://mevius.5ch.net/test/read.cgi/tech/1610096040/839

**デフォルトの名無しさん** · 2021/05/06(木) 01:02:12.67

let mut にするか var にするかの決定で、
目立たないけどRustに貢献した人という記事が最近書かれたので貼っとく
https://brson.github.io/2021/05/02/rusts-most-unrecognized-contributor

**デフォルトの名無しさん** · 2021/05/06(木) 01:05:25.16

>>443
3行でまとめて

**デフォルトの名無しさん** · 2021/05/06(木) 01:35:02.38

デイブ・ハーマン（Dave Herman）というECMAScript委員会のMozillaの代表者の人がいました。
リポジトリ上のコミットログでは目立ちませんが、彼の好みがRustチームの好みを作り、チームの組織と維持に重要な役割を果たしていました。
彼はチームの決定をほとんど穏やかに受け入れていましたが、let mut と var のどちらにするかについては var を使うというチームの決定に同意しませんでした。

**デフォルトの名無しさん** · 2021/05/06(木) 01:36:11.91

>>421
でも、
BYTE c = 'a';
と
let c = 'a';
では間違い易さが違う。後者は、int か BYTE か SBYTE か分からない。

**デフォルトの名無しさん** · 2021/05/06(木) 01:37:37.69

Rustだと、明示するには、
let c:i8 = 'a';
とキータイプが多くなってしまうな。

**デフォルトの名無しさん** · 2021/05/06(木) 01:40:47.77

例えばの話、演算子も優先順位が決まっているので、
if ( (a >= 5 && a <= 10) || (b>=10 && b <=20) ) {・・・}
見たいな条件も、優先順位の括弧を省略できるかも知れないが、勘違いや
記憶違いを防ぐために書いた方がいいと言われている。
int c = 'a';
char c ='a';
auto c = 'a';
ではやはり、autoはバグの原因になりそう。

**デフォルトの名無しさん** · 2021/05/06(木) 01:47:50.96

それと、型を明示した方が後から見たときにプログラマの脳内の想定もわかり易い。
float a = 1.0f;
float b = a + 5.0f;
みたいなものも、もし、
auto a = 1.0f;
auto b = a + 5.0f;
と書くと b は、double 型になってしまうかもしれないが、テストしても
間違いに気づかず、僅かに速度低下やメモリーを多く食ってしまう
かもしれない。また、思想にもよるが、1.0f などと書かずに
float a = 1;
float b = 5;
と書きたい人も居ると思う。これの方が、後から double 型に変えたときに
右辺を訂正する必要がないメリットもある。

**デフォルトの名無しさん** · 2021/05/06(木) 03:19:29.71

>>446
rustの文字リテラルはu8でもi8でもなくてcharな

それはそれとして型やら括弧やらを明示的に書くことは禁じられてないんだから書けばよいのでは
言語の問題というよりはコーディング規約でなんとかすべき領域かと

タイプ数が多くなるとかはデフォルトをどちらに倒すかの問題で世間の嗜好とずれてるなら多少手間がかかるのは諦めるしかない

**デフォルトの名無しさん** · 2021/05/06(木) 03:21:51.36

誤解を招きそうだから補足しておくとrustのcharはユニコードのコードポイントが格納される32bit符号なし整数型な

**デフォルトの名無しさん** · 2021/05/06(木) 06:46:11.97

>>443
こういうのいいな

**デフォルトの名無しさん** · 2021/05/06(木) 10:08:34.61

>>445
var使おうとしてたってマジかー
let (mut a, b) = get_foo_tuple();
みたいなやつとかvarじゃ困るから必然だと思ってたのに

**デフォルトの名無しさん** · 2021/05/06(木) 10:15:22.90

>>445の要約の最後たぶん間違ってる
デイブ氏はキーワードを重ねるとmutableな変数の使用を躊躇させる効果が生じて
プログラマのコーディング方式の選択を咎めることになるから反対だったらしい
チームの決定は初めからlet mutで彼は（珍しく）反対したけど最終的には受け入れた

**デフォルトの名無しさん** · 2021/05/06(木) 11:35:13.23

つまり暗黙の型変換は癌

**デフォルトの名無しさん** · 2021/05/06(木) 11:48:56.26

varでいいじゃん
あとはideが勝手に型直してくれるよ

**デフォルトの名無しさん** · 2021/05/06(木) 11:52:26.38

いないいない

**デフォルトの名無しさん** · 2021/05/06(木) 14:35:25.59

>>454
すまん、指示代名詞の指してる先を読み違えた
デイブ氏はvar押しだったんだな

**デフォルトの名無しさん** · 2021/05/06(木) 16:00:35.75

タイプ数で優劣を決めようとするアホとは次元が違うな

**デフォルトの名無しさん** · 2021/05/06(木) 16:31:20.99

タイプ数は少ない方が問答無用で良い

**デフォルトの名無しさん** · 2021/05/06(木) 17:13:47.97

fn, ret, cont, break の時代に回帰するか

**デフォルトの名無しさん** · 2021/05/06(木) 17:27:07.40

タイプ数は少ない
って基本型が少ない言語が好みなのかと思った

**デフォルトの名無しさん** · 2021/05/06(木) 19:28:16.24

<?rust
println!("hello rust!!");
?>

**デフォルトの名無しさん** · 2021/05/06(木) 21:17:13.93

>>448
型を明示したってバグるくせによく言うのぜ

**デフォルトの名無しさん** · 2021/05/06(木) 22:42:35.79

タイプ数が少ないようが絶対良いんなら
むかしGAMEとかいうすべてのキーワードが1文字の言語があったからそれでも使え

**デフォルトの名無しさん** · 2021/05/06(木) 23:22:18.38

Rust ～地図にない場所～

**デフォルトの名無しさん** · 2021/05/07(金) 03:50:05.38

>>464
型明示はバグの軽減に繋がる。
>>465
絶対的に良いわけではないが、let a:i32 = 5; と int a = 5; だと後者の方が楽。

**デフォルトの名無しさん** · 2021/05/07(金) 07:04:16.43

>>467
intが32bitだといつから錯覚していた？

**デフォルトの名無しさん** · 2021/05/07(金) 08:21:08.42

Announcing Rust for Windows v0.9
https://blogs.windows.com/windowsdeveloper/2021/05/06/announcing-rust-for-windows-v0-9/

**デフォルトの名無しさん** · 2021/05/07(金) 09:19:02.07

言ってる側から落とし穴に嵌っててワロタ

**デフォルトの名無しさん** · 2021/05/07(金) 10:35:21.40

let a = 5_i32;

型は右側だけで決めるのじゃ
両側で合わせるのは無駄、変更するときも面倒じゃろ

・・なに？
aがi32だと明示してバグを軽減したいじゃと？

それなら行を分けるのじゃ
１行にまとめるとせっかくの明示が埋もれてしまうからの

let a: i32; // この行の存在は大きいぞい
a = 5_i32;

**デフォルトの名無しさん** · 2021/05/07(金) 12:08:53.04

>>468
そこまでいうなら、int32 a = 5; や i32 a = 5; と書けばいい。
なお、Rustではこの書き方が出来ない。

**デフォルトの名無しさん** · 2021/05/07(金) 12:20:12.52

>>468
ちなみに、組み込み以外のほとんどのC/C++コンパイラでは、intは32BIT型。
デスクトップマシン用のC/C++では、32BIT/64BIT のどちらでも、intは、
32BIT型のはずで、少なくとも VC++では必ず int は 32BIT。

**デフォルトの名無しさん** · 2021/05/07(金) 12:24:00.34

>>472
int32_tな

**デフォルトの名無しさん** · 2021/05/07(金) 12:51:05.27

>>474
typedef int int32;
typedef int i32;
とすればよいだけ。

**デフォルトの名無しさん** · 2021/05/07(金) 12:57:04.52

>>475
それintが32bitじゃない環境でアホみたいにミスリーディングになるけど？
いい加減スレチだし「int32_t 標準ライブラリ」でググって理解したらこの話終わりにして？

**デフォルトの名無しさん** · 2021/05/07(金) 13:31:50.44

>>476
そんな基本的なことは当たり前で、そのような環境では、
typedef __int32 int32;
typedef __int32 i32;
とする。

**デフォルトの名無しさん** · 2021/05/07(金) 13:40:18.27

どういうバグを作る可能性があるかという点が共有されてないから議論空回りしている感

**デフォルトの名無しさん** · 2021/05/07(金) 13:42:32.36

というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
だと思ったんだ。もし、int32_t が使える環境で賢く使いたい人は、
typedef int32_t int32;
typedef int32_t i32;
typedef int32_t Int32;
などとすればいいという話。
前提とする知識が低すぎる人がいるから困る。

**デフォルトの名無しさん** · 2021/05/07(金) 13:45:35.27

何を議論してるのか全然分からん

**デフォルトの名無しさん** · 2021/05/07(金) 14:02:25.02

1レス目で即NG
相手してるやつも同じカテゴリなので即NG

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 14:03:01.68

議論なんかするつもりがないんだろう。

**デフォルトの名無しさん** · 2021/05/07(金) 14:40:46.39

>>479
>というか、int32_t という型名を考えた人が馬鹿すぎるので、長くて困るという話
>だと思ったんだ。

誰がどこでそんな話をしたのか
ログ辿っても全然分からない件

ついでに言えば
グローバル名前空間の中に標準ライブラリがブチ込む型名として
_tサフィックス以外あり得んので
何も馬鹿なことなんか無い
つーか本当に誰もそんな話してないな

これ突っ込んだら
どんなガイジレスを返すのか興味津々

>>480
論点不明のドッジボールだからな
今はどこでも似たようなやり取りが見られて
5ch終わってる感がハンパない
俺は句点付きが特に頭おかしいと思うけど
レスバ相手はEQがヤバイ感じだが
句点付きはIQがヤバイ

**デフォルトの名無しさん** · 2021/05/07(金) 14:57:30.94

メジャーなGUIアプリで使われているrust製GUIライブラリってなにがありますか？
GUI使いたいんですが長いものにまかれたいので

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 15:02:55.52

>>484
プラットフォーム (OS) によって違うんじゃない？
その中ではある程度に淘汰されてると思うけど、
あらゆる環境で万能な決定版は無いと思う。

**デフォルトの名無しさん** · 2021/05/07(金) 15:53:14.60

>>483
>句点付きはIQがヤバイ
実際にIQ150越えてるので、ノーマル一般人が理解できないだけではないか。

**デフォルトの名無しさん** · 2021/05/07(金) 16:08:00.06

>>486
証拠うpしてくれ
ID付き画像とかなら最高だ
IQ150超えでもこんなガイジレスするのか
マジで興味あるわ

**デフォルトの名無しさん** · 2021/05/07(金) 17:04:02.49

メモリ不足でカーネルパニックが起きることの問題がわからない
普通のパソコン用途に使われてたらユーザーランドのソフトがOOM Killerに殺されようがOS丸ごとクラッシュしようが作業内容が失われるのは変わらん
サーバー用途でも一部のプロセスが殺されて中途半端の状態で動き続けるよりいっその事OSまるごとクラッシュしたほうがいいと思う

**デフォルトの名無しさん** · 2021/05/07(金) 17:16:13.01

>>488
rustでLinuxのドライバー書く話？
メモリ不足時にどうハンドリングされるべきかは使い方によって違うので一律パニックするのは良くない
例えば例に挙げてるOOM Killerだってカーネルがパニックしたら実行されないわけで

**デフォルトの名無しさん** · 2021/05/07(金) 17:22:12.18

>>488
何かあった時止まればいいシステムばかりじゃないだろ
ペースメーカーとか原子炉とか
細かいことは知らんけど
昔、組み込み屋のおっさんが最初から1Mぐらい確保して
何かあったらそれを解放してどうにかするみたいなこと言ってた
知らんけど

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/07(金) 18:25:34.58

>>488
システムは単独で動いているわけではない。
カーネルがパニックすることがあって良いという前提で設計して、パニックしうる前提で運用できるならそれでも構わんのだが、
Linux のカーネルでパニックを許すなら今 Linux を基礎にしているあらゆるシステムの運用体制を見直さざるを得ない。

カーネルパニックが絶対に駄目というわけじゃないんだ。
(もちろん発生しないに越したことは無いが。)
Linux では起こさないという前提に皆が従っているので変えられないという話なんだよ。

**デフォルトの名無しさん** · 2021/05/07(金) 18:53:57.67

割り込みが飛んでくる環境で例外なんか扱おうとしたら普通に死ぬだろ

**デフォルトの名無しさん** · 2021/05/07(金) 19:12:04.63

>>488
失われる作業内容の範囲があるだろ。
クライアントOSのWindowsですらBSODで切れる奴が多かったんだから、サーバーOSでそんな考えが許されるはずがない。

**デフォルトの名無しさん** · 2021/05/07(金) 19:35:24.51

差し当たりRustの言語を広く浅く学習したいのですが、「実践Rustプログラミング入門」の言語部分(100ページ程度)が分量が少なめで気になっています
この本で大きく抜けている文法や機能ってありますか？

**デフォルトの名無しさん** · 2021/05/07(金) 20:06:32.24

>>494
The Bookと比べれば一目瞭然

**デフォルトの名無しさん** · 2021/05/07(金) 20:11:06.98

>>493
サーバーOSのほうがクライアントOSよりクラッシュには寛容だぞ
サーバー側の開発したことないのかな？

**デフォルトの名無しさん** · 2021/05/07(金) 20:22:58.56

>>496
最近は仮想化＆分散で寛容になっているの？

**デフォルトの名無しさん** · 2021/05/07(金) 21:23:40.41

>>494
最近の本だからasyncまであるし、そんなに大きな抜けはないかな
広く浅くならまぁいいんじゃないかと
もし細かい部分が気になったらthe bookで補完すればいい

**デフォルトの名無しさん** · 2021/05/07(金) 21:36:25.19

>>497
むしろchaos engineeringで積極的に落とす

**デフォルトの名無しさん** · 2021/05/07(金) 21:52:45.82

ペースメーカーとか原子炉とか、ノンストップシステムでは常に複数動いている

Kubernetes などでは、ネットワーク分断に備えて、
正常な状態を多数決で決めるから、3, 5, 7 みたいな奇数を動かす

2対2とか偶数だと、どちらが正常か判断できないから

**500** · 2021/05/07(金) 22:00:09.91

Netflix などは常に、システムを攻撃して落としたりして、テストしてる。
サイボウズのkintone は、毎日システムを破棄して、作り直しているとか

Kubernetes を使っているのかな？

**デフォルトの名無しさん** · 2021/05/08(土) 00:03:29.89

非常時の処理はカーネルの中心部が決めることで
枝葉のモジュールに決定権はないという話なんじゃないの？

**デフォルトの名無しさん** · 2021/05/08(土) 00:07:56.54

レイヤーがめちゃくちゃな話しとるな。
OSみたいなハードウェアに直触るものとkubernetesみたいな分散管理のソフトじゃ
全然話が違う。
実際kubernetesはGC付きのgolangが実装だろ。

**500** · 2021/05/08(土) 01:02:28.51

ノンストップシステムでは常に複数動く。
デュアルシステムとか

東証・富士通製のarrowhead は、3重だったかな？
それでも、ラックか何かの接続部分が落ちて、システムダウンした

ネットワークが集中している部分の故障が、最も怖い

**デフォルトの名無しさん** · 2021/05/08(土) 08:40:46.17

>>492
なんでじゃ
割り込みルーチンに入るときの退避と出るときの復旧をきちんとやっていれば
割り込みルーチン以外の処理は割り込みルーチンが呼び出されることに対して透過的に動作できる
一部のハードなリアルタイムOSみたいに（多重割り込み前提で）割り込みルーチンから
通常コンテキストに直接「ジャンプ」してタスクをたたき起こすみたいなケースでもなければ割り込みの存在は
通常コンテキストで何をやろうと一切影響は無い
（もちろん割り込み禁止、みたいな直接割り込みに影響する命令を実行したら話は別だがそれは普通特権命令でOS以外は実行できな
　い

カーネルでの例外が問題なのは、
例外機構を持たないCならスタックポインタの調整で済むところを
デストラクタがある高級な言語だと例外が通過する際に自動変数として構築されていたオブジェクトを
例外が通過する関数全てについて解放してやらねばならない
（それでいて一方、自動変数として構築される可能性はあっても
　例外発生時に構築されていないオブジェクトに対しては何もしてはいけない
という点
これは例外を飛ばすだけでその経路全部が同一のコンパイラで書かれなければならないことを意味する
途中に手で書いたアセンブラのルーチンなどあろうものならスタックをぶち壊してハードウェアの例外でいきなり
落ちるということになってそんなことがOS内で起きたら計算機上の資源の安全が担保されない。
OSとしては失格である

**デフォルトの名無しさん** · 2021/05/08(土) 08:53:39.11

、と思ったが
よく考えたら「手で書いたアセンブラのルーチン」があったらコンパイラはそれを知らない関数としてスタックポインタの調整以外のことを
しなかったら良いのかorz、
ここは「例外通過時にC++や異なるベンダーのRustコンパイラみたいな例外を捕捉する関数をコンパイルいたRustコンパイラが預かり知らない
巻き戻し処理が必要なルーチン」があったら、ということに訂正
、

**デフォルトの名無しさん** · 2021/05/08(土) 09:44:38.32

なんだこいつ
IQ64だな

**デフォルトの名無しさん** · 2021/05/08(土) 10:15:07.28

IQは関係無いやろうがｷﾞｷﾞｷﾞｷﾞｷﾞ、

**デフォルトの名無しさん** · 2021/05/08(土) 11:11:59.29

JAVAみたいな言語があるからnewしたまま放ったらかしでメモリ管理もろくに出来ない馬鹿で溢れかえって居るんだよな

**デフォルトの名無しさん** · 2021/05/08(土) 11:36:05.31

ついさっき知ったけど、new() はT だけじゃなく Result<T> を返していいんだな

**デフォルトの名無しさん** · 2021/05/08(土) 12:01:48.48

newはシンタックスじゃなくてただの慣例だからね
慣例ではResultを返すのはお作法に反するはず

**デフォルトの名無しさん** · 2021/05/08(土) 12:03:38.57

別にjavaがない頃からそういうバカはいたけどね

**デフォルトの名無しさん** · 2021/05/08(土) 12:09:19.46

メモリ管理もろくに出来ない馬鹿
・Linuxカーネルにカーネルスタックメモリ内の情報を読み取られる脆弱性
・「WebKit」にゼロデイ脆弱性～「macOS Big Sur 11.3.1」や「iOS/iPadOS 14.5.1」などが公開
・BIND9に脆弱性、アップデートや回避策を

**デフォルトの名無しさん** · 2021/05/08(土) 12:14:25.93

>>509
因果関係が逆で、
頭が悪くてその程度ももともと出来ない人は昔はCやC++でプログラムできなかった
がVBやJavaやC#やJSやPythonやRubyではできた。

**デフォルトの名無しさん** · 2021/05/08(土) 13:11:23.63

>>511
newとかfromでResult返すのたまに見かけるけど
どうするのがおすすめなの？
try_newとかtry_fromにするのが良いのかな

**デフォルトの名無しさん** · 2021/05/08(土) 13:37:14.67

>>511
ただの慣例じゃなくて、clippy先生の指導対象らしい
https://rust-lang.github.io/rust-clippy/master/#new_ret_no_self

Checks for new not returning a type that contains Self.

**デフォルトの名無しさん** · 2021/05/08(土) 14:30:50.83

手動でスタックポインタの調整ってバグや脆弱性の温床じゃね？

**デフォルトの名無しさん** · 2021/05/08(土) 17:15:39.08

医療機器や原発の制御システムとかが不意にリセットしないとか思っている時点で
組み込みとか高信頼性システムとかを全く知らないんだなって思う
ああいうのは最悪暴走したらリセットして最低限の機能は提供出来るように
作るのが基本だからね。そうしないと想定外の事態がおきた時に詰む

**デフォルトの名無しさん** · 2021/05/08(土) 17:18:46.34

そんなコーナーケースの為に俺たちの使い心地が悪くなるようなら耐えられないな

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/08(土) 17:23:48.71

暴走した場合にでもうてる手札を用意しておくってのと、
暴走しないように細部まで検証しておくってのは両立する話

**デフォルトの名無しさん** · 2021/05/08(土) 17:27:07.74

いうほどコーナーケースってほどでもないだろ。
割と考慮されて当然のケースだわ。
まあlinux単体がその品質を担保できてるとも思わんけど。

**デフォルトの名無しさん** · 2021/05/08(土) 17:33:15.67

原子力関係だけでなく航空機や宇宙機もだが制御不能になるのが一番ヤバイんで
バグ出しは常識的な範囲で行って、あとはリカバリ系に注力した方がシステムの信頼性は向上する
歴史的に見ても事故るシステムの多くはこの辺をガバっている事が多いし

**デフォルトの名無しさん** · 2021/05/08(土) 17:57:46.72

別に
ハイテク旅客機が落ちるのは自動制御と手動操縦のモード切替仕様を
パイロットが熟知しておらず緊急時に操縦桿を奪い合う格闘になったから
であってソフトは仕様通りだった
『ハイテク飛行機はなぜ落ちるか』（ブルーバックス）のｲﾝｼﾃﾞﾝﾄの数々を見たらﾜｶﾙ

原子炉の制御系はそもそも暴走させないように金かけて形式検証する

人間が本気になったらどんだけバグをなくすために金と手間を掛けられるかというと
スペースシャトルのSSMEの制御装置のソフトがどんだけ徹底したデバッグが行われたかを見たらﾜｶﾙ

**デフォルトの名無しさん** · 2021/05/08(土) 18:17:53.56

>>523
人間が使う物であればUIも当然システムに含まれる
判りにくいUIは良いシステムとは言えない

ソユーズや神舟はADA使ったりしていないけど
スペースシャトルより死人は少ない。米式が唯一の正解とは限らない
むしろスペースシャトルはシステム設計に失敗した例だろ

**デフォルトの名無しさん** · 2021/05/08(土) 18:22:37.13

UIの仕様バグと>>518が言っている暴走する系のバグは話がちげう