Rustアンチスレ

Getting startedでもHello World以上のことはやってるんだから
あなたの触ってる言語がRustじゃない可能性のが高そうだね

コンパイルさえ通してしまえばエラーが無いことを保証される。
自動的な並列化によりメニーコア時代に対応。
メモ化サポート、動的計画法が自動的に実装できる、AI時代に必須。
Rust使いというだけで尊敬される、自動的に彼女ゲット。
C/C++の20倍高速。

ただし扱えるのはモジラに選ばれた人間のみ

コンパイルすら通せない馬鹿が劣等感を爆発させた結果が>>1

Rustによって未来志向の意識世界に目覚めました。
いま核ミサイルの集中制御システムに携わっています。
Rustが世界を変える、Rustで世界を変える。
アッラーアクバール。

Cは自分の頭や足を撃ち抜く危ない言語ってよく言うが、つまり銃レベルで強力ってことだよな

Rustはなんだ？ぼうっ切れか？たしかに銃と違って暴発したりはしないな

http://ha10.net/talk/1503389313.html

>>5
>>1だけどこのスレ建てたのは離隔目的だぞ

どんな木っ端言語にもアンチがいるもんだなぁ(しみじみ)

アンチを隔離するつもりが信者が捕獲されちゃったとかrustyなコードにありがちな本末転倒っぷり

>>10
本当に木っ端だったらなんも言わねえよ
モジラが言語自体をゴミクズのままにしておきながら
ステマに工数と金をぶっこんで自社ブランドの肥やしにして
それに騙されてゴミクズ掴まされる被害者がでてることに文句つけてるんだよ

>>12をそっくりそのままGoを作ったGoogleに送りつけたい

>>12
え、go ぐらいシンプルな文法でも満足に使えんの？
馬鹿なんじゃないの？

>>12をそっくりそのままSwiftを作ったAppleに送りつけたい

>>11
Rustに傷つけられたアンチと戯れるスレだからね、仕方ないね

Swiftは騙されるアポー信者が多くてめっちゃウハウハだったな、Swiftやってますだけでクッソ仕事多かったのwww
Rustは、、、上流工程には知名度がなく、下流工程には難易度が高く、どこ行っても誰も騙せNEEEEEEEE
どこの業界(分野)に行けば騙されてくれる被害者がいますか？マジで教えてください

整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
enumをforループするだけのことが面倒なのもクソ
ボローチェッカーとの戦い(笑)以前に生産性低すぎるわこんなもん
C++を置き換えるとか言ってるやつは頭お花畑やろな

>整数型からC-like enumに変換するのにtransmuteとかしないといけないのがクソ
だって実現方法はともかく意味的に整数はenumではないもの

>enumをforループするだけのことが面倒なのもクソ
forループしようと思う時点でそれはenumを使うべき場所でないのでは……

unsafeなtransmuteなんて使う地雷に自ら突っ込んで行ったら生産性も落ちる罠

何をしようとしてenumメンバをforで回す機会があるのかサッパリ分からんが
生産性悪い書き方して生産性悪いと言ってるのはよく分かった
ちょっとオモロイから、生産性悪いと思った事例をもっと教えてくれよ

アンチアンチ

俺は賢いからunsafeだって使いこなせるぜ、transmute使うぜ
結果、メモリ非安全で生産性悪いRustクソ!!!!

俺はアホだから危ないunsafe使うのやめよ、整数型からenumにするのはfn new使おう
結果、メモリ安全で生産性良いなー

Rustはアホ向けの学習難易度の低い言語だった可能性が微レ存？

普通の人間はアホか賢人に分類すると、だいたいアホ側がふさわしいからな。
無理する奴がバグを生む。俺はアホで良い。

ちょっと検索すればenumのvariantsをループで回す方法でてくる
enumの定義時にマクロを使って全メンバーを含む配列も同時に定義するなどがある
これだけをやってくれるcrateも作れそうだ

C++が車だとしたらRustはせいぜいゴーカートだなぁ

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

C++がカーチスだとしたらRustはフォルゴーレな印象

つまり、どっかの豚しか乗りこなせないのか…

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

P5EA8

6YB

なんで所有権の移動という一度しか起こらない元値を破壊するものが印なしで
参照の借用渡しが＆にしたんだろう

ねえ

moveは安全なのに何が問題だと感じるの？

次世代言語スレのつづきか
安全なだけでめっちゃわかりづらいだろ
ふつうの=でコピーと動きが違いすぎる

コピーはコストかかるから暗黙的なコピーは意図せぬ性能劣化を引き起こす可能性がある

暗黙のコピーと暗黙の参照渡しが区別つかないJavaで困らないんだから困らないのかもしれない

javaで暗黙にコピーされるのは基本データ型だけでは

C#でも困んないし

JavaとC#にはGCがあるからな

ていうかJavaやC#は暗黙のdeep copyをしない件について：

https://i.imgur.com/QvQTuqJ.jpg

>>39
グロ

クソの中のクソ
キング・オブ・クソ
作ったゴミも使うカスも肥溜めで溺死すればいい

無能がほざいてて気分いいわ

haskellと同じ道をたどるだけだな。
馬鹿がなぜか選民思想やり出して終了。

>>3
>コンパイルさえ通してしまえばエラーが無いことを保証される。
そんなわけない。

Rustは、コンパイラ時エラーに悩まされる反面、実行時エラーに悩まされるのを減らす
などと言われる。
しかし、コンパイル時エラーが出ると言うことは、裏を返せば、書けないアルゴリズムが存在するということだ。
直感的ではない回りくどい書き方が必要となり記述量が多くなる。
他の言語では好きな書き方が出来て、それはどれも正解だが、Rustでは正解が非常に狭くなる。
正解が狭いことがエラーを減らすなどという人がいるが、実際には、Rustは
書けるアルゴリズムが狭い、と言うことなのである。
これは言語設計の問題である。

なお、ここで言っているアルゴリズムは、全体的なものではなく、細かいミクロ的なものである。
通常の言語では、1つの仕事を細かい変数の使い方まで含めれば数万通り以上に書けるだろう。
そして、そのどれもが正解であり、結果が正しくバグも無いのだから、内のどれかが悪い書き方という
ことは特にない。
ところが、Rustでは、その大部分の書き方が出来ないのである。
駄目だから敢えてできなくしているのではなく、Rustが設計上、書けないアルゴリズムがあるということに他ならない。
つまり、Rustは書けるアルゴリズムが、本来コンピュータが書けるアルゴリズムの内の、非常に狭いサブセットに限られてしまうということである。
これは、Rustの大きな欠陥である。

>>45
「駄目な書き方だからエラーにしている」
と言うのは間違いで、正しくは、
「Rustコンパイラの静的解析能力では、書き方を非常に限定しないと
　正しいことを保障できなかったり、自動化できなかったりするため、
　しょうがなく狭い書き方しか出来なくしている」
と言うことに他ならない。
人間には脳内の静的解析で明らかに正しいことが分かる書き方でも、
Rustコンパイラではでは同じことができないため、敢えて
変数束縛、借用、単一参照など、コンパイラでも解析できる程度の
範囲に書き方を限定して無理やり人間のプログラミングの可能性を
狭めているに過ぎない。

>>43
Rustは、Haskellから多くを借りてきているらしいから、Haskellと同じ
道をたどると言う予想はあながち間違ってない。

Rustは表面的に使うだけなら、まあ、C++が使えるプログラマなら、大体使えなくは無いだろう。

しかし、自分で独自にリンクリストを作ろうと思うと事態は一変する。

そこまで深く入った人ほど、Rustは難しい言語だと感じるはずで、
RustがC++程度で理解できると思ってる人は、99%、浅い所までしか使ってない
と言えよう。

道具として正しい在り方だな

>>49
RAD言語ならそれで良いが、システム言語では駄目。

Rustは、コンテナは、配列(長さがコンパイル段階で静的に決まる固定長)、
ベクター(動的配列)が主で、LinkedList<T>は、せっかくのリンクトリストの
特徴である末尾以外の「途中」への追加は出来ない。
これではリンクリストの意味が無い。
また、公式ドキュメントに
「ベクターの方がLinkedList<T>より速い」
などと書いてあるが、それはとんでもない間違い。

00年代半ばごろのゴミサイトがアクセス数を稼ぐのを思い出した


ゴミ

可読性低いな

Ｒｕｓｔを含めた新手の言語の仕様が固まるまで、２０年ぐらい掛かるからなぁ

今２０代の連中がＲｕｓｔを使いこなせる様になっても、

システム開発に使える頃には、４０過ぎの中年だけど、まだプログラマー続けてるの？

レッツ！ｍｕｔ　＆ｍｕｔ　もっと　＝　したい：ダメな日本語；

error[E0382]: use of moved value: `vector`

もうお前のRustコード直すの嫌だわ

意識高い系が自己満足でめちゃくちゃなコードを他人に押し付ける言語

>>45
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
そのやり方は一目見ただけではわかりにくいかもしれない。オランダ人にだけわかりやすいなんてこともあるかもしれない。

The Zen of Pythonの一節だけどRustの設計思想もこういうことなんじゃないか？
何通りもある書き方を統一することによってコードを読む人にも分かりやすくするってことだと思う。
もうそこは好みの問題だから気に入らなければやらないでいいんじゃないか？

Rustは組み込みシステムでも非常に多く使われているように何でも書ける
Cと同様に低レベルな部分でも記述可能でさらにインラインアセンブリも可

raw pointer 使えるし C でできることはだいたい出来るのでは
できないのは variable length argument/array くらい？

そりゃunsafeすればなんでもかけるわ

>>63
C/C++/Rust以外の言語ではどうやっても無理

なんかRustアンチは必要以上にunsafeを忌避してる気がする

unsafeは注意が必要な部分を限定するために用意された言語機能なのに
「unsafe使うならC/C++でいいじゃん」
とか考えてそうな雰囲気

unsafeブロック内でもボローチェッカは仕事するって知らん人多そう

>>24
いや、自走車椅子だろ

>>24
C++より便利で安全だから
例えると醤油とソースかな

Rustスレでは場違いなので、イテレータというか高階関数の話にもう一度食いつくとする。

Juliaなんかだと並列・分散処理するために@distributed forなんて書くが、Erlangだとループ中に
spawnをして、Goもgoroutineを起動する。map/reduceなんかだと明らかにメニ―コアを使った方が
速いが、標準ではそうなっていなくて、外部ライブラリのrayonなどを使用する。
GoでもRustでもこれをさらに分散処理させるにはgRPCなど規格化されたインターフェースを通すが
やりたい事はJuliaの@distributed forなのに手間を感じさせる。
Rustにライトウェイトスレッドが言語仕様として入るとは思えないが、やはり言語には向き不向きが
存在する。近年のjavascriptを発端とするasync/awaitにも疑問が生じる。あまりにも多くの言語が
同期実行のライブラリと整合性が無さすぎる

DSLと同等の使い勝手を汎用的な言語に求めるのはつらいのでは

>>69
たしかにJavaScriptのasync/awaitとRustのは最も対照的ですがどちらも良い特徴があると思います
JavaScriptはブラウザも外部のNode.jsもその言語実行環境として非同期ランタイムが組み込まれasync/await導入以前から非同期関数が標準として装備
そのため非同期関数が呼ばれたら次のスケジュールで即座に実行が始まりますね

一方でRustは標準の非同期ランタイムがなく用途に合わせて自由に非同期ランタイムを用意することが出来ます
さらにRustのasync/await自体はゼロコストで設計されており非同期関数が呼ばれても自動的にスケジューリングされない特徴があります

Rustはこれらに関して「何ができない」のではなく「何でもできる」わけなので
あとは記法の簡易性を求めるのならばその呼び出し関数等の設計とマクロでお好みの方面へ寄せることも可能です

