Rust part23

**デフォルトの名無しさん** · 2024/02/23(金) 17:37:52.13

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

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

**デフォルトの名無しさん** · 2024/03/29(金) 00:19:58.75

>>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない

**デフォルトの名無しさん** · 2024/03/29(金) 00:24:32.79

>>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全

**デフォルトの名無しさん** · 2024/03/29(金) 01:57:50.63

壊れたレコードオジ怖い

**デフォルトの名無しさん** · 2024/03/29(金) 02:36:16.29

>>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？

**デフォルトの名無しさん** · 2024/03/29(金) 07:36:27.65

雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな

**デフォルトの名無しさん** · 2024/03/29(金) 08:25:13.35

>>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。

デフォルトunsafe禁止は何回か話題に出てきているのな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:27:22.40

>>426
それぐらいやらないとRust採用するメリット無さそうだよな。

**デフォルトの名無しさん** · 2024/03/29(金) 08:41:03.04

初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？

**デフォルトの名無しさん** · 2024/03/29(金) 09:16:34.82

そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい

**デフォルトの名無しさん** · 2024/03/29(金) 09:24:57.68

>>436
じゃunsafe使うな、で済む話じゃん。

**デフォルトの名無しさん** · 2024/03/29(金) 09:49:54.05

>>440
そうだね
で？

**デフォルトの名無しさん** · 2024/03/29(金) 11:01:08.74

rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ

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

unsafeでサッと書いたほうが出世できるぞ

**デフォルトの名無しさん** · 2024/03/29(金) 11:49:42.05

たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな

**デフォルトの名無しさん** · 2024/03/29(金) 11:53:12.39

unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない

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

>>442
メジャーになれなくて何か問題あるの？

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

初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。

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

>>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。

**デフォルトの名無しさん** · 2024/03/29(金) 12:13:58.45

>>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。

**デフォルトの名無しさん** · 2024/03/29(金) 12:15:29.32

>>448
言語機能的にunsafeって書かなければそもそも使えないじゃん。

**デフォルトの名無しさん** · 2024/03/29(金) 13:21:21.11

>>446
時間の無駄

**デフォルトの名無しさん** · 2024/03/29(金) 13:35:34.69

>>448
そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね

**デフォルトの名無しさん** · 2024/03/29(金) 16:25:54.97

unsafeでサクッと終わらせてどんどん仕事取ろうぜ
safeでチンタラやってる無能に仕事を回すな

**デフォルトの名無しさん** · 2024/03/29(金) 17:20:13.23

アンチはunsafeを使うと早く書けると誤解しているのが面白い
早くもなければ楽でもないので普通は使わない

**デフォルトの名無しさん** · 2024/03/29(金) 17:36:40.68

「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね

**デフォルトの名無しさん** · 2024/03/29(金) 17:56:14.07

このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが

**デフォルトの名無しさん** · 2024/03/29(金) 18:02:08.48

正常なコミュニケーション力を持った優秀なエンジニア
→こいつらは出世するのでプログラミングスキルは生かされない方向に進む

正常なコミュニケーション力がない優秀なエンジニア
→こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない

どうしたら優秀なエンジニア揃えられるんや…

**デフォルトの名無しさん** · 2024/03/29(金) 18:06:18.85

ｶﾁｮｰ「では進捗を報告してください」
unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」
ｶﾁｮｰ「???」

**デフォルトの名無しさん** · 2024/03/29(金) 18:22:45.54

>>457
放っておいても勝手に集まるから心配しなくていいよ
そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど

**デフォルトの名無しさん** · 2024/03/29(金) 18:29:23.69

>>459
すまん、集まってるとこの実名あげてくれんか？

**デフォルトの名無しさん** · 2024/03/29(金) 19:20:01.67

>>458
いきなり人格攻撃かよ？Rustらしいな

**デフォルトの名無しさん** · 2024/03/29(金) 19:31:34.50

NとかFとかは優秀な人がいるイメージがない

**デフォルトの名無しさん** · 2024/03/29(金) 19:54:25.38

unsafe使う機会ってほぼないよな
よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか

**デフォルトの名無しさん** · 2024/03/29(金) 19:58:01.23

優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人
でunsafeを使いこなせるかどうかなんか無関係

これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人

**デフォルトの名無しさん** · 2024/03/29(金) 19:59:06.31

システムプログラミング用途も売りにしてなかった？
Cと同等のことをしてみせようってんなら
unsafeくらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ

**デフォルトの名無しさん** · 2024/03/29(金) 20:37:55.25

unsafe使うと変更する時にだるくなるからできるだけ使わない
グローバル変数使うのと同じ気分

「グローバル変数くらい当たり前に常用するやろ？しらんけど
　ボクは使いません！みたいな意見は誰も求めてないからｗ」
とか言われたら知らん

**デフォルトの名無しさん** · 2024/03/29(金) 20:41:59.79

誰にも影響及ぼさないなら勝手に使えばいい

**デフォルトの名無しさん** · 2024/03/29(金) 20:47:48.55

使う必要があるからunsafeってもんがあるんであって
使う必要がない人の意見や感想は求められてないんよ

使うべきとか使うべきじゃないとか
普通はどうとか普通はどうじゃないとか
無意味な応酬はやめよう

**デフォルトの名無しさん** · 2024/03/29(金) 21:08:57.87

コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。

**デフォルトの名無しさん** · 2024/03/29(金) 21:45:08.79

>>451
君の時間の無駄ってこと？
こんなところで毎日無駄な時間過ごしてるのに？
それって君がやらなければいいだけだよね

**デフォルトの名無しさん** · 2024/03/29(金) 21:46:36.17

>>468
一連のunsafeコントで初めてまともな意見だな

**デフォルトの名無しさん** · 2024/03/29(金) 21:52:31.85

エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで
Rustが普及する日は来るんだろうか
上の方でも言われてたけどコーダー集まらない問題に直面しそうだが

**デフォルトの名無しさん** · 2024/03/29(金) 22:06:45.92

Rustはコーダーは集まらんだろ

普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる
ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる

大手だとこれの繰り返しだがRustはそれが難しい

**デフォルトの名無しさん** · 2024/03/29(金) 22:29:09.47

意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと
増えるわけがない
javaやpythonじゃないんだから

野良Rustコーダーなんて存在しない
使える人間は100%C++使いなので引っ張ってこれない

**デフォルトの名無しさん** · 2024/03/29(金) 22:30:50.06

エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな

**デフォルトの名無しさん** · 2024/03/29(金) 22:35:31.54

まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう

**デフォルトの名無しさん** · 2024/03/29(金) 22:48:02.40

それよりもホントにシステムプログラミングできてんのかが興味あるわ
CからはOSならばUnixやLinuxやWindowsが生まれてきたけど
Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？
Cより書きやすくて？　安全なんだよね？　期待していいんよね？

Systems programming
https://en.wikipedia.org/wiki/Systems_programming
e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications

**デフォルトの名無しさん** · 2024/03/29(金) 23:01:23.64

今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある
でも期待するのは自由だ
Rustファンはみんな期待している

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

>>477
interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。

ビジネスになるかはともかく、技術的には余裕なはず。

**デフォルトの名無しさん** · 2024/03/29(金) 23:55:56.73

既にネットインフラは次々とRust製
ソースは>>51

**デフォルトの名無しさん** · 2024/03/30(土) 00:06:31.16

>>472
Rustは仕様や周辺ツールが飛びぬけて優秀な故
JavaやPHP等他の言語と違って素人でも適当に書いても
大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると
大規模開発現場で普及する事はこれからも無いよ。

**デフォルトの名無しさん** · 2024/03/30(土) 01:01:10.58

それで守られるのはITコン猿の立ち位置じゃね？
エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが

**デフォルトの名無しさん** · 2024/03/30(土) 01:46:17.09

