Rust part33

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

AstralのイグジットはVCの成功シナリオとしてはG/A/Mに買収くらいしかないでしょ
もしくはdockerみたいに売り時を逃した挙句にエンプラ向けの企業と組んで細々とやるかだな

**デフォルトの名無しさん** · 2025/10/22(水) 13:55:31.39

Astralは要はAnacondaの商売を乗っ取ってやろうってことでしょ?
Anacondaは従業員300人いるらしいから儲かってそう

**デフォルトの名無しさん** · 2025/10/22(水) 14:34:51.47

Anacondaは突然の有償化で崩壊、自滅したでしょ
非難されることは目に見えてたはずだけど、金払う客が少しでも残れば十分に資金回収できると踏んだんだろう
収益化が見えずVCから資金回収を迫られて強引に手仕舞いすることになった形

**デフォルトの名無しさん** · 2025/10/22(水) 18:48:15.08

複式簿記おじさん「国や企業の借金は投資家の資産です（回収しないとは言ってない）」

**デフォルトの名無しさん** · 2025/10/23(木) 00:17:51.64

アナコンダの件は企業は無料のを使っちゃいけないってお灸を据えた形にはなってて、うちの会社でも金払って使ってるわ
やっぱプログラマーとしては無料ほど高くつくものはないしサポート体制継続するなら有償でもいいって思うベンダーが我が多いってこと

**デフォルトの名無しさん** · 2025/10/23(木) 00:49:38.88

Anacondaみたいに全力で嫌われちゃうと今後はもう先細りしかないからなあ
企業での利用だったらとりあえずは金払ってもいいけど、将来性の面で問題があるから乗り換えを考えるわ

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

引数がふたつ以上あるときのライフタイム注釈ているかこれ
アプデで省略できるようにしてくれんかな

**デフォルトの名無しさん** · 2025/10/23(木) 08:02:52.36

確かに面倒だけど、実装から推論するのはRustの根本設計思想的にNGだからどうしようもない
どうせ書くのAIなんだから今となってはもうどうでもいいことだし

**デフォルトの名無しさん** · 2025/10/23(木) 08:26:01.60

大した手間ではなく
むしろライフタイム注釈は有った方が読みやすく
参照の流れも理解しやすい

struct Foo<'a, 'b, 'c>も
3系統の参照が入っていると明示され
他の言語よりも理解しやすくなってる

**デフォルトの名無しさん** · 2025/10/23(木) 09:55:41.49

なるほど。。。
変数に生存期間があるのはわかるけど「変数の型」にまで生存期間があるってのがようわからんぜよ

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

ライフタイム注釈も型のジェネリックパラメータの一つと考えればよいかと
参照のライフタイムは現行関数を抜けたら即死ぬ参照からもっと祖先の関数まで持ちこたえる参照そして永久不滅の参照まで色々あるけどジェネリックにいずれも入り得る

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

>>402
なるほどじゃねーよ
簡単に騙されんな

**デフォルトの名無しさん** · 2025/10/23(木) 12:08:09.39

>>401
設計者も手間だと思ってるから引数一つの場合の省略ルールがあるのに何言ってるの
引数が複数のときにライフタイムの明示が必須なのは、シグネチャだけの推論では多くの場合において過剰に強い制約を生じるから
仮にシグネチャだけで安全に推論するなら、戻り値のライフタイムは最もライフタイムの短い引数に合わせるしかないだろ？
そうするとスコープがネストされているような場合に戻り値が短いスコープの方に制約されてしまう
実用上はそれでも問題なく使えるケースは多いはずだが、本来の必要最低限の制約とは食い違うというのが設計者には許せなかったのだろう

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

だからこそライフタイム注釈の明示的な指定が重要
それがあることでコンパイラもコードレビューも正しい判断ができる

**デフォルトの名無しさん** · 2025/10/23(木) 14:21:00.93

注釈はプログラマの意図の表明だ。
意図と違う形で辻褄が合っても問題だろ。
よほど自明の場合だけ省略できるようになってるけども、どのレベルから自明と言えるかは感覚的だからな……

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

ライフタイムの指定を省略できる場合であっても、省略すると戻り値のライフタイムの制約が必要以上に強くなってしまうケースは普通にあって、
>>405の理屈を厳格に適用するなら引数が一つでもライフタイムの明示は必須だ
食い違いが生じるケースがどれくらいの頻度で発生するかという統計の問題なのよ

**デフォルトの名無しさん** · 2025/10/23(木) 15:27:37.26

二つを'a 'aにすると寿命の短い方に揃えられてしまうけど
二つを'a 'bにすると各々の寿命が尊重されて後に出来ることの範囲が広がるって話？

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

であるか

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

ライフタイムめんどくせえし全部stringで返すべと思ってたら&strとstringの速度差はだいたい10倍あるみたいなのでやっぱできるだけ&strで返そうとおもた🐼

**デフォルトの名無しさん** · 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>> 内部可変が必要で動的初期化をしたい場合

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

内部可変ってそういう意味じゃねえから

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

このようにRustは非常に使いにくい言語です

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

初期化と代入の役割は全く異なるとも言えるし、ほとんど同じとも言える
これも逆転しやすい
些細な変化で善悪が逆転する

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

>>507
君の書いた>>475がクソコードなだけで
クソコードで使われてるLazyLockやOnceLockがクソだという話ではない
下手くそな論点ずらしはやめろ

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

間違えた
クソコードは>>482だった

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

>>513
safe Rustではstaticは不変値になり不変参照しか得られない。
そのような不変参照しか持たない場合でも可変な借用を得られる仕組みが内部可変性。
>>512ではそのstaticで内部可変が必要な場合と不要な場合の区別が重要なので分けて説明したが、何を問題視している？

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

任意のTを実体化可能
内部可変を禁止できると思ってるなら事実誤認

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

>>516
コード見たけど何が問題なのか教えて

**デフォルトの名無しさん** · 2025/11/01(土) 10:00:34.52

>>520
482みたいなAIやら人工知能に書かせたコードの善し悪しなんて語っても無駄

**デフォルトの名無しさん** · 2025/11/01(土) 10:21:55.29

生成AIのほうが>>482なんかよりはるかにまともなコード書くぞ

**デフォルトの名無しさん** · 2025/11/01(土) 10:29:48.54

試しにChatGPTになぜクソコードなのか聞いてみた

====
以下のコードがクソコードだと言われました。なぜクソコードなのでしょうか？　どうすればクソコードじゃなくなりますか？

とても良い質問です。
このコード、**「動くけど設計として危険・臭い」**という典型的なクソコード（＝悪い設計例）です。
なぜそう言われるか、そしてどう直せばいいか、順を追って説明します。

なぜ「クソコード」扱いされるのか
① グローバル変数依存（隠れた順序依存）

BAR は FOO の値に依存しているのに、Rustの型システムではそれが表現されていません。
FOOをセットしてからBARを使うという順序前提が、コードの外にあります。
つまり：
…

② LazyLock と OnceLock の使い分けが不自然
FOO は「後でセットする」ための OnceLock
BAR は「自動で初期化する」ための LazyLock

しかし BAR の初期化に FOO が必要ということは、BAR の「自動初期化」が成立していません。
結局「FOOが先に初期化されていないと壊れる」＝「LazyなのにLazyでいられない」状態です。
…

③ 初期化エラーが実行時panic
expect("FOO: not initialized") は、
BARを最初に触ったタイミングでFOOが未初期化だったらpanic

という非常に脆い構造です。
初期化の安全性がコンパイル時に保証されず、実行時の偶然に依存しています。
…

**デフォルトの名無しさん** · 2025/11/01(土) 10:30:45.08

「動くけど設計として危険・臭い」という典型的なクソコードです！

**デフォルトの名無しさん** · 2025/11/01(土) 10:55:39.21

なぜAIはクソかを質問して
「AIの学習に人間が必要ということは自動初期化が成立していません」を生成できたら少しは信用できる

**デフォルトの名無しさん** · 2025/11/01(土) 10:58:56.69

>>518
たぶんRefCell/Mutex/RwLockあたりのロック付き型のことを内部可変性って呼んでるんだろうなって思ったけど

>不変参照しか持たない場合でも可変な借用を得られる仕組みが内部可変性。

この説明ならやっぱりそういう意味で書いてそうだね
Cell<T>もAtomic***も、さらに言えばLazyCell<T>も内部可変じゃないことになるが、まあそんなわけはないのでちゃんとドキュメント読んでね

**デフォルトの名無しさん** · 2025/11/01(土) 11:04:56.46

言語に関係なく初期化ルーチンで必ず初期化を行なうグローバル変数などについては依存関係があってもいいんだよ
今回の場合は万が一その依存関係が崩れていればpanicで落ちるから完璧に安全でしょう
まずいのは依存関係が崩れても検知ができずに間違った未初期化の値のままプログラムが進むこと
Rustのpanicはこの基本概念に基づいて安全性のために存在しています

**デフォルトの名無しさん** · 2025/11/01(土) 11:40:18.77

>>526
Rustでは内部可変を段階的に説明していてどちらも正しい。

一番の基本は、内部可変とは不変参照しか持たない時でも可変を許すパターン
https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
Interior mutability is a design pattern in Rust that allows you to mutate data even when there are immutable references to that data
通常の説明ではこれで問題ない。

一方であなたの説明では一番大事な正確な定義が抜けているが、
Rustで内部可変とはUnsafeCellを用いていること、すなわちトレイトFreezeを実装していない！Freeze型を指す。
この！Freeze型とは内部可変をもたらすUnsafeCellを用いているか否かを示している。
AtomicもMutexもLazyLockも全て元を辿るとUnsafeCellが使われていて自動的に！Freeze型となる。
もちろん普段の説明ではこの厳密な定義を用いずに、内部可変とは不変参照しかない時でも可変を得られること、で構わないと思う。

**デフォルトの名無しさん** · 2025/11/01(土) 13:01:38.93

コード書くときにこういった謎の禅問答みたいなことを延々と続けてるのか
大変だな

**デフォルトの名無しさん** · 2025/11/01(土) 13:03:56.65

"allows you to mutate data"に対して「可変な借用を得られる」だと制限が強すぎて間違いだったのを理解したので
>>528では最初からそう言いたかったんですよってフリで「可変を許す」「可変を得られる」みたいな曖昧な表現にしれっと置き換える
これが所有権の複製話法です

**デフォルトの名無しさん** · 2025/11/01(土) 13:08:31.28

rustは外部のライブラリーに依存しないで書くのは難しいような気がするのだが

**デフォルトの名無しさん** · 2025/11/01(土) 13:08:31.85

>>529
どれも単なる基礎知識だろ
コード書くための前提

**デフォルトの名無しさん** · 2025/11/01(土) 13:19:59.11

>>514
Rustの抽象度が高いことを使いにくいと感じる人は色んな知識経験が足りないんじゃないかな
抽象度の高いほうが可読性も保守性も良くて使いやすいよ

**デフォルトの名無しさん** · 2025/11/01(土) 13:26:36.27

>>529
普通はRustでもバイブコーディングでAI任せにして何も考えないから安心
どうでもいいことにこだわってるのは複おじぐらい

**デフォルトの名無しさん** · 2025/11/01(土) 13:28:11.18

rustは(知った被りアンチも多く嘘や不正確な情報が蔓延しているので)使いにくい

**デフォルトの名無しさん** · 2025/11/01(土) 13:35:00.58

rustはeatherはresultがあるから要らないといってなくなったらしいが、
errorのところにerrorじゃないものを入れてokのところに、
okじゃないものを入れるのにみんな抵抗感は感じないのだろうか

**デフォルトの名無しさん** · 2025/11/01(土) 13:37:12.17

GCに依存できる環境だとここまで考えなくてもいいんでしょ？
大変は大変でその代わりメリットがあると

**デフォルトの名無しさん** · 2025/11/01(土) 13:39:02.26

>>537
GC言語にも抽象度の高い言語があるからそこは関係ないよ

**デフォルトの名無しさん** · 2025/11/01(土) 13:41:49.38

>>537
GC言語でもグローバル変数をそのまま使ったらスレッドセーフでないため競合して詰む
もちろんその初期化も同じ
Rust固有の問題ではなくどの言語でも必要な話

**デフォルトの名無しさん** · 2025/11/01(土) 13:51:01.37

>>536
Result型を本来の用途以外で使ったらコードレビューで絶対リジェクトされると思うよ
ResultとOptionは実用上での利用が多かったから標準ライブラリに入ったのであって、Eitherが使いたかったら外部ライブラリ使うか自作すればいい

**デフォルトの名無しさん** · 2025/11/01(土) 13:57:10.92

>>540
そんなことはない
標準ライブラリでもErrorを拡大解釈してエラー以外に用いている
特に多いのが値の返還にResultのErrorを利用
左右対称ならResultを使わずにeither crateを使うべき

**デフォルトの名無しさん** · 2025/11/01(土) 14:22:52.12

>>534
基本的な概念や仕組みを知らないままバイブコーディングしていたらコードレビューもできずに詰みそう

**デフォルトの名無しさん** · 2025/11/01(土) 14:52:04.69

謎の禅問答を学習したら知能は増え信者は減る？
いや信者が増える方が宗教だろ
科学を舐めるな

**デフォルトの名無しさん** · 2025/11/01(土) 15:33:03.66

複オジは嘘ばっかりだな

**デフォルトの名無しさん** · 2025/11/01(土) 15:37:15.60

抽象化を理解できずに謎の禅問答にみえる新たな科学かもしれぬ

**デフォルトの名無しさん** · 2025/11/01(土) 18:01:00.80

複おじもはや一周回ってRustアンチまである

**デフォルトの名無しさん** · 2025/11/01(土) 19:00:08.27

>>545
盛大なブーメラン

>>528のように
内部可変性という抽象概念の定義を
特定の具体的内部実装でしか説明できないやつが
抽象化を理解してるわけがないんだよな

いつも思うが複オジはマジで抽象化理解してないよね
>>482のようなクソコード量産するのも根本原因は同じだと思うよ

**デフォルトの名無しさん** · 2025/11/01(土) 19:22:28.52

両者が対等ならLeft、Right使うよりOwned、Borrowedみたいに名前つけてくれ
Leftが成功寄り、Rightが失敗寄りみたいな慣習を持ち出すならResultでいい

**デフォルトの名無しさん** · 2025/11/01(土) 19:58:52.73

成功失敗に使う言語もあるけどRustのEitherはLeftとRight完全に対等
Resultよりも高機能で強力
RustのEitherはもともとRayonのために作られてItertoolsもそのEitherを組み込んでいて事実上の標準

**デフォルトの名無しさん** · 2025/11/01(土) 21:11:37.16

>>546
本人にそのつもりは一切ないだろうが結果的にはアンチ活動家以外の何者でもないわな

**デフォルトの名無しさん** · 2025/11/01(土) 21:21:09.81

Rust使いはアホというイメージを与えると同時に、
あんまりにも盲信的かつ程度が低いもんだから他の人が「さすがにそれは違う」とRustに対して批判的なトーンで諫めるものだから、
自然とスレの空気がアンチっぽくなるんだよね

**デフォルトの名無しさん** · 2025/11/01(土) 21:22:50.18

困ったもんだよな

**デフォルトの名無しさん** · 2025/11/01(土) 21:30:17.22

servo、久しぶりに動かしてみたら、まあまあ出来てるな
ついでにversoプロジェクトが終了していたことを今さら知った

がわの部分、shellが機能不足過ぎて常用するブラウザーには到底ならないが
描画エンジンとしては現時点でも何かに使えそう

**デフォルトの名無しさん** · 2025/11/01(土) 22:29:09.83

Rust使いはアホではないけど概念的に普通にコード書くのも大変なんだなと

**デフォルトの名無しさん** · 2025/11/01(土) 22:47:39.33

抽象度の低い言語より書きやすい

**デフォルトの名無しさん** · 2025/11/01(土) 23:35:48.21

所有権の複製おじさん
データ参照の競合おじさん
可変を得るおじさん

**デフォルトの名無しさん** · 2025/11/02(日) 15:05:38.09

>>555
Rustより抽象度の低い言語ってメジャー言語ではCとC++しかないじゃん

**デフォルトの名無しさん** · 2025/11/02(日) 18:02:42.58

全部きれいなお姉さんに置き換えたら赦す心が芽生えた

**デフォルトの名無しさん** · 2025/11/02(日) 20:55:21.31

確かに船と同じでコードを女性に例えるともっと
大事に扱う気になるかも知れない

**デフォルトの名無しさん** · 2025/11/02(日) 23:53:23.75

>>557
Goも

**デフォルトの名無しさん** · 2025/11/03(月) 01:05:29.98

メスガキのほうがイメージしやすいかもしれん

**デフォルトの名無しさん** · 2025/11/03(月) 11:14:52.63

そういえば女性エンジニアって能力的な下限が男性底辺よりも上な気がする
組織による違いや生存者バイアス的なのもあると思うが

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

原初は職業プログラマは女性の仕事だったのに一気に男性が増えたのはなぜななのか

**デフォルトの名無しさん** · 2025/11/03(月) 11:55:28.00

男の1/100ぐらいしか女いないしな
数が多ければ多いほど無能と有能の差は広がる

**デフォルトの名無しさん** · 2025/11/03(月) 12:06:07.94

プログラマの最底辺は技術云々じゃなく基本的な就労適正に問題があるレベルだからなあ
女性は自分の申告しているスキルの範囲ではそれなりに真面目にきっちりと仕事をする奴が多い気がする
ダメならすぐ病んで消えるから職場的にはあまり問題にならないし

**デフォルトの名無しさん** · 2025/11/03(月) 12:14:09.94

Recent Rust Changes
https://www.ncameron.org/blog/recent-rust-changes/

**デフォルトの名無しさん** · 2025/11/05(水) 17:38:13.88

RustでESP32とオモたが、環境作りがムズイ。
Windows VSCodeでPlatformIOのようにサクっとできるようにならないもんかね？

**デフォルトの名無しさん** · 2025/11/05(水) 17:51:33.76

まだ発展途上じゃけえ
ほとんどのクレートがまだバージョン0だし

**デフォルトの名無しさん** · 2025/11/05(水) 18:21:47.42

>>567
cargoでespupしてespflashでええやん

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

anyhowみたいなライブラリが出てきたということは、Rustってやっぱり厳密すぎたんじゃないかな
次に流行る言語は妥協がありそう

**デフォルトの名無しさん** · 2025/11/06(木) 12:39:14.84

>>202
pythonでも標準ライブラリでasyncio.Lockが提供されてるよ

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

>>571
Pythonのasyncio.Lockは失格
対象となる値とロックの関係が保持されない
ロックを得なくても値の変更が可能

**デフォルトの名無しさん** · 2025/11/06(木) 13:33:07.83

Pythonはそういう用途に使う言語じゃない
まちがってる

**デフォルトの名無しさん** · 2025/11/06(木) 13:51:58.57

>>571
よく読んでごらん
安全性のための必須条件を満たしているかどうかの話だよ
Pythonはこの安全性を満たしていないね

202 デフォルトの名無しさん sage 2025/09/21(日) 02:43:46.06 ID:ETMxp5J0
Mutexなどロックしている間のみ変数にアクセスできるしくみを用意している言語はRustだけじゃね？

**デフォルトの名無しさん** · 2025/11/06(木) 14:12:27.56

>>571
複オジィッシング詐欺に引っ掛かるやつw

**デフォルトの名無しさん** · 2025/11/07(金) 16:08:21.14

Rustでスマホアプリのバックエンドを実装してるんだけど、sqliteがシングルスレッド前提だからそこだけ同期処理になるんよ
この領域を非同期で書けないの最高に気持ち悪い。まとめてsqlにデータを挿入しないで、データがバッファーに貯まったらダンプする処理とか同期で書くの生理的にきつい
tokioのchannelとstd::threadが混じっていく

**デフォルトの名無しさん** · 2025/11/07(金) 16:32:35.77

>>576
Rust云々の前にそんなクソみたいなアーキテクチャを見直してきなさい
そんなもんどう考えてもまともなDBMSとスクリプト言語の組み合わせより遅くなるんだからRustの恥晒しになるだけ

**デフォルトの名無しさん** · 2025/11/07(金) 16:44:11.59

>>576
sqlite担当へチャネルを使ってリクエスト
sqlite担当はそのチャネルに来たリクエストを次々と処理する

**デフォルトの名無しさん** · 2025/11/07(金) 17:22:18.89

>>577
iphone, androidで安定的に動く唯一のRDBであるsqliteがシングルスレッドでしか動かないからどうしようもないんですよ

>>578
自分も同じ結論に落ち着きました
本来なら非同期処理で書くべきようなことまで、ループ処理やタイムアウトを多用して同期で書くからムズムズするけど

**デフォルトの名無しさん** · 2025/11/07(金) 17:22:46.88

>>576
sqlx::SqlitePool

**デフォルトの名無しさん** · 2025/11/07(金) 17:36:37.18

