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

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

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

どの言語であれ
標準ライブラリやランタイムに問題が生じなかった言語は存在しない
だから『標準』と名が付くかどうかはどうでもよい問題

Rustにはunsafeか否かの区別があるから他の言語より遥かに良い状況
標準か否かに関係なくunsafeではないコードに対してunsafeを冠せずに出したら厳しく指摘される
そしてunsafe以外についてはコンパイラが通れば安全性が保証される

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

でかい標準ライブラリを許容してると、言語をメンテしてる人たちにとっては切り捨てもできず、互換性を担保するのとかでどんどん負担もでかくなるし、言語自体の進歩まで遅くなりうるよ
Goの進歩がやたら遅いのも、もしかしたらそういうとこにも原因あるかもね

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

しかし非標準で同じようなライブラリが乱立してるような状況では新規言語に飛びつきたい言語オタクの精神異常者以外には参入し辛い状況ではある
普通の人普通の企業にとってはGoの方が魅力的に映るだろうな
進歩が遅いのも一度勉強した知識がそのまま使い続けられるし一度書いたコードが使い続けられるってことだし

**デフォルトの名無しさん** · 2022/03/11(金) 04:08:28.95

>>365
逆でしょ
RustはGoogle含めた大手IT企業から全面支持
そしてRustは後方互換性も維持しているから2018editionと2021でもほとんど変わらない
安心して導入できる

そして一番重要な言語機能
Goは今年ようやくジェネリクスだけど期待外れ
イテレータ導入提案すら何度も却下
GoとRustどちらも書ける人なら確実にRustを選ぶ現実

**デフォルトの名無しさん** · 2022/03/11(金) 04:20:44.43

>>366
Googleなんて言語オタクの精神異常者集めた企業の代表じゃん。そりゃそうなるよ。Common Lispとか好きそう

ジェネリクスとかイテレーターがなくてガッカリしてるのも言語オタクの特徴だな。普通の人はそれでいいって思ってるよ

**デフォルトの名無しさん** · 2022/03/11(金) 05:51:22.53

ほんとこのおじさん言語叩けりゃ何でも良いんだな。今度の棒はGoか。んでまだCommonLispのこと根に持ってる。そしてホントは.NET好きなのは隠しきれてない

**デフォルトの名無しさん** · 2022/03/11(金) 06:14:29.85

標準ライブラリならOKだよ
入っていると入っていないでは雲泥の差がある
処理系が責任を持って開発する部分で、基本部分である以上、ユーザーが少なくてもunsafeでも最大限の品質が保証されるから
言語仕様開発や処理系側からすれば、そんなところを大きくすると言語自体が保証する安全性にケチがつきかねないから小さくしたい心情はあると思う
純粋にフットプリントは小さくしたいしね
ただスレッドや同期機構まで用意してるので、世の流れとして非同期くらいまでは標準にしないと扱いにくいとは思う
切り離しやすく決まってると嬉しい
他の言語との比較はRust自体の説明に必要でない限りこのスレではしない

**デフォルトの名無しさん** · 2022/03/11(金) 09:41:54.29

なんだ、コード見て技術的なこと話してたらな、て思って見に来たら、
他のスレと同じで言語があーだこーだ言ってるだけか
まあ5chはこんなもんか

**デフォルトの名無しさん** · 2022/03/11(金) 09:58:37.49

unsafeがあるからダメなんじゃない
unsefeじゃないところがsafeなのがRustの大発明

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

曖昧な感想をダラダラ書くより、これを紹介したほうが有意義だろ。

安全と危険のご紹介
ttps://doc.rust-jp.rs/rust-nomicon-ja/meet-safe-and-unsafe.html

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

とりあえず英語版の方が内容新しいんで、こちらへ
https://doc.rust-lang.org/nomicon/working-with-unsafe.html

