Rust Part6

**デフォルトの名無しさん** · 2018/07/28(土) 03:04:38.63

Mozilla発のRust言語のスレ

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

Web上の実行環境
https://play.rust-lang.org

前スレ
Rust Part5
http://mevius.5ch.net/test/read.cgi/tech/1518347244/

**デフォルトの名無しさん** · 2019/04/17(水) 22:11:49.04

>>695
イヤでも使わなきゃならないのが優れた言語
嫌な奴はさっさと逃げ出して残った少数にもてはやされるのが（ｒｕ

>>698
ベンチの取り方も知らないみじく者にもてはやされるのが（ｒｕ

**デフォルトの名無しさん** · 2019/04/18(木) 00:48:35.35

>>34の画像ってどこのサイトからもってきたの？

**デフォルトの名無しさん** · 2019/04/20(土) 09:01:49.04

>>701
代入が値を返す場合、代入された値が戻り値へとmoveされてしまうから問題がありそう

**デフォルトの名無しさん** · 2019/04/21(日) 12:13:27.97

代入式の値はUnitでいいんじゃなかろうか。もともとCのような代入の連鎖はできないわけだし。

**デフォルトの名無しさん** · 2019/04/21(日) 15:32:25.18

https://play.rust-lang.org/?version=stable&;mode=debug&edition=2015&gist=765849a4e776e00b0c614fc941b02ecf
Defaultを実装してない構造体のフィールドのうちDefaultを実装してるフィールドだけまとめてdefault()で初期化するような記述方法は無いでしょうか？

イメージとしては
let s = S { nd: NonDefault::new( "foo" ), u: Default::default(), i: Default::default() } ;
の部分を
let s = S { nd: NonDefault::new( "foo" ), _: Default::default() } ;
のような形で書けないでしょうか

**デフォルトの名無しさん** · 2019/04/21(日) 16:17:53.22

>>706
マニュアルに
SomeOptions { foo: 42, ..Default::default() };

**デフォルトの名無しさん** · 2019/04/21(日) 20:37:02.65

>>707
ありがとうございます、ただそれだとSomeOptionsがDefaultを実装している場合の記法ですよね？
(実際試してもthe trait bound `SomeOptions: std::default::Default` is not satisfiedとなります)

質問としてはSomeOptions自体はDefaultを実装していないけど、そのフィールドのうちDefaultを実装している型の値はまとめてdefault()で初期化したいってことなんですが…

**デフォルトの名無しさん** · 2019/04/22(月) 22:53:15.58

そういうときは初期化子直接使うんじゃなくてコンストラクタ定義すんのよ

**デフォルトの名無しさん** · 2019/05/03(金) 19:03:01.94

新刊の「実践Rust入門」が売れているらしいね

**デフォルトの名無しさん** · 2019/05/03(金) 23:38:25.91

κeenさんの所でもまだ出てないのに売れてるらしいと書かれてたけどどういう事なんアレ？

**デフォルトの名無しさん** · 2019/05/04(土) 00:25:49.45

先行販売というのがありまして

**デフォルトの名無しさん** · 2019/05/04(土) 10:58:17.57

都内の大型書店には結構出てるし電子版は連休前が発売日だったはず

**デフォルトの名無しさん** · 2019/05/05(日) 00:20:18.06

電子版と紙で発売日違うのか。なるほど。

**デフォルトの名無しさん** · 2019/05/05(日) 15:42:25.76

結局ここまでまともなソフトが出ないってのはそういうことなんだな。

**デフォルトの名無しさん** · 2019/05/05(日) 16:52:40.49

>>715
え？どういう意味？

**デフォルトの名無しさん** · 2019/05/05(日) 18:47:18.73

急にアンチRustが勝ったのか

**デフォルトの名無しさん** · 2019/05/05(日) 21:12:05.69

はい論破

**デフォルトの名無しさん** · 2019/05/05(日) 21:34:31.13

メインでrust使ってる企業あったら入りたいもんだけど、実際使ってる企業あるの？
モダンな言語だとせいぜいGoとかelixirじゃない？

**デフォルトの名無しさん** · 2019/05/05(日) 22:35:02.29

世界コンピュータ将棋選手権に出た強豪ソフトがRust製で
公開予定

**デフォルトの名無しさん** · 2019/05/06(月) 04:44:55.95

人間からすれば強豪でも、予選落ちで強豪ソフトと呼ぶのは違う気もする

**デフォルトの名無しさん** · 2019/05/19(日) 01:45:51.38

Rustの本どんなもんかとアマゾンで見てみたら、
中華業者の星5レビューばっかで色々と察した
そもそもの話の言語自体が胡散臭いのも納得

**デフォルトの名無しさん** · 2019/05/19(日) 07:53:59.58

ライフタイム引数のクソさはもうどうにもならんな。
変な省略ルールとかつけて逆に分かりづらくなるとか本末転倒もいいとこだ。

**デフォルトの名無しさん** · 2019/05/19(日) 08:27:50.82

省略ルールのありなしに関わらず分かりづらいだけでは

**デフォルトの名無しさん** · 2019/05/19(日) 09:39:06.56

アマゾンのレビュー1件しか無いんだが

**デフォルトの名無しさん** · 2019/05/20(月) 04:17:07.25

https://ja.wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)
>実行時速度性能はC言語と同等程度である[8]。

これマジ？

**デフォルトの名無しさん** · 2019/05/20(月) 04:25:14.45

こんな記事を見つけた

＞Rustのコードを用いたこのためのテストの平均はCコードの実行したものの3.040倍と同じくらいだ。

＞この関数により、我々はRustが平均的に2.036倍Cよりも遅いことを知った。

やはりCの方が速いな。省メモリという点でもCが一番だし

**デフォルトの名無しさん** · 2019/05/20(月) 04:30:01.80

＞Rustが事実上Cよりも遅いままで終わってしまったという事実は、より落胆させられた。

＞また、全体を通してRust言語は、
この手の高水準な完成されたシステムを作る手助けをすること、
そしてこの領域において少量の変更で効果的にCを置き換えることができることを示すことができた。

現状のRustはCを置き換えれないけど、
将来的な改善まで含めればできるはずだと主張してるな。。

**デフォルトの名無しさん** · 2019/05/20(月) 08:44:28.91

鬼が笑うなｗ
実現してから言えとｗｗ

**デフォルトの名無しさん** · 2019/05/20(月) 11:23:27.01

Cと同等はさすがに無理にしても、もう少しCに迫る性能が出ないと、C／C++から脱出したい人の受け皿にはなれないんじゃないか？あるいはCの2～3倍遅い程度なら許容範囲内ということで割り切るしかないんだろうか。

**デフォルトの名無しさん** · 2019/05/20(月) 11:55:14.56

2015年の記事だぞ

**デフォルトの名無しさん** · 2019/05/20(月) 11:56:49.92

それが許容できるならNim早く1.0になーれ

**デフォルトの名無しさん** · 2019/05/20(月) 19:41:02.00

>>732
nimのllvm版 nlvm はどうよ？

**デフォルトの名無しさん** · 2019/05/20(月) 21:28:47.95

>>724
ライフタイムとムーブについてはそこまで複雑な概念ではないよ。
ライフタイムに対するシンタックスがヘンテコなだけで。

**デフォルトの名無しさん** · 2019/05/20(月) 22:35:24.52

RustでLinuxカーネルを書き直す時代はこなさそうだな

**デフォルトの名無しさん** · 2019/05/20(月) 23:11:59.72

>>726,727
メモリを自分で面倒見る分とセキュリティチェック甘い分早いだけだからcでリージョン使ってメモリ管理して配列の境界チェックとかもすれば似たようなもんだ。
rustのpanicはきれいに落とすぞ。ただ、ランタイムデカイ分とrust用のメタデータ含む分でフットプリントはcの方がいいと思う。

>>734
リージョン推論間違えるか効率悪い位ならリージョン指定させてほしい時はある。

**デフォルトの名無しさん** · 2019/05/21(火) 09:41:15.53

>>735
新しいOS作れば？
なんだったらAndroidみたいにLinuxの上に構築。

**デフォルトの名無しさん** · 2019/05/21(火) 22:10:42.02

それをRustでやってもCで書かれたOSを上回れないという話でしょ

**デフォルトの名無しさん** · 2019/05/22(水) 04:00:23.34

パフォーマンスとかどうなんだろな

https://www.redox-os.org/jp/

**デフォルトの名無しさん** · 2019/05/22(水) 06:22:56.65

https://discourse.redox-os.org/t/redox-performance/966

まだ初期段階だから比較しないで、みたいな事言ってる

最終段階までいってもCを超えると思えないんだが
しかもLinuxは組み込みでも使われてるがそれはCが省メモリだからで
Rustが勝てる見込みは無いと思うんだがなあ

**デフォルトの名無しさん** · 2019/05/22(水) 08:53:37.75

原理的には負ける理由もないと思うけどな。
Cは基本ノーチェックで脆弱性が見つかったらチェック入れるのに対して
Rustはいろいろチェック入ってるのをunsafeで外してパフォーマンス上げていくから
最終的に同じところに収束する気がする。
まぁ途中段階とか未知の脆弱性を放置する前提なら勝てないんだけど。

**デフォルトの名無しさん** · 2019/05/22(水) 18:27:00.47

中華ステマ企業が今押せと言われてるイチオシの言語Rust使ってるやつおるん？

**デフォルトの名無しさん** · 2019/05/22(水) 18:37:51.22

いつもの
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

**デフォルトの名無しさん** · 2019/05/22(水) 19:42:58.33

そのサイトいっつも思うんだけどベンチマークの並べ方恣意的じゃない？
vs Cではmandelbrotが下の方にあるけど
vs Javaでは上から2番目

Rustが勝利している項目では太字だけど
Cが勝利している項目では太字にならない

vs C++では、5項目でRust勝利、5項目でC++勝利で互角なのに、
Rustだけ太字でしかもRustが勝利したベンチマークから並べられてる。

俺はそのサイト少しも信用してない

**デフォルトの名無しさん** · 2019/05/22(水) 19:44:17.01

さらに言えば言語によって使用されるベンチマークがいつも違う。
勝たせたい言語のためにベンチマークを選択している可能性がある。

新手のマーケティングじゃないの？

**デフォルトの名無しさん** · 2019/05/22(水) 19:50:53.32

恣意的の意味するところがわからんけど
C++からだとRustに勝ったベンチマークだけ太字
C++が勝利したベンチマークから並べられるよ
使用されるベンチマーク云々はちょっとわからん

**デフォルトの名無しさん** · 2019/05/22(水) 19:53:02.49

>>742
Amazon Intel Microsoft Dropbox Nokia Fastly DiscordはGitHubでみた

**デフォルトの名無しさん** · 2019/05/22(水) 19:55:03.66

中国語ブログの方がRustに対して冷静な評価をしてる印象
https://www.oschina.net/translate/rust-vs-cpp
https://www.cnblogs.com/Bob-wei/p/5680648.html

彼らはRustの将来をどちらかと言えば悲観的に見ている

**デフォルトの名無しさん** · 2019/05/22(水) 20:05:42.30

ソース公開されて比較的新しいコンパイラを使って測定されるbenchmarksgameは信頼ならなくて
2016年に書かれた中国語のブログにあったフィボナッチ数列のベンチマーク(ソース非公開)の方が冷静？

**デフォルトの名無しさん** · 2019/05/22(水) 20:13:21.83

rust推す人もステマする暇があったらrust dockerでも実装すりゃいいのに。
性能と安全性でいえばgoの実装以上のものができるんでしょ？

**デフォルトの名無しさん** · 2019/05/22(水) 20:16:34.45

中華ステマ企業がって話があったから中国語圏でどうなのかなと思って調べただけ

あとそのサイトを信じるなら、5項目でRust勝利、4項目でC勝利で、
RustがCより速いという事になる。
その結論は信じがたい。

**デフォルトの名無しさん** · 2019/05/22(水) 20:20:32.23

ソースあるから実行すれば？https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html
俺はdockerを実装しなきゃいけないことになったから

**デフォルトの名無しさん** · 2019/05/22(水) 21:56:55.02

モジラのステマと買収から中国の陰謀まで進化したのか

**デフォルトの名無しさん** · 2019/05/22(水) 22:46:43.42

rustで書かれたコンテナエンジンはオラクルが作ってたろ
goのgcによるボトルネックがひどすぎるとかで

速度のベンチマークなんてほとんど意味ないだろ
生産性のがはるかに大切

**デフォルトの名無しさん** · 2019/05/22(水) 23:01:26.69

n-bodyのソースとか見ればわかると思うけど、メモリレイアウトとかSIMDとかほぼCと同等まで詰めてあるから、Cに勝っても何の不思議もない。
実質gccとllvmの最適化対決って感じでは。

Arena使って素朴に書かれたbinary-treesが勝ってるのは結構すごいと思う。

**デフォルトの名無しさん** · 2019/05/22(水) 23:12:51.32

railcar誰も使っちゃいねえ。。

**デフォルトの名無しさん** · 2019/05/23(木) 00:44:51.06

そりゃ互換実装なんてよっぽどメリットがないと使われないでしょ。
railcarは完全互換ですらなかったし。

firecrackerとかlucetみたいな独自路線の方がまだ見込みあるんじゃない？

**デフォルトの名無しさん** · 2019/05/23(木) 02:30:59.97

googleに中国人社員どれくらい居るんやで

**デフォルトの名無しさん** · 2019/05/23(木) 08:04:07.84

>>757
オーバーヘッドもなくセキュリティー的にも安定な実装というメリットがある
はず。

**デフォルトの名無しさん** · 2019/05/23(木) 20:26:15.35

http://yaneuraou.yaneu.com/2019/05/23/3%e5%b9%b4%e4%bb%a5%e4%b8%8a%e8%aa%b0%e3%82%82%e7%99%ba%e8%a6%8b%e3%81%a7%e3%81%8d%e3%81%aa%e3%81%8b%e3%81%a3%e3%81%9f%e6%8e%a2%e7%b4%a2%e9%83%a8%e3%81%aebug%e3%81%8crust%e3%81%ab%e3%82%88%e3%81%a3/
C++をRustで書き直したらバグ発見とのこと
なかなか面白いな

**デフォルトの名無しさん** · 2019/05/23(木) 22:26:59.74

コンバイル時かと思ったら実行時の検知かよ…

**デフォルトの名無しさん** · 2019/05/24(金) 06:57:29.74

GitHub’s Top 100 Most Valuable Repositories Out of 96 Million
ttps://hackernoon.com/githubs-top-100-most-valuable-repositories-out-of-96-million-bb48caa9eb0b
rust 5位だてよ

**デフォルトの名無しさん** · 2019/05/24(金) 19:43:59.31

ランキングもベンチマークもいくらでも恣意的に操作できる

実際に製品としてどんくらい世に出たかが全てだけど
Rustはどこの企業も口を揃えて「内部実装で使ってます」って言うだけで
動いてるコードを見たことがない

**デフォルトの名無しさん** · 2019/05/24(金) 21:19:42.85

>>763
企業で使ってもクローズドソースならそもそも何使っても見れないんじゃない？

**デフォルトの名無しさん** · 2019/05/24(金) 21:38:08.75

AWS https://github.com/firecracker-microvm/firecracker
Fastly https://github.com/fastly/lucet
Dropbox
Microsoft https://github.com/Azure/iotedge https://github.com/dropbox?utf8=%E2%9C%93&;q=&type=&language=rust
Intel https://github.com/intel?utf8=%E2%9C%93&;q=&type=&language=rust
Cloudflare https://github.com/cloudflare?utf8=%E2%9C%93&;q=&type=&language=rust

