プログラミング言語 Rust 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/05/21(日) 14:04:29.55

Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。

http://www.rust-lang.org/
https://github.com/rust-lang/rust

Servo
https://servo.org/
https://github.com/servo/servo

◆前スレ
プログラミング言語 Rust 2
http://echo.2ch.net/test/read.cgi/tech/1478023960

**デフォルトの名無しさん** · 2017/09/10(日) 16:53:04.07

>>770
木構造の一番いいサンプルおしえてよ

**デフォルトの名無しさん** · 2017/09/10(日) 21:30:15.59

木にせよ一般のグラフにせよライフタイム管理が面倒くさい

**デフォルトの名無しさん** · 2017/09/10(日) 22:30:44.85

この辺とか？
http://agtn.hatenablog.com/entry/2017/01/16/151745
ただ入れる操作によっても RefCell にしたり、やっぱり面倒は面倒。

**デフォルトの名無しさん** · 2017/09/11(月) 00:36:42.39

ぐええ、隣接リストとアリーナの違いがよく分からない

**デフォルトの名無しさん** · 2017/09/11(月) 06:43:38.80

768はこれがまともじゃないっていいたかったんでしょ。

**デフォルトの名無しさん** · 2017/09/11(月) 10:26:55.85

CやC++ならポインタ持っておくだけで簡単に実現できるのに……

**デフォルトの名無しさん** · 2017/09/11(月) 23:14:03.66

C++使うか、unsafe使えば良いのでは

**デフォルトの名無しさん** · 2017/09/11(月) 23:14:47.15

Rc+RefCellな型を用意するだけでもマシになるか

**デフォルトの名無しさん** · 2017/09/12(火) 00:26:37.00

ていうか練習ならともかく実際に使うプログラムでポインタをつないでグラフを表現することなんてそんなに頻繁にあるか？
取りうる表現の中で効率性が最悪な部類じゃん
Vecに対するLinkedListみたいなもんだろこれ

**デフォルトの名無しさん** · 2017/09/12(火) 01:20:27.09

オブジェクト指向っぽいAPIを触るときはだいたいその形にならない？

**デフォルトの名無しさん** · 2017/09/12(火) 03:08:23.10

グラフの時だけ、ガベコレ使えるGc型が欲しい

**デフォルトの名無しさん** · 2017/09/12(火) 08:30:34.06

じゃああんたは現実世界でツリー構造のものをどうやって表すの？

**デフォルトの名無しさん** · 2017/09/12(火) 11:30:27.08

>>779
VecじゃなくあえてLinkedList使う場面普通にあるんだが……

**デフォルトの名無しさん** · 2017/09/12(火) 14:48:49.21

linux の赤黒木の実装はポインタベースではあったな。
しかし個人的には配列実装のが結局速いって気はする。

**デフォルトの名無しさん** · 2017/09/12(火) 15:07:56.52

Effective Hogeでそういうことは言及されてるけど
Rustはどうだかなとドキュメント見たらSecond Editionで"Effective Rust"の節自体が削られとる:-(
Stack vs Heapはどこかに記述されてた覚えがあるから、ツリー/リスト操作もどこかに潜り込んでるのかなぁ

**デフォルトの名無しさん** · 2017/09/12(火) 17:41:48.32

配列ベースの実装はポインタの代わりにindex使うだけだからできることはあんまり変わらんわな
配列の方がデータの局所性高そうで速そうではある

**デフォルトの名無しさん** · 2017/09/12(火) 18:02:30.56

データ構造によって速い操作が違うという基本的な概念がない奴おるな

**デフォルトの名無しさん** · 2017/09/12(火) 18:50:57.82

vectorのmutabilityの問題があるの理解できてる？

**デフォルトの名無しさん** · 2017/09/12(火) 18:53:28.85

>>779
効率ってなんの効率？

**デフォルトの名無しさん** · 2017/09/12(火) 22:05:08.25

>>787
まあそういう無能がありがたがる言語なんだろうなRust

**デフォルトの名無しさん** · 2017/09/12(火) 22:20:04.05

mutabilityはRefCell使えば良いのでは
Refcell使わずにVecの中身を直接触る必要ある？

**デフォルトの名無しさん** · 2017/09/12(火) 22:27:17.20

>>791
いや、それでいいかも
rcさえなくなればborrowをユーザに書かせなくてすむからそれでいいや

**デフォルトの名無しさん** · 2017/09/13(水) 14:03:19.87

低レイヤーできます！ってアピールしたい言語なんだろうけれど、
あんま向いてない言語な気はする。

**デフォルトの名無しさん** · 2017/09/13(水) 14:56:53.13

低レイヤを書くにはチェッカーが強すぎて邪魔で、高レイヤを書くには全くカジュアルさがない
どっちにもなれない哀れな言語よ

**デフォルトの名無しさん** · 2017/09/13(水) 18:10:30.60

並列で大規模で低レイヤーな領域に向いた言語だからどれか一つでも欠けてる領域で使いづらいと思うのは仕方ない

**デフォルトの名無しさん** · 2017/09/13(水) 20:06:39.58

低レイヤーはやっぱC言語だな。
ポインタの習得が難しい事以外に欠点ないじゃんこの言語。
Rustはもっとポインタ扱いやすくして出直してきな。

**デフォルトの名無しさん** · 2017/09/13(水) 20:42:07.11

rustの並列処理って言うほど特化(最適化)されてる気はしないけどな・・・
スレッド跨いだオブジェクトの所有権譲渡も保障されてはいるけど、従来言語/ライブラリに比べてめっちゃ便利という感じはしない
futures-awaitとかyieldを使うと変わるのかねぇ、無くても困りはしないしと使ってないけどfutures-awaitは使ってみるかな

**デフォルトの名無しさん** · 2017/09/13(水) 20:42:42.41

C だっていろいろ批判はあるだろ。
型がゆるいとか、名前空間がグローバルしかないとか。
まあそれを差し引いてもやっぱ有効な言語と思うけど。

**デフォルトの名無しさん** · 2017/09/13(水) 20:49:43.29

>>798
Rustのコンパイル通す実力あるならCのその辺りの問題なんてないものと同じだから
Rustなんて使わずCでいいじゃんってなるんだよな

**デフォルトの名無しさん** · 2017/09/13(水) 20:52:03.57

とか思ってたら、yieldの方が公式nightlyにマージされたのか
futures-awaitもnightly要求するし素直にyieldの方を使ってみよ, stableにはいつ来るのかなぁ

**デフォルトの名無しさん** · 2017/09/13(水) 21:19:48.43

今さら C はねえよ

**デフォルトの名無しさん** · 2017/09/13(水) 21:41:03.71

>>801
Rustよりはあるわ

**デフォルトの名無しさん** · 2017/09/13(水) 21:54:04.29

ID:6DzbMbn9っていつものモジラ/Rustネガキャン君だろ

**デフォルトの名無しさん** · 2017/09/13(水) 21:57:53.87

>>803
さすがにあのレベルの基地と一緒にされるのは心外

**デフォルトの名無しさん** · 2017/09/13(水) 22:09:43.33

いつものコンパイル通らなくて発狂してる基地外かと思ったわ

**デフォルトの名無しさん** · 2017/09/13(水) 22:45:06.07

コンパイラーよりも自分が信用できるならC使えばよいと思う

**デフォルトの名無しさん** · 2017/09/13(水) 23:56:44.36

Rustのコンパイルが通るならCを使えば良い君まだいたのか
自分の言葉通りRustに拘わらずにCを使っていれば良いのに

**デフォルトの名無しさん** · 2017/09/14(木) 08:18:50.41

macro_rules! make_macro {
($id:ident) => (
macro_rules! concat_idents!{test_, $id} {
}
);
}
make_macro!{foo}

こういうの無理なのか。

**デフォルトの名無しさん** · 2017/09/14(木) 11:10:13.14

EmacsでRLS使ってる人居る？

**デフォルトの名無しさん** · 2017/09/14(木) 11:12:19.23

>>799
そういう根性論嫌い

**デフォルトの名無しさん** · 2017/09/14(木) 12:55:00.43

RustやSwiftとかの次世代言語ってOracle製品やSAPみたいな所あるよな。
無駄に抽象化して変な専門用語作って、プリミティブなエンジニアを寄せ付けない感じとか。

コマンドラインで一発で出来るようなことを、独自用語だらけのGUIでポチポチ操作させてんの。
こういう文化は本当に良くない。優秀なエンジニアはみんな逃げてしまう。

**デフォルトの名無しさん** · 2017/09/14(木) 13:54:06.68

>>810
コンパイル時に全部解決しなきゃいかん
てな話のがよっぽど根性論だと思うが。

**デフォルトの名無しさん** · 2017/09/14(木) 17:19:47.64

人間が気をつけてコードを書けばバグが出ないはずというのは根性論では

**デフォルトの名無しさん** · 2017/09/14(木) 18:36:21.42

人に依存するC/C++は日本的
システムが面倒を見てくれるRustはアメリカ的

**デフォルトの名無しさん** · 2017/09/14(木) 19:05:26.17

バグが出ないことよりも手法に熱中しちゃう方が日本的だなとか思っちゃうけど。

**デフォルトの名無しさん** · 2017/09/14(木) 19:14:58.28

形容詞化する国名

**デフォルトの名無しさん** · 2017/09/14(木) 20:08:31.29

～的ってつければなんだって形容詞になるの？

人に依存するC/C++はC/C++的
システムが面倒を見てくれるRustはRust的

**デフォルトの名無しさん** · 2017/09/14(木) 21:28:39.91

C/C++でもバグが出ないほど規模が小さい or 言語への習熟度が高いならC/C++使えばよいし
そうじゃないならRust使えば良いとしか言ってないのだが

**デフォルトの名無しさん** · 2017/09/14(木) 21:51:38.65

単純に「巡回グラフを始めとした自己再帰型のデータ構造を書き下せない（コンパイラが通してくれない）」って時点で、書けないプログラムの存在を認めてしまってるんだよなRustは

その上C言語にはValgrindやらcppcheckやら、金かかっていいならCoverityやら、いくらでもその手のツールはあるわけで、
Rustならではの点ってどこにもない割に欠点だけ目立つ訳よ

肝心の抽象化も機能足りてないしな。Nightly使えばなんぼかマシだが

**デフォルトの名無しさん** · 2017/09/15(金) 00:12:38.69

どうしても全部Rustだけで実装したいのか

**デフォルトの名無しさん** · 2017/09/15(金) 00:29:00.00

△全部Rustだけ
◯全部safe Rustだけ
Escape hatchの類は使いたくないというsafe Rust信仰の裏返しというツンデレなのでは

**デフォルトの名無しさん** · 2017/09/15(金) 01:05:02.21

How can I implement a graph or other data structure that contains cycles?
https://www.rust-lang.org/en-US/faq.html#how-can-i-implement-a-data-structure-that-contains-cycles

**デフォルトの名無しさん** · 2017/09/15(金) 13:00:11.59

できるできないレベルの話をしているのか、やりやすいやりにくいレベルの話をしているのかどっち

**デフォルトの名無しさん** · 2017/09/15(金) 13:25:48.45

できない => できるよ => やりにくい => そうねー => 応答終了, 最初に戻る

こんなのをずっと繰り返してるイメージだ
モジラ/Rustネガキャン君とRustのコンパイルが通るならCを使えば良い君の二人なのかな
二人とも長いこといるし、コンパイル通せないRustが相当憎いんだろうなぁと思ってる

**デフォルトの名無しさん** · 2017/09/15(金) 23:54:50.13

Cだって肝になるところをアセンブリで書くのはまれによくあることだし、
Rustで書きにくいところをCで書いたっていいよな

**デフォルトの名無しさん** · 2017/09/16(土) 02:17:34.76

Rustのコンパイルが通るならCを使えば良い君は、暗黙のうちにCで完全なメモリ管理を行うことの困難さを訴えているんだよきっと

**デフォルトの名無しさん** · 2017/09/16(土) 06:49:34.00

変な人がわくほどメジャーな言語になったんだなぁ

**デフォルトの名無しさん** · 2017/09/16(土) 12:21:42.89

てか細かいとこ C で書いてあとは軽い言語から呼ぶとか普通してるじゃん。
一つの言語で無理やりやろうとするからどっちつかずになるんじゃないのかね。

**デフォルトの名無しさん** · 2017/09/16(土) 12:23:12.97

>>828
RustがC(++)の後継目指してるとか言わなきゃこんなに言わんよ

**デフォルトの名無しさん** · 2017/09/16(土) 17:33:19.57

C(++)の座が奪われると危機感を感じて
「Rustのコンパイルが通るならCを使えば良い」と必死なのかw
置き換わるにはまだまだ先が長いから安心して自分の巣にお帰りに

**デフォルトの名無しさん** · 2017/09/16(土) 17:34:53.66

Rustのコンパイルが通るならCを使えば良い（自分はできるとは言っていない）

**デフォルトの名無しさん** · 2017/09/16(土) 20:08:37.91

実際に使ってる人たちは本当にいつかRustがC(++)に置き換わると思ってるの？

**デフォルトの名無しさん** · 2017/09/17(日) 00:38:06.21

RustがC/C++の後継目指してるなんて公言してるのか

**デフォルトの名無しさん** · 2017/09/17(日) 09:53:24.02

一応Goもc++の置き換えを想定した言語らしい。もっともgoogle社内の話だが

**デフォルトの名無しさん** · 2017/09/17(日) 12:44:11.46

>>830
×まだまだ先が長い ○先にモジカスが世界から消滅する
先が長いとか言ってる時点でモジカスのステマに荷担してると理解しろ

Rustがプログラミング言語を名乗ってるのはモジラが自由をお題目にしてるのと同じレベルの害悪だ

**デフォルトの名無しさん** · 2017/09/17(日) 15:13:14.19

複数のResultのNGをXORでまとめて(途中match分岐入れず)処理するのてどうすればいい？
超極稀に失敗する変な返り値を格納しても副作用の無い処理の連なりをゴソっと捨てる方法

**デフォルトの名無しさん** · 2017/09/17(日) 16:26:31.76

>>833
少なくとも firefox の c/c++ 部分の書き換えを想定してるだろう。
まあ c/c++ と一口に言っても結構レイヤーは広いように思う。
てきとうなサーバープロセスなら確かに go は書きやすいよ。
rust にそういうエリアがあると思えんというところが問題の焦点じゃないかね。

**デフォルトの名無しさん** · 2017/09/17(日) 17:40:27.30

>>836
求めてるものかどうかわからんが、Iterator<Item=Result<t, E>>はcollectでResult<Vec<T> , E>などにできる

**デフォルトの名無しさん** · 2017/09/17(日) 19:45:22.12

相当雑いけど>>838の実装例はこんな感じかな
ttps://play.rust-lang.org/?gist=c87421997c42f0dfa8aa6ecabbb7ba3b&version=stable

性能を突き詰めるならcollectしないでfilterの戻りをnextで回すべきだけど適当に
確か100万回くらい回したら数秒の差が出るくらいのはず

**デフォルトの名無しさん** · 2017/09/17(日) 23:03:20.12

>>839
そういや、こうやって変数のシャドウイングを積極的に使っていくのってどうなんだろうな？
俺はよくやってるけど、スタイルにうるさい人から怒られるかもとか思ったり

**デフォルトの名無しさん** · 2017/09/17(日) 23:17:40.08

>>839
https://play.rust-lang.org/?gist=4f2e38dd8570a14eb1801137a183e40d&;version=stable
こういう途中Errがいたら戻り値もErr、全部OkならOk<colletion>な意図だった

**デフォルトの名無しさん** · 2017/09/17(日) 23:18:40.79

collectも#inlineついてるなら手でfor書くのと同じになりそうだけど遅くなるのか
ExactSizeIteratorとただのIteratorで違うとかならわかるんだが

**デフォルトの名無しさん** · 2017/09/17(日) 23:25:16.47

OCamlだと普通なんで読みにくさを感じたことは無いなあ
むしろその変数はそこで終わりです、もう頭に入れとかなくても良いよってことだから脳にやさしいとまで感じる

**デフォルトの名無しさん** · 2017/09/18(月) 08:30:10.39

>>842
collectの関数コールは最適化されて消えるけど、collect内でVectorを作る分があるからな
メモリ確保して、要素をコピーしてって誤差程度だけどコストが乗っかる

filterまでだとFilterは作るけど要素のコピーはしてない感じだったから
他言語, 他ライブラリのfilterメソッドの戻りで配列/リストを作り直すIF/実装に比べて比較的早そうだと思った

**デフォルトの名無しさん** · 2017/09/18(月) 11:26:55.19

なるほど、Vec作るコストという意味なら確かにcollectはコスト掛かるね

まとめて処理というのがIteratorの要素からなる配列などのデータ構造を作って何かすると理解していたけど、
そうでないならば
f.map(¦x¦ {do_something(); }).collect::<Result<Vec<()>, _>>()
とすれば作られるのはVec<()>で、要素サイズ0だからヒープからはメモリ割り当てられないはず

これやるぐらいならfor使った方が

**デフォルトの名無しさん** · 2017/09/18(月) 14:28:43.98

一方C言語ならそんな面倒なこと考えずにallocしてforでいい
学習コスト高くて性能も低い言語Rust

**デフォルトの名無しさん** · 2017/09/18(月) 16:37:25.22

alloc？

**デフォルトの名無しさん** · 2017/09/18(月) 17:16:35.57

>>847
mallocとcallocのことをまとめてallocって言うんだがまさかRust民そんなことも知らない？

**デフォルトの名無しさん** · 2017/09/18(月) 17:40:00.45

俺たち、ついさっきまでzero-allocationな実装方針について話してなかったっけ……？

**デフォルトの名無しさん** · 2017/09/18(月) 17:48:40.40

せんせーallocaはallocに含まれますか

**デフォルトの名無しさん** · 2017/09/18(月) 18:07:06.15

定義による
スタックから確保するものと
ヒープから確保するものを
どちらもallocと呼ぶなら含んでる

**デフォルトの名無しさん** · 2017/09/18(月) 18:11:47.24

>>849
ゼロアロケーションつっても最初の一回はallocするだろ？
その後forでナメながら変換すれば単純で早くてコンパイルも通ってモジカス涙目みんな幸せって言ってんの
無駄に難しく考えるモジカスシンパらしい話だな

>>850
非標準関数はNG

**デフォルトの名無しさん** · 2017/09/18(月) 18:15:30.06

基地外って同じ言葉を連呼するからNGし易くて助かる。

**デフォルトの名無しさん** · 2017/09/18(月) 19:17:59.90

要素サイズ0のVecはヒープからメモリ獲得しないと明言したはずなのですが

**デフォルトの名無しさん** · 2017/09/18(月) 19:24:02.49

>>846の書くヒープアロケートするCコードはスタックアロケーションのみのRustコードより高性能なんだよきっと

**デフォルトの名無しさん** · 2017/09/18(月) 19:39:48.02

>>853
造語症っていうんだっけか？

それはそうとRustでCのmallocやcallocと同じ操作ってBoxであってVecではないよなあ。

**デフォルトの名無しさん** · 2017/09/18(月) 19:56:01.80

低級言語で書けばそれだけで性能が良くなるって勘違いはよくあるよな

>>856
どっちもヒープを使ってるから同じでええやろ

**デフォルトの名無しさん** · 2017/09/19(火) 01:46:56.36

話が明後日の方向に行ってるけど
>>844の主点はVecを作るコストではなくVecに要素コピーするコストの方だぞ
filterで除外した要素をcollect内でVecにせっせとコピーするからちょっち時間かかる

ちなみにC(++)でベタに実装するとこんな感じでリスト作成、要素コピーするからドングリの背比べ
std::list<char*> filter_collect(std::list<char*> v) {
std::list<char*> new_v;
for (auto i = v.begin(); i != v.end(); i++) {
if (*i != NULL) {
new_v.push_back(*i);
}
}
return new_v;
}
std::list<char*> v{"Hello", NULL, "World"};
auto new_v = filter_collect(v);

モジラ/Rustネガキャン君とRustのコンパイルが通るならCを使えば良い君が
よりよいCコードを挙げてくれるのをちょっと待ってみようか, 流石にこれは汚すぎる

**デフォルトの名無しさん** · 2017/09/19(火) 01:57:29.08

（そもそもの>>836が何をしたいのかいまいち分かっていないなんて言えない）

**デフォルトの名無しさん** · 2017/09/19(火) 09:23:52.82

これをCというか
いやまあC++としても酷いが

**デフォルトの名無しさん** · 2017/09/19(火) 09:49:54.63

(大丈夫、俺も分かってない...多分>>841さんの実装例が期待コードだったんだろうと匙投げた)

**デフォルトの名無しさん** · 2017/09/19(火) 11:20:24.23

仕様分からないのに実装しようとするRustの文化すげー

**デフォルトの名無しさん** · 2017/09/19(火) 18:29:28.71

そういえばRustってそもそもまだ言語仕様がなかったっけな（RFCが通ってない）

そんな言語を良しとするモジカスとそのお友達

**デフォルトの名無しさん** · 2017/09/20(水) 07:39:00.40

RubyやLua等も商用でも使われているけど公式な言語仕様って存在しなかった気がする

**デフォルトの名無しさん** · 2017/09/20(水) 08:58:49.24

RFCが通るとはどういう意味だろう
まさかIETFの話ではないだろうな

**デフォルトの名無しさん** · 2017/09/20(水) 17:20:54.79

https://github.com/rust-lang/rfcs

**デフォルトの名無しさん** · 2017/09/20(水) 17:30:21.92

https://github.com/rust-lang/rfcs/blob/master/text/2113-dyn-trait-syntax.md
さすがにこのSyntaxはダサいぞ？

**デフォルトの名無しさん** · 2017/09/20(水) 18:24:29.42

どうせならいっそ新しいepochでbare Traitのシンタックスでimpl Traitのセマンティクスを表すように変えて欲しくもあるけれど、motivationでも言われている通り互換性の観点からしてまあ無理だわな
理念には同意できるけど、うーむ……ダサい

**デフォルトの名無しさん** · 2017/09/20(水) 18:24:58.43

じゃあ討論してるIssueに行って、ダセェからこうしようぜって具体例を提案してこい
良さげだったら(y)押してやんよ

**デフォルトの名無しさん** · 2017/09/20(水) 18:39:23.24

これがダサいとかいうならimplとかpubなんてクソの山だろ

>>868
impl Traitのセマンティックスに置き換えたところで例えばVec<Display>にi32とStringを両方突っ込もうとしてエラーになるようなへまをする連中は消えないだろ

>>869
もうFCP過ぎてマージされてるんだよなあ