Rust Part6

**デフォルトの名無しさん** · 2018/07/28(土) 03:04:38.63

Mozilla発のRust言語のスレ

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part5
http://mevius.5ch.net/test/read.cgi/tech/1518347244/

**デフォルトの名無しさん** · 2019/03/02(土) 01:38:04.42

>>505 Dropを実装した型の値がdropされるとき、フィールドは全てvalidじゃないといけない。
そのままメモリ解放するだけ＝Drop未実装ならいいんだけど、drop中にinvalidなフィールドにアクセスできちゃうのがダメだというのが問題
解決案は、ここでもOption::takeかmem::replaceでNoneにすげ替える

けど、まずはLearning Rust With Entirely Too Many Linked Listsを写経してみた方が良いよ
今のListの定義だと無駄なメモリを食うし、パターンマッチとstructは相性があんま良くないし、これから先も似たような穴にハマると思われる

**デフォルトの名無しさん** · 2019/03/02(土) 15:28:49.59

Rustいいらしいですよって話を会社でしたら、
テックリードが「RustでできることはCやC++でもテストとツールで十分やってけるからイラネ」って言ってたけどマ？

**デフォルトの名無しさん** · 2019/03/02(土) 15:50:22.82

&str で関数に渡すと解放されてしまって使い回すこどができないのですが
使い回す方法ありませんか

**デフォルトの名無しさん** · 2019/03/02(土) 15:52:40.18

コーディングスタイルを徹底的に統制できるならマ

**デフォルトの名無しさん** · 2019/03/02(土) 15:55:37.40

>>510
コンピュータでできることは人の手と頭でできるよ

**デフォルトの名無しさん** · 2019/03/02(土) 17:11:13.26

>>512
じゃあうちにはたしかに要らんなあ
そんな統制がいるほどの人数でもないし

回答サンクス

**デフォルトの名無しさん** · 2019/03/02(土) 17:40:27.42

>>510
そのリードが C++でauto_ptrがdeprecatedになった理由とMove Semanticsと右辺値参照の関係をちゃんと説明できる人なら C++ でいい

**デフォルトの名無しさん** · 2019/03/02(土) 18:53:06.97

人間が信用できないからこそCよりRustだろ
気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
コンパイラ先生に怒られながら厳しい指導の下にやっとコンパイルしていただくのがRust

この記事とか参考になるかも
https://tomo-wait-for-it-yuki.hatenablog.com/entry/2019/02/05/210746

**デフォルトの名無しさん** · 2019/03/02(土) 19:04:12.47

プログラミングは製造業だからな
厳格なチェックは本来あって当然

**デフォルトの名無しさん** · 2019/03/02(土) 19:10:02.40

>>511
&str is 何？

**デフォルトの名無しさん** · 2019/03/02(土) 19:13:35.19

>人間が信用できないからこそCよりRustだろ
>気を付けてコーディングすればミスはなくなる、ってのは戦前の日本軍的な精神論だ
ぴんとこないな。
rustの場合、お役所とおせばテストなど自前でしなくともokっていう
変な信用を生んでるだけだろ。そっちのがよっぽど日本的だと思うがね。

**デフォルトの名無しさん** · 2019/03/02(土) 19:33:57.30

>>519
今時の言語なので、ユニットテストは標準で整備されてるよね
コンパイラは計算ミスや仕様間違いまではチェックしないので

**デフォルトの名無しさん** · 2019/03/02(土) 20:15:35.93

考え得る全パターンをいつもテストできるならいいんじゃないの

**デフォルトの名無しさん** · 2019/03/02(土) 20:36:46.57

メモリ破壊はユニットテストで検出されないケースも多い

**デフォルトの名無しさん** · 2019/03/02(土) 21:36:12.88

注意力ってのは慣れると省力できるようになるけど、有限リソースだし個人の習熟度と体力に依存するんで、目に見えない負債になる
新しい言語を理解するコストは償却できるけど、注意深さってのはソースコードを触る限りはコストを発生し続ける
機械がチェックできることは機械にやらせた方が絶対に良い

