Rust part33

1デフォルトの名無しさん
垢版 |
2025/08/15(金) 17:49:30.70ID:N8TIzbWg
公式
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/19(日) 15:30:20.66ID:KbF8yeKr
>>364
さすがに無責任すぎるね
偉そうに>>350みたいな偉そうな物言いをする以前の問題だわ
2025/10/19(日) 15:54:16.06ID:OdTstqtC
脆弱な言語だな
2025/10/19(日) 16:32:09.86ID:Zym90vNK
実際問題としては責任はないから無責任ってのは当たり前の話ではあるな。
368デフォルトの名無しさん
垢版 |
2025/10/19(日) 16:52:25.14ID:Slfms1FR
中水準言語、高水準言語、ライブラリ、フレームワークとなんでもあるプログラミング言語を語るのは難しい。
2025/10/19(日) 17:00:18.30ID:/rAjciqO
rustfmtって最近Linusがウンカスってキレてたけどそれで放棄されたん?
2025/10/19(日) 17:09:39.48ID:pT0uE4PB
>>369
それとは直接関係ない
2025/10/19(日) 17:38:21.32ID:KbF8yeKr
>>367
個人になくともRust財団にはガバナンスや品質管理の責任があるし、
個人もテック企業の社員が会社から金貰って業務としてRustの開発をしているから自社に対して対価に見合った仕事をする責任はあるよ
2025/10/19(日) 21:02:09.84ID:1nCMsk87
rustfmt最後のリリースが2023年7月か
コード自体は普通に今もコミットされてるみたいだけど、なんでリリースしないんだろうね?
373デフォルトの名無しさん
垢版 |
2025/10/19(日) 22:44:25.22ID:DrStTzLd
複おじが現れたときだけ不毛に無意味に盛り上がるスレ
2025/10/19(日) 23:28:35.37ID:aXP8YVkp
>>358
RustでWebの話はサーバーサイド
例外的にフロントの話をする場合でもWebAssembly利用
もし別の言語の話をしているなら明示的にその言語名を書きなさい
375デフォルトの名無しさん
垢版 |
2025/10/20(月) 10:34:27.56ID:P1GCyUuj
rustメンテイナーて結構給料いいの?
2025/10/20(月) 11:45:59.23ID:1ojc0PtK
そりゃ大部分はAWSとかMSとかの米ビッグテックの社員だからな
余裕で年収20万ドルオーバーよ
2025/10/20(月) 12:06:58.50ID:/GCbdeTP
>>375
Mozillaの給与水準は他と比べるとかなり低いがアベノミクスのおかげでシンガポールや香港はおろか韓国や台湾にも抜かれた貧しい日本の給与水準から考えればかなり高い
2025/10/20(月) 12:15:16.08ID:pO4VJ3Hu
Mozillaの社員なんて大規模レイオフでもうほとんど残ってないでしょ
今のRustは>>376のようなビッグテックが主導してるよ
379デフォルトの名無しさん
垢版 |
2025/10/20(月) 16:59:56.26ID:SRWHAJh/
アベノミクスのおかげでGDP過去最高609兆円、平均年収過去最高460万円、税収過去最高75兆円です
2025/10/20(月) 18:51:31.70ID:DCd4aGrf
>>379
バカ発見
381デフォルトの名無しさん
垢版 |
2025/10/21(火) 03:24:38.73ID:HSwZmZe3
はえーやっぱ給料いいんか
ibmでlinuxかーねる書くみたいな仕事とかも国内じゃまあ無理やな
2025/10/21(火) 03:46:47.30ID:oB45GTIt
Rustの有力開発者はみんなAstralで働いてる印象
2025/10/21(火) 08:21:33.19ID:iTOwcHSI
んなわけないでしょ
たかが従業員50人くらいのスタートアップが自分のプロダクトじゃなくてRustの開発ばっかりやってたらVCがキレるわ
それに仮にAstralがRustの最有力なんだとしたらRustはPythonの奴隷ということになるが、お前はそれでいいのか
2025/10/21(火) 11:09:21.75ID:l+qlgu4b
嫌な絡み方だなあ
そんなに癇癪持ちならプログラムでバグ出たときどんだけキレるの
385デフォルトの名無しさん
垢版 |
2025/10/21(火) 12:19:27.25ID:XD7lhD4Z
そりゃあもう開発室は修羅場よ
2025/10/21(火) 12:51:53.63ID:zjI3zBX4
独裁者あるある
立法の奴隷をやめようという発想で行政を暴走させる

自分で立法しないやつは奴隷か独裁者にしかなれないんだよ
2025/10/21(火) 14:45:27.32ID:la/0iqhD
Servo 0.0.1 Release
https://servo.org/blog/2025/10/20/servo-0.0.1-release/

えっ?
2025/10/21(火) 15:11:56.06ID:oB45GTIt
>>387
先月ナイトリービルドを試して、すぐにフリーズして使い物にならんなと思ったけど
2025/10/21(火) 16:12:17.01ID:GptfFBSs
Astral は Python のパッケージ管理を商品にして儲ける計画らしいけれど、今のところ真っ当に動いていない。
金が消えていくだけで入ってくる仕組みがいまだに何も出来ていないので心配されてる。
本当にどうなってんだろ?
2025/10/21(火) 16:36:04.66ID:hpThpzIv
ユーザーベースを広げて競合を潰しておくと有償機能を発表した時にユーザーの逃げ道が少なくていいんだよ

uvよりruffの拡張のほうがマネタイズしやすいだろうな
2025/10/21(火) 16:42:06.09ID:9Q/0i2Gr
>>389
今の規模ならエンタープライズ向けの有償サポートだけで十分食えるでしょ
2025/10/21(火) 18:26:55.85ID:x1GCjqC3
今のuvやruffでは有償サポートビジネスは無理
マンパワーの面でも相性が悪すぎる
2025/10/22(水) 10:19:41.33ID:fivlyo3h
AstralのイグジットはVCの成功シナリオとしてはG/A/Mに買収くらいしかないでしょ
もしくはdockerみたいに売り時を逃した挙句にエンプラ向けの企業と組んで細々とやるかだな
2025/10/22(水) 13:55:31.39ID:zYS+C6gy
Astralは要はAnacondaの商売を乗っ取ってやろうってことでしょ?
Anacondaは従業員300人いるらしいから儲かってそう
2025/10/22(水) 14:34:51.47ID:9KZ10JwK
Anacondaは突然の有償化で崩壊、自滅したでしょ
非難されることは目に見えてたはずだけど、金払う客が少しでも残れば十分に資金回収できると踏んだんだろう
収益化が見えずVCから資金回収を迫られて強引に手仕舞いすることになった形
2025/10/22(水) 18:48:15.08ID:A3Ttm+W+
複式簿記おじさん「国や企業の借金は投資家の資産です(回収しないとは言ってない)」
2025/10/23(木) 00:17:51.64ID:SNNXXGtL
アナコンダの件は企業は無料のを使っちゃいけないってお灸を据えた形にはなってて、うちの会社でも金払って使ってるわ
やっぱプログラマーとしては無料ほど高くつくものはないしサポート体制継続するなら有償でもいいって思うベンダーが我が多いってこと
2025/10/23(木) 00:49:38.88ID:j/9CbFi3
Anacondaみたいに全力で嫌われちゃうと今後はもう先細りしかないからなあ
企業での利用だったらとりあえずは金払ってもいいけど、将来性の面で問題があるから乗り換えを考えるわ
399デフォルトの名無しさん
垢版 |
2025/10/23(木) 02:13:47.52ID:T3GhTn1Z
引数がふたつ以上あるときのライフタイム注釈ているかこれ
アプデで省略できるようにしてくれんかな
2025/10/23(木) 08:02:52.36ID:uSK82vvB
確かに面倒だけど、実装から推論するのはRustの根本設計思想的にNGだからどうしようもない
どうせ書くのAIなんだから今となってはもうどうでもいいことだし
2025/10/23(木) 08:26:01.60ID:EvN9HHeU
大した手間ではなく
むしろライフタイム注釈は有った方が読みやすく
参照の流れも理解しやすい

struct Foo<'a, 'b, 'c>も
3系統の参照が入っていると明示され
他の言語よりも理解しやすくなってる
402デフォルトの名無しさん
垢版 |
2025/10/23(木) 09:55:41.49ID:T3GhTn1Z
なるほど。。。
変数に生存期間があるのはわかるけど「変数の型」にまで生存期間があるってのがようわからんぜよ
2025/10/23(木) 10:42:16.86ID:rbYHJ9y2
ライフタイム注釈も型のジェネリックパラメータの一つと考えればよいかと
参照のライフタイムは現行関数を抜けたら即死ぬ参照からもっと祖先の関数まで持ちこたえる参照そして永久不滅の参照まで色々あるけどジェネリックにいずれも入り得る
2025/10/23(木) 11:33:06.85ID:RL60E7N6
>>402
なるほどじゃねーよ
簡単に騙されんな
2025/10/23(木) 12:08:09.39ID:uSK82vvB
>>401
設計者も手間だと思ってるから引数一つの場合の省略ルールがあるのに何言ってるの
引数が複数のときにライフタイムの明示が必須なのは、シグネチャだけの推論では多くの場合において過剰に強い制約を生じるから
仮にシグネチャだけで安全に推論するなら、戻り値のライフタイムは最もライフタイムの短い引数に合わせるしかないだろ?
そうするとスコープがネストされているような場合に戻り値が短いスコープの方に制約されてしまう
実用上はそれでも問題なく使えるケースは多いはずだが、本来の必要最低限の制約とは食い違うというのが設計者には許せなかったのだろう
2025/10/23(木) 12:30:49.98ID:qu5HXOyL
だからこそライフタイム注釈の明示的な指定が重要
それがあることでコンパイラもコードレビューも正しい判断ができる
2025/10/23(木) 14:21:00.93ID:fxiWIqfp
注釈はプログラマの意図の表明だ。
意図と違う形で辻褄が合っても問題だろ。
よほど自明の場合だけ省略できるようになってるけども、どのレベルから自明と言えるかは感覚的だからな……
2025/10/23(木) 15:22:08.96ID:k6u6s2rE
ライフタイムの指定を省略できる場合であっても、省略すると戻り値のライフタイムの制約が必要以上に強くなってしまうケースは普通にあって、
>>405の理屈を厳格に適用するなら引数が一つでもライフタイムの明示は必須だ
食い違いが生じるケースがどれくらいの頻度で発生するかという統計の問題なのよ
2025/10/23(木) 15:27:37.26ID:hDpBG7ml
二つを'a 'aにすると寿命の短い方に揃えられてしまうけど
二つを'a 'bにすると各々の寿命が尊重されて後に出来ることの範囲が広がるって話?
2025/10/24(金) 10:04:48.68ID:PHL/ybvS
であるか
411デフォルトの名無しさん
垢版 |
2025/10/25(土) 12:18:04.03ID:dx13CXH8
ライフタイムめんどくせえし全部stringで返すべと思ってたら&strとstringの速度差はだいたい10倍あるみたいなのでやっぱできるだけ&strで返そうとおもた🐼
2025/10/25(土) 12:27:15.75ID:dvc0RMgV
そりゃ先頭ポインタと長さを返すだけで済む&str返しやスライス&[T]返しが圧倒的に速いよ
2025/10/25(土) 12:30:11.50ID:5GqPIi/l
>>411
実際のアプリではそこまで差は出ないでしょ
マイクロベンチマークが見せる幻想
2025/10/25(土) 12:36:43.77ID:mHIPVewV
&str返しができる状況でString返しをしてしまうセンスだと至る所で似たような非効率をしてしまいかねない
2025/10/25(土) 14:30:41.07ID:tv80YbgW
そもそもそのへん無頓着ならPythonとかのスクリプトでよくねっていう気も
2025/10/25(土) 15:28:17.84ID:Sq0aKQjf
たまにはCowのことも思い出してあげて🐮
2025/10/25(土) 16:30:57.36ID:dHJk9AZa
>>411
繰り返し呼ばれない関数で文字列がそれほど長く
速度的なメリットよりもライフタイムを引きずり回すデメリットが大きくなる場合は
&str返しできる状況でもstring返しをする

それ以外は&strで返せるなら&strを選ぶのが基本
418デフォルトの名無しさん
垢版 |
2025/10/26(日) 12:11:46.95ID:YIXSQNu/
文字列は用途によってはstring_cacheなど使ってintern化すると一気に扱いやすくなるよ
2025/10/26(日) 15:33:24.64ID:QFgKHJ6W
「用途によっては」「条件によっては」を付けたらだいたい何でも正しいよ。
つまり無意味だってことだ。
2025/10/26(日) 15:48:22.18ID:qLJPEdq/
何にでも向き不向きがあり万能はないため特徴と用途を比較して適切に選ぶ必要がある
文字列の比較があるならinterningは有利
同じ文字列が出てこないなら機能を発揮しない
それでも64bit ID化される点で参照や所有権を気にすることなく気軽に扱える視点での利点はあるかな
2025/10/26(日) 22:42:01.01ID:uL5v2PLc
https://itest.5ch.net/mevius/test/read.cgi/tech/1757733847/52
> Rustが広まってる理由はC並みの高速実行をゼロコスト抽象化によるコードの可読性・保守性・開発効率の高さで実現したことにあるからね
> 安全性などはついでのオマケ

5chのRust信者は程度が低いなw 安全性への認識がこんなものかww
2025/10/26(日) 22:50:15.71ID:/3Ktl5T9
高い抽象度で使いやすい言語は他にもあるけど速さ省メモリを両立させた言語はRustが初だな
それだけでも十分に価値はあるけどセキュリティ面から今重視されている安全性まで両立させたことが決定打
2025/10/26(日) 23:04:51.09ID:v+5C5Bjl
> 安全性などはついでのオマケ
 
安全性に勝るものなどないのに馬鹿丸出しw
424デフォルトの名無しさん
垢版 |
2025/10/26(日) 23:17:12.99ID:X+0qei7I
安全性が使用動機でなくても
他のメリットも他言語に例がなく十分満足できる言語とは言える
2025/10/26(日) 23:20:44.90ID:B58XHKxc
Rustは実際はc++の代用として使われる事例がほとんど
ユーザーは欧米に偏っていて一番IT人材が多いインドではほぼ使われていない
2025/10/27(月) 00:24:06.81ID:mFVRCEv/
>>425
インドでもRust利用企業が多い

Companies that use Rust in India
https://theirstack.com/en/technology/rust/in
2025/10/27(月) 02:06:07.73ID:LFGbdGCc
下馬評垂れてればプログラマーとしての格が上がるとでも思ってるんだろうか
2025/10/27(月) 06:13:04.93ID:AST59Cdb
>>425
各スクリプト言語からRustが多いよ
例えば遅くて困っていたツールなどで新たに良いものに作り直す時にRustが選ばれてる
先週このスレで話題になってたPythonのツールの話もそれだね
429デフォルトの名無しさん
垢版 |
2025/10/27(月) 06:31:46.50ID:bSWiCsX6
rustにも機械学習ライブラリあるしaiもrustでよくね
2025/10/27(月) 09:29:34.52ID:/CEP+D0A
>>429
そういう実際の経験に基づく説得力のあるコメントは参考になる
やっぱ人工知能を実装するならRust一択という結論に至った
2位の候補はC++だけど僅差でRustが使い勝手上かなあ
2025/10/27(月) 09:32:19.04ID:/CEP+D0A
>>428
遅くて困っていたツールってほど遅いのは普通に設計ミスじゃ無いの
たとえばspawnせずにシングルスレッドで回してる箇所見落としてるとか
言語による性能差意識できるほどRustがいいとは思えん
わざわざ他の言語で書くより、元のプログラミング言語でリファクタリングの方が楽だと思うけど
2025/10/27(月) 09:34:42.42ID:/CEP+D0A
>>426
英語はよくわからんけど、408社ってインドの有名企業のほぼ全て採用ってことか
メジャー企業はインフォシステムとかタタとかしか知らんがそこまで普及したのはここ数年よね
なんか日本より導入進んでね?
2025/10/27(月) 09:36:22.75ID:/CEP+D0A
>>425
欧米とインドだと案件の内容が全く違うんだよなあ
たとえばフロントエンドをインドに外注とかならRust使わんし
あえてバックエンドをインドで開発??あんま無いよなあ。バックエンド系の新サービスは欧米強いもんなあ

日本も同じこと言えるけど;;;
2025/10/27(月) 09:47:02.67ID:MUgrXvxY
>>431
実際にJavaScript・Python・Rubyなどスクリプト言語の補助ツールはRust製が多いよ
言語による性能差はあるのでしょう
435デフォルトの名無しさん
垢版 |
2025/10/27(月) 13:52:59.21ID:HMompUGJ
TypeScriptのコンパイラは色々あった末結局goで書き直されたな
rustになるかと思ってた
2025/10/27(月) 15:03:44.84ID:qhXNWfqN
>>431
設計をやり直す機会に書きやすい言語Rustに変更する場合が多いためRust製が増えた

>>435
それは事情と結果が解説されているが、元のコードと可能な限り1対1に対応する『移植』をしたかった
クラスベースの言語や非GC言語はその点で元コードと対応がとりにくくて脱落し、たまたまGoだけ上手くいった
2025/10/27(月) 15:22:52.00ID:8ULsq5Jc
Rust で書いて速くなるものは C でも C++ でも速くなると思う。
適切に再設計できれば。

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

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

Go も良い言語だと思うけど抽象度は高くない。
C の駄目 (というか面倒くさい) なところである文法の不必要な複雑さやメモリ管理を楽にしたという側面が強くて、
大規模なプログラムを整理するのはちょっとしんどい。
出来るという人もいるんだけどそういう人はたぶん C でも出来てしまうタイプの剛腕だから参考にならない。
2025/10/27(月) 15:53:13.91ID:qhXNWfqN
そうだよな
TypeScriptの件がたまたまGoだけJSと1対1の対応を取れたのも、Goが抽象度高くない言語だったため
439デフォルトの名無しさん
垢版 |
2025/10/27(月) 17:49:39.72ID:HMompUGJ
Rustが欲しいというよりCargoが欲しいんだよ
って思ってたらCabinとかいうの見つけて笑った
2025/10/27(月) 18:45:30.45ID:l4eceh5X
でもなんでRustは欧米中心で使われててその他で低いんだ?
コミュニテイーの所属者もそんな分布でアジアは低い
1位アメリカ
2位ドイツって
日本は11位
2025/10/27(月) 19:32:35.62ID:UgAh1tV0
Goも似たような感じだね
単にsurveyのアナウンスが拡散されるプラットフォームの人口分布に引っ張られているだけな気もする
RedditとかHackerNewsとか
2025/10/27(月) 19:41:30.85ID:FbhZH/Sk
>>438
違うよ
Rustでも抽象度の低いコードは書けるけど、メモリ管理と所有権システムが邪魔で一対一対応が無理
2025/10/27(月) 19:42:44.69ID:edSRXQey
リファレンスが英語だからな
ガイドは翻訳されてるけどライブラリ周りはどうしようもない
444デフォルトの名無しさん
垢版 |
2025/10/27(月) 20:06:35.18ID:oTj8oDFF
でも中国5位じゃん
2025/10/27(月) 20:56:19.83ID:qhXNWfqN
>>442
その説明は既に>>436で書いた
所有権システムとメモリ管理を並列に「と」で並べるのはおかしい
446デフォルトの名無しさん
垢版 |
2025/10/27(月) 21:04:31.26ID:syMP9q/B
Rustのコレクションは移動なしでは書けまい
2025/10/27(月) 23:32:35.09ID:OMtkXyUi
>>446
意味不明だな
移動は最も基本的な不可欠な概念
移動の概念がなければコレクションどころか何も動かない
448デフォルトの名無しさん
垢版 |
2025/10/28(火) 03:31:36.61ID:jbGu9KYL
Rustのコレクションは基本的でかつ非自明的にすごい
それはシャローコピーでもディープコピーでもないものが書かせた
2025/10/28(火) 17:50:32.18ID:rJCEklN9
>>447
バカなの?
2025/10/28(火) 18:01:51.21ID:KGeQ1yOx
>>446
コピーはダメだけど
コピーよりコストが安くなり得る移動は問題ないでしょ
451デフォルトの名無しさん
垢版 |
2025/10/28(火) 19:07:26.87ID:Zt6hv4It
goてunixの作者が作っとうけえあんなに使われてるんかな
ポイント使えるのにgcがあるとゆうようわからん仕様
2025/10/28(火) 23:49:42.09ID:tW1WhAkg
>>451
Goのポインタは構文はC風だが、できることはJava等のGC言語のオブジェクト参照とほぼ同じ
そして、GC言語のオブジェクト参照はポインタとして実装されており、ポインタとGCの組み合わせは全く矛盾しない
2025/10/29(水) 01:38:08.80ID:KUd6rxlw
C#だってGCあるけどポインタ使えるじゃん
454デフォルトの名無しさん
垢版 |
2025/10/29(水) 12:14:41.38ID:vbO9JSKW
DBを使用するスマホアプリのバックエンド開発でRustを使用してるけど、sqliteがシングルスレッドでしか使えないから
逆に複雑な設計を求められるな。慣れるまできつい
2025/10/29(水) 15:34:17.17ID:L881d/fh
Rustエンジニアをクビにして代わりにペチパー雇って、浮いた金でMySQLに変えた方が遥かに速くなりそうだな
2025/10/29(水) 17:35:51.56ID:DwSXyKDH
RustはSingletonの初期化と共有がすっきりしないな
初期化忘れのunsafeが付き纏うからどこかで割り切らないといけない
457デフォルトの名無しさん
垢版 |
2025/10/29(水) 19:33:33.85ID:OVpZFjzC
once_cellでええやん
2025/10/29(水) 21:05:45.94ID:DwSXyKDH
OnceCellのget_or_initだと初期化処理が動くタイミングが読めない

気持ち悪いからmainの最初で初期化する

共有する時に毎回初期化済みかチェックするの無駄では

unsafe「呼んだ?」
2025/10/29(水) 23:50:28.94ID:xf92jPdM
そんなコード書くやつはクビ
2025/10/30(木) 00:25:31.66ID:9N/j/0Me
別にチェックしたらいいやん
逆にそんな初期化タイミング気にする理由教えてよ
「最初にたまたま使うタイミングで」初期化で自然なのにあえてメイン関数で初期化する理由
2025/10/30(木) 00:26:18.06ID:9N/j/0Me
>>454
sqlite 嫌いや
2025/10/30(木) 00:40:46.28ID:srGle5DG
初期化で重い処理があると変のタイミングで遅延が発生するのが気になる
最初にxxx_init(gl_initとか)で初期化するライブラリに馴染んでるのもあるけど
2025/10/30(木) 01:29:19.31ID:bVySussB
つかOnceCellじゃなくてLazyCell使えば?
初期化タイミング固定したいなら一発getしとけばよし
2025/10/30(木) 03:16:33.13ID:X8TSXlMe
>>454
>sqliteがシングルスレッドでしか使えないから
sqliteはマルチスレッドでも使えるぞ?
レスを投稿する

5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。

ニューススポーツなんでも実況