プログラミング言語 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/04(月) 03:56:46.84

asmjsが早いんだからランタイム側の対応が十分進めばwasmも早くなるでしょ

**デフォルトの名無しさん** · 2017/09/04(月) 10:53:07.99

>>719
Rustなんて実用にならない言語未満使うくらいなら、クソとはいえ言語の体なしてるJS使うわクソ

**デフォルトの名無しさん** · 2017/09/04(月) 12:07:05.02

好きな言語を使ったらええ

**デフォルトの名無しさん** · 2017/09/04(月) 20:51:30.52

お前らslackにまけとるやんけ

**デフォルトの名無しさん** · 2017/09/04(月) 23:53:57.54

いつの間に戦っていたのか

**デフォルトの名無しさん** · 2017/09/05(火) 02:01:35.76

Hack&Slack

**デフォルトの名無しさん** · 2017/09/05(火) 04:46:57.50

@seanmonstarがMozillaを辞めるとか言いだして一瞬ギョッとしたけど、次の職場ではフルタイムでRustを使うと言っているからhyperの開発はむしろ加速しそう？
http://seanmonstar.com/post/164869651177/bye-mozilla-hello-bouyant

**デフォルトの名無しさん** · 2017/09/05(火) 07:50:37.72

rustってまだ俺の中で実験言語だけど
そろそろプロダクト作ってる人とか出てる？

**デフォルトの名無しさん** · 2017/09/05(火) 10:31:25.11

>>727
噂では泥箱あたりが使い倒してるとか
ずっと前から言われてるけど未だにコードの一つも公開されてないからただの提灯持ちで実際は使われてないと見てるがね

**デフォルトの名無しさん** · 2017/09/05(火) 10:34:56.85

Rustが1.0過ぎてから今に至るまで、Rust使ってるって主張する企業は
モジカス自身と個人情報おもらしの一件で何かしら話題とお金が欲しい泥箱しか見ないって時点で色々と察するべきなんだよ

お前らいい加減目を覚ませ

**デフォルトの名無しさん** · 2017/09/05(火) 12:37:41.86

https://www.rust-lang.org/en-US/friends.html

**デフォルトの名無しさん** · 2017/09/05(火) 13:37:05.48

見たことのないフレンズばかりだね

**デフォルトの名無しさん** · 2017/09/05(火) 14:44:43.29

>>730
そのうちモジラのフロント企業じゃないのはいくつだい？

**デフォルトの名無しさん** · 2017/09/05(火) 14:48:42.01

ID:Xe9ypjwu
この異常者まだ居たのか

**デフォルトの名無しさん** · 2017/09/05(火) 16:16:47.13

LINEはモジラのフロント企業

**デフォルトの名無しさん** · 2017/09/05(火) 17:49:37.05

dropboxやsamsungもmozillaのフロント企業の可能性が・・・？
実はmozillaってすごい会社なんじゃね

**デフォルトの名無しさん** · 2017/09/05(火) 19:27:40.10

rustっていまいち売りがないよな。
ちょっとしたツールを作るっていうのには向いてない気がする。
Goくらいの適当言語がちょうどいい。

**デフォルトの名無しさん** · 2017/09/05(火) 19:44:37.37

ちょっとしたではなく、きちんとしたソフトウェアを書くための言語だよ

**デフォルトの名無しさん** · 2017/09/05(火) 19:51:45.33

Rustは、型システムがきちんとしてないとイライラしてしまう人向けの言語だよ

**デフォルトの名無しさん** · 2017/09/05(火) 23:06:17.75

システムに近いところを触るバックエンドのデーモン等に向いた言語だよ

**デフォルトの名無しさん** · 2017/09/06(水) 00:48:38.63

SIGSEGVに絶望したくない人のための言語

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

パッケージのインストールだけで長時間かかるのだけ何とか改善してくれる神様たちっていないんですかね
issueにそういう要望とか出ないものですかね

**デフォルトの名無しさん** · 2017/09/06(水) 10:49:22.58

前にも出てたけど、CARGO_TARGET_DIRを設定すればさっきそれコンパイルしたじゃん！ってのが無くなる
まあコンパイルそのものは遅い方だからそれは我慢する

**デフォルトの名無しさん** · 2017/09/06(水) 16:57:20.79

Celeronの1コア、メモリ1GBなのでパッケージによっては5時間経ってもコンパイルが終了しないんですよね
例えばclippyとか。
パッケージのアップデート毎に結局更新されたものをコンパイルし直すからCARGO_TARGET_DIRの設定してもあまり変わらないような気もします
Core i7やryzen、メモリ8GBとかだともっと早く終わりますかね？

**デフォルトの名無しさん** · 2017/09/06(水) 17:03:33.32

お前には Core 2 Duo がお似合いだ

**デフォルトの名無しさん** · 2017/09/06(水) 18:26:50.13

コンパイラ、コンパイラドライバ、パッケージマネージャをそれぞれ独立して利用しやすくして欲しい
ポストC/C++を目指しているはずなのに言語仕様と関係のない制約が増えるのは勘弁

**デフォルトの名無しさん** · 2017/09/06(水) 18:51:54.27

https://github.com/mozilla/sccache

**デフォルトの名無しさん** · 2017/09/06(水) 19:10:48.28

>>745
java, phpが独立した3rd tools乱立でひどいことになったから
次世代は低レベルと高レベルの2レイヤーを公式に提供しようぜって現代の風潮でそれに沿ってると思うが
あいつら個々に独立したビルドシステム, テスター, パッケージマネージャー, ランチャーが乱立して辛い
rustやgoは公式で色んなものが利用しやすく整備されてて涙が出るよ, マジで

rustの公式ツールに不満があるなら3rd toolsを自分で作れば良いよ
誰も作るなとは言ってなくて、作ること自体は止められないはず、賛同する人がどれほどいるのか懐疑的だけど

**デフォルトの名無しさん** · 2017/09/06(水) 19:12:16.98

低レベル:rustc, 高レベル:cargo って意味な

**デフォルトの名無しさん** · 2017/09/06(水) 19:37:16.90

Rust＝Cargoな感じになっているように思うのは俺だけなのか？とりあえずCargoを使え的な記事ばかりでrustcを活用する記事はほとんど見ない
ちょっと高度な事をしようとすると絶望的に情報がない。さらにrustcの不安定性(機能しないオプションがある)が追い打ちをかけるｗ

**デフォルトの名無しさん** · 2017/09/06(水) 20:12:23.66

まあ今のRustとmakeを組み合わせようとはちょっと思えないな

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

ビルドにcmakeを要求するのに、エラーメッセージが分かりづらくて
はっきりとcmakeの必要性が分からないcrateが結構ある

依存ライブラリ一つ一つまでreadme読まないし

**デフォルトの名無しさん** · 2017/09/06(水) 20:57:11.59

cargo３兄弟

**デフォルトの名無しさん** · 2017/09/06(水) 21:15:39.15

build.shからmake叩いて、更にmakeからant叩いてたjava全盛期に比べれば多少はね
cmakeの代わりにbuild.rs(及びgcc-rs)使えば良いんだろうけど、build.rs書くの面倒でcmakeに走ってる予感

gcc-rsの機能拡張としてファイルパターンマッチ的なものが提供されたらcargoからcmakeも駆逐されるかもねー
あんまりbuild.rs使わないから既にデファクトスタンダードなcrateが存在してたらすまぬ

**デフォルトの名無しさん** · 2017/09/06(水) 21:32:03.27

そこまで分かっててなんでRust使い続けようと思うんだお前ら……

**デフォルトの名無しさん** · 2017/09/06(水) 21:35:26.17

cargoが便利だから

**デフォルトの名無しさん** · 2017/09/06(水) 22:38:49.71

https://blog.rust-lang.org/2017/09/05/Rust-2017-Survey-Results.html
ところで夏サーベイの結果出てるな

分かってたがNightlyの使われっぷりに吹く

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

だってRust会社で使えないしーが1位でRustむずいよーこわいよーが2位か

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

CrateがCargo前提になっていて他のビルドマネージャやrustcからは実質的に使えないよな？

**デフォルトの名無しさん** · 2017/09/07(木) 10:39:04.19

