プログラミング言語 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/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過ぎてマージされてるんだよなあ

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

誰か3行で

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

rustの三文字文化好き
mut, str, len, vec, rev

**デフォルトの名無しさん** · 2017/09/23(土) 13:46:38.85

変数名にしたかったのを予約しやがって！でもある

**デフォルトの名無しさん** · 2017/09/23(土) 14:49:56.77

Contextual keywordって書いてある

**デフォルトの名無しさん** · 2017/09/23(土) 15:11:25.15

let str = "Hello";
let str: &str = str;

これで普通にコンパイル通るしな。
変数名に出来ないのは>>872の中じゃ mut だけだろう。

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

str, len, rev
あたりは変数名として結構使うかな。
str , vec あたりは s, v くらい短くすることもある。

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

比較演算子 ==, <, > 等って、同じ型同士でしか定義できないのか

**デフォルトの名無しさん** · 2017/09/24(日) 20:16:16.24

それはEqとOrdの話でしょ
PartialEqとPartialOrdは別の型同士でも定義できる

**デフォルトの名無しさん** · 2017/09/24(日) 20:38:52.59

あ、ホントだ。出来たわありがとう。

use std::cmp::PartialEq;

struct Foo(i32);

impl PartialEq<i32> for Foo {
fn eq(&self, other: &i32) -> bool {
self.0 == *other
}
}

**デフォルトの名無しさん** · 2017/09/27(水) 15:23:55.91

Firefox Quantumリリースだってよ

**デフォルトの名無しさん** · 2017/09/27(水) 23:11:15.94

Rust 1.20、関連定数などを追加
https://www.infoq.com/jp/news/2017/09/rust-1-20-released

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

時報が壊れたと思ってたら、常時一ヶ月遅れの情報サイトをソースに時刻通知がきたよ
本人じゃなく模倣者だろうけど次回からは一次ソースのサイトをトリガーにしような！

**デフォルトの名無しさん** · 2017/09/28(木) 00:30:16.29

何でこの人こんなに怒ってるんだろ？

**デフォルトの名無しさん** · 2017/09/28(木) 00:53:16.99

1. 時報が壊れたことに怒っている
2. 一ヶ月遅れのinfoqをソースにしたことを怒っている
3. 模倣者であることに怒っている
4. その他

どれだと思う？

**デフォルトの名無しさん** · 2017/09/28(木) 02:25:57.30

一ヶ月入院でもしてたんだろ
許してやれ

**デフォルトの名無しさん** · 2017/09/29(金) 10:21:58.71

CもObjCもここ数年は仕様変更がないから、コンパイルはそのまま通る。
変なコード書いてなければ動作確認も問題なくパスする。
メンテナンスフリーって言われれば確かにそうかもな。

あとはフレームワークで非推奨にになったメソッド書き換える程度だけど、
これはSwiftと共通の作業だし、そもそもやらなくても動く。
とにかくSwift移行していない俺は毎年高みの見物してる。

**デフォルトの名無しさん** · 2017/09/29(金) 10:22:21.88

すまん誤爆した

**デフォルトの名無しさん** · 2017/09/29(金) 11:26:40.22

これが小学生のおっぱいかよ・・・
12歳の乳とは思えんな・・・

**デフォルトの名無しさん** · 2017/09/29(金) 11:51:24.12

誤爆しすぎだろ。

**デフォルトの名無しさん** · 2017/09/29(金) 22:06:45.55

rustの前にc++とhaskellぐらいはやっておくべき？

**デフォルトの名無しさん** · 2017/09/29(金) 23:43:36.68

C++なんてやらんでいい。haskellよりOCaml寄りじゃね？

C++よりメモリ周りが「javaからgcとロック付きオブジェクトとモニタと
並列ライブラリがなくなった」代わりに低レベルなマルチスレッドコード書けば
型システムが守ってくれるモノが近い。

**デフォルトの名無しさん** · 2017/09/30(土) 00:20:49.42

所有権の概念はC++のmove semantics回りが近いと思うけどな
まあゲーム作るとかじゃなければわざわざC++やらなくてもいいと思うけど

**デフォルトの名無しさん** · 2017/09/30(土) 22:05:33.32

Rust言語による第一プロダクトのFirefox Quantumですが
ベータ版リリースの時点でアドオンがお亡くなりになったとか、不安定でどうしようもないとか、メモリ食い潰して落ちるとか
様々なお声が聞こえてきますね

これがRustという安全な言語で作ったプロダクトなんですってね
おめでとうございますモジラ信者と工作員の皆様

**デフォルトの名無しさん** · 2017/09/30(土) 22:25:31.06

アドオンが不安定ってのはRust関係なくね？

**デフォルトの名無しさん** · 2017/09/30(土) 22:38:45.63

ベータ版の意味も知らないガイジやんけ
ガガイのガイｗ

**デフォルトの名無しさん** · 2017/09/30(土) 22:39:37.33

あそれあそれガイジが出た出たよよいのよいｗ

**デフォルトの名無しさん** · 2017/10/01(日) 00:00:05.60

>>894
API鞍替えのせいだから全く関係ない。
メモリも関係ないし、むしろ最近はバージョン上がるたびに消費メモリ減ってる。
というかパフォーマンス良くなったのは設計が変わったからで言語は関係ない。
言語関係する部分はC++よりマシだから書きやすくなったこと。

**デフォルトの名無しさん** · 2017/10/01(日) 00:42:35.99

>>897
設計の変更って具体的に何を変えたの？マルチスレッドに強いとか？gpuぜんていとか？

**デフォルトの名無しさん** · 2017/10/01(日) 23:58:38.97

>>898
HTMLの描画周りがマルチスレッド前提になっただけよ。
シングル前提でやるとHTML/CSSパース、DOM構築で同期取りまくりが減っただけ。
うちのmem 4g, 2core環境だとハードが足引っ張ってたから多分mem 8g, 4coreくらい要ると思う。
ここ数年のロースペックマシン以上が恩恵受けるんじゃ？
gpu前提はwebrenderだからまだ入ってないんじゃない。

**デフォルトの名無しさん** · 2017/10/02(月) 00:20:10.84

あ、悪い。webrenderもう入ってるわ。
webrenderとstyloが入ってるからもうマルチスレッドにgpu前提。

**デフォルトの名無しさん** · 2017/10/02(月) 11:21:20.04

Firefox爆速化件だけど、あのタイミングでRust化してればRustにも一気に注目集まったのにな。
もったいないな。

**デフォルトの名無しさん** · 2017/10/02(月) 14:16:58.24

w3mの代替になるコンソールブラウザがほしいところ

**デフォルトの名無しさん** · 2017/10/04(水) 00:06:33.86

lynks、links、EWW(Emacs)ではいかんかった？

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

それよりAmayaの後継をwhatwgに作って欲しい

**デフォルトの名無しさん** · 2017/10/04(水) 09:33:38.58

>>901
cssはrustになったんだよね？

**デフォルトの名無しさん** · 2017/10/04(水) 17:45:04.59

FizzBuzz を無駄にベンチマークしてみた By Nim、golang、Rust、Crystal、その他
http://wolfbash.hateblo.jp/entry/2017/07/25/232027

**デフォルトの名無しさん** · 2017/10/04(水) 19:54:27.21

なんというか、、参考にならないベンチマークだな。

**デフォルトの名無しさん** · 2017/10/04(水) 23:17:46.14

参考になるベンチマーク教えてくれ

**デフォルトの名無しさん** · 2017/10/05(木) 00:04:55.49

http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide
ここの諸々

久しぶりに見たらC gccがついに抜き返しててワロタ
C言語、頑張ったじゃん

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

>>909
6パターンだった頃は全部実行出来てたけど速度はバラバラでたしか#5が最速でC言語より速かった
きっと最適化を人間が制御するのは難しくて頑張らないとJavaやC#にも勝てない
現在7パターンあるけど4つがmake errorになるくらい言語仕様が不安定

実に参考になる

**デフォルトの名無しさん** · 2017/10/05(木) 02:42:46.62

>>909
mem順にしてもgz順にしてもcpu順にしてもD言語出てこないの悲しいな

**デフォルトの名無しさん** · 2017/10/05(木) 04:56:45.53

d言語のメリットって何？

**デフォルトの名無しさん** · 2017/10/05(木) 06:07:45.62

C++ではないこと

**デフォルトの名無しさん** · 2017/10/05(木) 09:06:46.27

>>910
人間が頑張って最適化した結果、C gccが上回ったんじゃないのかね

D言語はプログラミング人口少ないから・・・
2000年代の流行った頃ならもうちょっとスコアが出てたんじゃないかな

**デフォルトの名無しさん** · 2017/10/05(木) 10:18:07.23

RustもJavaも血反吐吐くほど最適化してるんじゃないの？
ポインタ扱いにくい言語でそれやると逆にコードが汚くなるから、
C言語よりも酷いコードになってるかもしれんよ。

**デフォルトの名無しさん** · 2017/10/05(木) 10:41:40.98

unsafe使ったらRustは更に早くなるのか・・・胸熱
取り敢えず、各コードを読んでから批評してはどうか

本家Rust Teamが改修して今のスコアだけど
彼らが直したのはI/Oにバッファ使おうぜってだけでそこまで変態的じゃないのよね
matchやmap, iterでクロージャー多用してるけど最適化コンパイルしたらif, forで書くのと同じ処理になるし

Option.mapは関数コールがあるから重たいかなと以前調べたら
LLVM中間コードの時点でインラインのif分岐(goto文)に展開されてベタコードと同じになるのかよと考えるのやめた

**デフォルトの名無しさん** · 2017/10/05(木) 11:26:31.98

>>909
C gcc 5.38
Rust #7 5.56
C++ g++ #3 7.18
Java 8.38

↑この並びでみると、Rustの速さよりもむしろJavaの意外な速さに驚く

**デフォルトの名無しさん** · 2017/10/05(木) 12:31:31.21

ぼくも同じこと思った…

**デフォルトの名無しさん** · 2017/10/05(木) 12:49:03.43

Javaは実行時最適化がはまれば速い感じ
でも、カリカリにチューニングされたJavaコードは、クラスをあまり使わずArrayだらけだっりしてつらい

**デフォルトの名無しさん** · 2017/10/05(木) 17:58:39.05

rlsもっと頑張って
replも提供して😭

**デフォルトの名無しさん** · 2017/10/05(木) 18:51:45.79

C言語の __func__ みたいなの無いのかよ～

**デフォルトの名無しさん** · 2017/10/05(木) 23:04:07.77

Javaやら.NET等のJIT系言語は速い速い言われるけど実際のアプリケーションでその速さを体感できたことは一度もないや・・・

**デフォルトの名無しさん** · 2017/10/05(木) 23:35:19.66

>>909
rust#7はrayon使ってるから中身はcocoとfutureか。
ライブラリが頑張ってzero cost抽象化が効いてる感じかね。

javaはもうちょっと早くなるんだけどなぁ。
これ以上やるとjitとライブラリに丸投げして素直なコード書くことに
専念できなくなるからやりたくない感じ。
将来的にはconst arrayと、勝手にSIMD使ってもうちょっとマシになるかな。

>>919
連続してることが保証されないからカリカリにチューニングする時は配列には頼らないよ。
nio buffer使うことはあるけど。unsafe使わずに配列確保すると0クリアされて無駄に遅いし。
仮想関数テーブルなくしたほうが速いからメソッド検索>invokestaticのコストの時staticに変えるとか、
動的ディスパッチ自分で実装するときにconstant specific class bodyとtable switch組み合わせるとか。

>>921
ないけどrpすればすぐに入りそう。

**デフォルトの名無しさん** · 2017/10/06(金) 00:32:27.39

>>923
>連続してることが保証されないから

それはもはやデータ構造として「配列」と呼ばれるものではないのでは……

**デフォルトの名無しさん** · 2017/10/06(金) 00:59:19.34

Dは仕様変更が多すぎた

**デフォルトの名無しさん** · 2017/10/06(金) 01:12:44.86

>>923
javaの配列って連続領域の保証されてないの？

**デフォルトの名無しさん** · 2017/10/06(金) 11:58:56.15

スレチだけど、JVMの実装仕様なんてベンダー依存でしょ, OracleとGoogleでも当然違うわ

**デフォルトの名無しさん** · 2017/10/06(金) 22:14:03.16

だから言語として仕様化されてないの？ってことだろ。
c++だって実装バラバラだけど連続領域な仕様だろ。

**デフォルトの名無しさん** · 2017/10/06(金) 22:51:58.93

Cはポインタ I/F仕様に引きづられて配列仕様も必然として明確にせざる得ないからでしょ
JVMはbyte codeの解釈さえあってれば良くて、データ操作の実装仕様は知るかよって話だよ
VM上では連続領域に見せかけても、実態は数チャンクに分けた配列の持ち方だってあろうよ

**デフォルトの名無しさん** · 2017/10/07(土) 00:56:21.68

いやだから、データ構造としての「配列」のデータ操作の時間空間コストと
実装がズレてたらそれはもう「配列」じゃないから

**デフォルトの名無しさん** · 2017/10/07(土) 02:30:16.92

一般的に配列と呼ばれるオブジェクトがメモリアドレス上でも断片化しないことを保証される処理系ってほとんど無いのでは？
ミュータブルオブジェクトへ要素を継ぎ足していったらコードからは連続的に見えてもメモリ配置は断片化するだろう

**デフォルトの名無しさん** · 2017/10/07(土) 04:32:31.86

「要素を継ぎ足していったら」がそもそもオカシイ
要素継ぎ足せるのはそもそも配列じゃなくてロープかなんかだから

**デフォルトの名無しさん** · 2017/10/07(土) 08:20:38.57

配列の要件ってインデックスで要素にアクセスすることくらいじゃないの？
要素のポインタをとって操作できる言語以外は実際の記憶領域が連続かそうでないか
判断する術はないと思うが。

**デフォルトの名無しさん** · 2017/10/07(土) 08:39:14.98

ポインタ操作だって処理系依存でどんな変態実装も理論上はあり得ると思うけど
C/C++の仕様を調べる気力がない

**デフォルトの名無しさん** · 2017/10/07(土) 09:54:16.89

>>933
> 配列の要件ってインデックスで要素にアクセスすることくらいじゃないの？

じゃリンクリストでもいいってわけ？
インデックス操作は内部でポインタたどってさ。

**デフォルトの名無しさん** · 2017/10/07(土) 12:18:14.74

配列だとインデックスのアクセスにO(1)を期待してるが
それが保証できるのかという話じゃないの