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/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.
あといくつ？

**デフォルトの名無しさん** · 2019/05/30(木) 10:14:12.88

gitへの依存ってあったっけ？
crates.ioからはソースアーカイブDLだから
gitプロトコルは使ってないと思うけど。

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

>>800
ビルド前のスクリプト実行は出来るのにビルド後のスクリプト実行が出来ない
も追加しといて

**デフォルトの名無しさん** · 2019/05/30(木) 13:11:59.05

勉強中なんだけど、rustってそんなにビルド遅いの？

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

>>804
「ビルドする度にコーヒーブレイク」と揶揄される某言語より遅い

**デフォルトの名無しさん** · 2019/05/30(木) 18:35:37.13

>>805
いやあれよりは速いよ
まあかなり遅い部類に入るのは認めるが…

**デフォルトの名無しさん** · 2019/05/30(木) 18:51:26.08

某言語って何？
いじわるしないで教えろよ！

**デフォルトの名無しさん** · 2019/05/30(木) 19:15:07.85

遅さではscalaが有名かな
まぁrustが遅いのは遅い

**デフォルトの名無しさん** · 2019/05/30(木) 19:56:11.95

前実測したけどscalaより遅かったぞ？
依存ライブラリ数の差の可能性はあるが

**デフォルトの名無しさん** · 2019/05/30(木) 21:43:56.76

scalaとビルド速度競ってる時点でお察しのクソ言語

**デフォルトの名無しさん** · 2019/05/30(木) 22:00:45.60

まあ仕事で使ってなきゃビルド時間なんか気にならんもんな。
遊びでやってる層にはコンパイル時になんでもやるってのは受けがいいんだろ。

**デフォルトの名無しさん** · 2019/05/30(木) 22:15:09.45

ていうか何をビルドして計ってるんだよ…
一切出てこないまま話は進んでるのか？

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

折角なのでHelloWorldのコンパイル速度比較してみた。
まぁ条件は適当なので参考程度だが。
毎回ビルドキャッシュ削除した状態からの10回平均。

C: 41.9ms
C++: 150.9ms
go: 211.4ms
D: 307.3ms
Rust: 320.1ms
Java: 346.5ms
Erlang: 1005ms
Haskell: 1106ms
C#: 3000ms
Scala: 6712ms

こうしてみるとCは異常に速いけど、Rustはまぁ普通と言ってもいいかもね。

**デフォルトの名無しさん** · 2019/05/30(木) 22:53:48.96

そういうことじゃねーよばか。。

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

ビルドが遅いのはコンパイラの遅さだから根本的には別問題。
cargoがロクに並列ビルドできないのもこっち側。

>>800,801
- 不要な条件付きの依存関係が要求されてビルド/テストできない
- rustup wrapperが遅すぎて色々タイムアウトする

が抜けてる。issue乱立しすぎて最新のissueがどれか分からんからリンクは貼らん。
無駄にissue分けすぎて他にも細かいのが色々あるけど、結局は中央リポジトリに依存しすぎ、オフラインモードが使い物にならない、
パッケージマネージャとビルドツール融合してどっちとしても使い物にならないに集約される。

>>804
intellij rustがon the fly analyze実装したから設定から有効にして試せばいいよ。
サンプルプロジェクト程度じゃ影響ないから実践に近いプロジェクトで試さないと分からないけど。

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

しかし実際遅さが気になるプロジェクトってどんなサイズ？
普段開発してるソース1万行で依存クレート100個くらいの規模だと気になったことがないんだけど。
もちろんクリーンな状態からの初回ビルドはそれなりにかかるけど、ソース書いてるときに依存クレートの再ビルドってほぼ発生しないし。

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

>>814
どゆこと

**デフォルトの名無しさん** · 2019/05/31(金) 02:33:21.46

rustで競技プログラミングが流行りだす？

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

>>818
ないない
競プロはメモリリークしてようがコーナーケースでバッファオーバーフローしようが
とにかく規定の入力に対して速く答えを返すものを
エラーハンドリングとか考えず手早く実装するのが正義
Rustと一番相性が悪い分野だろ

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

>>815
端的に集約するとそれだよな
未だにこれが「他の言語のパッケージマネージャーの良いところを集めて地雷を回避した理想的なパッケージマネージャー」とか言ってるやつは
それこそ金掴まされてるとしか思えんくらいにクソ

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

困るのは分かったけどなんで困るの？
2年くらい仕事で使ってるけどあーカーゴって便利だなぁとしか思ってなかったわ

**デフォルトの名無しさん** · 2019/05/31(金) 07:02:13.86

明らかにMozillaに金掴まされたな

**デフォルトの名無しさん** · 2019/05/31(金) 07:10:00.14

それならRustの歌でも作って武道館で歌うくらいやるけどなあ

**デフォルトの名無しさん** · 2019/05/31(金) 07:39:44.03

笛吹こうぜ

**デフォルトの名無しさん** · 2019/05/31(金) 08:06:14.65

なんでMozillaは俺には金掴ませてくれないの？

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

なんかもうちょっと具体的に
こういうことやると苦労する破綻するという例が欲しいな
他の言語やツールとの同等のことやろうとした比較があるとなお良し

**デフォルトの名無しさん** · 2019/05/31(金) 10:42:30.35

困る人は是非積極的にcargoにissueたてるなりpull req送って欲しい
人的リソースが足りないのよ

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

Mozillaに金掴まされてるは例のキチの常套句だったなそういえば

>>826
まずcrates.ioそのものは、使う側じゃなくてライブラリ公開する側になったらクソだとわかる
こればっかりは使って体験してくれとしか言えん

ビルドの遅さは、例えばDockerみたいなコンテナの相性がよろしくない

crates.ioに強依存してるから、aptでいうところのsquidみたいなことができない

これらの問題はカジュアルユースなら問題にはならんだろうが、プロユースには耐えんのよ

**デフォルトの名無しさん** · 2019/05/31(金) 14:27:52.82

aptでいうsquid？ミラーがほしいってこと？
俺の周りのプロはもうそんなことやってないけど。。。
multi stage buildでもしたらいいんじゃないの

**デフォルトの名無しさん** · 2019/05/31(金) 15:23:30.26

それはプロユースに耐えんのではなくて、そういう職場もあるってだけの話では？
crates.ioは複数ライブラリ公開しててもクソさが分からんしなぁ。
逆にこのパッケージリポジトリは素晴らしい、とかあるの？

**デフォルトの名無しさん** · 2019/05/31(金) 16:38:04.16

>>828
ビルドが遅いという以外何が問題と言ってるのかわからん

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

それで十分だろ。
それがわからんやつはboostマンセーして人に迷惑かけてもなんとも思ってない馬鹿と同列にしか思わん。

**デフォルトの名無しさん** · 2019/06/01(土) 00:03:29.85

出来上がったバイナリが速ければ問題ないんじゃない?

**デフォルトの名無しさん** · 2019/06/01(土) 00:43:37.39

せ…せいさんせいがおちるだろう！

**デフォルトの名無しさん** · 2019/06/01(土) 03:16:17.57

rustを良い言語だと評価してるやつはrustとより酷い言語しか使ったことないんだろうよ、VBAとか

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

最初から期待している点は2つ
１つはHaskellで実証されてる、型システムが豊かであることの安全性と利便性をC並みに低レベルな世界に持ち込んで組み込み業界に1石を投じること
もう一つはオブジェクト指向を言語仕様に取り込まなくてもオブジェクト指向でやりたいことの大部分は実現可能だと証明して、OOPパラダイムを衰退させること

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

とあるツールをcargoでビルドしたら、同じcrateが重複してバージョン違いで使われてて驚いた
そんなのアリなんか

Compiling env_logger v0.5.13
Compiling env_logger v0.6.1

**デフォルトの名無しさん** · 2019/06/01(土) 08:29:18.06

a crateとb crateがそれぞれ違うバージョンに依存してたらそうなるだろう
アリというかそうじゃなきゃ困るだろう
そうじゃない言語もあるけど

**デフォルトの名無しさん** · 2019/06/01(土) 11:57:29.44

hogehoge-sys みたいな外部のライブラリに依存するcrateだと異バージョン混在できなくてつらい
.soを実行時にリンクする都合上仕方ないのだけど

**デフォルトの名無しさん** · 2019/06/01(土) 12:06:40.79

絶対に
絶対に
所有権の移動のほうに記号がつくべきだった

**デフォルトの名無しさん** · 2019/06/01(土) 13:12:39.72

>>836
それ以外の部分がクソ過ぎてやっぱダメだわってなってるのが今
以前はこのスレにRustへの苦言かきこんだらボロクソに言われたもんだが
今では俺以外にもRustはクソって声が増えてる。良い傾向

**デフォルトの名無しさん** · 2019/06/01(土) 13:23:53.53

rust好みだよ。

**デフォルトの名無しさん** · 2019/06/01(土) 15:12:11.38

まあ使ってみないと本当の意味でダメさ実感できないからな。
実際にさわってみたやつが増えて夢から醒めたんだろｗ

**デフォルトの名無しさん** · 2019/06/01(土) 15:22:24.76

とある言語についてはいかがかと思う節もあるな～

**デフォルトの名無しさん** · 2019/06/01(土) 15:47:56.02

これ以上バカを現場に増やさないためにプログラム教育にはビルドって科目も入れるべきだな。

**デフォルトの名無しさん** · 2019/06/01(土) 16:00:35.35

お前にとってクソで大嫌いなのはわかったから冷静になれよ

**デフォルトの名無しさん** · 2019/06/01(土) 16:20:56.50

>>840
それは無理があるんじゃないか？
&で借用が妥当だと思うけど

&は借用の記号と同時に型の情報としての意味も有るはずだから
その点で問題が起きると思うが…

**デフォルトの名無しさん** · 2019/06/01(土) 16:33:15.53

例えば移動に記号をつけようとすると
T型と&mut T型の変数を移動する際はそれに全部記号を付ける羽目になるぞ
それでも良いのか？
ちなみに&T型は移動ではなくコピーなので除外したがコピーであって借用ではない
>>840はコピーはどうすべきだと思っているが知らないが
コピーにも記号を付けろと言うならさらに面倒なことになる
本当にそれでも良いのか？

**デフォルトの名無しさん** · 2019/06/01(土) 16:42:00.32

'=' の現状のrustの意味の統一を考えれば現状の仕様が妥当だわな。

**デフォルトの名無しさん** · 2019/06/01(土) 17:26:39.90

まだ他にも問題はあるぞ
例えば移動をmoveで借用を記号無しにすると
let a = 1_i32;
でaはi32型でなく&i32型になる。なぜなら記号無しは借用だから。
aがi32型になるためには
let a = move 1_i32;
と書かなければならない

さらに言うと
let a = move 1_i32;
let b = a;
let c = b;
でaはi32型、bは&i32型、cは&&i32型となるわけだ

俺はそんなヤバイ言語は使いたくないぞ

**デフォルトの名無しさん** · 2019/06/01(土) 17:43:27.50

この際に言いたくなったから言わせてもらうけど
時々「俺の方が良い言語作れる」とか言ってるヤツがいて
それに対する反論に「じゃあコンパイラ作ってみろよ」とか返してるヤツいるけど
そもそもコンパイラを作る実力が有るか無いか以前に
言語をデザインすることの難しさを分かってないヤツが多すぎて
コンパイラを作る段階にも至っていないっと思うわけよ

**デフォルトの名無しさん** · 2019/06/01(土) 18:30:16.77

俺は言語を作るセンスないし他のやつもなさそうだしお前にもなさそうだからこの話題はやめとこな
不毛だからな

**デフォルトの名無しさん** · 2019/06/01(土) 19:00:35.54

>>850
記号なし=はコピーで統一したらよい
Ｃ＋＋はやってるじゃん

**デフォルトの名無しさん** · 2019/06/01(土) 19:10:56.29

>>853
ポインタの基本をコピーじゃなくてムーブにしたいからムーブの方を記法的に容易にしたんだし、auto_ptrのセマンティクスの非統一による悲劇を避ける為にムーブに統一したんだよ？
議論の順番が滅茶苦茶だぁ

**デフォルトの名無しさん** · 2019/06/01(土) 19:13:31.38

uniqueとshareでなんとかなってるじゃん

**デフォルトの名無しさん** · 2019/06/01(土) 19:14:05.19

メモリ以外のリソースはコピーできないものが大半じゃね？

**デフォルトの名無しさん** · 2019/06/01(土) 19:14:44.62

変数がどの範囲で利用可能なのかぱっと見わからんのが酷すぎる

**デフォルトの名無しさん** · 2019/06/01(土) 19:16:22.51

>>856
コピーできないようなまとまったオブジェクトをほいほい変数移さないだろ

**デフォルトの名無しさん** · 2019/06/01(土) 19:18:22.75

>>853
取り敢えず借用を記号無しにするのは無理であることは納得してくれたの？

そして移動はどうするの？rustだと移動も結構しょっちゅう使うんだけど…
例えばBox型とかString型とかVec型とか&mut T型とか…
移動もコピーもどちらも=なのが判りづらいってのは一理有るんだけど、
それらの移動に全てmove等の記号をつけていくのはあまりにも面倒だと思うよ

**デフォルトの名無しさん** · 2019/06/01(土) 19:21:21.72

>>857
ぱっと見でわかるってどんな感じなの？

**デフォルトの名無しさん** · 2019/06/01(土) 19:29:50.41

>>860
所有権を手放すときに記号つく

>>859
そっちを&にして
右辺値が無名で宙ぶらりんのときはつけないでいいことにしたら

**デフォルトの名無しさん** · 2019/06/01(土) 19:36:06.88

>>861
そっちってどっち？移動を&にするの？じゃあ借用はどうするのよ？
さっぱり言ってる意味が分からん
てか最初の質問に答えてくれないかな？納得したの？してないの？

**デフォルトの名無しさん** · 2019/06/01(土) 19:40:22.13

>>862
してない。俺も言ってることよくわからん