**デフォルトの名無しさん** · 2019/03/02(土) 22:15:15.48

製品にするコードってどうせMISRA C辺りの静的解析噛ますし
今時ならvalgrindもテスト項目に入ってるだろうし
Rustなら全部コンパイラがやってくれる！と言われても、
いやCにも外部ツール入れれば同じことできるし……としか思わんのだよな

個人的にはクラスよりトレイトの方がしっくりくるからそれだけでもRustは意味があると思うが

**デフォルトの名無しさん** · 2019/03/02(土) 22:44:32.15

>>523
枯れてないコンパイラの癖に合わせる方がよっぽど注意力を削ぐと思う。
コンパイラになんでも機能ぶっこむより524のように構成した方がどのツールが文句言ってるのか
よっぽどわかりやすい。
機械にチェックさせるのはいいがシステムとしてモジュラリティーが高いツールの組み合わせのが
結局使いやすいし、ロバストになる。

**デフォルトの名無しさん** · 2019/03/02(土) 22:52:05.50

どうでもいいけど言語の持つ表現力とかは完全に無視なん？

**デフォルトの名無しさん** · 2019/03/02(土) 22:57:46.43

>>526
C++の方がノイズが多いくらいで表現力自体は大差ないわ
もちろん、そのノイズによる可読性や生産性の低下は決して無視できるものではないが

**デフォルトの名無しさん** · 2019/03/02(土) 22:59:57.91

>>525
Cだって作成当初よりコンパイラでチェックする範囲広げてるけど
全否定？

**デフォルトの名無しさん** · 2019/03/02(土) 23:01:34.51

>>526
CやC++との比較でそこ（表現力）に触れずに
「Rustは安全！C/C++はfree/delete忘れがーアクセス違反がー領域の破壊がー」ばっか言ってる人が多いのが疑問って話な

俺はトレイトに可能性感じてるから期待してるよ
C++のテンプレートとか関数オブジェクトとか書きたくねえし

あとチェッカーとコンパイラ分けるべきか合体させるべきかについては、
どっちにも善し悪しあるからCとRustどっちが優れてるとかはないと思ってる

**デフォルトの名無しさん** · 2019/03/03(日) 00:06:30.62

https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
MISRAに適合しててvalgrindでチェックしてもこういうのは無理じゃない？他に例が思いつかないけど

**デフォルトの名無しさん** · 2019/03/03(日) 00:19:36.71

Cじゃ確かに無理かもわからんが、C++のstd::vectorならatメソッドで同じことできるぞ

毎回アクセス範囲が適切か確認するから結局オーバーヘッドになってほぼ使われんがな

**デフォルトの名無しさん** · 2019/03/03(日) 00:45:31.79

基本はIndex::indexを呼んで必要なとき(オーバーヘッドが気になるとき)にunsafeで囲む
C++は全関数がunsafeで意識せずVec::get_uncheckedを使うようなもの
オーバーヘッドの問題でunsafeで囲んだらRustだってツールじゃムリ五十歩百歩って言われるかもしれないけど、五十歩の方がいい

**デフォルトの名無しさん** · 2019/03/03(日) 00:45:55.40

MozillaやRust作者の人達が、valgrindやチェックツールの使い方を知らない
アホ揃いだと思ってるの？

**デフォルトの名無しさん** · 2019/03/03(日) 00:57:04.94

>>533
MozillaやRust作者の人達の過激な信者が
valgrindやチェックツールの存在を知らないか軽視してるせいで
Rustの宣伝に対して過剰にC/C++をディスってるアホ揃いだと思ってる

もちろんそうじゃないRust推しもいることは承知の上だ

逆に、「そういうツール使えばC/C++だけで十分Rustなんてイラネ」って意見も
ベクトル違うだけで同じくらいアホだと思ってるがな

だからこそトレイトの使い方だとかモジュールの仕組みだとか
外部ライブラリ（crate）の扱い方の方向での他言語との比較が
あんまり見えないことが問題だと思うんだが

