プログラミング言語 Rust 4【ワッチョイ】
Mozilla発のプログラミング言語「Rust」のスレです ■公式 https://www.rust-lang.org/ https://blog.rust-lang.org/ https://github.com/rust-lang/rust ■ワッチョイ スレ建て時、一行目に !extend:on:vvvvv:1000:512 を入れること ■派生元スレ プログラミング言語 Rust 4 https://mevius.5ch.net/test/read.cgi/tech/1507970294/ VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>48 やっぱりちょっと分からないな。 RustやC++のどの辺がコンパイラに機能を詰め込んでると思うの? ライブラリorツールに任せるってのもどの辺を任せたいのかな? 話がザックリし過ぎて言いたいことがよく分からないんだが。 プリプロセッサマクロのことかな?あとは型システムとかGCのことかな?ライブラリに任せるの意味がよくわからんが… C++はコンパイラの方もだけど標準ライブラリでの機能実現も相応に多くて結果ソースの記述が煩雑になっているのは既知の事実でしょう ライブラリや実装に任せた結果APIの統一が取れなくなって結局細かな仕様策定を余儀なくされたSchemeを見ても銀の弾丸でない事は明らかだよね それに出来る事を増やすという点においてライブラリは有用だけど変数の不変性や型システムのような制限をする事に関してはコンパイラによしなにしてもらうより他ないよ ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の 両院で、改憲議員が3分の2を超えております。 『憲法改正国民投票法』、でググってみてください。国会の発議は すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ やっとstableでrustfmtできるようになったな >>45 は言語仕様の追加、更新が気に入らないんじゃないかな try!の代わりに?なんて以ての外だ、みたいな?それ以外に思い付かなかったけど 1.0以前に@や~を削除してライブラリにぶん投げた辺りは希望通りな気がする 基本的に電池入りじゃないRustはライブラリやマクロの代わりの言語仕様の追加じゃなく より効率的なバイナリを吐くための言語仕様の追加が多いイメージだけどなぁ、impl Traitとか >>56 あー、そういうこと。?記法は確かに若干違和感あったかもな。 でも実際、あれは便利なんだよなぁ。 File::open(path)?.read_to_string(&mut buf)?みたいに繋げられるから。 try!(try!(File::open(path)).read_to_string(&mut buf))は読みづらい。 かといって、 let mut file = try!(File::open(path)); try!(file.read_to_string(&mut buf)) みたいに2行に分けるのも面倒だし、無駄なローカル変数も出来れば避けたい。 結局、あれが妥当な判断だったと思うけど。 まぁ、stableにする必要あったのか?ってところで賛否両論あるかもね。 box キーワードは何時 stable になるんだ? boxキーワードはどういう時にうれしいのかがわからん 明らかに二行に分けた方が読みやすいわけだが。 新しい機能マンセー厨ってそういう感覚の狂いについて無自覚過ぎんだよね。 俺も違和感はあるけど、多くの人が賛意を出して採用されたんだから >>60 や俺の感覚が狂ってるんじゃね?自身の感覚の狂いって当然ながら無自覚過ぎんよ boxは在り様の総意を取るの面倒だし、目下はBoxで運用できてるしで、いつまでもstableに来なさそう ヒープを多用したい人には文法にあればありがたいんだろうけど、そもそもヒープが好まれんしのう boxっていきなりヒープにメモリ確保されるのが保証されたりするんじゃないの? 今はコンパイラ次第じゃん ironって今メンテされてないのか 最近のweb FWはrocketの方が人気なんかな nightly専用だからまだ手を付けてないんだけど それはInPlaceとかPlacerがあればよくてbox inはただのsyntax sugarでは 分解の方がよほどsyntax sugarじゃないのかいな NightlyのInPlace, Placer使わなくても、Stableの環境でmacro使って実現出来そう boxって名前はBox<T>以外に使う場面で綺麗に見えない place <- exprは代入みたい tokio-coreなくなるんか 一通り組み上がった後の悲しいニュース まじか、ちょっと辛いな 依存してるライブラリも結構あるよね tokio系列のやつってtokioとかtokio-coreとかtokio-ioとかtokio-protoとか複数あってよく分からんのよね tokio-ioのリポジトリにはtokioに移動したからもう使うなって書いてあるし tokio-coreは移動じゃなくて廃止予定って書いてある… tokio-protoはそのまま?tokio-timerとかtokio-serviceとかよく知らんリポジトリもあるし… 誰か各クレートの特徴(役割)と関係性を教えてくれ >>71 あっちは、アンチが立てたキチガイ専用スレだからいいんだよ コミットを追うとtokio-coreはtokioに変わったように見える tokio-core=tokioでtokioの本体 tokio-ioはtokio-coreを使って非同期ioを実装したものだったがしゃらくせえのでtokio-coreに取り込んだのかな tokio-protoはtokio-coreを使ってネットワークプロトコルを実装したものだったがしゃらくせえからtokio-coreに取り込んだのかな つまり tokio = tokio-core + tokio-io + tokio-proto か? [] [[[ [[ [] ][ [] [ ] [] ][]] [[[ [] } tokio-protoとtokio-serviceってtrait宣言が主体のインターフェース定義クレートだったような? 前者はクライアント、後者はサーバに適したインターフェースが定義されてた覚えがある io, timer, cpupoolなんかはユーティリティ機能が実装されてたよな 統合の基準はどこかで議論されたんだろうけど、どこでやってたのかな 【お知らせ】Packt出版より Network Programming with Rust が発売されました。 https://play.rust-lang.org/?gist=cb511b34bc3ffbb43b8589a24156337a& ;version=stable let mut foo = Foo{ a:0, b:0, c:0 }; let aaa = ["5", "432", "3"].iter().flat_map(|i| i.parse::<u32>()).collect::<Vec<_>>(); foo.a = aaa[0]; foo.b = aaa[1]; foo.c = aaa[2]; Rustってこれ以外に書き方ありませんか? tupleでやってみるとleft-hand of expression not validと出ました >>79 大量のフィールドに値を入れるのって 一行一行書くしかありませんか? 一行にしたいなら foo = Foo { a: aaa[0], b: aaa[1], c: aaa[2] }; でも良いだろ。 部分書換なら foo = Foo { a: aaa[0], .. foo }; とかもある。 朗報: ついにウェブプラットフォームでRustが速度性能トップを取る https://www.techempower.com/benchmarks/#section=data-r15& ;hw=ph&test=plaintext なお、JSON操作を伴うとJavaにも劣る模様 ツリー制御が不得意すぎて笑うわ JSON serializationはそんなに悪くないんじゃね?tokio-minihttpで96.2%出てる。 それよりSingle QueryとMultple Queryが遅いのが問題じゃね? serdeでシリアライズだけするぶんにはjavaの1.4倍くらい早かったんだけどなあ(俺調べ) Rust book first editionからの変更知りたいんだけどバージョン差分どこでまとめられてる? >>83 >>89 なんで自分で調べようともしないの? Rust Languageさんのツイート: "Announcing Rust 1.24.1: we had some regressions in 1.24.0, so we've released a patch release. Please check it out! https://t.co/zrItc0qiqD" ; https://twitter.com/rustlang/status/969367994072739841 👀 Rock54: Caution(BBR-MD5:b73a9cd27f0065c395082e3925dacf01) Iterator::mapに渡すクロージャ内で、クロージャ内の変数への参照を持つstructを返したい時ってどう対処するのが正解ですか? https://play.rust-lang.org/?gist=a15e0dfa10339570fef5b9225761a9f0& ;version=stable does not live longエラー関係は自分が思ってるより広い視点で見た方が解決するんじゃないかなあ Hito.konomi_no_mochiは参照なんだから、参照元としてVec<Mochi<'a>>を保持しないと駄目なんじゃね? =>mochiがMapになってて分かりにくい =>とりあえずcollectさせてVec<Mochi>持ったら動いた みたいな。 https://play.rust-lang.org/?gist=6c9947e3584f1feb5bb14f07d27aa9c7& ;version=stable 多分、頭の良い人ならもっと綺麗な説明と解法があるんだろうけど >>92 ありがとうございます 仮引数mのライフタイムはmain関数が抜けるまでだから通るということで合っていますか またVecではなくIterator::Mapだと駄目な理由は、Iterator::Mapはcollectされるまでクロージャが実行されないから…とかでしょうか >>93 仮引数mのライフタイムはクロージャ内なのは変わらないよ。>>92 は仮引数を参照じゃなく消費してるから通る(>>92 の&mじゃなくてmで良い) クロージャが実行されないから、ではなく、mochiの値が消費されてるのにその参照を持たせようとしてるから駄目 試しに>>91 のコードでmochi.map(|m| { 0 })とか書いて、mochiをprintln!に渡してみようとすると怒られるよ。もう使ってるって。 そこらへんの細かいルールを覚えるの大変だし、コンパイラもまだ分かりやすいエラーメッセージ吐いてくれないから、 ・参照を使うときは、参照元をちゃんと生かしておくこと ・参照を使った構造体は、元の値を修飾(見方を変える、新しい機能を持たせる等)するようなパターンに限定すること を守るようにした方がいいよ >>94 「消費したものの参照を持たせるのは駄目」と「消費しているから通る」はそれぞれはわかる気がするのですが、両方となると… 前者の「消費したもの」と後者(main関数中生き続けるMochiのベクトル)は別物だと思うのですが、 前者で駄目な理由は関数中生き続けるMochiがない(mapを呼び出しただけでは駄目)ということですか? 「消費されるので通る」じゃ言葉足らずでした。「参照じゃなくmoveして延命している」の方が通じるかも >>91 のコードを整理すると 1. HitoはMochiの参照を持ってるから、Hitoが有効なスコープ中はMochiも有効じゃないといけない 2. mochiはinto_iterで作られてるからMochi型を吐き出す、けど所有はしない 3. なのにmochizukiはmochi.map()で各要素への参照しか持たない 4. mochiから吐き出されたMochiの受け皿が無いんでエラーになる これを解決するには 1を変えてHitoがMochiを所有するようにデータ構造を変える 2で作られたMochi型の値をしっかり保持する変数を用意する の2種類くらいしか思いつかん。 Does Not Live Longエラーはライフタイムがどうのこうのと小手先で弄るより、 値の所有者を明快にしたり、データ構造を見直してみると案外素直に直せるのが経験則。 >>96 loop{ let (a, cond): (&str, bool) = get_too_many_str(); let m = Mochi{aji: a}; let h = Hito {m : &m}; if(cond){ break; } } // ここでhのvecが欲しい この場合は、ムーブする(ループより長いライフライムの)変数がないので1の手法しかないということになりますか? そこそこでかい文字列を扱っているので気を使っていたのですが、この場合Stringにすべきでしょうか 大きい文字列を扱うから参照にしたいってのは普通にあるし分かるけど Hitoが&MochiでなくMochiをメンバに持つようになっても文字列のコピーは行われないよ 自分なら>>97 のget_too_many_str()が返す&strの元を誰が保持するのかをまず気にする そこをしっかり把握してれば文字列のコピーは最低限になるはずだから >>97 んー、自分なら そこだけに使うMochiCow型作ってでも ajiの型をCowにして凌ぐかな &strの元もloop内の変数が持っています hのvecを作るにはコピーは避けられないようですね… &strからStringに変えたところhvec.push(h)してもエラーにはなりませんでしたが、 スコープを抜けたはずの変数が使える理由ってどこかに書いていますか? そりゃloop内の変数hから、loop外のhvecに所有権が移動したから 頭の中に入れておける物なんて極わずかだし、場当たり的にdoes not live longエラーに対処するのは大変なので、 ・値の所有者はどの変数であるべきか ・データ構造はどうあるべきか という観点だけ念頭にいれて、「性能を稼ぐために参照を使おう」って考えを一旦外すとスッキリするよ まともな話題はslackいっちゃうのかな。 匿名で喋りたいのはアンチ向きか 別にアンチって訳じゃないけど、コンパイルが遅すぎる(特に最適化掛けた場合に)のはどうかと思う。 実行が速くてもその生成に時間が掛かれば無意味でしょう……。 >>108 Rustで組んだ新Firefoxの動作が2倍ほど速くなったのは無意味? まあコンパイルは遅いわな。 ていうかcargoの仕組みが問題なだけか? rustcで単一ファイルだけコンパイルすると結構速いなと思った cargoって警告無視のオプション(-Awarning)の有無でも一からビルドしようとしたりちょくちょくお粗末 なんかRustってテスト用と製品用で別々の最適化を施せるんじゃなかったっけ。 俺は自分の為だけにRustを使ってるのであまり気にしたことがないが。 確実にどんな人でも可能なネットで稼げる情報とか 念のためにのせておきます グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 C717P rustを始めたんだけど 分かりそうで分からなくて イライラする なんだこの言語 他の言語の経験にもよるけど 3000行ほど書けば慣れるよ(適当 actix_webでちょちょいとwebサービス作ろうと思っただけなんだが externとuseみたいに、なんで同じようなものが2つ有るのとか trait?、インプリすればいいだけならなんでこんな名前なんだとか 察するにJava経験者かね externは外部ライブラリのモジュールを参照する宣言 modは自身のフォルダ以下のモジュールを参照する宣言 useはモジュールの要素(Struct or Trait)を取り込む宣言 pub use self::MyStruct; // 要素をexportしたり use std::io::Error as IOError; // as で別名つけたり use super::Result; // 上位の型を取り込んだり(mod.rs以外からだと同一フォルダのmod.rsを見にいくので注意) 肝はselfとsuperを使いこなすことかと このあたりリファレンスに書いてあるんで落ち着いて読んでもらえばいいけど インプリについては、Trait = Interface(Java)の理解でそれほど差し支えない気もするけど (定数は同じ階層のmoduleに移す) AssosiatedTypeがあるように"Traitはコンパイル時に解決できる"ものってのを 意識してればその内に腑に落ちるんじゃないかな ただこんなこと言うと 「RustのTraitは厳密なtraitじゃない論争」(Wikipedia参照)が始まっちゃうかもしれないので ゆるく受け流してほしいところ extern/use周りをrefineする話ってどうなった? チュートリアルの和訳のところを読んでいるけど 誰が訳したんだろう。。。 extern crateは、includeとかload libraryぐらいの意味だと思えばいいと思うが、 「え、それ、Cargo.tomlにもう書いたやん」って思うのは当然の感覚だな しばらくしたら言語仕様変わりそうだなあこれ 勉強していくべきなのかどうか迷う 仕様の改定はc++のようにコンパイラのリリースとは別に2〜3年毎に定めることになってる 将来のコンパイラでも古い仕様を選択して使えるはず どんな言語でも利用者多ければライブラリーのトレンド変わっていって学び直しはあるし 言語仕様の変更だけ特別視する理由が分からん ver1.0になったし、firefoxに200kstepのソースがあるから始めるなら今でしょ ruby1.8から1.9とか python2から3の変更とか 嫌じゃん 言語もライブラリも混在してぐちゃぐちゃ >>124 和訳は最新に追いついていないと思います、公式英文を確認したほうがいい Rustの場合仕様変更の影響を受ける記述はコンパイラがwarning(とsuggestion)出してくれるみたいだし むしろライブラリのアップデートより楽なんじゃないかな やりたいことをするのに1日使って50%しかできなかった 自分には無理だこの言語 ここにまともなRustユーザいないのは年寄りしかいないからなのかなぁ slackかtwitterでコミュニケーションとれるので5chへ書き込みたい事情があまりない >>138 おすすめのハッシュタグはなんでしょうか? もっとメジャーになってslackが荒れて来たらここもワンちゃん slackで発言できないアンチにしか存在価値がないのかぁ read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる