Rust part23
前スレ終盤がRust特有の型🔵ナニー症候群の典型(この用語は出典参照) https://mevius.5ch.net/test/read.cgi/tech/1705760500/977- https://www.youtube.com/watch?v=6gwF8mG3UUY >>4 Rustから前スレ終盤の型オナニーをなくしたような言語があれば使いたいけど、ないから仕方なくRustを使っている 静的型チェックレベルを高めつつジェネリクス等による汎化を活用しようとすれば大なり小なり型オナニーは避けられない 型オナニーより所有権やライフタイム管理の方が面倒だけどな 動的型付け言語しか慣れてない初心者が静的型付け言語に慣れるまで時間がかかるのは当たり前 Rustの型オナニーは「本当は1つにまとめても良いんだけど歴史的経緯で2種類あります」みたいなのが稀にあって気持ち良くない >>8 それRust特有だよね 時間がどんどん溶ける asはそろそろFrom/TryFromに統一してほしいんだけど 型オナニーって全部習得するまでにいったいどれだけ時間かかるんだ >>13 >>16 え、てかそもそも演算オーバーフローはpanicするのにキャストはpanicしないのか 生演算子はオーバーフローせずラッピングされる 型オナニーって複雑な型パズルを解いて悦に入ることを言ってるのかと思いきや そんなマインドでもGo言語なら習得出来るんだよなあ バカはGoへ行くしかないよ Rustの開発って時間掛かりそうなイメージある termuxよりscreen派なんだよなぁ。ライセンスはgplよりbsdのが好きなんだけど。 >>21 >>23 >>25 >>9 >>6 >>28 >>23 >>32 >>27 >>32 どんな言語にもマイナス面がありRustにもある >>36 >>35 漸進的型付けは静的片付けと動的型付けのどちらも出来るわけではなくて漸進的型付けという別物だと解釈すべきだと思うよ。 >>39 >>41 >>35 はそんなこと書いてないぞ ここはRustユーザが集うRustスレ C++の後継目指すプログラミング言語「Carbon Language」、Googleの技術者が実験的公開。C++は技術的負債で改良が困難と https://www.publickey1.jp/blog/22/ccarbon_languagegooglec.html >>37 https://i.imgur.com/Z8hI9C6.png Jobで判断するのはちょっとなあ >>48 >>46 >>49 https://japan.zdnet.com/article/35183866/ https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html Rustは知らず知らずのうちに技術的負債を量産しそうな気配だな https://mevius.5ch.net/test/read.cgi/tech/1705760500/9 https://mevius.5ch.net/test/read.cgi/tech/1692105879/990 >>4 https://github.com/rust-lang/rust/issues/114936 >>52 誰も問題視していないどうでもいいことでしかRustを叩けない状況 >>53 は>>51 向けな >>52 のは違うIssue/PRのcommitで場当たり的fixしただけで知れっと本質を隠蔽した >>54 >>37 ,47 >>53 >>51 にソースがあるようにRustで書かれている >>57 後半 >>57 >>57 >>59 >>55 >>62 >>55 の根本原因究明がならなかったから、今後も散発的に発見しては穴ふさぎをするのでは 例出せないならお前が偉そうに言うことではないぞ 俺の質問に答えずに訳のわからないことを言うしかできないんですね >>52 >>66 >>65 ,67はあのコテハン >>68 いや煽ってきたのはお前だろw 自分が攻撃するのは良くて攻撃されるのは嫌か？ 自分以外が全部同一人物だと思い込んでるアタオカの着火点は意味不明だよな >>69 >>71 誰も攻撃してないのにこの人怖い、やめてくれませんか 例の#25860、ジェネリクスとかマクロ生成の裏で意図しないでこのパターン踏んだりしない？ rustでリファクタリングしながらの開発ってなると多分unsafeを途中経過で入れたりとか >>76 >>32 >>39 >>77 Rustコンパイラチームは意図せず発生する可能性を否定していない様子 https://hackmd.io/@rust-compiler-team/SkkrA1DCK#Variance https://github.com/rust-lang/rust/issues/25860 >>77 >>82 >>84 >>85 >>81 可能性を論じるならお前の頭に隕石が落ちてくる可能性だってあるが、そんなことを心配したことある？ RustはVec等のCVE前科があるからなぁ 開発プログラムでunsafeを直接使うことはほとんどない 隕石であれ何であれそれがエンジニアリング可能な対象なら問題を特定して語る意味はあるだろう >>89 >>90 ,92 >>92 の最後の行があるから信用されない Rustの2023年のCVEはCargoで名前をエスケープし忘れた1件のみ Rust以外のコンパイラってそんな言うほどバグないか？ 普通にあるけどみんなで使うから大部分はリリース前に潰される >>91 今となっては未定義動作の多い言語を使うのは悪行だ >>82 >>97 >>99 事実を書かれただけで批判だと思っちゃうようじゃ生きづらかろうな >>101 アンチもMozillaが変なことやってるだけで >>103 >>105 Rustコンパイラにバグがあるのはかなりキモくて嫌だけど、Rustの利用をやめるほど致命的かというとな C++ の未定義を踏んでもおかまいなしってよりは原則として問題は検出する (けどちょっとはバグもある) Rust のほうがだいぶんマシな言語設計ではある。 unsafeなライブラリがRust用の安全なインターフェースを公開することにより保証される安全性とは プログラム全体がunsafeなC/C++は使いたくない >>109 反論できないときは関連するワードを含むRustの宣伝文句をぶつける 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 難易度は高くとも増加するユーザー、Rustチーム2023年調査「State of Rust Survey」 https://news.mynavi.jp/techplus/article/20240222-2889545/ >>105 ,109 >>112 >>前スレ992 Derefの名前の由来は*演算子（dereference：参照解決）だろうけど 意味的にはFollowRefの方が自然かな 【AI】Stable Diffusion 3発表、Soraで話題の拡散トランスフォーマーを採用 [すらいむ★] http://egg.5ch.net/test/read.cgi/scienceplus/1708865670/l50 >>115 >>116 ,117 Rustて、演算子と関数を(意味論的に)区別していたっけ？ Deref に関しては * 演算子として機能する以外に型強制の規則があるという話の文脈。 +に対するAdd, &=に対するBitAndAssignと同じ位置づけで >>121 >>116 >>119 関数と同じでは困るものといえば && || が有名だけど = が一番やばい >>125 Rustにおける = は心の中でバインド演算子って呼んでるわ >>124 https://doc.rust-lang.org/std/ops/index.html Derefによるcoerceは&**となるのが全然わからないって本気なのかな？ >>129 上の一連の流れ見てるだけでRustしんどそうに見える >>129 https://doc.rust-lang.org/book/ch15-02-deref.html#implicit-deref-coercions-with-functions-and-methods こんな議論が発生する時点でかなりややこしくて面倒な言語がであることは認めざるを得ない そんなことよりDerefの定義の中で参照外ししている↓が無限ループにならない理由でも調べてみたほうが面白いよ https://doc.rust-lang.org/src/alloc/boxed.rs.html#1927 >>135 rustは使い勝手のために暗黙にokにした構文が逆にわかりづらさを生んでる。 >>137 >>136 >>139 Rustってなんでzipを「簡単」に操作するクレートが一つもないんだ？ >>133 >>141 >>133 Rustもちょっと前の熱狂はなくなってしまった感じ まあ熱狂系の人は実用言語嫌いそうだし、熱狂系がいなくなったのは良いことでは >>144 https://eow.alc.co.jp/search?q=coercion Tのスマートポインタの参照 -> Tの参照 >>150 Rust の参照は借用規則に関わることを除けばポインタとそんなに差はないし普通にオブジェクトの一種なんだよな。 その橋渡し役がDeref coercion >>142 >>142 とにかく、間接参照から直接参照を得る演算の名前はderefでいいんだよね Derefは* >>157 https://doc.rust-lang.org/std/ops/trait.Deref.html ） こうだろ なんかゲシュタルト崩壊してきたんだがｗ C/C++書いてる者からすると勝手に変換してくれて楽ちんだなあって感じ Deref coercion &**のうち let s = String::from("xyz"); >>163 >>156 >>157 >>164 >>164 >>165 *xが左辺値なら代入、*xが右辺値なら複製とかいう演算に >>170 判りにくい仕組みだけどこれから開発が進むと これほど分かりやすくて便利な明確な仕組みはない 他の言語でこれより良いものが存在しないね >>172 Derefなのに&が消えてない（小並感） この仕組みがベストであるという主張は3種類ある この仕組みがない方が良いということ？ RustのDerefとそのcoercion枠組みの利点 >>179 >>178 Rustの方式の利点は>>180 に挙げられているから 検証可能とはコンパイラが無謬であることではない 単に理解できないから難癖つけてるだけだよねこの人 誰かの難癖を自分が思い付いたかのように言ってるだけで 全く相手にすべき人間ではないと判断する >>184 技術的選択は突き詰めれば必ずトレードオフが生じるもの Rustの方式の利点は>>180 に挙げられているから >>191 物的な代案や物的証拠により人の心を折ることが検証だと思っているんじゃないか わざわざRustスレにまでやって来てRust叩きやってる人だから心の病気なのかもな >>167 ビルトインは*を明示指定しないといけなくない？ impl Deref for &T >>199 derefの仕方は状況によって使い分けかな uv、めちゃ速いな uvというとCで書かれた非同期マルチプラットフォームライブラリ(Rustにはmioがある！)が有名だが JavaScriptでも遅いBabelを速いSWC(Rust製)に換えると爆速 Pythonの管理ツールまたなんか出たの！？という気分 uvはPython版のcargoを目指しているらしい nvidiaのど汚なさを理解してなさげで不安しかないわ RustでDB使う時の定番ライブラリって何ですか？ ORMが好きならdiesel 最近RDB以外のDBの存在を知った人にありがちな反応だよな Rustで一通り文法や機能紹介した入門書の次に読むような定石本ってどのようなのがありますか？C++でいうEffective C++みたいな >>216 >>219 こうね 解決案としてはそうなのだが、デフォルト挙動が罠すぎる Rustは利用者はアホだと思ってる 雨が降ってなくても傘を持つように言って来て外出すらさせてくれない デフォルトのハッシュ関数が遅くて困るってことはよく知らずに使ってたってことでしょ？ Rustはimpl std::hash::Hasherで必要なら自由に独自のハッシュ計算器をすぐ作れるし 「最悪の場合でもほどほど」なやつをデフォルトにするのは妥当だと俺も思う。 いやそもそもデフォルトいらんくね？ 掃除機はAI搭載して吸ってはいけないものを吸ったら止まってくれよ デフォルトを用意するかしないかは言語思想によるから正解不正解では語れないよな 適切なハッシュ関数を選択するのってそんな簡単なことじゃないからな HashMapで使われるHashに重いものを使う必要がある局面は限られてる 僕が美少女とセックスするためのプログラムはRustで作れますか >>233 とりあえずデフォルトを使って、必要になったら差し替えればいいんじゃないの？ >>236 ハッシュ衝突強度安全性が必要かどうかの判断ができない者がRustデフォルトの安全なものを用いることになるのは正しい https://github.com/rust-lang/rustc-hash 安全で高速を名乗ってるくせにライブラリがおっせえ言語だなあ 言語とは関係ない ライブラリやその管理が言語と関係がないとする主張は可能だが、その主張をするとcargoやcratesの存在が言語と関係ないことになり、Rustの良さを支えている理由の大きな割合を失うことになる >>241 >>242 >>243 >>244 スクリプト言語だと速度は求められないという了解があるし Rust や C++ の思想でいう速さはゼロコスト抽象のことだよ。 あらゆる言語のあらゆるプログラムについて以下が成り立つ 外に出るときはヘルメットを被って110をすでに入力したスマホを持ちながらおむつをしてコンドームつけてるのがRust デフォルトとFxHasherで比較してみたけどHashMapへのinsertのみで実行時間1.7倍 >>248 hash自体は基本的にアホでも作れる Rustはデフォルトハッシュ関数が用意されていておかしいと言うけど >>255 普通に考えて攻撃に強いハッシュ関数がデフォルトとなってるのがベストだよね >>258 江戸時代士農工商の身分制度があって みんなの言語思想発表会をするのはいいけどRustをそれに巻き込むなよ IDコロコロ全肯定君 SafeSlowHashMapみたいな名前にすれば良いのに >>264 >>265 >>266 >>266 こいつは結論が先にあってRustのすべてが正しいから後で理屈をつけているだけ ripgrepとかuvとかの既に実用が始まってるRust製アプリでは >>267 ほらこんな壊れたレスしかできないんだよ いつもRustを叩いてRustスレを荒らしてるアンチの言動はいつもワンパターン 「俺が高速なプログラムを作れるのは言語のおかげ」は合ってるが 『「俺が低速なプログラムしか作れないのは言語のせい」は間違っている』という立場、ユーザーが充分賢いことを仮定しているのでそれならPythonとC++で良い ほんとどうでもいいな プログラムしかしない人はこういうことしか考えることがないんよ 知識があれば高速化が可能な場合があるのは、言語や項目に関わらず一般的な話。 デフォルトいらんが >>279 弱いハッシュでも困るようなプログラム書く人は、自分で判断できるんじゃないの？デフォルトはパフォーマンス優先で良いと思うけどな。 攻撃で困るかどうか攻撃されるまで初心者は判断できないと思う。 RustのDefaultHasherは安全かつパフォーマンスのいいSipHashを使っているので普通は気にする必要ない Pythonはハッシュ値計算したらオブジェクトに保存してるでしょ 他の言語たちがRustを参考に同じように後追いしているのね >>286 >>274 他の言語もRustと同じハッシュ関数を用いていることが判明したのにRust叩きを続ける一匹 他の言語の例としてPythonやRubyのような遅いこと前提でとにかく初心者が書いても動けば良いという思想の言語を持ち出してくるのはおかしいでしょう >>283 必要なことしかやりませんって言語は他にあるからそちら使えばいいのでは？ 安全と速度は両立するかそれともトレードオフか Rustなんかに手を出すのはC++まともに書けない馬鹿なんだから、「充分賢ければ速く書ける」は実質「速く書けない」なんだよな 自由があればデフォルト設定を強制されないのは自明な事実 アホ vs バカの不毛な争いが続くのは隔離スレにﾜｯﾁｮｲつけたやつの責任だからな 本スレにワッチョイつけず隔離スレと称して余計なスレ立ててそっちにワッチョイつけるバカども。 不毛の判断が早いなあ 安全と速度を両立させたのが >>295 >>300 ワッチョイなんか盛り上がる訳ねえ 高齢化でコーディングできなくなったおじいさんを叩くのは良くないと言う話 30後半でコーディングしてるやつなんて9割コミュ障で出世できなかったやつだろ 能力が低下してコーディングできないのとしないのでは大違い 結局スクリプト言語で書かれた原作が必要か Rustで書き直してパフォーマンスが上がったので注目浴びる！みたいなプロダクトはなんか白けるよな。 日本みたいに、何とかするには人投入しよう！スキルどうでもいいからとにかく人集めて！なところじゃね～。 おそらく植山類が新しいリンカを作ったあたりが開発ツール高速化の機運の始まりだと思う。 コードを書けない だが読むより書くほうが優れているという前提から >>315 Rustコードを書けない似非技術者系おじいちゃんたちは他のスレでやりとりしなさい コーディングが出来なくなると人生はつらいと思うけどな… できなくなるんじゃなくて >>314 みたいな人は 人はいつか何もできなくなって死んでいくんだよな 肉屋がレッドオーシャンになれば豚はブルーだからこれでいい Rustで書けば速くてリソースコスト下げられるうえに保守性も良くていいことずくめだからだな 無効なアドレスを参照しない >>330 >>331 >>332 WebAssemblyバイナリの実行環境を提供する「Rust」で作成されたランタイム「Wasmi」に脆弱性が明らかになった。 デフォルトで制限よりも多くのパラメーターを指定すると域外に書き込みを行うおそれがある「CVE-2024-28123」が明らかとなった。 >>336 関係無いわけないでしょｗ ガベージコレクションのあるスクリプト言語であるPythonですら脆弱性でCVE出まくってるよ unsafe使用箇所だからメモリ安全の外だろうな コード見てみたが言語関係なくダメな書き方の見本ってだけだな 修正コードはhotfixでしょ ダメな書き方でもコンパイルが通れば安全なはずなのではｗ んなこたない 直接の原因はunsafeなメソッドをsafeメソッドにしたこと >>350 unsafeを適切に使えないプログラマが書くと全然安全じゃないという事？ 全然そういう事 >>353 俺はむやみに「全然」とか「ヤバい」を使ってるけどトラブルになったことはないな >>354 少なくとも>>350 のindex: usizeは NonZeroとかNonNullみたいな固定条件ならいいけど >>358 unsafeをsafeでないのにsafeにしておいて 結局プログラマが色々意識してコーディングしないと安全にはならないのね unsafeに手を出さなければ最悪でも暴走する前にpanicで停止する安全性は確保できる >>361 いつもの人がきたｗ > Rustであれば安全と思ってる人が多そう 原則はunsafeを使うな！ まあ実際rustはコンパイル通ればいいの思想を強める傾向にはある。 ロジックや言語仕様を考えずにコンパイルが通るまでひたすらいじくり回すタイプの人間は本当にいる。 >>358 >>359 のやり方はそれができてないように感じる 実行時に範囲が変動するといっても制御下にあるのだからindexがその範囲にある時のみ有効な型を実装すればよい 今回の件でRustの安全性が確実になったのが興味深いよな >>350 でunsafe利用だった >>371 >>374 誰にでもunsafeが使えてしまうのが問題なのでは？ Rust の制限は機械的に検証可能な範囲に絞ったらそうなったということであって、その制限の範囲内で十分にプログラムが書けるというものでもない。 >>375 >>350 の引数のindexをその型に変えたところでsafeにしたらダメだよ なるほど、欲しい機能を実装していったら、結構安全になったって感じなのかな。OpenBSDみたいな偏執なのとは違う感じか？ indexの境界チェックが律速になるようなコード書いてみてえな >>376 型宣言の時に type My_Int is range -1 .. 5; 範囲宣言(マイナスでも、１からでもＯＫ)できて、範囲を越えたらエラー 配列もその範囲指定で自由に作成できる。 >>383 >>384 >>384 何十年も前なのですまそ 今回の話は実行時境界チェックを無くす(減らす)実行時コスト削減の話だけど How much does Rust's bounds checking actually cost? https://blog.readyset.io/bounds-checks/ こんなもんjavaの速度低下が境界値チェックによるものじゃないってことで話は終わっとると思ったけどな。 unsafeは可能な限り避けるべきで unsafeは極力避けろというアドバイスばっかりでunsafeを適切に閉じ込める基本的な考え方や実装パターンの啓蒙が不十分なんだよね 「unsafeの閉じ込めにはセンスがいるから、教えてもらわないと出来ないやつはunsafeを使うな」 unsafeはライブラリ作者とかがハード周りアクセスするために使うもので、コーダーが使うものじゃないだろ。 >>393 >>392 >>350 のような基本的なミスを犯すやつが後を絶たない windows-rs とか使うと絶望するよな。もうちょいラップして安全なAPIも提供してほしい。 >>395 >>397 その素晴らしい提案がなぜされていないのか考えよう >>394 unsafe はコンパイラが安全性を「論理的に検証できない」部分であって、理論上の都合で出来た区分だよ。 >>401 >>402 >>403 理想をいえばunsafeなんて無いならサイコーだったんだろうね 生ポインタすなわちCPUによるメモリアクセスはunsafe >>406 そこまでsafeな事にこだわるなら、Haskellに行けばいいのでは…？ >>404 #![forbid(unsafe_code)] unsafeな部分の拡張子を変えるというのが有効とはあんま思えんのだよな >>409 >>411 rustもいろいろ問題を抱えてるんだね >>412 >>413 >>414 >>415 結局いつもの「無知なアンチ vs 無知な信者」の薄っぺらい対立になっちゃうのな まあハスケルなんかもinvalidな変数使うようにっての広めるのには役立ったからrustもそういう位置に落ち着くだろ。 unsafeを使う人はライブラリ作成者がほとんどで、残りはシビアなインフラ作成者 >>419 unsafeって書かないといけないってのは結構デフォ禁止よりの処置だと思うが 必要な各企業、各プロジェクトなどで義務付け https://rust-lang.github.io/api-guidelines/ >>422 forbidもunsafe_codeもrustcのlintの一部だな Rust Foundationによる資格認定試験に合格した者だけにunsafe使用パスワードが発行されるようにするしかないな。 どの開発でも >>420 時間がない時に焦ってunsafe使って書いたコードは長期利用すると大変なことになるので書いてから1時間以内に使って捨てよう >>429 >>430 >>432 雑にunsafe使って早く書けるのはFFIくらいかな >>427 >>426 初心者ぼく「禁止しないといけないようなもんが標準で使えるって結局それ危険な言語なんでは？ そもそも普通に書いててunsafe使いたいなって場面がない >>436 rustもプログラマがザコだと使いこなせない言語なんだろ？ たしかにプログラムの品質がいいから出世するって見たことないわ unsafeは面倒 初心者や一般的な人は、unsafeの使い所がないなら、unsafeを使うようなすごい人でもミスをしたり理解不足だったりするって事だから、すごい人が精進すれば解決でしょ。 >>440 >>442 >>448 >>448 unsafeでサクッと終わらせてどんどん仕事取ろうぜ アンチはunsafeを使うと早く書けると誤解しているのが面白い 「借用エラー出たらとりあえずunsafeと書いとけば回避できる」くらいのイメージなんかね このスレの優秀な人たちを安月給で揃えたチーム作れたらunsafeについて真面目に取り組んでもいいんだが 正常なコミュニケーション力を持った優秀なエンジニア ｶﾁｮｰ「では進捗を報告してください」 >>457 >>459 >>458 unsafe使う機会ってほぼないよな 優秀なエンジニアは担当している仕事がいつ頃終わるか明確に答えられる人 システムプログラミング用途も売りにしてなかった？ unsafe使うと変更する時にだるくなるからできるだけ使わない 使う必要があるからunsafeってもんがあるんであって コーダーの「使う使わない」の問題じゃなくて、管理者の「許可する禁止する」の問題なんだよ。 >>451 >>468 エンジニアが判断すべき問題を管理者が決定してるようなレベルの開発現場まで Rustはコーダーは集まらんだろ 意図的にどこかで誰かが資金を投入してRustコーダーを栽培（）しないと エンジニアの趣味なら高尚な言語追求してもいいと思うけど、ビジネスで使う言語はあくまでビジネスメリットが大きなもの選ばないと立ちいかなくなるよな まあJavaとかC++のバケモノみたいな分量のコーディング規約の存在を考えると、「Unsafe使うな」の一言で済むRustは原理的にはビジネス的なメリットありそう それよりもホントにシステムプログラミングできてんのかが興味あるわ https://en.wikipedia.org/wiki/Systems_programming 今更OSを書いたところでビジネスに出来るのは一握りの人間だからCの頃とは話がちょっと違いそうではある >>477 既にネットインフラは次々とRust製 >>51 >>472 それで守られるのはITコン猿の立ち位置じゃね？ 知ってる人間は黙ってRustの恩恵を受けておけば良くて C++が流行った経緯知ってる奴なら想像できるだろ。 C++はわかりやすく拡張されたCだからさ 当時NeXTに触れてたやつおるん？ 研究室にあったんよ 羨ましい C の宣言の文法が無茶苦茶なのを C++ で改良するかどうか迷った話は D&E に書いてある。 ABI stableにするのはエディション単位でいいんだからさっさとやればいいのにとは思う >>490 ABI部分のコーディングする人はプログラマーの1%もいないんだから影響は昔も今後もない ABIこそ良い奴が出たら置き換えられそうだけどな >>493 そりゃABIがらみのプログラミングよりはProtocol Buffersなど使う方が多いんだろうけど そんなん言ったらrustを必要とするプログラマこそ1%もおらんけどな。 「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨 https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html >>500 メモリの具体的な番地やレイアウトに依存する低レイヤの事情が消えてなくなるわけじゃないからな。 java, python みたいな言語ならメモリ安全だよ。お前らの用途ならそれで十分だろ。 >>501 >>503 ぬるぽ例外で止まるのはNone.unwrap()のpanicで止まるのと同じで安全に分類される >>508 メモリ安全の文脈だからそういう次元の話ではないのだが >>505 ちょっと何が禁止なのか分からないのでローカル変数の参照をreturnしておきますね どの言語にも共通するけど，書けるようになってくると楽しいよ でもってライブラリが足りて無いなって思って「使えね」ってなるんだよね >>512 >>500 >>517 rustを無理に使ってまですることがぬるぽ対策とかアホだよね >>519 >>518 Rust愛用者だけど今のホワイトハウスに推されると逆に不安になるんだがｗ >>518 ワロタ >>524 外部のお墨付きを欲しがる時点でオワっとるんよ IT大手ライバル同士が Rustの代替になる思想の言語が全くそれ以降全く見ないからな。 >>527 >>530 >>515 >>530 >>534 Rustで過去に結構破壊的変更がされてたらしいけどそれは普及してなかったからじゃないのか GCやJITは銀の弾丸と思われていろんな後発言語に取り込まれたけど、所有権は最初から組み込むには高度すぎるがエコシステム成熟前に組み込まないといけないという制約が大きいんだろうな。 >>537 Rustはむしろリファクタリングにも向いていてなかなか良い言語だぜ そもそもGC無しの言語ってニッチじゃない？ うむり、実用言語では現時点で安全性とスピードを高い次元で両立できてるのはRustだけかもね。 学問的には合理的な型システムとか検証器とかの研究は大きく進んでるけど すまんが↓これが動く理由を教えて欲しいんだけどさあ https://paiza.io/projects/uhC43ajorg-qaLG7mXbw7w >>544 値が複製されて、複製された値の所有権が関数fに渡るだな。 >>544 そう言うことなのか、ありがとう！ >>547 感じてるから違和「感」だからね >>553 >>542 >>557 >>556 少し前まで次世代言語と言われてた程度には後発。 >>559 Rust知ってれば安全性の高いシステム組めますと言うアピールになるし、C++にもその安全性のための知見は役立つ。 rustというものがありながらなぜ大部分のコードはC言語なのかを知るために現場に行くのもアリ Rustが実用的になったのは2020年 Rustへの移行は始まったばかりだからまだまだCが残っているのは当たり前 絶壁の学習曲線。 P系言語の糞思考に染まっていない初心者こそ >>567 初手Rustは冗談抜きで2024以降だと選択肢に入るんじゃないか >>567 >>567 >>567 単なる感想を必死にウソ扱いして何がしたいんだコイツw ライブラリはPythonと比べると流石に貧弱 >>575 >>576 >>576 >>570 Crypto分野はRustが他言語よりも充実してるかもね ライブラリの多さってイコールでユーザの多さなんだよ いやまあ数はあるんよ数は てかrustユーザーってnvidiaのcudaサポートの酷さにガチギレするような奴ばっかでしょ。 初心者向けのSimplified Rustと、 ゼロからプログラム書くならSafe rustが一番簡単だよ C++を完全に理解した者のための言語それがRust C++を使ったことないけど 所有権を複製するとか間違った事を言い続けてる人が良く言うわw 進化論肯定派じゃないの ｶﾁｮｰ「???」じゃなくて rustだいぶ分かってきたつもりだけど >>592 >>596 Rustってfunctionをfnって略すくらい気が短いのに、なんでメソッド定義時にはわざわざselfみたいなPython臭いの入力しないとだめなんですか？めんどいんですけど メソッドをそうでない普通の関数と区別するためにはなんらかのマークは要るじゃろ。 self/ mut self/&self/&mut selfの区別もいるしな C++ の ref-qualifier とか無理のある文法だもんな。 >>602 selfより短ければ良いのか、それともC++みたいに省略できてしまってどこで定義されてるのかようわからんくなるのが好きなのか ぜひとも >>605 の考える最高にイケてる構文を教えてほしい >>605 >>605 >>602 はそれらの区別のためにもselfは必須と言ってるようにみえる >>608 thisはたまにselfの代理で使われてるな deref後のinto_inner適用と区別のため メソッドを呼び出すことと関数の第一引数に渡すことを同一視する構文は >>615 >>616 UFCSは第一引数を1つ目だからというだけの理由で特別扱いするのが気持ち悪いんだよな >>619 言うほどほとんどの言語がこれか？ >>621 >>622 C言語のときはOOPじゃなくてただの関数の第一引数に構造体を指定してた >>624 あらかじめ書いておくけどreceiver.Foo()じゃないメソッドがあるのは 代案を出せないってことはRustに言いがかりをつけてるだけだな 別に他のOOP言語のように関数にマークつけてこれはこのインスタンスのメソッドですよと言えばいいだけ >>625 レシーバの名前を自由につけられると人によってバラバラで読みづらいんだよな UFCSはフリー関数でもメソッド風に呼び出せる機能のことでRustやその他多くの言語のメソッド呼び出しとは似て非なるもの >>619 はそれを分かった上でNimについて書いてるのかもしれないけど>>620 や>>622 は明らかに誤解してる >>631 Rustは小文字selfが値、大文字Selfが型を示していて使いやすいよな 関係ない長文でごまかすフェーズに入ってるってことは内心恥ずかしくて死にそうになってるんやろうな…… 複オジは見えてる範囲が狭過ぎる 自分が使ってきた特殊な仕様の言語に慣れ親しんでいると >>640 そんなことよりError::sourceの戻り値に'static要求されるのってなんでなん >>642 くだらないレスは頻繁にするのにまともな質問が来ると急に黙るの面白い まともな質問にいつものノリで適当に答えて嘘だったら良くないしね そっか Playgroundがwebsocket接続のタイムアウトエラー(504:Gateway Time-out)で全然動かないんだが俺環？ downcastなんて別にしないからいらねーよって思ったけど >>641 >>651 >>652 答えを教えてもらっているのにヒントありがとうというオジさんw >>653 アラビア語でコーディングすれば、入力左から右へ進むから右作用が思考の順になるぜ >>656 モジュール化や結合の観点から、関数が一つの変数の型に紐づくのがそんなに優れているとはあんま思えんけどなあ それはAddが交換法則の成り立つ二項演算子だからそう見えるにすぎない いや別にSubでもDivでも左のみに紐づいているのはキモい >>658 >>662 >>663 >>659 >>664 >>665 >>667 >ほとんどの言語がこの方式なのに何を気持ち悪がっているのだろう >>670 おじいちゃんは昼だけ起きてて ジェネリックにも同じように安全に適用できるのはRustにトレイト境界があるおかげか トレイト境界はc++ conceptみたいに同じ関数集合ならOKなんだっけ？ 異なる型間の共通項をトレイトとして切り出すだけでよく 143 デフォルトの名無しさん 2024/04/07(日) 19:27 継承がなくても構造体にメソッドついてたら実質クラスだろ >>681 用語も色々。 型クラスとクラスは全く異なるので混乱しない クラスとは何か？継承とは何か？ >>681 が一番まとも 話は非常に単純 RustにはJavaのクラスはありません Javaの生みの親であるJames Goslingも、 クラス継承のある言語でも今はクラス継承を使わない設計するのが良いとされてるので要らんよな それは単に使い分けが出来ない馬鹿な子向けの説明だぞ >>691 馬鹿が使うとクソになる仕様がある言語は馬鹿をチームに入れただけで開発が即破綻するからクソ Javaの生みの親も言ってるようにクラス継承の機能はない方がいい そういうのは話半分に聞いておけばいいよ >>696 最初はなかったしずっと取り入れなかったのはそれがJAVA風じゃなかったから インターフェイスにも集合で言うところの外延性は欲しいところ。 基底クラスで保証してる内部条件を継承クラスで壊されやすい Unreal EngineがRist対応するんだってね 隙間作って床下チェスト収納ってできなくなった？動画みてるけどうまくできん shift-jiｓのファイルをBufReaderで1行ずつ読み込もうと思ったら無理でOKが流れてこない read_lineはutf-8じゃないと無理だけどread_untilならバイト列で１行ずつ取れそう >>712 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が挟まるだけだよ バッファリングせず丸ごと贅沢にメモリ使っていいなら単純 コマンドラインからファイル名取るようにしたらパニック 知らないとそういう反応するんだろうけど 日本人だから日本語名が付いたファイルを扱う機会に恵まれてるからこういうことに出会える >>722 >>720 >>722 >>724-725 リリースした後の実行時のpanicを有り難がる信者 >>722 馬鹿と話しててもらちが開かない 所有権とか導入してバグを静的に弾こうとしてる割にはこういうところではガバガバ そんなことより The Embedded Rust 読み始めたんです。 公式チュートリアルすらまともに読めないお馬鹿さんは自分が使う道具を間違えててもそれを言語のせいにしたがる >>725 >>734 >>733 >>733 しいて言えばargs()を使う方が特殊ケースなのにデフォルトの名前を引き継いだのは設計ミス 一応argsをdeprecatedにして徐々に移行させていくのはできるだろうけど >>733 >>725 環境変数もvarとvar_osがあるから慣れろとしか言えない >>741 >>741 >>732 よーわからんけど10年ぐらい前はすべてutf16になると考えられてたのでは？ >>745 >>747 >>745 >>745 https://softwareengineering.stackexchange.com/questions/102205/ utf-16はUnicode 2.0（1996年7月）のサロゲートペア導入でutf-8に逆転されたな >>749 Rust界隈では狂信者がいてそいつらはまともに反論すら出来ないけど >>737 >>740 >>746 >>754 Windows は Windows の機能として文字コードの管理はしてるが歴史的事情でツギハギのグダグダ。 コンパイルエラーにできないから引数まで廃止するとか原理主義もここまで来てんのか。 >>754 >>760 保証できるものはするに越したことはないけど (充分に実行コストが小さい形では) できんからしゃーない。 どうでもいい話でもめてるな https://github.com/rust-lang/rust/issues/91226#issuecomment-1034188905 正しく使え論は暴論だな >>765 常に自動変換したほうが安全だけどな Rustはファイル名も自動変換なんかしていないように >>768 ファイルの引数だけ標準では何もしない >>768 Resultとかのハンドリングが面倒な人向けの簡便方法として用意されてるのでそれはないと思う こういうのを見ると、RustのデザイナーはRustに求められているのがなんなのか理解できていないと思うわな。 >>772 自動変換とかそんなアホなこと言ってるのはあんただけやで こいつOsStringの概念が分かってないのか OsStringはOSから渡されたバイト列をそのまま格納するだけで 想像力が欠如しているか頭がおかしいか指示待ち人間だからそういう幼稚なレスになる >>777 人間じゃなくて壊れたロボットに話しているようだな ぼきのかんがえたさいきょうのげんごにはstring<encoding>とchar<encoding>があって ほとんどの環境がWebも含めてUTF8に統一となったからRustのstr/String内部表現がUTF8であるのは合理的といえる 文字コードをUTF-8とか特定のものに決め打ちにしないという点ではRubyが一番先進的だったが、あれはやりすぎで以降の言語には採用されなかったな。 めちゃくちゃ間違ってるのになぜ上から目線で自信満々にレスするんだろう？ >>0774 おじいちゃん誰にも相手にされず寂しくなったんだねw crates.io が死んだときはどうすれば良い？ python みたいに何でも格納できる辞書型ってC++には無いよね？ anyとmap組み合わせればいいんじゃね？ Rustで辞書型はHashMap pythonみたいにだからclassがわりなのかも 静的型付けの有用性が大きく上回るから GUI付きのポータブルなデスクトップアプリを作るとなるとどのライブラリがいいんだろ？ UIはもうネイティブにこだわらなくてもいいんじゃないかな 用途次第 Tauri は各環境の WebView を使うからアプリケーションの側では管理しなくてよくなり楽…… 即応性が必要な人は特殊な学習を手間暇というか単純に時間をかけてやって 実行時のメモリ使用量の違いもかなり大きいから最初に考慮しといた方がいい UI を記述するためのものとしては html は「普通」じゃないってことをウェブ系の人は思い出して欲しい。 UI記述は宣言的なものが主流になりつつあってhtml的なものが「普通」になってきてるんだよ >>813 何気にslintと書いてみたが紹介動画見る限りvs codeにアドオン入れてライブプレビューしながらuiの構築がサクサク行えるのは割といいな… デスクトップアプリのここにグラフ出してくださいって言われて 他にいい表現方法があるなら自分で作って使ってりゃいいじゃん >>821 試してみたけど導入のカウンタの例がいきなりビルド出来ない… 
