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

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

Rust使えば無条件でC++より安全って訳じゃないよなあれ
並列処理で同じメモリに値書き込むと簡単に壊れるでしょあれ

Rust使えば無条件に安全って思ってるやつ多くね？
C++をRustに書き換えれば安全ってそのRustで書き換えたコードに誤りがあったら無意味だよね？

>>1
このスレはウソを書き込む釣りスレかね
Rustはメモリ安全だが
C/C++と同じでランタイムGCなんて無い

>>2
Rustは並列処理でも安全
データ競合は起きない

>>3
コードに誤りがあって安全でなければRustコンパイラがコンパイルを通さないのよ
だからRustは安全なのよ

>>4
普段PythonとかJavaのようなランタイムGCのあるメモリ安全の言語でもバグ出してるやつがRust使ったところで普通にバグ出るだろって話な

>>5
コードに誤りがあったら誤り通りのバイナリ吐き出すよ

>>7
データ競合があればコンパイラが通さないのよ

ビルド時間遅すぎて生産性なさすぎ
日本企業にRust使って良いとこなんて一つもない

ビルド一発で完璧なものを作れるGAFAMの天才エンジニアとかが扱う言語だよ

>>6
言語Aでバグ出す人は言語Bでもバグを出す！と主張してることに気付いてる？
それはRustと無関係な話

なおメモリ安全性と速度は両立しない

897: デフォルトの名無しさん 2026/03/14(土) 11:10:38.67 ID:sVkUX/u1
>>885
でも安全性を考えれば
速度と両立があるRustって感じなんか？

898: デフォルトの名無しさん sage 2026/03/14(土) 11:40:47.44 ID:SPLDb608
>>897
NO

ほぼ全てUnsafe 2.19秒
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-9.html

Unsafe控え目 3.24秒
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-7.html

Unsafeなし 3.46秒
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-3.html

別ソース
https://madnight.github.io/benchmarksgame/nbody.html

>>12
愚か者！
第一に、非常に特殊な例外的なものを例に出しても無意味。
第二に、そのunsafeのコードをよく見ろ。CPU依存の_mm256_xxx関数を呼び出しているだけだ。
このケースはunsafeを無くすことができる。
Rustでは安全と速さを両立できる。

ヒープ確保するのがリスクなら組込みたいに最初から固定長で確保しとけばいいだけなんちゃいますのん

>>11
だからC++からRustに書き換えれば完全に安全みたいな捉え方をしてる人が複数人いるけどそうじゃないよなって話

無知なwebエンジニアのワイに教えて
rustってみなさんどこで使ってんの
webAPI？わざわざwasmとかしてんの？

>>15
Rustでコンパイル通すことができれば安全です

>>1
これが原因か
https://www.youtube.com/watch?v=NMN9kUUOR1c

GAFAM含めた全てのIT大手がRust使ってるからな

いま転職活動してるけどrustの求人ってそんなにない印象だぞ
mercari系のユニコーンはGoが多くて、LY、paypay、マネフォあたりはSpringbootかruby on rails
機械学習系のとこはpython

その他C++系の求人では一部rustが歓迎条件に入ってる

GAFAMはGoogle Japanしか見てないけどJavaかC++が多い印象

HQ系では大規模トラフィックの最適化とかしてるからrust置き換えあるのかもしれないけど日本市場だとエンジニアも居ないしC++でいいやとなるのかもしれんな

>>18
正解！
他のゆっくり実況者もあんま変わらんけどね
これとか
https://youtu.be/Vi3xadsStU4?si=ckb6GNv69GGRqyTO

C++をRustに置き換えれば完全に安全って思ってるバカが多い印象
書き換え時にバグが紛れる可能性について全く考慮されてない

>>22
それはRustの問題ではない
元々のC++にもバグがあるかもしれないし別の言語からでも別の言語へでも同様なのでRustとは無関係な話

正しい事実はこれ
Rustへ書き換えることができれば安全になる

海外だとrustの求人はディズニーとか軍事ドローン作ってる防衛産業まであるけどit後進国のこの国じゃむりぽ
ちょっと前に任天堂がコンパイラの改善業務かなんかでrustの求人出してた

海外だと求人は結構ある模様
外資も日本法人は基本カスタマーサポートばっかだししゃあない
https://filtra.io/rust/jobs-report/oct-25
Amazon
Microsoft
Cloudflare
xAI
Apple
Dropbox
Nvidia
Google
SpaceX
GitHub
Mozilla
Woven By Toyota
Discord
Disney
Fastly
Mercedes
Bloomberg
Bun
Toyota Connected
Figma
Astral
KSAT
LINE
Akamai
Meta

>>18
タイトル詐欺やね
>>21
そっちは面白い

>>13
> Rustでは安全と速さを両立できる。
確かめてないだろw

unsafeを無くすためにAIにnightlyのstd::simdで書き替えさせたら2割弱スピードダウンした
AIにその原因を説明させたらちゃんと答えてくれたよ

まあ科学技術計算が特殊でRustの得意分野じゃないと言うならそれで良いよ

>>23
安全にはならない

>>26
おもんねぇよ

>>23
つクラウドフレア

>>23
書き換えるといってもそもそもの構造から発想の転換が必要になることが多い
簡単に書き換えれるようならそれはもともと危険性考慮必要もないほど単純で安全だったコードだろう

それとRustはメモリ安全性を保障してるわけじゃない
あくまでもメモリ安全性という目標のために未定義動作を防ぐことを目的としてるだけ
例えば相互参照や循環参照が発生した場合の有効な解決策を持っていないし何も対策せずにコンパイル通すと実行時にスタックオーバーフロー発生する可能性がある

安全性のためにRustに書き換えるってのは面倒だし難易度も高い話
マルチスレッドのようなより高度なプログラミングが必要になったときにRustの真価が発揮される

Rust板が必要だ

>>31
Rustはデータ競合も含めてメモリ安全性を保証している
Rustが難易度高いと主張するのは初心者だけ

>>27
#[target_feature(enable = "avx2")]
を利用する関数に付ければunsafeで囲わなくても_mm256_XXXを使えるようになったよ

>>33
データ競合をなくすためにクラス構造から再構築しなおさなきゃならなくなる
その前にデータ構造も再構築必要
難易度が高いというのはスキル的な話じゃなく実現コストが高いという意味

それとRustのメモリ安全というのはあくまでも未定義動作を防ぐためのもの
スタックオーバーフローに関しては無力

>>35
>>データ競合をなくすためにクラス構造から再構築しなおさなきゃならなくなる

おい！
元のC++コードにはデータ競合バグがあったのかよ！
Rustの問題ではないな
Rustならデータ競合が起きない

>>34
何だこれ
わざと嘘ついてるのか?

Rustスレでやって盛り上げてあげて

>>38
わかった

>>37
それは何ヶ月か前から使えるようになったな
例えばこうして使っている

#[cfg(target_feature = "avx2")]
#[target_feature(enable = "avx2")]
fn foo() {
　// avx2を使う実装
}

#[cfg(not(target_feature = "avx2"))]
fn foo() {
　// avx2を使わない実装
}

>>35
難しい=難易度上がる
面倒臭い=実現コストが上がる
決して難しい訳じゃないんだよな
ただし後者は日本語で言う(「難しい」を含む場合もある)

まだ言葉足りないか
>>35
難しい=難易度(必要なスキル)上がる
面倒臭い=実現コストが上がる
決して難しい訳じゃないんだよな
ただし後者は日本語で言う(「難しい」を含む場合もある)

わろす
watch?v=hgI_AOjGE38

マジで最近のYouTubeRust持ち上げすぎてね？って思うんだがどう？

最後のあがきってやつだろ

今頃になって持ち上げてるのは周回遅れだから無視でいいよ

>>40
論より証拠だからやってみなさい
https://godbolt.org/z/8fq9T3fYe

>>46
なるほどなぁ

>>12
それはRustでメモリ安全性と速度が両立している証拠
それらのコードの差はベクタ命令をどこまで使うかどうかの差
その違いについてはCでもRustでも同じ話

Zigのほうが好きな人多そう

Zigは少ないスポンサー企業がさらに減ってしまった

ポストC/C++として過去一成功してるってだけで持ち上げられる価値は十分にあると思うよ

ダメだダメだ言いながら「人間側が頑張る」と言うITにあるまじき精神論で何十年使ってきたと思ってんのよ

でも開発者おおいとエコシステム開発の勢いもあるから
rustでいいかなって思っちゃう

linuxカーネル7.1

Cがアホみたいにメモリ周りが危険だからその危険がなくなっただけでも価値があるという話

何事も得意不得意はある
Pythonのメインストリー厶はやっぱPythonが強いわ血眼で最適化されてるから
そこらへんの奴がRust使うより早い

>>56
ぱぱぱwぱいそんwww

C#のサブセットでRustみたいなやつ作りたいわ
UnityのBurstコンパイルみたいに[BurstCompile]って頭につけたメソッドだけクラスなし、GC無しでLLVMにコンパイルできる
もちろんメモリ管理もコンパイラー制御でコンパイルできなくするようなやつ

c#なんてゲームと仕事以外で誰も使ってないやん
主要oss見てみろって
javaとc#なんて見たことない

>>59
StackOverflowがC#なんだが

qiitaとかzennでもpythonの方が速かったって検証あるけどなあ

Python自体は遅いよ
だからこそPythonのライブラリをRustで書く
それを使うと速い

PythonとかRubyは最も遅い部類の言語なのでは。もともと速くあろうという点にはあまり重きを置いていない言語というか。

インタプリタを議論の俎上に出す時点でニワカもいいとこだろw

まぁ結局バイナリにコンパイルしたら速いよなってのは事実だよなC#もBurstコンパイルでネイティブバイナリ吐き出してその部分だけGC無しで実行してるし
PythonのライブラリをRustで書くってのも似たようなもん
BurstはC#オンリーで書けるのが強みか

CPythonはCのくせにクソ遅いCの恥さらし

https://www1.daiwair.jp/qlviewer/e-cast/2509059702scTvDPnFfu/index.html

もう皆Raku使おうぜ

RustのようにIT大手各社が採用したプログラミング言語は今後新たに出てきそうにない

Rust実行速度は速いかもしれんけど、実装時にバグばかり発生してめちゃくちゃ時間かかる
何年も使うようなプログラムじゃないとトータルマイナスな言語じゃね？

それはRustがバグを作り込みやすい言語ということですか
チュートリアル読んだ限りはそうは感じなかったのだけど

>>70
>>実装時にバグばかり発生して

逆だよ
Rustは強い静的型付けによりバグが生じにくい言語
抽象的な記述も使えば更にバグが生じにくくなる言語

他社でメンテはしにくく感じる

Rustの良さの一つは保守性の高さ

Rustは格段に読みやすい
デメリットとしてはcloneやunwrap系が混じるだけ

>>75
cloneがそんなに頻繁に出てくるのは何かおかしい
普通は参照もしくはCopyを使う

>>70
>何年も使うようなプログラムじゃないとトータルマイナスな言語じゃね？
そりゃそうだろ

Rustは清書用
Rustはリファクタリングには向いてない
矛盾してるようだけど矛盾してない

>>76
暗黙のCopyしたくないときはclone使うよ

2024年あたりから打ち捨てられたクレートが激増してる
clapやcronoの時みたいに大問題にはなってないけど数千万ダウンロードとかあっても平気で放棄されててRustのエコシステムには明らかに翳りが見えてきてる

>>76
まずはcloneで動くコードを書こう
デカいデータ丸々複製とかじゃなければほぼ影響はない

>>81
真逆だろ
俺は参照を使えと言ってる
大きなデータは参照
小さなデータはCopy
これらが一番速くて基本
cloneは次善策

速さは今話してませんが

参照を扱えないRust初心者もいるからね
Cのポインタ相当にすぎないから学べば簡単だよ
正確には指す実体が正しく存在することを保証されたポインタが参照
そのために単なるポインタとは異なり参照にはライフタイム注釈がある
それによりコードが分かりやすくなると共に安全にもなる一石二鳥だよ

複おじ読んでるこっちが恥ずかしくなるからもうやめて〜ｗ

>>83
無駄なcloneを避けるのは常識
なんでもcloneが許されるのは習い始めの時だけ

>>86
プロジェクト全体を見たときにそこまでこだわるような問題ではないということ
所有権で困ったらcloneしておいて後から最適化すればいい
参照使うなとは言ってないからね
開発速度のほうが大事だよ

Rc/Arcをcloneならわかるけどデータ自体をcloneするバカはいないだろ
データをcloneしちゃうバカが「開発速度のほうが大事」ってギャグかよ
知能レベル低すぎだろ

>>80
cratesのnamespaceってアカウント毎の階層になってないよね

>>82
参照使ったら文脈変わるやん

>>88
Copy使ってるからcloneしてませんとか言ってるバカも居る

>>88
横からだがcargoやripgrepのソース見てごらんよ
参照が使える場面でもめっちゃcloneしてるから

>>86
>なんでもcloneが許されるのは習い始めの時だけ
これはそう
でもRc/Arc以外のデータを何でもcloneしちゃダメだという素人考えが許されるのも初心者まで
中級者以降はそういう考え方をしない

C/C++でポインタを使ってきたまともなプログラマーならそのまま参照を使える
ポインタを使えない人はcloneに逃げて時間とメモリを浪費してしまう

この会話のレベルの低さから察するに、Rustは素人にとっても平易で読み書きしやすい良い言語だと思う

>>93
そこは全ての言語で共通の話で、
異なる内容のデータに分岐するときは当然クローンして、
同じ内容のデータを保持するときはクローン使ってはダメで参照を使って指し示す。
Rustでも全く同じ。

いや、Rustには型パズルを不必要にややこしくしないようにするためのcloneがある

>>97
そんな無駄なコピーをするのはRustを理解していないアホだけ
多くののケースは参照&Tで済む
そうでないケースもRc<T>など適切な方法がある

>>98
論理のすり替え。

Rustはこうやって議論が盛り上がるくらい人気でいいな

>>97
そこで型パズルなんてものは発生しなくて、
参照よりも元が長生きすればよい、
という誰もがわかる簡単な仕組み。
CPUもメモリも浪費する無意味なクローンは本末転倒。

くっそ早いしメモリも食わないのにRustが気に入らない人って何なんだろ
Goと比べてもGCないしコードも可読性高いし良いことしかなくない？

凡人やAIにWeb領域でRust書かせてもいうほど速くないしメモリ使わないのも効果実感しないしビルド遅いだけの言語だからかな

>>103
Web領域ならRustの独擅場
AWSなどのクラウドやCloudflareなどのCDNといったWeb領域はRustで作られている

>>96
異なる内容のデータに分岐しない場合にもめちゃくちゃcloneしてるという話をしてるんだよ
ripgrepやcargoのソースを見てごらんよ

この辺の感覚はCやC++のポインタでも全く同じなんだけどね
ポインタ使いこなせないやつほどポインタを使うことに無駄に執着する

>>105
C/C++/Rustいずれにも関わらず
同一内容のまま用いるデータをcloneすることは何一つメリットがない

結論から言うとその感覚、**「だいたい正解」**です。

前提としてポインタやプリミティブな数値ならclone/copyするのは当たり前
スライスなどのファットポインタやスマートポインタなどもclone/copyして使うのが当たり前
だから議論の対象は十分に大きなデータそのものでいいんだよね？
内容を変更するわけでもなくcloneすることはありえないでしょ？

むしろRustって遅くね？

cとかに苦手意識あってやってない人多いから少ない構造体とかだと参照でインスタンス作ると遅くなるて結構知らん人いそう

>>108
あえてcloneすることでメモリアクセスの局所性を上げるテクニック

>>111
それはムーブでいい
もしくは最初から局所的に置けばいい
cloneは必要ないね

20年前の常識をアップデートできてないんだろう

#[derive(Copy)] は使っちゃダメ絶対！

絶対なんてこの世には存在しないけどね

>>114
数値などをラップした型はCopy実装して元の型と同じ利便性を持たせることが一般的
ちなみにVecなどヒープを用いている型はそもそもCopyできないからそれをラップしてもCopyできない

>>106
>同一内容のまま用いるデータをcloneすることは何一つメリットがない
それは君がまだ初心者だからメリットを理解できていないだけ
中上級者が書いてるripgrepやcargoのソースを見てごらんよ

Arcのcloneだけだろ
無駄なcloneは無意味だから行われていない

ripgrepがー！
cargoがー！！

骨格検出をpythonからrustに変えたらCPUやメモリ効率は良くなった
でも速度は少し遅くなった

安全性があっても速度がないとねぇ…

使ってるのはどっちもC++のopenCVだけどpythonのが早いねえ
最新の分野は人が多い言語の方が最適化されてるから結局早いんだよね

rustは最適化したら最強なのかもしれないけど生産性がなさすぎてライブラリの保守状態がカオスっぽいし

GAFAMレベルの天才人材や資金が揃ってないと使用を許されない言語だと思うね

>>120
Pythonは遅い言語
C/C++/Rustが速い

でも実際に計測してpythonの方が速いしなあ
普通の企業ならRustで最適化するコストよりマシン自体のスペックを上げたほうが費用対効果良いしなあ

最適化なんか究めなくても普通にRustで書けば速い
遅くなりようがない

Rust はポピュラーな言語になっているようで、AI(ChatGPT、Gemini、Claude) のプログラミング言語の知力は優れたものです。
私は Rust について学んだことはないのですが、AI のお陰で「機能する」プログラムを書けました。
https://makoto-watanabe.main.jp/Rust.html
IDE は RustRover を無料で個人利用しています。

でも事実として遅くなってるし…　

AIとの相性も微妙だと思う
ビルドが遅いから実行結果が遅いぞと勝手にあれこれコマンドで調査してプロセスロックさせての無限ループ繰り返すから自分でやって結果渡さないといけないし

ここでrustすげーって言っている人は実際に業務でRustを扱ってみたことがある人なんだろうか？

全否定しているわけではなくて
ちゃんと書いたら速くなるんだろうなって予感はしているんだけどね

そこまでのリソース投下を普通の企業が許すイメージはないけど

>>120
>>pythonからrustに変えたらCPUやメモリ効率は良くなった

そりゃそうだ

>>でも速度は少し遅くなった

え！？
それはありえない
何か重大なミスかあるいは初歩的なミスか勘違いをしてるのだろう

リリースビルドしてないとかそんなんだろ

ライブラリ叩くだけだったらrust使わないでいいやろ
ライブラリを作るならまだわかるけど用途を間違ってる

>>128
単純にRustはSIMDだからSIMD化するときの時間がかかってるだけでは？

>>131
もともとほとんどの処理がNumpyやPandas2だっただけなら
下手なネイティブ化だと速度低下するわな

複おじが必死過ぎて笑えるｗ

>>132
何言ってんだこいつ？
SIMDって何かわかってる？

SIMD化するための準備処理に時間がかかってるって言いたいだけなんだけど伝わらなかったか

NumpyもPandas2もSIMDくらい使ってると思うけど

ま、たま〜に数回走らせるだけのデータ処理のために
雑で下手くそなネイティブプログラム組んでも
組む時間も実行時間も増えるだけって話では

numpyはともかくpandasはクソ遅いよ
何故かCライブラリだから速いって言う層が居るけど設計思想次第

NumpyとかRustからも使えるわけでそこに問題は生じない

>>137
pandasはv1とv2で別物レベルの速さ

PythonはCで描かれてるからRustよりも速いに決まってるだろ

>>139
そのv2も遅い
調べたらv3も出てたが遅い
これは別にクソコード書いてるとかCが遅いとか言う訳じゃなく、データサイエンティストのユースケースに合う対話型や汎用性、多機能、互換性などを速度より優先しているから

Pandasと比べてPolarsのほうが速いとも聞くけど、Pandasのv2とかv3と比べてどっちが速いんだろ。

>>142
必要になったときに自分で検証すればいいんじゃない？

Polars一人勝ち

polarsと比較したら、古くて参考資料が豊富にあるという以外pandasを使う利点なんかゼロだぞ

以前にも書きましたが、AI のプログラミング言語理解は優れたものです。
下記の仕様を Claude に伝えたところ、たちどころに動作するプログラムを教えてくれました。

******************************
Rust でデータ照合のプログラムを作ってください。
商社が、受けとった注文データを，品目マスタと照合して仕入先・品目コード別に集約するものです。
具体的には下記の内容です。

１．ユーザから受けた注文リスト(50,000件) 「Orders.csv」を、読み込みます。
注文リストの文字コードは UTF-8 で、項目は、品目コード,数量
２．「品目マスタ(15,000件) ItemMaster.csv」を、読み込みます。
品目マスタの文字コードは UTF-8 で、項目は、品目コード,仕入先,単価,重量
３．2つのファイル内容を「品目コード」で照合して、「仕入先」別に、「品目コード」毎に数量をまとめて、金額を合計した「集計リスト」を作成します。
「集計リスト(OrderSorting.csv)」としてファイル出力します。
集計リストの文字コードは UTF-8 で、項目は、仕入先,品目コード,数量合計,金額合計
４．注文リストで品目マスタに存在しないオーダは、OrderError.csv として、品目マスタ未照合分につい未照合全行を、品目コード,数量を出力してください。
******************************

上の仕様には画面表示について言及していないのですが、十全な内容が画面に表示されるプログラムでした。
また、テスト・データを生成するスクリプトまで含まれていました。
https://makoto-watanabe.main.jp/Rust.html#order_sorting

Rust構造体や HashMap など知らない私でも、仕様さえ伝えれば、 50,000 x 15,000 を、エラー出力を含めて 1秒で完了する Rust プログラムができました。
AI の登場で、プログラム言語学習の在り方が激変するでしょうね。

↑AIにメモリを安全に作ってって言えばRustいらないじゃん

Rustを知らない人なのだから
その程度の処理はPythonにしておくのが無難では

pythonなら300msで終わる

Rustと Claudeの親和性高杉て恐ろしくなる
Pythonより速度が遅いとか言ってる人ってビルドが遅いって話？実行速度は速いしリソースも食わない
どう比較したらPythonより遅くなるんだって

驚き屋さん。。。

AIコーディングの時代になった
速くてメモリ消費量も少なく安全なRustのコードをAIに出力してもらうことが最善

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に統一すればよいだけだ
あとは出力層の最後で実行環境毎に変換するだけの話
実行環境毎にソースコードの文字列リテラルを変えるなんてバカなやつはいない

仕様を自由に策定できる言語なら好きにすればいいだろう
C/C++は環境依存の仕様は言語仕様には取り込まない方針を取っているだけで

ここ見てると罵詈雑言書いてるだけのバカより技術的に抜けてても語ってる奴の方がええな
叩くだけなら誰でも書ける
>>252みたいなのが良いね。当たり前のことをわざわざ書いてあげてる優しさって大事だけど日本語コミュニティって何か煽り多いんだよな

>>252
ソースコードの文字符号をUTF8にした場合、ソースコードの肥大化の問題がある。

話は違いますが、Rust は変数名や関数名に日本語(UTF-8 3〜8バイト？)を使えます！
漢字名を使うと、日本人にとって飛躍的に可読性の良いコードになります！！

utf-8で8バイトとか異体字使う気満々ですやん

struct 渡邉;

とか出てきたら可読性良くても泣くんだが

異体字セレクタでbrainfuck実装したらwhitespaceより可読性やばそうだな
邉だと8種類以上あるからいける

問題は起きない
自分たちが使う場合はそんな問題が起きる使い方をしない
万が一起きた場合や難読化のため意図的に使われている場合でも字句解析で対応付けが明白になるため問題は生じない

ソースコードの肥大化っていっても、非ASCII文字をつかう割合なんてそんなに多くないのでは。

fn main() {
let x = 名前::渡邉(123);
}

mod 名前 {
struct 渡邊(i32);
}

異字体を間違えても似た名前があると指摘してくれた

error[E0425]: cannot find function `渡邉` in module `名前`
--> src/main.rs:2:15
|
2 | let x = 名前::渡邉(123);
| ^^^^
...
6 | struct 渡邊(i32);
| ----------------- similarly named tuple struct `渡邊` defined here
|
help: a tuple struct with a similar name exists
|
2 - let x = 名前::渡邉(123);
2 + let x = 名前::渡邊(123);

>>260
日本語のコメントが英文字のコード本体より多くなることが有る。

日本の文字はクレート上げてpublishするときの邪魔だからほぼ使わんし
ほんとに日本語コメント書いてる人ってあんま見かけないけどな
フロントエンド側のリソースとかの話をしてるのかもしれんけど

長々とコメントを書いても良いなら、そもそもソースコードのサイズを神経質に気にする状況でもないような気がするけど。

Linuxジャパンωωω=2πf

>>264
コメントは必要なものであって、飾りではなく、保守性を考えれば省略は出来ない。
だから、その論理はおかしい。

出来る限りバイト数を減らすためにSJISにして仮名は半角1バイトを使うのが基本
ユニコードは時代遅れだ

>>267
SJISはいいと思うが、半角カナは使うべきではないと聞いたから使ってない。

みんなさんはメモリ安心安全のための宇宙線対策はちゃんとやってますか？

>>268
半角カナを使うメリットのために問題点の多いSJISを使うんだろ
半角カナを使わないならば問題が起きないEUC-JPを使うべきだ

>>270
EUCにはmsvcが対応して無い気がするが。

>>270
半角カナを使わないといけない状況なんてあるの？

>>272
SJISが文字化けする欠陥品になった理由は半角カナを使うため
もし半角カナを使わないならばその問題のないEUCを使え

SJISの最大の欠点は、\ の文字コードを 2バイト文字の一部にも使っていること。
\ は、C言語の文字列リテラルで特別扱いされ、単純に1バイト単位でscanされてしまうので
コンパイラがSJISとしてちゃんとパースしないと問題が起きる。

だから半角カナを使うつもりがないならSJISを今すぐ捨てろ
SJISは半角カナを使うためにそのバックスラッシュ欠陥を抱えている
半角カナを使わない人はEUC-JPを使え

時代はEBCDIC

>>275
そんな理由だけでSJISが使われている訳ではない。EUC-JPにはコンパイラが対応してない。

>>277
欠点だらけのSJISが使われている唯一の理由は半角カナが使えるからだよ
半角カナを使わない人にとってSJISは何一つ魅力が全くない

半角カナ自体はUnicodeにも移植されてるから半角カナが1バイトだからだな
古いシステムのデータベースの名残り

バイト幅と文字幅が一致するから印刷系でもよく使われてた

半角カナ使わないのにSJIS使ってる人はバカだよな

euc使うならUnicodeでいいよな

極一部の例外を除いて現在はローカルファイルからネット上のやりとりまでUTF8で統一された
したがってプログラミング言語の文字列リテラルも文字列処理もUTF8で行なうことが望ましい
極一部の例外に対してのみ入出力の段階でUTF8との変換を行なう
Rustならencoding_rsを用いる

encoding_rs は、現時点で UTF16 に対応できないので要注意です。

let (encoded_bytes, _, _) = UTF_16LE.encode(content);
BOM を付けて `encoding_rs` でファイル保存すると、「BOMがある(UTF-16 ？) のに、その後に続く中身は UTF-8 で書き込まれている」という、「看板と中身が違う」状態になります。
(-_-;)

文字列を UTF-16 のイテレータに変換し、u16 を u8 (LE) に分解して書き込むと UTF-16 でファイル保存できます。
for u16_char in content.encode_utf16() {
// u16 を リトルエンディアンのバイト列 [u8; 2] に変換
let bytes = u16_char.to_le_bytes();
writer.write_all(&bytes)?;
}

みんながやってるから仕方なく使ってるけど
ライブラリ周りがちょっとなー

>>285
たしかに

>>285
具体的に言おうよ
デバッグプリントとかコレクションまで使いにくいわけ？

>>287
具体的にいう義務は無い。気づかない人の能力が低いわけだから。

>>288
[例]
A「あそこの店の料理、なんか今一だよね」
B「そうだよね」
店「具体的に言おうよ。何の調味料が何%不足して、何が何%多すぎると思うわけ？」
俺「それが分からんのは、あんたの料理の腕前不足でんな」

俺的にはライブラリの成熟度とエタっちゃうリスクが気になるな

そろそろ結論出た？
Rustは持ち上げられてんの？
wasmでrustって流行りそう？

論文読めっつってるだろ。

https://teamjces.github.io/www/paper/2026-03-31-compile.pdf

今の時代に書き味とかわけのわからない主張する人がいるけど好きな言語使えばいい
Rustのメモリ、コスパの良さが個人的には気に入ったが流行らない方が相対的な強みを持つからクライアントワークで使うメリットは少ないな

>>289
お前は誰だよ

>>294
コスパで考えたらRustよりCじゃないか？
最適化されてるってのもあるし筆が進む

確かにRustはC並に速いコードは書けてもC並に小さいコードは書けないことが少なからずあるな。

理屈的にはCだけどAI使っても限定的だよ
極限まで突き詰めればCが勝つこともあるけどjsonとか扱えないしコード量増えて結局同じぐらいになるでしょ？Cloudrunに動画とか任せる時に入れておくぐらいかな
今でもOS作るような人ならCかもだけどWin時代は地獄だったからやる気にならないな

へーC言語ってjson扱えないんだ

そもそもCをAI使って書くのは開発側のトークンの無駄遣いでしょ
コスパが悪すぎる

Cでバリバリ高速化したい人はjson観たいな超絶非効率なデータ構造は使わんよ

それだとrustがバカみたいじゃｎ

>>300
シリアライズとデシリアライズの概念すら知らない無知でワロタ

>>301
Rustはきちんと対応していて効率よく扱える

RustはCの上位互換とは言わないけど組み込み、OS以外なら結局Rustに集約する

>>304
RustのあるオブジェクトをCやC++やアセンブラで書ければ何でもできるわけだけどLLVMってそういうのどうするの？

C使いたい開発でJSONなんて扱うの？

>>306
C言語はまともに使える分野が狭すぎて敗北した
RustはJSON扱うWebサーバーサイドも楽に書けて非同期マルチタスクで実行効率も良いだけでなく
インラインアセンブリも対応していてC言語の領域もカバーできる

>>307
素人が使うことを想定して作られた言語じゃないからそこは仕方がないのでは
そもそもウェブでCなんて使わなくない？

>>308
確かに素人向けのC言語は非同期タスクも扱えないもんね
無理やりに同等のことをやらせようとしてもC言語では書きにくく分かり辛い酷いコードになってしまう
でもC言語は素人向けだからそんな高度なことは出来なくてもいいもんね

ド素人ワイはじめてのプログラミングはTauriからはいったけどCはさっぱりわからん

Rustすごい！を書き込んでる人がころころIDを変えるのなんでなの？

>>311
一人だけでなく複数人がRustすごい！と書いてるかのように見せたいからだろ
このスレではある意味一番有名な「複製おじさん(通称:複おじ)」だから覚えておくといいよ

複おじ煽りしてるの一人だけに見える

複おじと複おじ煽りする人との2人の異常者がいるって感じ?

投影同一視で複おじには自分を煽ってくるヤツも1人がID変えて書き込んでると思ってそう

>>300
jsonは内部データの型ではなくて外部とのデータ交換用の形式だよ
CでもRustでも内部データとしては構造体などに格納して扱う
そして通信時やファイル格納時にjson形式に逐次化するんだよ

投影同一視で複おじ煽りには複おじという1人がID変えて書き込んでると思ってそう

>>316
そういう使い方ならCでもjson使えるぞ

>>318
そういう使い方しかないよ
json形式の文字列のまま内部データとして格納するなんてありえない
例えばcsv形式のデータもそのまま文字列で扱うなんてありえないでしょ

ﾜｯﾁｮｲありで次スレが立った途端に特定のパターンの書き込みがぱったり途絶えるのは1人じゃないと考えるほうが無理がある

厚切りJSON

JavaScriptのせがれ

ケツカンマという言葉を流行らせた元凶

Rust は学習難易度が高い言語です。
しかし、Claude のお陰で、学習しなくても利用できる環境になったので、Rust はよりポピュラーに普及してゆくでしょう。
勿論、Rust を学習している人は AI が提示するコードよりも保守性を含めて高度なプログラムを作れることは言うまでもありません。

最近はAIコストが高騰してきてるからトークンコストが重いRustなんて費用対効果悪いから使わないよ

ほとんどの人はVecがあればダブルリンクリストが要らないことを納得できてないぞ。

日本はペシマイゼーション技術の国だからな。

>>326
CPUから見てメモリのアクセス速度がキャッシュを外す時とL1キャッシュに乗る時で数百倍も速度差あるからなあ
ほとんどの用途はVecでシーケンシャルアクセスが勝ってしまう

>>328
DDR-SDRAMなどの外部メモリーからの読み込みにかかる時間は12(ns)位だから、3GHzの場合で、36クロック位。
しかし、ループの中で意味のある処理をする場合、1回のループにかかる時間が最低で5クロックくらい必要だから、
5クロックが40クロックになることになるから、キャッシュミスが100%連続したとしても8倍くらいということになる。

間違ってるぞ
実際に計測すると桁違いに時間かかる

また始まってるなｗ

>>330
ちゃんと、x86 の WBINVD 命令(マシン語)を使って実測した？

な？ダブルリンクリストが要らなくなった理由をキャッシュ持ち出さなきゃ理解できないw

>>329
>DDR-SDRAMなどの外部メモリーからの読み込みにかかる時間は12(ns)位だから、
メモリスペック(例えばDDR5-6000 CL36)のlatencyが12nsというのはCAS latencyであってCPUがメインメモリーからデータを読み込むのにかかる時間ではない

これ何回目だよ

キモじじいというのはlinked list大好き算数100点おじさんかと思ってた

いっかい30年くらい黙れや。

＞最近はAIコストが高騰してきてるからトークンコストが重いRustなんて費用対効果悪いから使わないよ
こいつ使ってないだろ

トークンは重いだろ

アセンブラを知ってる人間がニヤニヤしながらイテレータを選ぶ。Rustの醍醐味だよな。

簡潔に書けるRustはトークン的には有利で消費も少ない

キータ信用してないとか言われたら終わりだけど、一応の根拠
https://qiita.com/ebasuke0226/items/a8adb4bc3000c5204c8d

結果（MAX_ATTEMPTS=3）
Python

成功率: 0.5
平均試行: 2回
コスト: 約 $0.009 / 実行
Rust

成功率: 0.0
平均試行: 3回（上限到達）
コスト: 約 $0.151 / 実行
結果（MAX_ATTEMPTS=5）
Python

成功率: 0.5（改善なし）
平均試行: 3回
コスト: 約 $0.016 / 実行
Rust

成功率: 0.0（改善なし）
平均試行: 5回（上限到達）
コスト: 約 $0.223 / 実行

比較から間違っていて酷い記事だな

>>339
イテレータとアセンブラは何の関連もないよ
例えばファイルから1行ずつ取り出すイテレータ
例えば円周率を計算して各桁の値を次々と返すイテレータ
例えば5chで新たな書き込まれたレスを次々と返すイテレータ

>>344
つまりどのイテレータも同じ速度か？サル。

意味はだいたいこうです。
「アセンブラまで分かっている低レイヤー寄りの人間が、Rustでは“手書きループ”ではなく“イテレータ”をニヤニヤしながら選ぶ。それこそRustの面白さ／良さだよな」
ここで言っているポイントは、Rustのイテレータは高級な書き方に見えるのに、コンパイラ最適化でかなり効率的な機械語に落ちることが多い、という話です。
たとえば普通は、
for x in xs {
sum += x;
}
みたいなループのほうが低レベルで速そうに見えます。一方で、
let sum: i32 = xs.iter().map(|x| x * 2).sum();
みたいなイテレータチェーンは抽象的で遅そうに見える。
でもRustでは、イテレータやクロージャがインライン化され、不要な中間オブジェクトが消え、最終的に手書きループと同等か、それに近い機械語になることがよくあります。だからアセンブラを読める人ほど「これ、抽象的に書いてるのにちゃんと良いコードに落ちるんだよな」と分かったうえで、あえてイテレータを選んでニヤニヤする、というニュアンスです。
「醍醐味」は、Rustが
安全性・抽象化・表現力 と 低レベル性能・制御性 をかなり高いレベルで両立している、というところを指しています。
かなり意訳すると、
> Rustは、低レイヤーを分かっている人ほど、安心して高級な書き方を選べるのが楽しいよな。
という感じです。

「0から9まで回せ」と「10回ループなら何でもいい」が同じ速度か？サル。

「0から9まで回せ」よりも「9から0まで回せ」の方が速いんだよ。前者は9かどうかの判定を10回行うのに対し、後者は0かどうかの判定を10回行うからだ。9かどうかの判定よりも0かどうかの判定の方が速いんだよ。サルにはわからないけどな。

>>346
それはスライスの話だよ
イテレータの話は>>344の例を指すよ

例えばグローバル変数が3つとグローバル関数を4つ含んだCのファイル。それとまったく互換の高速版をアセンブラのファイルとして書くことはできる。

同じことはRustでできるかな？任意のRustのファイルと互換のファイルをCやC++やアセンブラで書くことはできるかな？

ちなみにインラインアセンブラはサル用の道具だ。人間はファイル丸ごと、ライブラリ丸ごとアセンブラで書く。

ファイルを分ける弊害が大きいためインラインアセンブラが生まれた経緯も知らない若造かね

>>350
時代遅れのお爺さんが暴れてるな
グローバル変数は過去の遺物で、名前空間の衝突汚染や、値アクセスの衝突競合など害悪の象徴

>>35
じゃあCならCのファイルは分割しないのか？RustならRustのファイルは分割しないのか？

>>352
じゃあCならCのファイルは分割しないのか？RustならRustのファイルは分割しないのか？

>>353
CのABIがそれをサポートしなくなったとは聞かんぞ？

気持ち悪いじじいさんは初心者だよ
もちろんRustはCのABIをサポートしているよ

モダンを学べ
過度な最適化より大事なものがある

ならばなんでRustだ？

iterをaddressingと同一視あるいは勘違いしてるのかな

サルは>>348を読め。

最適化が進んでどっちでも変わらない

ループ内でカウンタを実際的に使用する/しないの違いは最適化できない。

>>348
Rustのコンパイラが馬鹿だからそういうことが起こるんじゃね？

>>348
昔はね

note.comなんて要らなくなるからな。
https://twitter.com/i/status/2049584636905603520
https://twitter.com/thejimwatkins

>>334
あなたの主張は間違ってはいない。
1. しかし、そのデータがなかなか見つからない。
2. (本当のLatency) = (CAN Latency) + (Memory Controller による遅延時間) + (CPU による遅延時間)
の内、右辺の第一項はDRAMの遅さに由来するので高速化が難しいが、
右辺の第二項、第三項は高速化を施しやすく、第一項に比べて、小さいと予想される。
3. それ故に、CAS Latency がおおよその目安として採用する価値がある。

>>367
誤: (本当のLatency) = (CAN Latency) + (Memory Controller による遅延時間) + (CPU による遅延時間)
正: (本当のLatency) = (CAS Latency) + (Memory Controller による遅延時間) + (CPU による遅延時間)

写像程度のプログラムしか作ったことないんだろうなー。

>>367
念のため、Gemini(AI) に聞いてみたら、
結論から申し上げますと、現代の一般的なx86系CPU（Intel Core iシリーズやAMD Ryzenなど）において、
ご質問の「残りの遅延時間」は合計で 40ns 〜 80ns 程度 になるのが一般的です。
- CAS Latency：約 12ns
- その他の遅延：約 50ns 〜 80ns
- 合計（実測値に近い値）：約 60ns 〜 100ns
とのことだった。つまり、
CAS Letency より、 (Memory Controller による遅延時間) + (CPU による遅延時間)
のような部分の方が大きいと答えてきた。
だったら、自作PC用のDDR4-SDRAMなどで、CL 値が書いてあって、それが小さいとかなり値段が高くなるのはなんだったんだ。

誰にでもわかる知識なんて求めてないし本人も知らないんだろう。

先生！じゃあVecDequeはどうですか？2分木やハッシュや集合はどうですか？ほんとに知ってるんですか？

>>364
キモじじいはC言語の話をしてる
Rustを知らない

いや、キモじじいはLispの話をしてる。お前らはLispを知らない。

ーーーー

鍵となるコンセプトは『文法としてのインライン関数』です。ifは引数を3つ取ります。条件式とthen節とelse節です。then節とelse節はインライン関数として与えられます。if自身もインライン関数として記述されます。それはその場に展開されることによって制御構造のように振る舞うのです。

RubyやSmalltalkのような言語はコードブロックを引数として渡す時に本物のクロージャを用いますがそういった際にインラインクロージャが使えると便利です。コンパイル戦略としてはJavaのバイトコードに落とすようなものを想像しています。このインライン化を自動で行い、さらに仕様化するにあたって、それは ((lambda ...)) の形をしているのではないかと考え、それを First Lambda と呼びました。

https://mevius.5ch.io/test/read.cgi/tech/1531587928/736
なんだこいつか

>誰にでもわかる知識なんて求めてないし本人も知らないんだろう。
特に最近AIの答えコピペする香具師が増えたがほんとに迷惑

AIのほうが賢いからね

ClaudeOpusにほぼ書かせてるけど間違い多いからローカルなら自己満足でいいけどビジネス用途の本番は使えないとわかる
でもRustを素人が初めても導入が早いしテストで補完してけばロジックもコードも学びながら進められる
他の言語とか本業経験ありでアーキテクチャの理解があるならAIファーストで初めてついて行って問題はないね

最近は AI にコードを書いてもらって、私がテストデータで検証して、不具合をまた AI に修正してもらうことを繰り返しています。
AI に使われている感じがして、必ずしも良い気がしません。

>>379
検証するのが使う側だけど

>>379
自分でコードしてAIにはテストしてもらえばよいのでは

>>379
ん～テストもAIに書かせたら？

RustとAIの相性悪すぎ

>>383
AIとの相性ならtypescriptかpythonだと思う
学習量がダンチだから

>>383
具体的に？確かにミスはそれなりにあるけどプロンプト工夫したら防げるだろ

>>383
むしろRustとAIの相性良いだろ
実行時エラーを最も少なくしてくれるプログラミング言語

全体の整合が取れないとコンパイル通らないからファイルが増えると大変そう

逆に不整合を含む状態で動いていいのかって問題はあるけど
AIで開発するレベルだとコンテクスト内の整合性だけで十分なのかもしれない

> ファイルが増えると大変

サル。

>>386
言語とクレート達が発展途上なので変化が多いのとAIに食わせるコード資産が少ない
実行時エラーが無くてもコンパイル時エラーは普通に出すし修整ループでコストも高い

相性云々はこれまで学習曲線ガーって言われてたのが無くなってRustそのものの利点だけを押し出せるところじゃないかな

実行時エラーが残る言語なんて修整コストが高すぎて使っていられないだろ

>>389
普通に cargo watchさせてコンパイルエラーだしたら修正って.claudeとかに書いておけばよくない？
少なくともエラーがある状態では止まらない。N+1みたいなものや重複部分は出たりするがそれは指示が悪い

このスレには不適だと分かっていますが、AI Gemini が興味深い回答をしたのでご紹介します。

******************
私の質問：
あなたはどうして、論理的に因果関係の流れに従って論述返答ができるのですか？
知識の羅列だけでない所が賢すぎて不思議です。
世の中では、「AI は、言葉の前後関係を統計的・確率的に処理して返答を作成している」と言われています。
しかし私は、あなたにはもっと本質的、構造的に思考する能力(プロセス)が有ると思っています。
教えて下さい。
******************
これに対して Gemini は長考した後、

******************
Gemini：
私は大規模言語モデルとしてまだ学習中です。そちらについては、必要な情報や機能がないため、すみませんがお手伝いできません。

******************
私の質問が Gemini の守秘部分に該当するのかもしれません。

>>392
嘘ついてる。騙されないように

>>392
Geminiに嫌われていたりして？
ログインしない起動したてのセッションだと冗長に答えてくれた

Microsoft Edit 2.0
https://github.com/microsoft/edit/releases
ソースコードが公開されているので、自分でコンパイルできます。

edlinωωω

>>395
今からMicrosoft Editを使う理由ってなんだろう

>>395
会社の命令で無理やりRustで作らされる作者が愚痴ってたよな

>>397
Windows環境ならシンプルで軽量なエディタとして需要はあるでしょ

高度で軽量なZedあるしeditは需要ないかな

>>400
Zedは全く比較対象にならない
コードエディタとして軽量でもeditと比べたら圧倒的に多機能で重いエディタ
editはメモ帳やnanoに近いから

ほなNVim使うか…

脳死でVS使ってるんだけど
駄目かなぁ

色々使ったけどIDEとして使うならVSでいいよ
AI使うならIDEは邪魔

Claude に依頼して、下記仕様で「数独ソルバー」を作ってもらいました。
https://makoto-watanabe.main.jp/Rust.html#SudokuSolver
私は、昔 VBA で数独ソルバーを作ったことがありますが、私の Excelマクロで解けない問題を、この Rust バージョンは瞬時に解決してくれました。

そもそも「数独」は、一つ一つ頭で考えて答えることを楽しむゲームです。
私はマクロ作るのに 3日も費やしましたが、アルゴリズムを考えて実装することで楽しめました。
AI に頼んで出来たプログラムは、高性能ですが内容を理解できなくて楽しめませんでした。

****************
　Rust で、数独(Number Place)の問題を解答するプログラム SudokuSolver を作ってください。
　プログラムは、問題のテキスト・ファイルを読んで、1問ずつ処理していきます。
　まず問題で与えられた数値を 9×9 の正方形の枠に表示します。
　この問題を解決して、結果をこの枠に、問題の数値とは別の色の文字で表示してください。
　数独の問題の解決は、 9×9 の正方形の全ての枠に数値が入った状態をいいます。
　この問題の処理時間を合わせて表示して一旦中断します。
　ユーザが Enter キーを押すと、次の問題について同様に処理を繰り返します。

　数独の問題は、SudokuData.txt というファイル名で、SudokuSolver.exe と同じフォルダに登録されています。
　SudokuData.txt の内容は下記のように 1問が、1行27桁の数値が3行並んだ形式です。
　数値「0」は、枠の空白部分になります。
　問題と次の問題の間には、1行の空白行があります。
****************
080000700200300008000006010
092750600030009000000400030
001500000005210060000008050

500000300020100070008000009
040007000000821000000600010
300000800060004020009000005

ソルバーは単なる総当たりだから人間でもAIでもバカでもできるぞ
バックトラックさせるのも無数にコードが落ちてるから楽勝
そんなソルバーで数独の答えが分かっても何にも面白味がない
人間が普通に考えて分かる解き方で次に判明する数字とそのために使う手法と手順を示すプログラ厶を作るならまだ意味があるが

「数独は商品名」厨が来るどー

人間が数独を解くと
ある局面で判明する数字は一部だけに限られる
ところがソルバーが解くと全てが判明する
人間が「この数独の問題この局面まで進んだけどここからどうすればいいの？」に対してソルバーは役立たない

>>408
それは君の使ってる特定のソルバーの問題であってソルバー全体の問題ではない
そんなこともわからんのかｗ

AIで直接機械語吐かせろってのと同じ次元の発想

マルチポスト：俺様乱数
https://github.com/teamjces/www/blob/main/rand.rs