プログラミング言語 Rust 4

**デフォルトの名無しさん** · 2017/10/14(土) 17:38:14.04

Mozilla発のプログラミング言語「Rust」のスレです

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

前スレ
プログラミング言語 Rust 3
https://mevius.5ch.net/test/read.cgi/tech/1495343069/

**デフォルトの名無しさん** · 2018/01/08(月) 22:52:48.05

カプコンのあれはゲーム用に超最適化されたGC詰んでるから…

**デフォルトの名無しさん** · 2018/01/08(月) 23:20:56.60

>>584, >>597, >>599
そりゃぁ、ゲームエンジンは速度が求められるからC#じゃ力不足だろうな。
そこまで持ち出されるとグーの音も出ない。
だから「『普通は』気にするようなものじゃない」って書いた。
ゲーム作ろうとするのにゲームエンジンから自作しようとする奴なんて『普通は』いないだろ？
そして、仮にゲームエンジンの開発に使うんだったとしても、
C#みたいなGC付きの言語ならともかく、C, C++, Rustの差は誤差みたいなものでしょ。
なぜなら、C++とRustの差が気になるっていうのなら、当然、C++とCとの差だって気になるはずだよな？
だったらゲームエンジンの開発にC++じゃなくてCを使ってるはずだろ？
でも実際にはCじゃなくてC++が使われている。
ということはゲームエンジンみたいにシビアな領域でもCとC++の差はさほど気にされていないってことになる。
ならやっぱり、C, C++, Rustの差なんて気にするようなものじゃないと言いたかった。

**デフォルトの名無しさん** · 2018/01/08(月) 23:59:18.26

>>575, >>596
Rustは実装にもよるけど vtable はほとんど使わないはずだよ。
「ジェネリックとトレイト境界」を使えば引数に関しては静的ディスパッチが可能。
戻り値のほうは「ジェネリックとトレイト境界」じゃどうにもできないけど、
こっちはTagged Union 使えば大体は何とかなる。
現状、クロージャを返す場合はトレイトオブジェクトを使わざるを得ないけど、
クロージャを返すことって稀だし、そこまで気にするようなことじゃないと思ってる。
Cにはそもそもクロージャ自体が存在しないわけだし。C++でもクロージャは一般的じゃない。

smart pointer に関しても unique_ptr なら遅くはならない。(ほとんど誤差みたいなもの)
だって unique_ptr は参照カウンタ使ってないし、Rallの仕組みを使って構造体(スタック)に
ポインタを持ってデストラクタで解放を行ってるだけだから、その程度で遅くなるわけがない。
そして、Rustはデフォルトが C++の unique_ptr と同じだからやはり遅くはならないはず。
遅くなるのは内部で参照カウンタを使ってるshared_ptrとweek_ptrの2つ。
Rustの場合は参照カウンタは Rc or Arc として標準ライブラリに用意されてる。
まあ、Rustで Rc or Arc を全く使わずに作るってのはちょっと現実的じゃないけど。

まぁ、自分もそれほど詳しいわけじゃないけど、
vtableとsmart pointer はRustが遅い理由にはならないんじゃないかな。
RustがC, C++ と比べて少し遅い理由は他にあると思うよ。
個人的にはまだコンパイラが成熟してないってのが主な理由だと思ってるけど。

結構いっぱい書いたけど、やっぱり結論としてはC, C++, Rust の速度差は普通に使う分には気にすようなものじゃないと思う。

**デフォルトの名無しさん** · 2018/01/09(火) 00:07:21.22

>>602
訂正
week_ptr ×
weak_ptr ○

**デフォルトの名無しさん** · 2018/01/09(火) 00:16:14.62

確かに

**デフォルトの名無しさん** · 2018/01/09(火) 08:02:08.21

HashTableがデフォルトで安全側に倒してSipHash使ってるのも大きい気はする
ripgrepやfont-rsなど既存の実装よりも圧倒的に高速なrust実装もあるし、言語自体の差と言うよりも、書き方の差だと思う
constexpr周りはDやC++の方が充実しているけど、build.rsなどで代替できなくもないと思う

**デフォルトの名無しさん** · 2018/01/09(火) 09:33:53.22

Unityが出てからC#でゲーム書く人が増えたわけだし、どこかの企業が気合い入れてRustサポートしたエンジン作れば使ってみる人も増えるやろ

**デフォルトの名無しさん** · 2018/01/09(火) 10:25:16.50

速さの差を気にする必要はないとかいう奴って
普段どんなところでコード書いてるプログラマなんだ？
プログラマなら一番速い選択するべきだろ

**デフォルトの名無しさん** · 2018/01/09(火) 10:36:54.87

かけれるコストが一定という制約で一番速くなる言語を選ぶと結果は変わるんだよ

**デフォルトの名無しさん** · 2018/01/09(火) 10:59:57.42

>>607
「速さ」にも何種類かあるのは理解してる？
最近は開発スピード優先だろ。

**デフォルトの名無しさん** · 2018/01/09(火) 12:31:14.96

開発スピード優先とは言っても
アルゴリズムや計算量知らないで
とんでもない糞コード書く香具師はいる

**デフォルトの名無しさん** · 2018/01/09(火) 13:00:20.99

そりゃ論外だ。
開発言語の問題じゃない。開発手法は少しは関係あるか。

**デフォルトの名無しさん** · 2018/01/09(火) 13:08:01.94

Rustでプログラマが意識してないのに走るランタイム処理って何かあるかな？
起動時になんか処理してる？
あとは、メモリ解放時に意外とjemallocが重いとか？

**デフォルトの名無しさん** · 2018/01/09(火) 14:20:37.33

かけれるコストを減らすのがプログラマの仕事だろうに……
処理の肝の関数をアセンブリで書くのに一週間かけるのか？

**デフォルトの名無しさん** · 2018/01/09(火) 15:06:26.69

> プログラマなら一番速い選択するべきだろ
> かけれるコストを減らすのがプログラマの仕事だろうに……

一番速い言語を選択した上でかけれるコストを減らすという主張のようだが、
コストの上限って大抵あるのよ？
上限ないならプログラム全部アセンブリで書いた上で
お好きなようにかけれるコストを減らしてください

> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？

元になる関数の有無、関数の規模、ボトルネックとしての割合、
複雑さ、アーキテクチャ、既存のテストコードの有無、
作業する人数、スキルと単価の前提すらなく作業時間だけ提示されても
必要なら一週間かけますとしか言えないよね？

**デフォルトの名無しさん** · 2018/01/09(火) 15:08:41.92

>>613
> 処理の肝の関数をアセンブリで書くのに一週間かけるのか？
必要ならやるけど
ふつうは、アセンブリで書くというという結論に至る前に
処理の見直しで数ヶ月試行錯誤するかな

**デフォルトの名無しさん** · 2018/01/09(火) 15:46:18.74

本当に必要なら
関数のアセンブリ化くらい一日でやるのがプログラマだろって話な？

**デフォルトの名無しさん** · 2018/01/09(火) 18:36:32.15

処理の肝の関数が一日程度のアセンブリの最適化ですむ程度なら、
絶対に手を付けないな
コードの保守性を考えるとむしろ害悪

ドライバのコードを一週間かけて最適化して劇的に早くしたことがあるが、
関数に対する暗黙の前提とかを見つけて、
ひらめきでニーモニックを最適化していく作業
一日程度でやることじゃない

**デフォルトの名無しさん** · 2018/01/09(火) 20:29:59.87

今時の高性能(で複雑な)なプロセッサの最適化はコンパイラ＞人間

**デフォルトの名無しさん** · 2018/01/09(火) 23:11:43.33

C++からRust移植で高速化！？

https://twitter.com/tanakh/status/950659594379968513

**デフォルトの名無しさん** · 2018/01/10(水) 00:25:27.71

例の会社の方ですね

**デフォルトの名無しさん** · 2018/01/10(水) 01:04:10.48

stockfishもrustで書き直しましょう！

**デフォルトの名無しさん** · 2018/01/10(水) 05:48:28.54

移植で高速化する案件ってのは、大概同じ言語で書き直しても高速化するからなあ
要するに作り直しに際して全体を見直すという行為が一番効く

**デフォルトの名無しさん** · 2018/01/10(水) 11:54:40.05

詐欺会社の社員の言うことなんて信じるからRustなんかに飛び付くんやろなあ

**デフォルトの名無しさん** · 2018/01/10(水) 12:43:57.38

気が狂ったようなレスだな

**デフォルトの名無しさん** · 2018/01/10(水) 15:45:01.02

>>622
お前それインタプリタ言語からコンパイル言語への移植でも同じこと言えんの？

**デフォルトの名無しさん** · 2018/01/10(水) 15:47:29.13

GoogleのAIエンジン、別にRustで書けとは言わんがせめてGoにしろやと常々思う
演算量多いんだよバーロー

**デフォルトの名無しさん** · 2018/01/10(水) 16:22:06.54

GoogleのサーバサイドではPythonからGoへ置き換わりつつあるみたいだけど、そっちも置き換わるのか

**デフォルトの名無しさん** · 2018/01/10(水) 18:47:50.56

スレチだけど、Goはマルチコアでの並列処理に適した言語だからAIエンジンをサーバで動かすなら置き換えて欲しいよね

しかしまぁ、C/C++からRustの移植で早くなるのは、オブジェクトの取り回しが無理やり矯正されることによる恩恵かねぇ
mutexのlock/unlockによるブロッキングが早々起きないから待ち合わせしなくていい所の待ち合わせは矯正されてそう
プログラマが意識して作るならC/C++のままで良いけど、人がやるより機械がやってくれるならそれに越したことない

**デフォルトの名無しさん** · 2018/01/10(水) 20:16:34.04

tensorflowの事言ってるなら、pythonで書かれてなかったら誰も使わないよ

**デフォルトの名無しさん** · 2018/01/10(水) 22:46:46.16

pythonは利用者==開発者での試験開発には非常に好ましい言語だけど、利用者!=開発者では性能悪くてver.2,3で言語仕様互換性のないRust未満のクソ言語だよ？
AIエンジンを実用ツールとして見ない日曜プログラマはtensorflow(python2 lib)をホクホクと使うけど、実用ツールとして見たらtensorflowは誰も望んでは使わないよ

同じように言語の適材適所を考えないプログラマはRustの適所を考えることもせず、アンチ活動に走るよね
コンパイル通るコード書くの大変だし、ローポインタ操作は好まれないし、日本語書籍少ないしで決して便利な言語じゃないけどRustもハマれば良い言語よな

**デフォルトの名無しさん** · 2018/01/10(水) 22:54:00.21

アンチの存在はともかく
アンチと戦うのが好きな人が多いのが難点ですね

**デフォルトの名無しさん** · 2018/01/11(木) 01:05:22.99

たなこふアンチはどっか逝って

**デフォルトの名無しさん** · 2018/01/11(木) 03:40:32.06

演算グラフを構築してGPUに投げる処理をrustで書けば速くなると思ってる低脳っぷりヤバイわ
GPUの100倍も遅いCPUでループ回るのが速いとかマジでどうでも良いからw

**デフォルトの名無しさん** · 2018/01/11(木) 04:02:35.22

今rustで業務アプリ開発してるけど、マルチスレッドでのデータ競合をコンパイル時にチェックしてくれるのが特にいい感じだわ
ただ、今まで気楽に相互参照使ってた所とかrust流の書き方しないとキツイのが結構あるな

**デフォルトの名無しさん** · 2018/01/11(木) 11:23:35.66

まあ行列演算のコアなところは今でもアセンブラだったりするわな。
一つの言語で全てのレイヤーを賄おうとするのがそもそも馬鹿すぎる発想。

**デフォルトの名無しさん** · 2018/01/11(木) 11:40:16.18

>>630
挙げてるデメリット全部致命的で、
全く嵌まれば強いように見えないな

**デフォルトの名無しさん** · 2018/01/11(木) 13:36:38.57

>>636
それってpythonについて文句言ってんの？それともRust？
それとも両方？

**デフォルトの名無しさん** · 2018/01/11(木) 19:09:36.95

>>630
日曜プログラマとかレッテル貼ってdisってみたけど、
実は自分の方がクソど素人だと>>633>>635にバラされた気分はどう？

流行りだからってドカタが無理してAIとか口出さない方が良かったね

**デフォルトの名無しさん** · 2018/01/11(木) 19:11:41.94

>>637
Rust
Pythonについては同意見

**デフォルトの名無しさん** · 2018/01/11(木) 23:02:05.67

道具でしかないプログラミング言語ごときに何でそう愛憎うずまくレスが沸くんだぜ

**デフォルトの名無しさん** · 2018/01/12(金) 00:01:22.91

やっぱりマイナー負け組言語マニアは余裕がないから
簡単にムキになっちゃうんじゃね

**デフォルトの名無しさん** · 2018/01/12(金) 00:16:17.30

Rustが使える有能な言語だと思っている？お前がそう思うんならそうなんだろうお前ん中では

Rustが使えない糞な言語だと思っている？お前がそう思うんならそうなんだろうお前ん中では

お前がそう思うんならそうなんだろうお前ん中では

**デフォルトの名無しさん** · 2018/01/12(金) 10:24:05.79

>>642
そういうお前のなかではどうなんだ？

**デフォルトの名無しさん** · 2018/01/12(金) 15:03:45.10

>>640
本当は電気ドリル使った方が楽なのに頑なにスコップ使わせたり、
逆にブルドーザーでやれというようなアホな現場があるのが
ITの世界だったりする。
まあそんなことが続けばその道具を嫌いになるのはわからんでもない。

**デフォルトの名無しさん** · 2018/01/12(金) 16:29:33.21

>>644
わかる
そしてスコップやブルドーザーでも時間や犠牲を払いつつもやれてしまうのがITの世界

**デフォルトの名無しさん** · 2018/01/12(金) 19:30:59.16

>>638
とりあえず、tensorflowのコードを見てないんだなって思った
GPUに投げる演算処理以外のステップ処理とか関数コールとか動的型変数の取り扱いとか
インタプリタ言語がコンパイル言語より遅い理由に挙げられるデメリットをガン無視かよぉ

>>639
IteratorやOption, Resultとか、ハマればC/C++で何行もかけて書いてた所が1行に収まって
短くて可読性高くて性能良いコードになるのはメリットだと思うんだけどなぁ
あとは、makeだのvalgrindだのgoogletestだの色々な3rd party toolを使わなくてもcargoで完結するのホント助かる

**デフォルトの名無しさん** · 2018/01/12(金) 20:43:22.05

>>646
3rdパーティツールを使ってないんじゃなくて、利用が簡易ってことだけどな。
そういう怪しげなこと書くくらいならモチっと使い方なり書いた方が普及には繋がると思うよ。

https://qiita.com/kubo39/items/cb84cd0ee89d257ce11e

**デフォルトの名無しさん** · 2018/01/12(金) 20:52:57.80

>>646
tensorflowはボトルネックになりそうな所はC++で書かれてるよ
想像でテキトーな事を書くなよ

**デフォルトの名無しさん** · 2018/01/12(金) 21:01:05.95

Pythonが科学技術分野で好まれてるのは
numpyやscipyのお陰だから言語に文句つけても意味ないし、
Rustで書くよりnumpyで行列演算した方が速いから
速度面でも移行するメリットがない

**デフォルトの名無しさん** · 2018/01/12(金) 21:54:28.61

>>644
ITに限らないような。低能率な環境や命令を棚に上げて生産性向上などと吠える製造業も多いぞ

**デフォルトの名無しさん** · 2018/01/13(土) 09:02:27.08

>>650
未だに設計にEXCEL使ってる現場とか多いしね。
自称IT屋がIT使ってない。

**デフォルトの名無しさん** · 2018/01/13(土) 19:22:01.99

excelがITではないとは暴言では

**デフォルトの名無しさん** · 2018/01/13(土) 19:34:17.26

エクセルは芸術

**デフォルトの名無しさん** · 2018/01/13(土) 21:22:56.33

>>652
ああ精確には「古いIT」だな。
客には「Excelで台帳管理しないでDBとWebアプリ使いましょう」とか提案する癖に、開発工程ではExcel使ってるという非効率さ。

**デフォルトの名無しさん** · 2018/01/13(土) 21:38:44.30

Excelが悪いとは思わないけど処理の規模が一線を越えてくるとプログラムを書いた方が処理効率や保守性の面で有利になる
関数山盛りの激重スパゲッティワークシートを運用しているところは少なからずあるのでは
あとExcelに表計算ソフト以上の仕事をさせているところも結構あるな

**デフォルトの名無しさん** · 2018/01/13(土) 21:43:49.20

経済学の論文でエクセル使ってて、しかし普通にバグってて問題になってたことがあったな。

**デフォルトの名無しさん** · 2018/01/14(日) 00:19:53.66

rustスレだと思っていたがexcelスレだった

**デフォルトの名無しさん** · 2018/01/14(日) 01:19:41.63

>>654
規模がでかくなるとすぐ破綻するが
使い捨て作業でつかうぶんには超優秀

なにもまちがってない

**デフォルトの名無しさん** · 2018/01/14(日) 03:40:45.43

まあ実際はエクセルとバージョン管理使ってりゃそれで十分なケースは多いけどね。

**デフォルトの名無しさん** · 2018/01/14(日) 09:51:38.95

とある公的研究施設に嘱託で行ってたときの実話なんだが

・それエクセルでマクロ書いたら多少楽になるんじゃね？って提案
→わけのわからんことに時間使わないで今すぐ手を動かして紙で管理してね

・コピペ満載糞コード見せられ「なぜこれ関数書かないんですか？」とだけ質問
→関数使うと見難くなる、保守しにくくなる、関数は書かないでね

なお、必死で食い下がって関数書くことだけは許してもらった模様
公務員なんてのはPCの前に座って屁こいてるだけで時間が金になるから
みんなこんなもんよ
時間を惜しむと言う発想が無いか、少なくとも民間とは違う

**デフォルトの名無しさん** · 2018/01/14(日) 11:24:43.60

rustなんて使ってるやつも同じメンタルだな
成果物出さないでコンパイラにエラーメッセージ出させてるだけで時間が金になるようなやつ
物作らなくていいなら理想の言語だわな

**デフォルトの名無しさん** · 2018/01/14(日) 11:37:01.71

けんきゅうしせつのひとが嘱託よりすべてにおいて優れているのは自然の摂理なので
本当にわけのわからない提案をしたり
既存コードに手を突っ込んで意味不明なリファクタをしようとしたりしたんだろう

マクロ化したり関数作ったほうが本当に能率いいなら
許可なぞとらずに自分のところだけそれでさっさとやっちゃう
うまくいくようならあとから提案する

**デフォルトの名無しさん** · 2018/01/14(日) 11:41:16.95

>>662
だーれがその「自分で勝手にやったところ」の面倒を見てくれるんだ？
嘱託ごときが定年まで面倒見れるわけもなかろうに
勝手にブラックボックス作るのは何様？

**デフォルトの名無しさん** · 2018/01/14(日) 11:46:14.88

自分の責任範囲内の話だし
特にブラックボックスなところはないが
なにがきにいらんのだ

**デフォルトの名無しさん** · 2018/01/14(日) 11:48:39.30

嘱託に設計を勝手に変えられる「責任」が存在するならそれは嘱託ではなくね？
自分が勝手にやった、自分一人しかわからないものは十分ブラックボックスだ

**デフォルトの名無しさん** · 2018/01/14(日) 11:57:24.04

コーディングルールに関数作らないことって明記されてなかったら
べつにいいんじゃないか

**デフォルトの名無しさん** · 2018/01/14(日) 12:26:12.32

いや関数ダメとか普通にどうかしてんだろ。。
これでブラックボックス化するからダメ言うんだったら何もできんわ。

**デフォルトの名無しさん** · 2018/01/14(日) 13:02:12.25

そもそもプログラミングってきちんと正しく
ブラックボックス化（カプセル化）しましょうってものだろうに。。。

**デフォルトの名無しさん** · 2018/01/14(日) 13:39:57.15

カプセル化はAPIと内部状態の分離であって
中のコードや仕様を隠蔽するのが目的じゃないんだが

**デフォルトの名無しさん** · 2018/01/14(日) 13:57:59.71

ID:pZVQT//+ は何かズレてんな。だから必死なのか。

**デフォルトの名無しさん** · 2018/01/14(日) 14:43:57.62

Rustに限らないが、新しい言語ごり押しする奴や
コーディング規約ガン無視してコード書いたりする奴は、
結局そいつしかメンテできない領域を産み出すだけで、全く生産性に寄与しない
ってことが言いたいだけだぞ

**デフォルトの名無しさん** · 2018/01/14(日) 14:45:29.84

>>669
その「APIと内部状態の分離」をなぜ行いたいのかきちんと考えたことはあるのか？
車を運転するのに車の仕組みを知らなくても良いのと同じように、
プログラム（ソフトウェア）を使うのにそのプログラムの仕組みを知らなくても済むようにするため。
さらに言うと、プログラマが他人が書いたAPIを使うのに、そのアルゴリズムを知らなくても済むようにするためだ。
結局のところ、カプセル化の目的は「きちんと正しく」ブラックボックス化を行うことで
利用者側が内部の仕組みを知らなくても使い方を知るだけで済むようにすることだ。
「APIと内部状態の分離」を行うのはそのための手段として最も有用なものの1つというだけに過ぎない。
何の目的もなく「APIと内部状態の分離」を行えば、それは「中のコードや仕様を隠蔽する」のと大して変わらないよ。
もう少し本質をしっかりと考えよう。
君の言ってること自体は必ずしも間違っているわけではないし、言わんとしていることも分からんではないが、
なんというか、、、底が浅いと感じてしまう。

**デフォルトの名無しさん** · 2018/01/14(日) 14:56:16.89

一応補足。
かといってカプセル化した中身は汚くてもいいと言ってるわけじゃないよ。
大多数の人間はカプセル化した中のコードを読む必要性はないけど、
プログラムにバグがないことは絶対に保証できないのだし、
パフォーマンスの改善やらその他いろいろな理由で、
一部の他人は必ず中身のコードを読むことになるからね。

**デフォルトの名無しさん** · 2018/01/14(日) 14:56:20.26

>>663 勝手にブラックボックスを作るべきではない
>>664 ブラックボックスなどないではないか
>>668 プログラミングとはそういうものだ

>>663への反論として>>664はわかるが>>668はなんかずれてると思うがな。

**デフォルトの名無しさん** · 2018/01/14(日) 15:03:52.23

>>674
「そもそも論」の話をしたからな。
ずれてるというか議論のすり替えが起こってるな。
悪かった。申し訳ない。

**デフォルトの名無しさん** · 2018/01/14(日) 17:34:15.38

どうなんだろう
人と違うことやるときは
特に何も決まってなくても提案として言ったほうがいいの？

**デフォルトの名無しさん** · 2018/01/14(日) 19:43:43.81

rustに関係ない話持ち込んじゃってゴメンね…
「関数書くな」って真顔で言われたときのショックを伝えたかったの
Cから入った人間だから「プログラムを書く≒関数を書く」
だとどこか思い込んでたようなとこがあったのかなぁ
軽くパニックになったわ
関数書かないで何を書くんだろう…って
関数を書かないレベルの人に言葉を尽くすのは大変だったYO

**デフォルトの名無しさん** · 2018/01/15(月) 01:12:06.90

昔俺が入ったプロジェクトはJavaだったけど、1クラス1スタティックメソッドのみっていう縛りがあったよ

**デフォルトの名無しさん** · 2018/01/15(月) 10:25:31.75

嘱託の契約次第だろ。
まあ、無駄な時間を使わされるようだったら契約違反を盾に交渉するのは正しい。契約外だったら少なくとも追加費用を要求しないとな。

**デフォルトの名無しさん** · 2018/01/15(月) 12:02:33.62

嘱託の人間に「こっちの方がいいから」って理由で
そいつにしかわからないプログラム書かれた側から言わせてもらうとまじでやめろ

お前がどんなにクソだと思おうと言われたようにやれ
嘱託のお前にとっては書いたらおさらばでいいんだろうが、こっちはそれを半永久的にメンテするんだぞ
こっちの形式指定はメンテするためにこっちが必要な条件なんだ

**デフォルトの名無しさん** · 2018/01/15(月) 12:05:18.28

だから「新しい言語のRust使います」だの「ナウでヤングなライブラリ使います」だの「イケてるツールのwebpack使います」だのは
お前がお前のために書くプログラムでやれ
嘱託先に納品する物で書くな。それはお前の物ではない

**デフォルトの名無しさん** · 2018/01/15(月) 12:09:10.97

関数切るなって指示も、メンテナンス性考えたら自然とそうなるところもあるだろう
例えばコード上あっちこっち飛ばれたら追えなくなるメンテナもいるんだ
そういう人にもメンテナンス業務させるためにそういう指定になるのは自然なこと

さすがにうちではないけども、そんな奴を抱えてるSIer上流も当然あるだろう

**デフォルトの名無しさん** · 2018/01/15(月) 12:11:40.00

人生楽しくなさそうだね

**デフォルトの名無しさん** · 2018/01/15(月) 12:31:52.75

逆にどんどん使ってくれというところもあるし場所によるとしか
どちらのケースが多いかは知らない

**デフォルトの名無しさん** · 2018/01/15(月) 13:32:29.94

>>680, >>681, >>682
まぁ、正しいこと言ってるとは思うよ。
納品物に使う言語とかを独断(個人の趣味)で決める奴は確かにバカだと思う。
でも、関数使うんじゃないって強制する側も大概だからな。
従うのが社会的に正しいってだけで、情報工学的には明らかにおかしいこともまた事実。
それと、全部従っておけばいいってのもどうかと思う。
おかしいと思うのなら時間をかけて説得するのも一つの手。
話が極端すぎるんだよ。

**デフォルトの名無しさん** · 2018/01/15(月) 13:55:34.30

人間、数回の経験ですべてがそうであると錯覚しやすいからねー
特に失敗は記憶に残りやすい（将来に活かせるとは言ってない）

**デフォルトの名無しさん** · 2018/01/15(月) 14:29:56.48

ところで全く話変わるんだけど。
最近Rustの勉強をしてるんだけど、まだ慣れないし、C++もあまりやってこなかったので、
俺のバカな頭じゃ理解できないことがいっぱいあるから誰か教えて。

質問1
Rustってimmutable参照は複数持てるけど、mutable参照は1つしか持てない決まりになってるよね。
それってたぶんマルチスレッドのことを考えてそうなってるんだよね？(この時点ですでに勘違いしてる？)
けどRustではSyncトレイトとSendトレイトを実装してない限り、スレッド間で変数の受け渡しできないんだよね？
これって逆に言えばSyncとSendを実装してない場合はシングルスレッドなんだからmutable参照が複数あっても問題ないんじゃないの？
なんでマルチスレッドを全く使わないコードを書いてる時でもmutable参照は1つだけしか使えないの？
SyncトレイトとSendトレイトについてなんか勘違いしてる？

質問2
Rustで木構造やグラフ構造を定義する時に循環参照(子が親の参照を持ちたいとか)する時って、たぶんRcとWeakを使うことになるよね？
そして木構造を可変にしたいときはさらにRc<RefCell<T>>って形になるよね？
このRefCell使うとボローチェッカの制約をコンパイルエラーじゃなくて実行時にパニックするように変わるんだよね？
こうするしかないのはRc<RefCell<T>>使わずに木構造を作ろうとして執行錯誤したけど無理だったからそうするしかないんだなと思って納得したんだけど、
RefCell使っちゃうとボローチェッカが効かなくなるからせっかくRustを使ってるメリットが無くなったような気がしてくるんだよね。
それでもRustを使うメリットって何？
RefCell使ってるとこ以外はボローチェッカが効くんだからunsafeコードと同じようにラッパーで包んでやれば上位層に悪影響は出ないよねってこと？
それともC++とかで同じように木構造を作ると、Rustだと単純にパニックするだけだけど、C++だとデバッグがメチャクチャ困難なバグになったりするの？
たとえRefCellを使っていたとしてもRustを使うメリットはしっかりあるんだって思える明確な理由を誰か教えて。

この言語やってるともしかして俺ってすっげーバカなの？って不安になってくる。
長文すいませんが、誰か教えてください。

**デフォルトの名無しさん** · 2018/01/15(月) 14:49:21.64

Rustなんて使った時点で騙されてる
その辺は言語設計が破綻してる証拠
悪いこと言わんからC++きちんと勉強してRustは忘れよう

**デフォルトの名無しさん** · 2018/01/15(月) 15:28:44.95

>>688
君ははた迷惑な例のアンチかな？
破綻している証拠とやらをその辺はとか適当な言葉で誤魔化してる時点で説得力がないよ。
てか、君には聞いていない。君以外に聞いてるんだ。

**デフォルトの名無しさん** · 2018/01/15(月) 16:35:55.57

木構造にRcは要らんだろ
各ノードは直接の親にしか所有されないんだから

**デフォルトの名無しさん** · 2018/01/15(月) 17:21:29.47

質問1について分かりやすいのがforループだな
あるベクタをforループ中に、forの対象にしてるベクタそのものにpushするみたいな黒魔術操作を禁止するために
forループを回してる間は回す対象の配列にイミュータブル参照を作ってる状態にしてコンパイラにチェックさせる

**デフォルトの名無しさん** · 2018/01/15(月) 17:44:57.62

質問1がそうなっている理由は、以下のようなケースで解放済みのVecにアクセスしてしまうことを防ぐというのもある
let mut foo = Some(vec![]);
let foo_mut = &mut foo;
let foo_ref = foo.as_ref().unwrap();
foo_mut = None;
println!("{:?}", foo_ref); // drop 済みのVecへのアクセス

**デフォルトの名無しさん** · 2018/01/15(月) 19:10:45.82

重箱の隅だが四行目は
*foo_mut = None
だな

**デフォルトの名無しさん** · 2018/01/15(月) 20:48:46.10

>>691, >>692
なるほど。mutable参照が1つしか取れない理由はマルチスレッド以外にも理由があったのか。
単純なコードだけど実際に示されないと気が付けないな。(少なくとも俺は)
やっぱりGC無しの言語はメモリ管理が難しいな。
そして、それをコンパイラがはじいてくれるのはやっぱり有難い。
納得のいく答えが得られた。教えてくれてありがとう。

>>690
それは木構造でも親から子を辿るだけで済む場合に限定されない？子から親を辿りたくなった場合だと無理じゃない？
子は複数いるんだからそれぞれの子が全て親のmutable参照を持つことはできないよね。
だって、mutable参照は1つしか作れないんだから。
そうするとRcとWeakとRefCellを使わざるを得なくなるよね？ならない？使わなくても済む方法があるの？
ちなみにRcじゃなくてArenaっていう仕組みを使うって方法ならどっかのブログで見たんだけど、
その方法だと動的に追加していくことは出来るけど、動的に削除を行うことは出来ないよね。
例えばJavaScriptのDomツリーとかはparentNodeで子から親のNodeを辿れるようになってるし、
appendChildとかremoveChildとかでNodeを動的に追加したり削除したりももちろん出来るよね。
それと同じようなことをRustでもしたかったらRcとWeakとRefCellを使うしかないんじゃないかと思ってるんだけど。

**デフォルトの名無しさん** · 2018/01/15(月) 20:53:28.00

双方向参照する場合はそう

RefCell使わなければならないケースでrustの方がうれしいのは、
実行時にはなってしまうが&mutのエイリアスがチェックされることかな
C++だと領域破壊してもそれらしく動いてしまうとかあり得てバグの発見が遅れる

**デフォルトの名無しさん** · 2018/01/16(火) 05:17:55.44

Rustで木を作ったぞ!

https://play.rust-lang.org/?gist=dc4c67944190cb7ab83b2e25e4fdd4e2&;version=stable

**デフォルトの名無しさん** · 2018/01/16(火) 12:11:08.60

https://news.mynavi.jp/article/20180110-568199/
モジラ工作員ざまあ！！！wwwww
いやー一年は工作でごまかせたかもしれないがさすがにメッキが剥げてきたね！
これが現実！！
騙されてるやつはまだ間に合うぞ！

**デフォルトの名無しさん** · 2018/01/16(火) 12:21:19.07

>>697 ……
https://qiita.com/kmizu/items/b07f1dcad63f104248c5

**デフォルトの名無しさん** · 2018/01/16(火) 13:02:13.48

>>698
どや顔で貼ったんだろうけど
記事内でリンクあるランキングでのRustの位置wwwwwwwwwwww
Rustのゴミさの補強にしかなってないwwwwww