>>580
ああっ。確かにsqlxを使う選択肢はありますね。失念してました
自分は実践でsqlxではなくrusqliteを技術選択しました
RDB用の単スレッドで動作させるならば、sqlxよりrusqliteの方が速いからです
別スレッドを立て、タスク管理をしてまでスループットを上げたいという条件下でsqlxは選びにくいと感じました

**デフォルトの名無しさん** · 2025/11/07(金) 17:38:03.28

>>576
sqliteは非同期には対応してないがマルチスレッドには対応していてシングルスレッド前提ではない
同時に書き込めるのは1コネクションだけなので書き込み処理を一つのスレッドにまとめる方法はよく採用されるけどそれをシングルスレッド前提と言ってる？

いずれにしろ非同期のラッパーを書いて同期部分は一箇所に隠蔽すればいいだけ
ラッパーが用意されてるライブラリもある

**デフォルトの名無しさん** · 2025/11/07(金) 17:39:57.53

>>577
バックエンドサーバーの話じゃなくてUIコード(フロント)から呼ばれるライブラリくらいの意味でバックエンドという言葉を使ってるのだと思う

**デフォルトの名無しさん** · 2025/11/07(金) 17:47:33.29

>>582 >>583
自分の言葉の選択の曖昧なところまで含めてすべてお見通しですね
Sqliteがシングルスレッド前提ではなく、制約がコネクションにかかること指摘ありがとうございます
同期のコードを集約して、非同期で包む方向で実装を進めていました。ライブラリについては調べてなかったです。有益な情報ありがとうございます
丁度そのあたりのコードで自作が増えて実装が複雑化しはじめていた頃なのでツールを調べてみます

**デフォルトの名無しさん** · 2025/11/07(金) 19:56:16.34

いつから健全なスレになった

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

sqliteて最近はcloudflareでも使われてるし最近流行ってるらしい🧐

**デフォルトの名無しさん** · 2025/11/07(金) 22:19:46.72

ワークロード的に明らかに問題が出ることが分かってるというのでなければ
とりあえずspawn_blockingを使うだけの方法から始めてもいいと思う

**デフォルトの名無しさん** · 2025/11/07(金) 22:33:36.98

>>582
彼の用途でそのマルチスレッド対応は意味がなくてスレッドMutexにより非同期タスクスケジューラのスレッドをブロックしてスケジューリング妨害となってしまう
つまりスレッドMutexではなくawaitで待つ非同期タスクMutexを使うべきだがsqliteは当然対応していない
そこでシングルスレッド前提で使う話なのかなと理解した
マルチスレッドで使う場合も非同期タスクとは別スレッドのsqlite用のスレッドプールを用意する形になるかと

**デフォルトの名無しさん** · 2025/11/08(土) 01:31:09.85

Debianのパッケージマネージャーであるaptが部分的にRustで書き直された影響で
RustがコンパイルできないマイナーなアーキテクチャがOSサポート停止になってしまうらしい
これは恨みを買うね

**デフォルトの名無しさん** · 2025/11/08(土) 13:19:45.72

aptのメンテナーすごい判断したな
メリットの方が大きいと踏んだからだと思うが、ノイジー・マイノリティの影響力を舐めてるわ

**デフォルトの名無しさん** · 2025/11/08(土) 13:56:10.82

実質的なメリットよりモチベーションの問題でしょ
DebianはLinux界隈の中では比較的大きな組織とはいえ所詮はコミュニティプロジェクト、
Rustを使えるならと活発に貢献してくれる若い奴1人のモチベ＝[ションは開発ｂｱける上で大ｂｫなファクターｂｾ
でも成演ﾊを享受するだｂｯのユーザーはｂｵばしば、大きｂﾈ企業の製品と涛ｯ等の体制や責粕Cがあるように滑ｨ違いしてるんｂｾよね
まｂRustの方はもｂﾍやコミュニテャBプロジェクトｂﾅはなく壮々たｂ髑蜉驪ﾆが顔を�Aね潤沢なリソ＝[スを有する組瑞Dなので、同様ｂﾌ言い訳は許さｂ黷ﾈいけどね

**デフォルトの名無しさん** · 2025/11/08(土) 14:53:09.75

シェア低くてもサポートしてほしいなら、自分でフォークして保守せえやってのが本来のOSSだからな