Rust part33

**デフォルトの名無しさん** · 2025/08/15(金) 17:49:30.70

公式
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 part32
https://mevius.5ch.net/test/read.cgi/tech/1755057787/
Rust part31 https://mevius.5ch.net/test/read.cgi/tech/1751545806/
Rust part30 https://mevius.5ch.net/test/read.cgi/tech/1748392296/

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

**デフォルトの名無しさん** · 2025/10/25(土) 12:27:15.75

そりゃ先頭ポインタと長さを返すだけで済む&str返しやスライス&[T]返しが圧倒的に速いよ

**デフォルトの名無しさん** · 2025/10/25(土) 12:30:11.50

>>411
実際のアプリではそこまで差は出ないでしょ
マイクロベンチマークが見せる幻想

**デフォルトの名無しさん** · 2025/10/25(土) 12:36:43.77

&str返しができる状況でString返しをしてしまうセンスだと至る所で似たような非効率をしてしまいかねない

**デフォルトの名無しさん** · 2025/10/25(土) 14:30:41.07

そもそもそのへん無頓着ならPythonとかのスクリプトでよくねっていう気も

**デフォルトの名無しさん** · 2025/10/25(土) 15:28:17.84

たまにはCowのことも思い出してあげて🐮

**デフォルトの名無しさん** · 2025/10/25(土) 16:30:57.36

>>411
繰り返し呼ばれない関数で文字列がそれほど長く
速度的なメリットよりもライフタイムを引きずり回すデメリットが大きくなる場合は
&str返しできる状況でもstring返しをする

それ以外は&strで返せるなら&strを選ぶのが基本

**デフォルトの名無しさん** · 2025/10/26(日) 12:11:46.95

文字列は用途によってはstring_cacheなど使ってintern化すると一気に扱いやすくなるよ

**デフォルトの名無しさん** · 2025/10/26(日) 15:33:24.64

「用途によっては」「条件によっては」を付けたらだいたい何でも正しいよ。
つまり無意味だってことだ。

**デフォルトの名無しさん** · 2025/10/26(日) 15:48:22.18

何にでも向き不向きがあり万能はないため特徴と用途を比較して適切に選ぶ必要がある
文字列の比較があるならinterningは有利
同じ文字列が出てこないなら機能を発揮しない
それでも64bit ID化される点で参照や所有権を気にすることなく気軽に扱える視点での利点はあるかな

**デフォルトの名無しさん** · 2025/10/26(日) 22:42:01.01

https://itest.5ch.net/mevius/test/read.cgi/tech/1757733847/52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ

5chのRust信者は程度が低いなｗ安全性への認識がこんなものかｗｗ

**デフォルトの名無しさん** · 2025/10/26(日) 22:50:15.71

高い抽象度で使いやすい言語は他にもあるけど速さ省メモリを両立させた言語はRustが初だな
それだけでも十分に価値はあるけどセキュリティ面から今重視されている安全性まで両立させたことが決定打

**デフォルトの名無しさん** · 2025/10/26(日) 23:04:51.09

> 安全性などはついでのオマケ
　
安全性に勝るものなどないのに馬鹿丸出しｗ

**デフォルトの名無しさん** · 2025/10/26(日) 23:17:12.99

安全性が使用動機でなくても
他のメリットも他言語に例がなく十分満足できる言語とは言える

**デフォルトの名無しさん** · 2025/10/26(日) 23:20:44.90

Rustは実際はc++の代用として使われる事例がほとんど
ユーザーは欧米に偏っていて一番IT人材が多いインドではほぼ使われていない

**デフォルトの名無しさん** · 2025/10/27(月) 00:24:06.81

>>425
インドでもRust利用企業が多い

Companies that use Rust in India
https://theirstack.com/en/technology/rust/in

**デフォルトの名無しさん** · 2025/10/27(月) 02:06:07.73

下馬評垂れてればプログラマーとしての格が上がるとでも思ってるんだろうか

**デフォルトの名無しさん** · 2025/10/27(月) 06:13:04.93

>>425
各スクリプト言語からRustが多いよ
例えば遅くて困っていたツールなどで新たに良いものに作り直す時にRustが選ばれてる
先週このスレで話題になってたPythonのツールの話もそれだね

**デフォルトの名無しさん** · 2025/10/27(月) 06:31:46.50

rustにも機械学習ライブラリあるしaiもrustでよくね

**デフォルトの名無しさん** · 2025/10/27(月) 09:29:34.52

>>429
そういう実際の経験に基づく説得力のあるコメントは参考になる
やっぱ人工知能を実装するならRust一択という結論に至った
2位の候補はC++だけど僅差でRustが使い勝手上かなあ

**デフォルトの名無しさん** · 2025/10/27(月) 09:32:19.04

>>428
遅くて困っていたツールってほど遅いのは普通に設計ミスじゃ無いの
たとえばspawnせずにシングルスレッドで回してる箇所見落としてるとか
言語による性能差意識できるほどRustがいいとは思えん
わざわざ他の言語で書くより、元のプログラミング言語でリファクタリングの方が楽だと思うけど

**デフォルトの名無しさん** · 2025/10/27(月) 09:34:42.42

>>426
英語はよくわからんけど、408社ってインドの有名企業のほぼ全て採用ってことか
メジャー企業はインフォシステムとかタタとかしか知らんがそこまで普及したのはここ数年よね
なんか日本より導入進んでね？

**デフォルトの名無しさん** · 2025/10/27(月) 09:36:22.75

>>425
欧米とインドだと案件の内容が全く違うんだよなあ
たとえばフロントエンドをインドに外注とかならRust使わんし
あえてバックエンドをインドで開発？？あんま無いよなあ。バックエンド系の新サービスは欧米強いもんなあ

日本も同じこと言えるけど;;;

**デフォルトの名無しさん** · 2025/10/27(月) 09:47:02.67

>>431
実際にJavaScript・Python・Rubyなどスクリプト言語の補助ツールはRust製が多いよ
言語による性能差はあるのでしょう

**デフォルトの名無しさん** · 2025/10/27(月) 13:52:59.21

TypeScriptのコンパイラは色々あった末結局goで書き直されたな
rustになるかと思ってた

**デフォルトの名無しさん** · 2025/10/27(月) 15:03:44.84

>>431
設計をやり直す機会に書きやすい言語Rustに変更する場合が多いためRust製が増えた

>>435
それは事情と結果が解説されているが、元のコードと可能な限り1対1に対応する『移植』をしたかった
クラスベースの言語や非GC言語はその点で元コードと対応がとりにくくて脱落し、たまたまGoだけ上手くいった

**デフォルトの名無しさん** · 2025/10/27(月) 15:22:52.00

Rust で書いて速くなるものは C でも C++ でも速くなると思う。
適切に再設計できれば。

ただ、書き直す機会があるときにこの時代にあえて C や C++ を使いたいとは思わないし、
元が C や C++ だったら同じ言語で書きなおすと元の設計に引きずられて同じような駄目なことをまたやってしまう。

Rust が特別に良いとまでは思わないけど「一新する良い機会」ではあった。

Go も良い言語だと思うけど抽象度は高くない。
C の駄目 (というか面倒くさい) なところである文法の不必要な複雑さやメモリ管理を楽にしたという側面が強くて、
大規模なプログラムを整理するのはちょっとしんどい。
出来るという人もいるんだけどそういう人はたぶん C でも出来てしまうタイプの剛腕だから参考にならない。

**デフォルトの名無しさん** · 2025/10/27(月) 15:53:13.91

そうだよな
TypeScriptの件がたまたまGoだけJSと1対1の対応を取れたのも、Goが抽象度高くない言語だったため

**デフォルトの名無しさん** · 2025/10/27(月) 17:49:39.72

Rustが欲しいというよりCargoが欲しいんだよ
って思ってたらCabinとかいうの見つけて笑った

**デフォルトの名無しさん** · 2025/10/27(月) 18:45:30.45

でもなんでRustは欧米中心で使われててその他で低いんだ？
コミュニテイーの所属者もそんな分布でアジアは低い
１位アメリカ
２位ドイツって
日本は11位

**デフォルトの名無しさん** · 2025/10/27(月) 19:32:35.62

Goも似たような感じだね
単にsurveyのアナウンスが拡散されるプラットフォームの人口分布に引っ張られているだけな気もする
RedditとかHackerNewsとか

**デフォルトの名無しさん** · 2025/10/27(月) 19:41:30.85

>>438
違うよ
Rustでも抽象度の低いコードは書けるけど、メモリ管理と所有権システムが邪魔で一対一対応が無理

**デフォルトの名無しさん** · 2025/10/27(月) 19:42:44.69

リファレンスが英語だからな
ガイドは翻訳されてるけどライブラリ周りはどうしようもない

**デフォルトの名無しさん** · 2025/10/27(月) 20:06:35.18

でも中国5位じゃん

**デフォルトの名無しさん** · 2025/10/27(月) 20:56:19.83

>>442
その説明は既に>>436で書いた
所有権システムとメモリ管理を並列に「と」で並べるのはおかしい

**デフォルトの名無しさん** · 2025/10/27(月) 21:04:31.26

Rustのコレクションは移動なしでは書けまい

**デフォルトの名無しさん** · 2025/10/27(月) 23:32:35.09

>>446
意味不明だな
移動は最も基本的な不可欠な概念
移動の概念がなければコレクションどころか何も動かない

**デフォルトの名無しさん** · 2025/10/28(火) 03:31:36.61

Rustのコレクションは基本的でかつ非自明的にすごい
それはシャローコピーでもディープコピーでもないものが書かせた

**デフォルトの名無しさん** · 2025/10/28(火) 17:50:32.18

>>447
バカなの？

**デフォルトの名無しさん** · 2025/10/28(火) 18:01:51.21

>>446
コピーはダメだけど
コピーよりコストが安くなり得る移動は問題ないでしょ

**デフォルトの名無しさん** · 2025/10/28(火) 19:07:26.87

goてunixの作者が作っとうけえあんなに使われてるんかな
ポイント使えるのにgcがあるとゆうようわからん仕様

**デフォルトの名無しさん** · 2025/10/28(火) 23:49:42.09

>>451
Goのポインタは構文はC風だが、できることはJava等のGC言語のオブジェクト参照とほぼ同じ
そして、GC言語のオブジェクト参照はポインタとして実装されており、ポインタとGCの組み合わせは全く矛盾しない

**デフォルトの名無しさん** · 2025/10/29(水) 01:38:08.80

C#だってGCあるけどポインタ使えるじゃん

**デフォルトの名無しさん** · 2025/10/29(水) 12:14:41.38

DBを使用するスマホアプリのバックエンド開発でRustを使用してるけど、sqliteがシングルスレッドでしか使えないから
逆に複雑な設計を求められるな。慣れるまできつい

**デフォルトの名無しさん** · 2025/10/29(水) 15:34:17.17

Rustエンジニアをクビにして代わりにペチパー雇って、浮いた金でMySQLに変えた方が遥かに速くなりそうだな

**デフォルトの名無しさん** · 2025/10/29(水) 17:35:51.56

RustはSingletonの初期化と共有がすっきりしないな
初期化忘れのunsafeが付き纏うからどこかで割り切らないといけない

**デフォルトの名無しさん** · 2025/10/29(水) 19:33:33.85

once_cellでええやん

**デフォルトの名無しさん** · 2025/10/29(水) 21:05:45.94

OnceCellのget_or_initだと初期化処理が動くタイミングが読めない
↓
気持ち悪いからmainの最初で初期化する
↓
共有する時に毎回初期化済みかチェックするの無駄では
↓
unsafe「呼んだ？」

**デフォルトの名無しさん** · 2025/10/29(水) 23:50:28.94

そんなコード書くやつはクビ

**デフォルトの名無しさん** · 2025/10/30(木) 00:25:31.66

別にチェックしたらいいやん
逆にそんな初期化タイミング気にする理由教えてよ
「最初にたまたま使うタイミングで」初期化で自然なのにあえてメイン関数で初期化する理由

**デフォルトの名無しさん** · 2025/10/30(木) 00:26:18.06

>>454
sqlite 嫌いや

**デフォルトの名無しさん** · 2025/10/30(木) 00:40:46.28

初期化で重い処理があると変のタイミングで遅延が発生するのが気になる
最初にxxx_init（gl_initとか）で初期化するライブラリに馴染んでるのもあるけど

**デフォルトの名無しさん** · 2025/10/30(木) 01:29:19.31

つかOnceCellじゃなくてLazyCell使えば？
初期化タイミング固定したいなら一発getしとけばよし

**デフォルトの名無しさん** · 2025/10/30(木) 03:16:33.13

>>454
>sqliteがシングルスレッドでしか使えないから
sqliteはマルチスレッドでも使えるぞ？

**デフォルトの名無しさん** · 2025/10/30(木) 03:58:11.87

dockerhub見るとポスグレのほうがマイエスの2倍くらいpullされとうけどやっぱマイエスてオラクルだから嫌われてるの？

**デフォルトの名無しさん** · 2025/10/30(木) 04:18:06.36

>>463
最初のアクセス時に自動初期化してくれるだけでよいならDeref/DerefMutが使えるLazyCellが圧倒的に扱いやすいね
そうでなく初期化のタイミングを自由にして初期化以前はNoneを返したりset/takeを使ったりしたいならOnceCellだね

**デフォルトの名無しさん** · 2025/10/30(木) 10:22:35.58

どっちもスレッドセーフじゃないだろ

**デフォルトの名無しさん** · 2025/10/30(木) 10:35:58.35

そっすね

**デフォルトの名無しさん** · 2025/10/30(木) 10:41:04.39

それぞれに対応するスレッドセーフ版のOnceLockとLazyLockがある

**デフォルトの名無しさん** · 2025/10/30(木) 10:48:00.79

なのでそれを常識としてOnceXxxxとLazyXxxxの性質の違いの話かと

**デフォルトの名無しさん** · 2025/10/30(木) 10:52:57.20

>>458
共有前にmainで必ず初期化するのであれば
共有後に毎回初期化済みかチェックする必要ない

逆に共有後の初回アクセス時に初期化するという形をとるなら
初期化済みかどうか毎回チェックするようなコードがどこかに必要

毎回チェックするコードを自分で書きたくなければ
LazyLock等に肩代わりしてもらえという話

**デフォルトの名無しさん** · 2025/10/30(木) 11:04:47.24

>>466,470
LazyCell/LazyLockのget/get_mutがもうすぐstabilizeされるから
初期化以前はNoneを返すというのはどちらでも同じようにできるようになる

初期化関数で引数を受け取る必要もなく常に固定の初期化関数を実行すればいいだけならLazyCell/LazyLock
引数を受け取ったり条件によって違う初期化関数を実行したい場合はOnceCell/OnceLock
これが基本的な使い分け

**デフォルトの名無しさん** · 2025/10/30(木) 11:23:27.81

使い勝手が天と地の差
Lazy～はderefできるから*Xでアクセスできてコードも見やすい
Once～は返値Option処理かget_or_init(|| ...)が必要

**デフォルトの名無しさん** · 2025/10/30(木) 11:31:00.93

シングルスレッド＋遅延評価ではタイミングが不明
別スレッドのスタックに置けば遅延しないのでかえって違和感が少ない

**デフォルトの名無しさん** · 2025/10/30(木) 12:35:20.68

>>473
それは使い分けの結果であって原因ではないからな

LazyCell/LazyLockでもinterior mutabilityを使えば
初期化時に引数を受け取るのと同じようなことができるが
get_or_init以上に使い勝手が悪化するから
derefしたいかどうかで選ぶものではない

**デフォルトの名無しさん** · 2025/10/30(木) 13:04:12.82

Option処理をしたくないとき
JavaにたとえるとNullPointerExceptionをcatchしたくないとき
必要なのは「catchされませんでした」みたいなパニックを容認すること
これがスタンダード

unsafeが必要だという考えはスタンダードではない

**デフォルトの名無しさん** · 2025/10/30(木) 13:10:40.17

unsafeもpanicもどっちも自由に使えばいい
panicを禁止するためにunsafeを使いたいのだとしたら自由とは言えない

**デフォルトの名無しさん** · 2025/10/30(木) 21:08:57.21

>>476
>Option処理をしたくないとき
まずこれが全くスタンダードじゃない
Option処理をしたくないなどという理由は容認されない

**デフォルトの名無しさん** · 2025/10/30(木) 21:45:45.78

例外処理でも条件分岐でも、わざわざ明記することはあっても、いつもそんな起きないことを書いていたら、他人には起きる例外だと認識されてしまう。

**デフォルトの名無しさん** · 2025/10/30(木) 21:53:26.04

Optionは長さに制限があるキューと考えられる
キューが空なら読む側はブロックすればいいのにブロックしないから無駄に複雑になる

**デフォルトの名無しさん** · 2025/10/30(木) 21:56:50.09

？

**デフォルトの名無しさん** · 2025/10/30(木) 21:59:43.38

>>475
そこは併用することで解決できる
まずOnceLockで変数FOOの場合
初期化は例えばこうなる

static FOO: OnceLock<String> = OnceLock::new();
let foo = std::env::var("FOO").expect("no 環境変数FOO");
FOO.set(foo).expect("FOO: 初期化済");

このOnceLockのFOOの利用はこうなり可読性の悪い欠点がある
println!("FOO: {}", FOO.get().expect("FOO: 未初期化"));

一方でLazeLockで変数BARの場合
初期化で引数を渡せない欠点を先程のFOO活用で補える

static BAR: LazyLock<String> = LazyLock::new(|| BAR初期化関数(FOO.get().expect("FOO: not initialized")));
fn BAR初期化関数(foo: &str) -> String {
format!("適当に{foo}を変換")
}

このLazyLockのBARの利用はderefでこうなり可読性が向上する
println!("BAR: {}", *BAR);

**デフォルトの名無しさん** · 2025/10/30(木) 22:01:59.88

そういうのは一番嫌われる

**デフォルトの名無しさん** · 2025/10/30(木) 22:02:57.95

意味のない値に意味を持たせるのは最悪

**デフォルトの名無しさん** · 2025/10/30(木) 22:17:52.20

FOOやBARは例示で用いる昔からの慣習だよ
Rustの標準ライブラリのdocでも使われてるよ

**デフォルトの名無しさん** · 2025/10/30(木) 23:31:49.22

2進数に集合の意味をもたせるとか、方程式に図形の意味をもたせるとかね

**デフォルトの名無しさん** · 2025/10/31(金) 00:39:35.14

>>482
さすが汚コード製造機の二つ名は伊達じゃないな
可読性が向上するｗ

**デフォルトの名無しさん** · 2025/10/31(金) 01:23:46.44

#defineが嫌われていなければexpect云々を#defineするだけで解決するが
嫌われているのが現実？
いや、好感度など無視して解決可能というのが現実じゃないか

**デフォルトの名無しさん** · 2025/10/31(金) 01:26:08.34

C/C++のクセで毎回、何かを確認しないといけないと思い込んでいるのかな？

**デフォルトの名無しさん** · 2025/10/31(金) 01:36:15.69

LazyLockは変数宣言を見れば初期化のための式や関数を追える点でも可読性いいよな

**デフォルトの名無しさん** · 2025/10/31(金) 02:15:05.64

Cellを激推ししてた時代の複オジを思い出した
成長しないね

**デフォルトの名無しさん** · 2025/10/31(金) 03:52:17.44

C++のように使いたい人間がいるから面倒なんだよなあ

**デフォルトの名無しさん** · 2025/10/31(金) 04:51:55.42

久しぶりにC++いじったら、依存ライブラリ管理がめんどくさすぎてキレそうになった
cargoはえらい
cmake大嫌い

**デフォルトの名無しさん** · 2025/10/31(金) 07:07:09.98

OnceLockやLazyLockを嫌いな人は代わりに何を使っているの？

**デフォルトの名無しさん** · 2025/10/31(金) 08:13:57.15

Mutex<Option<T>>

**デフォルトの名無しさん** · 2025/10/31(金) 08:16:32.55

>>495
デタラメな回答はダメ

**デフォルトの名無しさん** · 2025/10/31(金) 08:43:37.37

初心に帰ろう
static mut FOO: MaybeUninit<Foo> = MaybeUninit::zeroed();

**デフォルトの名無しさん** · 2025/10/31(金) 08:47:38.08

unsafeは論外

**デフォルトの名無しさん** · 2025/10/31(金) 11:44:05.74

デタラメがダメならやはり
ウソでも本当でもないポストモダンみたいな言葉を話すのが一つの手段なんだよな

**デフォルトの名無しさん** · 2025/10/31(金) 14:32:08.02

>>482
なんだこれ？
BAR初期化関数の中で普通に環境変数読めばいいだけだろ？
しかもこんな雑にpanicだらけのコード書くやついたらブチ切れるぞ

**デフォルトの名無しさん** · 2025/10/31(金) 14:41:51.16

まあいいじゃんそういうの

**デフォルトの名無しさん** · 2025/10/31(金) 14:48:40.46

>>500
exampleで本題ではないエラー処理を略すのは常識なんだがdoc.rust-lang.org見たことない人なんやろか

**デフォルトの名無しさん** · 2025/10/31(金) 16:19:06.11

現実にはあり得ないコードで可読性を論じるおバカさん乙

**デフォルトの名無しさん** · 2025/10/31(金) 16:34:52.47

代案を出せばいいんじゃね

**デフォルトの名無しさん** · 2025/10/31(金) 18:21:19.45

案が増える保証はどこにもない
コメのように減産も増産もありうる

**デフォルトの名無しさん** · 2025/10/31(金) 18:29:01.57

「批判するなら代案だせ」ww
度し難いクソコードに代案を求めるなよ

しかも既に代案出してもらってるというのにこのバカは

**デフォルトの名無しさん** · 2025/10/31(金) 18:45:07.30

OnceLockとLazyLockがクソコードってRustのスレッドセーフ初期化で辿り着いた最善案なのに

**デフォルトの名無しさん** · 2025/10/31(金) 18:47:08.71

代案はZigを使うこと

**デフォルトの名無しさん** · 2025/10/31(金) 19:49:57.01

昔は初期化のためにlazy_static!が使われてた
そこへ改良されたonce_cell::sync::Lazyが登場した
それを標準ライブラリに取り込んだのがstd::sync::LazyLockで最終形

**デフォルトの名無しさん** · 2025/10/31(金) 20:47:30.17

質問者が消えて要件不明なのにいつまでも基礎的な部分を整理だけし続けるいつものやつ

**デフォルトの名無しさん** · 2025/10/31(金) 21:12:30.84

ギリギリセーフは最善ではない
細かいルールに依存してしまうので些細なルール変更でアウトになる
という基礎知識

**デフォルトの名無しさん** · 2025/10/31(金) 21:15:37.01

>>495
MutexとLazyLockは役割が全く異なる。
staticで使う場合にその目的に応じて以下の3つに使い分けられる。
LazyLock<T> 内部可変は不要で動的初期化をしたい場合
Mutex<T> 内部可変が必要で静的初期化をしたい場合
LazyLock<Mutex<T>> 内部可変が必要で動的初期化をしたい場合