プログラミング言語 Rust

1 名前：デフォルトの名無しさん [2012/01/25(水) 20:05:49.96 .net] Mozillaがリリースした、プログラミング言語「Rust」について語るスレです。 www.rust-lang.org/ 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のような参照変数で十分代用できる 458 名前：デフォルトの名無しさん mailto:sage [2015/08/30(日) 07:01:42.91 ID:HJK6L9Ls.net] そういう無駄な他言語仕様の取り込みは要らない 一見変数名が短くなって特定箇所はシンプルに見えるが 全体のコードからすれば簡素にするではなく、複雑にするだろ 459 名前：デフォルトの名無しさん mailto:sage [2015/08/30(日) 07:12:12.11 ID:9R41/ZIA.net] まあまあ 今はいらんかもしれんけど、本格的にいろんな環境で使われだして環境差を吸収しないといけないとなってくると そういう機能も必要になってくるよ 他言語にある機能だって無駄に存在してる訳じゃないからな 460 名前：デフォルトの名無しさん mailto:sage [2015/08/31(月) 11:07:32.54 ID:tdAWRFGn.net] 長い変数名ってjavaのメンバ変数みたいな？ 想定しているコードがよく分からん。aliasと元の変数が同時に出てくるコードの可読性は低くないか？ 自分だったら↓みたいに元の変数からmoveさせて処理した後に元に戻すようにすると思う。 #[derive(Debug)] struct Foo { x: i32, y: i32 } #[derive(Debug)] struct Bar { verylong_named_variable_which_will_be_moved : Foo } fn main() { let mut bar = Bar { verylong_named_variable_which_will_be_moved: Foo { x: 100, y: 200 } }; let mut a = bar.verylong_named_variable_which_will_be_moved; a.x = 10; a.y = 20; bar.verylong_named_variable_which_will_be_moved = a; println!("bar = {:?}", bar); } 461 名前：デフォルトの名無しさん mailto:sage [2015/08/31(月) 13:07:11.54 ID:yj9JwLwE.net] 444の意図とは逸れるかもしれないけど 例えばerrnoなら実際はerrnoだったり_errnoだったり__errorだったり environならenvironだったり__environだったり*(NSGetEnviron())だったりする stdinだったら__stdinpだったり__sF[0]だったり(&__iob_func()[0])だったり…… それがヘッダファイル中で#defineされているから、C言語からはどの環境でも同じ名前で使えるわけだ 今は処理系もひとつで動く環境も限られているから表面化しないかもしれないけど 普及と同時に差も広がっていく中で #[cfg(〜)] 使って全ての環境分書き分けろってなったらやってられんと思う ……というつもりだったのが>>459 462 名前：デフォルトの名無しさん [2015/08/31(月) 13:48:51.45 ID:gJdrS6xb.net] まあ、低レベル言語でどこまでの抽象化を許すかは難しいよな 463 名前：デフォルトの名無しさん mailto:sage [2015/08/31(月) 15:10:03.72 ID:Dkk0mMpb.net] Cでは#define, ifdef使う所を、rustでは#cfg使うのがrustの出した解決策なんじゃなかろうか 464 名前：デフォルトの名無しさん mailto:sage [2015/09/01(火) 13:12:24.79 ID:Qh110XSL.net] #cfg濫用は心配することないと思うけどな。 現在でもwinとlinuxとOSXがサポート対象だけど、環境の違いを陽に扱うコード以外は#cfg使って書き分けるなんてやってない。 Cでは抽象化の手段が少ないからプリプロセッサ使わないとやってられないが、 rustならトレイトとかコンテナ型を使って、ゼロコストで環境の違いを吸収できるのではないだろうか。 465 名前：デフォルトの名無しさん mailto:sage [2015/09/04(金) 19:40:34.17 ID:PM7GVPA4.net] iOSとAndroidと、それらの各種CPUを対応しててくれてありがたいんだが、libcの#cfgがバグってて悲しい rust/src/libcは直ってるようなので、gitのリビジョン参照の更新待ちだい 466 名前：デフォルトの名無しさん mailto:sage [2015/09/18(金) 08:13:22.55 ID:qEC88fFW.net] 1.3来てるぞ 467 名前：デフォルトの名無しさん mailto:sage [2015/09/18(金) 10:09:51.13 ID:qiV5MD3f.net] Release Notes v1.3.0 https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-130-september-2015 468 名前：デフォルトの名無しさん mailto:sage [2015/09/23(水) 23:21:07.14 ID:IGgDNXyV.net] メソッドをオーバーロードするのにトレイト組み合わせなきゃならんのは何で？ オペレータのオーバーロードと方法を合わせるためなんか？ 469 名前：デフォルトの名無しさん mailto:sage [2015/09/24(木) 00:52:09.13 ID:lP9arsTC.net] 型推論が面倒になるからじゃない？ 仮にオーバーロードができたとして、2つのメソッドdo_somethingがそれぞれAsRef<str>と&Stringを引数として渡せるとしたら、 let bar = "abcde".to_string(); foo.do_something(&bar)とやったとき、どっちのdo_somethingを呼ぶべきか分からない。 470 名前：デフォルトの名無しさん mailto:sage [2015/09/25(金) 18:26:11.73 ID:R+TRhKVr.net] try! が使えなくなってるような 471 名前：デフォルトの名無しさん [2015/10/06(火) 23:08:05.18 ID:GvY89Hx4.net] >>470 使えるよ？ 戻り値の型と合ってないとかでは。 472 名前：デフォルトの名無しさん mailto:sage [2015/10/30(金) 08:18:22.20 ID:pCPlChjw.net] 1.4来た 473 名前：デフォルトの名無しさん [2015/10/30(金) 10:46:42.92 ID:IKqzpUXy.net] スタートダッシュはもたついたけど地道に進んでるようだな。 474 名前：デフォルトの名無しさん mailto:sage [2015/10/30(金) 22:03:45.74 ID:wx6dAr+H.net] この言語って将来性ある？ 軽量タスクをあきらめた時点で多くの期待を裏切った感があるけど 475 名前：デフォルトの名無しさん mailto:sage [2015/10/30(金) 23:07:12.55 ID:r01g6EEx.net] 裏切られたのお前だけじゃね？ 476 名前：デフォルトの名無しさん [2015/10/30(金) 23:57:05.43 ID:FTBRryE0.net] ランタイムを持たずに低水準を弄ろうというシステム向け言語で デフォルトでグリーンスレッドをサポートとかそりゃ無理でしょ ま、需要があればライブラリで提供されるだろうさ 477 名前：デフォルトの名無しさん mailto:sage [2015/10/31(土) 00:17:04.93 ID:qwGp3Rk5.net] scala使っとけよ いい言語だぞ 478 名前：デフォルトの名無しさん [2015/10/31(土) 00:44:50.75 ID:L1WutJvq.net] >>477 何故にそこでscala？ scalaやるくらいならocamlやる。 JVM上でってことならいっそのことclojureやるわ。 479 名前：デフォルトの名無しさん mailto:sage [2015/10/31(土) 03:33:05.27 ID:F9rGVxSD.net] 476がなぜそんなにscalaを嫌ってるのか少し気になるw まぁscalaもocamlもclojureもRustからは遠い言語だけど。 480 名前：デフォルトの名無しさん mailto:sage [2015/10/31(土) 04:11:48.61 ID:/cAGFdj7.net] 嫌ってる訳じゃないだろ。他に良い言語があるのに、ってだけで。 481 名前：476 [2015/10/31(土) 06:37:08.04 ID:L1WutJvq.net] うんscalaが嫌いってわけじゃない。 ocamlやclojureがもっと良い言語とも言わん。 単に何故にRustのスレでscalaが出るって思っただけ。 482 名前：デフォルトの名無しさん mailto:sage [2015/11/07(土) 12:41:15.36 ID:ptDOELGY.net] OCamlがRustから遠い言語だと！letやらOptionやらを見ればOCamlの香りがするだろう！ OCamlの型システムを魔改造して、ガワをC++やJavaにして、ついでにGCも取っ払ったらRustだろうが！ 使えば使うほど「OCamlならもっと楽に書けるなーこの式」とか思っちゃうくらいには近いぞ。 というか何故しなかったのか。 パターンマッチのデリミタを|から,にしたり、ジェネリック型の表記をT ListからList<T>にしたり、 式をML系列(foo x y)からalgol系列(foo(x,y))にした理由が未だに分からない。 括弧の量が増えて困る。 483 名前：デフォルトの名無しさん [2015/11/07(土) 13:31:16.74 ID:dEyvNDQG.net] そりゃ「から〜にした」っていうのが単に480の習得順序なだけだからでしょ。 484 名前：デフォルトの名無しさん mailto:sage [2015/11/07(土) 13:32:09.75 ID:7OElurpY.net] ML系列流行らないからじゃない？話はずれるがOCamlも一旦キーワード整理しなおした文法2.0作らないとツギハギちょっとひどい。

---

---

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

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