>>71
これは良い書き方をしているが非同期ランタイムを自由に選べるのではなく、適切に選ばないと
インターフェースをサポートしない場合があるため、互換性が保てないでしょう。Rusterは
ゼロコストという話を良くしますが、Rustの非同期はタスクごとにステートマシンを作るために
確かにNode.jsなどと比べるjavascriptと比べれば、全体で非同期をスケジューリング管理する
ものと比べアロケーションや実行コストなどは小さいですが、それほど喧伝すべきことでもありません。
いずれにせよ多くの非同期はI/Oバウンドでありepollベースなどで管理されます。当然ながら
(Cに代わるようなハードウエア近い）システム言語なので出来ない事があってはイケていません。
私が言っているのは、Rustに限りませんがasync/awaitの記述が普通に考慮されてない設計の悪い
ライブラリが沢山あるという事です。Rustのマクロは最低だと思います、なぜわざわざ学習コストを
引き上げるのか理解できません

>>72
あなたの主張は意味がわからない
まず「互換性が保てないでしょう」は何との何の互換性が保てないのか？意味不明
次に「それほど喧伝すべきことでもありません。」は結局のところあなたは反論すら出来ずに同意してしまっている
さらに「Rustに限りませんが(略)設計の悪いライブラリが沢山あるという事です。」はRust言語に対する批判にすらなっていない
それぞれ具体的に問題点を述べましょう

唐突にマクロが登場するのも分かりませんね
async-awaitがマクロだった頃の話をしているのですか？

あんたの方が意味不明だけど（笑）
まず文書の書き方にケチを付けてロンパーする癖を直しましょう。

最初から非同期ランタイムの互換性と書いているでしょう。例えばasync-stdと
tokioは互換性がありません。今は互換性がほぼあるようになってきていますが
それでも完全ではありません。

ゼロコストFeatureという話は、VS Javascriptという言語のランタイムではその
通り認めていますが、コンパイル型の言語でコストが高い非同期は稀です。

Rust言語に対する批判しか書かないわけではありません。あなたは攻撃されたと
思い込む癖が強すぎる。「近年のjavascriptを発端とするasync/awaitにも疑問が
生じる。あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」
という大本も読めない。まあそういう人間が増えすぎて居る訳で、こんな雑談で
怒り心頭になり、それぞれの具体的な問題点はあなたの性格でしょう。
言語的な反論をせずに文書の読解も出来ず、条件反射で相手を貶す。とてもでは
ないですが近寄りがたいですね

またマクロについても「マクロでお好みの方面へ寄せることも可能です」という
返答に関して感想を述べてるのに過ぎないのに、全く話を辿れていません。

>>75
具体的な問題点を述べましょう
例えばtokioの上に構築されたhttpモジュールであるhyperも互換レイヤーによりasync-std 上でも動作します

RustアンチスレでなぜJavaScriptを問題にしているのかも謎ですが
JavaScriptのasync/await/Promiseもあの環境で非常に優れて設計されています
この件についても具体的な問題点を述べておられないですね

>>75の勝ち
以上

>>75
＞「近年のjavascriptを発端とするasync/awaitにも疑問が生じる。
＞あまりにも多くの言語が同期実行のライブラリと整合性が無さすぎる」

意味がちょっと不明です。
JavaScriptでそれらが用いられうる通信分野では、基本的に同期実行のライブラリは存在しません。
例えばhttpなどで取得してくるfetch()も非同期ですし、もっと低水準のモジュールも非同期です。
同期実行のライブラリと整合性が無さすぎるとは、何を意味しているのでしょうか？

発端と言ったらC#の方が古くね

Rustって組み込み開発向いて無くね？
どう考えてもLinuxなりBSDなりある程度高度なOSがある事前提だ、OSのメモリーコンパクションが
無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。
マイクロコントローラのメモリー付きSoCでブーストラップローダーがあるだけの組み込みには使えない
ま、サポートプラットフォームにTier1/Tier2でも、そういうのに使えるとは書いてないけど

>>80
その文章だけならCにいれかえてもあってそうなんだが？

>>80
つまりC/C++/Rustは組み込みやOSに向いていないとｗ

そこで組み込みのために開発されたJavaですよｗ

それはリソースがたっぷりある組み込みのケースで感覚としてはアプリ開発に近い
組み込みはピンキリだからスクリプト言語が動く環境まである
一方でC/C++/Rustじゃないと厳しい環境もある

設計にバカが関わってなければC++で十分

コードの規模が大きくなると複雑さが増して相対的に知性下がるからバカが開発することを前提にした方が良い

>>87
それは自覚症状が無いだけで自分が馬鹿なだけかも知れんが。

>>88
自分は馬鹿と思ってコード書いた方が良いよ本当に
これはバカにしてるとかじゃなくて心構えとして

>>89は賢いお人

本来馬鹿は馬鹿を自覚できないから
平気でウンコを顔面につけたまま歩き回り
いろんなものを糞まみれにしてケロっとしてる

>>89
お前と俺を一緒にスンナよ。
人間の頭脳は画一敵意ではなく差が大きい。

微笑ましい

少なくともある程度以上の大きさの開発したことある人や
複数案件を同時進行した人なら
いくら完璧にしていても確率的にミスが入り込むとわかるはず
そしてC++とRustとの比較ならどちらが良いかも冷静に判断できる

>>85
そんな事を言ってるんじゃないと思いますよ、「複数のファイルのチェックサム計算」なんて単純な事なら
当然ながら同期と非同期でそれほど違いは出ないでしょうし互換性があるように見えるでしょう。なぜなら
チェックサム計算は一瞬で終わり非同期はファイル毎に区切っているから。チェックサム計算は同期コードで
いずれも書かれていて１つも違いがありません。
これをいくつかのファイルは巨大でファイル長が不明（無限では無い）が大きいファイルのチェックサム計算や
より複雑で時間のかかる計算を非同期で行いたいとすればどうしますか？チェックサム計算で、read_to_endは
使えずストリームを非同期に読み続けて計算することになるでしょう。という事はbytes.iter().foldも使えません

「同期実行ライブラリと整合性が無いというのはウソです」このように言い切ること自体に"気持ち悪い信仰"を
持っているのは良く分かりますが、元が「整合性が無さすぎる」と言っているのは、整合性がある１パターンを
示しても意味が全く無いという事です。多くの問題は「ウソです」と言い切れる浅はかさが問題です
http://qiita.comの記事なんて初心者のサンプルに過ぎません

>>93
確率的な話をするならコンパイラの塾制度考えた場合の確率を下回るくらいのメリットしかrustにはないよ。

>>95
rustcで検出できるバグを仕込む確率よりもrustcのバグを踏む確率の方が高いということ？

rustcで検出できるバグよりcとのバインディングでの勘違いで生じるバグのが多いわな

まあ静的チェックに過剰な期待してる奴は大抵クソだよ

>>93
そのうち上位層はビジュアルプログラミングに取って代わられて行ったりしてね

Rustのスレで何を頓珍漢な

コンパイルチェックがゼロになるコードを書けるまでウンコ呼ばわりされる

>80
>無いとGCが無い故にメモリーの断片化が起こり、長時間稼働するタイプの小さな組み込みには向かない。

ヒープも使わない（ことが多いから）、メモリーの断片化も起きない
当然GCなんかいらない
rustが組み込みに向かないのは同意する

小さなの規模にもよるけど
スタックや初期化時以外で動的なメモリ確保がそもそもできなくない？
Unix風のプロセスモデルでもないとmallocし続けるだけでアウト

組み込みの世界ではヒープじゃなくて、
リンクリストのノードを固定長メモリブロックとして使ったりする
例えばuItronのメモリプールの実装とかそんな感じ
ヒープはリアルタイム性がないから

で、rustはstatic mutが使い辛過ぎて、組み込みでは難しそう

D言語も忘れないで下さい。

アンチスレとはいえ
将来性を考えると、さすがにD言語よりはrustの方が……

D言語：「忘れないで・・・」

Deprecated
Dormant
Dead
縁起悪いよ…(´・ω・`)

言語と関係ないがrusterのこういう陰湿さが嫌、goに頻繁に嫌がらせしてるし、gcが選べるD言語など
まだまだマイナーな言語へ嫌がらせする

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はどう考えても、プログラムの１つ１つを完全に知りえていなければプログラムを書いてはならず、安全な側へ倒すのではなく、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と同じ関数を他のプログラミング言語で書くとどんなコードになるの？
具体的にコードを比較して客観的に判断したい

>>126
release buildでもチェック有効にできるよ
https://doc.rust-lang.org/cargo/reference/profiles.html#overflow-checks

プログラムの一つ一つを理解しなくても書ける言語ってどういうものだろう

>>125
今どきのC++は遅いっていうけど、新しいC++の仕様を使うからである。
つまり、Better Cみたいな使い方をすればRustより速くなる(実際そういう結果もある)。
まあ、体感はどっちもかわんねえべってとこだから、RustよりJava,C#とかスクリプト言語をアンチすればいいと思う。Rustで慣れてる人はRustで書けばいい。

C++が遅いってコンパイル時間の話ちゃうん

なんで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つのメモリ領域を使うと予想

>>149-150 あ、ほんとだありがとう。

試しに>>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つ使用に収まっているな

https://wandbox.org/permlink/tYewWGlffMON9jxK

ところでこの結果とフラグメンテーションって特に関係あるんですかね

>>144
>>145
なーにを馬鹿な考察してんの?
おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを
なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。

>>145
>Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため

変数が確保されるのは関数コールの度に毎回上書きされるスタックであてｔヒープではない
そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。
したがって長期間リブートを想定しないRTOSで、
予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、
現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw

>>154
マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、
物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね

仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど
だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ

というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ
組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ

>>142
> >>137のような解放直後に同じサイズで領域を確保する場合は領

なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。
例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、
そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。

そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww
おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ?
そこが実はページング対象になってなかったとなぜ断言できるんだ。

>>156
>物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都

プログラムからは論理アドレスしか見えない
同じ領域を確保してるかどうかはプログラムからはわからない

>>156
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど

汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?

それなんかRustと関係あるんすか？

>>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はまあまあイケる
いいじゃんいいじゃん

カス言語ではない

C美しい
C++カス
Rustもうちょっとがんがれ

Rust リファクタリングしてるときに
trait 境界が変わって
あれ？ってなることが多いな

>>192
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね

>>0185
お前はディストリ自分で組まないの？
情弱だな(ﾌﾟ

創価

crates.io が死ぬと詰むな・・・

なんなの vendoring とか stable channel とか

意識高そうですね()

Ruby批判だけど
https://qiita.com/scivola/items/17470c52641d3ffa1650
Rustにも同じことが言える

>>198
Rustに該当する話が一つもないのにRustを批判？

信者は信者スレに帰れ

おまいらホントRuby好きだな

遅いのがなあ

test

githubの応答が遅いんだが

知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

無敵で草

理由なんか不要
ゴミはゴミ

安全なんかどうでもいいから早く書かせろよ
国防総省がどうとかAIがどうとかうるさいんだよ

愛は重要だ

Rustには開発者への愛がないんだよ
機械ばっかり見てる

Rust信者はいちいちThe Book読めとか言ってくる
自分では説明しない

俺にわからないことがあいつらにわかるわけないだろｗｗｗ

>>211
そんな専門書読むほどRustに興味ないｗｗ

unsafeとかいうゴミ

偉そうにメモリ安全とか言ってるけどわかってないだろ

どうせ流行ってるから使ってるだけ

流行ってるから使うとか、JKのインスタかよ

専門書を読めばJKでもわかる

>>218 専門書を読めばｗ

そんな勉強熱心なやつはいないｗｗ

rustなんてクソ言語学ぶ価値ない

RustはHaskellと同じ道を辿ってる

コンパイルの遅さが致命的

RAM爆喰いデブrust-analyzer

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

Rustスレのアンチコメントをまとめてくれているのか

RustはAIが無かったらワンチャンあったかもな
ご愁傷様

>>227
信者「いや、AIがあるからこそ！」

Rustは契約プログラミングをサポートしていない

>>229
流石にバカ

>>1
その段階で躓くのはアホすぎる

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

Rustはフールプルーフじゃない

むしろフールプルーフだからコンパイラに止められるんでは

俺の思い通りに動かないRustが悪い

Rustはコンパイルが速くなるように作られてないからコンパイルが遅い
C++はコンパイルが速くなるように作られてるからコンパイルが速い

コンパイル時なんちゃらで今後遅くならんか
ゼロコスト抽象化の代償かな

C++は神
rustはゴミ

>>237
コンパイル時処理はC++が先にいってる

RUSTは美しくない

アンチの頭脳はこの程度

信者ぶちギレで草

Rsut応援隊って一人で何人分の自演してるんだろうな

美しくないのは事実だからｗｗ
信者乙ｗｗｗ

自分の言葉で語れない信者ｗ

信者はウェブまでrustで書くらしいぞｗ

moveとかいうキショすぎ仕様

>>247
お前さっきから古い投稿コピペしてるだろ

>>13
>>15
お前らは何なら書けるんだよｗｗ

どうせpython
しかも境界条件でバグる

Pythonは神だろ

pythonなんて遅くてバグだらけ

Pythonアンチはよそでやれよ

アンチの頭はこの程度

>>246
草
頭悪いんやろな

RustなんてしょせんMLのパクリ

Rustスレまた荒れてて草
Rust信者は協調性ゼロの奴しかいない

電燈がついてたら集まる虫だもんｗ

このスレダメじゃん。読んでると擁護したくなるわ

>>256
Rustは関数型を一部壊してCっぽくしたやつだから

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

>>261
これ無敵すぎて笑う

unsafeがあるからゴミ
厳しいからゴミ
↑これ

Rustがゴミなのはrustcがゴミだから

所詮メモリ管理ができない奴のひがみ

>>265
黙れ

WASMの失敗はRustなんかを入れたこと

もうコレ「お笑い小噺板」でやってても良いのでは？

>>268
それは違う

>>21
自分を天才だと思ってる奴はだいたいバカ

学習難易度は高いけど、ミスをしないと思ってる奴はバカ

使う意味ない

意味ないってことはないだろ

>>268 アンチスレ立てる用の板じゃないでしょ

個人で使う意味はないでしょ

別にC++でいいよね

モダンC++書くならもうRustでいいだろ

C++は慣れてるから……

Rustも慣れたらええやん

うるさい

Rustが嫌いだから嫌いなんじゃなくて、Rust信者が嫌いなんだわ

>>267
golangでいいぞ

Goはいいぞ

C++のコンパイラにguardオプションを付ければいいだけなのよ。
又は後付けのセキュリティチェックを準備すればいい。
もう誰かやってると思う。
大丈夫　また戻ってくるよ。

流石にC++は言語仕様で安全じゃない部分があるからなあ

unsafe使えば一緒だろ

コンパイル通らんかったら意味ない

thread::spawn() すら知らないくせにイキってるバカもこっちで隔離してほしい

BunをClaudeでRustに変換したみたいだけどunsafeだらけらしいなｗ

バカは何使ってもダメってこと

>>288
thread::spawn() を使う奴はRustアンチらしいぜｗ

このスレより意味不明でおもろい

>>141
それならもうRustで書いた方が楽なん笑う

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

草

RUSTは"Resource acquisition is Unforgiven STealing"の略な

リソース取得は息をするようにやってるんですがそれは

信者が怒ってて草

信者イライラ

ｗｗｗ

>>3
これ好き

>>48
C++完全に理解した

C++100%わかってると思ってるのは流石におもろい

RustはC++と比べるとまだマシ

ここまで自演までしてRustを盛り上げようとしなきゃいけない理由って？

民家への飛び込み営業って、営業になりたがるような陽キャでもすぐ精神病むような過酷な仕事だけど
宗教の信者はそれを無報酬で喜んでやるわけじゃん？

複おじ理論「thread::spawn() を使う奴はRustアンチ！」

複オジ理論「不要なスコープを取り除いたらスコープが壊れてるんだ！」

複おじ理論「どんな寿命の参照でも、関数から必ず返せる！」
↓
「スコープで寿命が変わってるから返せないんだ！　こんなのは反例にならない！」

おもろすぎる

信者もアンチもここまでぶっ飛んだことは言わない

Cをやらないと理解できない欠陥言語

Cくらい分かるでしょ？
問題ないな

……と言ってる奴はだいたいわかってないｗ

Cわかってるってイキってる奴はわかってないよな

Rust信者もRustわかってない

Rustって言語仕様は他の言語と比べて大きいの？普通なの？

C++より非常に小さくコンパクトにまとめられている

でもC++でよく使われてる機能はだいたいある
C++には使われていない/使わない方がいい機能が多すぎる

Rustよく分かってないけどclaudeでインターフェイスだけ書いてcargo check満たしたコード書かせるだけでRustは爆速でメモリコスパも良い
スポットで使うつもりがどんどん拡大してるよ

REST APIとDB使うくらいなら簡単そう

>>320
AI時代になって遅い言語を使う意味がなくなったよな
その言語じゃないと不利な特殊環境などを除けばGC言語は全廃でよくなった

goとJavaはいるでしょ
ライブラリの資産が膨大すぎる

それ以前にAIにRustやCで複雑なロジックやメモリ管理を書かせると動かないことはまだ多い
人が書くより時間をかけて繰り返しデバッグして作るよりはGoみたいなGC言語を使った方がいいんだよね

わざわざ開発速度を落とすメリットがないことは多いしな
Rustで最高速・最軽量を徹底しなきゃいけない用途ってアプリケーション開発では少ない

なんか建設的な話題になってて草

ライバルが同じサービスやアプリなどをRustで軽量高速に作ったらライバルに負けてしまう
ライバルがいない間は安心
ライバルが出現する前にRustへ移行が建設的かも

普通のスタートアップはパイソンで十分だと思うよ
ゲームや広告配信処理あたりは速度重要だろうけど

>>328
こうやってメンテナンスできないゴミを作って後で困るんですねｗ

>>327
心配しなくてもそんなコストをかけるメリットがない
数ミリ秒速くても客は気付きもしない
Goで書いてそこそこの速度で動けば十分

それはそう

【悲報】Rust信者、スタックとヒープの区別を free() するかどうかだけだと思っている模様

アホすぎて草

やっぱりこの程度

複オジ、ムーブとコピーの区別がつかない様子

ムーブなんか使わないだろｗｗ

こっちの方が治安よくて笑う

ここはC++のすばらしさを語るスレですか？

別にC++の話そんな続いてないだろ

それな

またRustスレ荒れてて草
わからないのにイキりたがる信者が多いからだね

Rust応援隊って仕事でやってるんだろ

>>322
AI時代にメモリ食って遅い人間向きの言語は不要になってきてる。さすがにCだとAIのトークンコスパが悪いから辞めたけどRustは良い
もう既に3桁はN+1みたいなクソコード書いてるだろうけど書いてはいけないコード、良いコードとルールを足してテストを増やせばコンパイルが遅いだけになった
ある程度開発〜運用できるプログラマが使う前提ならAI×Rust 可読性がどうしても必要ならGo

Rustなんて何に使うんや？
Webでもゲームでも使い物にならんやろ
学生さんが夏休みに楽しく遊ぶのはええけどね

>>343
AIがそもそも何を書いてるのか理解してなさそう

>>344Webとゲームしか思いつかないのが浅はか
大半のプログラムはそのどちらでもない

Webとゲームは学歴不問だったりするからな。Webは特にレベル低い。DDDとかなんじゃそりゃ

ドメイン駆動設計って頭悪すぎる言葉よな
そうじゃないソフトウェアを作るアホがいるのかって感じ

高速省メモリの分野はRustに任せて
我々は妥協してC言語を使おうぜ

Fil-Cプロジェクトは、コンパイラの修正とガベージコレクションを通じてCコードにメモリ安全性の計装を追加するもので、大規模な書き換えなしにレガシーなCコードベースを保護するためのパラダイムシフトの可能性を示している。
Fil-Cは、コンパイル時の計装と並行ガベージコレクタの組み合わせを通じて、空間的安全性（境界外アクセスの防止）と時間的安全性（解放後使用エラーの排除）の両方を提供する。
Fil-Cでコンパイルされたコードのパフォーマンスオーバーヘッド（推定1～4倍のサイクルと追加のメモリ使用量）は、議論の中心的なポイントとなっている。
ガベージコレクションの要件により、Fil-Cは決定論的メモリ管理が極めて重要であるカーネル開発や組み込みシステムには適さない。
このツールは、他の言語から呼び出されるCライブラリでも課題に直面しており、二重のガベージコレクションシナリオが複雑さを生み出す可能性がある。

C言語は高速省メモリの代表例だろ
Rustとの違いは安全性

>>348
それな
用途考えずにソフトウェア開発するとか人手と金の無駄

>>349
Fil-Cを使うことで、C言語は高速省メモリを失う代わりに安全な言語になった。
Fil-Cのメモリ管理は並行ガベージコレクタで動作する。
free() はオブジェクトを「free 状態」にマークするだけで、実際のメモリ回収は GC が行う。
これにより use-after-free が原理的に攻撃に使えなくなる。
検査に違反した操作は全て「Fil-C panic」として捕捉され、プロセスが停止する。
ヒープ/スタックの範囲外アクセス、use-after-free、ポインタと非ポインタの型混同、va_list の誤用、システムコールに渡すバッファの検査など、C のメモリ安全性を脅かすものは一通りカバーされている。

CプログラマはGCなどという気持ち悪いモノを使わない
そんなものに手を出すならRustの方がマシ

C言語の文法もライブラリもそのままだよ
コンパイラをFil-Cへ変更するだけでGC言語としてコンパイルされる
C言語の文法が好きな人にはピッタリだね

高速省メモリを失ったらC言語の意味がないのでは。。。
そんな捻くれた実装なんか乗せずにRustと同じレベルの厳格なコンパイルエラーモードを追加するだけでいいのに

Fil-C実用で使う奴ってバカだよね、Go使った方が同じことができてより安全でより書きやすいんだから
そんな実験的に作られたものを例に出して「だからCは高速省メモリじゃない」というのはただのバカ

>>355
C言語の仕様ではそもそもRustみたいな厳格なコンパイルエラーは検出できない
最近のGCCには標準で -fanalyzer が搭載されてるけど、これをもってしてもRustよりは弱い保護しかできない

実用出来ないでしょ
既存の.so使えなくなる制限が大きすぎる
CIに使えるかな

-fanalyzer(静的解析)と-fsanitize(動的解析)なんてのがあったなんて知りませんでした。
gcc14以上みたいですね。

>>345
自然言語語も理解してなさそう

>>360
自然言語語は草
お前だろｗ

>>352
C言語の美しさは挙動の透明さによるものなわけで、挙動が不透明なGCに全てのオブジェクトを任せて、メモリ消費量を増やし、動作速度を落とし、stop the worldを発生させるFil-CはC言語であるメリットがない

GCがないRustへ書き換えた方がいいね

それどころかGC言語のGoよりも遅くて非効率なケースが多い
いくらなんでもバカすぎる

Goより遅いのは草
ただの道楽やんｗ

アホくさ

Goより遅くてGoより書きにくくてGoより環境依存でGoよりバグりやすくてGoより使えるバイナリのライブラリが少ないのか
……ん？

既存のC言語のソースコードをGCモードで安全に動かすのがFil-Cコンパイラ
Goより遅いのも仕方ない

RustはGoより早いの？

特殊な用途で役にたつかもしれない。?

>>369
早くていけない

>>368
※ただし既存のバイナリは使えない
これが欠点として大きすぎて使う気にならない
それならGoのエコシステムでも十分使い勝手がいいよ

>>369
GCの処理が丸々ないんだから、当然速いわな

>>370
特殊な用途で役立つ数よりも、勘違いしたアホがゴミを量産する数の方が多そう

>>369
そこはGCの有無が効いてる
GC無い方が速い

C使ってて努力してsoの置き換えまでやる人いるかな
ヒマ人検出器として見守る

まあ、GCあるGoより遅いあたりFil-Cは最適化も大したことない

Go向けにした方が100倍よさそう

世のため人のためにFil-CではなくGo対応にしましょう

Goより遅いｗｗ

Rustの代わりにFil-Cは頭わいてる

>>349
>>352
GC付きのいい言語は別にいくらでもある

>>354
バカが「俺もC言語書けるんだぜ」って知識もないのに威張るために使うならアリってことか？

>>349
>>354
移行期技術を新規開発に使っていいと勘違いするバカが湧いてて草

新規開発ならGC不要なRustでしょ

そらそうよ。Cの過去資産が多い場合に考える用だ

Cの既存資産が多くてもGCをつけられて困らない分野となるとGoで書き直す方がよさそう

言語機能が弱くて不便なGoをわざわざ使うことはあるまい

最近はCのアプリ減ってるし、sqlite3みたいなものはCがいいっしょ

>>386
言語機能が弱いとは？
クラス信者かな

イテレータのループ無かったGoさん

ループも自力で書けないのかこいつは

>>389
いつの話してるんだこいつは

>>389
いつの話してるんだこいつは

>>388
信者は信者スレに帰れ

>>387
Fil-CにするくらいならGoでいいだろ
Fil-CじゃダメならRustになるな

>>393
何言ってんだこいつ

>>393
いつからここはGoアンチスレになったんだよｗ

>>392
最近までなかったような
ここはアンチスレだから手厳しいぞ

>>394
だからピュアCだって

>>398
ピュアCのままがベストってことは、安全性度外視ってことだがわかってるか？
SQLがホントに安全性度外視でいいと？

>>397
ここはGoアンチスレじゃないぞ

>>389
Cにもない定期

>>399
めちゃくちゃテストあるからいいんじゃね
あと組込みDBなのでMySQL達とは違うよ
Go実装のDBあるしそっち使えばいい

テストで安全性は保証できないよｗ

そんなもの保証しなくていい。手段と目的を入れ違えてないか
20年続いてるプロダクトを切り替えるほどのものじゃない。
やりたいならスクラッチからsqlite.rsを実装せよ

>>404
話をすり替えてるのはお前だよｗ
>>387でCがいいと言い出したからこういう話になってるんだわ

技術的にCがいい理由なんかないんだよな
既存資産ってだけ

新規ならね。20年続いてたらRustはないしFなんとかもない

>>389
Cにもないですよ

>>408
Rustとの比較じゃないの?

>>409
Fil-CよりもGoの方がマシって話だっただろマヌケ

えーと
Rust、C、Go、Fなんとかの順だね
あれ?アンチになってない

Rustはゴミ

205　デフォルトの名無しさん　2026/07/17(金) 21:59:09.13　ID:5FsOttRT
知識のない奴が好き勝手Rustをバカにできるのがこのスレのいいところなんだから、まともな意見とか求めてないんだよｗ

無敵理論やめろｗ

根拠なくていいんだこの錆

序盤の書き込み見ればわかるけどろくに根拠なんかないぞ

Goより遅いとか書いてるやつってRust使ったこと無いだろ

メモリを逐次バラバラにたくさん確保して使いまくる特殊な分野のベンチマークにおいて、
何も考えずに書いたRustのコードがGoに負けたことがある。
そういう分野での常套手段であるメモリをまとめて確保とまとめて解放をすれば、もちろんいつも通りと同じくRustがGoより速い。

「まとめて確保とまとめて解放」をしなければGoのほうが速いんだなｗ
Goすごくね？

GCを持っている以上は独自のメモリープールもあるだろう
細かく確保するように見えて実はメモリープールから切り出しているから速くなる
ただしメモリープールの追加確保が必要になった場合はスパイク状の負荷が発生する

>>419
メモリをバラバラに取得解放よりも
まとめて解放するGCが勝つレアケースがある

しかし現実にはC/C++/Rustでも
その手のケースではメモリをいわゆるアリーナ管理でまとめて解放している
したがって常にGC言語が負けている

Postgresの構文器用に確保したメモリの一括解放エグいよね

意図的にクソコード書かない限りGoとのパフォーマンス差は圧倒的なのに
GoにはGoの良さがあった。Javaにだってあったわけだけど今はもう時代遅れよな