プログラミング言語 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 >>175
ExactがFilterだと分かれば別のFilterを組み合わせられることはわかるでしょ？
warpのFilterシステムを理解させるための解説ドキュメントが不足してるのと
他で類似の仕組みをあまり経験したことがないのが理由なんじゃないのかな？
型が入れ子の形でチェインされてる状態に慣れてないから
それがわかりにくさの原因のように感じるかもしれないけど
JavaやgoのReader/Writerみたいにデコレータ的に型を重ねていくのはそんな特殊なことじゃないよ iterator系の処理はどんな言語でもやりすぎると意味不明なんでいい単位で説明変数や関数に切り出すのは大事だよ。 関数単位で切り出す場合はimpl TraitやBox<dyn Trait>使った方が良いと思う
実装の詳細が型として露出してしまうのはよろしくないし
何より長い型を書き下すのはめんどくさい >>176 いやExactがFilterかどうかが分からないんだ。自信が無い
https://docs.rs/warp/latest/warp/filters/path/struct.Exact.html
https://docs.rs/warp/latest/warp/trait.Filter.html
↑2つを見ても、ExactがFilterをimplしているとは書いてないんだ
知ってたらマジで教えてほしいんだが、どこ見ればいいの？
>>178 そう思うのは人情だが、じゃあどういう型の関数にすればいいのかって話
ググらずに分かる？俺は分からなかった >>179
非公開の（だけど実装が漏れている）FilterBaseトレイトを介してFilterを実装してるんだね……
FilterBaseが公開されていればExactのblanket implementationsに出てくるはず
同じことは指摘されているが放置されている模様
https://github.com/seanmonstar/warp/issues/742 もしかして特段に分かりづらい構造だったのかWarp Sealed TraitっていうユーザーにTraitを実装させないための一般的なパターンなんだけど
privateなTraitはドキュメントには現れないのでExactがFilterBaseを実装してることを確かめたければソースを見るしかない
でも関数や構造体の説明にFilterだよって書いてるんだからまずはそこからじゃないか？
path()「Create an exact match path segment Filter.」
Exact「A Filter matching an exact path segment.」 いや型の説明がコメントにしか無いかったら疑うのが基本じゃないか…？
説明にある通りの使い方はできるけど、何故そう使えるのか分からない、となった上での話
前にもちらっと書いたところもそうなんだけど、impl Filterを返す関数のシグネチャも独力だと分からなかったんだよ。もっと情報の少ないクレートでやる必要が出てきたら詰んじゃう [T]と[T; N]があるように
strに対するSizedなstr<N>とかできんかね ttps://doc.rust-lang.org/beta/unstable-book/language-features/yeet-expr.html
名前の元ネタがよくわからん >>185
trY Early-ExiT で yeet じゃない？
experimental だからわざとクソ命名してそう。 ProviderとDemandってCOMのQueryInterface的な使い方もできるのかな cargoのsparse protocolは嬉しい Default alloc error handlerはLinus指摘の取り込みかな。 Linusの話は、メモリアロケーション失敗時にpanicするなという話だと思うけど、今回の変更とは全く関係ない
今回の変更でalloc crateがalloc_error_handlerのデフォルト実装を提供するようになった
新たに提供されたalloc_error_handlerはpanicする実装になっているので、メモリアロケーション失敗時にpanicになることは変わらない
単に、利用者がalloc_error_handlerを独自に実装する必要がなくなったというだけ
Linusの指摘に対しては、Box::try_newなどのアロケーション失敗を呼び出し元に通知するAPIを用意することで対応している >>195
サンクス。
Linusは「単にエラーを返せ」と言っていたから、error handlerじゃ確かに駄目だね。 Rust製の高速なwebpack互換バンドラ「Rspack」登場。現時点で5倍から10倍の性能向上
https://www.publickey1.jp/blog/23/rustwebpackrspack510.html
> Rust製の高速なバンドラとしては、webpackの主要な開発者がNext.jsに入社してwebpackの後継として開発している「Turbopack」もあります。
> 現時点ではまだwebpackが抜きん出た人気を得ていますが、現時点で主要な開発者が抜けてしまったwebpack後継の座を狙った競争が始まったといえそうです。 >>197
ちょっとスレチ気味だけれど
Turbopack(新調で700倍高速) vs Rspack(互換性維持で5～10倍高速)
webpackからの乗り換えはしばらく様子見 一度普及したソフトの作者自身が後継プロジェクトを立ち上げてもなぜかうまくいかない法則 速度遅くてもウケたプロダクトの動作速度上げたところで
現行をリプレイスする理由にならないからな
それにRustがいかに速かろうと今の時代ネックはIOである可能性が高いし >>200
詳しく見ていないけど、ロジックにボトルネックがあるのかもね。 10倍のオーダーで速度差出るなら性能がリプレース理由になる場合も増えると思うよ
数分かかる処理が数秒で終わると快適さが全然違うだろうし >>201
どうせ IO がネックだからってのは昔から言われてることだけど
クラウドサービスを前提にすると事情が違うと聞いたことがある。
レスポンスタイムにあまり差が無かったとしても課金は演算量 (CPU の使用量) に対して
だからなるべく効率的に実行できる言語を使ったほうが安く上がるんだとさ。 Ruby on Rails 6 では、webpack が標準だったけど、
Rails 7 では、Import Maps で、CDN から直接インポートするように変わった。
脱webpack/node.js
ES2015 に対応していないブラウザ用に、バンドルする方法もある。
バンドラーは、esbuild, rollup, webpackの3つ ドキュメントコメントを reStructuredText で書きたい let-else の else ブロックの中だけ rustfmt 効かなくて設定間違えたかと思ったら
フツーに未対応だった
https://github.com/rust-lang/rustfmt/issues/4914 let-elseは鬼っ子だから
改行位置決めるのも大変 横から済みませんがが、
Rust で Vec に要素を追加した場合にメモリー不足になったかどうかを検出
するのはどうしたらよいんでしたっけ？ >>210
それは予め領域を確保しておく関数で、確保できなかった場合には、
Result<(), TryReserveError>
という戻り値を返す関数と言うことですか？
そして、関数呼び出しの直後に ? を書くと、エラー発生時にそこで
アプリをダウンさせると言うことですか？ >>211
事故レスですが、? 演算子は、x ? と書くと、x の値が Err(y) だったら、
return Err(From::from(y)),
というような動作をする関数のようですね。 いろいろ違う
落としたいならpanicさせとけばいい メモリ不足を検出した場合に何をしたいかで適切な対応は変わってくるけど、何をしたいの？ >>214
メモリー不足の時にメモリー不足である旨のエラーメッセージを出して、
なんらかの自作の処理コードを動かしたいです。 >>215
なお、Vecに追加する動作を行なった関数の中で処理をしたいです。 重要:
メモリ不足だからと言ってmallocが失敗するとは限らない 今の Linux カーネルだとアプリケーションからオーバーコミットを無効にすることは出来るようになってるぞ。 try_reserveの戻り値がErrだったら処理を実行するだけだよ
この説明で分からないならenumやResult型について勉強した方が良いよ
あとtry_reserveの失敗要因はメモリ不足だけじゃないけど、エラー種別はnightlyじゃないと取得できないみたいね RefMut <-> Ref にも Rc <-> Weak みたいな相互変換メソッドがあればいいのに >>220
RefCell自体を取り回して必要なところで都度RefやRefMutを作れば良いのでは >>221
実際今はそれでやってて、別に問題になるほどじゃないんが、ちょっと無駄だよなあと
Ref/RefMutってあんまりあちこち取り回す用にできてないよね >>222
RefやRefMutはMutexのGuardみたいなもんなんだから取り回す範囲は極力狭くするべきなんじゃね Rust for Linux updates! More pin-init and refactoring! - YouTube
https://www.youtube.com/watch?v=jAanHvcuYtA The RustConf Keynote Fiasco, explained
https://fasterthanli.me/articles/the-rustconf-keynote-fiasco-explained
一連の事件は結局不幸な伝言ゲームの結果だったということだろうか 以前からCodeLLDBでたまに値がちゃんと表示されないことがあるなーと思ってたら再帰型が原因だったんですね
今ほとんど再帰でできてる部分触ってるせいで困ってる……
dbg!書けばいいだけではあるんだけど泥臭くて嫌だわね
https://github.com/vadimcn/codelldb/issues/605 いつのまにかrust-specがマージされてる。まだ作業終わってないけど。
ttps://github.com/rust-lang/rfcs/pull/3355
ttps://github.com/rust-lang/rust/issues/113527
rustにもようやく仕様が。 これから編集者雇うみたいだからまだまだ時間は掛かりそうだけど、前進だね Hugging FaceがPyTorch的なRust製フレームワークを作り始めたらしい
https://github.com/huggingface/candle githubにrustupのソースコードあるから読めばいいよ。 Debugを上位トレイトに持たないトレイトのオブジェクトをなんとかしてdbg!する方法は無いもんじゃろか 構造体フィールドの中身を知りたいという事ならAnyを継承させてダウンキャストするかDebugを継承したtraitにするしかないね intellij rustからRustRoverギリギリ燃えてないな。プラグインもIDEAもバグが増えたのが懸念とか言われてるけど。 RustのコンパイルターゲットはTierで分けられているけど
x86_64-pc-windows-msvc ←Tier1
x86_64-unknown-none ←Tier2
この違いって何？
Tier1の条件を見るとすべてのテストに合格すること的な事が書いてあるしプラットフォームが不明の状態でそれは不可能はなず
組み込み向けなどの低レイヤー用途を想定したターゲットにTier1のものはなくすべてTier2以下になっている
もしこれが理由なら自分が書いたコードはTier1と同レベルに翻訳される(実行できなかったり実行結果が不正なコードは生成されない)事が
期待できるけどそう考えて問題ないのだろうか >>241
x86_64なら現実的にはほぼ動くとは思う
ただ、あくまでもrust側ではコンパイルが通ることしか確認してなくて、生成されたコードが正しく動作するかは未確認の状態
利用者側が動作確認をきちんとやる必要があるよ >>242
例えばベアメタル開発用などでOSとインターフェイスしないコードのみほしい場合
x86_64-pc-windows-msvc(x86_64-unknown-linux-gnuとかでも可)でスタティックリンクのライブラリとしてビルドしてカスタムリンク
x86_64-unknown-noneでビルド
の二択だと出力物の信頼性はどちらの方が高いのだろうか。どちらも適切なローダーを用意すれば動作するはず
特に低レイヤーの開発で翻訳不良があるとトラブルシュートが沼りやすいし、前者の方が有利なら
ゴミが付いたりビルドが複雑化するなどのデメリットを考慮しても検討する価値があるはず より正確にはtier2はwith/without Host Toolsに分かれる。
withの方はtarget環境扱いだけじゃなくてネイティブなhost toolsを使用して開発環境として使える。
*-*-none-*はベアメタル向けだからHost Toolsのサポートはない。
言い換えるとtier2 with Host Toolsはセルフホストできる。
Tier 1にもwith/withoutの分類があるけど事実上withoutの方がない。
これは今のところHost Toolsをサポートしてないtier 1が存在しないから。
だからビルド環境に指定したいならx86_64-unknown-none。 x86_64-unknown-noneが吐くコードをどのくらい信用して良いのかって話ね
Tier2＝十分にテストされていない＝不正命令例外を吐いたり意図しない演算結果になる可能性がある
とかだと開発に重大な影響が出るし勘弁してほしい。Tier1のターゲットならそんな可能性は無視できるはずだし テスト云々はlibstdが主なんでは？
そもそもコード生成するのはLLVMなんだし機械語レベルじゃRust側のTierは関係ない気がする x86_64-unknown-noneがTier2の理由がstdのテストができないからならそれでいいんだけどね
Platform Supportを見ても
>x86_64-unknown-none * Freestanding/bare-metal x86_64, softfloat
としか書いていない。hardfloatが使えない？のはよくわからないが Tierはrustcのコードベースがビルドできるかどうかの保証であって吐くバイナリの質の保証じゃない。
そもそもrustcはフロントエンドだからどういうバイナリ吐くかは無関係。
tier 1/2の違いは自動テストが常に実行されるかどうかの違いだけ。
全部Platform Supportに書いてあるからこの説明でわからんならどこが理解できないのか言ってくれ。 Tier表記がアテにならないならコードの質を比較するにはどうしたらいいんだろ
x86_64とavrが同じ品質、同じ最適化レベルなわけないよな rustに限らずコンパイラの生成コードの品質はアセンブリ見て判断するしかないんじゃね
LLVM IRもプラットフォームごとに差があるのかね？ Rust製ブラウザエンジンの「Servo」、アプリに組み込み可能なクロスプラットフォーム対応WebView化を目指す。Electron代替を目指す「Tauri」への組み込み実現へ － Publickey
https://www.publickey1.jp/blog/23/rustservowebviewelectrontauri.html
期待 https://rust-lang.github.io/rfcs/3192-dyno.html
気づいたらポシャっててstd-1.73.0からProvider/Demandも消えてた
やっぱりRTTIとかそういうのはあんまり乗り気じゃないのかな？？ RubyのYJITって仕組みはRustで実装されてるんだな
ソース見てビビった >>253
へぇ、Node.jsもあちこちが遅いからと
ちょこちょこ便利ライブラリの中身がRustに置き換わり始めてるし
今後こういう流れは加速しそうだな 遅い部分を Rust でなおそうというよりは、
Rust へ置き換わる流れに乗るついでに駄目なところをそろそろなんとかしようぜという感じじゃないかな。
イマイチなのがわかっててもちゃんと動いてるなら何かきっかけがないと重い腰が上がらないのはよくあること。 YJITのコード、相当面白いな
RustでJITしてるよw
マシンコードゴリゴリ生成してる rustってJavaやpythonみたいに爆発的に流行るわけじゃなくてじわじわ広まっていく感じなんだろうな YJIT、最初はCで実装されてたがRustに変えたみたい
bindgenでCRuby側のAPIをRust側に持ってきて
それを使いながらJITでマシンコード生成してる
面白すぎる
コードもめちゃくちゃ読みやすいぞ RustのRTOSはTockがあるけどFreeRTOSやTOPPERS/SSP、μT-Kernelなど既成のRTOSとの比較レビューってある？ >>257
それなりに使われるだろうけど普及はしないよこんな糞言語 >>264
糞言語は定義しなくていいということですか >>266
糞言語でも神言語でもいいから
普及したかどうか基準を明確になれば良い >>268
プログラミング言語の前に国語勉強しよう 
