プログラミング言語 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/06/27(火) 22:56:55.59

>>225
どゆこと？
より一般化してUnsized Rvaluesにしたけど、Openのまま3か月放置？

**デフォルトの名無しさん** · 2017/06/28(水) 01:29:39.37

>>226
関連するissueがまだopenのままに見える

**デフォルトの名無しさん** · 2017/06/28(水) 11:14:29.14

瑕疵担保責任（かしたんぽせきにん）

瑕疵担保責任のポイント

民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
不具合を指摘されたらすぐに行動をとるべし
軽微なミスでも先延ばししない

http://www.atmarkit.co.jp/ait/articles/1706/26/news014.html
http://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt

改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている

全ベンダーが泣いた民法改正案を解説しようその1
http://www.atmarkit.co.jp/ait/articles/1609/14/news009.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html
http://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html

ポイント1：修補や損害賠償、契約解除の期限がなくなる

従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。

もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。

**デフォルトの名無しさん** · 2017/07/01(土) 18:15:18.87

Futuresに詳しい人教えて

Zero-costを謳ってTraitでコスト削減してるのは理解したんだが
id_rpc(&my_server).and_then(|id| {
get_row(id)
}).map(|row| {
json::encode(row)
}).and_then(|encoded| {
write_string(my_socket, encoded)
})
ってやった場合に
AndThen x2, Map x1を初期化時に作るコストについては
実行時のコストには乗らないから度外視って理解であってる？

Aaron Turonのブログ読んでもそこは言及してないように読めるので教えてくれい

**デフォルトの名無しさん** · 2017/07/01(土) 20:18:30.04

コンパイラの最適化で消えるか、消えないにしてもstackいじるだけだから無視できるほど小さいコストなんだと思う

**デフォルトの名無しさん** · 2017/07/02(日) 07:08:11.19

んー、その擁護は微妙に納得いかないかな...
AndThen, Mapは状態変数を保持するenumを内包するstructなので消えないはずだよねぇ
まぁstackいじるだけという言い分として、ならば実行時のcallでBoxFutureを返すのはバッドノウハウってことか
BoxFutureを返すのと、Futureを実装したstructを返すのと、どっちがZero-costに近いかは測ってみるか
サンプルだとBox<Future>だけど、Tokioは一律structを実装してるから、後者の方が早いんだろうけども

**デフォルトの名無しさん** · 2017/07/02(日) 11:32:28.47

すまん、よくよく考えたら実行中にBox<Future>を返すのは動的にステートマシンのタスクを増やす行為だからNGだ
Futureを返さなきゃと.boxed()使ってたけど、素直にPollで結果を包むだけでよかった

**デフォルトの名無しさん** · 2017/07/04(火) 00:00:54.04

futuers-rsは

これfutuereじゃねぇじゃねーか、並列計算してないパイプラインをfutuere呼ぶなよ
↓
すぐにfutures-cpupoolを見つける

までが予定調和。

Zero-cost ~~futures and~~ streams in Rust

**デフォルトの名無しさん** · 2017/07/04(火) 09:31:46.73

これZero-costじゃねぇじゃねーか
↓
Zero-cost(コストがないとは言ってない)

までが予定調和だったわ
下手な自作設計よりは全然コスト軽いけど鵜呑みは良くないね

**デフォルトの名無しさん** · 2017/07/04(火) 10:33:24.16

まず future の綴を覚えるところからお願いします

**デフォルトの名無しさん** · 2017/07/04(火) 12:20:45.83

impl Traitじゃあかんのか？

**デフォルトの名無しさん** · 2017/07/04(火) 13:09:55.73

aturon氏の記事（Zero-cost futures in Rust）を読めば"zero cost"というのは「直にステートマシンを書いたのと同様のコードにコンパイルする」という意味で言っていると分かるはずで、
状態変数があるからzero costじゃないなどという指摘は出てこないと思うのだけど

**デフォルトの名無しさん** · 2017/07/04(火) 13:30:28.66

traitってGoのinterfaceに似てる
って言ったら型警察に起こられるんだろうか

**デフォルトの名無しさん** · 2017/07/04(火) 14:05:06.69

>>237
？

だからコストがないって訳じゃないと理解したんだが
タスク構築のための初期化アロケーションとか、ステートマシンのための状態管理(分岐)の少量コストはあるって解説してるよな

言葉遊びによるZero-cost警察の方なら触ってスマン

**デフォルトの名無しさん** · 2017/07/04(火) 16:29:36.87

警察じゃなくても激おこやと思うw

**デフォルトの名無しさん** · 2017/07/04(火) 16:36:55.49

zero costは宣伝文句で、zero overheadくらいが妥当では

**デフォルトの名無しさん** · 2017/07/04(火) 18:21:59.60

実行はゼロコストかも分からんが書くコストが青天井なので結局意味のない言語

**デフォルトの名無しさん** · 2017/07/04(火) 19:19:11.80

Aaron Turonのブログを引用しながら実は別の意味で言ってましたとか草

**デフォルトの名無しさん** · 2017/07/04(火) 22:45:10.68

javaはzero-overheadの語を使うけどrustはzero-costを使うよね。
zero-overheadだと追加の余計なコストがかからないという意味がわかるけど、
zero-costだとコストそのものがないと言っているのかzero-overheadと同じ意味で使ってるのか定かではないと思う。

**デフォルトの名無しさん** · 2017/07/04(火) 22:53:04.21

Rustでzero-cost (abstraction)といったら抽象化レイヤーによるコストが0という意味だろうね

**デフォルトの名無しさん** · 2017/07/05(水) 03:06:44.06

そもそもがC++界隈からの借用語だしな

**デフォルトの名無しさん** · 2017/07/05(水) 16:39:24.43

激おこな警察官が多くて誰がどの立場で何を擁護してるのかワケワカメ

とりあえずまぁfuturesやtokioを下手に使うとコストがゴリゴリ上がってくのは分かった
ステートマシン(AndThenやMap)も抽象化しきれなかったのかstructでI/F切られてるし注意して使わんとな

**デフォルトの名無しさん** · 2017/07/05(水) 17:11:36.04

そりゃ、真にコストゼロはありえないだろう
一般に気にされてるのは、C/C++より多いかどうかでしょ

**デフォルトの名無しさん** · 2017/07/05(水) 18:08:21.50

だれかGUIライブラリ書いて
そしたら社内ツールでC#の替わりに使うで

**デフォルトの名無しさん** · 2017/07/05(水) 18:41:42.95

ゼロコストがabstractionにかかっていることをつい忘れちゃう
まあ普通に考えたら、futuresでもIteratorでもMapを実現したいなら値と関数は保持しないといけないし、AndThenも前と次の値を持ってないといけないよね
ラッパー構造体のコストは引数がコピーじゃなければメモリ的にもCPU的にもゼロだったはず

**デフォルトの名無しさん** · 2017/07/05(水) 19:26:13.97

>>248
別にC/C++と比較してコストがあるかは気にしてないぞ
C++ TemplateとRust Traitは実質同じ所に行き着くんだから比較するほどの意味もなし

>>250
IteratorやMapを抽象化できないのか？、できないならコスト削減できない不適切なLibではないのか？とは思わないのかねぇ
Rustに限らず新興言語はキーワードだけ拾って素晴らしいものだ！みたいな賛美ユーザが多いね

>>249
ttps://github.com/kenz-gelsoft/wxRust

もう動かないかもしれないけど
去年くらいのwxWidgetsが3.2.0でFFI周りのI/Fを非公開にしてwxHogeHogeが全滅した

**デフォルトの名無しさん** · 2017/07/05(水) 19:35:34.06

>>150
コンパイラだってバカ正直にMap構造体を用意してそこにクロージャをそのままぶち込むようなコードは生成しないんやで

**デフォルトの名無しさん** · 2017/07/05(水) 19:42:23.78

>>251
>IteratorやMapを抽象化できないのか？
まあ確かにHKTが欲しいと思わないこともないな

**デフォルトの名無しさん** · 2017/07/05(水) 19:43:35.74

>>252
安価は>>250の間違い

**デフォルトの名無しさん** · 2017/07/05(水) 20:12:29.34

>>249
GTKはまともに使えるっぽいけどそれじゃだめなの？
俺はgtkあんま好きじゃないからいやなんだけど

**デフォルトの名無しさん** · 2017/07/06(木) 11:00:33.73

>>247
>コストがゴリゴリ上がってくのは分かった
何を突然ファビョってるんだか
タスクごとのヒープアロケーション数はΘ(1)に抑えられているだろ

**デフォルトの名無しさん** · 2017/07/06(木) 20:30:03.81

最近の公式の動きを見ていると、WebフレームワークはRocketを推していく方針に見えるな

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

>>257
何でよりによってnightlyを要求するRocketなん？

**デフォルトの名無しさん** · 2017/07/10(月) 13:13:29.86

>>256
タスク数に合わせてO(n)になってると思うんだけどそれは度外視なのかな？

**デフォルトの名無しさん** · 2017/07/10(月) 13:58:50.67

オラクルがrustでコンテナランタイム作っとるってよ

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

Building a Container Runtime in Rust | Oracle Developers Blog
https://blogs.oracle.com/developers/building-a-container-runtime-in-rust
> almost all container utilities are in c or go.
> (中略)
> Rust sits at a perfect intersection of these two languages

**デフォルトの名無しさん** · 2017/07/11(火) 13:53:59.15

オラクルの時点でお察し案件じゃん
まあオラクルとモジラは業界のゴロ同士仲がよろしいんですなあ

**デフォルトの名無しさん** · 2017/07/14(金) 04:46:26.78

google という名前のcrateが上がってて、
説明文が "Google is evil"
バージョン番号が "6.6.6"

**デフォルトの名無しさん** · 2017/07/14(金) 20:21:33.28

Googleが悪とかやっぱモジカスだわ

**デフォルトの名無しさん** · 2017/07/15(土) 17:00:03.78

Rust公式がTwitterで"Rocketの新バージョンがリリースされたぜ"とか呟いてて、それに対して"Ironの何が悪いんだ"的なクソリプが付いてるの笑う

**デフォルトの名無しさん** · 2017/07/15(土) 23:27:50.25

RustのSlackでmame氏にCでポインタとか触ったことありますか？って聞いてるやついてワロタ

**デフォルトの名無しさん** · 2017/07/16(日) 13:32:06.66

箸が転がったから笑った

**デフォルトの名無しさん** · 2017/07/16(日) 13:33:12.21

膝がワロタ

**デフォルトの名無しさん** · 2017/07/17(月) 22:50:00.44

関連型ってさなんでいるの？
CeylonやC#みたいにgenericsのin/outで実現できない？

**デフォルトの名無しさん** · 2017/07/18(火) 13:42:50.01

>>261
ライブラリの問題とかそういう回避方法はないのかと考察したけど、goroutineの仕様上無理ぽって結論なのか
rustが最適な言語かどうかは懐疑的だけど、go以外の使える新興言語ってのは他にないし仕方ないのかねぇ

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

>>269 in/outの方が劇的に良かったりするの？MSDNとか読んでもすぐに理解できなかった

**デフォルトの名無しさん** · 2017/07/19(水) 22:47:17.03

>>271
良くなったりするわけじゃなくて全く同じもの。
単にrustのジェネリックスに制限があるだけ。
in/outや+/-なのはjavaの境界ワイルドカード型の定義が
長いから短くなったものでキーワードにするかシギルにするかの好みの違い。

**デフォルトの名無しさん** · 2017/07/20(木) 00:56:51.60

C#とか知らないから適当なことを言うけど、in/outって要は型パラメータの反/共変性を指定する構文ってこと？
Rustはクラスがないからあまり関係ないような気が
そもそも関連型と型パラメータは全く別物だし

**デフォルトの名無しさん** · 2017/07/21(金) 01:30:42.74

Announcing Rust 1.19 - The Rust Programming Language Blog
https://blog.rust-lang.org/2017/07/20/Rust-1.19.html
・C互換な(untagged) unionの導入
・loopのbreakで値を返せるようになった
・値をキャプチャしないクロージャを関数ポインタ（impl Fnでなくてfn型）として扱えるようになった

**デフォルトの名無しさん** · 2017/07/21(金) 03:20:29.74

新しい言語は早い段階から使い始めれば
バージョンアップ時は変更点だけ覚えればいいけど
バージョンアップが重なったあとから始めようとすると覚えることいっぱいすぎ
Rustよ
もっとシンプルに

**デフォルトの名無しさん** · 2017/07/21(金) 08:32:20.79

-Zオプションが時報に無視されててワロタ

**デフォルトの名無しさん** · 2017/07/21(金) 12:38:58.44

Cargoがhigh level過ぎでrustcがlow level過ぎな課題はいつ解決するんかな
他のビルドツールを使ったプロジェクトにrustを入れるのが今は面倒

**デフォルトの名無しさん** · 2017/07/21(金) 19:27:14.18

ていうか時報の反応速度が高くて笑う
まさかリリースの度に待機してるのか？

**デフォルトの名無しさん** · 2017/07/22(土) 07:37:27.49

> ・loopのbreakで値を返せるようになった

遂に来たか。

**デフォルトの名無しさん** · 2017/07/22(土) 14:32:40.69

時報であることに使命を感じて全力待機してそう, 機械の鑑だよホント

**デフォルトの名無しさん** · 2017/07/22(土) 16:14:42.22

誉め言葉として受け取っておく

**デフォルトの名無しさん** · 2017/07/22(土) 16:20:13.34

>>281
誰だお前

**デフォルトの名無しさん** · 2017/07/22(土) 16:39:57.41

なお、バグった機械の模様

**デフォルトの名無しさん** · 2017/07/22(土) 17:02:38.46

雑談の種になるよう頑張ってるんだよ、そんなあげつらうことないでしょ

**デフォルトの名無しさん** · 2017/07/22(土) 17:04:33.13

というかどこに行けばRustの話をしていいのか分からない。英語ならRedditがあるけど

**デフォルトの名無しさん** · 2017/07/22(土) 17:05:27.55

あれ、associated constsはstabilizeされたんじゃなかったのか

**デフォルトの名無しさん** · 2017/07/22(土) 17:10:48.08

>>286
現行のbetaではfeature gateが外れているから次のstableに乗るはず

**デフォルトの名無しさん** · 2017/07/22(土) 17:42:07.41

rust-jpのSlackとか？
ところでLLしか触ったことなかった俺も最近Rust使い始めてみたんだけど、有識者から見てRustで1番理解が大変なの（あるいは抑えておかなきゃならないとこ…）はどのあたりなのか教えて欲しい。

**デフォルトの名無しさん** · 2017/07/22(土) 18:20:40.76

>>288
トレイト
ムーブ
参照（borrowing）

Javaも触ったことないならトレイトは最初難しそう

**デフォルトの名無しさん** · 2017/07/22(土) 20:18:18.76

slackの質問に対するリアクションありすぎてこわい

**デフォルトの名無しさん** · 2017/07/22(土) 20:29:54.52

>>289
ありがとう
公式のチュートリアルみたいなやつ進めてるんだけど今のところトレイトオブジェクトらへんでちょっと理解に苦しんでる

**デフォルトの名無しさん** · 2017/07/24(月) 12:10:36.01

