Rust part23 - 暇つぶし2ch

Rust part23 ..

354:デフォルトの名無しさん
24/03/21 20:09:58.67 gM/gTjZ5.net
>>353
それ言うなら
無闇に「ヤバい」を使うぐらいヤバい
じゃね

355:デフォルトの名無しさん
24/03/21 20:26:53.11 1l7zk65j.net
俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな
ガンガンunsafe使ってこーぜ！！

356:デフォルトの名無しさん
24/03/21 20:28:39.30 7RDAu5V5.net
>>354
それだと単なる自己言及だから352に対する答えとして不十分では

357:デフォルトの名無しさん
24/03/21 20:45:04.06 t5wrhqh7.net
少なくとも >>350のindex: usizeは
何らかラッピング { index: usize }と別型にすべきところ
まず範囲外のusizeでうっかり使っても型エラーにできる
そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる

358:デフォルトの名無しさん
24/03/21 21:05:14.02 7RDAu5V5.net
NonZeroとかNonNullみたいな固定条件ならいいけど
範囲みたいな可変条件だと型だけじゃ厳しいでしょ
別の条件で作られた同じ型の値を使われるかもしれないし
ライフタイムで条件と関連付けるのも限界がある
結局テストパターン増やしてdebug_assert踏むしかない

359:デフォルトの名無しさん
24/03/21 21:44:37.76 t5wrhqh7.net
>>358
もちろん二段階
まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける
次にコーディングやレビューやメンテでその専用型の動きに注視できる

360:デフォルトの名無しさん
24/03/21 22:18:44.86 cOunjWn7.net
unsafeをsafeでないのにsafeにしておいて
ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです

361:デフォルトの名無しさん
24/03/21 22:27:42.27 WuGieKPN.net
結局プログラマが色々意識してコーディングしないと安全にはならないのね
こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど

362:デフォルトの名無しさん
24/03/21 23:07:15.31 7RDAu5V5.net
unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる
実際は安全の為でもpanicで止まると困るから色々注意しないといけないし
unsafeで余計なチェック省いたり黒魔術使ったりもする
Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない

363:デフォルトの名無しさん
24/03/21 23:12:07.53 v/mpoJJ8.net
>>361
unsafeを使わなれば自動的に安全が保証される
unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される
C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない

364:デフォルトの名無しさん
24/03/21 23:22:25.34 WuGieKPN.net
いつもの人がきたｗ
結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ
Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど

365:デフォルトの名無しさん
24/03/21 23:58:23.31 z414Bs3I.net
> Rustであれば安全と思ってる人が多そう

いや一応言っとくけど多くはないよ流石にｗ
一部の人が連呼してるだけ
ほかの人はもっと現実的だろな

366:デフォルトの名無しさん
24/03/21 23:59:21.08 t5wrhqh7.net
原則はunsafeを使うな！
これだけだ

理解できていてunsafeを使う場合も
とにかく閉じ込めろ！
専用のクレートを作れ
専用のモジュールを作れ
専用の型を作れ

367:デフォルトの名無しさん
24/03/21 23:59:51.15 XJ9dJAV6.net
unsafe使わなければ安全

368:デフォルトの名無しさん
24/03/22 09:16:28.77 IQ7X1X+j.net
まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。
それは意識して気をつけた方がいい。

369:デフォルトの名無しさん
24/03/22 10:19:34.77 avPqaarP.net
ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。
チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。
そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ……
普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。

370:デフォルトの名無しさん
24/03/22 11:58:26.79 7Rs7masV.net
>>358
0～127の範囲のみを取りうるようなEnumなら作れる
wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど

サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本
それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない
 >>359のやり方はそれができてないように感じる

371:デフォルトの名無しさん
24/03/22 12:34:01.41 TbCMvv+/.net
実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい
そうすればその型に対して常に安全にget_uncheckedを使える

372:デフォルトの名無しさん
24/03/22 14:04:42.65 ZrfX32kv.net
Rustは失敗言語

373:デフォルトの名無しさん
24/03/22 14:10:55.04 ceR9yHkM.net
今回の件でRustの安全性が確実になったのが興味深いよな
アンチが必死に探してきた問題も>>350でunsafe利用だった

374:デフォルトの名無しさん
24/03/22 16:00:31.63 JqYXTM4B.net
>>371
「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど
実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ
unsafeにする意味がない

375:デフォルトの名無しさん
24/03/22 17:14:19.13 vuLWDWdh.net
>>374
実行時コストをかけないためにget_uncheckedを使うのが一般的
その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法)

376:デフォルトの名無しさん
24/03/22 19:27:28.32 G6tKD1fj.net
Adaなら特定の範囲の型作れるみたいよ

377:デフォルトの名無しさん
24/03/22 20:07:18.97 vuLWDWdh.net
今回は範囲が固定ではなく変わり得る

378:デフォルトの名無しさん
24/03/23 23:29:45.64 eeq00BcS.net
誰にでもunsafeが使えてしまうのが問題なのでは？
原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。

379:デフォルトの名無しさん
24/03/24 00:34:36.37 iaJ2USO3.net
Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。
まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。

380:デフォルトの名無しさん
24/03/24 10:55:06.56 UXqlkypu.net
>>375
「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら >>350の引数のindexをその型に変えたところでsafeにしたらダメだよ

381:デフォルトの名無しさん
24/03/24 11:08:34.82 BHU0SFkf.net
なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？

382:デフォルトの名無しさん
24/03/24 11:48:11.45 uu8/yG2s.net
indexの境界チェックが律速になるようなコード書いてみてえな

383:デフォルトの名無しさん
24/03/24 20:37:14.59 YsO86RjG.net
>>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー　配列もその範囲指定で自由に作成できる。

384:デフォルトの名無しさん
24/03/24 20:45:58.90 Rrl8qRWO.net
>>383
定数じゃなければ結局実行時にチェックするってことだよね

385:デフォルトの名無しさん
24/03/25 01:12:47.74 yMlw6u5B.net
>>384
新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。

386:デフォルトの名無しさん
24/03/25 07:21:41.59 CNajD+3j.net
>>384 何十年も前なのですまそ
array(-2)とかarray(6)をアクセスしたら例外発生　array(-1)はOK

type Month is range 1..12
type Month_Array is array(Month) of Integer;
ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12);

for m in ma'first..ma'last loop // カウンタは1から12
ma(m) = m;
end loop;

387:デフォルトの名無しさん
24/03/25 14:37:28.19 x/lXcXel.net
今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど
そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね

388:デフォルトの名無しさん
24/03/25 16:23:44.40 9GDk/VLW.net
How much does Rust's bounds checking actually cost?
URLﾘﾝｸ(blog.readyset.io)

389:デフォルトの名無しさん
24/03/25 17:27:16.04 MT/jL+52.net
こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。
問題は浮動小数の取り扱いだっての。

390:デフォルトの名無しさん
24/03/25 21:23:48.62 x/lXcXel.net
unsafeは可能な限り避けるべきで
safe Rustでの改善をまずすべき
その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える

現実にはsafe Rustでの改善ができてないことが多い
例えばよく見かける例としては
iが動いていくのにa[i]でアクセスしてしまう
これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern
参照(ポインタ)化することで範囲checkを1回に減らせる

391:デフォルトの名無しさん
24/03/27 15:06:55.14 g9hYSxJr.net
unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね
unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事

392:デフォルトの名無しさん
24/03/27 15:29:03.70 pFQTMi8v.net
「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」
が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので

393:デフォルトの名無しさん
24/03/27 16:02:47.08 BwG0n/Az.net
unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。
unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない？

394:デフォルトの名無しさん
24/03/27 16:59:36.71 LwoOYerE.net
>>393
そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。

395:デフォルトの名無しさん
24/03/27 17:05:39.09 6Vj8sISV.net
>>392
センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ
今はそれが全然できてないから >>350のような基本的なミスを犯すやつが後を絶たない

396:デフォルトの名無しさん
24/03/27 17:08:09.55 6japDZ8y.net
windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。

397:デフォルトの名無しさん
24/03/27 18:09:17.85 345wycOn.net
>>395
～すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。

398:デフォルトの名無しさん
24/03/27 18:27:03.05 3NgGdhlw.net
>>397
問題点の指摘や解決策の提案と
問題解決のために実際に誰が動くのかという
2つの異なるものを混同したらだめだよ
マネジメント101

399:デフォルトの名無しさん
24/03/27 18:54:43.86 nHNmKGrp.net
その素晴らしい提案がなぜされていないのか考えよう
そしてなぜ自分は実行から逃げているのか考えよう

400:デフォルトの名無しさん
24/03/27 20:42:45.86 deTzlgug.net
>>394
Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。

401:デフォルトの名無しさん
24/03/27 21:06:58.89 LwoOYerE.net
unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。
危険な操作も含まれるけど危険な部分を分けれてるわけではない。
もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。

402:デフォルトの名無しさん
24/03/27 21:18:47.87 deTzlgug.net
>>401
安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。
デフォルト禁止でもいいくらい。

403:デフォルトの名無しさん
24/03/27 21:31:01.25 LwoOYerE.net
>>402
だからそうしたいならそうすりゃいいって話をしてる。
あなたが裁量権をもつプロジェクトでは。
私が反論してるのは「そのためのものだ」という部分に対して。

404:デフォルトの名無しさん
24/03/27 21:44:58.62 deTzlgug.net
>>403
Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。
unsafeはデフォルト禁止でいいよ。

405:デフォルトの名無しさん
24/03/27 21:49:49.48 Fy0R0co2.net
理想をいえばunsafeなんて無いならサイコーだったんだろうね
rust陣営もしゃあなしでunsafe導入したんやろうし
unsafeなしですべてがセーフで効率的だったら
そりゃあrustは本当に素晴らしい文句なしの言語だったやろな

406:デフォルトの名無しさん
24/03/27 22:08:33.46 toZsv7uT.net
生ポインタすなわちCPUによるメモリアクセスはunsafe
そこが出発点
unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる
それがsafe Rustの基本原理
つまりunsafeに行き着くためunsafe無しでは何もできない
これが真理
一方で
unsafeを閉じ込めたライブラリ利用可を前提にすれば
unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実

407:デフォルトの名無しさん
24/03/27 22:24:02.18 cgbLYCC5.net
>>406
だったらデフォルトunsafe禁止で良い。
どこでもunsafe okはやっぱりチグハグ。

408:デフォルトの名無しさん
24/03/27 22:52:47.09 qNf/D02g.net
そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？

409:デフォルトの名無しさん
24/03/27 22:57:38.14 LwoOYerE.net
>>404
「そうであって欲しいと自分は思っている」なら別にいいよ。
ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。

410:デフォルトの名無しさん
24/03/27 23:02:28.02 toZsv7uT.net
#![forbid(unsafe_code)]
を宣言すればいい
もちろんすべてはunsafeへ行き着くため
unsafeを禁止できるのは自分のコード部分だけ

411:デフォルトの名無しさん
24/03/27 23:55:45.93 pFQTMi8v.net
unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな
平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する

412:デフォルトの名無しさん
24/03/28 07:44:09.91 OabXy/xk.net
>>409
公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。
>>411
拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい？

413:デフォルトの名無しさん
24/03/28 08:15:17.48 wHq/ItvK.net
rustもいろいろ問題を抱えてるんだね
プログラマの習熟が必要だっていうなら流行らないだろう
メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし
新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう

414:デフォルトの名無しさん
24/03/28 08:34:31.08 5loDhjzb.net
>>412
こう書くだけでunsafeの使用が禁止されます
#![forbid(unsafe_code)]
>>413
普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません

415:デフォルトの名無しさん
24/03/28 08:48:28.49 OabXy/xk.net
>>414
>411みたいなマキャベリガイジが混ざると破綻しますな。
MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。

416:デフォルトの名無しさん
24/03/28 09:00:19.29 5loDhjzb.net
>>415
これでunsafeが使用禁止となり安全なsafe Rustになる
#![forbid(unsafe_code)]
コンパイラがunsafeをエラーとして弾く

417:デフォルトの名無しさん
24/03/28 10:37:24.50 dWo+4s1T.net
結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな

418:デフォルトの名無しさん
24/03/28 14:03:58.90 61/ABBlz.net
まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。

419:デフォルトの名無しさん
24/03/28 17:41:01.08 Li+1uESY.net
unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者
一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる
もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、
その部分だけを切り出してライブラリ作成者になれる
それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない

420:デフォルトの名無しさん
24/03/28 18:27:15.03 OabXy/xk.net
>>419
そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。

Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。

421:デフォルトの名無しさん
24/03/28 18:35:39.73 2Ez7VURh.net
unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが
このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう

でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ

422:デフォルトの名無しさん
24/03/28 18:56:54.80 Hx0Q8eMq.net
必要な各企業、各プロジェクトなどで義務付け
#![forbid(unsafe_code)]
これでunsafeの話はおしまい

他の言語と比べてRustはコーディング規約もAPI規約も公式で楽
Rust公式APIガイドライン
URLﾘﾝｸ(rust-lang.github.io)

423:デフォルトの名無しさん
24/03/28 19:45:10.84 OabXy/xk.net
>>422
公式のドキュメントで
#![forbid(unsafe_code)]
の説明を探しているんだけど、どこにあるのかしらん？
doc.rust-lang.org/nomicon/safe-unsafe-meaning.html
の１行でおしまい？

424:デフォルトの名無しさん
24/03/28 20:08:10.91 uNPCtnZO.net
forbidもunsafe_codeもrustcのlintの一部だな
doc.rust-lang.org/rustc/lints/levels.html#forbid
doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code

425:デフォルトの名無しさん
24/03/28 21:59:19.02 vhhc95Ef.net
Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。

426:デフォルトの名無しさん
24/03/28 22:34:58.42 jTiWvkZ+.net
どの開発でも
#![forbid(unsafe_code)]が原則
どうしてもunsafeが必要なら
その安全ロジックを関係者で協議後に
#![deny(unsafe_code)]へそのモジュールのみ変更し
許可する部分のみを
#![allow(unsafe_code)]として監視対象
といった感じが一般的かと
監視対象を極一部に限定できて
全体はコンパイラにより保証できるため
他のプログラミング言語より扱いやすい

427:デフォルトの名無しさん
24/03/28 22:41:56.41 8+kd1npI.net
>>420
一般とそうでない奴は誰がどうやって区別するのさ？

428:デフォルトの名無しさん
24/03/28 22:42:31.88 8+kd1npI.net
>>421
正解

429:デフォルトの名無しさん
24/03/28 23:58:52.21 KGiLR8kg.net
時間がない時はunsafe使っていいよ

430:デフォルトの名無しさん
24/03/29 00:05:51.94 B//2x2dm.net
時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう

431:デフォルトの名無しさん
24/03/29 00:19:58.75 Rgc3qInF.net
>>429
safeで書くのが早くて楽で安全
わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない

432:デフォルトの名無しさん
24/03/29 00:24:32.79 Rgc3qInF.net
>>430
unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる
safe Rustが楽で早く書けて安全

433:デフォルトの名無しさん
24/03/29 01:57:50.63 EplliVDI.net
壊れたレコードオジ怖い

434:デフォルトの名無しさん
24/03/29 02:36:16.29 B//2x2dm.net
>>432
安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは？

435:デフォルトの名無しさん
24/03/29 07:36:27.65 9Pm5HVgJ.net
雑にunsafe使って早く書けるのはFFIくらいかな
FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い
pure Rustでunsafeの方が早いケースはちょっと思いつかないな

436:デフォルトの名無しさん
24/03/29 08:25:13.35 bd1Zch8f.net
>>427
そりゃプロジェクト管理者だろ。
そもそもRust採用するメリットはソースコードの品質管理しか無いし。
デフォルトunsafe禁止は何回か話題に出てきているのな。

437:デフォルトの名無しさん
24/03/29 08:27:22.40 bd1Zch8f.net
>>426
それぐらいやらないとRust採用するメリット無さそうだよな。

438:デフォルトの名無しさん
24/03/29 08:41:03.04 ev5kqnbp.net
初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？

439:デフォルトの名無しさん
24/03/29 09:16:34.82 cTkAvXQI.net
そもそも普通に書いててunsafe使いたいなって場面がない
多人数で書いてるならforbidで落としてもいいけど
コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい

440:デフォルトの名無しさん
24/03/29 09:24:57.68 vaG7EqUh.net
>>436
じゃunsafe使うな、で済む話じゃん。

441:デフォルトの名無しさん
24/03/29 09:49:54.05 AosFf04R.net
>>440
そうだね
で？

442:デフォルトの名無しさん
24/03/29 11:01:08.74 8PtB/vi4.net
rustもプログラマがザコだと使いこなせない言語なんだろ？
人材確保すら苦労するってメジャーになれるのかよ

443:デフォルトの名無しさん
24/03/29 11:23:44.57 34VMnlB4.net
unsafeでサッと書いたほうが出世できるぞ

444:デフォルトの名無しさん
24/03/29 11:49:42.05 ZM8BmiyA.net
たしかにプログラムの品質がいいから出世するって見たことないわ
逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな

445:デフォルトの名無しさん
24/03/29 11:53:12.39 opHbD1qf.net
unsafeは面倒
Rustで書いていてunsafeを使いたい気分になることがない
さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない

446:デフォルトの名無しさん
24/03/29 11:54:18.08 K6ErCtbZ.net
>>442
メジャーになれなくて何か問題あるの？

447:デフォルトの名無しさん
24/03/29 12:08:03.79 6hM9S6Vd.net
初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。

448:デフォルトの名無しさん
24/03/29 12:08:08.24 GuqFwMZD.net
>>440
PMやったこと無いの？
unsafe使うなと管理するより、そもそも使えない方が遥かに楽。

449:デフォルトの名無しさん
24/03/29 12:13:58.45 E/kaNL72.net
>>442
C++ とかだと使いこなせてないのになんとなく動いちゃったりするから……
使えてないなら使えないほうがちょっとマシなんだよ。

450:デフォルトの名無しさん
24/03/29 12:15:29.32 vaG7EqUh.net
>>448
言語機能的にunsafeって書かなければそもそも使えないじゃん。

451:デフォルトの名無しさん
24/03/29 13:21:21.11 l8m+nc89.net
>>446
時間の無駄

452:デフォルトの名無しさん
24/03/29 13:35:34.69 ZM8BmiyA.net
>>448
そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね

453:デフォルトの名無しさん
24/03/29 16:25:54.97 34VMnlB4.net
unsafeでサクッと終わらせてどんどん仕事取ろうぜ
safeでチンタラやってる無能に仕事を回すな

454:デフォルトの名無しさん
24/03/29 17:20:13.23 Cl3C8AEw.net
アンチはunsafeを使うと早く書けると誤解しているのが面白い
早くもなければ楽でもないので普通は使わない

455:デフォルトの名無しさん
24/03/29 17:36:40.68 cTkAvXQI.net
「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね

456:デフォルトの名無しさん
24/03/29 17:56:14.07 uhU4IUEm.net
このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが

457:デフォルトの名無しさん
24/03/29 18:02:08.48 uhU4IUEm.net
正常なコミュニケーション力を持った優秀なエンジニア
→こいつらは出世するのでプログラミングスキルは生かされない方向に進む
正常なコミュニケーション力がない優秀なエンジニア
→こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない
どうしたら優秀なエンジニア揃えられるんや…

458:デフォルトの名無しさん
24/03/29 18:06:18.85 fG0MAqjd.net
ｶﾁｮｰ「では進捗を報告してください」
unsafe_man「ｱﾉｰ、ﾁｮｯﾄ時間かかってｵﾘﾏｼﾃ、ｱﾝｾｰﾌが、ｿﾉｰ（怒涛の勢いで難しいことを話し続ける）」
ｶﾁｮｰ「???」

459:デフォルトの名無しさん
24/03/29 18:22:45.54 TAofIzHh.net
>>457
放っておいても勝手に集まるから心配しなくていいよ
そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど

460:デフォルトの名無しさん
24/03/29 18:29:23.69 /REVrZ9A.net
>>459
すまん、集まってるとこの実名あげてくれんか？

461:デフォルトの名無しさん
24/03/29 19:20:01.67 GuqFwMZD.net
>>458
いきなり人格攻撃かよ？Rustらしいな

462:デフォルトの名無しさん
24/03/29 19:31:34.50 wqpOcL9O.net
NとかFとかは優秀な人がいるイメージがない

463:デフォルトの名無しさん
24/03/29 19:54:25.38 M7FjmHlu.net
unsafe使う機会ってほぼないよな
よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか

464:デフォルトの名無しさん
24/03/29 19:58:01.23 wqpOcL9O.net
優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人
でunsafeを使いこなせるかどうかなんか無関係
これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人

465:デフォルトの名無しさん
24/03/29 19:59:06.31 0Uoml8t7.net
システムプログラミング用途も売りにしてなかった？
Cと同等のことをしてみせようってんなら
unsafeくらい当たり前に常用するやろ？しらんけど
ボクは使いません！みたいな意見は誰も求めてないからｗ

466:デフォルトの名無しさん
24/03/29 20:37:55.25 TAofIzHh.net
unsafe使うと変更する時にだるくなるからできるだけ使わない
グローバル変数使うのと同じ気分
「グローバル変数くらい当たり前に常用するやろ？しらんけど
　ボクは使いません！みたいな意見は誰も求めてないからｗ」
とか言われたら知らん

467:デフォルトの名無しさん
24/03/29 20:41:59.79 wqpOcL9O.net
誰にも影響及ぼさないなら勝手に使えばいい

468:デフォルトの名無しさん
24/03/29 20:47:48.55 0Uoml8t7.net
使う必要があるからunsafeってもんがあるんであって
使う必要がない人の意見や感想は求められてないんよ
使うべきとか使うべきじゃないとか
普通はどうとか普通はどうじゃないとか
無意味な応酬はやめよう

469:デフォルトの名無しさん
24/03/29 21:08:57.87 bd1Zch8f.net
コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。

470:デフォルトの名無しさん
24/03/29 21:45:08.79 DW6NdCQ6.net
>>451
君の時間の無駄ってこと？
こんなところで毎日無駄な時間過ごしてるのに？
それって君がやらなければいいだけだよね

471:デフォルトの名無しさん
24/03/29 21:46:36.17 wXELlTG7.net
>>468
一連のunsafeコントで初めてまともな意見だな

472:デフォルトの名無しさん
24/03/29 21:52:31.85 TAofIzHh.net
エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで
Rustが普及する日は来るんだろうか
上の方でも言われてたけどコーダー集まらない問題に直面しそうだが

473:デフォルトの名無しさん
24/03/29 22:06:45.92 wqpOcL9O.net
Rustはコーダーは集まらんだろ
普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる
ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる
大手だとこれの繰り返しだがRustはそれが難しい

474:デフォルトの名無しさん
24/03/29 22:29:09.47 wqpOcL9O.net
意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと
増えるわけがない
javaやpythonじゃないんだから
野良Rustコーダーなんて存在しない
使える人間は100%C++使いなので引っ張ってこれない

475:デフォルトの名無しさん
24/03/29 22:30:50.06 UmT7/PmU.net
エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな

476:デフォルトの名無しさん
24/03/29 22:35:31.54 B//2x2dm.net
まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう

477:デフォルトの名無しさん
24/03/29 22:48:02.40 0Uoml8t7.net
それよりもホントにシステムプログラミングできてんのかが興味あるわ
CからはOSならばUnixやLinuxやWindowsが生まれてきたけど
Rustからは一体どんな素晴らしいものが生まれてくるんだろうか？
Cより書きやすくて？　安全なんだよね？　期待していいんよね？
Systems programming
URLﾘﾝｸ(en.wikipedia.org)
e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications

478:デフォルトの名無しさん
24/03/29 23:01:23.64 B//2x2dm.net
今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある
でも期待するのは自由だ
Rustファンはみんな期待している

479:デフォルトの名無しさん
24/03/29 23:11:14.94 JKQcuRe5.net
>>477
interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境（Cとアセンブラの独壇場。C++不可の世界）で組み込みRust使う記事とかあったよ。
ビジネスになるかはともかく、技術的には余裕なはず。

480:デフォルトの名無しさん
24/03/29 23:55:56.73 VDRjyKLu.net
既にネットインフラは次々とRust製
ソースは >>51

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

482:デフォルトの名無しさん
24/03/30 01:01:10.58 7ofxl8DK.net
それで守られるのはITコン猿の立ち位置じゃね？
エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが

483:デフォルトの名無しさん
24/03/30 01:46:17.09 v9pXWAWc.net
知ってる人間は黙ってRustの恩恵を受けておけば良くて
人売りサル業界は人/月だコミュニケーションスキルだと
喚いていれば良い。

484:デフォルトの名無しさん
24/03/30 07:28:24.91 6WvjgMqi.net
C++が流行った経緯知ってる奴なら想像できるだろ。
C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。
でも流行ったのはC++。

485:デフォルトの名無しさん
24/03/30 13:15:43.05 Kpt9p6/a.net
C++はわかりやすく拡張されたCだからさ
ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった
NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない
日本語の書籍がないのが一番つらかった

486:デフォルトの名無しさん
24/03/30 20:58:56.17 IReUP+am.net
当時NeXTに触れてたやつおるん？
たまげたなぁ
俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ
いつごろだったかなぁ日本語のやつあったけどなぁ
まさかmacOSで脚光浴びるとは思いもせずに

487:デフォルトの名無しさん
24/03/30 21:08:50.38 Kpt9p6/a.net
研究室にあったんよ
当時でももう型オチででも予算無いからリプレースも出来ず
MOのデータを消しながら使ってた
古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで
自分は図書館に埋もれたModulaの本を読んでた

488:デフォルトの名無しさん
24/03/30 21:14:51.55 IReUP+am.net
羨ましい
俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ
あー羨ましい

489:デフォルトの名無しさん
24/03/30 22:32:19.21 VLAlfJh3.net
モーモーちゃんに入れている人は居たな

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

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

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

491:デフォルトの名無しさん
24/03/31 15:29:48.98 dXzgmT0X.net
ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う

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

493:デフォルトの名無しさん
24/03/31 19:15:56.54 r1rO2LMH.net
ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない
多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する

494:デフォルトの名無しさん
24/03/31 19:55:09.30 T95JlUSJ.net
ABIこそ良い奴が出たら置き換えられそうだけどな
現状良い奴がないだけで

495:デフォルトの名無しさん
24/03/31 21:03:45.67 rhKYEfc8.net
>>493
何言ってんのwww
相変わらず無知が過ぎる

496:デフォルトの名無しさん
24/03/31 22:06:47.20 HimKkZni.net
いやまあ1%もいないんじゃない？

497:デフォルトの名無しさん
24/03/31 23:37:37.59 PUonJ710.net
そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど

498:デフォルトの名無しさん
24/04/01 19:53:32.69 QJf4H8j7.net
そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。

499:デフォルトの名無しさん
24/04/01 20:06:07.63 lQvViLVK.net
C++より多いから問題ない

500:デフォルトの名無しさん
24/04/01 22:56:49.63 wqqAiPYQ.net
「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
URLﾘﾝｸ(atmarkit.itmedia.co.jp)

501:デフォルトの名無しさん
24/04/02 08:53:54.00 i0O60K8Z.net
>>500
メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。
c++標準も、Safe Rust に倣って
c++ subset for safe programming
とか作ればいいのに。

502:デフォルトの名無しさん
24/04/02 09:19:58.94 D6QICSr8.net
メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。

503:デフォルトの名無しさん
24/04/02 09:39:48.87 EeET/S7r.net
java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。

504:デフォルトの名無しさん
24/04/02 11:06:55.03 lti1kN7b.net
>>503
安全じゃ無いぞ

505:デフォルトの名無しさん
24/04/02 14:49:37.59 b3hi6lw5.net
>>501
C/C++はプログラム全体がunsafe空間なので難しい
safeにしようとすると全く別言語になってしまう
結局C/C++を捨てるのが正しい

506:デフォルトの名無しさん
24/04/02 17:14:03.69 kERS+9TD.net
>>503
nullポイントがある時点で…
一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど，だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ

507:デフォルトの名無しさん
24/04/02 17:14:28.23 kERS+9TD.net
nullポインタだ
ごめんなさい

508:デフォルトの名無しさん
24/04/02 18:23:13.98 mnREx4SD.net
ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される
nullから何かを読み出して動き続けると危険

509:デフォルトの名無しさん
24/04/02 18:43:54.77 0YGJ2wff.net
>>508
Someである保証がある時のみunwrap()を使う
保証がないのにunwrap()する人はクビ

510:デフォルトの名無しさん
24/04/02 18:54:06.54 mnREx4SD.net
メモリ安全の文脈だからそういう次元の話ではないのだが

511:デフォルトの名無しさん
24/04/02 18:55:57.61 i0O60K8Z.net
>>505
コーダー向けだから別言語でいいよ。
new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。
operator関数定義も禁止でいいんじゃない？

512:デフォルトの名無しさん
24/04/02 19:03:35.75 mnREx4SD.net
ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね

513:デフォルトの名無しさん
24/04/02 19:19:41.72 qL7KDCYj.net
rustって楽しい？

514:デフォルトの名無しさん
24/04/02 19:20:30.34 kERS+9TD.net
どの言語にも共通するけど，書けるようになってくると楽しいよ

515:デフォルトの名無しさん
24/04/02 19:40:54.12 lti1kN7b.net
でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね

516:デフォルトの名無しさん
24/04/02 19:43:54.71 ptOw8ylO.net
>>512
あ、未定義と定義されているのも全部禁止ね。

517:デフォルトの名無しさん
24/04/02 20:13:32.30 +hiVU8fL.net
>>500
これでRustの知名度も上がるし普及も加速しそう

518:デフォルトの名無しさん
24/04/02 20:26:12.86 lti1kN7b.net
>>517
結構前にもNASAが同じ様な事言って今やんw

519:デフォルトの名無しさん
24/04/02 20:31:06.25 EeET/S7r.net
rustを無理に使ってまですることがぬるぽ対策とかアホだよね

520:デフォルトの名無しさん
24/04/02 20:45:15.37 lti1kN7b.net
>>519
まあ戦争によるサイバー攻撃に備えろってのは分かるんよ
日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね

521:デフォルトの名無しさん
24/04/02 21:20:14.32 +5bQ5ala.net
>>518
NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね
間違いなく日本も追随することになる

522:デフォルトの名無しさん
24/04/02 21:56:04.08 mnREx4SD.net
Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ
ONCDは健全なのかな

523:デフォルトの名無しさん
24/04/02 22:51:50.04 ZP8DsSPi.net
>>518
NASA？NSAじゃなく？
NSAはNASAじゃないぞ。

524:デフォルトの名無しさん
24/04/02 23:24:29.45 JjgiIhmH.net
ワロタ
NSAとNASAの区別もできんとはｗｗ

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

525:デフォルトの名無しさん
24/04/02 23:39:08.04 /KZzSXx2.net
とりあえず良いcrateが増えまくってほしいな

526:デフォルトの名無しさん
24/04/02 23:51:33.79 DOFjhDY0.net
>>524
あとは日本がどれだけ遅れるかだな
数ヶ月か、1年か、数年か、

527:デフォルトの名無しさん
24/04/02 23:57:17.27 ULMcj34Q.net
外部のお墨付きを欲しがる時点でオワっとるんよ
言語として
ここでそういう話題使って必死で盛り上げようとして
消えそうな火に風送ってるつもりかしらんけど

528:デフォルトの名無しさん
24/04/03 00:07:33.86 xB8sPKZQ.net
IT大手ライバル同士が
GAFAMからHUAWEIまで一致団結して
Rust Foundationを設立した時点で未来は確定していた
そしてRustに対抗できるライバル言語の芽が今も存在しない

529:デフォルトの名無しさん
24/04/03 05:31:15.82 SWmJ9bDO.net
>>527
話題にも上がらないよりまし

次ページ