Rust part25

**デフォルトの名無しさん** · 2024/07/31(水) 00:46:26.17

公式
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 part24
https://mevius.5ch.net/test/read.cgi/tech/1716759686/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:24.38

unsafeって危険だから描くんじゃなくて
unsafeを描くことで危険を回避出来るんだ
だからunsafeが使われてるからって危険なコードじゃないんだ
unsafeを観たら危険だと脊髄反射する方が馬鹿の誤解

**デフォルトの名無しさん** · 2024/08/27(火) 14:18:59.31

だから >>445 はピンぼけ的外れ

**デフォルトの名無しさん** · 2024/08/27(火) 14:29:34.76

RustかC++のどちらかなのかはRustで落ち着いたけど
unsafe RustかCかは結局どっちがいいんだい？

**デフォルトの名無しさん** · 2024/08/27(火) 14:38:55.67

>>454
え？いつの間に落ち着いたの？

**デフォルトの名無しさん** · 2024/08/27(火) 14:47:28.58

>>454
Zigだよ
ZigこそがベターCで、C++風味が入っていない

**デフォルトの名無しさん** · 2024/08/27(火) 15:35:17.48

>>452
おまえは何を言ってるんだｗ

**デフォルトの名無しさん** · 2024/08/27(火) 15:36:49.68

>>456
1.0になってから来てくれ

**デフォルトの名無しさん** · 2024/08/27(火) 16:13:13.47

>>454
最大サイズのマインスイーパーを30分かけてじっくり解きたい → C
マインスイーパーは最小でいいから余った時間でソリティアやりたい → (unsafe) Rust
作業に戻る → C++

**デフォルトの名無しさん** · 2024/08/28(水) 04:07:55.29

最大サイズのマインスイーパーだと
プログラムに解かせるのに30分くらいかかるのか
それはメモリを積むと速くなったり
コア数を積むと速くなったり
未知のアルゴリズムで速くなったりする？

**デフォルトの名無しさん** · 2024/08/28(水) 09:07:31.11

まあそうなるよなw
頭悪いたとえ話だから仕方がない

**デフォルトの名無しさん** · 2024/08/28(水) 09:16:54.18

でもプログラムに解かせるのに30分もかからないだろくらいの感覚は常識として持っておいて欲しいところ

**デフォルトの名無しさん** · 2024/08/28(水) 10:32:38.93

マインスイーパーはNP完全であると証明されていてかなり難問
さらにそもそも常に論理的に解けるわけではないためリゾルバーは勝率100%ではなく問題難易度別に平均勝率が示される
具体的には論理的推論で開けられる場所がなくなった時に人間は運ゲーとなるが機雷のある場所の確率計算により勝率を高められる
その手法ならびに巨大サイズによっては計算時間30分はありうるのではないか

**デフォルトの名無しさん** · 2024/08/28(水) 11:57:33.04

>>460
そんな訳無い
10秒もかからん

**デフォルトの名無しさん** · 2024/08/28(水) 12:03:45.27

例えば話悪すぎるのは理解するけど、プログラムにマインスイーパー解かせる話だっけ

**デフォルトの名無しさん** · 2024/08/28(水) 12:21:33.97

>>464
なぜ0.1秒ではなく1秒ではなく100秒ではなく10秒なのか？

**デフォルトの名無しさん** · 2024/08/28(水) 12:23:32.67

>>465
プログラム板のプログラミング言語スレでそれ以外にどんな可能性があるか？

**デフォルトの名無しさん** · 2024/08/28(水) 13:59:37.19

誤魔化せれば何でもいいから意味の無いレスを拾ってごちゃごちゃ書き込んでるんだろう

**デフォルトの名無しさん** · 2024/08/28(水) 16:33:13.07

いつのまにかAndroid公式ドキュメントにRustの章ができてた

**デフォルトの名無しさん** · 2024/08/28(水) 17:22:14.56

AndroidはJNIをJavaとバイナリとの間に噛ませないといけないからほんとに面倒くさい

**デフォルトの名無しさん** · 2024/08/28(水) 19:34:23.32

