Rust part23
前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照) https://mevius.5ch.net/test/read.cgi/tech/1705760500/977- Netflixは2年かけて気が付いたけど凡人程のめり込む沼 出典 https://www.youtube.com/watch?v=6gwF8mG3UUY Haskellの時と同様、概念だけ触れたら他の言語に活かすのが良い 長居していると症候群認定される危険性があるから >>4 それ何の情報もなく見ても無駄 具体的な説得力ある話がない TypeScriptが嫌いでGoが好きらしい Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている 静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない RustやTypeScriptだけでなくC++のtemplateやPythonの型ヒントでも同じこと 単独のTraitだけの話で型オナニーとか言ってるやつはオナニーレベルが低過ぎ 静的型チェックへの適性がないのでRustも辞めた方がいい 型オナニーより所有権やライフタイム管理の方が面倒だけどな それが型と絡むからさらにややこしくなる 動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前 GC前提言語しか慣れてない初心者がそうでない言語に慣れるまで時間がかかるのは当たり前 プログラミングに向いてる人ならどちらもすぐに慣れる そんなことで文句を言っているようではプログラミングに向いていない Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない >>8 それRust特有だよね 時間がどんどん溶ける asはそろそろFrom/TryFromに統一してほしいんだけど 型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ >>13 機能が異なるので統一されない asはcastなので変換From/TryFromとは異なる 例えばi32からu8の場合は変換できない値があるため impl From<i32> for u8は実装がなく impl TryFrom<i32> for u8の実装があり u8::try_from(-3_i32)は変換できずErrとなる 一方でasはcastなので-3_i32 as u8は8bitに切り捨てられ252となる >>16 それだけならstdにimpl From<i32> for Wrapping<u8>でも入ってくれれば事足りると思うが…… asって手軽なだけで変換元と変換先の型ごとに意味が複数あるのが複雑で嫌いなんじゃ C++のC形式キャストみたいな印象 え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか だるっ そういうとこやぞ 生演算子はオーバーフローせずラッピングされる panicはデバッグ時のみ 明示的にラッピングしたいときはwrapping_add オーバーフローを処理したいときはchecked_addやoverflowing_addまたはsaturating_add 型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや 標準ライブラリの基本的な使い方を覚えることなのかよ オナニー要素ゼロじゃん そんなマインドではRustに限らず言語習得は無理だぞ そんなマインドでもGo言語なら習得出来るんだよなあ バカはGoへ行くしかないよ Rustなどは一般的なプログラミング能力がある人向け Rustの開発って時間掛かりそうなイメージある とりあえず作ってみて後でリファクタリングって作り方ができない感じ? termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。 >>21 リアルの会話でこうやってRustのマイナス面を他と同じと言う奴は 内心信用してない >>23 言い方があれだけどこっちの方が信用できる >>25 リファクタリングってのは外部から見た時の挙動を変えないのが原則なので 少なくとも型やライフタイムについては辻褄が合っていることを保証できる仕組みは リファクタリングでも便利なんだぞ。 内部的な処理でもあまり柔軟には変えづらいということはあるけど 変えづらいところは (外部に対する保証に関わってくるので) 変えてはならない箇所だってことがわかる。 >>9 ✕プログラミングに向いていない ○rustに向いていない 皆さん、これがrust信者です >>6 せめてtraitに外延性があって集合的操作ができればいいんだけど、さすがにビルドに時間掛かりそうだしな。 ただでさえビルド時間が重たいから、設計の「早すぎる最適化」は仕方ないのかね。 >>28 例えばpythonとかだと型とかプログラム構造気にせずにパパッと書いて ある程度動くスクラッチでレビューして内容詰めて スクラッチから流用できそうなら作り込んでリファクタリングみたいにできるけど Rustだとそういう風にできなさそう >>23 こういうのに限ってgoでもろくなもの書けない >>32 Pythonだとそのリファクタリング前後で挙動が変わってしまわないように気を遣うのがしんどいな そういうとりあえず試しに作るケースだとユニットテストなんかも当然ない状況なんで Rustに限らず静的型ならその辺をだいたいコンパイルエラーで拾えるのが楽 >>27 「僕は基本Traitがよくわからない => それはRustのマイナス面」 この発想が幼稚さがわからないのかな? 他の言語と比べたときのRustのマイナス面はたくさんあるがそういう話のレベルじゃないだろ >>32 動的型付け言語しか使ったことがない初心者が 静的型付け言語の圧倒的なメリットを理解できないのはよくあるあるある 脱初心者の壁を乗り越えよう どんな言語にもマイナス面がありRustにもある しかしマイナス面を上回る莫大なメリットがRustにはいくつもあるからIT業界をあげてRustを支援&採用している 揚げ足取りでRustを叩きたいだけの人はアンチスレへ行け >>36 知らないのかもしれないけど今のPythonはどちらもできる >>35 どんな理由であれ複雑なのはマイナスだろ 複雑なのがプラスだってんならC++かbrainfuckやれよ 漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。 >>39 能力が同じなら複雑さはマイナスだが複雑にしてでもそれを上回るメリットが得られることがあるという話だということも理解できないの? トレードオフ >>41 >>35 はそんなこと書いてないぞ > 「僕は基本Traitがよくわからない => それはRustのマイナス面」 > この発想が幼稚さがわからないのかな? だぞ。勝手に自分の文脈を他の人のレスに上乗せして書いてない解釈を押し付けるなよガイジ ここはRustユーザが集うRustスレ 叩きたいだけのキチガイはアンチスレへ行け C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html >>37 嘘はいかんよ Rustにはメリットなし、がIT業界の総意 Adaの方が上 最新版IEEE調査Jobs https://i.imgur.com/Z8hI9C6.png Jobで判断するのはちょっとなあ Jobの要件にするのってその言語さえ出来れば良い人を探す時じゃん Rustってまだそのフェーズではないんだよな >>48 言うてメインはOSS用だよね 大手はちょっとばかり資金援助してレバレッジ効かせようと宣伝して 2021-2022がRustハイプのピークだったんだけど真水のJobは稀 >>46 Carbonはその公式FAQに明記してるように Rustを使える状況ならRustを使ったほうがいいという立ち位置 Carbonは既存のC++遺産メンテ用 >>49 次々とRust製へ変わっていってる リソース面すなわち経済的にもエコ的にもRustが有利なので今後次々とRust製へ置き換わっていく ソース >【クラウド世界トップシェアAWS】 >https://japan.zdnet.com/article/35183866/ >Rustで構築されたAWSサービスの例としては、 >コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、 >「Amazоn Simple Storage Service(S3)」、 >「Аmazоn Elastic Compute Cloud(EC2)」、 >コンテンツ配信ネットワーク「Аmazоn CloudFront」、 >LinuxベースのコンテナーOS「Bottlerocket」などがある。 >【CDN世界トップシェアClоudflare】 >https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html >CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、 >同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。 Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな Rustは既に違法建築だから 前スレで言われる矮小化オンパレードで笑ったw 前スレ https://mevius.5ch.net/test/read.cgi/tech/1705760500/9 >>https://mevius.5ch.net/test/read.cgi/tech/1692105879/990 一応知らない人のために書いておくけど 「Rustがunsafeコード一切なしでメモリアンセーフ」な事が判明してから半年近く経ってる 特定の機能導入のタイミングでコードが発見されたけど、 「Rustの仕様バグ」だと認識されていて直せない >>4 そんな事並べて理解したつもりでも、分からないと言っている人の側の主張が正当なんだよ 最近はここでも保証って言われなくなっただろ、当たり前だよRustの仕様に健全性が無いのだから たぶん知っていて話を逸らしているのか、過去スレでスルーしたかで、この指摘も無理やり矮小化してくるからな (githubの議論でも矮小化して放置) 気を付けろよ https://github.com/rust-lang/rust/issues/114936 >>52 情報古いな AmazonはLLRTでしょ cloudflareのRustは放置だ 誰も問題視していないどうでもいいことでしかRustを叩けない状況 アンチが追い込まれている >>53 は>>51 向けな >>52 のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した >>54 問題視したから取り繕いfixしたんだよ >>37 ,47 上位は納得だから結局のところ「IT業界をあげて」なんて言いたかったら Jobで判断するのが客観的で中立フェアな基準なんだな >>53 LLRTはAWS LambdaでJavaScriptを使いたい人向けのJSランタイムの一つ Rustが使えるならRustを使ったほうが有利 さらにAWS自体も>>51 にソースがあるようにRustで書かれている >>57 後半 部分的にな あとそのソースとやらのLiam Tungはいなくなったね 飛ばし過ぎた? >>57 >Rustが使えるなら 時々見るこの枕詞は実際の現場では使えない事の証拠なんだよなぁ >>57 >JavaScriptを使いたい人 これが圧倒的だからAmazonが独自魔改造したから凄い >>59 そのAWS Lambdaでも当然Rustを使えます Rustを使えないのは環境ではなく低層プログラマー >>55 この恣意的な例以外で同様の脆弱性が生まれる例があれば教えて欲しい 煽りとかではなく >>62 俺も煽りじゃなく警鐘で言うけど >>55 の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは (CVE報告しないで悪用されたら最悪だけど) Rustのメモリ安全性目標チェックは他の言語と比べて 相対的にメリットがあったりデメリットがあったりするだけのことだから 例出せないならお前が偉そうに言うことではないぞ どの立場からもの言ってるんだ? 俺の質問に答えずに訳のわからないことを言うしかできないんですね くだらないクズが >>52 実際の開発では出てこない極端に作り上げた例のみだから Rustを採用しているIT大手を含めて問題視していない >>66 ちなみに急に煽り始める>>65 ,67はあのコテハン >>68 >実際の開発では出てこない極端に作り上げた例 自分で踏んだ事ないから想像だけど、失敗を犯すのはその考え方の人間 いや煽ってきたのはお前だろw 何を勘違いしてるんだ 自分が攻撃するのは良くて攻撃されるのは嫌か? そういうやつには徹底的にやるから覚悟しろよ 俺に攻撃するってことはそういうことだ 自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな >>69 実際にコードを見てごらん ありえない無意味なコード 識者たちも問題視していない >>71 誰も攻撃してないのにこの人怖い、やめてくれませんか 心理的安全性を通り越して身の危険を感じる((((;゚Д゚))))ガクガクブルブル 例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない? 絶対ない? rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか そういうテクニックが必要になると思う。 その辺の整備が進めば割と広まるかもね。 >>76 絶対にないから安心していい その「&'static &'a ()」が出てくることはない >>32 サクッとプロトタイピングする目的ならそりゃRustよりPythonのほうが向いてる Rustは多少手間がかかったとしても速度・安全性・堅牢性を高い水準で求める場合に使う言語 >>39 AsRefやTryFromが複雑とか言われても困ります >>77 unsafeは基本的に不要 必要だと思ってもまず標準ライブラリにその機能がないか調べる 次にクレートにその機能がないか調べる どこにも存在しない場合 unsafeを安全に閉じ込めて安全に使うことができる有用な機能を発見したのならばラッキー それをクレートとして公開するとよい Rustコンパイラチームは意図せず発生する可能性を否定していない様子 ここのヤツはやっぱりテキトー言ってるだけか https://hackmd.io/@rust-compiler-team/SkkrA1DCK#Variance > https://github.com/rust-lang/rust/issues/25860 > root issue of most variance issues > ⚠🚨⚠ can potentially just happen by accident >>77 同じ構造体の一部を参照しながら別の一部を書き換える大きめのメソッドを 複数のメソッドに分割しようとするとborrow checkerに引っかかる的な話かな 他の言語のクラスと同じ感覚で構造体作るとたまに嵌る Rustの構造体はRDBのテーブルを正規化する雰囲気で分割した方がいい >>82 Rustのvariance仕様だから発生させることはできるけど 現実に使うコードでは発生しない 意図的にその仕様の狭間をつく現実的でないコードでのみ発生する そのためその2015年からそのまま放置で誰も困っていない >>84 by accidentを辞書で引いてこい >>85 その2015年から9年間 その問題でトラブルが起きたことがない >>81 >unsafeは基本的に不要 >...ラッキー 嘘で始まって運頼みで締めるとはw 信者の心の支えの大手のあそこは 見境なくunsafeを使わざるを得なくなって Rustでやった意味が無くなってるってよ 可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある? RustはVec等のCVE前科があるからなぁ 頭に隕石が落ちたんじゃね? 開発プログラムでunsafeを直接使うことはほとんどない unsafeが閉じ込められ安全なインターフェースが公開されている形で間接的にのみ用いる どうしてもunsafeが必要になった場合でもそのように安全な形で分離して用いる 隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう >>89 Dropで型がpanicする時にその要素をた用いたVec::from_iter()で二重解放のバグが発見された件か もちろん他の言語と同様に全ての言語においてライブラリにバグが見つかることは当然ある Rustはその点でも少ない方なので信頼して使える >>90 ,92 思い描く理想と現実の落差が激しいな Rust不信の原因だぞ とくに>>92 の最後の行があるから信用されない Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ Rustの2022年のCVEは0件 つまりRustコンパイラについて過去2年間でCVEなし 信頼度が高いと言える Rust以外のコンパイラってそんな言うほどバグないか? 普通にあるけどみんなで使うから大部分はリリース前に潰される コンパイラというよりライブラリのバグみたいだけど他の言語より未定義動作にシビアだから バグ扱いされる事例が増えるのは仕方ない >>91 お前のとこは無限のリソースがあるのかな? いいなぁ優先順位考えなくていい環境。うらやましいよ。 今となっては未定義動作の多い言語を使うのは悪行だ Rustを使うべし >>82 ここの信者はテキトー過ぎるよな コンパイラ開発チームはもとより、サーベイ回答者もコンパイラバグ潰しを最優先、が一番多い >>97 余裕があるからRustもやる、と言うのが普通だな サーベイでも(余裕がなくなって)Rust採用予定なし、なぜなら他言語採用予定だから、が一番多い (ただし採用にはインターンも含まれる) >>99 対処の必要があるものはその通り しかし実害がないと皆が判断して対処優先度低いまま9年間が経過したが実害がな起きていない そんな状況のものを杞憂したり揚げ足取りでRustを叩いてる連中がゴミ 事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな >>101 これが矮小化と言うやつか 7割がバグ潰しを「最優先」と回答している事実 直したくても直せないまま何年も経過、unsafe無しでメモリ安全ではない(事実)、Rustの不健全仕様(事実) (unsound=不健全は数学用語、要は矛盾があるという事) 幸運にもRustが使われなさ過ぎで実害がないように見える(または報告がないだけ) (良心的に考えてRustが広く使われてない内に)バグ潰しをしとけ、がユーザーの9割の意見(中優先含めて) 週明けのテック記事はどう書くのかな 良い所だけ抜き出してビューが取れるハイプ期間は弱まったと思う それと飛ばし過ぎるといなくなるorz アンチもMozillaが変なことやってるだけで firefoxに導入できるわけがない一般人が 使えるようになるのは妄想とか 言ってた頃に比べると細かい実装の穴を ネチネチやるまでになって大変だなあ >>103 根本的なことを理解できてないようなので一点だけ unsafeがプログラム全体に散らばっている他の言語に対して Rustはunsafeを局所的に閉じ込めて安全なインタフェイスを公開しそれを使ってプログラミングする言語 よく使われる基本機能は標準ライブラリとしてunsafeを閉じ込めてあるが 必要なら自作を含めてunsafeを閉じ込めたライブラリを使ってよい 他の言語と比べてunsafeを局所的に閉じ込めた部分のみ注視すればよいことがRustのメリット >>105 unsafeに閉じ込められなかった事実を提示されてるんだが何言ってるんだ? Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。 unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは もちろん呼び出される側の安全性ではない 呼び出す側だけが検査される しかも検査が完璧かどうかは実装依存 じゃあ言語仕様により保証されるのは何か 言語仕様は、あとは検査が通るか通らないかを確かめればよいというところまで仕様を確定しなければならない プログラム全体がunsafeなC/C++は使いたくない 未定義な動作も多すぎる >>109 Rust関係無しに基本的なことを理解できてないようだけど 掛ける情けも無し 反論できないときは関連するワードを含むRustの宣伝文句をぶつける いつもの流れです 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 https://news.mynavi.jp/techplus/article/20240222-2889545/ >>105 ,109 詐欺師みたいな偽者だな、Rust不信の種まきするのやめろ >>112 分かっていれば支離滅裂文章なんだけど騙されるのは学生位だろうか >>前スレ992 Derefは演算子 ・そのためstd::ops::Derefにある (変換std::convert::AsRefと対照的) ・演算子*によりderefされる ・&**へとcoerceされる Derefの名前の由来は*演算子(dereference:参照解決)だろうけど 機能は&**へのcoerceを前提にしてて結果的にrefのままだからややこしいな 現状だとInnerRefの方がしっくりくる 意味的にはFollowRefの方が自然かな まあ*演算子で使われるtraitだからDerefでいいんだけど 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★] http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50 ボイス・トォ・スカるしている者も攻撃を受けるようになりました >>115 >・&**へとcoerceされる これDeref Coercionのこと言ってる? だとしたら&**に限定する意味がわからない あと前スレ992で重要なのは&T→TはDerefの役割ではないというところね >>116 ,117 スマートポインタのdereferenceのために存在するTraitだから InnerRefやFollowRefよりDerefのほうがずっと自然だと思う *演算子の振る舞いとは別にcoercionの振る舞いは理解しなければいけない そういう点でも「Derefは演算子」という捉え方は良くないよ Rustて、演算子と関数を(意味論的に)区別していたっけ? 中間記法によるややこしい結合順の違いがあるぐらいで、構文解析後は等価だから、あんまりこだわっても仕方が無い気が。 中間記法の演算子は人間の算数の記法に配慮しているだけの悪習でしか無いから、積極的に差異をつけないほうが良い気がするけど。 Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。 +に対するAdd, &=に対するBitAndAssignと同じ位置づけで (*T)に対するDerefがstd::opsに入ってるイメージだけど (*T)自体は let x: Box<String> = Box::new(String::from("foo")); let y: String = *x; みたいに参照先の値を取り出す使い方ができてむしろそっちが本来の意味なのに それができないtrait DerefがDerefを名乗ってるのが微妙だと思った >>121 サンクス。 「演算子」じゃなくて「 * (参照外し演算)」ということね。 >>116 *を明示的に付けるとdereferenceされるからDeref &**によるcoerceは何も付けずに適用される そのため参照から参照へ型が変わるだけで参照のままとなる >>119 Derefはoperatorなのでstd::opsにある Derefでも&T→Tと実装されている Derefによるcoerceは&**となる 関数と同じでは困るものといえば && || が有名だけど = が一番やばい 初期化とか代入とかコピーとか移動とか >>125 =はパターンマッチング マッチングした時にCopy実装があればコピーされる 以上で極めてシンプル Rustにおける = は心の中でバインド演算子って呼んでるわ >>124 >Derefはoperatorなのでstd::opsにある https://doc.rust-lang.org/std/ops/index.html ここ見ればわかると思うけど各Traitの説明に”The ~ operator”と書いてるものがoperator Derefは”Used for immutable dereferencing operations, like *v.”とあるようにDerefそのものはoperatorではない >Derefでも&T→Tと実装されている Deref<Target=T> for &Tの実装が提供されてるのは別の役割のため その実装が実行されて&T→Tになっているのではない Box<T>→Tなんかも正確に言えば&Box<T>→&T >Derefによるcoerceは&**となる 全然わからない 何か一つくらい根拠を提示してくださいな Derefによるcoerceは&**となるのが全然わからないって本気なのかな? 「corece後の参照」= &**「corece前の参照」 となるのがDerefによるcoerceだよ >>129 >「corece後の参照」= &**「corece前の参照」 実験コード書いて一通り確認してみたら たしかにそうなった 上の一連の流れ見てるだけでRustしんどそうに見える >>129 なるほどそういう風に捉えてるのか ちょっと独特だね それはcoercionの動きというよりderefのシグニチャを 内部的にderefを使ってる*演算子で再定義しようとしてるので 循環が気持ち悪いけど一つの見方として頭の隅にしまっておく ちなみにThe Bookにある一つの例ではderef coercionがなければ*が余計に必要と説明されてる https://doc.rust-lang.org/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods それに&**とは必ずしも等価じゃないからDeref Coercionを説明するのにはあまり勧められないかな let x = "Hello".to_string(); let y = Box::new(x); let z = &**y; //zは&strになる let z:&str = y; //これはcoerceしないのでコンパイルエラー こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ https://doc.rust-lang.org/src/alloc/boxed.rs.html#1927 >>135 それが&T→TはDerefの役割ではないという話 rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。 >>137 まあそれは他の言語も歩んできた道だから…… 良いとは言わんけどなくてもめんどいんだよな。 >>136 *selfはそれでいいけど、**selfはそれじゃ説明付かんぞ >>139 &T→Tと同じでBox<T>に対する*演算子もコンパイラビルトインだからDerefのimplは使われない Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ? Tauriがこなれてきたからそろそろ.NETからアプリをRustにポーティングしようかなと思ったらエコシステムがまるで成長していない・・・ >>133 まず基本を理解しよう deref coreceは必ず参照から参照へのみ起きる Box自体は当然deref coreceされない その例だと let b = Box::new("Hello".to_string()); まずc0は単なるBox参照 let c0: &Box<String> = &b; このc1とc2がderef corece let c1: &String = &b; let c2: &str = &b; そのc1とc2を明示的に書くとこうなる let c1: &String = &**(&b); let c2: &str = &**(&**(&b)); この暗黙に適用される&**がderef corece この自動適用のおかげでstrのメソッドが使える assert!(b.starts_with("He")); フルに書くとこうでもちろん対象はbではなく&b assert!(str::starts_with(&b, "He")); この&bが前述の通り自動的に&**(&**(&b))となり&str型へcoreceされている >>141 圧縮アーカイブならzipクレート 圧縮ならlibflateクレートなど >>133 > coercion 横から素人がすまん、これ何て読めばいいの? Rustもちょっと前の熱狂はなくなってしまった感じ 入込数が減ってると思う まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは >>144 発音[US] kouə́ːrʒən | [UK] kouə́ːʃən カナ[US]コウアァジョン、[UK]コウアーション 参考:https://eow.alc.co.jp/search?q=coercion 自分はコアジョン派 Tのスマートポインタの参照 -> Tの参照 文字の配列の参照 -> 文字のスライス 一連の流れを見るとみんなポインタに熱狂している >>150 そこはポインタと参照の根本的な違いを理解しできるかどうかかな 「Boxというスマートポインタ」の参照を扱うから意外に感じているのかもしれないが 「Boxというスマートポインタ」はヒープ領域の解放責任つまり所有権を持つ したがってBox自体を他の関数などへ渡してしまってはmoveしてしまい継続して使えなくなる だからスマートポインタの参照を渡すことになる 一見するとこれはポインタのポインタで無駄な間接参照に感じるかもしれない しかし参照=ポインタではなく参照は抽象的なものなのだ Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。 C++ の参照はオブジェクトではなく参照の参照もとれないし参照のポインタもないし、 参照のサイズも取得できないというのに比べたら Rust の参照は実体のあるものとして感じられてしまう。 その橋渡し役がDeref coercion &Box<T>はそのままだとTのポインタを持つBoxへのポインタとなってしまうが Box<T>→TのDerefがあるため &Box<T>→&TとDeref coercionが適用できる 静的にコンパイル時点で行われるため実行時コストはかからない >>142 この辺り最初理解するまで訳分からんかったな 理解すると大したことはないのだが >>142 >deref coreceは必ず参照から参照へのみ起きる &**との違いを認識してもらうための例を出したんだけど伝わらなかったみたいだね それは別にいいんだけど書いてる内容を見る限り Deref Coercionの動きを単に擬似的に再定義しようとして&**になると言ってるだけじゃなく 実際に&**が適用されると思ってるみたいに感じるね だとしたらそれは完全な間違い derefの実装の中で*演算子が使われることはあってもDeref Coercion自体は*演算子とは関係ないんだよ Boxのderef実装だって*演算子を使わずself.ptr.as_ref()的な実装で実現してもいいわけだし とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね Derefは* Deref coercionは&** 前者は明示が必要な点が違い x: &Box<T> とすると *x: Box<T> (by Deref &T→T) **x: T (by Deref Box<T>→T) &**x: &T (xのDeref coercion結果) x: &Vec<T> とすると *x: Vec<T> (by Deref &T→T) **x: [T] (by Deref Vec<T>→[T]) &**x: &[T] (xのDeref coercion結果) x: &String とすると *x: String (by Deref &T→T) **x: str (by Deref String→str) &**x: &str (xのDeref coercion結果) >>157 とりあえずDerefの定義が pub trait Deref { type Target: ?Sized; // Required method fn deref(&self) -> &Self::Target; } (https://doc.rust-lang.org/std/ops/trait.Deref.html ) でderef()の戻り値には自動的に&がつくから *x: Box<T> *x: Vec<T> *x: String はDeref traitと関係ないことを抑えておこう そこに(by Deref…)を書かれると話がおかしくなる *Tができることの一部をDeref traitではできない 正確な表現かは分からないけどDerefは&の向こう側でしか*を適用できない こうだろ x: &Box<T> とすると *x: Box<T> (by Dereference) **x: T (by Deref Box<T>→T) &**x: &T (xのDeref coercion結果) x: &Vec<T> とすると *x: Vec<T> (by Dereference) **x: [T] (by Deref Vec<T>→[T]) &**x: &[T] (xのDeref coercion結果) x: &String とすると *x: String (by Dereference) **x: str (by Deref String→str) &**x: &str (xのDeref coercion結果) なんかゲシュタルト崩壊してきたんだがw 関係ないけど微積のdxとかdyを思い出してしまった C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ Deref coercion &**のうち 右側の*は参照に対する参照外しで 左側の*はDerefで定義(実装)されてるものなのね let s = String::from("xyz"); let x: &str = &s; let x: &str = &&s; let x: &str = &&&s; これ全てコンパイル通ってderef coercionされるから 『by Deref &T→T』も適用されていると思うぞ >>163 &&T→&Tのことを&T→Tとは書かないわな 前者の用途にDeref for &Tは存在してる >>156 演算の名前はdereference derefはDerefトレイトに定義してあるメソッドの名前 >>157 >Derefは* 違う Derefはトレイト *はdereference operator >Deref coercionは&** 違う Deref Coercionとはcoercionが行われる場合に「&Tを&<T as Deref>::Target」にcoerceすること Deref Coercionと*などの演算子は全く別の独立したものとして扱われている それぞれの処理の一部で必要に応じてDerefに定義されたderefメソッドを活用してるというだけ 片方がもう片方に依存してたりもしない Deref Coercionの処理の一部として呼び出されるderefメソッドを 演算子で擬似的に再定義しようとすれば&**になるというの話はかろうじて理解できるが 前述のように定義が循環してるだけでなく再定義する価値を見いだせない >>164 &&T→&Tの場合もreference用のビルトインderefが先に動いてDeref for &Tの実装コードは動いてない可能性ない? >>164 Deref coercionの定義を理解しよう Deref T→Uが実装されている時に (つまり*TがUとなる時に) &T→&UのDeref coercionが自動適用される &String→&str (by Deref String→str) &Vec<T>→&[T] (by Deref Vec<T>→[T]) &Box<T>→&T (by Deref Box<T>→&T) &&T→&T (by Deref &T→T) これらはすべてDeref coercion >>165 Deref T→Uが実装されている時に (つまり*TがUとなる時に) &T→&UのDeref coercionが自動適用される U=*T ↓ &Tから出発すると U=**(&T) ↓ 両辺の参照をとると &U=&**(&T) つまり Deref coercionとは&**の自動適用のこと *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に ビルトインderefみたいな名前をつけるのが間違っている >>170 mutabilityを除けば左右どちらも同じ型だから形が同じであることは問題ない 左はmutabiltyが必要だからderefではなくderef_mutと区別されていてその点でも問題ない 判りにくい仕組みだけどこれから開発が進むと 文法変えたりするのかな? これほど分かりやすくて便利な明確な仕組みはない 他の言語と比較すれば明らか 他の言語でこれより良いものが存在しないね RustのDeref ・自動適用されプログラマーの負担を軽減し利便性も良い ・魔法ではなくtrait Derefの実装に基づき動作して分かりやすく自作の型にも適用可能 ・コンパイル時に静的に解決され実行時の付加コストゼロで高速動作 >>172 Pythonが分かりやすいのは知ってるけど RustとPythonは両極端だから文法を微調整してもしょうがない 文法を変える必要があるのは両極端を否定する言語だけだ Derefなのに&が消えてない(小並感) 背景を理解しないと引っかかりやすいRustの七不思議候補 この仕組みがベストであるという主張は3種類ある 一つは馬鹿な信者が言ってるだけという可能性 一つは本当にこの仕組みがベストである可能性 最後は信者ではないけど素直な馬鹿だからもっと良い仕組みを知らない可能性 このどれであるかは賢い人間がもっと良い仕組みを教えてあげると判別できる 馬鹿な反論が返ってきたら馬鹿な信者 合理的な反論が返ってきたら本当にこの仕組みがベストかもしれない 意見を翻されたら素直な馬鹿 この仕組みがない方が良いということ? 下手で全部書くべきと? RustのDerefとそのcoercion枠組みの利点 ・プログラマーの負担が減る ・コードが見やすくなる ・枠組みはDerefトレイト利用で明白かつ汎用的になっている ・自分で作った型にも実装して作動させることができる ・静的に解決しているためミスしてもコンパイル時にわかる ・実行時に付加的な動作がなく高速に実行される これらの利点を上回る方法があるならば知りたい 既存の言語でも新規の方法でも >>179 >下手で全部書くべきと? どこかの方言? >>178 いずれにせよRust信者は自分の信仰を他人に押し付けるために検証可能性を潰すから、科学とはほど遠い姿勢かと。 Rustの方式の利点は>>180 に挙げられているから もしRustより良い言語が存在するならば その方式およびRustの利点を上回る利点を挙げればいいんじゃね? 検証可能とはコンパイラが無謬であることではない ここが難しい コンパイラが未完成の状況でも人間が正解の一部をなぜか知っていること これが検証可能 単に理解できないから難癖つけてるだけだよねこの人 自分の主張も一切ないし 誰かの難癖を自分が思い付いたかのように言ってるだけで 何一つまともな批判はない 全く相手にすべき人間ではないと判断する よって今後無視する >>184 それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう 技術者なら自分が使っている道具の限界や弱点とは真摯に向き合うべき その際他の道具との比較も必須ではない 技術的選択は突き詰めれば必ずトレードオフが生じるもの 利点だけを見て欠点に目をつぶったまま良し悪しを論じるのは愚の骨頂 Rustの方式の利点は>>180 に挙げられているから もし仮にRustより良い言語が存在するならその言語の方式の利点を挙げればいいんじゃね? >>191 >それは「批判するなら代案出せ」と同じ議論を潰すだけの態度なのでやめよう 議論を潰すというよりも批判から逃げたいだけだろう 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな >>167 >&&T→&Tの場合 これ調べてみたんだけどビルトインderefが優先的に動いて Deref for &Tの実装は使われてなかった ビルトインは*を明示指定しないといけなくない? coercionは何も指定しなくてもDeref実装があれば自動的に多段に適用してくれるけど impl Deref for &T はtrait境界を満たすためだけに定義されてるんだろうな 標準だとDeref境界はPinくらいしか使ってないけど >>199 *演算子のときもDeref CoercionのときもビルトインderefがDeref::derefよりも優先して使われるよ derefの仕方は状況によって使い分けかな 例えばVec<T>からスライス&[T]にする場合 // deref operatorを使う方法 // 一番短く頻出 let slice = &*vec; // RangeFull Indexを使う方法 // Rangeを変えて汎用的に範囲指定ができるメリット let slice = &vec[..]; // deref coercion先の型を明示する方法 // 関数呼び出しは引数の型が明記されてるのでこのパターン let slice: &[T] = &vec; // deref()メソッドを使う方法 // ただしDerefトレイトのuseが必要 use std::ops::Deref; let slice = vec.deref(); uv、めちゃ速いな 今までの処理時間はなんだったのか これはRustの印象を良くするツールになるわ uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある!)が有名だが そのuvはRust製のPythonパッケージマネージャーなのか JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速 Pythonの管理ツールまたなんか出たの!?という気分 uvはPython版のcargoを目指しているらしい nvidiaのど汚なさを理解してなさげで不安しかないわ RustでDB使う時の定番ライブラリって何ですか? ORMが好きならdiesel ORMが嫌いならsqlx 最近RDB以外のDBの存在を知った人にありがちな反応だよな Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか?C++でいうEffective C++みたいな >>216 Rust for Rustaceans >>219 Rustはデフォルトのハッシュ関数が最強最善の暗号学的ハッシュ関数であるSipHashを採用しているため衝突にも強くハッシュDOS攻撃に対しても安全 もし強い衝突耐性を必要としない用途ならばFxHasherなどの速さ重視のハッシュへと簡単に置き換えられる type Hasher = std::hash::BuildHasherDefault<FxHasher>; let mut map = HashMap::<Foo, Hasher>::default(); こうね HashMap::<Key, Value, Hasher> 解決案としてはそうなのだが、デフォルト挙動が罠すぎる デフォルトいらなかったのでは Rustは利用者はアホだと思ってる だから徹底的に厳しくしてくる 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ? そう考えると初心者向けにデフォルト厳しくしておくのは正解な気がするわ、セキュリティに関わるし まあ言語側はそんな事考えずにとにかく一番スタンダードなものデフォルトにしろって考え方もわかるが Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし 逆にそれと独立にimpl std::hash::Hashで自分の各型に対してハッシュ計算法を指示できるし この2種類のトレイトを標準で用意してくれているRustは非常に好環境 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。 状況に合わせて選択できたり自分で作れたりする人はそうするんだから、 デフォルトではそうでない人を想定するだろ。 いやそもそもデフォルトいらんくね? なんでデフォルト欲しいんだ? 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな rustの場合は何事も「安全」に基づいて設計されてると認識してる 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな ハッシュ関数の特性だけじゃなくhashbrownの特性も知らないといけないしその両方を組み合わせた際のハッシュDoS耐性の程度も評価できないといけない HashMapのように基本的なデータ構造を使うのにどんな場合でもいちいちユーザーがその選択しなきゃいけないようだと辛すぎるわな HashMapで使われるHashに重いものを使う必要がある局面は限られてる でも他人のライブラリの外から必要な時にハッシュアルゴリズムを変えることなんかできないので悩ましい人もいるだろう 僕が美少女とセックスするためのプログラムはRustで作れますか >>233 ライブラリを作成する時にその用途に応じた適切なハッシュを用いればよい 用途により異なるならば安全側に倒すか指定する方法を提供すればよい とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの? Rustだとなんか問題あるんだっけ? >>236 ライブラリのハッシュを差し替えられない デフォルトハッシュを使うような人間がどんどん参戦してきてcratesの名前空間を埋め尽くしていく ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい そこまで必要としない用途であると判断できた者だけがFxHashなどを用いればいい RustコンパイラもFxHashを用いている https://github.com/rust-lang/rustc-hash 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ これ治すにはいちいち依存ライブラリ全てをcloneしてきてチマチマ変更していかないといけないってマジかよ 言語とは関係ない 外部からのデータを扱うなど攻撃耐性など必要となる部分には攻撃耐性のあるハッシュが必須 そうでない部分には攻撃耐性は必要ない 各プログラムの中にこれら両者はは共存しうる この使い分けができているかどうかは各言語の問題ではない ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる やはりエコシステムやそこにある資産も含めての言語の評価だろう それにユーザーの問題を言語が引き取らないのであればコードを書く人が充分賢いことを仮定することになり、C++で良いということになる >>241 C++だけでなくスクリプト言語であろうがすべて同じ 攻撃耐性が必要となるところで強度の高いものが使われてなければ欠陥プログラム >>242 だからデフォルトなんかいらないんだよ ハッシュごとき使うのにデフォルトがないと使えないような人間がcratesの名前空間を埋めていくのはヤバいよ >>243 ほとんどの言語の連想配列(hashmap)のハッシュ関数はデフォルトがありますよ 指定しないと使えない言語がもしあるとしてもレアじゃないですか? >>244 それはJavaScriptやPythonのような馬鹿がライブラリを書いて馬鹿が馬鹿の再生産をすることを推奨している言語の話でしょう? もしくは仕様だけ緩く決めて実装には何の責任も取らない言語か スクリプト言語だと速度は求められないという了解があるし Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。 抽象化にはコストはない (または十分に小さい) が実行すれば実行内容に相応の実行コストが生じるのは当たり前のことだし、実行内容を最小限にすることを目指したって単に不便になるだけだ。 あらゆる言語のあらゆるプログラムについて以下が成り立つ 【必須】信頼できない外部入力データに対しては攻撃に強いハッシュ関数を用いなければならない 【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい この状況で安全な言語はデフォルトとして攻撃に強いハッシュ関数が適切 そして後者と判断できるプログラマーのためにハッシュ関数を指定できる仕様が適切 Rustはこの適切な仕様となっている 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍 現実のプログラムだとそれ以外の部分が大量にあるためそれ次第で誤差だね これはデフォルトが安全側に倒す形を取っていて正解と思う >>248 >【自由】そうでないデータに対してはどのハッシュ関数を用いてもよい いやーそれはどうだろう? ハッシュDoS耐性は不要でも例えばFxHashを使うべきじゃないユースケースも普通にあるよね? stdに1つしかHasherが用意されておらずサードパーティ頼みな現状は言語的には結構不親切 hash自体は基本的にアホでも作れる それが適切なのかどうかは不明 Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど すべての言語で用意されてるでしょ? Rustは様々なハッシュ関数が標準ライブラリにないと言うけど それが普通でしょ? さらにRustの標準ライブラリはなるべく小さくする方針ね >>255 ここまで読んでそういう解釈になってるなら理解する力が足りてない 重いハッシュ関数がデフォルトになってるのがどうなのかと言う話 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね 攻撃の可能性のない部分のみを後でチューンアップつまり弱いハッシュ関数で置き換えるだけだから これより良い策があるの? >>258 バカなの? それだとチューンアップする前が攻撃耐性ないじゃん 江戸時代士農工商の身分制度があって 雨の日だけ農民も下駄を履いてよかった みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ IDコロコロ全肯定君 攻撃されるかもしれないのに攻撃の耐性をつけてない人に 対するフールプルーフのために一律全てのコードを遅くする そもそもその人が設計ミスってるんだろう SafeSlowHashMapみたいな名前にすれば良いのに >>264 >>265 Rustを使ったことすらない人が文句を言ってるのか RustのHashMapはHasherに対しても多相であり型パラメータでHasherを指定する >>266 HashMap::new()すらしたことないのかな? >>266 誰もそんな話してないやろ これだから複クンは こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ いつもおかしなことを言ってる ripgrepとかuvとかの既に実用が始まってるRust製アプリでは デフォルトのハッシュ関数使ってるの? >>267 やっぱりRustを使ったことないんだな impl<K, V, S> HashMap<K, V, S>にfn new()は存在しないため HashMap::<Key, Value, BuildHasherDefault<Hasher>>::default()のように使う ほらこんな壊れたレスしかできないんだよ 脳が死んでる いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン 今回のHashMapの件で例えると もしデフォルトのハッシュ関数が安全でなく速いものだと「Rustはデフォルトが安全でない!」と叩く もしデフォルトのハッシュ関数が安全で遅いものだと「Rustはデフォルトが遅い!」と叩く どちらになっていても叩くことが目的のキチガイ 「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが 「俺が低速なプログラムしか作れないのは言語のせい」は間違ってる 『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い ほんとどうでもいいな 自転車置き場というより豚小屋の議論 プログラムしかしない人はこういうことしか考えることがないんよ 知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。 安全方針のRustとしては、ハッシュ衝突強度を知らなくてもデフォルトで安全がベター。 デフォルトいらんが ハッシュも自分で選べんガイジがハッシュマップ使うな >>279 わかってなさそうなので再度書くけど ハッシュ衝突強度が高いからと言ってハッシュDoS耐性が高いとも限らないしHashMapに適してるとも限らないからね 弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの?デフォルトはパフォーマンス優先で良いと思うけどな。 攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。 そして攻撃されてから対処するのでは遅いかもしれない。 パフォーマンスチューニングは遅いことが問題になってからやるので深刻ではなかろう。 RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない もちろんPythonやJavaScript(v8)やSwiftなど多くの言語がこのSipHashを使っている そのうえでRustは必要とするHashMap毎にFxHashなどさらに高速なものを簡単に指定できる Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ 他の言語たちがRustを参考に同じように後追いしているのね >Pythonの文字列やバイト列に対するハッシュアルゴリズムは、HashDoS対策としてPython 3.4から SipHash24が使われていました。 >その後、ラウンド数を減らしたSipHash13でも十分に安全だとして2015年にRustが、2016年にRubyが、SipHash24からSipHash13への切り替えを行いました。 >Rust や Ruby からは数年遅れましたが、Pythonもデフォルトの文字列ハッシュアルゴリズムがSipHash13に切り替わりました。 >>286 常にそれをされたら困るが Rustでもハッシュ値をオブジェクトに持つstring_cacheなどが用途に応じて使われている >>274 人にキチガイと言う前に自分の脳を使って考えたら? どちらになっても叩くことはないだろ 他の言語はデフォルトで速いハッシュを使ってるよ 他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹 他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう >>283 判断できない人まで言語側で救う必要性が分からない。 それなら、unsafeもカジュアルに使えないように仕掛けを用意した方が良いんじゃないかと。 必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは? 安全と速度は両立するかそれともトレードオフか トレードしかしない人にとって、コストは支払うと決めたら絶対にキャンセルできない印象があるよね 有償かと思ったけどよく考えたらやっぱゼロコストだったという現象は許せない Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな 賢いならRustなんかやらない 自由があればデフォルト設定を強制されないのは自明な事実 ただし、賢い人間が自由を所有しているのか、道具自体が自由度を持っているのか そもそも「所有している」というのはただの感想なのか客観的事実なのか アホ vs バカの不毛な争いが続くのは隔離スレにワッチョイつけたやつの責任だからな 本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。 5chでRust使ってるって言ってるやつらはそんなもの 不毛の判断が早いなあ 後世の歴史家が判断するという定型文に縛られないから早いんだな 安全と速度を両立させたのが RustやPythonなどが採用しているSipHash13 >>295 いや、unsafeは判断できる人が使うものだろ。 >>300 分かってるんならワッチョイ付きRustスレの盛り上げに協力してくれんかえ ワッチョイなんか盛り上がる訳ねえ そんな話題あったらこのスレに投下してつまらない議論を流した方が余程生産的 高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話 30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ 能力が低下してコーディングできないのとしないのでは大違い 結局スクリプト言語で書かれた原作が必要か 他のジャンルでも原作なしのオリジナルは難しそうだろう Rustで書き直してパフォーマンスが上がったので注目浴びる!みたいなプロダクトはなんか白けるよな。 JSとかPythonの基盤ツールをRustで書き換えて激速!みたいなのはもう汎用言語としてのアイデンティティ捨てられててオワットル。 日本みたいに、何とかするには人投入しよう!スキルどうでもいいからとにかく人集めて!なところじゃね~。 おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。 歴史的事情でごちゃごちゃしてて遅いのが仕方がないと思われていたものについて 速度を意識して書いてみたら数百倍単位で速くなってわひゃーーというのが強烈なインパクトだった。 (それは C++ で書かれてるんだけどね。) 商売で開発ツールを提供している会社にとっては少なくともそれと同程度のものを出さないと面子が立たない。 リンカを作ってるところはこぞって高速化に努めた。 リンカ以外にもその機運が波及しているのが今。 で、高速化のキモはデータ構造であるというのが明瞭になったんだけど メモリ管理の部分を処理系 (ランタイムサポート) の側でやるようなものだとそこんところのチューニングが出来ない。 Rust である必然性が強いわけではないけど C++ とかよりは今なら Rust のほうがいいかなってのはまあ自然な判断ではある。 コードを書けない プログラムできなくなるとこういうことしか書けなくなると言う見本 だが読むより書くほうが優れているという前提から 原作を正しく読解するよりも正しくない二次創作のほうが優れているという結論が出てくる >>315 辛辣で草 そういう似非技術者系おじいちゃんおちょくると 怒って自分が唯一知ってる知識振り回してくるから面白いぞ Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい ここはRust専用スレ コーディングが出来なくなると人生はつらいと思うけどな… できなくなるんじゃなくて 元々できてないんよね>>314 みたいな人は というより単に職業マじゃないのかもな 趣味でプログラム触ったことあるパソコン少年的な 人はいつか何もできなくなって死んでいくんだよな つまらないね 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな ただしまともなプログラマーしか使い こなせない 無効なアドレスを参照しない 運が良ければSegmentation Fault、運が悪ければ変な値が使われて何か起こる 無効なアドレスを更新しない 運が良ければSegmentation Fault、運が悪ければそこの値が壊れて何か起こる メモリリークは割とどうでもいい >>330 メモリ安全性のうち特に重要な一つがメモリ競合の安全性 まだ使っている値を意図せずに書き換えてしまい矛盾してしまう プログラミングで起こるバグの代表的な一つ Rustではこれを防ぐことができる >>331 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばメモリの概念理解せずにC言語使って、動かすたびに結果がかわるバグプログラム生み出してビビリ倒したことを思い出しました…… >>332 ありがとう 「運が悪ければ変な値が使われて何か起こる」 そういえばC言語の現在時刻取得関数がポインタ返し&参照先書き換えるタイプの関数だったので大ハマリしたことありますね… WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。 ttps://www.security-next.com/154875 デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。 2023年12月にリリースされた「同0.31.1」にて脆弱性は修正された。 パラメーターが128個以下であることを確認する回避策についてもアナウンスしている。 >>336 そういうのRust関係ないからわざわざここに書かなくてもいいよ 関係無いわけないでしょw rustで書かれてたら安全なんじゃなかったん?w ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ unsafe使用箇所だからメモリ安全の外だろうな インタプリタのスタックフレーム参照で毎回境界チェックする実装も微妙だししゃーない コード見てみたが言語関係なくダメな書き方の見本ってだけだな ttps://github.com/wasmi-labs/wasmi/commit/f7b3200e9f3dc9e2cbca966cb255c228453c792f ttps://github.com/wasmi-labs/wasmi/blob/v0.31.0/crates/wasmi/src/engine/stack/values/mod.rs#L158-L163 修正コードは毎回境界チェックしてるのと同じ extendする前に必ずreserve呼ばなければいけないとか反省の色が見られない 修正コードはhotfixでしょ masterブランチの方は結構手が入ってると思う ダメな書き方でもコンパイルが通れば安全なはずなのではw んなこたない ダメなunsafeの使い方すれば安全じゃなくてもコンパイルは通せる 直接の原因はunsafeなメソッドをsafeメソッドにしたこと unsafeのsafe wrapperの質は大事 今のコードもunsafeの使い方が怪しくて信頼できない fn get_release_unchecked_mut(&mut self, index: usize) -> &mut UntypedValue { debug_assert!(index < self.capacity()); // Safety: This is safe since all wasmi bytecode has been validated // during translation and therefore cannot result in out of // bounds accesses. unsafe { self.entries.get_unchecked_mut(index) } } >>350 俺んとこもそのコードはよく書くけれど 今回の敗因は引数のindexが生のusizeであること そこをusize直接ではなくそのラッピングの専用型にする そしてその専用型が動く範囲が必ず範囲内であることを保証する形で get_uncheckefのunsafeを使う関数をsafeに仕上げる unsafeを適切に使えないプログラマが書くと全然安全じゃないという事? 全然そういう事 Rustで無闇にunsafeを使うのは日本語で無闇に「全然」を使うくらいやばい >>353 それ言うなら 無闇に「ヤバい」を使うぐらいヤバい じゃね 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな ガンガンunsafe使ってこーぜ!! >>354 それだと単なる自己言及だから352に対する答えとして不十分では 少なくとも>>350 のindex: usizeは 何らかラッピング { index: usize }と別型にすべきところ まず範囲外のusizeでうっかり使っても型エラーにできる そしてラッピング型の動作が必ず範囲内に収まるコードであることを注視するだけで安全性を保証できる NonZeroとかNonNullみたいな固定条件ならいいけど 範囲みたいな可変条件だと型だけじゃ厳しいでしょ 別の条件で作られた同じ型の値を使われるかもしれないし ライフタイムで条件と関連付けるのも限界がある 結局テストパターン増やしてdebug_assert踏むしかない >>358 もちろん二段階 まずは専用型にすることで管轄外のusize indexがうっかり混じるのを型エラーで確実に避ける 次にコーディングやレビューやメンテでその専用型の動きに注視できる unsafeをsafeでないのにsafeにしておいて ある型が使い方によってはunsafeになるかもしれないから注視しろってのはちょっとキツイです 結局プログラマが色々意識してコーディングしないと安全にはならないのね こういうのもコンパイラがエラーにしてくれてそれを直していけば安全になるものだと思ってたんですけど unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる 実際は安全の為でもpanicで止まると困るから色々注意しないといけないし unsafeで余計なチェック省いたり黒魔術使ったりもする Rustの安全性のサポートは選択と集中がしやすくなる程度で万能ではない >>361 unsafeを使わなれば自動的に安全が保証される unsafeを使うならその関連箇所に人間による安全保証が必要、それ以外は自動的に安全が保証される C/C++はすべてのコードがunsafe状態なので自動的に安全が保証されるところがない いつもの人がきたw 結局レベルの低い人が書くとunsafeも不適切に使われて今回のように脆弱性が出てしまうでしょ Rustであれば安全と思ってる人が多そうなのでかえってunsafeによる脆弱性が見落とされたり発覚しにくくなって問題だと思うんですけど > Rustであれば安全と思ってる人が多そう いや一応言っとくけど多くはないよ流石にw 一部の人が連呼してるだけ ほかの人はもっと現実的だろな 原則はunsafeを使うな! これだけだ 理解できていてunsafeを使う場合も とにかく閉じ込めろ! 専用のクレートを作れ 専用のモジュールを作れ 専用の型を作れ まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。 それは意識して気をつけた方がいい。 ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。 チュートリアルすら読まずに書き始めてなんもわからんから教えてと質問サイトに投稿しちゃうやつはいる。 そういうやつは早めに脱落して欲しいし大抵は脱落していくんだけどどういうわけか生き残ってあらゆるところをワヤにしていく狂人がたまにいるんだよ…… 普通に現実を見ながらちゃんと学べる人なら (たまにはミスることもあるだろうけど) 大丈夫だよ。 >>358 0〜127の範囲のみを取りうるようなEnumなら作れる wasmiの例のように実行時にバッファサイズが変動するなら無意味だけど サイズが変動する場合はget_uncheckedに必要な安全性の保証をsafe wrapperの中でやるのが基本 それができないならunsafeのままにして上位で安全性を保証させるようにしないといけない >>359 のやり方はそれができてないように感じる 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい そうすればその型に対して常に安全にget_uncheckedを使える 今回の件でRustの安全性が確実になったのが興味深いよな アンチが必死に探してきた問題も>>350 でunsafe利用だった >>371 「indexがその範囲にある時のみ有効な型」の意味がよく分かってないけど 実行時に型の方でindex検査して無効時にpanic起こすなら普通にusizeでgetしてunwrapしようよ unsafeにする意味がない >>374 実行時コストをかけないためにget_uncheckedを使うのが一般的 その代わりロジックでindexが範囲内であることを保証する(ことがてきる時に使われる汎用的な手法) 誰にでもunsafeが使えてしまうのが問題なのでは? 原則使えないくらいが、バカでも安全になるからRustの方向性に合ってる気がする。 Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 まあ思ったよりも足りるけどやっぱり必要だから unsafe はある。 >>375 「indexがその範囲にある時のみ有効な型」でも有効範囲が実行時に変動するなら>>350 の引数のindexをその型に変えたところでsafeにしたらダメだよ なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか? indexの境界チェックが律速になるようなコード書いてみてえな >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、1からでもOK)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。 >>383 定数じゃなければ結局実行時にチェックするってことだよね >>384 新しい型はint型とは独立した型なんだから変数にしたってその新しい型じゃないとコンパイル時にエラー。 >>384 何十年も前なのですまそ array(-2)とかarray(6)をアクセスしたら例外発生 array(-1)はOK type Month is range 1..12 type Month_Array is array(Month) of Integer; ma : Month_Array := (1,2,3,4,5,6,7,8,9,10,11,12); for m in ma'first..ma'last loop // カウンタは1から12 ma(m) = m; end loop; 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど そのAdaの例だと実行時に範囲外に値が動けてアクセスで例外発生するから何の解決にもなっていないね How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/ こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 問題は浮動小数の取り扱いだっての。 unsafeは可能な限り避けるべきで safe Rustでの改善をまずすべき その次にindex checkの有無で意味のあるパフォ向上がある時のみ考える 現実にはsafe Rustでの改善ができてないことが多い 例えばよく見かける例としては iが動いていくのにa[i]でアクセスしてしまう これはiの範囲checkとa[i]の範囲checkで二重checkになるbad pattern 参照(ポインタ)化することで範囲checkを1回に減らせる unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね unsafeを良く知れば知るほど自然と避けるようになるから避けろ避けろと言うよりもunsafeに関する知識を深められるようにする方が大事 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 が言える限界な気がする。現にunsafeを適切に閉じ込めるためのノウハウを継承できる資料とかがないので unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 unsafe可能ソースファイル用の拡張子を別途用意して、rsファイルはunsafe禁止にしてもいいくらいじゃない? >>393 そしたら全部を unsafe 可能版で書いちゃうのが世の中の現実ってもんなんだよ。 >>392 センスの問題ではないと思うが仮にセンスが必要だとしてもセンスがあるやつが適切に閉じ込めた事例とダメな事例を類型化してパターンナレッジとして浸透させればいいだけ 今はそれが全然できてないから>>350 のような基本的なミスを犯すやつが後を絶たない windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。 >>395 ~すればいいだけって言う奴はたいてい本人はやらないんだよなぁ。 >>397 問題点の指摘や解決策の提案と 問題解決のために実際に誰が動くのかという 2つの異なるものを混同したらだめだよ マネジメント101 その素晴らしい提案がなぜされていないのか考えよう そしてなぜ自分は実行から逃げているのか考えよう >>394 Rustが流行りそうな一番の理由は「管理側」が「コーダー」にunsafeみたいなことをやらせたくないということなんだから、どこでもunsafeとか管理側が許さんだろ。 unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 危険な操作も含まれるけど危険な部分を分けれてるわけではない。 もちろん unsafe を制限する規約のプロジェクトがあったって良いが、そのための機能じゃないよ。 >>401 安全性をコンパイラが検証できないなら、なおのこと制限すべきだと思うがね。 デフォルト禁止でもいいくらい。 >>402 だからそうしたいならそうすりゃいいって話をしてる。 あなたが裁量権をもつプロジェクトでは。 私が反論してるのは「そのためのものだ」という部分に対して。 >>403 Rustのコンセプトとニーズからすれば、どこでもunsafe使えるのは中途半端だ、ということだよ。 unsafeはデフォルト禁止でいいよ。 理想をいえばunsafeなんて無いならサイコーだったんだろうね rust陣営もしゃあなしでunsafe導入したんやろうし unsafeなしですべてがセーフで効率的だったら そりゃあrustは本当に素晴らしい文句なしの言語だったやろな 生ポインタすなわちCPUによるメモリアクセスはunsafe そこが出発点 unsafeを組み合わせてunsafeを閉じ込めたsafeなインタフェースを提供できる それがsafe Rustの基本原理 つまりunsafeに行き着くためunsafe無しでは何もできない これが真理 一方で unsafeを閉じ込めたライブラリ利用可を前提にすれば unsafeを用いないsafe Rustでほとんど大抵のことが実現できるのも事実 >>406 だったらデフォルトunsafe禁止で良い。 どこでもunsafe okはやっぱりチグハグ。 そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…? >>404 「そうであって欲しいと自分は思っている」なら別にいいよ。 ニーズとかコンセプトとか、ありもしないものを根拠にしてることに反論されてるんだよ。 #![forbid(unsafe_code)] を宣言すればいい もちろんすべてはunsafeへ行き着くため unsafeを禁止できるのは自分のコード部分だけ unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな 平気でunsafe使ってくるガイジは当然平気でunsafeな拡張子を使ってくるだろうという予想する >>409 公式の「効率的で信頼できるソフトウェアを誰もがつくれる言語」に従うなら、安全でもなくて誰もが使えるわけでもないunsafeはデフォルト禁止にすべきだろ。やっぱりチグハグだわ。 >>411 拡張子以外だとどんなのができるかねぇ。コーダー向けRustとライブラリアン向けRustで完全に分けるぐらい? rustもいろいろ問題を抱えてるんだね プログラマの習熟が必要だっていうなら流行らないだろう メモリ安全なソフトウェア書くことを優先するなら土方が適当に使えるjavaやc#があるだろうし 新しいc/c++/rustと競合する決定版のような言語が出てきてrustはさらなる傍流に押しやられそう >>412 こう書くだけでunsafeの使用が禁止されます #![forbid(unsafe_code)] >>413 普通の人はunsafeなんか使いませんからRustは安全で何も問題ありません >>414 >411みたいなマキャベリガイジが混ざると破綻しますな。 MSとかGoogleとかの管理側がRustに期待するのはそういった部分含めた安全性だろ。 >>415 これでunsafeが使用禁止となり安全なsafe Rustになる #![forbid(unsafe_code)] コンパイラがunsafeをエラーとして弾く 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。 unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者 一般プログラマーはunsafeを使わずに、unsafeが閉じ止められたライブラリのsafeなインターフェースのみ用いる もしunsafeを用いて閉じ込めてsafeなインターフェースを提供できる新たなパターンを発見した時のみ、 その部分だけを切り出してライブラリ作成者になれる それができない一般プログラマーはunsafeに縁がなく、unsafeを気にする必要がない >>419 そうならやっぱりデフォルト禁止にすべきだな。一般コーダーはunsafeを使えないようにしてコードの安全性を高めるべき。 Rustのデフォルトムーブとかshared xor mutableとかは安全側に倒しているのに、なんでunsafeだけはユルユルなのかね。 unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが このメッセージが伝わらない相手にはもうunsafeの文法を分けてunsafeだけ難しくするとかしかなさそう でもわざわざ難しい文法を用意すると言うのも馬鹿らしい話だ 必要な各企業、各プロジェクトなどで義務付け #![forbid(unsafe_code)] これでunsafeの話はおしまい 他の言語と比べてRustはコーディング規約もAPI規約も公式で楽 Rust公式APIガイドライン https://rust-lang.github.io/api-guidelines/ >>422 公式のドキュメントで #![forbid(unsafe_code)] の説明を探しているんだけど、どこにあるのかしらん? doc.rust-lang.org/nomicon/safe-unsafe-meaning.html の1行でおしまい? forbidもunsafe_codeもrustcのlintの一部だな doc.rust-lang.org/rustc/lints/levels.html#forbid doc.rust-lang.org/rustc/lints/listing/allowed-by-default.html#unsafe-code Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。 どの開発でも #![forbid(unsafe_code)]が原則 どうしてもunsafeが必要なら その安全ロジックを関係者で協議後に #![deny(unsafe_code)]へそのモジュールのみ変更し 許可する部分のみを #![allow(unsafe_code)]として監視対象 といった感じが一般的かと 監視対象を極一部に限定できて 全体はコンパイラにより保証できるため 他のプログラミング言語より扱いやすい >>420 一般とそうでない奴は誰がどうやって区別するのさ? 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう >>429 safeで書くのが早くて楽で安全 わずかでもパフォ上げる必要性のあるような箇所が生じない限り、unsafeを検討する人は存在しない >>430 unsafeの使用は、その論拠の安全性の検討や、それ以前に必要性の検討などが必要となるため、時間がかかる safe Rustが楽で早く書けて安全 >>432 安全性の検討も必要な検討も全部スキップして「えいや」ってやればsafe rustより速く書き上がることもあるのでは? 雑にunsafe使って早く書けるのはFFIくらいかな FFIはどのみちunsafe必須だけど、事前条件とかの検討せずに雑にsafe化してしまうならそれは確かに早い pure Rustでunsafeの方が早いケースはちょっと思いつかないな >>427 そりゃプロジェクト管理者だろ。 そもそもRust採用するメリットはソースコードの品質管理しか無いし。 デフォルトunsafe禁止は何回か話題に出てきているのな。 >>426 それぐらいやらないとRust採用するメリット無さそうだよな。 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは? そもそも普通に書いててunsafe使いたいなって場面がない 多人数で書いてるならforbidで落としてもいいけど コードレビューでちょっとでも見ればunsafe使ってることは明らかなんだし、いずれにしてもどうでもいい >>436 じゃunsafe使うな、で済む話じゃん。 rustもプログラマがザコだと使いこなせない言語なんだろ? 人材確保すら苦労するってメジャーになれるのかよ たしかにプログラムの品質がいいから出世するって見たことないわ 逆にクソ過ぎて出世できない奴はいるかも知れんがそういう奴はプログラム云々の問題ではないからな unsafeは面倒 Rustで書いていてunsafeを使いたい気分になることがない さらに通常のプログラミングでunsafeを使うメリットがあるケースが訪れることはまずない 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。 >>440 PMやったこと無いの? unsafe使うなと管理するより、そもそも使えない方が遥かに楽。 >>442 C++ とかだと使いこなせてないのになんとなく動いちゃったりするから…… 使えてないなら使えないほうがちょっとマシなんだよ。 >>448 言語機能的にunsafeって書かなければそもそも使えないじゃん。 >>448 そのあたりの管理は開発TLの仕事だと思ってたがPMが兼任することもあるのね unsafeでサクッと終わらせてどんどん仕事取ろうぜ safeでチンタラやってる無能に仕事を回すな アンチはunsafeを使うと早く書けると誤解しているのが面白い 早くもなければ楽でもないので普通は使わない 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが 正常なコミュニケーション力を持った優秀なエンジニア →こいつらは出世するのでプログラミングスキルは生かされない方向に進む 正常なコミュニケーション力がない優秀なエンジニア →こいつらはどうでもいいことばかりブツブツ言っててイマイチスキルが生かされない どうしたら優秀なエンジニア揃えられるんや… カチョー「では進捗を報告してください」 unsafe_man「アノー、チョット時間かかってオリマシテ、アンセーフが、ソノー(怒涛の勢いで難しいことを話し続ける)」 カチョー「???」 >>457 放っておいても勝手に集まるから心配しなくていいよ そこに混ざりたいなら自身も優秀なエンジニアになる必要はあるけど >>459 すまん、集まってるとこの実名あげてくれんか? >>458 いきなり人格攻撃かよ?Rustらしいな unsafe使う機会ってほぼないよな よほどシビアな低レベルライブラリ作成かFFI部分くらいじゃないか 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人 でunsafeを使いこなせるかどうかなんか無関係 これいつまでかかるのと聞かれていつまでに終わるか言えて理由も言える人 システムプログラミング用途も売りにしてなかった? Cと同等のことをしてみせようってんなら unsafeくらい当たり前に常用するやろ?しらんけど ボクは使いません!みたいな意見は誰も求めてないからw unsafe使うと変更する時にだるくなるからできるだけ使わない グローバル変数使うのと同じ気分 「グローバル変数くらい当たり前に常用するやろ?しらんけど ボクは使いません!みたいな意見は誰も求めてないからw」 とか言われたら知らん 使う必要があるからunsafeってもんがあるんであって 使う必要がない人の意見や感想は求められてないんよ 使うべきとか使うべきじゃないとか 普通はどうとか普通はどうじゃないとか 無意味な応酬はやめよう コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。 >>451 君の時間の無駄ってこと? こんなところで毎日無駄な時間過ごしてるのに? それって君がやらなければいいだけだよね >>468 一連のunsafeコントで初めてまともな意見だな エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで Rustが普及する日は来るんだろうか 上の方でも言われてたけどコーダー集まらない問題に直面しそうだが Rustはコーダーは集まらんだろ 普通は外注先がほぼコーディングできない新人を連れてきて実質的にこちらが教育する羽目になる ある程度使えるようになるとそいつがどこか単価の高いところに送られてまた代わりの新人が送られてくる 大手だとこれの繰り返しだがRustはそれが難しい 意図的にどこかで誰かが資金を投入してRustコーダーを栽培()しないと 増えるわけがない javaやpythonじゃないんだから 野良Rustコーダーなんて存在しない 使える人間は100%C++使いなので引っ張ってこれない エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう それよりもホントにシステムプログラミングできてんのかが興味あるわ CからはOSならばUnixやLinuxやWindowsが生まれてきたけど Rustからは一体どんな素晴らしいものが生まれてくるんだろうか? Cより書きやすくて? 安全なんだよね? 期待していいんよね? Systems programming https://en.wikipedia.org/wiki/Systems_programming e.g. operating systems, computational science applications, game engines, industrial automation, and software as a service applications 今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある でも期待するのは自由だ Rustファンはみんな期待している >>477 interfaceって組み込み専門誌は毎月お題スレみたいな問題を解く記事が出てたり、Rust特集の時でもOSを作るどころか、OS乗らないような環境(Cとアセンブラの独壇場。C++不可の世界)で組み込みRust使う記事とかあったよ。 ビジネスになるかはともかく、技術的には余裕なはず。 既にネットインフラは次々とRust製 ソースは>>51 >>472 Rustは仕様や周辺ツールが飛びぬけて優秀な故 JavaやPHP等他の言語と違って素人でも適当に書いても 大した問題は起こらないから「技術者の立ち位置」を守る観点で見ると 大規模開発現場で普及する事はこれからも無いよ。 それで守られるのはITコン猿の立ち位置じゃね? エンジニアは長期的な保身より目の前の利便性に飛びつきそうだが 知ってる人間は黙ってRustの恩恵を受けておけば良くて 人売りサル業界は人/月だコミュニケーションスキルだと 喚いていれば良い。 C++が流行った経緯知ってる奴なら想像できるだろ。 C++が出た当初はSTLもテンプレートもなかったしライブラリなんかはObjective-Cのほうが多いくらいだった。 でも流行ったのはC++。 C++はわかりやすく拡張されたCだからさ ライブラリのAPIとかCばかりだから最悪そのまんまCでも良かった NEXTSTEPでObjecive-C開発は呪術で入門書もなく上手くいかなくても何が悪いのかさっぱりわからない 日本語の書籍がないのが一番つらかった 当時NeXTに触れてたやつおるん? たまげたなぁ 俺なんか図書館の奥に潜んでるObjective-Cの本読んでたよ いつごろだったかなぁ日本語のやつあったけどなぁ まさかmacOSで脚光浴びるとは思いもせずに 研究室にあったんよ 当時でももう型オチででも予算無いからリプレースも出来ず MOのデータを消しながら使ってた 古いUNIX系の雑誌の特集見てそれをポチポチやってクソうるさくて遅いHDDの音聞きながらコンパイル待って…と言う感じで 自分は図書館に埋もれたModulaの本を読んでた 羨ましい 俺は演習室のBSDのWMをafterstepにしてニマニマしてただけ あー羨ましい C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。 結局は C のままでいくと判断した。 良くなるのだとしても、少なくとも一時的には大きな混乱が起こることを C++ は許容しなかった。 言語ってのはそれを取り巻くエコシステム (言語ユーザーやドキュメントも含む) と離れて成立することはないってこと。 C++ は C のツールチェインにほとんどそのまま乗っかる形で (最初は) 普及したし。 Rust はツールチェインの整備も一緒に取り組んだというのは普及の一助になったとは思うけど、 今までに作られた膨大なソフトウェア資源の最も低レイヤの部分は結局は C なんだよね。 そもそも ABI が C を基準にした仕様だったりするので 他の言語と接続するときは皆が C に合わせる形になる。 もしこれから Rust がもっと普及することがあったとしても低レイヤでは C の残滓はいつまでも消えないと思う。 ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う >>490 Rustで書いたOSが大流行でもしない限りCと同じようにはならない。 ただ、Linux は Rust を取り込み始めたので何十年も掛けてゆっくり Rust 化する可能性はある。 そうなると移行したライブラリは増え続け、50年後ぐらいには今のCと同じようになっているかも知れない。 もちろんその頃には別の新言語が出てきていて Rust が時代遅れな言語になっているわけだが。 ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない 多言語システムはそれより多いけどそこはABIではなく様々な通信プロトコルなどを介する ABIこそ良い奴が出たら置き換えられそうだけどな 現状良い奴がないだけで >>493 何言ってんのwww 相変わらず無知が過ぎる そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス:「C」「C++」よりも「Rust」などの言語を推奨 https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html >>500 メモリ安全というならSafe Rustのみだな。Unsafe Rustは禁止すべき。 c++標準も、Safe Rust に倣って c++ subset for safe programming とか 作ればいいのに。 メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。 java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。 >>501 C/C++はプログラム全体がunsafe空間なので難しい safeにしようとすると全く別言語になってしまう 結局C/C++を捨てるのが正しい >>503 nullポイントがある時点で… 一応JavaはStream APIと同じくらいのタイミングでOptional<T>が追加されてたはずだけど,だからといって従来の「失敗したらnullを返すメソッド」がOptionalを返すように修正されたわけじゃないしなぁ ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される nullから何かを読み出して動き続けると危険 >>508 Someである保証がある時のみunwrap()を使う 保証がないのにunwrap()する人はクビ メモリ安全の文脈だからそういう次元の話ではないのだが >>505 コーダー向けだから別言語でいいよ。 new deleteは禁止していいし、ポインタ演算その他のポインタ処理は全部禁止でいい。生ポインタのヒープ領域コピーも禁止していいし、そもそも生ポインタ禁止で参照のみ可にしてもいい。 operator関数定義も禁止でいいんじゃない? ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね どの言語にも共通するけど,書けるようになってくると楽しいよ でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね >>512 あ、未定義と定義されているのも全部禁止ね。 >>500 これでRustの知名度も上がるし普及も加速しそう >>517 結構前にもNASAが同じ様な事言って今やんw rustを無理に使ってまですることがぬるぽ対策とかアホだよね >>519 まあ戦争によるサイバー攻撃に備えろってのは分かるんよ 日本も来年ぐらいに戦争になるって予測がアメリカとか含めて言われてるからね >>518 NASAに続いて米政府も「C/C++からRustへ切り替えろ」と明確なメッセージを出したことは大きいね 間違いなく日本も追随することになる Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがw ONCDは健全なのかな >>518 NASA?NSAじゃなく? NSAはNASAじゃないぞ。 ワロタ NSAとNASAの区別もできんとはww メッセージを出してるところが広がってトーンも厳しくなってきてるのは確か 2022/11 NSA 2023/09 CISA 2023/12 CISA+NSA,+FBI+Five Eyesの各機関 2024/02 White House(ONCD) >>524 あとは日本がどれだけ遅れるかだな 数ヶ月か、1年か、数年か、 外部のお墨付きを欲しがる時点でオワっとるんよ 言語として ここでそういう話題使って必死で盛り上げようとして 消えそうな火に風送ってるつもりかしらんけど IT大手ライバル同士が GAFAMからHUAWEIまで一致団結して Rust Foundationを設立した時点で未来は確定していた そしてRustに対抗できるライバル言語の芽が今も存在しない Rustの代替になる思想の言語が全くそれ以降全く見ないからな。 今のところGCレスでメモリ安全に向き合った唯一の言語でねえの? 後発の言語は Rust みたいに複雑なコンパイル時の検証を最初から書こうなんてそうそう思えないんじゃないかな。 >>527 欲しがってるかね? むしろ外部が乗っかろうとしてる感じ。 >>530 メモリ安全に向き合う、程度ならそれこそc++11が先駆けだろ。 過去互換性のせいで徹底できないけど。 それよりもRustはスタックフレーム指向であることに価値がある。 スタック is god, 再帰 is god. >>515 まあ標準ライブラリがかなりミニマムだなぁって感じるときはある 乱数くらい用意しておいてよ… >>530 ある言語Aがあってその弱点が強烈で直したいけどすでに普及しきっている で別の言語Bが作られる その言語Bが普及しきっていなければ容易に弱点を変更できるので別のC言語は必要とされない >>534 >その言語Bが普及しきっていなければ容易に弱点を変更できる これが真とは限らない 容易に変更できる場合もあればそうでない場合もある Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか wikipedia > 2015年に1.0版がリリースされるまでにいくつもの破壊的な仕様変更があったが、1.0版以降は基本的には後方互換を保って6週間間隔で定期的にリリースされている。 GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。 >>537 所有権は最終的にはプログラム間の境界の問題になるから、c++のスマートポインタのようにアダプタで管理範囲を調整することで改善可能。 適切なアダプタを用意しても境界のプロトコルをどうやって徹底するかという問題は残るから、Rustみたいに言語レベルで強制できると頑強になる。 ただ、Rustみたいにガチガチにすると設計の柔軟性を失うから、実装も早すぎる最適化になりがち。Rustの絶壁の学習曲線と相まって、開発初期のRust導入はプロジェクトを破綻させる要因となりうる。Rustが適しているのは、ある程度枯れた設計の実装を置き換えるようなプロジェクトかと。 Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ とりあえず動くように雑に書いて動かしてみて 次に機能追加充実させる上で整理しながらモジュール化や共通事項のtrait化など このようなリファクタリング過程で 他の言語だとメモリ安全性だけでなく書き換え競合やヌル値エラー値取り扱いミスなどエンバグすることも多いが Rustではコンパイル通せばそれらの心配がなくリファクタリングできる そもそもGC無しの言語ってニッチじゃない? 当面は、Rustで充足されて安泰な気がする。 うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。 関数型言語にも良いのあるけど、普及しなさそうだしね…。 (OCamlとか次世代HaskellらしいIdrisとか) それにCとアセンブラしかない分野(C++不可なくらい低スペックな組み込み)でC++以降のモダンな言語が使えるのは大きい。 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど メモリの動作モデルをそこそこちゃんと仕様にしてるのは C/C++ しかないんだよね。 LLVM が C/C++ を前提にしてるところもあるし、 Rust もそれに合わせる形になってるところもある。 C/C++ 的な分野をよりよくやる言語と考えると Rust はとても良い。 すまんが↓これが動く理由を教えて欲しいんだけどさあ https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w 一見すると5行目で所有権が失われて、6行目で使ってるように見えるんだけど・・・・ これって5行目が借用に推定されてるの? それともリテラルを引数にした場合だと5行目で「1」が他のスタックにコピーされて、所有権が失われる問題なんか起きないのかな? へるぷみい >>544 値とその所有権が複製されて関数fに渡される分とそのまま残る分の2つになる 値が複製されて、複製された値の所有権が関数fに渡るだな。 所有権の複製とかいうクソワードは避けてくれ。 >>544 i32 は Copy トレイトが実装されてる。 普通なら所有権の移動になる文脈で暗黙に clone されると思ったら良い。 そう言うことなのか、ありがとう! 理由が分からなかったから不気味だったぜ >>547 >値が複製されて、複製された値の所有権が関数fに渡るだな。 複製された値の所有権は最初から関数fのスコープの中で発生するものなので 「関数f」に渡るという表現には少し違和感を感じる 感じてるから違和「感」だからね 要は頭痛が痛いと同じ >>553 感じるを感じるメタ表現だろ。 ポインタのポインタみたいなもんだ。 >>542 embedded 対応アーキ少なくね? >>557 重言ではあるけど間違った日本語ではない といったほうがよかったね >>556 少ないね。 でも、そもそも今までCとアセンブラ以外はほぼ無い状態だったから、出てきただけマシ。 それに、少ないといってもシェアが広いアーキなので滑り出しは順調と言えるのかと。 少し前まで次世代言語と言われてた程度には後発。 鯖向け言語で終わると思ってたら、マジでC/アセンブラの牙城を崩し始めるとは思わんかった。 むしろ崩し始めることすら無理だと思ってた。 >>559 状況も追い風なのかもね。 二の足踏んでたけど、armと生きていく決心をしてrust覚えるか。 先にrust身に付けてから、非対応アーキでC++導入したらメリットあるかな? Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。 複数言語使えますってだけでもアピールになるしね。 Rustは多分仕事自体はまだ多くない。 これからアピールして増やしていく感じなので、両方使えてた方がいい。 rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ Rustが実用的になったのは2020年 それ以降の新規案件はRustになっている Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前 絶壁の学習曲線。 貧弱なライブラリと人材。 早すぎる最適化。 しばらくは既存コード置き換えが中心だし、今後もプロジェクト初期のプロトタイピングで使われることは無いだろう。 P系言語の糞思考に染まっていない初心者こそ 最初にRustを学ぶべき >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか >>567 移植なんて無駄な作業はどの言語間でも行われることが少なく 通常はシステム更新で全体もしくは一部が作り直される時に別の言語が使われる Rustでも同様でほとんどがそれら含む新たな案件 >>567 早すぎる最適化という意味不明なデタラメ書いているのは君一人だけ そしてRustを叩きたいためにウソを散りばめる >>567 貧弱なライブラリとかエアプかよ そしてRustを叩きたいためにウソを散りばめる 単なる感想を必死にウソ扱いして何がしたいんだコイツw ライブラリはPythonと比べると流石に貧弱 特に数値計算とか物理・機械学習系 簡単な数値計算の時点でnumpy•scipyのようなデファクトがなく、雑魚が乱立している もっと高度な計算系ではもっと雑魚が乱立しているか、そもそもない >>575 キチガイアンチ すべての分野でライブラリが充実している言語は存在しない ある分野で一番充実している言語を棍棒にしたら他のすべての言語が負けるのは当たり前 そういう無意味なことをして叩いて楽しいか? >>576 貧弱なことを指摘するのは叩きではない 俺はただ、「貧弱なライブラリとかエアプかよ」とか言っているエアプに現実を指摘しただけだ >>576 そこは「Rustなら〇〇分野のライブラリがどの他言語より充実している」と反論するところだろ。 >>570 絶壁の学習曲線だから無理だろ。 moveを意識しないshared xor mutableの無い、Rc中心のEasyRustとかが無いと、fnひとつ呼び出せないんじゃない? Crypto分野はRustが他言語よりも充実してるかもね ライブラリの多さってイコールでユーザの多さなんだよ 更にいうとその言語開発者の意欲の表れでもある ライブラリが少ないという事はユーザが少ない 更に少ないユーザの中でも意欲の有る人間は少数って証明なんだよね いやまあ数はあるんよ数は 意欲のある人はいるっぽいんだけど、デファクトとるようなライブラリってやっぱりそれなりの人数でちゃんと資金とって作られてるんだよな 資金取るのは個人の意欲だけじゃなくて、お金のある人を納得させる理屈が必要で、少し前までのRustは少なくとも数値計算の分野でそれが出来る言語ではなかったと思う てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。 そんなんで数値計算ライブラリが入るわけがない。 初心者向けのSimplified Rustと、 c/c++ライブラリバインドを強化したAdaptor Rustあたりは欲しいなぁ。 Safe Rustじゃ難しそうだし。 ゼロからプログラム書くならSafe rustが一番簡単だよ こいつに従っているだけで割と見通しが良くてバグりにくいコードが書ける まあGoto 多用しているようなFortran おじいちゃんとは相性が悪いかもしれんが C++を完全に理解した者のための言語それがRust 故に誰も C++を使ったことないけど Rustで困ったことないな Rust理解で必要なことはポインタとスタックとヒープとRAIIくらいかな 所有権は単なるヒープ解放責任だから大したことではない 所有権を他へ譲渡しないとRAIIによって自動解放されるというだけの話 非常にシンプル 所有権を複製するとか間違った事を言い続けてる人が良く言うわw 進化論肯定派じゃないの 人を淘汰することを志している カチョー「???」じゃなくて カチョー「で?」なら共感できたかも rustだいぶ分かってきたつもりだけど ライフタイムとジェネリクスとクロージャが一斉に襲いかかってくると無理 好きな言語だけど世の中にはプログラミング言語に強い興味を示す奴が稀なので厳しいなぁと感じる >>592 進捗報告相手が課長というのが昭和かもな そんな会社で働きたくない >>596 それぞれ理解していれば組み合わさって困ることはないんじゃないかな Rust特有のライフタイム注釈は構造体なら「参照を持ってるよ」の印で関数なら「この引数の参照は返り値の参照に対応するよ」の印であとは有効期間を満たすだけなど Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか?めんどいんですけど メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。 self/ mut self/&self/&mut selfの区別もいるしな self自体これ以上短くしてもよくわからん単語になるしまぁ妥当では C++ の ref-qualifier とか無理のある文法だもんな。 そこに書くんか!? という変な驚きがある。 引数の一種ということにしたほうがかなり単純でよい。 実際、 C++ でも C++23 から this を明示的な引数に取れる文法が追加された。 (deducing this) >>602 普通に全部ダサいんだよなあ 何とかならなかったのかとならなかったのかとならなかったのかと… selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか ぜひとも >>605 の考える最高にイケてる構文を教えてほしい Rustを今から変えるのは無理でも、後継言語に採用されるかもしれんし >>605 nimの関数呼び出しルール 関数名(第一引数,第二引数...) 第一引数.関数名(第二引数...) で第一引数がself相当 が一番スマートかと。 >>605 むしろ>>602 はそれらの区別のためにもselfは必須と言ってるようにみえる さらに構造体などフィールド名と関数内の変数名との区別のためにもselfは欲しい 現状のRustの仕様がベストかな >>608 nimを知らないけど、Rustのassociated functionもその二種類の呼び出し方法がとれる点は同じだね Vec::push(&mut vec, 123); (&mut vec).push(123); vec.push(123); この&mutを省略できてRust便利 thisはたまにselfの代理で使われてるな Rc::into_innerとか deref後のinto_inner適用と区別のため 敢えてself使わないことでメソッド呼び出し形式をできなくして 明示的にRc::into_inner呼び出しさせるパターンだね メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は LISP 用に作られたオブジェクトシステム new flavors でやってた。 >>615 メッセージを送る構文と関数呼出しの構文の両方があって構文糖として扱える仕組みになってたという話。 new flavors の前に flavors というのがあって、それはメッセージを送る構文しかなかったのだけど new flavors で改良 (かどうかわからんけど) された。 >>616 むしろ逆かな target.method(arg1, arg2, ...)という targetへのメソッドコールを実現するのを関数で表すと method(target, arg1, arg2, ...)とする言語が多い Rustでも同じでこのtargetをselfと書く targetは送る側から見た視点 selfは受け取った側から見た視点 各実装は受け取った側でなされるためself UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな レシーバとして扱われるなら構文上も特別であってほしい >>619 何が気持ち悪いのかさっぱりわからない まず、全ては関数呼び出しになりそれ以外の方法はない、というのはいいよね? 次に、その関数呼び出しでのレシーバの渡し方は最初の引数になる、というのも自然だよね? ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう 言うほどほとんどの言語がこれか? pythonは後付けでOOPぶっこんだからただの関数の引数にSelfなんだ これがPythonいまいちだなって思うところ c++も似た様な理由でstaticでthis 後発で考慮する余裕あるのにそれを引っ張ってる >>621 君の感性がおかしいんじゃね? NimもZigもRustもPythonと同じ標準方式 foo(receiver, arg1, arg2, ..) または receiver.foo(arg1, arg2, ..) >>622 実質Pythonフォロワーを含めて言われても… C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた それがOOP言語になって指定不要になった それがまたC言語時代に逆戻り >>624 何を言ってるのかわからん 文句を言うなら望ましい代案を出してみて あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは receiverがNullの可能性がある場合でそう設計されてただけ 代案を出せないってことはRustに言いがかりをつけてるだけだな 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ その表記は時間をかけて考えたらいい >>625 レシーバは必ず必要 Goでも func (receiver ReceiverType) Foo(引数…) { return receiver.xxx + receiver.yyy } と書く レシーバ指定不要という主張は理解できない レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな selfなら必ず揃うし予約語としてシンタックスハイライトされるのもいい UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの >>619 はそれを分かった上でNimについて書いてるのかもしれないけど>>620 や>>622 は明らかに誤解してる >>631 そう言われるとRustの仕様がベストなのかな レシーバに名前を付けないと名前空間の分離ができなくて レシーバに名前を自由に付けられると読みづらくて Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな 型指定にSelfやSelf::Itemなど使えるだけでなく Self::CONSTANT_NAMEやSelf::function_without_self()などの呼び出しもできる Selfによって自分自身であるとわかりコードが読みやすい 型名変更の影響も受けず読みやすいメンテしやすい ダメな言語だと以下のダメなパターンがある ・Selfの代わりに型名を書かなくてはいけない言語 (自分自身だとわかりにくくメンテ性も悪い) ・Selfの代わりにself(やthis)を用いてしまう言語 (値と型の区別がつかない) ・Selfを使わずに名前空間の区別がない言語 (間違いが起きやすく自分自身だとわかりくくメンテ性が悪い) 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな…… 複オジは見えてる範囲が狭過ぎる だから長文になればなるほど勘違い度や害悪度が高まる 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると 一般的なの仕様のRustに違和感を感じて文句をつけたくなる気持ちはわからんでもない Rustを叩く前に視野を広く持つべきだな Rustの仕様はよく考えられ機能的に洗練されている >>640 Rustに無いからといってUFCS叩くのはさすがにアホかと。 そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん >>642 エラー返す時に参照してるリソースをつかんだままにしたくないからじゃない くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い まともな質問にいつものノリで適当に答えて嘘だったら良くないしね そっか 俺の答えも間違ってたしな 正しくはdowncastのために必要らしい 詳しくはfix_errorのRFC見て Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環? downcastなんて別にしないからいらねーよって思ったけど そういえば内部で似たようなことやってるあれがあったな、どっちかっていうとあれのためか ヒントありがとう >>641 UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 RustはUFCSを採用しないだけでなく、更に厳しく孤児ルールによってメソッド名空間の汚染を防いでる。 Rustでのメソッド追加拡張は、そのための新たなトレイトを用意することで、その利用空間に限定して安全に行うことができる。 >>651 UFCSはそもそもメソッドとか無いんだから、ありもしないメソッド空間の汚染とか考えるだけ無駄。 それに、メソッド呼び出しは人間の思考パターン(大域から局所に絞り込む)に従った自然な記述方法なんだから、それを拡張困難なメソッドだけに限定するのは酷い制約かと。カス文法のPythonを思い浮かべますな。 >>652 Rustでメソッド呼び出しは拡張困難ではなく、拡張用トレイトを自由に新たに用意することで、他への汚染を招かずに安全に拡張できる。 そのためUFCSのような愚かな方式を採る必要がない。 答えを教えてもらっているのにヒントありがとうというオジさんw >>653 それって単にメソッドだけ特別に名前空間を管理していという話で、UFCSだから問題になるという話では無いな。 もっとUFCSならではの問題点を指摘してくれ。 せめて関数が左作用ならUFCS捨ててもいいけど、どの言語も馬鹿のひとつ覚えで右作用を採用するからメソッドとかUFCSが重宝される。 アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ アラビア語おすすめ >>656 それはメソッド呼び出しのメリット モジュール化や結合の観点からも最初からメソッド定義していくのが正しい UFCSはそれが出来ないあるいは間違ったプログラミング設計によりフリー関数を多数作ってしまった間違った環境でメソッド呼び出ししたくなった時のみ必要とされる 具体的には歴史的な負の遺産でボロボロなC++が該当する そのためC++ではUFCSを導入しようと今も悪あがきをしている ほとんどの言語にUFCSがないのはそんなものを必要としないためだ モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ RustのAdd演算子とかrhsとlhsの型が違う時は演算子がlhsのみに紐つくことになってかなりキモい それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない AddAssignやSubやShlなど多くの演算は非対称 いや別にSubでもDivでも左のみに紐づいているのはキモい >>658 やっぱりUFCSじゃなくて名前空間の設計の問題にしか見えんね。 例としてc++を挙げているが、名前空間を使っているライブラリとかで問題になっている事例てあったっけ? グローバルのフリー関数は影響範囲が広すぎて問題を引き起こすというなら、Rustのトレイルと同様に適切な名前空間を用意しないと関数を定義できないようにすればいいかと。 >>662 トレイルではなくトレイト トレイトは名前空間を用意するものというより、トレイトをuseすることでそのトレイトにより実装されるメソッドが使えるようになるだけ >>663 だったらなおさら>662だけの話かと。名前空間で「メソッド空間」を管理するのをRustは「トレイト」で管理しているだけにしか見えないね。 >>659 >モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ 同意 >>664 Rustはそうやってきちんと管理できつつ便利でいいよなー 他の言語も導入すればいいのに >>665 オブジェクト指向を全否定するキチガイか クラスのある言語もクラスのないGoやRustなどの言語も 一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ >>667 >一つの変数の型に関数を紐づけることがプログラミング言語の中核機能だ オブジェクト指向前提思考? >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう からの >UFCSはメソッド名空間の汚染であるため、まともな言語では採用されていない。 schizoかな? >>670 虚言癖などと同じパーソナリティ障害の一種だから生温かく見守ってやれ おじいちゃんは昼だけ起きてて 夕方を過ぎると寝てしまう ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ? 柔軟性のために外延性は欲しいところ。 異なる型間の共通項をトレイトとして切り出すだけでよく コードを美しく整理して保守性を高めやすい 143 デフォルトの名無しさん 2024/04/07(日) 19:27 純関数型言語でなくても モダンなプログラミング言語 Go、Rust、Zig、Nim、Julia、Elixirなどは クラスおよびその継承を言語仕様から排除しておりクラスは存在しない それら各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である クラスとその継承は悪手であるとプログラミング言語界では結論が出ている 継承がなくても構造体にメソッドついてたら実質クラスだろ 関数に構造体渡してたらそれはクラスじゃないけど >>681 構造体にメソッドが付くことはカプセル化と言う クラス=カプセル化+実装継承 なのでクラスとカプセル化は異なる このクラスを成り立たせている実装継承が悪であるためにモダンな言語群がクラスを採用しなかった 実装継承とは具体型が別の具体型を継承することを指す クラスでは派生クラスが基底クラスを継承するため悪の実装継承となる 正しい方法はインタフェイスやトレイトなどの抽象型からのみ継承する つまりクラスを完全に排除できるためモダンな言語群にクラスはない 用語も色々。 Rust で言うところのトレイトみたいなやつを Haksell とかでは型クラスって呼んでるし、 JavaScript のクラスの実体は (特定のプロトタイプに紐づいたオブジェクトを生成するための) 関数。 極論すればクラスと名付けたものがクラス。 Rust でクラスと呼んでない以上はもう別概念として捉えるしかしょうがないだろ。 C++ のクラス的なことの一部を Rust でも「可能ではある」というという主張なら賛成するけど、 クラスとは何かを定義せずにクラスかどうかを論じても無意味。 型クラスとクラスは全く異なるので混乱しない クラスとはクラス継承すなわち親クラスから子クラスへの実装継承できるものを指す JavaScriptはプロトタイプを親として実装継承するためクラス 一方でRustにクラスはない クラスとは何か?継承とは何か? こういう基本的な概念を特定言語の実装から離れて理解しようとしない限り何を言っても虚しい >>681 が一番まとも 話は非常に単純 具体的な型から具体的な型への継承が実装継承でこれがよくない classは具体的な型superclassから具体的な型subclassへの継承があるから実装継承 interfaceやtraitは具体的な型ではなく抽象的な型なので該当しない 最近の言語がclassのみ採用しなかった理由はその違い RustにはJavaのクラスはありません RustはJavaではないからです あたまいいね Javaの生みの親であるJames Goslingも、 「もう一度最初からJavaを作り直すとしたら、どこを変更したいですか?」に対して、 「クラスを除外するでしょうね」と答えている。 その理由は、クラス継承が実装継承となっているためで、この設計を後悔していて、インターフェースによる継承が望ましいと述べている。 クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな それは単に使い分けが出来ない馬鹿な子向けの説明だぞ >>691 言語仕様としてあった方が良いということ。 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ Javaの生みの親も言ってるようにクラス継承の機能はない方がいい なくても困らない あると問題を引き起こす そういうのは話半分に聞いておけばいいよ nullを使ったのは失敗だったとか 後からそれらしいことを言ってるだけ javaはクラスと継承が無くなったらまともに機能しない interfaceにデフォルト実装がなかったので全部自前かコンポジションで実装することになったはず >>696 interfaceにデフォルト実装を後から入れたので問題なくなった そうなるとclass継承は不要 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから 今JAVAが生き残ってるのは最初の設計思想が世間に受け入れられたからであって 後から○○無くせばよかったと言うのは誤りで浅はか NULLを無くせばよかったと言うが当時メジャーな手法でそれの代替手段がなかったのと同じ インターフェイスにも集合で言うところの外延性は欲しいところ。 基底クラスで保証してる内部条件を継承クラスで壊されやすい Javaは基本的に全部オーバーライド可能でprivateとfinalで変な継承を抑えてたけど C#はabstract/virtualかつsealedでない要素だけオーバーライド可能になってたと思う 古い知識だから最近の動向は知らない Unreal EngineがRist対応するんだってね 隙間作って床下チェスト収納ってできなくなった?動画みてるけどうまくできん shift-jisのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない 全部読んでデコードして\nで切り分けるしかないの? read_lineはutf-8じゃないと無理だけどread_untilならバイト列で1行ずつ取れそう >>712 encoding_rs_io::DecodeReaderBytesBuilderでsjisをdecodeするreaderを作る あとはreader.lines()で同じ std::io::BufReader::new(encoding_rs_io::DecodeReaderBytesBuilder::new().encoding(Some(encoding_rs::SHIFT_JIS)).build(std::fs::File::open(SJIS_FILE)?)).lines() BufReaderもFile::openもそのまま使える点がいいね >>715 ありがとうございます 動作確認しました ちょっと仕組みがむずかしいですね decoderが挟まるだけだよ // UTF8の場合 let file = File::open(path)?; let reader = BufReader::new(file); for line in reader.lines() { // SJISの場合 let file = File::open(path)?; let decoder = DecodeReaderBytesBuilder::new() .encoding(Some(SHIFT_JIS)) .build(file); let reader = BufReader::new(decoder); for line in reader.lines() { バッファリングせず丸ごと贅沢にメモリ使っていいなら単純 let bytes = fs::read(path)?; let (s, _, _) = SHIFT_JIS.decode(&bytes); let reader = BufReader::new(s.as_bytes()); for line in reader.lines() { コマンドラインからファイル名取るようにしたらパニック windowsで文字コードが違うかららしいけどこういうバッドノウハウを開発者に積み重ねていかないと使えないのはめんどい 知らないとそういう反応するんだろうけど std::env::args_osを使ってOsStringを取って対処する必要があるんだよ 勉強になっただろ? 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える アメリカ人だったらこういうのに出会わないでコーディングしてリリースしてるだろう 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されている >>722 チュートリアルレベルの基礎を バッドノウハウwとか 積み重ねでいかないといけないwとか 言ってるから何言ってんのwになる >>720 Rustのパニックはどの関数で何をした時に発生するかすべてドキュメントに明記されてるのでパニックはプログラミングした側に問題がある さらにパニックがソースコードの何行目のどの場所で起きたのかもわかるのですぐにそのバクを調査できる まずは基礎知識を身につけよう >>722 std::env::argsのドキュメントにどういう時にパニックが起きるか書いてある さらに対処方法はargs_osを使えと明記されている ドキュメントを見よう >>724-725 こういう低能がありがたがるんだろうな 信者としか言いようがないw リリースした後の実行時のpanicを有り難がる信者 Rustのライブラリの思想がいまいち馴染みにくいと言うか素人が作るとこうなりますと言う見本 >>722 Rustではそんな個別の知識を知らなくてもpanicさせた関数が分かるから その関数のドキュメントのpanicの項目を見れば明記されてる 他の言語と比べても良い環境 馬鹿と話しててもらちが開かない 世界中で使ったらパスの問題で落ちるプログラムがガンガン量産されているのは事実 お前らそれを一個一個プルリク送ったりしてるのか? 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ 世界中で英語じゃないwindows環境でpanicが起こるコードが蔓延してる 非合理的 そんなことより The Embedded Rust 読み始めたんです。 冒頭からリンカで割り込みベクタマップの取り方やら panic 無効にしての main 関数導入やら、HAL は自分でこさえるんだよね?と言わんばかりの内容。 おおむかしのMCU開発環境みたいで嫌いじゃないけど、arch 対応してないと敷居高いねこれ。 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる プラスドライバーを使うべき状況でマイナスドライバーを使って使いにくいじゃねーかこんな道具は非合理的などと言い出す ヤバすぎね? >>725 なんでコンパイル時にエラーにできないんだろう? Rustのポリシーからすれば安全優先でargs_osだけにしてargsは削除すべきでは? c++じゃあるまいに、コマンドラインのデータが常に正しいunicodeだと信用するプログラムを書けるとか、セキュリティーホールになりかねんと思うけど。 >>734 緊急停止して「安全ですよ」はちょっと…… >>733 セキュリティホールにならない 異常データに対して止まり動作を続けない >>733 >なんでコンパイル時にエラーにできないんだろう? 出来るわけないだろw 実行時に与えられる外部入力をコンパイル時にどうやって判定するんだよw バカすぎる しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス もう治る見込みはないからargs_os()を使おうねってだけだけど 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど 特に提案もなさそうだし誰も困ってないんじゃないかな そもそもほとんどのケースでclapとか使うだろうし >>733 >>>725 >なんでコンパイル時にエラーにできないんだろう? むしろ何でできると思ってるんだろう。謎 環境変数もvarとvar_osがあるから慣れろとしか言えない OS標準が全部utf-8になる未来もありえるし >>741 紛らわしいけどvar/var_osとvars/vars_osは別物だよ varはinvalid UTF-8でもエラーハンドリング可 varsはpanic argsは引数にUTF-8以外はダメだよって前提で使える余地がまだあるけど varsはそんな前提をおける状況はほぼなくてよりたちが悪い >>741 >OS標準が全部utf-8になる未来もありえるし 10年前のその未来予想が大外れしてるから今となっては設計ミスとしか言いようがない もう10年経ったとしても状況は変わらないと思う >>732 公式チュートリアルまともに読めるならC++で良いからな よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? どう考えてもstd::env::argsを非推奨にしろとは思うけどね 欧米人がつくるとこんなことになるんだ 普通は2種類の扱いがある ・実行環境に合わせて自動的に内部での標準形式に変換 か ・何もしない 何もしないならOSから受け取ったままOSに渡して置けば大体問題はない 第三の愚策がRust 受け取ったままそのままOSに渡してもコケる Rustは何もしないように見えるけど何かしてるからコケるのでは? >>745 間違いだらけだな 世界の標準はUTF8 ウェブももちろんUTF8 RustもUTF8 Rustがこの件でコケることはない きちんと各関数の仕様が明記されていて常に正確に動作している >>747 一般的なパニックは色んな意味合いがあるけど Rustでのパニックは関数ドキュメントに明記されている想定のことが起きた ライブラリ関数の作成者はパニックを発生させる時の条件をドキュメントに明記しなければならない だからそれを利用する各プログラマーにとっても想定内のことのみパニックが起きる >>745 勘違いしてることが多すぎてもう笑うしかないwww >>745 >よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは? 30年以上前にUCS-2がWindowsやJavaに採用された時代のことを言ってるのかな? (UTF-16と違ってUCS-2は固定幅なので今でもまだ使い所はあるけど) ↓これが15年くらい前のUTF-16に対する一般的な認識 https://softwareengineering.stackexchange.com/questions/102205/ utf-16はUnicode 2.0(1996年7月)のサロゲートペア導入でutf-8に逆転されたな しばらくはBMPしか使われなかったから耐えてたけど 1990代前半に始動したJavaは運が悪かった >>749 そう書きながら何もまともなレスすらできないレス乞食 Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど Rustが正しいRustが正しいと繰り返すばかり >>737 >>740 windows環境とかunicode以外が混ざる環境でargをコンパイルエラーにできないのかね。 そもそもargは廃止していい。 >>746 なるほど。 「RustはWindowsをケアする気が無い」 ということですか。 >>754 Windowsでも設定すればUTF-8になるしLinuxだってUTF-8以外に自由に変えられるわけだから、そんな判定は不可能 まぁ廃止していいには同意するけども Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。 今の Linux はおおよそ UTF-8 で統一されているけど規約で縛っているだけで、 OS としてはバイナリ単位で素通し。 保証としてはあてにならん。 コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。 >>754 無知にもほどがある! unicodeとUTF-8が区別できない Windowsに限らずLinuxでもmacOSでも非UTF-8の引数や環境変数が使われる可能性があるのは同じなんだがそんな常識を知らない >>760 そんなんだったらなおさらのこと、Rustの安全指向に従ってargs_osだけにすべきで、argsは廃止にすべきだろ。 Rustはメモリ安全しか興味無いんかね。 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。 どうでもいい話でもめてるな Rustはすべて提供してドキュメントにそるぞれ明記しているのだから使う側の各自の問題 こちらはUTF8環境でしか使われないのでargs()のみ利用している https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905 関係する議論はこのあたりかな もともとはargs/varsをパニックさせずに無視するか置換してほしいって要望だったが 無視や置換はセキュリティ上問題になる可能性があるので却下 varsは将来的にdeprecatedにするかもと言っている なんでargsもdeprecatedにすべきだろって提案すれば通る可能性はあるかもね 正しく使え論は暴論だな それが許されるならスマートポインタやGCは出ずみんな今でも生ポインタを使ってる >>765 生ポインタは安全ではないから全く違う argsは常に安全 常に自動変換したほうが安全だけどな 開発者が特別コードを書く必要もない Rustはファイル名も自動変換なんかしていないように 変換するかどうかは各自の自由裁量であるところが非常に良い点だよ 自分の好みと合わないからといって批判している人たちは頭がおかしいので相手にしても無駄なのだろうけど >>768 ここまで読んで何の話をしているのか理解できないならRust使うのは辞めたほうがいい ファイルの引数だけ標準では何もしない 普通のキーボード入力などでは変換している >>768 自動変換は正直意味不明だが(変換元の文字コードが判定不能なのに何を変換するのか?) argsは今RFC出したらResultにしろって突っ込まれると思うし 1.0であまり深く考えずに入れちゃった気はするよ Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う argsじゃなくてargs_utf8onlyとか名前をダサくして 逆にargs_osを元のargsに戻しとけば リファレンスをよく読まない人たちがつまづく可能性を下げられる こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。 Rustは雇われコーダー用Safe Rustのニーズがほとんどで、Unsafe Rustとかのニーズは無いと思うがね。 >>772 自動変換が本当に意味不明ならここまでの話が見えてないとしか言いようがない 自動変換とかそんなアホなこと言ってるのはあんただけやで そんなものは無いし必要ない こいつOsStringの概念が分かってないのか 本当に知能レベルが低すぎる OsStringはOSから渡されたバイト列をそのまま格納するだけで EUC-JP環境ならEUC-JPバイト列がそのまま入るし何も変換されたりしないが… 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる 結局内部で使う場合は簡単にutf8に変換してる なにからutf8に変化するか指示も必要がない ただのボイラープレート >>777 自動変換なんてものはない むしろ自動変換を避けるために用意されているのがOsString もちろん自動変換は行われない 人間じゃなくて壊れたロボットに話しているようだな いくつになろうとこんなダメな人間になってはいけないな ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって どんなエンコーディングの文字列でも統一的に扱うことができましゅ Rustもまだまだでしゅね ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる もちろんWebでもローカルファイルでも古いものは様々な文字コードが使われているため必要なら各々で対処する必要がある 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。 めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう? 複オジは昔の自分を諭してる気分じゃないか? >>0774 お前の着眼点は凄えよ!感動した。 その通り、Rustは初心者/素人 御用達言語だよ。 おじいちゃん誰にも相手にされず寂しくなったんだねw crates.io が死んだときはどうすれば良い? python みたいに何でも格納できる辞書型ってC++には無いよね? anyとmap組み合わせればいいんじゃね? ここRustスレだけど Rustで辞書型はHashMap 複数の型を格納したかったらenumかdyn Trait TraitをAnyにするならdowncastして使う 実際には共通に処理したい目的があるはずなのでそのTraitを用意すればdowncastしなくて済む pythonみたいにだからclassがわりなのかも p["name"]="yamada taro"; p["age"]=25; みたいなのかな いずれにしてもC++じゃないので 静的型付けの有用性が大きく上回るから そのケースならstructにするだろうし 色んな型を横断的に扱いたいケースならtraitかな GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ? UIはもうネイティブにこだわらなくてもいいんじゃないかな 昔からwebでしかUI提供してないソフトはゴロゴロある 用途次第 WebベースのUIでは反応速度が遅すぎる場合もあるしサイズが許容できない場合もある Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽…… みたいな言説もあるが、 WebView の種類・バージョンを固定できないから変化に追従する必要が生じる。 そもそもウェブの世界は変遷が激しい。 Living Standard ってなんやねん。 普通の産業の感覚では信じられんようなことをしやがる。 元からウェブ系のスキルセットを持っている人が開発してメンテナンスもするってのなら Tauri は良い選択肢だと思うが、それなりにデメリットもあるよ。 ただ、多言語 (というか Unicode) に隅々まで対応しているようなフレームワークってことになると ウェブ系の基盤がめちゃくちゃ整備されているのでそこらへんは唯一無二だわ。 即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって そうでない場合は普通にhtmlで 実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい 常駐の軽いアプリを作りたい場合なんかは特に UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。 元はドキュメント記述用だったのに html5 から大幅に路線変更してアプリケーション基盤として再編したけどどう見たって無茶苦茶だ。 ウェブの人が使う分にはこれでいいことは否定しないけど、 UI 記述の「普通」ではない。 UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ MFCやCocoaやGTK的なものが今では逆に「普通」ではない >>813 宣言的がどうこうとかいう問題ではなく html が「普通」ではないと述べてる。 これが良いとか悪いとか言ってるわけではないよ。 まず第一に選ぶべき「普通」だとする論を否定してる。 何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな… tauriは環境構築する段階でnodeのバージョンやら依存ライブラリの不備でエラーがでてしまい結構時間が掛かってしまった デスクトップアプリのここにグラフ出してくださいって言われて 対応できる環境は少ない 他にいい表現方法があるなら自分で作って使ってりゃいいじゃん >>821 Elm Architectureの設計パターンを覚える必要があるけどなかなかいいですね 試してみたけど導入のカウンタの例がいきなりビルド出来ない… バージョンの変更にドキュメントが追いついていないのは残念ですね… read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる