Rustアンチスレ
Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです >>89 は賢いお人 本来馬鹿は馬鹿を自覚できないから 平気でウンコを顔面につけたまま歩き回り いろんなものを糞まみれにしてケロっとしてる >>89 お前と俺を一緒にスンナよ。 人間の頭脳は画一敵意ではなく差が大きい。 少なくともある程度以上の大きさの開発したことある人や 複数案件を同時進行した人なら いくら完璧にしていても確率的にミスが入り込むとわかるはず そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる >>85 そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら 当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで いずれも書かれていて1つも違いがありません。 これをいくつかのファイルは巨大でファイル長が不明(無限では無い)が大きいファイルのチェックサム計算や より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか?チェックサム計算で、read_to_endは 使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません 「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を 持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある1パターンを 示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です http://qiita.com の記事なんて初心者のサンプルに過ぎません >>93 確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。 >>95 rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ? rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな まあ静的チェックに過剰な期待してる奴は大抵クソだよ >>93 そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる >80 >無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。 ヒープも使わない(ことが多いから)、メモリーの断片化も起きない 当然GCなんかいらない rustが組み込みに向かないのは同意する 小さなの規模にもよるけど スタックや初期化時以外で動的なメモリ確保がそもそもできなくない? Unix風のプロセスモデルでもないとmallocし続けるだけでアウト 組み込みの世界ではヒープじゃなくて、 リンクリストのノードを固定長メモリブロックとして使ったりする 例えばuItronのメモリプールの実装とかそんな感じ ヒープはリアルタイム性がないから で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう アンチスレとはいえ 将来性を考えると、さすがにD言語よりはrustの方が…… Deprecated Dormant Dead 縁起悪いよ…(´・ω・`) 言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など まだまだマイナーな言語へ嫌がらせする >>106 将来を考えるなら、文字列でだらだら書くというスタイルが古臭いってなるかもね。 今のプログラミングは、分厚い本を読まされてる、書かされてるみたいなもん。 映像なら3秒でですむことを延々と書き連ねているようなもんだし。 永遠に可能性が無いとは言わないが、テキスト以外の方法は生まれては消えてを繰り返してるのでどうも期待出来無い。 人間がコード書く役割が終わる方が先に来るんじゃないかな。 >>112 AIでも同じようなことが言われていて、 囲碁で人間に勝つには100年かかるなんて言われてたからね。 >人間がコード書く役割が終わる まさにそれ。 人間は「こうしたい」というのを表現できればそれで良いわけで、それをわざわざ文字列で延々と書き連ねるというのが古臭いことになるんじゃない?ってことね。 現状人間同士である程度厳密に情報を伝えようとすると言葉に頼るわけでコンピューター相手でもそこは変わらない気がする >>114 わざわざ人間が翻訳機になってるっていうのが古臭いって思うんよね。 >>114 文字によるプログラムっていうのが結局いつまで経っても1.5次元みたいなもんで、どことどこが関連しているのかということすらパッと見てわからないしね。 まあ、世の中には何百万行もあるプログラムでも簡単に目を通して全体像を把握できるような天才的な人もいるんだろうけど、私には無理だわ。 トシヨリガーとか、老害だとか言ってる割には旧来の手法に固執するんだな。 >>116 グラフィカルなプログラミング環境とか、設計手法だけどUMLとかあるにも関わらず一般的なプログラミング言語を置き換えるには至ってないよね 旧来の手法を置き換えるには何かしらのブレークスルーが必要なんだと思う 現状プログラミングが主に言葉で書かれているのは、人間がプログラムを考えていることと、人間の考えを厳密にコンピューターに伝える必要があることに由来していると思う 人工知能が発達して人間の曖昧な指示に従ってコンピューターがプログラミングするとか、脳波読みとりなど言語化なしで人間の考えを伝える手段が現れれるなどすれば状況は変わるかも知れない どの程度の複雑さをコンピュータ側に持って行っても、要求なり目的なりを記述する必要は残る。 いわゆる "プログラミング" では無いかもしれないが。 そこの記述はグラフィカルでどうのこうのと言っても汎用性を求めると結局はテキストになるんじゃないかな。 まあ要求記述のテキスト、というとSQLがその一つなんだけどさ。 >>118 で、現実にやってるのは、やれCだなんだと、それぞれの方言に合わせて人間が一生懸命翻訳作業をして文字列で書き起こしている。 客観的に見れば実に珍妙な記号とあるふぁべっの羅列でね。 そして、流行りの方言が出るたびにその方言を覚えては翻訳作業。 でも、結局のところコードが大幅に減るわけでもなく、肥大化するにつれて誰も正しい全体像を把握できなくなるのは同じこと。そして、いつまで経っても無くならない誤訳…バグの山。 やはりこのスタイル自体に無理がきているんだと思うわ。まあ、究極はコンピュータそのものの考え方から変えないとダメかもしれないけどね。 >>119 そのレベルの話だとコーディングと言うよりも設計の問題なのでは 自分がどうしたいってことしか考えないから、言語が要らないなんて言い出す。 受けとる方を考えてみろ。 CとリリースモードのRustは、どちらも実行時間が最小限です。 Cは未定義の動作でそこに到達します。 Rustは、非常に堅牢な言語定義を使用して、コンパイラーが多くの危険なプラクティスを拒否し、多くの望ましい結果を安全で比較的便利にすることを可能にします。 しかし、Rustは、多くの人が望ましくないと考える特定の動作も許可します。許可されるように言語を定義するだけです。たとえば、整数のオーバーフローを考えてみましょう。デバッグモードでは、Rustは整数のオーバーフローでパニックになります。良い。リリースモードでは、2の補数としてラップします。悪い。つまり、それは言語定義に含まれているので、非常に優れていますが、私に関する限り、これは、符号付き整数のオーバーフローを未定義の動作として参照するCおよびC++言語定義とほぼ同じくらい悪いものです。 >>122 Rustはそのために例えば足し算でも checked_add overflow_add wrapping_add saturating_add など用途毎に使い分けられるようになっている あかんところ列挙 ・コンパイル型言語らしいけど、C++の方が速い(GCC万歳) ・CPLから派生した言語とかなり系統が違う(習得しづらい) ・関数宣言でわざわざfnをつけないといけない(文脈で理解できないのかコンパイラ) 以下、C++のあかんところ ・最近のは遅い->STL使わんかったらいい、もしくは自作 ・バッファオーバーランとか、危ないことが起こる->そんな阿保プログラムを書かなかったらいい >>124 RustとC++はほぼ同等の速度 その上でRustは様々な安全性とC++より便利な機能によりプログラミング生産性も良い >>123 そういうことを言いたいんじゃない。releaseとdebugで動きが異なることを言いたいのだ。例えばGoなどはどちらも動きはわからない。 Rustはどう考えても、プログラムの1つ1つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、releaseでオーバーフローを省略するのにそれで速いとゴマカしている。計算系のベンチマークテストなどまさにそう また上のように「用意している」という表現も、限りなく敷居をわざと高くしているだけで、何の利点でもない。 >>123 checked_add (=足し算でoverflowするとOption::Noneを返す) 便利だな 例としてすぐオーバーフローするi8型(符号付き8bit整数)を使って フィボナッチ数列イテレータを書いてみた fn fibonacci_i8() -> impl Iterator<Item=i8> { itertools::unfold((0_i8, 1), |(m, n)| m.checked_add(*n).map(|f| { *m = *n; *n = f; f }) ) } fn main() { for f in fibonacci_i8() { print!("{f} "); } } 出力結果: 1 2 3 5 8 13 21 34 55 89 確かに上限127を超えて溢れる寸前まで求まっている このようにわざと貼り付けなくても良いことを書いて、不都合を指摘すると流すようにするのは本当に良くないコミュニティの態度 >>127 と同じ関数を他のプログラミング言語で書くとどんなコードになるの? 具体的にコードを比較して客観的に判断したい >>125 今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。 つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。 まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。 なんでJavaやC#がスクリプト言語に入ってんだ? C#にはC#スクリプトがあるが実行時に中間言語にコンパイルするだけだろ 一度だけ必要なメモリを確保して使い回せるものを オブジェクトとして生成、消滅繰り返すようなプログラム組むと(普通にC++でかくとこっちになる)遅くなるよ 挙句の果てにメモリフラグメントが避けられない 普通にCで書くとよほどの馬鹿でも無い限り無駄なメモリ確保開放を繰り返すなんてことはしないから >>134 領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ ベンチマークとかあるの? >>135 行列クラス考えてみろ while(1) E = A*B+C/D C++なら一行でかけるが 誤送信 >>135 行列クラス考えてみろ while(1) E = A*B+C/D; C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない ETでなんとかなる部分もinverseがあるとそれもお手上げ 一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。 >>135 >普通のmalloc実装ならそうそうフラグメント起こすことはない ヒープの動的確保でフラグメント興さないなら RTOSでメモリプール確保する必要なんてないよなww >>137 速度に関してはC++の方が不利なことに対しては異論ないよ ただフラグメントについては本当にそうなのか気になってた 今時のmallocなら直近にfreeされた領域再利用するから>>137 みたいな例なら毎回同じ領域が割り当てられると思うよ 寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね ただ、そういうのは "最近の普通のmalloc" ではないと思う >>139 なんで同じ領域が確保されると保証されるのさ。今時のOSでww そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ? とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。 そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。 あれはデフラグの対象にするかどうかが細大の目的 あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ >>137 >速度に関してはC++の方が不利 これもちょっと違うだろ 上で>>131 が言ってるようにBetter cに留めて。 過度な見やすさや書きやすさを追求しなければ C++はC機能包含してるんでC++で不利になることなんてない。 機能を使わなければいいんで不利になりようがない。 Pure C流ででもかけるわけだし >>140 とりあえずglibcのmallocでいいや >>137 のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね // ヒープを使う型Testを作って実証実験 #[derive(Debug)] struct Test(Box<isize>); // Test型が作成される時に使われるnew()を実装 impl Test { fn new(n: isize) -> Self { let new = Test(Box::new(n)); // その時にヒープで確保されたアドレスを表示 println!("{:p} = Test::new({n})", new.0); new } } // Test型の足し算を実装 impl std::ops::Add for Test { type Output = Self; fn add(self, rhs: Self) -> Self::Output { Test::new(*self.0 + *rhs.0) } } // 足し算の途中で使われる一時領域のアドレスはどうなるか? fn main() { let a = Test::new(1); let b = Test::new(10); let c = Test::new(100); let d = Test::new(1000); let e = Test::new(10000); println!("{:?}", a + b + c + d + e); } 実行結果 0x55790623d9d0 = Test::new(1) 0x55790623d9f0 = Test::new(10) 0x55790623da10 = Test::new(100) 0x55790623da30 = Test::new(1000) 0x55790623da50 = Test::new(10000) 0x55790623da70 = Test::new(11) 0x55790623d9d0 = Test::new(111) 0x55790623da70 = Test::new(1111) 0x55790623d9d0 = Test::new(11111) Test(11111) つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された したがって>>140 の主張がおかしい 一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる なぜなら、一般的には「中間値2=中間値1+次の項目」と順に計算していくためである つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする しかし>>144 の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目 5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる これがRust 今回用意したTest型はCopyを実装しなかったため、最初の「中間値1=a+b」を計算した時点てaとbは消費されてそれらの領域は解放される そのため次の「中間値2=中間値1+c」の時に、中間値2の領域として既に解放されたaの領域が使われた 実際に中間値2のアドレスがaと同じになっていることで確認できる 同様に中間値3は中間値1と同じアドレスとなっている 結論 Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、 >>137 のようなケースでも最小限のメモリしか必要とせずに済む glibc mallocの仕様なのでCやC++でも同じです Rubyを長期間動かすとGCがメモリを 細分化してしまうという話かなんかと 混同してんのかな >>145 > しかし>>144 の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目 7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの? たぶん1行目も0x55790623d9d0なのを見落としてる >>148 よく見ると2番目の中間値であるTest::new(111)のアドレスが変数aつまりTest::new(1)のアドレスと同じ これはRust特有でその時点では変数a(や変数b)を使い終えて解放されているために再利用されたと推測できる そのため6つメモリ領域で済んでいるのだろう >>146 CやC++では使い終わった変数の領域が暗黙的には解放されないから7つのメモリ領域を使うと予想 試しに>>143 で中間値をもう一つ必要とする例でやってみた println!("{:?}", (a + b) + (c + d) + e); メモリ1 = Test::new(1) メモリ2 = Test::new(10) メモリ3 = Test::new(100) メモリ4 = Test::new(1000) メモリ5 = Test::new(10000) メモリ6 = Test::new(11) // (a + b) メモリ1 = Test::new(1100) // (c + d) メモリ3 = Test::new(1111) // (a + b) + (c + d) メモリ6 = Test::new(11111) // (a + b) + (c + d) + e 即座に解放された変数領域を2つ使う点で異なるが結果的に計6つ使用に収まっているな >>144 >>145 なーにを馬鹿な考察してんの? おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。 >>145 >Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため 変数が確保されるのは関数コールの度に毎回上書きされるスタックであてtヒープではない そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。 したがって長期間リブートを想定しないRTOSで、 予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、 現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw >>154 マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、 物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね 仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ 組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ >>142 > >>137 のような解放直後に同じサイズで領域を確保する場合は領 なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。 例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、 そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。 そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ? そこが実はページング対象になってなかったとなぜ断言できるんだ。 >>156 >物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都 プログラムからは論理アドレスしか見えない 同じ領域を確保してるかどうかはプログラムからはわからない >>156 >マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど 汎用OSで自分の起動したタスクしか動いてないと思ってるわけ? RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。 そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。 今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、 やっぱりフラグメントは常時発生してる。 てか、メモリデフラグとか動かしたことないのか? >>154 まずは基礎知識を勉強しよう Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと そうでない意味のタスクならばプログラミング言語Rustとは関係ない話 >>155 そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている そんな基本的なことも理解できないならば勉強して出直してきなさい >>159 それはRustとは全く無関係ない話 基礎的なことを会得していないとそういった無関係な話を持ち出してしまう >>157 ページサイズより大きい領域の獲得解放を繰り返す想定で良いのかな? malloc/freeがmmap/munmap呼び出しと一対一対応するような で、どのOSの実装で問題が起きたの? ページ単位で割り当てるのにどうやってフラグメンテーション起こすんだろう じゃあなんでLinuxやBSD、Windowsはメモリコンパクション機能を実装してるの? >>164 LinuxやBSD、Windowsはメモリコンパクション機能を実装してるの? なんで、mallocの話がOSの話とすり替わってたの? >>140 あたりでもう一緒くたにされてるからしょうがない たぶん誰も問題意識を共有できてない たぶんmallocとOSが密に関連するようなRTOS?が前提なんだと思うよ >>140 は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう ずっと暴れている>>140 だけが『所有権』と『OS』を同時に登場させていて二つの別レイヤのメモリ管理の話を区別できていない ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている まあ所有権の話は唐突でよく分かんないけど彼の中では理屈的に繋がりがあるのではないのかな もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど あーうぜー 1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる() 1.61.0なのに 1.60.0-xxx をDLしてくるし() あーうぜー いつのまにかpython module のビルドに入り込んでるのな 悪質 なんか第二Javaという感じの臭いがする 非人間的な設計で人間を不幸にしていく悪しき文明というか linus はこれがいいみたいだけどな() git も Rust もゴミ meson のビルドで、 × Preparing metadata (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [64 lines of output] こんなエラーが出た すげーイラっとくる > .toml クズ言語 >>177 重要な部分はRustで作らないと思うよ >>177 俺もgitもgithubも使いにくいと思っていた。 git自体は悪いと思わんが、なんかgit奉行が色々言い出すのがうざいわ。 rustもそういう匂いがぷんぷんする。 >>183 名前は変わったと思うが、MS製のVisual Source Safeなんかは直感的で便利 だったな。特に何も学ばなくても普通に使えた。 cargo check error: failed to run custom build command for `glib-sys v0.17.10` いい加減にしろよカス言語 cargo publish して初めて出るエラー (cargo のあっち側の環境でコンパイルしてる) ってうざいよね >>185 Cコンパイラかリンカが入ってないんじゃね そのメッセージの前に何か出ていると思うが >>186 あっち側ってcrates.ioのこと? リモート側でビルドなんか走るんだっけ firefox のビルドもrust が邪魔しまくりだよね() RustとC++の相性は最悪だが RustとCはまあまあイケる いいじゃんいいじゃん read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる