プログラミング言語 Rust

1 名前：デフォルトの名無しさん [2012/01/25(水) 20:05:49.96 .net] Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。 www.rust-lang.org/ 348 名前：デフォルトの名無しさん mailto:sage [2015/07/15(水) 23:54:13.14 ID:Kkrt7iJt.net] 極端な例になるけどこれを見て欲しい trait FooA { 　fn foo(&self) { self.bar1(); self.bar2(); } } trait FooB { 　fn foo(&self) { self.bar2(); self.bar1(); } } trait BarA { 　fn bar1(&self) { println!("A-1"); } 　fn bar2(&self) { println!("A-2"); } } trait BarB { 　fn bar1(&self) { println!("B-1"); } 　fn bar2(&self) { println!("B-2"); } } 一般的なトレイトだとFooAとFooBのどちらかとBarAとBarBのどちらかを組み合わせることができる それがトレイトの再利用 この場合トレイト型で区別しても意味が無い 349 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 01:05:53.97 ID:AYGKegct.net] はぁ？ 350 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 03:44:30.67 ID:xr+gKr/s.net] その一般的なトレイトだと、FooAかFooBをミックスインした対象はbar1とbar2を呼び出せないといけないんだよね？ OCamlの書き方でやると < bar1 : (); bar2: () > というシグネチャを持っている型しかFooA/FooBをミックスインすることはできないわけだ。 その型に、例えばBarと名づけて型チェッカで検査させて都合がでるとは思えない。実際に問題は起きていない。 https://codeshare.io/5XfJ1 ↑で一々implの羅列を書くのが面倒だという声に応えて>>341のようなimpl<F> Foo for F where FooA { ... }があって、 けどこれはまだ使い勝手が悪いからnegative boundがRFCに上がっている。 それも待ちきれないならnightlyのlibsyntax、あるいはsyntexを使って自動化することもできる(はず)。 他の言語だと、traitは型じゃないの？FooA+BarAをミックスインした型とFooB+BarAをミックスインした型は多相リストに入れたら駄目だったりするの？ 351 名前：デフォルトの名無しさん mailto:sage [2015/07/16(木) 23:56:38.15 ID:P5KxMz2p.net] 一応トレイトの論文(Composable Units of Behaviour)があって それを本来のトレイトと呼んでるんだけど本来のトレイトは型じゃないってのは事実 PHPのトレイトが型としての機能が無くて本来のトレイトに近い Scalaのトレイトは型として扱うことで継承構造も再利用できるようになってるけど Rustと違ってそれで本来の使い方が出来なくなったりはしてない それと読み返してて思ったんだけどもしかしたら誤解させたかもしれない 今のRustでトレイトの型としての機能を無くすならトレイトの代わりになる別の抽象型が必要になる PHPもトレイトの他にインターフェースがある それにトレイトが型なのが問題というよりも型として強力にするために多態性を持たせたり 名前が衝突しても解決しなくていい仕様にしたのが一番の問題 そこで本来のトレイトと使い方が大きく変わってしまった 352 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 00:25:13.89 ID:GZRy2HRh.net] 論文のタイトル正確にはTraits: Composable Units of Behaviourだった 353 名前：デフォルトの名無しさん mailto:sage [2015/07/17(金) 13:44:39.09 ID:vkp5Zmx6.net] 型とクラスを混同しているようだけど、型とクラスは違う。その論文のどこにもトレイトは型じゃないと言ってない。むしろ型以外の何者でもない。 クラスベースのOOPLは型≒クラスだけど、rustにはクラスもその階層構造も無い。 その論文で言及している、inheritance由来のデメリットはrustには存在しない。 よってトレイトがクラスベースの言語で解決してくれるような問題はrustには無く、論文の定義通りのはたらき、 すなわち「requiredなメソッドを用意したらあるメソッドをprovideする」を行っている。 「本来の使い方」という曖昧な言い方はやめてくれ。 useで明示的に指定したメソッドしか使えないのは論文の定義(トレイトをミックスインした場合と、しないで同名のメソッドを定義したものは同等であるべき)とは違うように見えるが、 クラスが無いんだからあまり変わらない。むしろあるメソッドがどこから提供されているのかを曖昧にしないのは利点ですらある。 トレイトに関する多相性というと、トレイトをミックスインした型全てを扱える仕組み(fn do_foo<T:>(f: &T) where T: TFoo {...})と、 多相トレイトを定義できる仕組み(trait TFoo<V> { ... })の2つがあるが、後者があるのがどう問題になるのか？ 多相トレイトを使う時、すなわちミックスイン時には単相化されるか、多相型のパラメータに渡されるだけなんじゃないの？ そして多相トレイトをやめた場合、例えばIterator<Item=T>というものはどう実現すればいいのか。 354 名前：デフォルトの名無しさん [2015/07/17(金) 14:25:23.54 ID:Zvxj9F2y.net] 結論：オブ脳の恐怖 355 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 21:30:37.89 ID:FAOQ/v/X.net] まあrustのトレイトはその言葉の意味「特性」をそのまま持ち込んでいるから、シグネチャ以外の特徴の表現にも使われている。 SizedとかSyncとか。 この過剰な応用がどんなデメリットになるかはもう少し様子を見てみる必要があるとは思う。 今も初見じゃ分かりづらいエラーメッセージの元になっている。Sizedトレイトが実装されてないから駄目ってどういうこと？とか。 356 名前：デフォルトの名無しさん mailto:sage [2015/07/18(土) 22:39:00.92 ID:vVMIYXNu.net] あの論文を読んでどうやったらトレイトを型と見なせるのか俺にはわからん 型＝クラスと思ってるわけじゃないけど型という用語の認識が違うのは確かだろうね 君はRubyのモジュールも型とみなすのかな俺は違うと思ってる 正直認識が違いすぎてどう説明していいのか分からん 他言語のトレイトを使って確かめてくれとしか言いようがない 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系みたいに型の構文を関数定義から分離して欲しい… 少し複雑になると読みにくくてかなわん…

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef