プログラミング言語 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/05/30(火) 19:07:46.03

まあプロダクションでのパフォーマンスはServoとQuantumが示してくれるでしょ

>>85
Non-lexical lifetime以外よく分からない

**デフォルトの名無しさん** · 2017/05/30(火) 20:40:00.58

Cで書くには煩雑なものを相手にしたときに、
実際Rustがどんだけの結果を出せるか、
というのがみんなの興味だろう。

ちっさいサンプルプログラムみたいなんをコンパイルして、
それでベンチマークテストして結果比較したって、
そんなもんは誰も嬉しくはないし驚きも無い。

オーバーヘッドの一点のみで語りつくせるんなら、
バイナリエディタと機械語でOSだって作れる。
それはオーバーヘッドの無い、最速最軽量だろうね。

**デフォルトの名無しさん** · 2017/05/30(火) 21:45:35.31

librsvgの移植が、中規模コードの実践例として参考になりそう
https://people.gnome.org/~federico/news-2016-10.html#25

**デフォルトの名無しさん** · 2017/05/30(火) 21:54:14.25

free挿入するよりcopying gcの方が速いし
無駄なオーバーヘッドなくそうとしたらlibstdの実装みたいに
raw pointerだらけになるからそんなこと気にしなくていいよ。

jitのおかげでロジックそのまま書いても速いなんてことが
起こらないから将来、最適化は必要になるだろうけど過剰な最適化は必要ない。

抽象度の高いまま低レベルな領域でも書けるからいいんだよ。
javaだと整数型の型を揃えようとするからバイト列の操作とか苦手だけどrustはそういうのないのよ。

**デフォルトの名無しさん** · 2017/05/30(火) 23:04:32.49

>>87
ベンチマークって基本そういう系多いからね
ファイルアクセスとか考えたら速度ほとんど変わらないのに

**デフォルトの名無しさん** · 2017/05/31(水) 01:36:02.83

ベンチマークはオーバーヘッドが無視できるよう(特定)処理を大量回数ループさせてる
という意味が分かってないから、そういうこと言っちゃうんだろうねぇ

もっと勉強しろ、若造どもが

**デフォルトの名無しさん** · 2017/05/31(水) 01:44:33.93

オーダが同じでもオブジェクト生成や関数呼び出し等々のオーバーヘッドは係数部分に効いてるんやで

**デフォルトの名無しさん** · 2017/05/31(水) 02:15:05.25

Rustはzero-cost abstractionだのコンパイラによる関数最適化でC言語とさして変わりないんやで^^
VMだと係数にもろに影響するやがな

**デフォルトの名無しさん** · 2017/05/31(水) 09:42:28.64

>>91
だから若造はいないんだって。
Cとか言い出す老人しかいないの。

**デフォルトの名無しさん** · 2017/05/31(水) 09:46:53.00

>>94
>>78

若者も老人もいるんだよなぁ

**デフォルトの名無しさん** · 2017/05/31(水) 12:19:43.42

本当のおっさんや老害はRustスレなんてこないだろ。
ワイは偉そうに古参風を吹かせてた>>77だがまだビンビンの学生やで。

**デフォルトの名無しさん** · 2017/05/31(水) 12:22:43.65

ワイ周辺だと学生はそれなりに見る
よくはてなブログに書いてる人も学生でしょ

**デフォルトの名無しさん** · 2017/05/31(水) 12:27:53.72

そりゃ、おっさんの大多数は新しい言語が嫌いだからね

**デフォルトの名無しさん** · 2017/05/31(水) 12:38:49.91

それな

**デフォルトの名無しさん** · 2017/05/31(水) 12:55:16.23

年取ると守りに入ってしまっていかんな

**デフォルトの名無しさん** · 2017/05/31(水) 18:15:57.61

まだ2chは若者に人気だったのか
slackとかじゃないの

**デフォルトの名無しさん** · 2017/05/31(水) 23:54:17.31

>>83
ランタイムなんてリンクしなけりゃ済む話

**デフォルトの名無しさん** · 2017/05/31(水) 23:59:15.13

no_stdか……

**デフォルトの名無しさん** · 2017/06/01(木) 10:52:08.55

それランタイムじゃなくライブラリ
no_mangleでマングル名消してもランタイムはリンク解消できないだろうねぇ

**デフォルトの名無しさん** · 2017/06/01(木) 12:56:34.33

#![no_std]すればliballocとlibpanic_unwindはlibstdは勝手に外れなかったっけ？
libcoreはliballocにリンクしていないし#![needs_panic_runtime]もしてない

**デフォルトの名無しさん** · 2017/06/01(木) 13:33:54.90

Rustランタイムって具体的には何してくれるの？
ファイナライザ呼び出しとパニック時のスタックダンプ表示？

**デフォルトの名無しさん** · 2017/06/01(木) 13:39:40.72

ttps://doc.rust-lang.org/book/no-stdlib.html
最小限のmain関数だけにしても、C言語+clangでビルドするバイナリ相当までは削れんなぁ

Rustマングル名の解読とか、C言語へのブリッジなんかも入ってるんでない
str型はno_stdでも使えるようだから、この辺の一部プリミティブ型のラッピングもしてるかな

**デフォルトの名無しさん** · 2017/06/01(木) 14:25:43.96

ランタイム気になるのはOS書く時くらいでしょ

**デフォルトの名無しさん** · 2017/06/01(木) 14:27:32.75

あとOS無しの環境でプログラム動かす時とかもそうだけど
要するにそういうときだけ

**デフォルトの名無しさん** · 2017/06/01(木) 15:23:27.31

その辺の整備は優先度低いだろうからな。
トレイト境界の特殊化とか知恵の輪みたいな型システムのサポートとかもっとやることがある

**デフォルトの名無しさん** · 2017/06/01(木) 15:36:56.97

IoTブームを考えると、組み込み系が一番Rustを活かせる場だと思う
パフォーマンスが良いし、アップデート出来ない環境で脆弱性の心配が減るのも良い
メモリフットポイントも、先行事例を見るにまあぼちぼちなんとかなってるようだ

**デフォルトの名無しさん** · 2017/06/01(木) 16:49:21.04

新興言語が使い物にならないのはSwiftが証明しちゃってるしな。
学習コストが高いし、仕様変更も多すぎて管理コストがかさむ。
仕事では使い物にならない。

IoTはなんだかんだいってバックエンドCフロントエンドECMAScriptが主流になるんじゃないかな。

**デフォルトの名無しさん** · 2017/06/01(木) 16:57:13.59

IoTもう終息してきてない？

**デフォルトの名無しさん** · 2017/06/01(木) 18:07:25.12

マングリングなんかはコンパイル時に解決してるのでは
strはただのデータと長さのペアの構造体
ランタイムとはなんなのか

**デフォルトの名無しさん** · 2017/06/01(木) 18:32:06.24

解決してないから、場合によってはno_mangleが必要なわけでな
プログラムロード時に展開して処理中はオーバーヘッドないだろうけども

IoTブームを考えるとRustの選択肢はありだろうけど
流行りを無視したら性能良く容量少ないバイナリ吐くCかギリギリC++かなぁ
ガチな組み込みは老人ばかりでC/C++で難なく安全なコード書くし
組み込み系の仕事やってると業務での採用提案は現実的には思えんわ

**デフォルトの名無しさん** · 2017/06/01(木) 19:44:54.46

>>115
ガチ組み込みでもC++使うんだ。
自動車とかだとCのみだよね。
家電とか？

**デフォルトの名無しさん** · 2017/06/01(木) 23:17:34.13

>>116
自動車は普通にc++使ってる部分もあるよ。

**デフォルトの名無しさん** · 2017/06/01(木) 23:38:13.83

ハードウェアは未だにZ80が現役のパチンコでもZ80要らないところなら色々使うで。
ソフト部分がjavaかC#か、最近はunityだから格差が大きい。
こういうニッチなところならrustのno_coreも入り込めるかも

**デフォルトの名無しさん** · 2017/06/01(木) 23:39:53.34

ごめん言い忘れた。
いまだにC++使わないのなんか軍事兵器くらいやで戦闘機のOSとか

**デフォルトの名無しさん** · 2017/06/01(木) 23:46:55.28

そんなの持ち出す前にlinuxでしょ

**デフォルトの名無しさん** · 2017/06/02(金) 00:20:19.49

F-35はC++が使われてるんじゃなかったか

**デフォルトの名無しさん** · 2017/06/02(金) 00:22:55.55

お前らやたら詳しいな……

**デフォルトの名無しさん** · 2017/06/02(金) 00:25:26.45

その辺はAdaが使われてる印象だったんだがCも使われてんのか。

**デフォルトの名無しさん** · 2017/06/02(金) 00:54:37.65

今、MISRA Cを使ってるようなところが、Rust向きだと思う

**デフォルトの名無しさん** · 2017/06/02(金) 01:43:12.50

飛行機なんかはメモリ確保命令は使わずに上書きでやりくりするんでしょ？
リアルタイム性が要求されるから決定的瞬間にアロケーションや解放なんて処理始まったら死ゾ

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

>>125
そうならばメモリアクセス安全に寄ったRustは不向きの用途だな。
専用ランタイム作らん限り。

**デフォルトの名無しさん** · 2017/06/02(金) 06:39:31.02

>>123
組み込み業界、Ada使うくらいなら素直にアセンブラ使うわw

>>119
他言語へのAPI公開のため最近はまたC言語が流行ってるやぞ
RustもGoもSwiftもC言語とのI/FはあるけどC++とのI/Fはないから、流行りに合わせてCにしとこってのはままある
まぁRustはbindgenとかいう変態ツールでC++マングル名を回避する荒業に出てるからなくても困らんのだけども

**デフォルトの名無しさん** · 2017/06/02(金) 07:33:26.58

>>125
ATS2 みたいな機能を Rust も組み込めば良いのに。

**デフォルトの名無しさん** · 2017/06/02(金) 09:15:56.51

C++でextern Cじゃいかんのけ？

**デフォルトの名無しさん** · 2017/06/02(金) 10:26:55.70

cとのI/Fではc++が最強か

**デフォルトの名無しさん** · 2017/06/02(金) 16:42:33.09

>>117
そーなんだ。俺がやってたのはもう10年くらい前だからさすがにかわったのか

**デフォルトの名無しさん** · 2017/06/02(金) 17:04:48.35

impl Into<[u8]> for Hoge {
これがエラーになってしまうのですが、どうやればInto<[u8]>を実装できるのでしょうか？
impl<T: [u8]> Into<T> for Hoge {
これも試してみたのですがシンタックスエラーになってしまいました。

**デフォルトの名無しさん** · 2017/06/02(金) 18:53:59.81

>>132
ttps://play.rust-lang.org/?gist=33ccca08ebe70d32141ce8cdaeddd76e&version=stable&backtrace=0
配列の長さが固定なら参照にしなくてもいいけど、多分可変長なんだろうからlifetime使わざるを得ない気がする

このスレでtokio, tokio言うからどんなものよと使ってみてるけどムツカシイ・・・
クライアントのサンプルコード少なすぎる、futuresの在り様が掴めなくて苦しいぜよ

**デフォルトの名無しさん** · 2017/06/02(金) 20:26:56.32

tokio好きのエロい人、ボスケテ
ttps://play.rust-lang.org/?gist=1efad716955551cd68c21b0183b9f942&version=stable&backtrace=0

これで実行すると、リクエスト送信 => レスポンス受信 => リクエスト送信、みたいな動きになる
sendとsend_allで二回送信してるんだろうから分からいでもないんだけど
リクエスト送信 => レスポンス受信、の動きにするにはどうすりゃいいの

**デフォルトの名無しさん** · 2017/06/03(土) 19:09:45.21

logとかrandとか、標準ライブラリではないけと、ほぼ公式ライブラリ化してるcrateのリストって、どこかにある？

**デフォルトの名無しさん** · 2017/06/03(土) 20:41:56.30

brson / stdx

**デフォルトの名無しさん** · 2017/06/03(土) 22:00:53.66

>>136
いい感じだね
Authors欄がThe Rust Project Developersになってるcrateのリストが
公式サイトのどこかにあるかなと思ったけど無いなあ

**デフォルトの名無しさん** · 2017/06/03(土) 22:03:30.78

>>137
https://github.com/rust-lang-nursery

**デフォルトの名無しさん** · 2017/06/03(土) 22:21:40.86

>>138
これや！

**デフォルトの名無しさん** · 2017/06/04(日) 03:40:08.07

そういうのがstdに無いのが不便で仕方ないんだがどうしてそうなったの

**デフォルトの名無しさん** · 2017/06/04(日) 03:45:59.28

>>140
それもう100回くらい語られてる
https://blog.rust-lang.org/2017/05/05/libz-blitz.html#batteries-included

**デフォルトの名無しさん** · 2017/06/04(日) 03:50:33.29

>>141
FAQにも無いように見えたしググり方も分からなかったんや
ありがとナス

**132** · 2017/06/04(日) 10:44:11.97

>>133
そこにもlifetime指定できたのですね。ありがとうございます！

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

C++のとき=で右辺の状態が変わるのが人間の直観によろしくないと
非常に明白な結論が出てるのに
なんで変えなかったんですかね

思考が著しく阻害される

**デフォルトの名無しさん** · 2017/06/04(日) 16:24:39.76

記号が　<- だったらよかったのにって？

まあ慣れだと思うけど。

**デフォルトの名無しさん** · 2017/06/04(日) 16:28:32.85

それを言い出したら左辺の状態が変わるのも"直感によろしくない"しなあ

**デフォルトの名無しさん** · 2017/06/04(日) 16:42:30.55

>>145
代入ってよく使うのに2文字はだるすぎ
慣れれば=でも問題ない

**デフォルトの名無しさん** · 2017/06/04(日) 16:58:15.24

お前ら非常に明白な結論になんてことを・・・

**デフォルトの名無しさん** · 2017/06/04(日) 17:07:01.45

>>51
valgrindの扱えない一般のuse-after-free　って何だ？

**デフォルトの名無しさん** · 2017/06/04(日) 19:25:09.29

>>149
メモリ以外も含めたリソースの解放後の使用って意味じゃね？ファイルとか

**デフォルトの名無しさん** · 2017/06/04(日) 21:24:44.90

>>150
ファイルに関してはValgrindには--track-fds=yesがあるから例として微妙では
もうちょっとドメイン固有なもの、例えばSerdeでDeserializerを２回使うのを防ぐとかの方がありがたみが強そう

**デフォルトの名無しさん** · 2017/06/04(日) 21:40:25.92

valgrindみたいな実行時チェックとコンパイル時の静的チェック比較してどうするの

**デフォルトの名無しさん** · 2017/06/06(火) 00:41:45.73

https://docs.rs/try/1.0.0/try/

>Since the introduction of the ? operator, its supporters have preffered its use, ignoring the valid criticism of the ? operator almost hiding the error propagation operation.

彼は一体誰と戦っているのだろう……

**デフォルトの名無しさん** · 2017/06/06(火) 02:28:52.15

というか、try!をdeprecateする話なんてあったか？
Rust 1.13以前をサポートするcrate（特にnursery系）ではバリバリ現役じゃん

**デフォルトの名無しさん** · 2017/06/06(火) 13:02:17.27

そういや、crates.ioに公開されてるものって
対応してるrustcのバージョンが不明確だな

**デフォルトの名無しさん** · 2017/06/06(火) 21:24:51.99

案の定、誰もtokioを使ったことない感じでスルーされつつ自己解決した
ttps://play.rust-lang.org/?gist=42a8464afde50942d9a162f3d1cfe9c0&version=stable&backtrace=0

futuresのAPI分かりづらいよ
zero-costとかそう言う所じゃないレイヤーのI/F設計が頭おかしい気がする
いや、気がするだけでzero-costに注視した場合にそうならざるを得なかったのかもしれんが

とりあえず、奥深いと言うかなんと言うか、tokio及びfuturesの闇の深さが分かったのでちょっと遊ぼう
tokioはstd:netのラッパーで本当に早いの?な感じだったけど、futuresの方は中々に面白い

**デフォルトの名無しさん** · 2017/06/06(火) 21:31:18.02

mioは本質的にstd::netを使ってなくねなどと重箱の隅を突いてみる

**デフォルトの名無しさん** · 2017/06/06(火) 21:39:21.98

tokioもサーバサイドで使うぶんには効率的よ？と直前のレスをちゃぶ台返し

エアプログラミングで卓上で論じる分には楽しいけど、実際使ってみようとしたらドキュメント少なすぎるだろ
futuresのtutorialみたらtokio.ioに飛ばされてスッゲーあっさりとしか書かれてないでやんの

**デフォルトの名無しさん** · 2017/06/07(水) 10:48:52.84

な？Rustってまともに使える言語じゃないだろ？
だからもう騙されるのは終わりにしようぜ。

**デフォルトの名無しさん** · 2017/06/07(水) 13:01:49.86

ソース読めばいいよ

**デフォルトの名無しさん** · 2017/06/07(水) 19:59:59.87

言語じゃなくライブラリの問題なんだよなぁ、言語仕様で躓いたPG(笑)はスクリプト言語にでもおかえり

ソース追い回しても分かんなかったよ, crate futuresのソースがC++のマクロ地獄みたいなの
解決したらそりゃそうだと納得なんだが、sink.and_thenのErrとstream.into_future().and_thenのErrが一致しないのは罠だと思った
お前ら両方ともtrait Futureのand_thenなのに違う型をツラっと返すなよな・・・
sinkから作ったFutureとstream(のinto_future)から作ったFutureがand_thenで連結できないのかと悩んだよ

**デフォルトの名無しさん** · 2017/06/07(水) 20:19:54.47

むしろ同じエラー型しか返せないとしたら面倒臭いわな
例えばfutures_cpupoolで常にio::Errorしか返せないとかだったら扱いにくいのなんのって

**デフォルトの名無しさん** · 2017/06/07(水) 20:43:02.03

Futureの操作元(今回はStream)をエラー時にも返したい時がある的な振る舞いは未だに理解できんぞ
sinkはErrでstreamは(Err, Stream)とかイミフ、どうせなら両方ともタプルにしてくれよ

**デフォルトの名無しさん** · 2017/06/07(水) 20:44:49.12

それはそうだが、StreamFuture::Errorの型はあれはちょっとなあ……
所有権を返したいってのはなんとなく分かるが

**デフォルトの名無しさん** · 2017/06/07(水) 20:46:10.36

>>164は>>162宛てな

**デフォルトの名無しさん** · 2017/06/08(木) 02:32:18.91

reqwest、HTTPヘッダやMIMEタイプまでそれぞれ別個にタイプセーフとかクレイジーだな、いい意味で
いや、hyperのせいか

**デフォルトの名無しさん** · 2017/06/09(金) 01:32:14.88

Announcing Rust 1.18 - The Rust Programming Language Blog
https://blog.rust-lang.org/2017/06/08/Rust-1.18.html

pub(restricted)と構造体フィールドの自動並び替えがstabilized

**デフォルトの名無しさん** · 2017/06/09(金) 07:32:46.19

時報が少し賢くなってるwww

**デフォルトの名無しさん** · 2017/06/09(金) 12:48:15.05

>>167
ありがとう。
これからも頑張って。

**デフォルトの名無しさん** · 2017/06/09(金) 13:10:04.93

pijulってなんだよgitだけでいいだろ

**デフォルトの名無しさん** · 2017/06/09(金) 14:25:21.34

gitよりmercurialが好きです(半ギレ

pijul(とdarcs)は初めて存在を知ったけどほーって感じ
Pull Requestはサービスプロバイダに依存するから、VCS自体にPR管理機能を持つのは良いのかもねぇ

**デフォルトの名無しさん** · 2017/06/09(金) 14:42:06.85

pgr

**デフォルトの名無しさん** · 2017/06/09(金) 15:36:57.58

Rustはgithubに依存しすぎだろ
GoogleやMicrosoftも似たようなサービス始めるみたいだし、もっと中立的になった方がいい

**デフォルトの名無しさん** · 2017/06/09(金) 15:39:14.20

goもかなり依存してないか？

**デフォルトの名無しさん** · 2017/06/09(金) 15:44:08.83

github依存度で言ったらGoよりましじゃないかな？自前でcrates.io持ってるし。
まあgithubに依存してなくてもやらかしたnpm見てるとgithub依存も最悪ではないみたいに思ってしまうがな。

というかgithub以外のまともなホスティングサービスがないのが悪い

**デフォルトの名無しさん** · 2017/06/09(金) 15:49:49.79

Scala/JavaのIvyみたいに、crates.io互換鯖を自由に立てられるようにしようとか
crates.ioのログインにgithubアカウント以外も使えるようにしようとかの動きは無いのかな？

**デフォルトの名無しさん** · 2017/06/09(金) 15:51:15.80

まあそれはともかく、gitとhgのサポートが既にあるのに
pijulとかいうまだまともに使えないVCSをwritten in Rustってだけで突っ込むのは
内輪のノリがきつすぎてイタい子なんだなあって感想

**デフォルトの名無しさん** · 2017/06/09(金) 15:52:47.94

>>177
Haskellのdarcs優遇と同じ現象だな

**デフォルトの名無しさん** · 2017/06/09(金) 16:00:58.60

>>178
ghcすらdarcsを捨てたと言うのにな。

というか今気づいたけどcargoってSubversion対応してねえのか。pijulとやらより
そっち先じゃねえの？

**デフォルトの名無しさん** · 2017/06/09(金) 16:13:07.06

>>175
bitbucketがあるだろ！！(今度こそマジギレ

sourceforgeのgitサポートがもう少し早ければ幾つかの連立もあったろうけど
sourceforgeは遅れるわGoogle Codeはへっぽこだわでgithub+git一強になったこのご時世は嫌だねぇ

pijulが強制されるわけでもなく、今まで通りcrates.ioホスティングがデフォルトだからgithub(git)に依存してないでしょ
個人的には面白いVCSだとは思うけど、率先して採用するプロジェクトはなさそう

**デフォルトの名無しさん** · 2017/06/09(金) 16:17:48.77

cargoのdependenciesにbitbucketのmercurialを書けるようにするissueは、前に見かけた気がする
たしか、やる気がないわけではないけど、使いやすいライブラリが無い的な返答だったような
直にリンクするとGPLになるとか

**デフォルトの名無しさん** · 2017/06/09(金) 17:16:09.17

vcs指定すると何がいいの？

**デフォルトの名無しさん** · 2017/06/09(金) 20:27:02.60

>>177
内輪云々というか、たまたま気が向いた人がPRを送ってきたから受け入れたってだけの話じゃないの？
それを言い出したら標準ライブラリだってredoxサポートのためのコードがたくさんあるし

**デフォルトの名無しさん** · 2017/06/09(金) 21:39:26.49

>>181
普通にrepositoryのURI指定でhg://bitbucket.org/hoge/hageみたいにしとけば動いた覚えがあるぞ
githubもgit://github.com/hoge/hageにするし、VCS, 接続サーバを意識してなくないかな

今更subversionやcvsを使う気は無いけど、誰かPR出してみようぜ
rejectされるなりacceptされるなり、どっちに転んでも笑い話だと思う

**デフォルトの名無しさん** · 2017/06/10(土) 04:46:24.86

pijul(ピフル)試してみた
・ドキュメント無さすぎ
・パッチのハッシュがクソ長いし、指定時に省略できない
・SSH周りがいろいろおかしい。agent使えないとか
・エラーメッセージが全く役に立たない。コード読んで初めて原因が分かる感じ
・現在のバージョンを特定するタグ、IDのようなものが未実装
・複数ファイルの追加は一つずつ指定する必要がある。ディレクトリ一括とかダメ
・ワーキングディレクトリ内の未追加ファイルを一覧するコマンドが無い。要記憶力
・ワーキングディレクトリ内の状態を一覧するコマンドが無い
・ファイルとして受け取ったパッチの取り込みを行うコマンドが無いので、自分で.pijulディレクトリの中にコピーするらしい

結論：実用にはあと2年は待ちたい。すぐ使いたいならdarcs使え