このexampleの2番目の
if idx <= arr.len() {
なんかが典型的で、これ気付けません。直後にあるとおり、

”...This program is now unsound, Safe Rust can cause Undefined Behavior, and yet we only modified safe code. This is the fundamental problem of safety: it's non-local. The soundness of our unsafe operations necessarily depends on the state established by otherwise "safe" operations...."

なわけ。
テキストでは最終的に可視性を利用して局所化してみたいなハウツーを入れてるけど、それは対策方法であって、局所化できる保証はない。
人間にミスは必ずあるからね。
どう書けば安全か分かっていて、それを確実に守れるなら、人間はC/C++でもバグ1つなく完璧にコーディング出来るはずなんだよ。

ってわけで、Rust is ☢UNSAFE☢ !!!!

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

>>373
紹介している内容と主張している内容が一致していないように思えますが
unsafeが一つでもあればunsafeだと主張してるのかな？

**デフォルトの名無しさん** · 2022/03/11(金) 12:18:09.85

>>374
unsafeに閉じ込めるのはプログラマの責任、ということだろ。

Rustがunsafe以外で未定義動作にならないことを保証しているんだっけ？

**デフォルトの名無しさん** · 2022/03/11(金) 12:25:34.38

Haskellに対してモナドで副作用してるから純粋関数型言語じゃねえって感じの主張してはるんやろ

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

モナドが副作用起こしてるんじゃなくて実装系が副作用起こしてるんだけどね。
まああの辺の無駄な解釈学振り回すことばっかりな点は同じクソさを感じるわな。

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

>>377
あぁすまん。雑だった

**デフォルトの名無しさん** · 2022/03/11(金) 16:22:44.16

言語の理屈の立て方とそれの実現の仕方はレイヤが違う話だし、
言語の話をする以上は言語の理屈を軸にするしかしょうがないじゃん。

**デフォルトの名無しさん** · 2022/03/11(金) 21:29:04.10

>>373
unsafeを用いて安全なコードを書いている部分に対してのみ
人間が注力することができるようになったRustは他の言語より進んでると理解できた？

>>375
unsafe以外ではRustは未定義動作(undefined behavior)がないことを保証

>>379
そこは理屈というか理論というか抽象的な概念で理解しておくべきところだね
実装や内部表現は変わりうるし最適化で消滅しうるので実現方法で理解しようとしても不安定で無意味

**デフォルトの名無しさん** · 2022/03/11(金) 23:04:07.65

>>380
何度言っても「unsafeを用いて安全なコードを書いている部分」が人間には限定できないのを理解できてないのはお前ｗ

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

>>367
Goが魅力的と書いておいてGoogleをそこまで叩くちぐはぐさ
Rustを叩ければ棍棒は何でもいいんだな

>>381
まだ意味不明なこと言ってRust叩きしてるのか
敗北を認められなくて引くに引けずかね

**デフォルトの名無しさん** · 2022/03/11(金) 23:25:07.91

>>382
叩く・叩かないや敵味方のような二つでしか考えられないのか？

**デフォルトの名無しさん** · 2022/03/11(金) 23:29:38.47

>>382
論理的に反論されたことがないという認識なんだがｗ
上から頭ごなしにこうです！と言われて、いやこうこうこういう理由でそうとは思えないと伝えたら、
「意味不明」とか「Rust叩き」とか、「敗北を認められな」いと言われて議論が終わっちゃうだけｗ

**デフォルトの名無しさん** · 2022/03/11(金) 23:30:30.36

>>383
自分が何を書き込みしたのか見直そうぜ

>>365
>>普通の人普通の企業にとってはGoの方が魅力的に映るだろうな

>>367
>>Googleなんて言語オタクの精神異常者集めた企業の代表じゃん

**デフォルトの名無しさん** · 2022/03/11(金) 23:32:12.74

>>385
叩いてみんなに構ってほしいだけなんだかほっとけ

**デフォルトの名無しさん** · 2022/03/11(金) 23:33:05.04

>>385
両方ともただの事実だが

**デフォルトの名無しさん** · 2022/03/11(金) 23:37:39.97

>>384
Rustの言語ルール及びunsafeとそれ以外(safe)を分けることで
初めてコンパイラが通れば安全性を保証すること成功した枠組みを
未だに理解できずイチャモンつけるだけしか出来なくて恥ずかしくないのかね？

**デフォルトの名無しさん** · 2022/03/12(土) 00:00:00.86

>>388
別にunsafe自体はRustが作ったわけじゃないよｗ
C#が大昔にunmagedなコードを呼び出すために開発した
Rust同様に別にどこまでも範囲は広げられる
Javaもnativeってあるよね

この2つは基本的にVMが保証している枠組みを外れる部分に対して使用されてるので、VM内のコードが実行される限り、使う動機が発生しない
対してRustは安全を担保するための所有権の仕組みを逃れるためなど、unsafeを使用する動機がいたるところにある
標準が提供しているライブラリが足りないこともあり、これは相当深刻な状況なわけだｗ

すると、両者が意味するunsafeな部分の意味が大きく変わってくる。
簡単に言えば原則safeな部分を書き換えるためにunsafeが使用されないかどうかの違いｗ
残念ながらRustは安全を担保するための所有権の仕組みを逃れるためなどの理由でsafeな部分を書き換えるためにunsafeが使用されてしまっている
Rustがunsafeな理由の1つはこの動機の部分に潜在的な問題があるってことｗ