恣意的に集めてみたけど使ってる証拠にはなれないんだな

**デフォルトの名無しさん** · 2019/05/24(金) 22:02:14.23

全く使う気にならないツールばっかりってのがすげーな。

**デフォルトの名無しさん** · 2019/05/24(金) 23:06:53.82

俺もAWSは使う気になれんな

**デフォルトの名無しさん** · 2019/05/25(土) 01:14:49.01

プロダクトがあるか無いかより、「xxxで作ってたものをrustで作り直したよ！」って話が多いのが気になる
既存の作り直しよりも新規性のある何かが出来て、それを皆が使いたくなって言語が広まるってのが普通だと思ってる
(goならdockerとか)
rustでそういうのがまだ見えないのはちょっと嫌な感じはしてる

**デフォルトの名無しさん** · 2019/05/25(土) 01:27:20.73

もともとC++は辛いので作り直せる言語を作ろう
だからしょうがないんじゃない

**デフォルトの名無しさん** · 2019/05/25(土) 04:03:12.09

C++はまだ進化中(複雑化中)だし、C++使ってる分野では特に移行する必要がないというか

**デフォルトの名無しさん** · 2019/05/25(土) 15:49:15.59

Rustは学習を終えたとしてC++より開発効率良いの？

**デフォルトの名無しさん** · 2019/05/26(日) 15:37:50.13

>>768
重箱の隅で申し訳ないが、Goなのはk8sだと思う

Rustでキラーアプリ出ないのはある意味当然で
そういうものって未完成でもとりあえずぶち上げてコンセプト見せないと流行らないんだが
Rustって真逆で完璧に作らないと動かない言語だから
キラーアプリの作成とそもそも相性が悪い

**デフォルトの名無しさん** · 2019/05/26(日) 18:38:24.59

つまりrustで作られたものは完全無欠ってこと？
そんなばかな

そもそもなんでメジャーな採用事例を気にする必要があるの？
自分が作ってるプロダクトがrustと相性がよければ使えばいいだけじゃん

**デフォルトの名無しさん** · 2019/05/26(日) 18:55:54.46

キラーアプリってあれか
RubyがRailsで人気爆発あるいは
ディープラーニングやるならPython
みたいな話期待してるのか？

**デフォルトの名無しさん** · 2019/05/26(日) 19:11:37.22

C++にはキラーアプリがないと思うけどそれでいいと思う

**デフォルトの名無しさん** · 2019/05/26(日) 19:12:42.72

そもそもキラーアプリが言語の普及に影響したのってRailsくらいだと思うけど。
別にdockerやk8sのユーザがgoで実装しなければならないってことはないでしょ。

**デフォルトの名無しさん** · 2019/05/26(日) 19:57:50.92

>>771
rustで学習を終えてc++で作るのが一番効率が良い。
つまり学習用と割り切ればかなり意味のある言語ではある。

**デフォルトの名無しさん** · 2019/05/26(日) 20:11:18.02

メモリエラーを気にするならfortran使えば？

**デフォルトの名無しさん** · 2019/05/26(日) 21:40:26.71

Kotlinもよろしく

**デフォルトの名無しさん** · 2019/05/26(日) 21:46:53.56

C++で痛い目にあってからRust覚えた後にC++の最新verに戻るのが最適解

じゃないとRustの諸々の安全装置がなぜあるか理解し難く面倒臭いだけと思われてしまう

**デフォルトの名無しさん** · 2019/05/27(月) 11:56:38.15

C++に戻るつもりが戻れなくなってしまったな。
最新ならC++の言語機能には特に不満はないけど、標準のテスト・ビルドツール・パッケージマネージャがないのが辛すぎる。
戻った人たちはその辺どうしてるんだろう…。

**デフォルトの名無しさん** · 2019/05/27(月) 12:07:35.18

困ってない
標準にこだわる理由は？

**デフォルトの名無しさん** · 2019/05/27(月) 12:32:08.94

いろんなOSSを触ってるとプロジェクト毎に独自の流儀で、それぞれにいちいち合わせるのが面倒だし、
新規プロジェクトでも何を採用するかで悩む。
別に標準化とかされなくてもデファクトスタンダードが一つに決まってれば十分なんだけど。

**デフォルトの名無しさん** · 2019/05/27(月) 23:24:40.87

C++とくらべりゃRustのほうがスッキリしてるやろ
Cのほうがもっとスッキリしてるけど

**デフォルトの名無しさん** · 2019/05/27(月) 23:28:30.02

cargoが糞すぎて標準だと困る。

**デフォルトの名無しさん** · 2019/05/28(火) 03:03:23.56

> 標準のテスト・ビルドツール・パッケージマネージャ

最近のプログラミング言語はそれぞれがこのシステム作るよな
言語を超えた協調もなく

**デフォルトの名無しさん** · 2019/05/28(火) 06:25:30.00

意味わからない
どゆこと？

◆QZaw55cn4c · 2019/05/28(火) 08:13:08.53

>>786
そりゃ、ライブラリの名前だけでも共用すればいいのに、と思いますがそれもできていないし…

**デフォルトの名無しさん** · 2019/05/28(火) 08:55:39.10

なんの意味が？？

**デフォルトの名無しさん** · 2019/05/28(火) 09:28:40.66

Ruby のBundler で、各プロジェクト毎に、異なる依存ライブラリを管理するのが便利だから。
それで、Node.js のnpm, yarn も同じように作った

他にも、Vagrant, Chef, Homebrew など、バージョン管理はRuby で作られる

**デフォルトの名無しさん** · 2019/05/28(火) 09:52:05.49

クソ言語のことは聞いてない。

**デフォルトの名無しさん** · 2019/05/28(火) 12:38:13.43

cargoで困ってない

**デフォルトの名無しさん** · 2019/05/29(水) 07:06:20.60

vagrantもchefもrubyで作られてるからだしょ？
そもそも言語じゃないし
何が言いたいのかさっぱり分からん

**デフォルトの名無しさん** · 2019/05/29(水) 07:23:51.85

「俺のやりやすいやり方に周りは合わせろ」ってことだろ。よくあるクソ意見だよ。

**デフォルトの名無しさん** · 2019/05/29(水) 12:18:00.52

Cargoは近年稀に見るクソパッケージ管理ツールだろ
これなら散々クソクソ言われてきたけど
最近pipenv出してきたPythonの方がマシまである

**デフォルトの名無しさん** · 2019/05/29(水) 19:28:54.53

具体性具体性

**デフォルトの名無しさん** · 2019/05/29(水) 21:05:22.23

https://keens.github.io/blog/2018/08/26/cargonodokogaiinoka/

ビルドとパッケージ管理を変に混ぜてグダってる。
こういう言語にありがちなビルド速度軽視が大問題。

**デフォルトの名無しさん** · 2019/05/29(水) 21:24:19.77

ひとつの仕事をうまくこなせと言いたい

**デフォルトの名無しさん** · 2019/05/29(水) 21:58:57.68

クソのクソクソにありがちなグダっぷり？

**デフォルトの名無しさん** · 2019/05/30(木) 03:54:53.60

ビルド速度が遅いビルドツールの代表のsbtより遅いのがクソ
crates.ioに強依存しててオフラインビルドができないのがクソ
gitに強依存しててアーカイブ形式で配布できないのがクソ
そもそもcrates.ioの運営がクソ

あといくつ欲しい？

**デフォルトの名無しさん** · 2019/05/30(木) 07:44:46.49

ビルド速度が遅いのをパッケージマネージャのせいだと、言語の違うものと比べて言われてもなんともな
crates.io関連はこれ
https://github.com/rust-lang/cargo/issues/5655#issuecomment-488347426
https://github.com/rust-lang/cargo/issues/6589
アーカイブ形式は無理っぽい
https://github.com/rust-lang/cargo/issues/1139#issuecomment-69398250
>The ABI for a library is not stable between compilations, even when theoretical ABI-compatible modifications are made.
あといくつ？