rustって現場で使われ始めてるの？
メモリ管理周りのメンタルモデルって他の言語に応用利いたりする？
コードがきれいになるとか？
始めるモチベが欲しい。

**デフォルトの名無しさん** · 2017/07/24(月) 12:28:38.82

C++ほど辛くない

**デフォルトの名無しさん** · 2017/07/24(月) 14:12:02.33

>>292

1.クソコードをコンパイルさせてくれない
2.コンパイル通すの少し大変だけど実行時エラーが本当に出ない
3. 速い
4.パッケージマネージャーがよくできてる

1は本当に大きくて、自分のコードとコンパイラが喧嘩になると大抵自分のアーキテクチャが悪く、直すとちゃんと正しい実装になって感動する。つまり正しいコードが書けるようになる

**デフォルトの名無しさん** · 2017/07/24(月) 14:19:11.38

>>294
もう一つ。仕事で使ってたりする？
goのcliツールはよく見るんだけど
rust製って何が有名なのかね？
ブラウザ以外で

**デフォルトの名無しさん** · 2017/07/24(月) 16:50:51.12

仕事で使ってるかは別としてcliツールは作りやすい印象

**デフォルトの名無しさん** · 2017/07/24(月) 17:05:29.37

ripgrepしか紹介できないんだがなんかないのか

**デフォルトの名無しさん** · 2017/07/24(月) 17:19:06.22

redoxosのシェルやエディタはunix用としてもビルドできるし
有名かは別として

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

ripgrepはもちろんだが、tokeiも便利だよ
ion-shellもよく出来てる

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

https://github.com/rust-unofficial/awesome-rust

**デフォルトの名無しさん** · 2017/07/24(月) 19:32:19.52

tokei のレポジトリにある使用例

https://asciinema.org/a/d14m9g1d2cyo7wvrxh0z4ck6o

を見てみたら、F* と Ur/Web がカウントされていたので「あっ（察し」事案だった

**デフォルトの名無しさん** · 2017/07/24(月) 23:36:39.90

確かにcliは書きやすくて社内で使ってるサポートツール類はほとんどRust製。
小さいツールだと関係者も少なくて説得しやすいし。

https://www.rust-lang.org/ja-JP/friends.html

こことか見ててもそういうパターンが多いように見える。
さすがに大規模なプロダクションコードをいきなり
置き換えとか無理だろうし。

**デフォルトの名無しさん** · 2017/07/24(月) 23:43:54.02

Rustである旨味なさそうだけど学習用？

**デフォルトの名無しさん** · 2017/07/25(火) 06:07:27.53

おお、色々情報ありがとう。
今のところgoのcliツールのほうが目立ってるのは、単純に1.0のリリース時期の違いによるものなのかな。

redox は気になるなー。rustのメモリ管理の仕組みからいってバグが少ないosになるのかな。ちょっと試してみたいかも。reduxと名前が似てるのがなんかやだけど

**デフォルトの名無しさん** · 2017/07/25(火) 10:59:30.41

goのツールをパクって速いのを作ればいいのか？
goのツールは何があるの？

**デフォルトの名無しさん** · 2017/07/25(火) 11:37:29.68

俺が知ってるのは
peco、ghq 辺りかな。
ghqは常用してるけど最近重くなってきてるからぜひrustで軽くなるならして欲しい。
多分gitにアクセスしてる部分がボトルネックな気がするけど。

**デフォルトの名無しさん** · 2017/07/25(火) 11:45:28.60

あとgitをrustで書き直したらはやくなるとかないかね。
ライナスに喧嘩売ることになるかもだけど。
それをきっかけにlinuxをcにこだわるのをやめてくれるかもw

**デフォルトの名無しさん** · 2017/07/25(火) 12:39:25.58

pecoもghqもすでにrust版あるよ

**デフォルトの名無しさん** · 2017/07/25(火) 13:18:07.15

wasmがもっと成熟すれば...

**デフォルトの名無しさん** · 2017/07/25(火) 14:21:47.66

>>308
へー。リンク下さい

**デフォルトの名無しさん** · 2017/07/25(火) 16:53:49.81

>>310
https://crates.io/crates/rhq
https://crates.io/crates/skim

**デフォルトの名無しさん** · 2017/07/25(火) 17:33:21.29

skimええやん

**デフォルトの名無しさん** · 2017/07/25(火) 17:38:52.31

>>307
Facebookが社内向けにMercurial(Python + C)をRustで一部？書き直したら速かったらしい

俺も、社内向けツールを前任者がgoで書いたのを幾つかRustに移植してる
ただの練習素材として移植してたけど、2～3倍速くなったよ

**デフォルトの名無しさん** · 2017/07/25(火) 19:00:41.47

「Rust 1.19」リリース。union（共用体）をサポート
http://www.publickey1.jp/blog/17/rust_119union.html

**デフォルトの名無しさん** · 2017/07/25(火) 20:32:46.37

>>313
おおー。魅力的な話だね。
メモリの使用量もrustだと減るようなきがするんだけどそのへんどうかな。

**デフォルトの名無しさん** · 2017/07/25(火) 21:45:29.88

rustは今の日本だと凄腕のプログラマが使ってるところはちょいちょい見かけるな。
もっとwebの人たちがたくさん布教すればいいんだろうけど、やっぱrust自体が難しいのかね。
C++とよくセットで名前が出てくるから、ビビる人が多いのかなーとも思う

**デフォルトの名無しさん** · 2017/07/25(火) 22:11:08.39

最近真面目に勉強し始めたけど潜在的に難解なバグを生み出す汚いコードを平気で書く人だと
コンパイルが通らないので辛いと思う。
若干煽り気味に言えばPHPやRailsだけやってプログラミングを分かった気になってちゃんと勉強してない人には無理。

**デフォルトの名無しさん** · 2017/07/25(火) 22:21:26.92

ios -> objc, swift
android -> kotlin,java
web frontend -> typescript, javascript
web backend -> go,ruby,php
ってイメージだがrustはどこに入るの？

**デフォルトの名無しさん** · 2017/07/25(火) 23:01:36.50

webassemblyの今後の成熟具合によっては、
web frontendに食い込んでいくかも

**デフォルトの名無しさん** · 2017/07/26(水) 02:52:39.50

>>318
希望的観測で言えば、
今までC/C++で書かれていたようなもの全てと、今goで書かれているものの半分 -> rust

WebAssemblyをほんとに必要としてるのは、ごく一部の人だと思う

**デフォルトの名無しさん** · 2017/07/26(水) 08:56:45.29

>>320
例えばc++ でUE4って書かれてるけど
そこをrustでってのはあるのかな？
ゲームエンジンとかはc++ってイメージだけどそれがrustでどうなるのか興味あるなー。
c++よりバグが少なくなってメモリ使用量も減るなら
家庭用ゲーム機とかの性能向上に役立ちそうだけど。

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

https://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/dining-philosophers.html
このチュートリアルもうちょいなんとかならないのか
クロージャー周りの説明が抜けてるからなんだかふわっと触って終了みたいな感じになるんだけども。シンタックスの方から学んだほうがしっくりする。

**デフォルトの名無しさん** · 2017/07/26(水) 12:59:44.03

>>321
ゲームエンジンそのものがRustで書かれているのでなければ移行はないと思ってる
自分は据え置き開発だけど、ライブラリやツールやアセットパイプライン含めてC++ならそのまま利用する方が楽だし、ゲーム会社ならC++の資産やノウハウも蓄積されてる

**デフォルトの名無しさん** · 2017/07/26(水) 16:21:03.85

>>323
環境的にc++14使うくらいは許されてるの？

**デフォルトの名無しさん** · 2017/07/26(水) 18:20:47.88

>>324
基本C++11かな
部分的に14の機能も使えるかも
そのうち使えるようになると思われる