>>459
君頭悪いのに無理に例えなんか使わないほうがいいよ

**デフォルトの名無しさん** · 2024/08/28(水) 21:16:27.54

まさかマインスイーパーの例え自体が地雷になるとはｗ
Rustスレなのにunsafeだな

**デフォルトの名無しさん** · 2024/08/28(水) 22:54:19.83

さあみなさま、脱unsafeを心がけていきましょう！

**デフォルトの名無しさん** · 2024/08/28(水) 23:16:33.26

>>456
Zig、エリアアローケーターがとても魅力的なんだけど、非同期まわりの仕様が白紙に戻っちゃったのがなあ
もちろんZigの求められている役割的に非同期はそこまで重要ではないのだけれどちょっと悲しさを感じる
なんでもZigに限らずLLVMとasync/awaitの相性がとてつもなく悪いらしい
https://www.reddit.com/r/Zig/comments/1d66gtp/state_of_async_in_zig/
長文すまん

**デフォルトの名無しさん** · 2024/08/28(水) 23:17:49.58

Swiftのasync/await良く出来てるけど？

**デフォルトの名無しさん** · 2024/08/28(水) 23:25:03.26

>>475
加えてGolangやKotlinのasync/awaitもよく出来てる
成功例はあるんだしきっとなんとかしてくれるよね

**デフォルトの名無しさん** · 2024/08/28(水) 23:30:17.85

golangはasync/awaitじゃなくてCSPな？

**デフォルトの名無しさん** · 2024/08/28(水) 23:32:07.56

>>477
すまん指摘助かる

**デフォルトの名無しさん** · 2024/08/28(水) 23:41:09.49

>>474
気になったけどエリアアロケータはarena allocatorの空目？
arenaはアリーナ（闘技場）

**デフォルトの名無しさん** · 2024/08/28(水) 23:41:42.12

GoもKotlinもLLVMバックエンドじゃないだろ

**デフォルトの名無しさん** · 2024/08/28(水) 23:46:05.67

>>474
読んでみたが登場人物たちが無知すぎるな
特にZigでのasync/awaitの経緯を解説しているmlugg0はRustについて不慣れで全くわからないと答えてる

>>Zigに限らずLLVMとasync/awaitの相性がとてつもなく悪いらしい

それは間違いでLLVM coroutineを使おうとすると重くなる
Rustはそれを使わずにスタックレスなステートマシンとして実現しているため軽く良く出来ている

**デフォルトの名無しさん** · 2024/08/29(木) 01:22:47.24

>>481
Rustは最強ってことでいいけどここにいてもお前がザコなのは変わらないからもう引っ込んでなよ

**デフォルトの名無しさん** · 2024/08/29(木) 06:12:15.98

>>480
バカなAIが跋扈してる

**デフォルトの名無しさん** · 2024/08/29(木) 06:26:17.95

Zigは技術的な敗北でasync/awaitを削除しただけでなく思想的にも嫌悪や不要論が跋扈していて終わってるな

**デフォルトの名無しさん** · 2024/08/29(木) 07:28:11.89

>>474
スレッドプール作れるし問題なし

**デフォルトの名無しさん** · 2024/08/29(木) 07:34:05.99

async awaitが何なのか理解していない人たちがZigに集まっている

**デフォルトの名無しさん** · 2024/08/29(木) 07:53:29.77

Zigは未使用変数がエラーになるのがな…
せめてデバッグビルド中はワーニングになってほしいが
作者の思想的に無理そうなんだよな

**デフォルトの名無しさん** · 2024/08/29(木) 08:06:23.91

>>487
Cとかでよくある消すと何故か動かなくなる未使用変数を撲滅する対策とか？
もしそうならまっとうに境界チェックしてほしいが。

**デフォルトの名無しさん** · 2024/08/29(木) 08:08:24.23

zigはビルドツールのccとしてcmakeより使いやすくて好き

**デフォルトの名無しさん** · 2024/08/29(木) 08:10:24.41

>>488
いや、Rustと同じく変数名に_つければ通るからあんま関係ないかな
これのせいで実装中やデバッグ中に関数呼び出し一つコメントアウトするたびに
あちこちに_をつけてまわらないといけないからかなりつらい

**デフォルトの名無しさん** · 2024/08/29(木) 08:32:58.82

Zigは未完成のまま終わりそうだな

**デフォルトの名無しさん** · 2024/08/29(木) 08:51:25.64

>>489
pkg-config 呼び出す機能がないんじゃない？

**デフォルトの名無しさん** · 2024/08/29(木) 09:33:53.27

>>490
これだけ変数の使用不使用にうざい仕様の割に
同一scope内での二重定義(上書き)はあっさりと許す糞仕様ω

**デフォルトの名無しさん** · 2024/08/29(木) 12:29:33.60

シャドウイングがない言語は不便すぎるから有るのは正しい

**デフォルトの名無しさん** · 2024/08/29(木) 12:50:47.36

>>486
async awaitをやさしく解説してください

**デフォルトの名無しさん** · 2024/08/29(木) 13:07:04.37

せんでええよ

**デフォルトの名無しさん** · 2024/08/29(木) 13:32:35.20

https://rust-lang.github.io/unsafe-code-guidelines/introduction.html
こんなのあるんだ、まだ中身スッカスカだけど

**デフォルトの名無しさん** · 2024/08/29(木) 14:09:44.24

async (∩ﾟдﾟ)ｱｰｱｰ
await 聴こえなーいΩ＼ζ°)ﾁｰﾝ

**デフォルトの名無しさん** · 2024/08/29(木) 14:12:39.25

asyncの一番難しいとこは発音だな
間違えてる日本人が多い

**デフォルトの名無しさん** · 2024/08/29(木) 14:49:29.45

>>497
それは「まだ」じゃなく
すでに捨てられた後のもの

**デフォルトの名無しさん** · 2024/08/29(木) 19:49:23.69

Rustの非同期が非常に軽く上手くいってる理由は簡素であることかな
futureの構築とfutureの実行が明確に分離されている
構築で返されるのは単なる構造体の値でありヒープ利用を前提としない
実行はポーリングしないと何も進まない簡素さ
asyncタスクはステートマシンによるコルーチンとして実装されている
つまり個別のスタックを必要とせずに動くためメモリリソースの点でも有利となってるね

**デフォルトの名無しさん** · 2024/08/29(木) 23:02:59.56

>>479
エリアとかって恥ずかしい奴と思ってた。

**デフォルトの名無しさん** · 2024/08/29(木) 23:05:24.99

>>489
cmakeのバージョン変化に嫌気して素のgnu makeに戻ったわ。

**デフォルトの名無しさん** · 2024/08/29(木) 23:20:35.98

>>502
area allocatorで検索したらarena allocatorしか出てこなかった
どっちが正解か分からんけど勘違いしたままだとプレゼンで恥かきそう

**デフォルトの名無しさん** · 2024/08/30(金) 01:16:51.32

https://en.wikipedia.org/wiki/Region-based_memory_management
region, zone, arena, areaと呼ばれると書いてあるし言うほど間違いじゃないんじゃね

むしろ”闘技場”に驚いたわ

**デフォルトの名無しさん** · 2024/08/30(金) 01:40:41.30

両方あるんか
arenaは知ってたけどareaでも意味通じるから迷ってた

**デフォルトの名無しさん** · 2024/08/30(金) 02:21:05.28

areaだと一般用語の～エリアと曖昧になりやすいせいかarenaと呼ばれることが多いかな
特にRustではその手の各種クレートはxxx-arenaと名付けられているね
そのため「そこはアリーナ系を使おう」だけで話が通じると思う

**デフォルトの名無しさん** · 2024/08/30(金) 13:24:19.84

Rustで勘違い3選
https://qiita.com/namn1125/items/2a59f486cce30fd2b889

**デフォルトの名無しさん** · 2024/08/30(金) 14:03:33.10

高階トレイト教会

**デフォルトの名無しさん** · 2024/08/30(金) 18:16:40.82

https://japan.zdnet.com/article/35223295/2/
> LinuxへのRust言語の導入の話になると、Torvalds氏は採用のペースが上がらないことに失望感を示した。
> 「更新が思ったほど速く進んでいないが、問題の一端は、昔からのカーネル開発者が『C』に慣れていて、Rustを知らないことにある。彼らは、ある面で大きく異なる新しい言語を学ばなければならないことを、あまり歓迎していない。そのため、Rustに関しては多少の反発がある」

**デフォルトの名無しさん** · 2024/08/30(金) 18:18:32.29

まあ既存のエンジニアにRust学ばせるんじゃなくRustやりたいってヤツが実績積んで参加すべきだわな

**デフォルトの名無しさん** · 2024/08/30(金) 18:22:28.02

昔ながらのカーネル開発者は賢いからCで良いんだよな

新参のCまともに書けないバカがカーネルにいっちょ噛みするためにRust推してみたけど、本人はRustわかる程度の知能はあるがカーネル理解できる程の知能はないからカーネル周り書けず、他人にRust勉強しろと喚くことしか出来ない

**デフォルトの名無しさん** · 2024/08/30(金) 18:27:03.74

C++の苦痛を経験しないと有難みがわからないのがRustだからな。linuxカーネルがC++を採用していたらすんなり移行してたかも

**デフォルトの名無しさん** · 2024/08/30(金) 18:42:19.31

C++なんてバグの温床だから採用しないのは正解

**デフォルトの名無しさん** · 2024/08/30(金) 19:05:19.61

>昔ながらのカーネル開発者は賢いからCで良い

＋1

**デフォルトの名無しさん** · 2024/08/30(金) 19:08:04.69

>linuxカーネルがC++を採用していたらすんなり移行

これは絶対無い
むしろC**使われてるとRust化から遠ざかる
断言出来る
RustとC++の相性は最悪

**デフォルトの名無しさん** · 2024/08/30(金) 19:21:09.42

かつてC++をボロクソに叩いていたLinusが、何でRustを許したのかよくわからない

**デフォルトの名無しさん** · 2024/08/30(金) 19:35:01.93

Rust for Linuxってout-of-treeカーネルモジュールをRustで書けるってだけでは？
それすらも思ったほど書く人がいなかったってことを言ってるんだろうか

**デフォルトの名無しさん** · 2024/08/30(金) 19:51:34.75

いや書きたい人はたくさんいるし、実際書かれてるけどそれを本家に取り込む際にメンテナが拒否するって話
例えば

Rustドライバを書くための基盤となるユーティリティを追加したい　→　実際のドライバで使われていないユーティリティは追加しない
ならドライバとユーティリティを一緒に追加したい　→　パッチが大きすぎるからレビューしない

みたいなのとか

この辺見ると実際にRustドライバの作者がカーネルメンテナの何に不満を持ってるかわかるよ
（この人はApple Silicon用のGPUドライバをRustで書いてる人）
https://vt.social/@lina/113045455229442533

**デフォルトの名無しさん** · 2024/08/30(金) 20:29:51.47

>>510
糞言語ってことじゃねｗ

**デフォルトの名無しさん** · 2024/08/30(金) 21:40:23.58

rustでファイルシステム扱うAPIを入れる活動に
メンテナから難癖つけられてうんざりしたので
下りるという人が出たらしいので
政治レイヤーで色々あるんだろうなあ

**デフォルトの名無しさん** · 2024/08/30(金) 22:55:20.95

>>512
＞昔ながらのカーネル開発者は賢いからCで良いんだよな

その割には毎週セキュリティパッチでてるようじゃん

**デフォルトの名無しさん** · 2024/08/31(土) 03:26:17.69

>>517
新しいものをなんでも否定していたら「老害」認定されるから、ここはちょっくら軟化しておこうかな、みたいな感じじゃね。

**デフォルトの名無しさん** · 2024/08/31(土) 04:29:19.80

>>517
Cに対してC++の導入の益と害を考えると害が大きい
Rustの導入は益が大きいため国防総省(DARPA)も進めようとしている
ソース>>309

**デフォルトの名無しさん** · 2024/08/31(土) 06:58:45.77

信者が家主に対してやっている事はこれに近い

最近、水道企業団の職員や委託業者を装い、「水質や水道管の検査に来ました」などと言って高額な浄水器の購入や水道管の取替えなどをすすめられた、
水道管の調査と称して管が汚れているから水道水が危険と言って給水管清掃の契約をすすめられた。などの事例もあります。

**デフォルトの名無しさん** · 2024/08/31(土) 08:04:20.66

リーナス自身がRustで何か作って見せたら流れ変わるかもな
まあそんなことは無いんだろうけど

**デフォルトの名無しさん** · 2024/08/31(土) 08:34:49.06

Rust がどうこうというのを抜きにしてひとつのプロジェクトにいろんな言語が混在するのは面倒さが生じるというのはある。
Linux に乗ろうとするなら Linux の方針に従えというのは当然の判断だろう。
受け入れてしまったらメンテナンスしなきゃならんし、メンテナンスできないものを導入するのは問題だ。
あくまでも Rust の急進的導入をしたいというなら fork するくらいの気概を見せて欲しいところ。

**デフォルトの名無しさん** · 2024/08/31(土) 08:38:08.89

>>527
既にRustのコードが入っている現実を無視して妄想が激しいな

**デフォルトの名無しさん** · 2024/08/31(土) 09:01:31.35

Rustのコード入れたくないまでならまだ分かるが
（Rustドライバ導入の前段階として）既存のサブシステムのバグを直したいと言ったら
今あるドライバではそのバグは踏んでないから直す必要なし、って言われたりしてるらしく
さすがに自分のCのコードのクオリティくらいちゃんと上げろよ、とは思う

**デフォルトの名無しさん** · 2024/08/31(土) 09:13:30.90

考え方が違うんだよね
C/C++では現在のコードの使い方の範囲内では(ギリギリ)バグを回避できているので大丈夫と考える
そして後に機能追加や改修が入ったときにそのギリギリのところを踏んでしまって致命的バグが露呈する
このダメな考えな人がまだ多くいる

**デフォルトの名無しさん** · 2024/08/31(土) 09:22:22.01

RustほどC++と相性の悪い言語はないね。
C++との相性を考えるならNimの方が良い。
勘違いしないで欲しいんだがRustとCの相性はとても良い。

**デフォルトの名無しさん** · 2024/08/31(土) 09:25:59.57

>>529
>今あるドライバではそのバグは踏んでないから直す必要なし、って言われたり

これは酷い
MicsoSoftを嗤えないな

**デフォルトの名無しさん** · 2024/08/31(土) 09:27:58.78

>>530
>そのギリギリのところを踏んでしまって

きみも考え方が間違っている
昔ながらのカーネル開発者は賢いからCで拡張してもそのバグを踏まない自信があるんだよ
(それが良いか悪いかは別として)

**デフォルトの名無しさん** · 2024/08/31(土) 09:38:02.88

各OSで脆弱性報告が無くならないのはなぜか？
思い込みの自信でプログラミングしていてバグを踏むからである

**デフォルトの名無しさん** · 2024/08/31(土) 09:42:22.13

FFIがそもそもCのAPI以外が難しい
C#やGoでも他言語の呼び出しはCのAPIを通すのが一般的で、メソッドをもったクラスや構造体、抽象的なインタフェースなどを言語間で翻訳できるものはあまりない
(C++とPythonを連携させるpybind11や、RustとPythonを連携させるPyO3などはうまくやってる例)

そういう点でC++と相性の良いものってだいぶ限られると思う
C APIを通すならどの言語からでも呼べるけど、C++のAPIを翻訳するには言語あるいはライブラリによるサポートが必要

**デフォルトの名無しさん** · 2024/08/31(土) 09:57:33.39

「RustとC++は相性が悪い」というよりも「C++と相性が良いのはNimなどに限られる」という感じじゃないかと思う
そういやC++の後継を目指してたCarbonってどうなってるんだろ

**デフォルトの名無しさん** · 2024/08/31(土) 10:01:46.87

Nimのような弱小言語を使う人は今後も極少数に限られるから意味がないよな

**デフォルトの名無しさん** · 2024/08/31(土) 10:04:38.88

C++のメモリ管理とNimのメモリ管理はは全く異なっている
相性がいいなんて話はまやかし

**デフォルトの名無しさん** · 2024/08/31(土) 10:08:52.28

>RustとPythonを連携させるPyO3

これはC++要素無いだろ

**デフォルトの名無しさん** · 2024/08/31(土) 10:28:40.41

>>539
C++に限った話ではなく、クラスやメソッドといった概念を異なる言語間 (ここではRustとPython) でうまく翻訳できてる例として書いた

他だと、例えばC#とRustを連携させる csbindgen はFFIをしやすくはしてくれるけど、メソッド付きのクラスなどは作れずAPIはほぼCになるといった感じ

**デフォルトの名無しさん** · 2024/08/31(土) 10:40:19.97

>>530
まだ顕在化していないものに対してあれこれ考えるのは
難しいことができる「才能」とは違った「センス」が必要なんだよね

そして学校でも企業でも才能で判断することはやっているけど
センスに関しては無頓着というか、センスに気づくにもセンスが要るということで
そもそもそういうものがあることを分かっていない人が多い

**デフォルトの名無しさん** · 2024/08/31(土) 11:37:38.42

>>540
>クラスやメソッドといった概念を異なる言語間 (ここではRustとPython) でうまく翻訳

きみは何も判ってないな

**デフォルトの名無しさん** · 2024/08/31(土) 12:39:33.76

カーネルメンテナーの中にはここにいるような
rust信者は死ねとか思ってる人いるんやろ

**デフォルトの名無しさん** · 2024/08/31(土) 12:42:56.23

RustがC++と相性が良いと思ってる(だけじゃなくてそう喚き散らしてる)Rust信者は死ねば良いよ

**デフォルトの名無しさん** · 2024/08/31(土) 13:15:38.97

>>542
中身のない否定じゃなくて役に立つこと書いて
PyO3も内部的にはPythonのC APIを通してFFIしてることは分かってる
それをライブラリ側で抽象化してRustのメソッド付きの型をPythonのオブジェクトに返還してるので、そこそこうまく翻訳できてると言って良いんじゃない？

**デフォルトの名無しさん** · 2024/08/31(土) 14:19:45.17

カーネルデベロッパはRustよりZigが好きだと思うよ
ZigこそCの置き換えを担う
RustはC++の置き換えとして役割を全うしてくれ

**デフォルトの名無しさん** · 2024/08/31(土) 14:34:53.19

企業や国防総省や各ソフトウェアプロジェクト等が解決したい、人間の手に依らない、様々な安全性の保証を、Zigは解決しないことが、企業スポンサーの量質や、政府による支持の差となっています。

**デフォルトの名無しさん** · 2024/08/31(土) 16:51:39.82

言語一決定戦

**デフォルトの名無しさん** · 2024/08/31(土) 18:46:49.67

Rustのライブラリまわりの現況ってどう思ってる？
プロジェクトでライブラリを使うと、他の言語に比べて依存ライブラリが多くなりがち＆1.0未満のライブラリが多いな気がしてるけど、みんな気にしないもの？

**デフォルトの名無しさん** · 2024/08/31(土) 19:46:25.63

>RustはC++の置き換えとして

まだこんなこと言ってる馬鹿がいるのか

**デフォルトの名無しさん** · 2024/08/31(土) 19:47:21.29

>>549
cratesは破綻してる

**デフォルトの名無しさん** · 2024/08/31(土) 20:11:59.68

>>549
考え方を180度変えるとわかりやすい
クレートは可能ならば小さければ小さいほど良い
並行してコンパイルできるメリットがあるだけでなく
重複コードもなるべく無くせるメリットもある
特にunsafeを含む基礎的な汎用な機能の場合に
大きなライブラリにその同じ機能を持つコードが各々に別々に入ると
unsafeの監視も各々で個別に無駄に重複して行う必要となってしまう
この点でも小さく分けたほうが望ましい