そういう意味で話題提供すると、cargoって結構disられてるけど
どの変がクソなのかいまいち分からん
キャッシュサーバ持てないって話ならnpmとかbundleとかgo getも大概では？

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

>>519
ほんそれ

**デフォルトの名無しさん** · 2019/03/03(日) 07:44:53.56

みんな同じ話題について話してるのか？
好き勝手独り言言ってるようにしかみえない。

**デフォルトの名無しさん** · 2019/03/03(日) 16:01:14.67

これがいつもの流れだ

**デフォルトの名無しさん** · 2019/03/03(日) 16:51:19.54

そりゃーRust信者とRustアンチしかいねえからな
話が噛み合うわけない

**デフォルトの名無しさん** · 2019/03/03(日) 16:53:34.09

Rustだと（unsafeなし、コンパイラのバグなしなら）プログラムの全実行パスでメモリリークや破壊がないことが保証できると思うけど、
C/C++で同等のチェックができるツールってある？
valgrindは単にvalgrindで実行したパスで問題なかったことが分かるだけって理解なんだけど。
もしあるならそれはそれで使ってみたい。

**デフォルトの名無しさん** · 2019/03/03(日) 17:11:00.51

>>539
俺もその認識なんだけどvalgrindナメてたかな
Firefoxのcssのバグはテスト書いて発覚した感じなんだけど

**デフォルトの名無しさん** · 2019/03/03(日) 17:26:47.25

その手の静的解析ツールはたいてい商用製品だね。一番手頃なのはVSで使えるSALかな。

**デフォルトの名無しさん** · 2019/03/03(日) 17:57:36.24

顔本のinferがオープンソースで全パス調べてくれるやつだな

企業ならcoverity課金してるだろ

**デフォルトの名無しさん** · 2019/03/03(日) 18:42:44.87

inferは知らなかった。ちょっと試してみる。
まぁ商用含めても原理的に検出率100%とはいかないだろうけど、
Rustだって標準ライブラリ内のunsafeバグとかあるからいい勝負なのかな。

**デフォルトの名無しさん** · 2019/03/03(日) 18:48:10.42

全パスチェックしてもRustのコンパイル時のチェックには及ばない
全パスチェック程度で済むものならば、Rustにあんなややこしい概念を持ち込む必要はないんだよ

**デフォルトの名無しさん** · 2019/03/03(日) 18:59:21.85

言語として縛りを強制するってとこに旨みがあるよね
静的チェックを過大評価云々は的を外した無意味な議論

**デフォルトの名無しさん** · 2019/03/03(日) 19:51:05.48

Rcなりunsafeなりあるわけでなんだかね。
rustを意識してプログラムをすることに意味はあるがrustの実装系を使うことに
そこまで意味はない。

**デフォルトの名無しさん** · 2019/03/03(日) 22:01:18.12

俺はweb屋さんだけどサーバ書くならrustが最高とおもってる
これって過激な信者？

**デフォルトの名無しさん** · 2019/03/03(日) 22:32:13.67

信者だアンチだディスったディスってないでrustを語れよ

**デフォルトの名無しさん** · 2019/03/03(日) 23:36:41.41

coverityとかの静的解析って誤検出が結構ある
で誤検出かどうかの人力解析も超めんどくさい
かつ1度の解析にめっちゃ時間かかる

これがあるからC/C++でもRust同等とかないわ

**デフォルトの名無しさん** · 2019/03/03(日) 23:53:56.27

>>547
web屋さんはもともとC++なんて使ってないし使う人が順調に増えていってる印象
問題はweb屋さん以外にどうアピールするか

**デフォルトの名無しさん** · 2019/03/03(日) 23:58:03.76

どうせ一時の流行で終わるんだから被害は少ないほうがいい
Scalaとかも中途半端に業務系が乗っかってきはじめた矢先に梯子外されて死屍累々の惨状だったし

**デフォルトの名無しさん** · 2019/03/04(月) 01:59:21.29

>>551
なんか梯子外された事件あったっけ？
Java8の登場でScalaがただの難解なJava8になった話？

**デフォルトの名無しさん** · 2019/03/04(月) 05:28:04.34

scala十分流行ってるでしょ

**デフォルトの名無しさん** · 2019/03/04(月) 05:49:29.62

えっ

**デフォルトの名無しさん** · 2019/03/04(月) 07:38:18.48

Javaは今でもクソ言語なのでScalaとは比べるべくもない
単に日本の人月制度とマッチしなかっただけ
Rustもそうなる
学習コストの高い良い言語より学習コストの低い低単価で人を集められる言語

**デフォルトの名無しさん** · 2019/03/04(月) 08:34:11.43

色んな業界があるのに一緒くたにして評価できなくない？

**デフォルトの名無しさん** · 2019/03/04(月) 16:55:17.66

>>555
JavaやPHPはともかく、そういう意味でCやC++がコスト低い言語とは思えんが

**デフォルトの名無しさん** · 2019/03/04(月) 22:48:27.10

個人的な経験だけど、Rustのコンパイラを単純に黙らせるようにソース修正していくと物凄く汚くなることが良くある
ので、そもそもの設計を見直すようになったり、かくあるべしって仮設を明確にするクセが身についた気がするよ

**デフォルトの名無しさん** · 2019/03/04(月) 23:49:25.53

>>557
低学歴のC/C++職人様はつぶしが利かないからスキルの割に高くないイメージ

**デフォルトの名無しさん** · 2019/03/05(火) 05:49:14.36

資源の共有状態を見直すってのはrustは置いといてもプログラムをに置いてやっぱ本質だなと思う。

**デフォルトの名無しさん** · 2019/03/05(火) 23:33:10.77

ArcとかMutexとかRwRockが気に入ってる
最初めんどくさかったけどよく考えたら当たり前に必要なんだよね
そこを隠蔽しないことでコストのトレードオフをプログラマに意識させるのがよい

**デフォルトの名無しさん** · 2019/03/06(水) 00:07:02.80

練習で他言語のプログラムを移植してみたらコンパイラに
ガンガン怒られて本人が壊れるような使い方しないからと手抜きしていた部分が
洗い出されてなるほどなあと思った

**デフォルトの名無しさん** · 2019/03/06(水) 00:31:05.23

>>558
黙らせるだけで終わってしまうわ

**デフォルトの名無しさん** · 2019/03/06(水) 02:33:21.88

rustでguiだと何使う？
やっぱgtk？

**デフォルトの名無しさん** · 2019/03/06(水) 06:28:18.81

rustに限らず他の言語でもgtkぐらいしかないでしょう

**デフォルトの名無しさん** · 2019/03/06(水) 10:55:39.33

んなこたーない

**デフォルトの名無しさん** · 2019/03/06(水) 11:15:19.50

orbtk?
redoxのguiだけど、windowsでも動いたよ。

**デフォルトの名無しさん** · 2019/03/06(水) 12:02:48.23

GTKは糞

**デフォルトの名無しさん** · 2019/03/07(木) 02:41:58.99

>>561
当たり前じゃねえから
PythonとかPerlとかRubyで書かれたプログラムにはないけどちゃんと動く
それともこれらの言語で書かれたものはプログラムじゃないとか言っちゃう系？

**デフォルトの名無しさん** · 2019/03/07(木) 07:08:20.11

>>569
パイソンだって排他制御書くじゃん

**デフォルトの名無しさん** · 2019/03/07(木) 07:18:52.41

RwRockが自然に必要ってのは言い過ぎだわな。
必要なところは必要だろうがそれがあまりに多いのは多分設計ミスってる。

**デフォルトの名無しさん** · 2019/03/07(木) 08:07:15.51

ですから必要なところは必要と言ってるだけじゃないですか
当たり前にってのは原理的に必要と言ってるだけだよ

**デフォルトの名無しさん** · 2019/03/07(木) 09:00:14.60

>>569
Rustの設計思想理解してないのか
単にアホなのか

**デフォルトの名無しさん** · 2019/03/07(木) 09:44:04.96

まぁ自分の書いている範囲内しか見えない人は普通にいるだろう。
どの言語だってライブラリや処理系レベルでは排他制御はあるし、
逆にどこにもなかったら単に間違ってる。

**デフォルトの名無しさん** · 2019/03/07(木) 11:44:24.50

Perlは知らんがRubyやPythonには
GILっていう排他制御が言語処理系に含まれてることを考えると
非常に味がある

**デフォルトの名無しさん** · 2019/03/07(木) 11:46:01.46

Luaって息してないの？

**デフォルトの名無しさん** · 2019/03/07(木) 11:50:35.55

>>576
他の言語が息できない分野でエラ呼吸してるよ

**デフォルトの名無しさん** · 2019/03/07(木) 12:47:59.26

>>575
GILは複数スレッドの競合によってインタプリタがぶっ壊れるのを防ぐために必要な、インタプリタ自身の内部的な排他制御
アプリケーションコードで行う排他制御の代わりにはならないよ
インタプリタがスレッドセーフでない糞実装であるための苦肉の策で、
Rust含め元々スレッドセーフな「まともな処理系」なら全く必要のないもの

**デフォルトの名無しさん** · 2019/03/07(木) 12:55:45.82

そういや Perl でマルチスレッドのプログラムは作ったことないなあ。fork してマルチプロセスにするのはよくやるが。

**デフォルトの名無しさん** · 2019/03/07(木) 13:06:36.81

>>575
GILは欠陥扱いだろ…

**デフォルトの名無しさん** · 2019/03/07(木) 14:00:26.28

そうか、今時の人はみんなLock-freeアルゴリズム使いこなすんだな
Mutexなんて見たことないんだ

**デフォルトの名無しさん** · 2019/03/07(木) 16:39:47.28

OSかそれに近いコア領域とかトランザクション必要なデータベースでも書かん限り
MutexとかLockとかが必要だとは思わんなー
Web系にもてはやされてるらしいけど君らそもそもそれオーバーキルどころか逆に足枷ならん？って思う

**デフォルトの名無しさん** · 2019/03/07(木) 18:08:18.69

そういうあんたは並行処理どうやってんの？

**デフォルトの名無しさん** · 2019/03/07(木) 18:38:08.85

>>583
そもそもそんなに並行処理をOSやミドルウェア頼りじゃなくて自分で書くが必要な場面て例えばどこ？
と質問に質問で返してみる

**デフォルトの名無しさん** · 2019/03/07(木) 18:43:18.41

念のため言っとくと、別にロックなんて無駄だとか言いたいんじゃなくて
ArcとかMutexとかRwRockが当たり前に必要とかいうマウンティングに反論してるだけな

**デフォルトの名無しさん** · 2019/03/07(木) 18:54:58.71

>>584
仮にお前がミドルウェア使うだけの些末プログラマ
だとしてもミドルウェアがマルチスレッドで動いていたり、
複数のミドルウェアを使う場合は
排他処理が必要なケースは普通に出てくるだろ

**デフォルトの名無しさん** · 2019/03/07(木) 19:01:04.74

>>585
rustをc++の代替候補として考えるなら使って当然
並行処理でこそrustの有り難みが生きるわけだし
マウンティングに感じるのは単にお前が並行処理に馴染みがないからだろ

**デフォルトの名無しさん** · 2019/03/07(木) 19:49:57.49

>>586
それはそんな使い方する方が何かしらおかしい
排他制御ってのは本当に必要なところ以外ではやらないように回避するもんだ

>>587
Rustの旨味がそこにあるのは否定しないが、
それが全プログラマが当たり前のように使いこなせるべきっていうのは
ただのマウンティングだろうに

**デフォルトの名無しさん** · 2019/03/07(木) 20:59:20.87

>>588
排他が必要だからするにきまってんじゃん
そういうところに思考が及ばないやつはjsだけ使ってりゃいいと思うよ

**デフォルトの名無しさん** · 2019/03/07(木) 21:02:19.38

プログラマーがリソースの共有状態を意識すれば
無駄な排他制御しなくても大丈夫だという主張かねえ

**デフォルトの名無しさん** · 2019/03/07(木) 21:17:09.18

RwRockってRwLockの間違い？
そういう言葉遊びのライブラリでもあるの？

**デフォルトの名無しさん** · 2019/03/07(木) 22:06:32.44

RwLockが少ない設計で組めたぜ！って自慢するならともかく
RwLockめっちゃ使ってますなんてアピールする奴は普通にバカだろ。

**デフォルトの名無しさん** · 2019/03/07(木) 22:11:49.22

単に日本語の問題では？
多分解釈が二通りある。
マルチスレッドプログラムにとって排他制御は当たり前に必要
プログラマにとって排他制御は当たり前に必要

個人的には文脈から前者と理解したけど、後者だと思うなら言い過ぎだというのは分かる。

**デフォルトの名無しさん** · 2019/03/07(木) 22:15:22.37

lockをrockと間違ってもしれっとしてるやつもかなりのバカだよね
ソフトウェアの超頻出単語じゃん

**デフォルトの名無しさん** · 2019/03/07(木) 22:34:05.54

だからプログラマにとって当然の能力という意味で言ってないって
めっちゃ使ってるとも言ってないって
隠蔽しないから必要性とコストを意識できていいねって言ってるやんけ

誤字はすまんかったけど

**デフォルトの名無しさん** · 2019/03/07(木) 22:44:55.70

まあ俺が採用だったらここまであからさまな地雷は避けるわ。

**デフォルトの名無しさん** · 2019/03/07(木) 22:59:19.47

なぜ自分が採用に関与できない雑魚だと表明してしまうのか理解できないけど、そうしたほうがお互い幸せになれるだろうね

**デフォルトの名無しさん** · 2019/03/07(木) 23:52:54.26

>>596
お前は派遣だろ目を覚ませ( ‘д‘⊂彡☆))Д´) ﾊﾟｰﾝ

**デフォルトの名無しさん** · 2019/03/08(金) 07:01:44.63

こういう奴らに並列実装なんてさせるから地獄を見ることになるんだよな。。

**デフォルトの名無しさん** · 2019/03/08(金) 09:05:39.84

Rustなら地獄を見そうなコードは
コンパイラが怒るからよかったじゃん

**デフォルトの名無しさん** · 2019/03/08(金) 09:22:23.55

Mutexとかもはや古典技術でしょ
Rust使う領域では理解してて当然と言っていいよ
これがマウントだとしたらキレイなマウント

**デフォルトの名無しさん** · 2019/03/08(金) 11:37:10.05

>>601
そういうことばっか言ってるからいつまでも二流言語と違うんか？

**デフォルトの名無しさん** · 2019/03/08(金) 12:02:47.61

フリーランチの時代はとっくに終わってるのに気づいてないんだ…
プログラミング界の横田庄一だな

**デフォルトの名無しさん** · 2019/03/08(金) 12:28:00.15

横田庄一と聞いてすぐに誰の事かわかる人は横田庄一

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

いやちょっと待て、横井だよな？

**デフォルトの名無しさん** · 2019/03/08(金) 13:03:58.27

>>605
すまん横井だw
よっこいしょういち

**デフォルトの名無しさん** · 2019/03/08(金) 13:17:39.94

Rockといい横田といい、この程度のことも注意できない奴だから
こんな口うるさい姑みたいなやりたいこともやりにくい言語をもてはやすんだと納得

**デフォルトの名無しさん** · 2019/03/08(金) 13:28:47.21

横井さんも刺身食えなかったらしいからな
排他処理に拒否反応示すのも無理はない
Rustはやめときな

**デフォルトの名無しさん** · 2019/03/08(金) 18:14:30.11

Rustは刺身だった