Rust part14

**デフォルトの名無しさん** · 2022/02/12(土) 01:24:16.59

公式
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を学びたい人はまず最初に公式の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/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

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

**デフォルトの名無しさん** · 2022/03/08(火) 02:05:41.64

>>257
普通に書いたら遅くなるコード例が欲しかったんですがこれは何をしようとしていて何が遅くなっているんですか？

**デフォルトの名無しさん** · 2022/03/08(火) 02:21:08.30

>>262
お前が誰かなんて知らねーし、すでに自分で探せと言ったものを何度も他人に聞くなよｗ本当に頭悪いなｗ

**デフォルトの名無しさん** · 2022/03/08(火) 02:27:22.25

おれのコードか? 欲しけりゃくれてやるぜ… 探してみろこの世の全てをそこに置いてきた(ﾄﾞﾝ

**デフォルトの名無しさん** · 2022/03/08(火) 02:27:39.29

>>263
どの書き込みに対するレスかすら確認せずに反論してたのか...すごい

**デフォルトの名無しさん** · 2022/03/08(火) 02:38:10.27

レスは適当に追うけど、長すぎんだよｗ
複数に答えてるところで分岐があるんだし、かなり前のお前のレスを読まないと分からない内容にしてるお前の頭が悪いだけｗ
しかも断られた内容を「自分の頭が悪くて...どういうものなのか想像もできないので...だけでも良いので教えてください」と懇願するほどの馬鹿ｗ
再度断られると煽りはじめ、しかもしつこく深夜まで…やばいってお前ｗ

**デフォルトの名無しさん** · 2022/03/08(火) 03:00:25.45

>>266
うんうん、わかったわかった
「普通に書いたら遅くなるコード例」はあなたからは出てこないのね
それならこれ以上やりとりしてもお互い無益なのでやめましょう
何度もレスさせてごめんね
こんな遅くまで付き合ってくれてありがとう

**デフォルトの名無しさん** · 2022/03/08(火) 04:06:31.78

>>267
はじめに断ってんだろｗ二度断ってなお煽ってきて何いってんの？ｗ確信犯がそれで許されるわけねーだろｗ
二度と書き込みませんと宣言したら許してやるｗ

**デフォルトの名無しさん** · 2022/03/08(火) 04:29:07.10

名だたる企業がRustについての肯定的なレポートを出しているが、それも誤りだというのか？
誤りではないが、だからといってシェアがとれるわけではないというのか？

**デフォルトの名無しさん** · 2022/03/08(火) 05:04:17.68

特定のシチュエーションで肯定的という事実だけ
それを元に何かを想像するのは自由だが、どの領域でどこまでシェアを伸ばせるかについては想像に過ぎない
さも名だたる企業が領域とシェアについて言及してるかのごとくに言い広めるのは良くない

**デフォルトの名無しさん** · 2022/03/08(火) 06:10:54.51

何もかもソース無し個人の感想で草

**デフォルトの名無しさん** · 2022/03/08(火) 06:19:02.05

自分で見つけられない人は可哀想ｗどこまでも煽っていくスタイルなんですねｗ

**デフォルトの名無しさん** · 2022/03/08(火) 06:35:46.51

>>270
名だたる企業が安全だと言っている事実に誤りはないのかね？
速度もCと互角と言っているのは？

**デフォルトの名無しさん** · 2022/03/08(火) 07:07:05.39

就寝したかな？

**デフォルトの名無しさん** · 2022/03/08(火) 13:19:25.26

C#ってWindows限定じゃなきゃ選択肢に上らない。いつMSがやーめた、今度はこっちにするわって言い出すかわからんもん。Rustはどうかな？

**デフォルトの名無しさん** · 2022/03/08(火) 14:18:20.87

MSがやめたら進化は止まるかもしれんが使えなくなるわけじゃないだろ

**デフォルトの名無しさん** · 2022/03/08(火) 14:44:27.03

>>275
いつの時代の話だよw

**デフォルトの名無しさん** · 2022/03/08(火) 14:57:59.41

言語に関してはMSはディスコンしてもサポートがめちゃ長いから比較的安心

D言語みたいなのでもまだ続いてるからRustも今のところ心配する必要ない
衰退し始めたら気長に移行すればいい

**デフォルトの名無しさん** · 2022/03/08(火) 18:06:02.16

>>274
昼過ぎに起きて一斉に書き込んでるね
よー寝るやつだw

**デフォルトの名無しさん** · 2022/03/08(火) 18:21:13.99

>>279
だなー、他のスレにも同じ時間帯に書くからわかりやすいわ

**デフォルトの名無しさん** · 2022/03/08(火) 22:24:39.58

非同期関数(非同期タスク)について質問です
単純に読むとか書くとかなどは非同期関数を呼んで待たされる(=待たせてくれる)のでawaitで待てばよいのですが
何かある仕事を専門にする人がシングルトン的に存在していてそこへ仕事を依頼して非同期に結果が出たら結果をもらう場合は
Rustではどうするのが効率がいいのでしょうか？
例えばコールバックをしてもらうとか
チャネルをもらってその読み出しで待つとか
スケジューラーの中で寝て待って起こしてもらうとか
その他など各々の可能不可能とメリットデメリットと具体的な方法が知りたいです
それに加えてタイムアウト付きで結果がまだ出ずとも時間内に戻りたい場合はどうなりますか？

**デフォルトの名無しさん** · 2022/03/08(火) 22:42:13.35

必要な機能をもった非同期ランタイムを選択する。
自分でやるなら unsafe でやることになるだろうけど本当にしんどい道のりになると思う。

**デフォルトの名無しさん** · 2022/03/08(火) 22:59:43.72

全然具体的でなくて草ｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/08(火) 23:20:38.55

ちょっと前提が異なるけど参考情報
hyperの中核となっているService traitは非同期コールバック方式
これでサーバーもクライアントもDNS解決もコネクション張るのも全てやっている

**デフォルトの名無しさん** · 2022/03/08(火) 23:28:46.08

>>281
select_all使えばいいと思う

**デフォルトの名無しさん** · 2022/03/08(火) 23:48:42.33

例えばhyperでサーバーがHTTPリクエスト受けるのにも二段のimpl Serviceが使われていて
一段目はコネクションが張られる毎
二段目はそのkeepaliveで複数回になりうるHTTPリクエスト毎

>>285
タイムアウトはその合成でいけるね

**デフォルトの名無しさん** · 2022/03/08(火) 23:52:54.53

古き良きselectを使わないやつはunsafeにまみれるがいい！
$ cargo geiger

**デフォルトの名無しさん** · 2022/03/08(火) 23:53:52.79

// こんな人向けの話
#[tokio::main]
async fn main() {
async {
println!("{}", "こんにちは世界！");
}.await;
}

**デフォルトの名無しさん** · 2022/03/09(水) 10:50:10.12

だけど今さらJavaを選択しないだろ。終わりの始まりはOracleがSUN Microsystemsを買収したとき。

**デフォルトの名無しさん** · 2022/03/09(水) 10:56:14.10

>>202
補完の効かないHTMLモドキ書くの辛ぽよな
VDOM系ならsauronがmacro以外でも書ける
個人的にはSilkenwebかな

**デフォルトの名無しさん** · 2022/03/09(水) 12:12:27.95

>>289
世の中web系ベンチャーばかりじゃないので…

**デフォルトの名無しさん** · 2022/03/09(水) 12:23:18.65

>>289
もちろん今となってはJavaを使う意義は全く無いが
Javaしか使えない(人材しかいない)遅れたところも存在している

**デフォルトの名無しさん** · 2022/03/09(水) 12:49:32.47

>>281
結局どこかで同期(待ち合わせ)したいならば
(1) 条件を満たしたらReadyになる自作Future<Output=T>を受け取りfuture.awaitで待つ
(2) lockされた非同期Arc<Mutex<T>>を受け取りmutex.lock().awaitで待つ
(3) 非同期channel::Receiver<T>を受け取りreceiver.recv().awaitで待つ
これらawaitの前の部分はfutureなのでタイムアウト付きにしたいなら
非同期timeout(duration, future).awaitで待つ　または非同期sleepを使って
futures::future::select(future, sleep(duration))で任意の仕様で作成可
さらに多くのfutureが関係するならselect_all

**デフォルトの名無しさん** · 2022/03/09(水) 13:01:08.14

悩ましいのが非同期処理待ち合わせにおけるタイムアウトしたときなどのキャンセル処理だな

**デフォルトの名無しさん** · 2022/03/09(水) 13:05:17.06

unsafeに屈してtokio/mioベースでウェーイし、二度と安全などと申しません！するのが普通
これは踏み絵なのだ

**デフォルトの名無しさん** · 2022/03/09(水) 18:04:37.99

マクロのdslは補完が効かないのか

**デフォルトの名無しさん** · 2022/03/09(水) 19:04:55.67

>>294
タイムアウトもしくは多数のfutureから先着一択した場合でも
残りのfutureは手元に残るしその出自も把握しているわけだから
用途ごとに必要なキャンセル処理を用意したり実施したりすればよいだけ
これは非同期でなく同期で全体の処理時間にタイムアウトを設けた場合でも起きる話

**デフォルトの名無しさん** · 2022/03/09(水) 22:19:31.86

async/awaitなどを使わないとしても、その手の処理を実装するなら通常は非同期I/Oを使用する
もしくは同期I/Oを別スレッドから強引にclose/shutdownする
なので、非同期I/Oを使用せずに綺麗に実装するなら、常に終わるまで待つか、キャンセル自体、つまりタイムアウトを諦めるのが普通
だから非同期を使うのであれば速度優先unsafe党に入り、RustはC/C++よりちょっと遅く、C/C++同様安全でない言語です！と懺悔しながら他の言語に許しを乞う必要があるｗ

**デフォルトの名無しさん** · 2022/03/09(水) 23:10:28.68

>>298
プログラミングしたことないためにunsafeが何かをわかっていない人だ
わかってないからブレて毎回主張に自己矛盾

**デフォルトの名無しさん** · 2022/03/09(水) 23:16:40.46

>>298
いつコテハンするの？

**デフォルトの名無しさん** · 2022/03/09(水) 23:23:01.29

僕ちゃん達にはむじゅかししゅぎましたかねｗ

**デフォルトの名無しさん** · 2022/03/09(水) 23:29:33.27

>>301
そんな単純な煽りはつまらんから
もっともらしいデタラメ並べた長文よろ

**デフォルトの名無しさん** · 2022/03/10(木) 05:39:25.09

このスレ以外でも思うんだけど
言語アンチって何が目的なの？
嫌なら使わなきゃいいだけだし
他に良い言語があると思うならそれ使えばいいじゃない

特にrust使う人なんてほぼ他の言語経験者なんだし
適材適所で使う言語選んでるでしょ
わざわざこのスレに来てrust批判したり他言語マンセーしたりしたとこで
大半の人は必要なら使うし必要ないなら使わない
余りにも不毛だからそういうのやめて欲しいわ

**デフォルトの名無しさん** · 2022/03/10(木) 05:43:47.53

俺はRustの話しかしてないんだがｗ
君もRustを使ってunsafe党に入るのだｗｗｗｗ
viva! cargo-geiger!!!!!

**デフォルトの名無しさん** · 2022/03/10(木) 06:31:20.40

>>303
反応を楽しんでるんだよ
それでリアルの憂さを晴らしてる

**デフォルトの名無しさん** · 2022/03/10(木) 07:17:23.57

# ようこそ！unsafe党へ！
cargo install cargo-edit cargo-geiger
cargo new notsafe
cd notsafe
cargo add --features full tokio
cat >src/main.rs <<EOF
#[tokio::main]
async fn main() { async { println!("{}", "こんにちは世界！"); }.await; }
EOF
cargo run
cargo geiger

**デフォルトの名無しさん** · 2022/03/10(木) 12:59:34.09

>>306
試してないけどこれどうなるん

**デフォルトの名無しさん** · 2022/03/10(木) 13:22:56.24

geigerは依存ライブラリを含めたunsafeの使用状況を集計するツールらしい
unsafe党とか言ってる人はもしかしたら
「見えないところでunsafe使うならRustは安全アピールするな」って言いたいのかもしれないし
unsafeをカウントできることがRustの安全性のひとつであることを知らないのかもしれない

**デフォルトの名無しさん** · 2022/03/10(木) 13:38:33.30

次スレはわっちょい頼むな

**デフォルトの名無しさん** · 2022/03/10(木) 14:09:03.75

>>307
https://i.imgur.com/jmr2YMq.png

**デフォルトの名無しさん** · 2022/03/10(木) 14:34:40.76

Unsafe使うなら見えないところでやってくれ。そしてUnsafe由来のバグは出すなっていうのがRustの思想ちゃうん？
ツール使わんと見えないなら大成功では

**デフォルトの名無しさん** · 2022/03/10(木) 15:37:06.36

# 見えないところでunsafeで一旦実行できるも、ちょっと修正するとコアダンプの例ｗ修正はunsafeでない場所ｗ
cargo install cargo-edit cargo-geiger
cargo new --lib maybe_safe
cd maybe_safe
cat >src/lib.rs <<EOF
pub fn read_address_4byte(address: usize) -> i32 { unsafe { *(address as *const i32) } }
EOF
cargo build
cd ..
cargo new perfectly_safe
cd perfectly_safe
cargo add --path ../maybe_safe maybe_safe
cat >src/main.rs <<EOF
#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(&0 as *const i32 as usize); }
EOF
cargo geiger
cargo run
cat >src/main.rs <<EOF
#![forbid(unsafe_code)]
fn main() { maybe_safe::read_address_4byte(0); }
EOF
cargo geiger
cargo run

**デフォルトの名無しさん** · 2022/03/10(木) 15:45:27.83

大成功(コアダンプ)でござるｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/03/10(木) 16:15:09.98

>>312
これ何でread_address_4byteにunsafeつけないで内部でunsafeブロック使ったの？
渡された数値を無条件にアドレス扱いしてそこにアクセスするのが絶対に安全だと判断した根拠を
コメントで書いといた方がいいよ
ちゃんと理由を説明できないならunsafeブロック使うのはやめたほうがいい

**デフォルトの名無しさん** · 2022/03/10(木) 17:06:13.98

そりゃ変なプロパガンダかまされて、こんなしょーもない言語使わされるなんてことになったら最悪だからな。
若いバカに騙されるバカ経営陣によくある話だわ。

**デフォルトの名無しさん** · 2022/03/10(木) 17:16:27.08

バグを混入させたくて混入させる人は原則いないのである。
例示は可能な限り単純化しているが、現実世界は複雑なのだ。

プログラマが「意図せず」混入させてしまうバグを「一部」言語で回避できるからこその「安全」であり、プログラマ自身が安全性を保証する側になってしまってはもはや「安全とは言えない」ｗ
処理系が「標準」として提供するものは処理系が「安全」を保証するものと仮定して除外し、「標準以外」の安全性を確認できればプログラム全体の「安全」も仮定でき、それを機械的に可能にしているのがRustという言語ｗ
そしてそのする「標準以外」の安全性を確認ツールがガイガー(geiger)なのだｗ
「標準」が「安全」と仮定される限り、ガイガーがunsafeをscanした結果☢ が1つもなければ、プログラム全体の「安全」も仮定されることになる。
もし☢があるならば、プログラム全体の「安全」は言語(処理系)でなくプログラマ自身が保証する必要がある。
この☢がある状態はC/C++と何ら変わらず、かなりのライブラリで☢が氾濫する昨今、言語が保証する「安全」についてRustに優位性は存在しない。
に依存する。

Rustコミュニティは他言語と比べれば豆粒程度なので、言語が保証する「安全」がプログラム全体の「安全」に占めるウェイトが大きくなければ、どこかで破綻し見限られ、喧伝してる手前凋落する運命となるだろうｗ
しかしそれでも人は速度を諦められず、unsafe党に次々ダイブしていくわけであるｗ

☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢
☢ガイガーカウンター＝放射線測定器☢
☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢☢

**デフォルトの名無しさん** · 2022/03/10(木) 17:37:18.96

unsafeじゃなくて、carefulってキーワードにすれば良かったのにね

**デフォルトの名無しさん** · 2022/03/10(木) 17:39:42.56

わかってる人しか使っちゃいけないんだし、unsafeのほうがいいかなあ

**デフォルトの名無しさん** · 2022/03/10(木) 17:45:02.59

libcがunsafeだからlibcの利用禁止！！！！！！！！！！！！！！！！！！！！

**デフォルトの名無しさん** · 2022/03/10(木) 18:02:59.97

exampleが日本語のクレートなtrie木を使おうとしたらもうコレｗ
https://i.imgur.com/ksKY9gX.png
こういうのばっかりなんですわ

**デフォルトの名無しさん** · 2022/03/10(木) 18:05:02.01

> 例示は可能な限り単純化しているが、現実世界は複雑なのだ。
それはまあその通りで、だからあんまり複雑な内容をunsafe内で書くのはやめような

**デフォルトの名無しさん** · 2022/03/10(木) 18:07:50.66

毒を食らわば皿まで！by unsafe党！

**デフォルトの名無しさん** · 2022/03/10(木) 18:17:23.72

unsafe使ってるのは競プロの異常者たちだけというデータは出てるから無視で良い

**デフォルトの名無しさん** · 2022/03/10(木) 18:18:21.60

まーじでワッチョイ入れるべきだったなこれは

**デフォルトの名無しさん** · 2022/03/10(木) 18:21:54.05

ワッチョイスレ既にあるぞ

**デフォルトの名無しさん** · 2022/03/10(木) 18:33:47.69

cargo install でコマンドをインストールすると依存するクレートも含めて
$HOME/.cargo/bin/registry
以下のディレクトリにソースや管理用のデータが格納されているようですが、
これらの管理というのはどのようにすればよいものなのでしょうか？

一定以上に古いものを削除するとか、
インストール済みのバイナリクレートが依存しているものだけを残すとか、
そういう機能は普通はあるだろうと思うのですが cargo のコマンドとしては見当たらず、
何か専用のコマンドを入れる必要があったりするのなら教えて欲しいです。

**デフォルトの名無しさん** · 2022/03/10(木) 18:35:27.76

単純なものの組み合わせで複雑になるのだよｗ
複雑になると人間的なチェックでは見落としが出るのだよｗ
その際にどこまで複雑になっても正確さ100%の機械的チェックは申し分なく有効なのだよｗ
それを(Rustの)内側だけにある要因だけで捨ててunsafe党に入ってしまうのが現状のRust ｗ
私もあなたもunsafe! viva! unsafe! Rust is unsafe!!!

**デフォルトの名無しさん** · 2022/03/10(木) 18:36:19.21

>>326
cargo cache はどう？
https://crates.io/crates/cargo-cache

**デフォルトの名無しさん** · 2022/03/10(木) 18:36:59.75

>>327
組み合わせる前にunsafeブロック閉じよう
unsafe内で組み合わせ爆発を起こすな😡

**デフォルトの名無しさん** · 2022/03/10(木) 18:40:22.68

最新ナンバリングスレをワッチョイ化しないと多分だめ

**デフォルトの名無しさん** · 2022/03/10(木) 18:58:28.71

>>329
コンパイラチェック可能な最小限のunsafeブロックの外側が、事実上安全ではないんだよｗ
これをどこまで広げるかを人間が決めるのでは、複雑な現実世界に適用した際バグると言っているｗ
誰もがこれなら平気！バグはないというところから、バグは生まれるわけだｗ
unsafeがあるだけでそれは致命的な障害となるｗ viva! unsafe! Rust is unsafe!

**デフォルトの名無しさん** · 2022/03/10(木) 19:02:33.98

完全に安全な言語なんてどこにも存在しない

**デフォルトの名無しさん** · 2022/03/10(木) 19:22:49.02

そう、つまりRustはおおよそのケースでC/C++と同じくらい安全でなく、RustはC/C++より少し遅い言語なわけだｗ
viva! ☢unsafe☢! Rust is ☢unsafe☢!

**デフォルトの名無しさん** · 2022/03/10(木) 19:23:02.49

銀の弾丸はないんだよ
だけど物事は少しずつよくなっいくの

**デフォルトの名無しさん** · 2022/03/10(木) 19:28:34.82

そのとおり！今は嘘をつかず謙虚にユーザーが増えるのを待っていろｗ
非同期に必要なlibc周りのゴミゴミした部分が十二分に安定して標準に取り込まれれば逆転も可能だろｗ
それまではジッと我慢ｗ

**デフォルトの名無しさん** · 2022/03/10(木) 19:39:15.65

ここで真っ赤になってディスろうがRustの利用は拡大している

**デフォルトの名無しさん** · 2022/03/10(木) 19:40:41.65

まだ叩かれたりないのかｗマゾかよｗ

**デフォルトの名無しさん** · 2022/03/10(木) 19:46:32.94

Google Trendsのen-USで見たらRustでプログラミング言語がないんだがｗ
https://i.imgur.com/Gi5avJg.png

**デフォルトの名無しさん** · 2022/03/10(木) 20:11:05.69

>>328
ありがとう
しばらくこれで運用してみる

**デフォルトの名無しさん** · 2022/03/10(木) 20:20:46.82

Rustは何かにつけて長時間ビルドする上にそのサイズがクソデカイから困るんだよなｗ
容量足りなくていつも消して回り、ちょっと変更してフルビルドっていう繰り返しｗ

**デフォルトの名無しさん** · 2022/03/10(木) 20:38:14.39

>>331
ええそんなことあるか？

**デフォルトの名無しさん** · 2022/03/10(木) 20:48:32.09

>>341
適当なテストでリリースしたりしませんｗ

**デフォルトの名無しさん** · 2022/03/10(木) 21:24:21.13

まず言語と関係なく一般的な前提として
・プログラミングをする上で当然unsafeな操作を避けることはできない
・unsafeな操作を組み合わせることで安全なプログラムを作ることがプログラミングの本質

次に
・unsafeな操作のコードは人間による厳重なチェックが必須でこれを避けることは出来ない
・unsafeな操作がプログラム全体に散らばってしまっているのがCとC++

そこでRustの方針
・unsafeな操作は局所的に閉じ込めてしまい安全なインタフェースを公開
・そのunsafeな操作で作られた安全なインタフェースの安全性は人間が保証
・データ競合を含めたプログラム全体の安全性はRustの言語ルールによりコンパイラが保証

したがってどんなにプログラムとその中のデータや依存関係が複雑化および巨大化しようとも
Rustにおいて人間は局所的に閉じ込めたunsafeな操作部分のみ厳重チェックすればよくなった

暴れている ID:JmzvOlHn はこれを理解することが出来ない愚かな存在
例えば >>312の read_address_4byte()
これはunsafeな操作を使ったunsafeな関数であるからunsafeを宣言しなければならない

>>330
ワッチョイ化しなくても愚かな存在はすぐに区別がつくので大丈夫
並行してワッチョイ無しスレも立って過疎と活性の結果となる

**デフォルトの名無しさん** · 2022/03/10(木) 21:38:23.62

>>343
> ・unsafeな操作を組み合わせることで安全なプログラムを作ることがプログラミングの本質
これ嘘ｗ
> ・unsafeな操作は局所的に閉じ込めてしまい安全なインタフェースを公開
これ「局所的に閉じ込め」られると思ってるところがただの思いこみｗ
理由は
> ・そのunsafeな操作で作られた安全なインタフェースの安全性は人間が保証
これが不可能だからｗ
閉じ込められないと、
> ・データ競合を含めたプログラム全体の安全性はRustの言語ルールによりコンパイラが保証
これの意味がなくなるｗ

という説明を長々としてきたのだが、残念ながらID:Bj7uYOrmには理解が及ばなかった模様ｗ
以上から、Rust is ☢ UNSAFE ☢! となるｗ

どうして理解できないんだろうなぁｗ
機械は言われたとおりのことしかできないけど、言われたとおりに100%ミスなくできるｗ
でも人間は必ずミスをするんだよｗ
保証できていることの意味が全然違うことを理解してほしいねｗ

**デフォルトの名無しさん** · 2022/03/10(木) 21:45:03.55

ワッチョイあり作っていい？

**デフォルトの名無しさん** · 2022/03/10(木) 21:54:57.49

スレの途中で作ると人移動しないかもしれない。いやでも、おじさんこんだけ激しく荒らしてるから、移動するかもしれない。

**デフォルトの名無しさん** · 2022/03/10(木) 22:02:14.74

この手の嵐はワッチョイ導入でさぁーっと消えるｗ
そらもう面白いように消える不思議なことに

**デフォルトの名無しさん** · 2022/03/10(木) 22:05:50.15

別にどっちにも書くだけだけどなｗ

**デフォルトの名無しさん** · 2022/03/10(木) 22:07:42.67

少なくとも自演はできないし一週間NGできるから快適になるよなぁ

**デフォルトの名無しさん** · 2022/03/10(木) 22:12:09.43

どうぞどうぞご自由にｗ自演なんてしてないし、別IDなんてないけどなｗ
そもそもまともな内容書いてないやつしかワッチョイの話してないのが非常に胡散臭いｗ

**デフォルトの名無しさん** · 2022/03/10(木) 22:12:58.79

>>344
そうは言ってもデバッグするときunsafeな場所が限定されている方が良くない？

**デフォルトの名無しさん** · 2022/03/10(木) 22:31:54.92

>>351
設計意図が実装に見えるのは大事なことｗ
でもそれを安全というのはちょっとねｗ

**デフォルトの名無しさん** · 2022/03/10(木) 22:33:25.84

>>351
どうせunsafeがある時点で論外って答えが返ってくるだけだぞ

**デフォルトの名無しさん** · 2022/03/10(木) 23:13:00.51

>>352
safeという強い言葉が気に入らないってこと？
それはまあちょっとわかる

**デフォルトの名無しさん** · 2022/03/10(木) 23:16:42.15

「大規模化／複雑化すれば人間は必ずミスをする」からこそ
それを回避するためにRustが作られた

Rustコンパイラはコードがどんなに大規模化／複雑化しても
メモリ安全性やデータ競合が無いことを保証できる
その唯一対象外となるのがunsafeな操作

Rustでは局所的な極小規模で単純な部分にunsafeな操作を閉じこめる
そして外へは安全なインタフェースのみを公開
人間にしか出来ないunsafeな操作利用の妥当性チェックを最小化することに成功した
どんなに大規模and/or複雑化してもプログラム全体の安全性を人間がチェックする必要が無くなった

一方でCやC++などはプログラム全体にunsafeな操作が散らばり人間の手に負えない
GC導入のハンデと引き換えにメモリ安全性の一部を得たGC言語であっても
ヌルポインタを含む一部のメモリ安全性やデータ競合などを防ぐことが出来ていない
それらの安全性を保証することに成功したプログラミング言語がRust

**デフォルトの名無しさん** · 2022/03/10(木) 23:32:10.55

可哀想なくらいに他人の言葉を受け入れられない人だねｗ
Rust作られた目的まで捏造されちゃったよｗ
unsafeを閉じ込められるというのは幻想ｗ
外には安全なインターフェースのみ公開という理屈が「仮定」できるのは処理系とのそこが提供する標準含むランタイムだけｗ
プログラマが実装するプログラムはunsafeを使った途端にプログラム全体がもうunsafeでC/C++と同じなんだよｗ
GCは関係ないｗ
リアルタイム性を予測可能にするためにランタイムが予測不可能な時間を使用することを回避したい場合のみGC有無が関係するｗ
null安全は書き方だけであり、他の言語でも大抵似たようなことが実現できるし、機械的なチェックも可能ｗ
そしてC/C++と同様に安全性が保証できず、C/C++より遅い言語が何を隠そうRustさんｗ

**デフォルトの名無しさん** · 2022/03/10(木) 23:34:44.83

>>354
viva!tokio!な現状だと安全ではないと言ってるだけｗ
cargo geigerで☢がなければ(C/C++より)安全って言ってもいいと思う

**デフォルトの名無しさん** · 2022/03/10(木) 23:50:22.89

ずーっと同じこと言って人を煽ってるだけ。典型的な構ってちゃん

**デフォルトの名無しさん** · 2022/03/10(木) 23:58:49.51

>>356
ほら、理解できていない
unsafeで作られた安全なコードに対する人間による妥当性チェックの必要性は
それが標準であろうとデファクトであろうと自作であろうと全て同じ

逆に言えばその局所的なコードの妥当性チェックがなされていれば
Rustではプログラム全体の妥当性がコンパイル時点で保証される
Rust以外のプログラミング言語はこれができない

**デフォルトの名無しさん** · 2022/03/11(金) 00:07:06.62

>>359
理解できてないのはお前ｗ
ランタイムやVMは他の言語でも別枠だからプログラム本体とは切り離して安全としていいんだよｗ
そこは言語が規定してる部分だからだｗ
C#やJavaでVMがnativeだからって文句言うアホはいないし、各種インタプリタ言語の組み込み関数が何で書かれてても誰も何も言わないだろｗ
RustよりはC#やJavaの方が明確に安全と言えるけどなｗ
Rustだと言語の内側からunsafeにしたいという欲求が生まれる温床があり、不必要にunsafeが発生しうるｗ

**デフォルトの名無しさん** · 2022/03/11(金) 00:49:50.34

もし仮にTokioが標準ライブラリならOKなのか？
標準ライブラリにバグがある確率とコンパイラにバグがある確率は同じくらいとして

**デフォルトの名無しさん** · 2022/03/11(金) 01:19:06.80

標準ライブラリはもの凄い小さくて、あとは個人や小さな組織が作った野良ライブラリだよりだから、
安全性は全然担保されてないと思うがなぁ。