cargoって裏でやってることはrustcのラッパじゃなくて独自の方法でコンパイルしてるのか？
ひでえ仕様だな

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

>独自の方法でコンパイルしてる
そんなことはないはずだが、どこからそんな情報が出てきたんだ？

**デフォルトの名無しさん** · 2017/09/07(木) 21:46:15.77

crateが実質cargo専用になってるってbuild.rsとかその辺のことか？

**デフォルトの名無しさん** · 2017/09/07(木) 22:56:42.47

crates(.ioからのダウンロード、及び、crateの依存解決/分割ビルド)が実質cargo(コマンド)専用と言いたんじゃないのかな
curlでダウンロードして、rustcで.rlib作る分割コンパイルすれば出来なくはない
cargoコマンドのコードは開示されてるから自分で頑張れ, https://crates.io/crates/crates-io

rustcを使いこなせずcargo未満/rustc以上ツールの車輪の再発明を熱望する無能と
rustのコンパイルできるコードを書けず挫折したアンチが合わさり話が明後日に向かっておるわ

**デフォルトの名無しさん** · 2017/09/07(木) 23:20:58.99

cargo install に download-only オプションがつけばいい流れ？

**デフォルトの名無しさん** · 2017/09/08(金) 00:39:59.57

>type hello.rs
fn main() {
println!("Hello World!");
}
>rustc -V
rustc 1.19.0 (0ade33941 2017-07-17)
>rustc hello.rs
>rustc -v hello.rs
>
-vが効いていないように見えるけど仕様なの？
コンパイラやリンカに与えられているオプションとかを見たいんだけどどうしたらいい？

**デフォルトの名無しさん** · 2017/09/08(金) 03:12:39.89

rustc -Z print-link-args hello.rs

https://github.com/rust-lang/rust/issues/36175

**デフォルトの名無しさん** · 2017/09/08(金) 07:52:33.56

それはnightly限定ですやん

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

スコープでインスタンスの寿命を静的に管理しようってのは面白いと思うのだが、
再帰的な構造とか扱う場合の簡易さをも少し考えるべきだったね。

まああんまこだわらなければ結構使いやすい気はするけど。

**デフォルトの名無しさん** · 2017/09/08(金) 16:10:21.35

こだわるも何も木構造まともに書き下せない言語の用途ってなんだよ

https://amp.reddit.com/r/rust/comments/33jv62/vecrcrefcellboxtrait_is_there_a_better_way/
この辺の問題も一行に解決してないし

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

まあ raw pointer 使えば何とでもなるし（震え声）。

**デフォルトの名無しさん** · 2017/09/10(日) 15:21:33.90

木構造は書けるでしょ
難しいのは巡回するグラフ構造

**デフォルトの名無しさん** · 2017/09/10(日) 16:53:04.07

>>770
木構造の一番いいサンプルおしえてよ

**デフォルトの名無しさん** · 2017/09/10(日) 21:30:15.59

木にせよ一般のグラフにせよライフタイム管理が面倒くさい

**デフォルトの名無しさん** · 2017/09/10(日) 22:30:44.85

この辺とか？
http://agtn.hatenablog.com/entry/2017/01/16/151745
ただ入れる操作によっても RefCell にしたり、やっぱり面倒は面倒。

**デフォルトの名無しさん** · 2017/09/11(月) 00:36:42.39

ぐええ、隣接リストとアリーナの違いがよく分からない

**デフォルトの名無しさん** · 2017/09/11(月) 06:43:38.80

768はこれがまともじゃないっていいたかったんでしょ。

**デフォルトの名無しさん** · 2017/09/11(月) 10:26:55.85

CやC++ならポインタ持っておくだけで簡単に実現できるのに……

**デフォルトの名無しさん** · 2017/09/11(月) 23:14:03.66

C++使うか、unsafe使えば良いのでは

**デフォルトの名無しさん** · 2017/09/11(月) 23:14:47.15

Rc+RefCellな型を用意するだけでもマシになるか

**デフォルトの名無しさん** · 2017/09/12(火) 00:26:37.00

ていうか練習ならともかく実際に使うプログラムでポインタをつないでグラフを表現することなんてそんなに頻繁にあるか？
取りうる表現の中で効率性が最悪な部類じゃん
Vecに対するLinkedListみたいなもんだろこれ

**デフォルトの名無しさん** · 2017/09/12(火) 01:20:27.09

オブジェクト指向っぽいAPIを触るときはだいたいその形にならない？

**デフォルトの名無しさん** · 2017/09/12(火) 03:08:23.10

グラフの時だけ、ガベコレ使えるGc型が欲しい

**デフォルトの名無しさん** · 2017/09/12(火) 08:30:34.06

じゃああんたは現実世界でツリー構造のものをどうやって表すの？

**デフォルトの名無しさん** · 2017/09/12(火) 11:30:27.08

>>779
VecじゃなくあえてLinkedList使う場面普通にあるんだが……

**デフォルトの名無しさん** · 2017/09/12(火) 14:48:49.21

linux の赤黒木の実装はポインタベースではあったな。
しかし個人的には配列実装のが結局速いって気はする。

**デフォルトの名無しさん** · 2017/09/12(火) 15:07:56.52

Effective Hogeでそういうことは言及されてるけど
Rustはどうだかなとドキュメント見たらSecond Editionで"Effective Rust"の節自体が削られとる:-(
Stack vs Heapはどこかに記述されてた覚えがあるから、ツリー/リスト操作もどこかに潜り込んでるのかなぁ

**デフォルトの名無しさん** · 2017/09/12(火) 17:41:48.32

配列ベースの実装はポインタの代わりにindex使うだけだからできることはあんまり変わらんわな
配列の方がデータの局所性高そうで速そうではある

**デフォルトの名無しさん** · 2017/09/12(火) 18:02:30.56

データ構造によって速い操作が違うという基本的な概念がない奴おるな

**デフォルトの名無しさん** · 2017/09/12(火) 18:50:57.82

vectorのmutabilityの問題があるの理解できてる？

**デフォルトの名無しさん** · 2017/09/12(火) 18:53:28.85

>>779
効率ってなんの効率？

**デフォルトの名無しさん** · 2017/09/12(火) 22:05:08.25

>>787
まあそういう無能がありがたがる言語なんだろうなRust

**デフォルトの名無しさん** · 2017/09/12(火) 22:20:04.05

mutabilityはRefCell使えば良いのでは
Refcell使わずにVecの中身を直接触る必要ある？

**デフォルトの名無しさん** · 2017/09/12(火) 22:27:17.20

>>791
いや、それでいいかも
rcさえなくなればborrowをユーザに書かせなくてすむからそれでいいや

**デフォルトの名無しさん** · 2017/09/13(水) 14:03:19.87

低レイヤーできます！ってアピールしたい言語なんだろうけれど、
あんま向いてない言語な気はする。

**デフォルトの名無しさん** · 2017/09/13(水) 14:56:53.13

低レイヤを書くにはチェッカーが強すぎて邪魔で、高レイヤを書くには全くカジュアルさがない
どっちにもなれない哀れな言語よ

**デフォルトの名無しさん** · 2017/09/13(水) 18:10:30.60

並列で大規模で低レイヤーな領域に向いた言語だからどれか一つでも欠けてる領域で使いづらいと思うのは仕方ない

**デフォルトの名無しさん** · 2017/09/13(水) 20:06:39.58

低レイヤーはやっぱC言語だな。
ポインタの習得が難しい事以外に欠点ないじゃんこの言語。
Rustはもっとポインタ扱いやすくして出直してきな。

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

rustの並列処理って言うほど特化(最適化)されてる気はしないけどな・・・
スレッド跨いだオブジェクトの所有権譲渡も保障されてはいるけど、従来言語/ライブラリに比べてめっちゃ便利という感じはしない
futures-awaitとかyieldを使うと変わるのかねぇ、無くても困りはしないしと使ってないけどfutures-awaitは使ってみるかな

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

C だっていろいろ批判はあるだろ。
型がゆるいとか、名前空間がグローバルしかないとか。
まあそれを差し引いてもやっぱ有効な言語と思うけど。

**デフォルトの名無しさん** · 2017/09/13(水) 20:49:43.29

>>798
Rustのコンパイル通す実力あるならCのその辺りの問題なんてないものと同じだから
Rustなんて使わずCでいいじゃんってなるんだよな

**デフォルトの名無しさん** · 2017/09/13(水) 20:52:03.57

とか思ってたら、yieldの方が公式nightlyにマージされたのか
futures-awaitもnightly要求するし素直にyieldの方を使ってみよ, stableにはいつ来るのかなぁ

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

今さら C はねえよ

**デフォルトの名無しさん** · 2017/09/13(水) 21:41:03.71

>>801
Rustよりはあるわ

**デフォルトの名無しさん** · 2017/09/13(水) 21:54:04.29

ID:6DzbMbn9っていつものモジラ/Rustネガキャン君だろ

**デフォルトの名無しさん** · 2017/09/13(水) 21:57:53.87

>>803
さすがにあのレベルの基地と一緒にされるのは心外

**デフォルトの名無しさん** · 2017/09/13(水) 22:09:43.33

いつものコンパイル通らなくて発狂してる基地外かと思ったわ

**デフォルトの名無しさん** · 2017/09/13(水) 22:45:06.07

コンパイラーよりも自分が信用できるならC使えばよいと思う

**デフォルトの名無しさん** · 2017/09/13(水) 23:56:44.36

Rustのコンパイルが通るならCを使えば良い君まだいたのか
自分の言葉通りRustに拘わらずにCを使っていれば良いのに

**デフォルトの名無しさん** · 2017/09/14(木) 08:18:50.41

macro_rules! make_macro {
($id:ident) => (
macro_rules! concat_idents!{test_, $id} {
}
);
}
make_macro!{foo}

こういうの無理なのか。

**デフォルトの名無しさん** · 2017/09/14(木) 11:10:13.14

EmacsでRLS使ってる人居る？

**デフォルトの名無しさん** · 2017/09/14(木) 11:12:19.23

>>799
そういう根性論嫌い

**デフォルトの名無しさん** · 2017/09/14(木) 12:55:00.43

RustやSwiftとかの次世代言語ってOracle製品やSAPみたいな所あるよな。
無駄に抽象化して変な専門用語作って、プリミティブなエンジニアを寄せ付けない感じとか。

コマンドラインで一発で出来るようなことを、独自用語だらけのGUIでポチポチ操作させてんの。
こういう文化は本当に良くない。優秀なエンジニアはみんな逃げてしまう。

**デフォルトの名無しさん** · 2017/09/14(木) 13:54:06.68

>>810
コンパイル時に全部解決しなきゃいかん
てな話のがよっぽど根性論だと思うが。

**デフォルトの名無しさん** · 2017/09/14(木) 17:19:47.64

人間が気をつけてコードを書けばバグが出ないはずというのは根性論では

**デフォルトの名無しさん** · 2017/09/14(木) 18:36:21.42

人に依存するC/C++は日本的
システムが面倒を見てくれるRustはアメリカ的

**デフォルトの名無しさん** · 2017/09/14(木) 19:05:26.17

バグが出ないことよりも手法に熱中しちゃう方が日本的だなとか思っちゃうけど。

**デフォルトの名無しさん** · 2017/09/14(木) 19:14:58.28

形容詞化する国名

**デフォルトの名無しさん** · 2017/09/14(木) 20:08:31.29

～的ってつければなんだって形容詞になるの？

人に依存するC/C++はC/C++的
システムが面倒を見てくれるRustはRust的

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

C/C++でもバグが出ないほど規模が小さい or 言語への習熟度が高いならC/C++使えばよいし
そうじゃないならRust使えば良いとしか言ってないのだが

**デフォルトの名無しさん** · 2017/09/14(木) 21:51:38.65

単純に「巡回グラフを始めとした自己再帰型のデータ構造を書き下せない（コンパイラが通してくれない）」って時点で、書けないプログラムの存在を認めてしまってるんだよなRustは

その上C言語にはValgrindやらcppcheckやら、金かかっていいならCoverityやら、いくらでもその手のツールはあるわけで、
Rustならではの点ってどこにもない割に欠点だけ目立つ訳よ

肝心の抽象化も機能足りてないしな。Nightly使えばなんぼかマシだが