- 1 名前：デフォルトの名無しさん [2012/01/25(水) 20:05:49.96 .net]
- Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。
www.rust-lang.org/
- 357 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 02:51:08.17 ID:0GQY2ef7.net]
- 論文に書いてあるのは「トレイトはクラスではなく、クラスを構成する部品である」ということなのはいいか？
「トレイトは型じゃない」とは一言も書いてないし、それ以前に型という単語すら使ってない。言及していない。
だから型じゃないと主張するなら、自分でその根拠を述べる必要があるのは分かってるか？
クラスの無い静的型付け言語のrustでのトレイトは、
1. 階層構造が無い、あるメソッドを定義すればそれに基づいたメソッドをstruct, enum, primitiveに与えるもので、
2. (Struct | Enum | Primitive) = State + Traits + Glueを満たすんだから、
論文にあるトレイトとほぼ同義。linear compositionができるんだから使い方も間違っちゃいない。
動的型付けでは曖昧にしていた所をはっきりさせれば、多相トレイトが自然であることも分かるだろ？
話を曖昧にしたがるあなたに付き合う必要は無いけれど、ついでに適当に書くよ。
Rubyのモジュールをミックスインしたクラスから生成されるオブジェクト全てを扱えるメソッドが書けるなら、モジュールは型とみなせる。
例えばFooモジュールを作るだろ？
module Foo
def bar
return "bar"
end
def baz(x, y)
return x + y
end
end
で、こいつをミックスインしたクラスのインスタンスを、例えばdef do_something(f) return (f.bar , f.baz(1,2)) endに渡せるんだろ？
ならインスタンスはパラメトリック多相なFoo型を単相化したもの、と呼べるだろ。
Foo型とはメソッドbar : () -> stringとbaz : int -> int -> intを持つもの全て、だ。
動的型言語の関数に対して、静的型言語の型注釈を無理なく与えようとしたら、
殆どの関数は多相型になり、多相性を制限するもの(haskellの型クラス, OCamlのモジュール+ファンクタ, rustのトレイト, Javaのアドホック多相かジェネリクス)が必要になる。
- 358 名前：デフォルトの名無しさん mailto:sage [2015/07/19(日) 18:51:02.73 ID:pLL2VJtZ.net]
- なるほど要するに
trait Foo {
fn bar(&self) {}
}
となってるときにselfの型はFooだからトレイトは型である必要があると言いたいわけだ
普通のトレイトはクラスにミックスインした時にコピーされるから
その時selfの型が決まるけどそうやって曖昧にすることを許さないと
でもその考え方はやっぱりトレイトと違う
一応論文のURLを貼っておくけど
ttp://www.ptidej.net/courses/ift6251/fall06/presentations/061122/061122.doc.pdf
8ページの図にあるTCircleとTDrawingがトレイト
白丸が提供するメソッドで右矢印が必要とするメソッド
9ページの図がトレイトのミックスイン
これがRustのトレイトと同じに見えるらしいけど
俺にはむしろ5ページの図にある多重継承の例がRustのトレイトだと思ってる
そこに多重継承の問題が書いてあって実装が重複すると書かれているけど
それを>>341で解決を試みているように見える
この流れだと多重継承もトレイトだとか言われそうだけど
そうなったらもう何も言えない
- 359 名前：デフォルトの名無しさん mailto:sage [2015/07/20(月) 21:03:10.22 ID:oqUyaDhZ.net]
- だーかーらー「思ってる」だけじゃなくて根拠を書いてくれ。どうしてrustのトレイトが多重継承と同じになるんだ？
例えば多重継承によって発生するdiamond problemをrustのトレイトを使って書いてくれ。
>>341で愚痴ったのは自分だが、あるトレイトTFooBarをimplすれば、自動的に他のトレイトTFooもimplしたことにしたい、という横着な欲求を実現しようとして、
(実現できたらtraitを使ってOOPのクラス継承を簡単に作れる)
impl<T> TFoo for T: TFooBar {...} と書いたら、自分の予想外の事態(TFooBazも同様にしたら、TFooBarとTFooBazの両方をimplした型はどうなる？)
をコンパイラが検出してエラーを出しただけの話だ。
普通に実装を羅列すれば問題ない。デフォルト実装を書けばimplにコードを書く必要もない。型SFooに対し、impl TFoo for SFoo {}と impl TFooBar for SFoo {} と書けばいいだけ。
多重継承の問題じゃない。implを多相にしたら範囲が広すぎて怒られただけの話。
rustのトレイトは、論文の通りで、継承はあるけどそれで階層構造を作るわけじゃない。
trait FooBar : Fooと書いたら、Fooの要求するメソッドをFooBarも要求する、Fooの提供するメソッドをFooBarも提供する、だけ。
impl FooBar for SFoo {...}でFooから受け継いだrequiredメソッドを書けないじゃないかと思うかもしれんが、
静的型付けの言語でFooBarとFooの関係を完全に切り離すのは利便性を下げるだけなのは分かるよな？
impl Foo for SFoo {...}と書くだけでSFooはFoo型としてもFooBar型としても扱えるようになるんだから。
- 360 名前：デフォルトの名無しさん [2015/07/20(月) 21:06:59.38 ID:XuKvM2I+.net]
- トレイトは多相性の制限という形で不変条件を表現してるものなんだから
>>357が正しいとしか思えんけどなあ。
- 361 名前：デフォルトの名無しさん mailto:sage [2015/07/21(火) 21:00:10.36 ID:Nw2FJ/oz.net]
- 論文の5ページの図は菱形継承とは関係無い
むしろ親クラスと子クラスの2階層でも問題があることを示してる
具体的には親クラス同士の連携のために親クラスに連携用のメソッドを追加する必要があること
その連携用のメソッドを子クラスで実装しなければならないことが書かれている
Rustが名前の衝突を許すせいで分かりづらいけど名前の衝突を避ければ>>348は
trait FooA {
fn foo(&self) { self.FooA_bar1(); self.FooA_bar2(); }
fn FooA_bar1(&self);
fn FooA_bar2(&self);
}
となってミックスインする時にFooA_bar1を呼んだらbar1を呼ぶように実装することになる
名前を同じにしようがtrait FooA: Barにしようが実装の数は変わらない
そしてこの連携のための実装は再利用が出来ない
>>350でこの問題の解決方法として>>341を挙げてるからそれを指摘した
別に>>341のエラーを多重継承のせいにしたつもりはない
確かに論文ではトレイト間の階層構造に意味が無いことは書かれていたけど
同時にトレイトはクラスの階層構造に影響しないとも書いてあったはず
クラスとトレイト間では階層構造を作るという解釈はどこから来た？
ここで2階層になってるからさっきの多重継承の問題が出てきた
- 362 名前：デフォルトの名無しさん mailto:sage [2015/07/21(火) 23:59:09.59 ID:BEOiskjZ.net]
- あなた「Rustのトレイトはクソ！本来の使い方ができない！」 >>343
ぼく「どうクソなの？本来の使い方って？」 >>345
あなた「トレイトは実装の再利用をするための部品。トレイトを型として扱ってるからクソ！多相性があるからクソ！」 >>346
ぼく「再利用できるじゃん。例もあるでしょ」 >>347
あなた「例えばこんなコードでトレイトを組み合わせることができない！」 >>348
ぼく「できたよ」 >>350
あなた「論文の定義と違うからクソ！トレイトがクラスになっているRustはクソ！」 >>351
ぼく「そもそもrustにクラス無いじゃん。クラスと型は違う」 >>353
あなた「じゃあお前はrubyのモジュールも型と言うんだな！話にならん！」 >>356
ぼく「rubyよく知らないけど型と呼べそうだよ。そもそも元の論文でtraitと型の関係は何も書いてないじゃん」 >>357
あなた「rustのトレイトは論文5pの図で言うところの多重継承だ！クソ！」 >>358
ぼく「多重継承じゃないでしょ。フラットになってるでしょ。Rustのトレイトが多重継承ならdiamond problemを書いてみてよ」 >>359
あなた「5pは菱型問題じゃない！お前分かってない！親子だけの2階層だけでも問題！」 >>361
- 363 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 00:06:40.09 ID:pdX/k3oq.net]
- あなたが書かなければならないのは、>>343で吠えたようにrustのトレイトが実装の再利用において、
本来のトレイトが解決してくれることができないこと、なんだけど1つも例を挙げてないよね。
>>348で折角「極端な例」を出してくれたが、それが>>350でrustでも書けることを示したんだが。
で、クラスと型を混同している頭ではトレイトが型なのが許せないようで、論文という他人の言葉だけを頼りにグダグダやっているけど、
第一級市民としてのクラスが無い、多相型のあるrustで、という文脈をずーっと無視しているよね。
論文は動的型付けの、継承がコードの再利用方法としてメジャーな言語の中での話、っていう文脈も無視しているよね。
トレイトは型ではいけない理由も、rustのトレイトが多重継承だと思った理由も、何にも説明してくれないからこっちで補完して反論してきたが、
もうお節介はやめるよ。ちゃんと自分の頭で考えなさい。
- 364 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 13:50:02.41 ID:tlwxTsYf.net]
- >>362
何を長々と、、、と思ってたらまとめが出来ていて分かった、乙
関数型の議論と同じく実用はおいといてセンシティブな定義で気に入らないのかな
定義に敏感な人は大変だなぁ
- 365 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 21:55:10.25 ID:ubJIybN+.net]
- 論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で
その問題を解決するためにトレイトを提案してる
その問題の1つが>>350のimplで理由は>>361に書いた
結局トレイトで否定したやり方をRustはトレイトと呼んでるわけだ
Rustの文脈を無視してるというのならトレイトの目的や背景も考慮したらどうだ
トレイトが型ではいけないってのは結局俺の間違いだった
型の機能を優先しすぎてトレイトの機能を無くすのが問題だっただけで
トレイトの機能と型の機能は両立できそう
- 366 名前：デフォルトの名無しさん mailto:sage [2015/07/22(水) 23:45:21.91 ID:pdX/k3oq.net]
- >論文ではまず実装の再利用に関して既存のやり方には問題があることを示した上で
>その問題を解決するためにトレイトを提案してる
だからその問題を具体的に、自分の言葉で説明しろよ。>>350を書いたのは俺だ。
そこにかかれているのはimpl TFoo for SFoo {}をひたすら書くのが面倒だね、ってことだけだ。勝手な誤読をすんな。
これが論文で言うcode duplicationだと思っているなら、あなたは論文を読む以前の知識が足りない。
しかも>>361で性懲りもなく親クラスなんて言葉をrustに持ち込んで妄言を吐いてるだけ。rustの何が親クラスなんだ？
トレイトの背景と目的？だから継承ベースのコードの再利用にある問題を解決するには、って分かってるから>>353で
「そんな問題はrustには無いんで、論文の言葉どおりにトレイトを定義した」と書いている。
で、親クラスって何よ？>>350のどこにも親クラスなんて存在しない。
- 367 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 21:35:53.52 ID:XXd04llZ.net]
- Rustのトレイトを親クラス、構造体を子クラスと見なせば論文の例はこうなる
https://play.rust-lang.org/?gist=8f1db295cff07a5163e7&version=stable
SyncAとSyncBのimplがほとんど同じでA::やB::の代わりにsuperが使えれば完全に重複
論文ではこの重複も問題として扱っている
- 368 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 22:25:53.21 ID:bNJIoU7G.net]
- それでみなさんはrustで何作ってるんですか？
- 369 名前：デフォルトの名無しさん [2015/07/23(木) 22:42:51.27 ID:GSXYPmA+.net]
- >>368
まあ、昔と違ってシステムプログラミングの需要って減ってるよね。
GTKかwxWidgetsのRustバインディングが安定したら何作るか考えるわ。
- 370 名前：デフォルトの名無しさん mailto:sage [2015/07/23(木) 22:49:25.52 ID:yXyFyEpk.net]
- >>367
みなさなきゃ良いんじゃね
rustのトレイトの問題じゃなくお前さんの視点の問題だろ？
Cで作るようなシステムアプリケーションとか作ってる
基本評判悪いけど面白い言語よのう
- 371 名前：デフォルトの名無しさん mailto:sage [2015/07/24(金) 00:32:36.11 ID:D0ziIpoZ.net]
- >>367 phpでやってみたが、減らせるコードって36-39行と47-50行だけしかなくね？ codepad.viper-7.com/2A7K4h
しかもSyncAとSyncBをAを扱う関数に渡したら、syncRead呼ばれないし。継承じゃないなそれ。
学習目的もあるが、PEGをもっと広めたいなーと思って色々触っている。
DSL作るのはLispと関数型言語が楽だとは知っているけど、rustも代数的データ型とパターンマッチがあるから何とかなるんじゃないかと思っている。
std::mem::size_of_valとかで見る限り、構造体のメモリ使用量がCと同じなのが気に入った。
いくらメソッド追加してもコストにならないし、vtableが出てくるのは&Traitみたいなtraitオブジェクトを渡すときだけなのも良い。
struct Container<'a, T: 'a + Trait> {
inner: &'a T
}
のメモリ使用量はusize
struct Container<'a> {
inner: &'a Trait
}
はファットポインタなのでusize + usize
- 372 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 02:29:33.62 ID:qRv1Q/E9.net]
- 普段ScalaとPlayFrameworkでWeb書いてるんやが、JVM嫌すぎてやめたい。
Rustさんはどうなんすかね。
- 373 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 02:34:13.24 ID:6f0NYoQy.net]
- Announcing Rust 1.2
blog.rust-lang.org/2015/08/06/Rust-1.2.html
- 374 名前：デフォルトの名無しさん mailto:sage [2015/08/08(土) 11:31:29.07 ID:vDqHzBe+.net]
- >>372
JVMの何が気に入らないのか分からんが
マルチコアプロセッサで効率的な動作を期待するならgoの方が向いてる
- 375 名前：デフォルトの名無しさん mailto:sage [2015/08/09(日) 03:37:11.08 ID:f9auPRN7.net]
- Rust1.2に付随してcargoのバージョンが上がってプロジェクトディレクトリの.cargo/configで
[build]
rustc = "multirust run nightly rustc"
とチャンネルを指定することができるようになったのが嬉しい。
前からcrates.ioのドキュメントにできると書いてあったのに、stableじゃできなかった。
3つもチャンネルがあるとドキュメントがいつから対応しているのか書く側も把握しづらいのかね。
- 376 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 01:45:21.38 ID:7PEu3mkB.net]
- >>375
できなかった。自分でrust-nightlyとか適当なシェルスクリプトかまさないといけない。
- 377 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 12:36:33.87 ID:0A5qnrPY.net]
- >>374
ただの技量不足なんですが、メモリ食っちゃうので…
- 378 名前：デフォルトの名無しさん mailto:sage [2015/08/12(水) 15:02:52.00 ID:rodoarXT.net]
- そりゃgoを使っても本質的には変わらんなw
rustでビルド時に厳密にチェックするのは一案かもな
最初は厳密すぎて実装効率がクッソ下がる悪夢にうなされるだろうけど
- 379 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 21:19:32.57 ID:gZkyyADQ.net]
- rustで、機械学習やりたいんですが線形代数とかに便利なライブラリってあります？
- 380 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 21:32:20.79 ID:PzFzu2cW.net]
- 基本的なライブラリも出揃ってないんだからないでしょ。
まぁ速くて関数型だから機械学習に使いたいのは分かるけど
- 381 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 22:24:22.09 ID:YKJt+Rxb.net]
- 普通にC/C++ライブラリをブリッジしてフロントをrustで書けば良いのでは
ブラックボックスのライブラリまで無駄にrustランタイムに依存しなくて良いだろう
関数型だから(笑)で選んだなら全てがrustじゃないと気に入らないかもだが
そうじゃないと思いたい
- 382 名前：デフォルトの名無しさん mailto:sage [2015/08/13(木) 23:14:36.16 ID:nvcb5WnS.net]
- C、C++で書かれたライブラリは予想外な最適化がなされていることがあるのではないか、と
https://github.com/BurntSushi/rust-memchr/
のベンチマークを見て、
code.metager.de/source/xref/gnu/glibc/string/memchr.c
を覗いて思った。
- 383 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 06:56:14.33 ID:blwavvg/.net]
- >>381
単純にrustに触るモチベーションにしようかと思っただけなんですが、
結局c++とかさわることになるなら、もうちょっとまってみます。
- 384 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 07:57:50.79 ID:OFjX8KNn.net]
- そうかrustじゃなきゃヤだったか、残念だ
rustに限らず新進の言語は自分が早い、と言い張ってるが
inlineとかconstexprとか、そういう言語仕様レベルでC/C++には負けそう
スクリプト言語よりは早いし、C/C++にない言語特性で勝ってるから良いんだけど
- 385 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 08:20:01.82 ID:8DhgL6X2.net]
- どうせバックエンドはLLVMだし、速度はなんとでもなりそう
inline指定はC++より細かくできるし
そのうちconst関数も実装されるんじゃなかったっけ
- 386 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 08:36:32.05 ID:+/xffdWO.net]
- 魔法の言葉、LLVM
LLVMを使ってれば全てが横並びになる、、、わけがねーだろ
- 387 名前：デフォルトの名無しさん [2015/08/14(金) 13:18:33.36 ID:MLcHO6rW.net]
- CはともかくC++書きたくないからRustに期待するので…
GCないし言語仕様自体で遅くなるということはない
現状でも遅くないし、最適化はコンパイラの成熟待ち
- 388 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 13:23:40.07 ID:ySA2YUfa.net]
- cppとかもうオワコンだろ
- 389 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 13:46:27.32 ID:G+XHrt0h.net]
- だったらrustがzero-costを推してるのは、、、
雨後のたけのこよろしく言語乱立なう
枯れるまでC++は良い言語の一つだと思うよ
- 390 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 17:04:46.99 ID:mJ5T1H4E.net]
- 最適化といってもコンパイラができる最適化には限りがあるよ。
例えばサイズnのスライスに対してある特定の処理を書くとしたら、
slice.iter().map(|x| { f(x) }) とか書くじゃん。遅延処理になるから、その後枝刈りができる可能性はあるけど、基本的にn回処理しなきゃならない。
頭のおかしい人が&[u8]とf(x)の中身を見て、&[u64]にしてf(x)を変形させて処理がn/8回で済むアルゴリズムを考えたとき、
そいつをコンパイラに伝える方法があるようには思えない。特にf(x)の中身を見ないといけない部分が難しい。
rustでスマートに書けるところは多いけど、速度が問題になるジャンルでは簡潔さを捨てても取るべきものがある、と思う。
- 391 名前：デフォルトの名無しさん [2015/08/14(金) 17:18:09.99 ID:MLcHO6rW.net]
- そりゃアルゴリズム変えるなら別の書き方することになるってだけでは…
RustはCとのインターフェイスが簡潔なのがよい
ほんとC++さっさと滅ばねーかなー
- 392 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 18:56:03.00 ID:tSzJ9MLR.net]
- ちゃんと読んでないけど、アルゴリズムの書き方が言語仕様で縛られるのでは？
C++を滅ぼそうとDだのC#だの出たけど倒れる気配ないからなぁ
時代は変わったけど難しいね
- 393 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 20:22:55.00 ID:N/BdRhBJ.net]
- 滅びを願う必要ないでしょうに
- 394 名前：デフォルトの名無しさん mailto:sage [2015/08/14(金) 23:57:05.10 ID:bS+eLMvH.net]
- >>390
f(x)がinline化可能なら、コンパイラがそういう最適化できる可能性もあるのでは？
ただ、最適化突き詰めていくと今のところ人の手でしかできないようなものがあるというのはその通りだと思う
- 395 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 11:29:55.30 ID:LE4LycT3.net]
- >>392
C#はc++滅ぼすためにでたんか
VM上で動く言語がc++の替わりになるとは思えんけど
- 396 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 15:00:25.90 ID:BF06i3ZJ.net]
- C#の4つの+の内2つは†だからね
- 397 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 16:30:24.95 ID:2bLrWO8C.net]
- c♯はvm言語だけどjavaとは比較にならないくらい速いぞ
- 398 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 19:21:36.26 ID:y8T1xilv.net]
- rustのC/C++にない機能特徴ってメモリ管理以外何かある？
文法はどーでもいいので、機能面でメリットがあれば教えて頂きたく
- 399 名前：デフォルトの名無しさん mailto:sage [2015/08/15(土) 19:44:13.49 ID:b89uyLUZ.net]
- バックエンドがLLVMということは、裏返せばLLVMにできないことはどう頑張ってもできなくて
LLVMを使いこなすという点ではclangの方がずっとこなれている、ということでもあるからなあ
clangだと独自拡張やビルトインを駆使してめっさ面倒なことがrustでこんなに簡単に！はあっても
clangでできないことがrustならできる、は無いだろ
- 400 名前：デフォルトの名無しさん [2015/08/16(日) 00:02:58.53 ID:0FrBGB/k.net]
- >>398
代数的データ型があること
- 401 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 08:54:35.06 ID:B/eZX+WT.net]
- 機能なのかね、関数型(笑)の特徴ではあれど文法の話な気が
zero-cost abstractionsってサイトのトップで言ってるけど
C++のvisual関数と違って、rust traitの抽象化はオーバーヘッドが少ない(もしくはゼロ)、、、？
- 402 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 15:52:42.12 ID:LltgmYR9.net]
- 言語の機能と文法はどう区別するべきか
言語の型システムに影響与えるものは機能に分類されると思う
rustのメモリ管理も型レベルで整合性判定しとるらしいし
その話は置いといてメモリ管理以外にも色んなファイルやソケットみたいなリソース管理
もやってくれるって宣伝しとる
- 403 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 17:33:48.92 ID:mucOKkH4.net]
- >>399
最後の文、なんかおかしくね？
- 404 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 17:37:02.87 ID:P0XQ+1Fa.net]
- Rustのtraitは&TとかBox<T>とかって形以外で使う分には完全にゼロコスト。C++のtemplateと一緒
- 405 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 19:29:02.58 ID:y6uPjVhI.net]
- visual 関数…
- 406 名前：デフォルトの名無しさん [2015/08/16(日) 20:25:28.98 ID:kniDeEJc.net]
- >>401
ADTのない言語でパーザやコンパイラなんか絶対に書きたくない
- 407 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 20:32:14.50 ID:+yYCxpZd.net]
- >>404
C++のvirtual関数だって静的に解決できる範囲だと普通の関数呼び出しだぞ
結局、必要なとこではやっぱりコストがかかりますという当たり前の話でしかない
- 408 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 20:45:48.84 ID:MwsW2pbd.net]
- >>402
プログラマじゃなくユーザにメリットある影響なら機能的な意味と見なしたいな
メモリやリソースは解放漏れでユーザに悪影響出るが、代数的データ型は影響無さそう
型情報を納めるためのメタデータが必要で
(極少量とは言え)性能が落ちるならカティンとくるがまさかそんなこともあるまい
- 409 名前：デフォルトの名無しさん [2015/08/16(日) 20:54:28.62 ID:kniDeEJc.net]
- >>408
>型情報を納めるためのメタデータが必要で
>(極少量とは言え)性能が落ちるならカティンとくるが
頭おかしい
- 410 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:05:51.13 ID:+yYCxpZd.net]
- ユーザへのメリットというなら、まずライブラリの形式がrlibとか特殊入ってる時点で……
もちろんVM言語よりは遥かにましだけど
- 411 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:06:48.25 ID:ffOxBAui.net]
- >>406
君が出来なくても賢い人が作ってくれるとからどうでもいいな
>>407
原則、静的解決出来ないことがない言語仕様が差別化なのかねぇ
これに限らず、ブレを許す気がないコンパイラなのが愉快
- 412 名前：デフォルトの名無しさん [2015/08/16(日) 21:10:29.90 ID:kniDeEJc.net]
- >>411
>君が出来なくても賢い人が作ってくれるとからどうでもいいな
コンパイラもパーザもそういうもんじゃないんだけど……
まあ、環境の違いかな
- 413 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:16:25.34 ID:+yYCxpZd.net]
- >>411
『&TとかBox<T>とかって形以外は』の部分はどこ行った
- 414 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 21:16:51.88 ID:YpDp9c6J.net]
- >>410
一応、普通のstatic, shared libraryにも変換出来るし、、、
(付与されるランタイムのオーバーヘッドがC++のソレとどの程度違うかは知らん)
- 415 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:08:36.25 ID:jt+RDWuc.net]
- Ownership と Borrowing はなんとか付いていけたけど
Lifetimes は，なにがしたいのかすら解らない...ｼｮﾎﾞﾝ
- 416 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:17:23.38 ID:rxm0/YIk.net]
- trait objectとそれ以外が陽に異なるから、オーバーヘッドの有無が分かりやすくていい。
C++に無さそうなのって、Phantom型とか？
ADTもパターンマッチをバリバリ使うのに必要な機能。
見た目enumなのがC,C++のenumと混同しちゃうかもしれんが、あれとは安全性のレベルが違う。
- 417 名前：デフォルトの名無しさん mailto:sage [2015/08/16(日) 23:39:45.12 ID:t+fZbGif.net]
- C++にPhantomタイプがない・・・？
それともRustのは別のものを示す語彙なのか？
- 418 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 01:03:54.38 ID:wXUvnq59.net]
- 急に人増えたけどなんかあった？
- 419 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 08:15:46.05 ID:EwR31uEA.net]
- 実は増えてないとか？
- 420 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 09:22:50.55 ID:++j4diFB.net]
- >>413
&TやBox<T>多用するのはイクナイrustプログラムの可能性が微レ存？
- 421 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 09:33:55.34 ID:Fu9VunjR.net]
- RustとSwiftはそっくりなんだから統合しちゃえばいいのにな
- 422 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 09:50:54.17 ID:S2KJYKrv.net]
- そっくりか、心が広いな
- 423 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 10:12:49.16 ID:OjKjgwDq.net]
- rustもswiftもgoも好きで使ってるけどswiftはgoと統合して欲しい
gc以外は感情論を持ち込まなければなんとかなりそう
rustは不毛な大地を一人でどうぞ(好意的な意味で
- 424 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 22:06:52.82 ID:qu3dwpPf.net]
- >>423
swiftとgoを統合の意味がぜんぜんわからないな。
goにGenericsが入ってほしいという話ならわからなくもないけど。
swiftはCocoaライブラリの互換性に縛られて言語仕様として洗練されてない。
goはシンプルを極めすぎて、Genericsとか入れてくれない予感。
rustはLLVMのフロントエンドってところでマルチプラットフォームな言語として一番期待できるよね。(swiftはCocoaがない環境で息できないでしょ)
UE4でC++の代わりにrustを使えないかと妄想してます。
- 425 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 22:34:16.53 ID:XjHdii/s.net]
- swiftの文法とgoの機能が合わさり最強に見える
rustは言語仕様と標準ライブラリが安定してユーザが定住するならなぁ
ユーザ数少ないのにマルチプラットフォームとか誰得だ
特色違えど言ってることがLuaと変わらんので笑える
- 426 名前：デフォルトの名無しさん mailto:sage [2015/08/17(月) 23:35:52.17 ID:rr3yinc6.net]
- swiftが底センスなのって互換性が原因かなあ
単純に設計者が(ry
- 427 名前：デフォルトの名無しさん mailto:sage [2015/08/18(火) 03:11:58.06 ID:1Gz3JsMv.net]
- 言語設計したAppleを責めるのはヤメロ
>>424
UE4って組み込み環境じゃなくゲームランタイムか
UE4知らんけどstatic library食えるならrustもいけるんじゃね
クロスコンパイラのrustc,cargo作れば良いわけだろ
- 428 名前：デフォルトの名無しさん mailto:sage [2015/08/18(火) 11:59:33.30 ID:6CH1l8he.net]
- swiftはアップデートするたびにcppに近づいてるな（悪い意味で）
- 429 名前：デフォルトの名無しさん mailto:sage [2015/08/20(木) 15:10:15.72 ID:JJlPzozZ.net]
- replか、rustの機能に合わせたスクリプト言語、あるいはコンパイラにキャッシュが欲しいです。
crateはコンパイル単位としてはでかすぎて開発サイクルが落ちまくるわ。
- 430 名前：デフォルトの名無しさん mailto:sage [2015/08/20(木) 19:05:12.42 ID:lKgof8/J.net]
- 富豪プログラマ乙
環境一式が提供されれば便利だけど、ないならないなりに自前で便利な環境作れば良いと思うよ
- 431 名前：デフォルトの名無しさん mailto:sage [2015/08/20(木) 20:23:20.16 ID:TcFY2I1R.net]
- >>429
https://github.com/murarth/rusti
- 432 名前：デフォルトの名無しさん [2015/08/20(木) 20:47:55.40 ID:5WCLlVT0.net]
- REPL使えるのはありがたいなあ
- 433 名前：デフォルトの名無しさん mailto:sage [2015/08/21(金) 21:43:41.45 ID:JyBfu5gS.net]
- >>430
富豪じゃないって話だろ？
- 434 名前：デフォルトの名無しさん mailto:sage [2015/08/22(土) 10:13:08.54 ID:EXDgxhBq.net]
- 言語は富豪じゃなく、プログラマが富豪感覚って話だろ？
昔、Pythonをログインシェルにする機構があったが
Rustをログインシェルにする強者は世の中にいるかね
- 435 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 10:35:52.76 ID:Gi1OdVG4.net]
- 自前で便利な環境ってどんなの？cargoのソースを少し弄っては動かして、ってのをやろうとしたことがあるけど、
自分のPCだと再コンパイルに何分もかかって苦痛の極みだった。
printデバッグはcrateがある程度大きいと役に立たない。
rust-gdbを使ったものの、メソッドをどう呼べばいいのか分からなくて難儀した。
最終的に特定した不具合はrust-1.1のstableで配布されていたcargoのバージョンが古すぎて
crates.ioのドキュメントにある機能が実装されてなかっただけだったんだけどね。徒労でした。
- 436 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 10:49:21.79 ID:DVHNG28Q.net]
- rustを使わなくて良いと判断することが良い環境じゃないかな
コンパイラ、デバッガ、ライブラリ管理、IDEをMozillaが綺麗に整備する気ないから
他の流行りの言語に比べて環境は人によってマチマチになるのが必然で問われても最適解はないよ
低レイヤーかつメモリ、リソース管理が楽なrustだけど開発環境は中々に不毛だと思う
オールインワンな用意されたモノが良いならswiftが最強、アポーOS内なら文句出ない
- 437 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 14:11:14.16 ID:2b/ywy3L.net]
- 静的型付けでIDE使えないとかなんの罰ゲームだ
- 438 名前：デフォルトの名無しさん [2015/08/23(日) 14:36:11.06 ID:myL1fwDZ.net]
- インクリメンタルなコンパイルもIDEに情報渡すためのコンパイラ側のサポートも
わりと優先度の高い開発目標になってて実際に着手してるから時間の問題
- 439 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 14:49:20.21 ID:DiK7bPRN.net]
- 型推論と静的型付けを混在してんのか？
静的型付けならC言語すらそうなわけだが
百歩譲って静的型付け+型推論としてもC++11が標準IDEなしで頑張っとる
emacsでもvimでもsublimeでもAtomでも好きなIDE(エディタ)使えよ
自分で選べず罰ゲームだと思うなら、まだ早い
- 440 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 15:29:12.91 ID:vCSJ96fF.net]
- 最強ideとして名高いintellij様がその内rustも対応するだろ（鼻ほじ）
- 441 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 17:12:50.17 ID:kGlhzngs.net]
- >>439
誰も型推論の話はしてなくね？
実際cやらcppでインライン構文チェック、補完できるエディタなんて普通にだろうし
- 442 名前：デフォルトの名無しさん [2015/08/23(日) 19:11:10.03 ID:myL1fwDZ.net]
- >>441
とはいえ、Rustのように型推論がある言語だとコンパイラが型推論した
結果をIDEに伝えてくれないとマトモな補完はできないので。
パーザと型検査機・型推論機に特化したツールを用意するか、
コンパイラが型推論の結果を別ファイル化なんかで伝達するかしないといけない
- 443 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 19:26:43.38 ID:/Chtfvs+.net]
- >>442
rebuildfmでtypescriptがIDE用にアノテーション情報をコンパイラが提供してると聞いた。
golangは言語としては提供してないけどgocodeってツールがそういう役割してる。
rustは今のところない感じ？
- 444 名前：デフォルトの名無しさん mailto:sage [2015/08/23(日) 20:29:46.00 ID:TP37Tp0e.net]
- racerとかいう補完ツールがあるけど、中身がどうなってるかは知らない
- 445 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 11:33:37.99 ID:LydH6mPU.net]
- ctags程度のインデックスファイル作成かな > racer
型推論した上で、その型がどんな名前のメンバ変数/関数が扱えるのかまでは補完してくれなさそう
>>441
型推論込みでコード補完してくれるIDEがないと罰ゲームだって話だろ、多分
- 446 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 14:35:52.72 ID:ILt1JEYe.net]
- 変数に別名を与える構文とか出来ないかな
refだと所有権の貸し借りが発生するせいで気軽に使えないからね
同じ変数に対して複数の名前で同時に読み書き出来る状況になるけど
Rustではそういうのもデータレースと見なすのだろうか
- 447 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 14:44:45.63 ID:h1iic6zY.net]
- それがメモリ管理のバグを生むから許せねーってのがrustの理念だろうよ
多用するもんじゃないだろうけどArcとか使えば良いんじゃね
- 448 名前：デフォルトの名無しさん [2015/08/29(土) 15:27:58.89 ID:hP/roqxQ.net]
- ML系みたいに型の構文を関数定義から分離して欲しい…
少し複雑になると読みにくくてかなわん…
- 449 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 16:06:46.95 ID:PwA9Vh//.net]
- ML系統も変数:型だけど、valに相当する構文を入れて、定義の所では省略したいってこと？
val foo : i32 -> i32;
fn foo(n) { n * 2 }
個人的には賛成。
多相型に対してimplを書くとimpl<'a, T1, T2, ...>が続いて読みにくくなるのも何とかならんかな。
punningというか、同じ文字を使っているなら省略してもオッケーみたいな。
- 450 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 16:42:49.79 ID:vqRxT/fZ.net]
- >>446
他の言語ならあるの？
- 451 名前：デフォルトの名無しさん [2015/08/29(土) 17:10:08.52 ID:hP/roqxQ.net]
- >>449
そうそう。定義内に入ってると読みにくくて読みにくくて…
- 452 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 17:27:04.02 ID:r87Lb3Gh.net]
- >>450
Cのポインタで出来るんじゃない？
>>449
タイプ数、ライン数を増やさんで欲しいな
今の仕様に追加なら見て見ぬふりしよう
- 453 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 17:36:28.28 ID:vqRxT/fZ.net]
- >>452
それだと本質はrefと変わらなくね？
- 454 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 17:51:33.64 ID:sBKhQngs.net]
- >>450
Cならunion、Pascalならabsoluteがあるよ
- 455 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 18:24:22.69 ID:u5YtsQ0V.net]
- 単に長い名前を一時的に短い名前にしたいだけだろ
Dのaliasみたいな
unionやabsoluteは別の型でオーバレイするので用途が違う
- 456 名前：デフォルトの名無しさん mailto:sage [2015/08/29(土) 19:18:35.10 ID:x4JINQUQ.net]
- Cならcpp経由の#defineか
rustでもrustcかける前にcppかまそう
- 457 名前：444 mailto:sage [2015/08/29(土) 21:38:49.53 ID:ILt1JEYe.net]
- すまん言葉足らずだった
>>446は>>455の言うように長い変数名を短くするような使い方を想定していた
>>456のやり方みたいにコンパイル前に名前を置き換えるだけでもいけるから
データレースは起きないと思ったんだ
他の言語だと所有権のチェックが無いからrefのような参照変数で十分代用できる
|
 |
