Rustってネットで持ち上げられすぎてね？

メモリ安全ってだけでランタイムGCあり(メモリ安全)の言語でバグ出してるやつが使ってもバグが減るわけじゃないんだが？

Rustはオワコン

>>152
早くてメモリ消費量が少ないのと安全を一緒に並べてはいけないと思う
前者はC以外との比較、後者はCとの比較
比較対象をコロコロ変えていいなら何でも言える
例えばPythonは速くて型安全で誰でも使える言語なんてことも言えちゃうのでは

Pythonは遅い言語
型安全もない

攻守のバランスの良いC#が最強

Pythonは遅いけど、型安全性は定義によるかな。動的型付け=型安全性がないみたいな感覚の人は多いけど、計算機科学の普通の用語法だと、Pythonとかは型安全の方に入るみたいよ。

うーんこの通じなさ以下解説

この書き込みは、比較対象を都合よく変えることで、もっともらしい主張を作っている点を批判している、という意味です。順を追って整理します。
① 問題にしているポイント
引用されている「>>152」の主張はおそらく：
「速い」「メモリ消費が少ない」「安全」
といった特徴を、同時にその言語の強みとして並べているものです。
② 書き込みの指摘
投稿者はこう言っています：
> それぞれの評価って、比較対象が違うでしょ？
具体的には：
「速い・メモリ少ない」
→ これは C以外（例：PythonやJavaなど）との比較
「安全」
→ これは Cとの比較（Cは安全性が低いことで有名）
つまり：
👉 同じ土俵で比較していないのに、全部まとめて「優れてる」と言ってるのはズルい
という批判です。
③ 例で言っていること（Pythonのくだり）
> Pythonは速くて型安全で誰でも使える言語なんてことも言えちゃう
これは皮肉です。
例えば：
「速い」→ 他の遅い言語と比べれば（※実際は遅いが）
「型安全」→ 型が緩い言語と比べれば
「誰でも使える」→ 難しい言語と比べれば
こうやって比較対象を都合よく変えれば、何でも良く見せられるということ。
④ まとめ（この人の言いたいこと）
特徴を語るなら 同じ比較基準で統一しろ
比較対象をコロコロ変えると いくらでも都合のいい主張が作れてしまう
だからその主張は あまり信用できない
一言でいうと
👉 「比較の基準がバラバラなのに全部メリットみたいに言うのはおかしいだろ」ってツッコミ

どうせAIにコーディングさせるのだから
・実行が速いことは必須
・メモリ消費が少ないことも必須
それで危険なリスクがあるなら台無しだから
・様々な安全性があることも重要
問題があれば実行前にコンパイルエラーにしてくれるRustがAI時代には最適なプログラミング言語

Rustはクラウドにデプロイするシステムと相性が悪い
Rustを使っているのがクラウドを運営する側しかいないのが答え

>>160
クラウド利用側が支払う料金を少なくするためにRustへ移っていってる現状を見ようよ

トークン利用量が桁違いに増える
大規模なシステムならそれも気にならないだろうけど問題はRustの場合はバグ検出や脆弱性検出の知見がモデル側に十分にないこと

クラウド利用はRustが最も適しているよ

AIが登場しなかったらRsutにもワンチャンあったと思うよ

AIやクラウドと相性が最も良いRustが安全で速くて省メモリ
AIに遅い言語や安全でない言語のコードを出させると負ける
Rustの時代が確定

それな

Mythosが27年物のOpenBSDのバグを
「C/C++のままでバグ修正」してくれている

「書き換えで直す」と言う選択肢はなくなった

今後作られるものはRust製になるね
AI出現により他の言語で作るメリットが全く無くなった

これらの企業団体が既存のC/C++システムのまま継続する
https://i.imgur.com/EmZs6lz.png

>>167
>>168の企業団体のスキルやコードと全く接続していない「正真正銘の新規」なら
言語はC/C++でもRustでも他の言語でもエンジニアの好きにすればよい

>>168
それらRustを使ってる企業や団体だね

>>170
使ってるか無いかで言えば
「1%」位はRustを使ってるかもね

>>170
それも体力のある所が「書き換えで直す」という
一時の風潮に「滑り止め」で便乗しただけ

結果的には必要なかった

君たち今後はAIがコーディングするんだよ
ただしハルシネーションなどゼロには出来ないので安全な言語でないと困る
C/C++だけは新規プロジェクトで絶対に使われない

>>173
ハルシネーションと安全性が直交している事は
他の人に任せる

AIの時代になったからなあ
C/C++の価値がゼロになってしまった
不便でも危険でもプログラマー人口の多さだけがメリットだったけどそのメリットがゼロになってしまった

AIの時代とは

Rust否定派の人って絶対使ってないだろ
こんなに省エネ最高速なものがAIで運用できる。しかも基礎教養があればコードは割と単純
cargoがちょっと重いけどそれだけ

>>171
1%も使ってない

プライベートの面白アプリならそれでいいが仕事であまり自我を出さないほうがいい
速さと可読性で決まるわけではないのでね…
俺はRust大好きだよ

新規プロジェクトでC++使う人はバカしかいない

Rust肯定派の人は、そもそももともとのC++経験が少ない傾向がある。

Rustに投資した人がRustを推し
別の言語に投資した人がその言語を推すのだ

rustとpythonで喧嘩、どこかviとemacsで喧嘩に似てるな

>>181
めっちゃ判ります
C/C++使いこなせない人がRust持ち上げてる傾向があるわ

逆だろ
両方使えるからC++は捨てるべき問題児だとわかる
後発言語だけあってRustが優秀すぎ
Rustを使えない人だけがRust批判をしている

>>185
SNSで「私の好きな言語一覧」の中にRustを書いている人は、JS、Pythonなどは書いてある事が多いが、
C++ が書いてある事が少ないから行っている。

>>186
誤: C++ が書いてある事が少ないから行っている。
正: C++ が書いてある事が少ないから言っている。

>>146
その指示書がある種のプログラミングコードになっている。
何にもコードを書いてないわけではない。

キラキラ系に憧れる職人と職人に憧れるキラキラ系からモテてる言語という印象

なぜRustを学習せずに批判してるんだろ
C++やってるならRustすぐ学習できるだろ
そうすればC++が設計失敗した言語だとわかるよ

>>190
C++を普段使いしている身の上で Rustを学んだが、そこまでは思わなかったが。

学生の頃にCとC++やったけど基本的知識で十分だよ
AIで書いたコード読めて時々自分で修正する程度なんだし

カリカリチューニングするならCとかアセンブリ使うだろう
しらんけど

なお、C++ の設計が好きではない事が有るが、その場合、独自のクラスを定義したり、C 言語風に書いたりしている。

PythonやJSの場合、独自に関数を作ると、もともとある組み込み関数より速度が遅いことが有るが、
C/C++ の場合、組み込み関数は仮に作ってあるだけで、気に入らなければ独自に作っても速度は遅くならない。
そういう言語なんだから、嫌いなクラス、template クラス、嫌いな関数が有るなら、自分で独自なものを
定義して使う設計思想になっている。
それを知らずに他の言語と同様に、用意された関数やクラスを使わないと効率が上がらないから、
気に入らなくても使うしかない、などと考えているなら、それが間違い。

Rust は、習得するのが難しい言語だと私も思います。
例えば、Deserialize なんて言われても全く理解できません。

でも AI プログラミングの時代では、プログラミング言語を学習する必要は少なくなっていると思います。
私は BASIC の経験があるのですが、Python、C/C++、Jav でも何でもよいのですが、プログラミング経験のある人は、システムの要求仕様を考えてテスト方法を準備するなど、基本が分かっています。
このため、Rust を学習することなく、ただも試してみる価値がある言語だと思います。

学習するより先に使ってみたらいいよ
コードは書いてくれるわけだし問題あるコードは書かせた後にチェックしたらいい
Rustなんか触る人はだいたいの言語は学んできてるわけだし微修正から触ってたらすぐ覚える

>>197
使ってみる前に判断する想像力を持っているのが優れたプログラマ。

自演すごくね？

>>196
シリアライズとデシリアライズは特定のプログラミング言語に関係なく基本的な概念だよ

C++撲滅過激派
Rust盲信者
AIコーダー
誰が誰と戦ってるのか

RusTで支払い減らすのは無理だね
トークン使用費と人件費で赤字だから

>>198
リスクないことでそんな判断するのはただの無能でしょ
まず試す行動が取れないって仕事できない奴の典型

>>201
何かが琴線に触れたな

>>203
大きなお世話。自分の事は自分で決める。

>>201
自演かも知れないが自演でも自演じゃなくても
なんか言われるだけで否定されたと思い込むタイプ
賛同する人はわざわざ言わないことが多いのにそういうこともわからない
AIと壁打ちばかりしててそんな風になる人いそうだな

やっぱ持ち上げられすぎてるよなRust

Rustのように読み書きしやすくて速い言語が他にないからでしょ

２桁は言語触ってきたけどRustは今後伸びるよ
スケールなしの限られた資源のサーバーで運用するには最適解
AWSにアホみたいに払ってる企業は導入考えるべき

>>209
「サーバー購入」に出資、250億円の被害か 消費者庁に求める
弁護団によると被害者は全国で約5千人、金額は約250億円に上る。
弁護団は、顧客の紹介で新たな顧客を集める「マルチ商法」の資金集めであり、
サーバー販売業者「クリアースカイ」（京都市）に対する業務停止命令や検察への告発などを消費者庁に求めた。
弁護団によると、同社は2023年9月〜今年2月ごろ、顧客に購入させたサーバー機器を他の会社に貸し出し、
数カ月後に購入金額の110%で顧客から買い戻すとかたり、1口110万円で資金を集めながら、買い戻しをしていないという。
弁護団によると被害者は全国で約5千人、金額は約250億円に上る。
弁護団は、顧客の紹介で新たな顧客を集める「マルチ商法」の資金集めであり、
サーバーに関する事業はほとんどしていなかったとみている。2月から同社の代表者らと連絡が途絶えているという。
弁護団の加藤博太郎弁護士は14日の会見で「サーバー購入が国家戦略に沿うものだとして、著名人や警察との関係をうたって勧誘していた」と指摘。
550万円を出資した女性は「サイバーセキュリティー強化の国策を応援したいと出資した。返金を強く望んでいる」と話した。
騙される方もアホかも試練

今後伸びるっていうかもう伸びてるよ
でも全肯定はできんかな

すげえ自演Rustおじが発狂してる

もはや、時間の問題でほとんどAIが自力で作れる時代になるが、妥当性チェックだけは人間がやる仕事だ。
rustが特別その分野で特別他言語より出来るという事実があれば出せばいいと思うけどな。

Rustのデメリットの一番大きい所がめんどくささだったけどAIがそれを補助してくれてる
あとはGCがないことによる運用的弊害
うちは保守性でGoを少し残して残りはRustって切り替える
まだまだPythonもjavaもCも結局スポットで使うけど今後どんどん変わってくんだろうね

気が狂ってる

そもそも2026年にもなって素の文字列がUTF-8でない言語なんか使ってられない
C++のことだよ

>>150
>Rustと Claudeの親和性高杉て恐ろしくなる

Claude に作ってもらったプログラムがうまく使える理由を Claude に聞いたら、下記の返答がありました。

バグの少なさ ≒ Rust のコンパイラの厳格さ（7割）
＋ Claude の学習による Rust イディオムの理解（2割）
＋ Claude が仕様を型・構造として捉える思考（1割）

## Rust がバグを防ぐ仕組み
**�@ 所有権システム（Ownership）**
**�A 型システムが非常に厳格**
**�B `Result` 型によるエラー処理の強制**
**�C `match` の網羅性チェック**

**ただし、限界もあります**
Claude は、コンパイルを実際に通しているわけではないので、稀に細かい構文ミスや、ロジックの誤りが混入することはあります。

>>216
C++が「素の文字列がUTF-8でない言語」という認識は間違ってる

プリフィクスを付けるか、コンパイラオプションで指定しないとUTF-8にはならないんじゃなかったっけ？　自分の記憶違い？

>>219
マイクロソフトがC#に誘導したいためにわざとCやC++を使いにくくしているのだと俺は理解している。

なお、個人的には、Win32やMFCで、UTF8や、UTF16、UTF32 も使っているが、SJISを使っていることも多い。

>>218
詳しく

>>219,221
そうそう

>>222
C++ の std::string も、MFC の StringA も、マルチバイト文字列(ASCII文字列含む)という以外は、文字コードを規定しておらず、
SJIS でも UTF8 でも使用可能。

>>223
誤: MFC の StringA も
正: MFC の CStringA も

>>217
こういうのが典型的なハルシネーション
自分が欲しい答えを忖度して書いてもらってるのと同じ

>>223
218> C++が「素の文字列がUTF-8でない言語」という認識は間違ってる
223> マルチバイト文字列という以外は、文字コードを規定しておらず、SJIS でも UTF8 でも使用可能。

書いてる本人はこの2文の矛盾に気づかないもんかね?

「素の文字列がUTF-8の言語を使いたい」とでも書けばよかったか?
C++の文字列はUTF-8と規定されていないから、過去のライブラリ流用や文字列操作に余計な気を使うから嫌ね、という含みだったんだが

はいこの話題終わり

「素の文字列」とは、"文字列"の事なら
ソースコードの文字エンコーディングがそのまま
exe/dllのスタティック領域にバイナリ埋め込みされるだけなのでは

素の文字列（文字列リテラル）とstringオブジェクトは別物では。でもって、エンコーディングはプリフィクス依存だったのでは。

>>142

pandasは無茶苦茶に遅い
体感的にpolarsは10倍以上早い
一度polarsを使ったら、2度とpandasには戻れない

L"文字列"ならUTF16LEでバイナリ埋め込みされるね

VCの -utf8オプションはソースコードがutf8エンコーディングの場合に用いる
-utf8オプションなしだとシステム設定の文字コード前提ってだけだよね

>>226
その辺は、Rustでも全く気を付けなくて良い訳ではない。
ファイルを読み込んだような場合やOSのAPIなどを使う場合において。

>>228
L"xxx" だけは、wchar_t の 0 終端文字列になると規定されているが、"xxx" は、マルチバイト文字列であると言うだけで、
encoding は、時と場合によりケリで、なんでもいいといえばなんでもよく、それを扱う関数の解釈次第。

Javaなんかは、内部的な文字列の形式は、UTF16 固定ではあるが、逆に柔軟性のなさがめんどくさかった。
マルチバイト文字列をそのままではある変えず、いちいち、変換関数を呼び出さなくてはならない。
Rustも同様の問題を抱えることであろう。

>>233
誤: マルチバイト文字列をそのままではある変えず、いちいち、変換関数を呼び出さなくてはならない。
正: マルチバイト文字列をそのままでは扱えず、いちいち、変換関数を呼び出さなくてはならない。

関数の解釈次第になるん？　字句解析段階の話なのでは

>>235
「コンパイラの字句解析段階」という意味ならば、コンパイラの種類によってはそういう場合もある。
但し、場合によるかもしれないが、マイクロソフト系のコンパイラは、ソースコードの中の L"xxx" が付かない "xxx" の
形式の文字列リテラルの文字コードを原則として解釈しない傾向がある。

>>233
Rustでは問題ありません

まず言語に関係なく今どき全ての環境をUTF8にするのがベストで今すぐすべきです
やむを得ない例外的な対象のみ読み込み時にUTF8へ変換することでプログラム自体はUTF8だけを扱うべきでしょう

>>237
例えばコンパイラと言うプログラムの場合
SJISで書かれたソースコードを読み込み時にutf-8に変換してコンパイルすれば
問題ない、と言っている?

基地外のせいでますますRust離れが進む

そもそもutf8を含めたunicodeが必要になるのはアジア圏と中東の一部だけだから英語圏の開発者はなかなか気にしてくれない

最近は英語圏も無駄に絵文字で遊んでる🦀

>>241
いいことだ🫪

>>238
当たり前だけどソースコードはUTF8のみ
内部の取り扱いもUTF8のみ
それをSJISなど他で出力するかどうかは出力の変換部分だけ

>>236
誤: マイクロソフト系のコンパイラは、ソースコードの中の L"xxx" が付かない "xxx" の形式の文字列リテラルの文字コードを原則として解釈しない傾向がある。
ｽﾏﾝ。これは撤回。
SJISの場合、\ (円マーク、バックスラッシュ) の文字コードを二バイト文字の文字の一部に使っているので、
コンパイラはちゃんとSJIS専用に解析してる。そうしないと、C言語の \t、\n、\xHH などのエスケープシーケンス
と混同してしまうため。
だから、基本的に、ソースコードの文字列リテラルの中にUTF8とSJISのどちらの
文字コードを入れるかでコンパイラオプションで解析の仕方を変えないといけない。

>>242
何その絵文字😳

>>244
内部データや文字列リテラルはUTF8に統一すればよいだけだ

AI-226 は論理学の学習が足りてないな

C++のプリファクスなしの文字列リテラルのエンコード方式（ordimary literal encoding）について規格上の定義はないので、①コンパイラオプションで指定するエンコード方式、②当該ソースファイルのエンコード方式、③処理系ごとの既定エンコード方式なんかを候補に処理系依存で定められるみたいね。
処理系の仕様を確認すればよいだけだから問題ないという考え方と、既定値はUTF-8に決めといてよという考え方は、両方ありうるところ。個人的にはUTF-8に決まっている（必要があればコンパイラオプションで変更する）方がどちらかといえば良いかなと思うが、大した違いではないという考え方はあるだろう。

こいつほんまにprogrammerなんか？アホ過ぎるだろ

encoding(charset)とlocaleは別なのだ🌱
*A系のAPI関数(MessageBoxA等)や非UTF-8環境linuxのprintfにUTF-8文字列を渡すと文字化けするのだ
だから""の中のエンコーディングはプログラマーが管理しないといけないのだ🌱

男は黙ってeuc

どの言語でも内部データや文字列リテラルはUTF8に統一すればよいだけだ
あとは出力層の最後で実行環境毎に変換するだけの話
実行環境毎にソースコードの文字列リテラルを変えるなんてバカなやつはいない