知ってる人間は黙ってRustの恩恵を受けておけば良くて
人売りサル業界は人/月だコミュニケーションスキルだと
喚いていれば良い。

**デフォルトの名無しさん** · 2024/03/30(土) 07:28:24.91

C++が流行った経緯知ってる奴なら想像できるだろ。
C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。
でも流行ったのはC++。

**デフォルトの名無しさん** · 2024/03/30(土) 13:15:43.05

C++はわかりやすく拡張されたCだからさ
ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった

NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない
日本語の書籍がないのが一番つらかった

**デフォルトの名無しさん** · 2024/03/30(土) 20:58:56.17

当時NeXTに触れてたやつおるん？
たまげたなぁ
俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ
いつごろだったかなぁ日本語のやつあったけどなぁ
まさかmacOSで脚光浴びるとは思いもせずに

**デフォルトの名無しさん** · 2024/03/30(土) 21:08:50.38

研究室にあったんよ
当時でももう型オチででも予算無いからリプレースも出来ず
MOのデータを消しながら使ってた

古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで

自分は図書館に埋もれたModulaの本を読んでた

**デフォルトの名無しさん** · 2024/03/30(土) 21:14:51.55

羨ましい
俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ
あー羨ましい

**デフォルトの名無しさん** · 2024/03/30(土) 22:32:19.21

モーモーちゃんに入れている人は居たな

**デフォルトの名無しさん** · 2024/03/31(日) 11:42:27.74

C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。
結局は C のままでいくと判断した。
良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。
言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。
C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。

Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、
今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。
そもそも ABI が C を基準にした仕様だったりするので
他の言語と接続するときは皆が C に合わせる形になる。

もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。

**デフォルトの名無しさん** · 2024/03/31(日) 15:29:48.98

ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う

**デフォルトの名無しさん** · 2024/03/31(日) 16:44:42.12

>>490
Rustで書いたOSが大流行でもしない限りCと同じようにはならない。
ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。
そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。
もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。

**デフォルトの名無しさん** · 2024/03/31(日) 19:15:56.54

ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない
多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する

**デフォルトの名無しさん** · 2024/03/31(日) 19:55:09.30

ABIこそ良い奴が出たら置き換えられそうだけどな
現状良い奴がないだけで

**デフォルトの名無しさん** · 2024/03/31(日) 21:03:45.67

>>493
何言ってんのwww
相変わらず無知が過ぎる

**デフォルトの名無しさん** · 2024/03/31(日) 22:06:47.20

いやまあ1%もいないんじゃない？

**デフォルトの名無しさん** · 2024/03/31(日) 23:37:37.59

そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど

**デフォルトの名無しさん** · 2024/04/01(月) 19:53:32.69

そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。

**デフォルトの名無しさん** · 2024/04/01(月) 20:06:07.63

C++より多いから問題ない

**デフォルトの名無しさん** · 2024/04/01(月) 22:56:49.63

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

**デフォルトの名無しさん** · 2024/04/02(火) 08:53:54.00

>>500
メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。

c++標準も、Safe Rust に倣って
c++ subset for safe programming
とか作ればいいのに。

**デフォルトの名無しさん** · 2024/04/02(火) 09:19:58.94

メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。

**デフォルトの名無しさん** · 2024/04/02(火) 09:39:48.87

java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。

**デフォルトの名無しさん** · 2024/04/02(火) 11:06:55.03

>>503
安全じゃ無いぞ

**デフォルトの名無しさん** · 2024/04/02(火) 14:49:37.59

>>501
C/C++はプログラム全体がunsafe空間なので難しい
safeにしようとすると全く別言語になってしまう
結局C/C++を捨てるのが正しい

**デフォルトの名無しさん** · 2024/04/02(火) 17:14:03.69

>>503
nullポイントがある時点で…
一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ

**デフォルトの名無しさん** · 2024/04/02(火) 17:14:28.23

nullポインタだ
ごめんなさい

**デフォルトの名無しさん** · 2024/04/02(火) 18:23:13.98

ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される
nullから何かを読み出して動き続けると危険

**デフォルトの名無しさん** · 2024/04/02(火) 18:43:54.77

>>508
Someである保証がある時のみunwrap()を使う
保証がないのにunwrap()する人はクビ

**デフォルトの名無しさん** · 2024/04/02(火) 18:54:06.54

メモリ安全の文脈だからそういう次元の話ではないのだが

**デフォルトの名無しさん** · 2024/04/02(火) 18:55:57.61

>>505
コーダー向けだから別言語でいいよ。

new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。
operator関数定義も禁止でいいんじゃない？

**デフォルトの名無しさん** · 2024/04/02(火) 19:03:35.75

ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね

**デフォルトの名無しさん** · 2024/04/02(火) 19:19:41.72

rustって楽しい？

**デフォルトの名無しさん** · 2024/04/02(火) 19:20:30.34

どの言語にも共通するけど，書けるようになってくると楽しいよ

**デフォルトの名無しさん** · 2024/04/02(火) 19:40:54.12

でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね

**デフォルトの名無しさん** · 2024/04/02(火) 19:43:54.71

>>512
あ、未定義と定義されているのも全部禁止ね。

**デフォルトの名無しさん** · 2024/04/02(火) 20:13:32.30

>>500
これでRustの知名度も上がるし普及も加速しそう

**デフォルトの名無しさん** · 2024/04/02(火) 20:26:12.86

>>517
結構前にもNASAが同じ様な事言って今やんw

**デフォルトの名無しさん** · 2024/04/02(火) 20:31:06.25

rustを無理に使ってまですることがぬるぽ対策とかアホだよね

**デフォルトの名無しさん** · 2024/04/02(火) 20:45:15.37

>>519
まあ戦争によるサイバー攻撃に備えろってのは分かるんよ
日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね

**デフォルトの名無しさん** · 2024/04/02(火) 21:20:14.32

>>518
NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね
間違いなく日本も追随することになる

**デフォルトの名無しさん** · 2024/04/02(火) 21:56:04.08

Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ
ONCDは健全なのかな

**デフォルトの名無しさん** · 2024/04/02(火) 22:51:50.04

>>518
NASA？NSAじゃなく？
NSAはNASAじゃないぞ。

**デフォルトの名無しさん** · 2024/04/02(火) 23:24:29.45

ワロタ
NSAとNASAの区別もできんとはｗｗ

メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か
2022/11 NSA
2023/09 CISA
2023/12 CISA+NSA,+FBI+Five Eyesの各機関
2024/02 White House(ONCD)

**デフォルトの名無しさん** · 2024/04/02(火) 23:39:08.04

とりあえず良いcrateが増えまくってほしいな

**デフォルトの名無しさん** · 2024/04/02(火) 23:51:33.79

>>524
あとは日本がどれだけ遅れるかだな
数ヶ月か、1年か、数年か、

**デフォルトの名無しさん** · 2024/04/02(火) 23:57:17.27

外部のお墨付きを欲しがる時点でオワっとるんよ
言語として
ここでそういう話題使って必死で盛り上げようとして
消えそうな火に風送ってるつもりかしらんけど

**デフォルトの名無しさん** · 2024/04/03(水) 00:07:33.86

IT大手ライバル同士が
GAFAMからHUAWEIまで一致団結して
Rust Foundationを設立した時点で未来は確定していた
そしてRustに対抗できるライバル言語の芽が今も存在しない

**デフォルトの名無しさん** · 2024/04/03(水) 05:31:15.82

>>527
話題にも上がらないよりまし

**デフォルトの名無しさん** · 2024/04/03(水) 07:36:47.52

Rustの代替になる思想の言語が全くそれ以降全く見ないからな。
今のところGCレスでメモリ安全に向き合った唯一の言語でねえの？

後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。

**デフォルトの名無しさん** · 2024/04/03(水) 08:17:45.92

>>527
欲しがってるかね？
むしろ外部が乗っかろうとしてる感じ。