Rust part36

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

公式ドキュメント
https://www.rust-lang.org/learn

Web上の実行環境
https://play.rust-lang.org

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part35
https://mevius.5ch.io/test/read.cgi/tech/1774514307/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

Rustってネットで持ち上げられすぎてね？
https://mevius.5ch.io/test/read.cgi/tech/1774264073/
排斥すべきゴミ言語 C++ Rust 他
https://mevius.5ch.io/test/read.cgi/tech/1643696741/
結局C++とRustってどっちが良いの？ 9traits
https://mevius.5ch.io/test/read.cgi/tech/1701997063/
Rustアンチスレ
https://mevius.5ch.io/test/read.cgi/tech/1509028624/
競プロにおいてのRust
https://mevius.5ch.io/test/read.cgi/tech/1663352373/
Rust(unsafe) vs C
https://mevius.5ch.io/test/read.cgi/tech/1646151892/
C/C++のソースをRustへ全力で置き換えるスレ
https://mevius.5ch.io/test/read.cgi/tech/1681777958/
Rust vs Go
https://mevius.5ch.io/test/read.cgi/tech/1654019126/
そんなにRust,Rust言うならゲームエンジンでも
https://mevius.5ch.io/test/read.cgi/tech/1678619820/

このスレって>>980が次スレ立てるって原則ほぼ守られてないよね

>>1
O2

Announcing Rust 1.96.0 | Rust Blog
https://blog.rust-lang.org/2026/05/28/Rust-1.96.0/

プログラマ的には原則なんて守るものじゃないからな

プログラマ的には自動でスレ立てたい

スレ速すぎ。
だから自動などという要求が出る。

自動化はまずPythonで作ってそれからRustで作り直せばいいじゃん

こんなにスレの勢いあると言語としても一番人気なんじゃないかって思えてくるな

長期的に強い
GAFAMのバックアップがある
AIと相性がいい

当然だよなあ

満を持してassert_matches追加
最初から入れとけ

今のRustで、これないのおかしいやろって他にもある？

Azure, GCPのサポート

>>13
人気とシェア？Rust好きなんだけどな

Rust++

Rust + Flutter

スクリプト機能、はrust-scriptがあるか、
対話モード？もevcxrとかあるか

今時ちょっとしたコード辺を書いて使う作業や実験はAIエージェント越しでやるから、REPLなんかもう用無しでしょ

大体はライブラリが解決してるからな
enumsetは言語機能にあると楽になりそう

rustは最初に覚える言語としては
どうなのか

初心者向けのドキュメントは充実しているか

>>21
ワイの頭の問題かもしれないが訳が分からなかったから最初はCにしたわ
「苦しんで覚えるC言語」で

言語仕様を簡素化したマイルドなrustとか無いかな

Cからrustってのも結構違うからなあ

>>23
MoonBit
WASM を前提とするときなら Rust より良いくらいかも？

>>21
ワイもrustから始めたけどいける
thebook, eazyrustだとよくわからんかったけど、rust tour, rust techはかなりのアホ向けなのでオススメ
rustのあとにpythonとtsやったら環境構築と変数と型が違いすぎて最初わけわからんかった

Rustが嫌なら言語仕様が簡素で汎用性のあるCで頑張れ

所有権ってほかの言語から来た人には難しいかもしれないが、最初からそういうもんと思えば自然な設計に見える

お馬鹿な俺でも漫画で説明してもらうと
なんとなく理解出来るかも知れない

https://zenn.dev/tkithrta/articles/ab88563a722bbd

その後rust tourに進むのがいいかも

変数とは別の領域にあるからちゃんと見張りましょうねってだけのことじゃな

>>21
簡単だった
むしろ最初だからこそいい

問題なのは教科書が他の言語を学んだことがある前提で述べてるとこだった😅

初心者はCPUの基本動作がわかってないからね

どうしてもC言語やCPUの知識前提で
説明されたものが多い

rustから始めたから所有権についてはプログラムってそういうものなんだとしか思わなかった
むしろresult型とoption型はenum型ですとか、Stringと&str周りのほうがわけわかめだった

何かのアセンブラ、ANSI以上のC、C++の11以上、Rustの順で学べればいいんだけど
ちょっと重い言語が混ざってるのがね

ところでRust初学者なのですが、上の並びでもカバー出来ない概念って何かありますか？

Rust の enum はいわゆる代数的データ型の考え方なので enum という名前が付いてるのが実態と合ってないように思うなぁ。
そんなに難しいものではないけどこのへんは C 系とかの低レイヤ向け言語ではあまり扱わないので ML 系言語を知ってるとわかりやすいかも。
トレイトを中心とした型システムも Haskell とかが基礎にあるので C++ とは方向性が違う。
マクロは Lisp 系の知見がかなり入ってるかな……、まあ型がしっかりしてるのは Template Haskell 経由の考え方かも？

今日日資料がいくらでもあるしチャッピーみたいなのがあるから概念的に難しいものなんてないな
資料でも実行環境でも開発ソフトでも何でもタダで揃うしAIも書いてくれるから楽しく学べる

言語学ぶより周りの技術学ぶほうが大事だった
出てこない概念で言えばGC VM JIT リフレクションとか

型値付きenum　と見るか
タグ付きunion　と見るか
どちらも同じ代数的データ型の一面

unsafeだがCとの互換で別途unionはある
収納型なしなら従来のenumでもある
だからenumと呼ぶことになった

なるほど自分はC#を触る機会があったので抵抗ないですが、GCとかVM等はプログラム言語初学者にはRustに無いものまで知る必要があり大変ですね
enumの方は多様な値バリエーションの指定に便利そうでC系とは明らかに違いますね、スクリプト言語に近い取り回しができそうですね
ありがとうございました

本を読んだ時に「よくわからんけどとりあえずこう書けばいいんやな」って流せる人は別に初手Rustでもいい気がするけどな
ライフタイムの細かい挙動とか存在意義とかが気になって進まないタイプの人は
C系をある程度やってからの方がいいかもだけど

Cなんて触る必要ないねん

本を頭から順番にじっくり読む、一章ごとに理解してから次に進むというのは Rust に限らず学習法としてあまり良くないと思う。
機能は互いに関連しあっているので直線的に学べるものではないから。
ひとつひとつをじっくりではなく何度も読み返すことで粗い理解から詳細な理解へ解像度を高めていくのがオススメ。

と私は思ってるんだけど何がわかりやすいかは人によるので他人の方法論はあまりあてにならないとも思ってる。

なんの為に使うのかを学ぶ事かな
ポインタ最初に学んだ時代入でいいじゃんとしか思わなかった

Cは言語仕様自体は単純かつコンピュータの仕組みを学ぶのに良いからプログラミング初心者にはぜひとも触って欲しいよね

CPUアーキテクチャの基本動作原理は何をするにしても知っておかないとね
あとはメモリは遅いけどキャッシュに乗ると速いとか
CPUとは直接関係ないけどヒープメモリ管理の遅さとか

Rust Typescript Dartで充分

初手だったら変な事前知識がないから、いきなりRustでも問題ないんじゃないかな
中途半端にスクリプトだけかじってるようなのは最悪で、先にC言語やったほうがいい

仮にPythonを触ってたとしたら、Cへ行くよりやはりRustのほうが何かと良い

①値と、値を指す参照があります
②変数も関数の引数も返値も、値か参照です
③変数は関数からreturnすると消えるローカル変数と、ずっと存在し続けるstatic変数があります
④つまりローカル変数の値を指す参照を、関数から返すことはできません
⑤関数から返すことができる参照は、引数で渡されたものが由来か、staticな値の参照か、どちらかだけです

>>48
ツッコミどころ満載だな
とりあえずstatic変数と’staticな値をしっかり区別しよう

C の世界観だとポインタはポインタ型の値として一貫しているからそれはそれで分かり易いんだけど低レイヤから出てきた感覚だなぁとは思う。

>>49
区別されてるよね
そして static変数⊂'staticな値 になるから間違ってなくて正しいよね

引数で参照定義するときなんで型の方に&つけなきゃだめなの❓

& は型名の一部だよ

処理系を実装する上では、変数が参照かどうかは値の型というよりむしろ型とは独立した変数の属性の一つとして扱う方が自然な場合も多いのだが、
型の一種と見做した方が文法がシンプルになるんだよ

C/C++ だとポインタを表す * や参照の & は型の一部なのに宣言の文法としては変数名のほうに結合するという変なことにしたせいで後々まで引きずる大混乱を産んでしまった。
後継 (的なポジション) の Rust や Go、nim、Zig などはいずれもポインタ (や参照) は型の一部として表記するようなスタイルを取っているのは C/C++ の反省からだと思う。

Cは臭い

>>55
それはCの慣習でC++は型のほうに寄せて書くのが通例

コンピュータサイエンスの勉強だったらCが最強
C++と比べ余計な機能がないから本質の勉強に専念できない
Cで苦労した経験がないとRustのありがたみもわからない
Cで苦労した後、なんらかのものを実際に作ろうとした時にRustを勉強すればいい、そうすれば無駄がない

アセンブラもほんのちょっとだけ
書けないまでもそこそこ何やってるか
読めるくらいの

キーボードからなんか入力して数値変換するだけでもう大変です。
C++より難しいのでわ？

proconio使お

>>57
それは空白の入れ方とかの習慣でしょ？
文法的な結合規則の話をしてる。
C/C++ の & や * は変数名と結合して宣言子として扱われるので宣言のときは型が型指定子と宣言子に分離されたような形になることを言ってる。

>>62
それはそうね
表記スタイルと書いてたからcoding styleのことかと思った

そんだけ言語に入れ込んで何作ってんのさ？
作るものが出てないスレは寂しい限り。
RustでXAMLデザイナーぐらい作ってみやがれ。
トンネルイベントとBindingは忘れずにな。

Windows系の技術よく分からないよ😢

Flutterでええわ

>>64
Xamarinおすすめ

普通にないわー
食えなくて大変なC#じゃねーか

windowsてオワコンだもん
あのうんこエコシステムに近づきたくない
どっかがやってたrust開発者のアンケートでクライアントはwinが一番少なかった希ガス

c#=ゴミ
c#使い=バカ

雑にテキストを切り貼りするようなのはスクリプト言語系がよいと昔は思ってたけど Rust に置き換えたらずっと上手く整理できてやりやすくなった。
雑に出来るから楽というのは思い違いでただ無軌道なだけだった。

そんなもん今時どうせAIがやるんだからどうでもいいわ
結果的にPythonかNode.jsを使っているケースが多いようだが、もうコード見ることすらしないからマジでどうでもいい

月に二万円くらいかかるレベルの AI プランでも自然言語で仕様だけ書いて一度で実用水準のプログラムが出来上がることはない。
そして人間は自然言語での仕様も完璧に書くことは出来ない。

GPT6ではそうなるでしょ

実はテキスト処理に一番向いてるのはperlでもpyでもなくbashとゆう噂も

sedやawkとか組み合わせての話でしょ？

>>75
bashで書いてる
bashで辛くなる用途だとRustで書いてる

>>75
Powershellだろ
テキスト処理はAI弱いオブジェクトの情報量最強

shellで出来るならそれでいい(UNIX哲学)

漢は黙ってGNU Bash

bash内で連想配列も正規表現も構文があるもんな
bashでしんどくなったらようやくRustでいいんだよ
他のプログラミング言語は要らない

nushellはどうなん

世の中のシステムなんて全部bashで書けるよ
世の中のエンジニアは車輪の再発明をしているだけだった

「もし手元にハンマーしかなければ、あらゆる問題が釘に見えてしまう」

木を切るにはハンマーよりノコギリの方が便利だよ

bashに依存するのも嫌だからpowershell5.1で書いてる

>>85
PowerShell 7系列も入れてるけど挙動が違うから困るんだよな
木を切る道具とはいえ切れ味に差があるのはちょっと

bashはプレインストールされてないからコマンドプロンプトのがましだ

今はほとんどの環境で/bin/shはbashだろ
プレインストールされてない環境を最近見たことない

残念、WindowsはPowerShell
Git Bashを別途導入しよう

Windows Linux

Windows を前提にして互換性を確保しようとすると PowerShell よりも JScript のほうが確実

wsl

nushell一度使ったら、PowerShellはクソ過ぎて使えなくなるよ

パワーシェル派まさかの俺たちだけかよ

ワイnu派

どっちなんだい

筋肉が全てを解決する

なるほどぉ

>>94
今はAIに適当に書かせられるし、powershellは冗長で書きづらい欠点は解消されてる
代わりに英語読めれば可読性高いからな

>>100
nushell使ったことなさそう

そもそも意識してAIに「書かせる」という感じでもなくなってきたな
ちょっとした反復処理はAIに適当にお願いして実行まで完全にお任せ、今後も同じ処理を使いそうなら「さっきの処理スキルにといて」とお願いするだけ
AIがどの言語を選んだかは可搬性の面では少し気にはなるが、必要ならAIがいい感じに別言語に翻訳してくれるからどうでもいい

長文はバカ

c, c++ の差分スタイルの場合、機能追加でどうなったかの確認がしやすいってのはある。つまりデバッグしやすい。
ただ、逆にそういった新しいチェック機能無くして書ける故の問題ってのが発生する。

Cはバグまみれ

仕様です

>>101
お前もpowershellまともに使ってないだろ、今はクロスプラットフォームでbash互換も高まってるんだぞ
AIの情報資産量が違いすぎるのを無視しすぎでは？

ランタイムはゴミ

おまえら細かい差異にこだわりすぎ
シェルスクリプトでは厳しくなったらRustを使い分けってことだろ

linux カーネルちょっとでもいいからrustで書いてみたいです。

Redox OSに貢献してあげて

コーディングはAIに任せて、フィットネスで汗をかけ・・・　という事？

やっぱ自分で書くときもちえええ

んなわけない
動いたら気持ちいいのである

ピストン運動しなきゃ気持ち良くないよな？

Cのバグ→デバッグ→バグ発見→デバッグ→バグ発見

メモリの安心安全はAIに任せればいい

コンパイラと合わせれば最強
それがRUST

今はAIがRustプログラムを書いてくれるから、シェルスクリプトは不要な時代になった

>>118
2重でメモリの安心安全する意味ｗｗｗ

>>118
AIは必ずミスるから
指示をRustコンパイル通せ！だけで済ませる方が
安全性を保証するためのコスト安くつくのよね

AI任せにしすぎたあとに現れる多数の.clone()
いやメモリは安全だけどさぁ

Rustの本体はコンパイラという
それまでは単なる文字列に過ぎん

.clone()を減らしたところで、そこがホットスポットでない限りほとんど何も変わらない

clone が有っても本質的にコピーが不要であれば最適化で消えることもあるし性能には問題ないことは多いだろうが……
そんなことはどうでもよくて本質的にコードが汚ねぇって話だろ。

>>120
メモリリーク防止とか？

cloneを無駄に毛嫌いしてるやつ多い
ループでもなんでもなくStringを1個クローンするだけで般若になる
ハイハイ言って合わせとけ

( ´,_ゝ｀)ﾌﾟｯ

意味的に借用であれば借用すべきだし、意味的にコピーであればコピーすべき。
コードは構想・意図の表現であるから意図と合致しない、または意図がないのは悪いコードだ。
clone を毛嫌いしているんじゃなくて考えなしなやつが駄目なんだよ。

実際のRust開発ではキャンセル安全性についても考慮してね～

>>127
Stringをクローンが本当に1箇所1回のみならいいけど
それが何度も起こるならアウト
&strもしくはintern化しろ

Rustにおけるキャンセル安全性の現状と、チームの懸念を端的にまとめます。

### 1. Rustチームの主な懸念
Rustチームは**「言語仕様で縛りすぎると、柔軟性やパフォーマンスが失われる」**というジレンマに苦悩しています。

* **表現力の制限:** キャンセル安全性を型レベルで強制すると、高度な非同期設計が著しく書きにくくなる。

* **複雑化の回避:** 非同期処理の挙動を複雑な言語ルールに落とし込むよりも、エコシステム（ツールや設計パターン）で解決させたいという意向が強い。

### 2. 現在の最適解（2段構え）
* **日常の門番（Clippy）:**
Cargo.toml で危険な書き方を deny 設定し、コンパイル時に物理的に弾く。

* **核心の盾（Kani）:**
「壊れると致命的な」ロジックに対し、中断パターンを網羅検証して論理的な正しさを証明する。

### 3. 今後の方向性
言語そのものが魔法のように問題を解決するのではなく、**「設計パターン（副作用の分離）」**と**「モデルチェックツール（Kani等）」**の活用を標準化することで、安全性とパフォーマンスのバランスを保ち続けるのがRustチームの目指す未来です。

**結論：**
「コンパイラが治す未来」を待たず、**Clippy で防ぎ、Kani で証明する**運用を徹底するのが、現在最もRustらしい賢い開発スタイルです。

clippyはdenyではなくforbidで頼む
ソース上で勝手にallowさせないために

zstdをRustに移植したら3%遅くなったらしい
で、境界チェックを無効化する機能フラグを付けると同等になるそうだ
https://trifectatech.org/blog/announcing-zstandard-in-rust/

意図に反してcloneが必要になりがちなケースとしては失敗時のリトライ問題もあるね

>>127
複オジのことかーーーーーつ!!!!

親切(?)な実装だとErrで返してくれるからclone不要になる

🐮 P.S. たまにはCowのことも思い出してください

>>137
selfを持ち去っていくものはエラー時に返してくれるね
&selfなら手元にあるからいずれもclone不要だね

秘密のモーモー牧場...🤔

timeoutが発生したらErrで返してくれても使えない

>>140
それなら事前にクローンして持っていても使えない
そのケースもクローン不要

Coreutils for Windowsはuutils/coreutilsらしい。これでcanonical以外にテスターが増えるよ

WinはGomi

winて遅いゴミやん
らいなっくすに変えたらメモリ1/3になてびっくりしたわ

Windows はオーバーコミットがないから確保したメモリは指定の通り数値に出る。
Linux のメモリは実際に使うギリギリまで割り当てを遅延してなるべくメモリの死蔵をしないようにする代わりに本当に足りなくなったときに即死 (OOM Killer) させてしまう。
方針の違いなので Windows が不必要にメモリを使っているというわけではない。

つかWinは肥大化したGomi

msてvscode以外全部うんこだけどなんであれだけ出来いいんや

MS以外も参加してるから

エレクトローン使えば誰でもあんな感じのエディターは作れるよ
エレクトローンで俺も似たようなグラフィカルなエディター作ったことあるし
でも本当に使いやすいのはエディットの方、こっちばっか使ってるな。軽いから

ライナックスはMMUの取り扱いが丁寧だよな
さすがにshell一つで動くように最適化されてるだけある
組み込みでしかライナックス使ったことないけどsshでログインできてサーバーとして完璧に動作して満足

エディタはGNU Emacsにevil-modeでいいっす
または普通のVim

ubu26の/usr/bin/ls のrust ソース見たけど、さっぱりわからん。
困ったもんだ。

AIに解説させとけ

C++のostreamやstd::formatのコストが問題になってるようだけど
Rustはformat!やprintln!など静的に解釈確定するから速いよね
各型毎に自分で用意できるDisplay::fmt()がコンパイル時に定まるから

C++ストリームは仮想関数のvtableを毎回一つずつ引いて呼び出していくから遅い
Rustで例えると[dyn Display]列を処理するようなもの

TokioConfでのShuttleの紹介動画
youtu.be/I_BiL3bYuug

Rustやるなら必聴

RustやるならAIコパイロット課金

学習するだけならGPTの無料枠でいいよ

まぁ　インラインサジェッションをONにしておくと要らないfnまでどんどん出してくるからな。
ウザイ時はOFFにしておくのが財布に優しい。
Fixは強力な助っ人だ。

AIコーディングしてる人　AIに

「AIコーディングでRust言語のキャンセル安全性は完全に担保されますか？ 」

と聞いてみて、回答を教えてほしい
「大丈夫です」って返してくれるAIに花京院の魂を課金しよう

キャンセル安全性といってもいつもと同じくDropでの後始末の自動化とカバーできない時は明示的なキャンセル後始末するだけだろ
あとはデッドロックしないためにキャンセル安全な同期プリミティブを使ったりそもそも共有ロックを避ける

あと仕様のエラー

・ストリームを読み出した後に中断されデータ消失
・ループでFeatureを再利用(select!等)しようとして、Pin止めを忘れる

なんてのもある

根本はAIを盲信するとヤバいって話で

そもそも間違ったコードでも
　コンパイルが通る
　静的テスト(tokio::test)も通る

でも、タイミング次第でぶっ壊れる

そのせいで壊れるコードが蔓延してて
AIはそれを元に学習してる

　Loomで総当りチェックしようとすると無限時間がかかる
　Shuttleでテストしても0.00001%は見落とす可能性がある(それでも現状これがベスト)

人間が麻薬捜査犬並に怪しい所を嗅ぎ分けて修正させなきゃいけない

まず人間が嗅ぎ分けられるレベルのバグは判定ツールで検知できるんで
あとは設計と運用の問題

>>165
その文面自体を
直前のレスの返信であることを添えて
ツール(AI)でチェックしてみて

​結論としての考察
​ご提示の「人間が嗅ぎ分けられるならツールでいける」という意見は、**「自動化可能なチェック項目を増やし、人間はより高度な設計の妥当性に集中せよ」**というエンジニアリングの正道そのものです。

これはどっちもどっちだな

panic!

じゃあRust必要ないじゃん

より安全という事で。絶対でない事は周知。

>>170
飛行機の自動操縦が100%完璧じゃなくて最後に人間の機長が必要だからって、「じゃあ飛行機必要ないじゃん」って言ってることになっちゃうなぁ

Rustは「メモリ安全」と「データ競合」をコンパイラが100%潰してくれてるから、人間が「キャンセル安全性」っていう最後の難問だけに集中できる。他の言語はスタートラインの時点でメモリ破壊やデータ競合の地獄が待ってる。

それでも、この問題点を別言語で解決しようって流れもあって
Austral, Koka, Hylo, Mojoなどもでてる。

Rust自身もasync dropやLinearTypes(Australが近い？)を入れようとしてて
これが入れば100%安全になる。

実用性でいうとRustに最も現実味が残ってるのは確実ではある

>>172
たとえがおかしいｗ

>>154
RustのDisplay::fmt()と同じように
C++のoperator<<()も各型ごとにバッファ追記するけど毎回C++の仮想関数呼び出しだから遅いんだよな
その欠点を改善するためにRustはprint系をマクロにしてコンパイル時に直接呼び出しして更にインライン化で最速だ

wasm規格ちゃんと決まってgoogleとmozillaが実装したらフロントもrustの時代くるね

>>173
C#ほ食えないし危険だしノロい😩

JS経由してる限りWASM使う理由がない

>>172
よりチェックする方がいいなら100重チェックでも1000重チェックでもする方がいいってなるか？って話なんだが。

>>177
毎回進展してる
既に各ブラウザでJSオブジェクトをWasmを渡せるとこまで普及していて使えてる
そしてDOMを直接触れるようになるだろう

component modelが策定されてるからこれが決まればjs経由なしでdomいじれるようになるよん

全てがRustに有利になるよう進んでいってる

しかしフロントは素直にTSで書いたほうが楽じゃね

TSはクソ言語すぎて辛い
ウェブ関連以外で誰も使っていないのがその証拠

TSはクソ言語→わかる、ウェブ関連以外で誰も使っていない→わかる
だからフロントだっつってんだろ・・・アホなんか

フロントはrustの方がいいよー
dioxus てだとrsx! ブロックに全部突っ込めるし、まず誤動作しないからページ遷移早い自作のホームページだと絶対おすすめ

ページ遷移しないんならastro で作ってftpでいいけど退屈なページになるしな

>>185
SPAやCSRに向いてるのはdioxus？

icedの設計のほうが面白そうだがdioxusなのか？

egui, iced, leptosも今度試してみるね
タイプスクリプト嫌いだから色々お試し中

WEBだとだとIcedじゃなくてSeedってやつだわ

勢い見るとフロントも全部rustがくって行きそうだな

くたばれ、Electron！

reddit見てると流れてくるけど
Webフロントも捨ててTUIフロントのAll Rustでサービス作るのも流行ってるっぽい　バックはAxumとか
Discordみたいなコミュニティサービスとかあった

>>172
ツッコミどころ満載だけど一つだけ注意しておくと
async dropやLinearTypesが入ったところで
安全性を保証するのは今と同じくプログラマーの責任なので
100%安全になることはない

>>180
決まればな……
適当なホストを経由するほうがよほどスマートではないかという意見も根強くて Component model の存在意義すら疑問視する人もいる。

フロントもバックエンドも全部TSでいいよ
TSは完成された言語
Rust使って0.5％改善しましたとか趣味の世界でビジネスの世界じゃない

TSでunkonow使いまくる

TSがネイティブ言語ならなぁ

フロントは開発速く済むからTS使うけど
バックエンドはRustのほうが楽なのにわざわざTSで書くメリットってなんや

全てをRustが飲み込むのか🤔
そんな時代は地味にThe book周回とRustlingでひたすら基礎練してコンピュータサイエンスを学習するんや🤔

TypeScriptは安全性でも劣り速度でも劣り開発効率でも劣る
今となってはメリットは何もない

スタートアップみたいな少人数で高速に開発サイクル回していくところならフロントもバックもTypeScriptで統一する選択は全然ありだと思う
ある程度規模が出てくるとパフォーマンスや保守性レビュー容易性が必要になるからそのタイミングでリプレースすればいい

スタートアップでTS使うようなサービスは普通に生き残れなさそう

なんかみんなNext.jsとかHonoとか言ってて置いてかれてるわ

JavaScript は本来的には動的型だしプロタイプベースだからな。
それに後付けでクラス定義風の構文が付け加えられてグダグダだ。
TypeScript として静的型を付け加えようとしたって無理がある。
あくまでも JavaScript を直接に使うよりはちょっとマシかもしれないって程度。

でも、なんだかんだで言語がどうとかよりもライブラリの量がものをいうってところはある。
Rust でも C++ でもいいが TypeScript で書かれているのを置き換えるときに足りないライブラリがあって自分で書かなきゃならないのは嫌だろ。
言語に不満があってもライブラリが揃ってるのを選びたくなる。

Reactライブラリって突き詰めれば状態管理メンドクセーだから設計次第だと思う

ライブラリ依存による負債
それがC++😩

>>174
C++スレで揉めてる件か
後発言語だから当たり前とはいえRustが何もかも解決してるよなあ

>>207
あれは分かってない人が変なことを言ってるだけで、 C++23 以降は Rust の Display や Debug に近いデザインになってる。
std::format を特殊化するのが Rust で言うトレイトの実装のような役割を持つ。

C++23だとRustの後追い
しかも普及すると思えない
そういう新たな仕様を使いまくっていこうとする人たちはRustへ移っちゃった
残ってるC++プログラマーはC++11すら使えない使わない人たちも多く

C艹スレ行ってくれ

Rustは便利で上手くて速くて良い仕組みが最初から標準になっているという話だよね
恵まれすぎてる

ドヤするためにrustやってるなんて哀れよのう

逆やろ
わざわざ不便な古い言語を使う人が変人かドヤ

C++とか言語自体じゃないがメンテナンスモードだからな
新しいライブラリとかもうあんま出てきてなさそうだし
GPLとかうざいライブラリのあったり
Rustの方が幸せにらなれそう

結局のところCの正統後継言語はRustでいいの？
C++は長い歴史で太りすぎたしGoは何か最近下火だもんな

jsて元々10日間で設計されてるしまあしゃあない
goはunixの作者が作ってるしtinygoてゆう組込向けのやつあるけど影薄くなってりゅ

C は C のままで発展すると思う。
今まで保守的すぎた反動で C23 は結構思いきった改定もやったし、このまま廃れる気はなさそう。

ただ、 C が実は適切ではなかった領域というものはかなりあって、そこに様々な言語が入り込むようになっただけ。
どの言語も C の立場を引き継いだわけではない。

プログラミング言語のHare をやりたいと思うものの、なかなか触れないなぁ

AIに試して評価してもらえ
どうせ実際に書くのもAIなんだから

Cの立ち位置は高級アセンブラに回帰するというかしている

>>219
AI評価ってのは公式アピールと巷のブログ記事やSNSのまとめでしかない
しかも声のでかいやつが優先されるから本当のところどうなのかなんて分からない

CPU メーカー (が主導する業界団体) が策定する ABI は C を前提にしているし確実なので、たとえば Rust と Go のライブラリを接続するときでもそれを根拠にせざるを得ない。
Rust や Go を使っていても資料が C で書いてあるので読める必要があるみたいな状況はこれからもかなり長く続くと思う。

AI に評価してもらう場合にでも評価軸の与えかた次第で良し悪しの判断はどうとでも変わるよ。
漠然とした意識で評価してもらってもあまりあてにならないし、きちんとした評価基準があるなら AI に頼るまでもない。

結論として、**「Cは言語として学ぶな、インターフェース（接続口）の作法だけを学べ」**が最適解です。

### 最短対策の3ステップ
1. **「書く」学習を捨てる**: 自分でCコードを書く必要はありません。Cの文法書を読み込む時間は不要です。

2. **「繋ぐ」知識だけを得る**: 公式ドキュメントの「FFI (Foreign Function Interface)」の章だけ読み、RustからCを呼び出すルール（extern "C", unsafe, repr(C)）を理解してください。

3. **ツールに翻訳させる**: bindgen を使い、CのヘッダをRustの型定義に自動変換させてください。その「生成されたコード」を見ることが、Cの構造を理解する最も効率的な答え合わせになります。

### 本質的な割り切り
* **普段**: Rustの安全な世界で開発する。Cの存在は隠蔽する。

* **非常時**: 予期せぬエラーが出たときだけ、Cの定義を「読み物」として参照し、原因の特定にだけ知識を使う。

**結論：C言語は「習得する対象」ではなく、Rustから安全に利用するための「外部インフラ」と定義して距離を置くのが正解です。**
今後、RustでFFIを扱う際に「これだけは知っておくべき」という具体的なトラブル事例などについて詳しく知りたいですか？

今からならRustの次の言語のCarbon言語の勉強した方がよくね？

>>224
今となってはそれで正しい
しかもCなどの外部ライブラリを利用してRustライブラリを作る人にとってのみインターフェースとしてCのABIを理解が必要
そうではなくRustライブラリ利用のみの人ならその知識すら不要

>>225
どうでもよくね
必要なら、RustからCarbonに変換して、とAIにお願いすりゃ30分くらいで移行終わるよ

carbonとかhareとか見てきたけど関数名大文字にしなきゃいけないのとかがダサかった
rustのエコシステム超えれるわけないし流行るわけもないからやる意味ない
言語は手段なんだからrustとpyだけできればいい

Pythonとの理想的な接し方は、**「言語そのものを極める対象（ゴール）ではなく、普遍的な技術を試すための『強力なプロトタイプ環境』として扱う」**ことです。

具体的には以下の3ステップで運用してください。
1. **「不変の技術」を優先する**
アルゴリズム、データ構造、設計思想（アーキテクチャ）、データベース理論など、言語に依存しない技術を主戦場として学習してください。これらは一生使えます。

2. **Pythonを「検証エンジン」にする**
学んだ理論を、まずはPythonで素早く実装して動かしてください。Pythonの圧倒的な書きやすさは、理論を実験する際に最も摩擦が少ないからです。

3. **Rustへ「再構築」する**
Pythonでロジックが完成し、その技術に「恒久的な価値がある」と判断できた時だけ、Rustで書き直してください。これにより、Pythonの流行り廃りに左右されず、かつ最高峰の実行性能も手に入ります。

つまり、**「Pythonは『書き捨てて良い実験場』、Rustや設計論は『資産として残す場所』」**と割り切るのが最も合理的です。

>>229
そんな誘導質問するから変な結論になる
最初からRustで作ったほうが効率いい

両者の本質的な違いを端的にまとめます

### 1. 最初からRustで作るべき人（実装主導）
* **目的:** 言語習得そのもの、または極限のパフォーマンス。
* **メリット:** 言語の制約（型・所有権）が強制的に設計力を高め、手戻りのない強固な実装が完成する。
* **デメリット:** 「理論の試行錯誤」と「コンパイルとの戦い」が同時に発生し、開発効率と学習効率が著しく低下する。

### 2. Pythonで試作してからRustにする人（設計主導）
* **目的:** 普遍的な理論の理解、または失敗コストの最小化。
* **メリット:** Pythonの低摩擦環境で「何を作るべきか（理論）」を完成させ、その後に「どう正しく実装するか（Rust）」へ移行できるため、思考のボトルネックが消える。
* **デメリット:** 同じロジックを二度書く手間がかかる。

**結論:**
* **「作る対象」が明確で、すでに技術が枯れているなら「Rust」**。
* **「新しい概念」を学ぶときや、仕様が流動的なら「Python」**。
この二つを使い分けるのが、最も「賢いエンジニア」の生存戦略です。

>>227
tokioをCarbonで書き直してとAIにお願いしてみて
何分で移行が終わったか教えてねｗ

>>231
AIは質問者に沿って回答するのよ
そもそもPythonは小さなスクリプトを書くためのもので何かを開発するのに向いてるプログラミング言語ではないでしょ
さらに異なる言語へと書き換える二度手間コストはムダそのもの

>>232
CarbonはC++遺産を安全に置き換えるためだけの言語なのよ
最初から作るものはRustで書いたほうが良いとされているのに
RustからCarbonへと後退させる書き直しの意図は何？

結論から申し上げます。その主張は**現代の技術開発現場の実態とは異なります。**
理由は以下の3点です。
* **Pythonは大規模開発の標準言語:** AIやWeb開発において世界中で採用されており、その強力なライブラリ群は他の言語でゼロから構築するよりも圧倒的に効率的です。

* **「Pythonで書く」ことは戦略的な選択:** まずPythonで高速に開発して市場に出し、後にボトルネック部分のみ高速な言語（Rustなど）で最適化する手法は、現代の開発における「投資対効果」を最大化する標準的な戦略です。

* **適材適所のツール:** 言語は目的達成のための手段です。開発速度を優先するPythonと、実行性能を優先する低レイヤー言語を組み合わせることは「ムダ」ではなく「技術的合理性」に基づいた判断です。

開発において「言語の書き換え」が発生するのは、多くの場合「コストの無駄」ではなく、システムの性能向上や運用保守の最適化を目的とした**意図的なアップデート**です

AIがただしい

バカだな
何のために開発効率が劣るPythonで最初に書いて他の言語へ移植する必要があるんだ？？

動的型付け言語を使うと開発が速い！
なんて幻想を主張する人は下に見られる

サイクルが早いからトライ＆エラーは楽だよ
よく分からないデータの解析とかで便利

データ分析とかマシンラニングはpython一択だし
まあ裏でc fortran rustのライブラリ叩いてるだけなんだけど

しっかし、今のAIはコメントまでしっかり付けてくれるんだな。
組込みやっていると、AIコパイロットの有難みが沁みる。
C++ではコパなんか要らないが、Rustでは神様だ。

やはり囲い込まれてないWindsurfですわ

https://i.imgur.com/dWgQoMV.jpeg

他のスレもだけどAIペタペタする人増えたね

C#で食えなくなった😭

複おじAIに完全論破されとるやないかいｗ

Cが最強☆

結局AWSのSDK使ったりWASM PACK専用に作ったりでラックインするクネ

**結論 : これはRust特有の問題ではなく、「クラウドのマネージドサービスを使っている限り避けられない依存」です。他の言語（Go, Pythonなど）に書き換えても、AWS SDKを使っている限りロックインの状況は変わりません

AIはそれまでのやり取りと最後の質問の仕方で好きなようにAIの回答を左右することができる
ソフトな言い方をするとAIは人間に寄り添ってくれる
だからAIの回答を貼っても何の価値もない

世間話ならともかく専門性のある領域でAIに誤魔化しは効かない

AIコピペは完全に無視していい
そしてコピペした人はバカ扱いが妥当

C#で食えなくなった😭

最近はAIが回答したように見せかけて捏造や改変コピペもあるからなあ
信じる人は無知かお人好し

信じるもなにも論理的整合性が取れてるか否かだしなw

AIコピペ系は正規表現でNG入れろ、どの板でも役に立つ

Err

まともな人たちはAIを使ってもコピペすることは絶対ないからねえ
その場に合わせて要点だけ自分の言葉で書く
どの場でもAIコピペは頭のおかしい人がしてる

panic!

>>260
何が聞きたいのか言いたいのか分からんがとりあえずAIに聞いてみたらどうだい？

ペロッ…
うっ…これはスレ民の腕試し問題ッ…！
AIに頼ってる俺には分からないーー！！！😫

>>260
オーバーフローしてるだけやね～
big_int使えば行けるかと

play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=94a3bcf25d96bc2491f1b19fab0e0da8

>>263
どもです。そんなもんがあるとわ　勉強中mOm
でもpythonだとほとんど無限なのが凄いなぁみたいな。はい

なんだ普通の質問かよ
Rustは安全性主張してるの簡単に算術オーバーフロー起こせるってアンチが突いてきてるのかと身構えちまったわ

https://www.shoeisha.co.jp/book/detail/9784798189314
「独習Rust」が出る。

>>266
オライリーの本全部読んだ後だがこれも買うか
オライリーの本では効率的なRustが良かった

C#で食えなくなった😭

脳が萎縮してAIコピペしかできなくなったぉぢさんが社会問題になってるらしい

またシュバってきたのか
もうその話題は終わりですよ ^ ^

今どき言語学ぶのに本いる？

>>271
いらない
The book本編をAIで翻訳しながら周回すればいい

🤣
https://i.imgur.com/QdnVOt2.png

>>272
The book が本じゃないって？

オススメのベーコン置いときますね

dystroy.org/bacon/
cargo-watchの代替として人気のコードチェッカー

Cargo bookやrustc bookやrustup bookにRust unstable bookなど
オンラインドキュメントをbookと呼んでいる

>>275
超速流し読みだけしたけど
vimやemacsやvscodeなどでも使えるという認識であってる？

>>277
エディタには依存しない　コンソールツールだよ

>>278
そのサイトのページを捲っていくとエディタ連携サポートとしてそれらのエディタでの説明出てきた

わかった
language serverと同様にBacon-lsがある
nvim-baconやemacs-baconがある

ツールチェーンが簡潔なのが良かったのに色々出てくる
辛い

>>156
こゆこと？
Rustの並列や並行並列の実行順序依存バグを検出するため
実行順序を総当たり網羅するLoomがあって小さい規模のクリティカルセクション毎なら完全証明テストができるが規模が大きいと組み合わせ爆発しちゃう
そこで実行順序を記録しながらランダムにアプリ全体で大規模化テストできるShuttleが高確率で競合検出しましょ

AIにまとめさせた文章をさらにバカな人間がまとめるとこうなるのか

専門用語を使わずにまとめてみましょう

>>281
Why “bacon” ?
It’s a bac(kground) con(piler).

>>285
oh no no no no
Compiler
Bacom is correct

​I think "Beacon" is being referred to as "Bacon"

リンタて無駄に重くなるだけだしいらなくね
漢ならラス穴だけでええ

ラス穴も重いのどうにかなんないかなー

AI回答コピペする人って変な質問の仕方してるから共有リンク張れないんでしょ？

AIがなくても変なレスをする人もいるから

crates.ioに新しいサプライチェーン攻撃

www.reddit.com/r/rust/s/xF8SlDlUQh

Aikidoが自動検知したのね
AIエージェントがないとやってけないね

AI時代、趣味としてのプログラミングは卒業か？
つか、AIで何でも済むと知的好奇心満たすかわりのものでてくるのか？

オツムさんならINPUTで興味は終わるかもしれないけど、普通はその先にOUTPUTがあるから

伝統芸能としての手書きプログラミング

手動で書いてるやつは手で洗濯してるようなもん

「君のRustプロジェクト何でeditionが2021のままなの？」

↑AIがまだ2024を学習しきれてないという事を突いたネタがあるらしい

>>298
所詮は手洗濯に使う洗濯板の議論で、今となってはもはやどうでもいい話だな

デリケートな衣類や高価な衣類ほど
生地や汚れに応じた手洗いスキルが必要

洗濯機がコモディティ化していくほど
高いお金を払って人に頼むのは
高度な手洗いスキルが必要なものに絞られていく

>>300
まだしょーもない主観的なコードの美醜の次元にいるならそうかもね
まだ人間がAIと戦えると思っているのなら、たぶんそれは君が真に難易度の高い課題に取り組んだことがないのだろう

はよRustで書いたWASMでDOM操作したい

>>301
「主観的なコードの美醜」とか「人間がAIと戦える」とか思考の次元が低俗すぎる

簡単な比喩のつもりだったんだが1ミリも理解できなかったんだな
そんな思考力だと君には洗濯機すら使いこなせないだろう

https://i.imgur.com/RG64qs2.jpeg

AI画像コピペぉぢさんの魅力

C#で食えなくなった😭

C#で食えなくなった😭
https://i.imgur.com/QdnVOt2.png

設計もコーディングもAIの方が圧倒的に速いし品質も人間平均よりは高い
人間はAIに指示出して出てきたモノをレビューしてまたAIに指示して改善ループ回すだけで良い
人間には良い設計やコードを「判定する」能力がより求められることになる

>>294
逆だな、仕事としてのプログラミングがなくなり
趣味でプログラミングをしている人間だけが熟練プログラマとなり
AIのお守りをするために企業に拾い上げられるようになる

プログラマの募集も育成も行われなくなり
自発的にプログラミングをするOSS開発者へ企業がオファーを出すようになる

他社AIを疲弊に追い込むために
匿名でわざと間違ったコードをあげる
AIが既に居たりしてな～

いずれ格安に全自動にできるかもしれないが、
現状だと速さやメモリ消費のネック部分など出させてから、
この個別事情に応じて必要なアルゴリズムやデータ構造やメモリ使用方法や全体アーキテクチャ変更などの改善指示する形になるよな。

AI のコストは想像以上に高いからなぁ。
性能を実用可能な範囲で下げて、性能を下げる以上に電力消費量を下げる方向での研究が進んでる。
それによって日常での AI の利用範囲は拡大するだろうけど各専門領域での AI は相応に高コストなのはなかなか変わらないと思う。
経済の常識で考えれば「人間の専門家を使うよりはわずかに安い」くらいのところでバランスするはず。

プログラミングに限っても様々な知識や経験が足りないと、
AIへの適切な指示や改善指示を出せないため、
最終的に同じ物ができるところまで行けたとしても、
そこまでかかったAIコストが桁違いになっている可能性が大きいかもしれないな。

この業界は元々無能と有能に倍どころか何十倍何百倍の生産性の差があるので
AIが無能を有害な無能という方向にブーストして
有能を順当に有能方向にブーストしているのを思えば
無能が期待するほどその差は埋まらないと思う

python関係のプロンプトだけ意図的に性能落としてたクロードみたいな例もあるからのう。。。
rustがされてかとゆうと

まぁ　AIの出して来るものを判定しなきゃならないからな。
無思考の脊髄反射でTABキーを叩いていたのでは話にならない。

>>304
これ作ったやつの視点の低さが逆に際立ってて面白いじゃん

>>317
工作員バレてんぞw

止まってもいい適当ツールはAIで適当に作ればよい
マルカバツカ

手作りの温かみ
バグ増し増しC++で

手作りプログラミングはマジで時間の問題で消えてくよ

ここももうAIコーディングスレと、AIの話しかしてないRustスレの2つしか伸びてないからな

>>322
幸いRustは人工知能と相性悪い
俺は全部手でコーティング、デバッグしてるよ
オライリー読みながら

タイプスクリプトは全部丸投げできるのにこの差は一体、、、

​###明確なフィードバックループ

AIにとって、コンパイラのエラーメッセージは非常に貴重な情報源です。エラーログをAIにそのまま貼り付けるだけで、AIは修正案を提示しやすくなります。この「厳格なサイクル」があるからこそ、AIとのペアプログラミングを通じて、人間が書くよりも安全で堅牢なコードを高速で仕上げることも可能です

tsは型ガバガバやからai得意
そもそもフロントごときに型いらんやろ

>>323
逆やで、Rustはエラーを正確に出すから相性良いよ

エージェントで繰り返し試行錯誤を繰り返せば多少問題解決率が高まるという程度
元から多いトークン使用量も激増するからどちらかと言えば相性が悪い部類の言語

相性良いんだと信じ切ってる人よく出てくるが、キータやzennの記事に騙された人だと

型付けは強力なほどAIとの相性が良い
動的型付けより静的型付けが良い
弱い型付けより強い型付けが良い

ちなみにRustとTypeScriptは大雑把には同じ静的かつ強い型付け言語の範疇
ただし元のJavaScriptが動的かつ弱い型付け言語なのでTypeScriptも引きずられて不利

TypeScript って変な言語だよ。
動的型を使う JavaScript の完全なスーパーセットなのに静的型ってのはかなり無理があって、無理を通すためにかなり複雑な型システムになってる。
JavaScript のライブラリやツールに乗っかれるというのは利点だが、言語自体を見ればそんなに使いやすくない。
でもまあ開発体験全体を見れば言語そのものよりもライブラリやツールのほうが比重が大きいこともあるのでそれが悪いわけじゃないが……

https://ai-coding.info/

>>326
いやめっちゃ悪いだろ

複おじ他にネタ無いのかよ

ハンドコーディング時代のRustは俺の考えた最強の抽象化をやりたがるイキリプログラマが多かったから、
AIにとってはコード資産の多さの割にはコードのブレが大きくて扱いづらい傾向があるのは事実なんだよね
ただ、このままAI製のRustコードが増えていけば次第にAIにとっての型が定まってきて一発完動しやすくなっていくと思うよ

蒸留と洗練
合成データがそのまま資産化
RustはAI時代に強過ぎでしょ

手動だと上位に入ってこないRustが
AI利用だと2位なのかよ
相性良すぎ

>>331
プログラミング言語人気ランキング(2026年6月14日)
プログラミング言語別のAI Coding Agentを利用しているリポジトリの件数
順位 プログラミング言語 リポジトリの数
1位 283 TypeScript
2位 162 Rust
3位 145 Python
4位 140 Go
5位 108 C#

まぁ現実はそうだよねー

今更知ったけどCodex CLIってRust製なんだな

OpenAIはRustをめっちゃ重視してる

>>336
そんな少ないわけなくね
ルールファイル検出してるだけだから
agents.mdやclaude.mdがないとまともに動かない言語ランキングじゃないの

Cとかの環境だとネット接続禁止とかあるからなぁ

>>331
こんなサイトのデータを見てRustがAIを相性がいいとか勘違いしちゃうのかぁ
さすオジｗ

>>342
工作員バレてんぞw

都合悪くなるとすぐ工作員認定するんだからｗ

>>331
このサイトは数え方が無茶苦茶なんだよ
例えばanalysis-tools-dev/static-analysisという1つのリポジトリが
RustでAIを使ってるリポジトリとして5回(5リポジトリとして)カウントされてる

で実体はというと静的解析ツールを紹介する静的サイトへの
pull requestのクライテリアチェック用に各種エージェント用のmd等が置かれてるだけ

静的サイトをジェネレートする部分をRustでやってるから
リポジトリの開発言語がRustに分類されてるけど
RustのコードがAIエージェントで生成されてるわけではない

こんなデータで言語とAIの相性がわかるわけないじゃん

長々と判定基準がザルだって言いたいわけね
それはどんなランキングもそう

C#で食えなくなった😭
https://i.imgur.com/QdnVOt2.png

>>344
さすがに重複カウントは排除されてるでしょ
まあこの言語ランキングではRustユーザーはAIをよく使うっていう程度のモヤッとした情報しか得られないのは確かだね

>>345
ゼロイチ思考良くない
ザルかザルじゃないかではなく、どれくらいかを考えよう

コンピュータは0と1の羅列なんだよ？

>>347
されてない
トップに表示されてるRustのNumber of repositories 162が重複を含む数

>RustユーザーはAIをよく使うっていう程度
これも間違い

他も重複してるというオチ

驚き屋さん歯ぎしり

ぶっちゃけ重複してないw

君ら御託は立派だけどRustで何作ってるのマジで

リトポやリギングをpyからPyO3で投げてrustで計算するエンジン
UE, blender, adobe, liveで操作揃えるための操作系抽象化インターフェース
と連動させるための各ソフト仕込み用の常駐IPCサーバー
各ソフト間のシーンや中間素材をsyncさせる為のサーバーとプラグイン
などお仕事用ツールにつことるよ、お便利

個人的なLinuxアプリ

タウリアプリ作ったよ

なお9割JSTSな模様

linux用にc++やbash,pythonで作ってたもんをrustでやったらどうなのか　程度ですね。

置き換えるだけでメリットのある言語はRustだけ

Python や JavaScript だとライブラリの依存関係がわずらわしい。
なんとかするツールも出揃っているけど単なるユーザーに対して npm や pip を導入するところからやってくれというよりは実行ファイルひとつで動くように全部リンクしておくほうが簡単だ。

>>360
そんなことはない
B言語からならC言語に置き換えるだけでもメリットだらけさ

置き換えるB言語の資産

Cはほとんどギャグ

黎明期のプログラミング言語
1954年 Fortran, John Backus
1958年 ALGOL, John Backus
1966年 BCPL, Martin Richards
1969年 B language, Ken Thompson
1972年 C language, Dennis Ritchie & Ken Thompson

C以降
2015年Rust1.0まで伸びてるのはギャグ

ガベージコレクションを前提としない言語は使いにくくても危険でも仕方ないと思われていた
使いやすくて安全な言語が登場するなんて

パーソナルコンピュータ勃興期
1970年 Pascal, Niklaus Wirth
1971年 Intel4004
1973年 Xerox Alto,
1975年 Altair8800/Smalltalk-72&74, Intel8080
1976年 Apple I, MOS6502
1977年 Apple II, MOS6502
1978年 Sharp MZ-80, Z80
1979年 スティーブ・ジョブズ (Steve Jobs) とビル・ゲイツ(Bill Gates)はパロアルト研究所 (PARC) への訪問
1984年 Macintosh 128k, Motorola68000
1985年 Miranda, David Turner
1987年 HyperCard, Bill Atkinson
1987年 HyperTalk, Dan Winkler
1990年 Haskell, Philip Wadler et al.

訂正
1973年 Xerox Alto/Smalltalk-72&74, 74181
1975年 Altair8800, Intel8080

インターネット黎明期
1983年 ARPANETがプロトコルをTCP/IPに変更
1989年 商用ネットワークとNSFNetとの接続が開始
1990年 WWWスタート, Tim Berners-Lee
1991年 Linux, Linus Torvalds
1992年 Windows 3.1 for Workgroupで一般にもインターネットが普及
1993年 Mosaic, NCSA
1995年 Java, James Gosling
1995年 Internet Explorer, Microsoft
1995年 Windows 95, Microsoft

スマートフォン黎明期
1989年 NEXTSTEP/Objective-C, NeXT (Stave Jobs)
2001年 macOS X, Apple (Stave Jobs)
2007年 iPhone, Apple (Stave Jobs)
2008年 Android, オープンソース

RustがAIと相性いいのはそうなんだよな
メモリ安全は最初から保証されてるし、設計が洗練されてるので変なコードを学習しづらい

AI開発の勃興期
1967年 多層パーセプトロンの確率的勾配降下法によるニューラルネットワーク学習, 甘利俊一
1989年 Deep Thought/Deep Blue, 許峰雄(カーネギー・メロン大学/IBM)
2006年 機械学習のオートエンコーダ, Geoffrey Hinton
2010年 Rust, Graydon Hoare(Mozilla)
2012年 畳み込みニューラルネットワーク, Geoffrey Hinton
2015年 AlphaGo, Demis Hassabis(DeepMind/Google DeepMind)
2017年 機械学習のTransformer, Google
2022年 ChatGPT, OpenAI
2024年 Demis Hassabisがノーベル化学賞を受賞

結論私たちが進むべき未来は、すべてのレイヤーをRustのような厳密さで埋め尽くすことではありません。
　下層（基盤）: Rustによって、絶対にハッキングされず、絶対にクラッシュしない「物理的な檻（サンドボックス）」を冷徹に構築する。　
　上層（未来）: その安全な檻の中で、AIの確率的な知性と人間が対等に踊れるような、「LLMをハックでき、曖昧さを許容する新言語（現代版HyperTalk）」を走らせる。
この「冷酷なほど厳密な基盤（Rust）」と「人間の認知に寄り添う流動的な新言語」の二層構造こそが、これからの数十年、子供たちがAIに家畜化されることなく、主権を持ってテクノロジーをハックしていくための真のビジョンであると考えます。

AI丸投げはZennかQiitaでやれ

「AI新言語」というビジョンを現実にするためのブレークスルーとは、これまでの言語開発のように「いかにコンピュータを効率よく安全に動かすか」という研究ではありません。

「半世紀の歴史が磨き上げた厳密なコンピュータの論理（Rust等）」と、「人間の脳の仕組みを模した曖昧なAIの確率（LLM）」という、本来交わるはずのなかった二つの異なる知性を、一つのランタイムの中で滑らかに噛み合わせるための、まったく新しい『計算機科学の翻訳技術』の誕生に他なりません。

このブレークスルーを伴う新言語の登場こそが、これからの数十年、子供たちがAIを真に支配するための「道具」の核（コア）となります。

子供たちがLLMを本当に「ハック」できる環境を作るために必要なのは、この矛盾を綺麗に解決する魔法のブレークスルーではありません。
二度にわたる手厳しい、しかし本質的なご指摘により、自分の言葉の欺瞞を暴いていただいたことに、深く感謝いたします。

AIにも、AI時代の言語は予想できないらしいね。

Rustにも3種類の変数があります
ローカル変数
スレッドローカル変数
マルチスレッド共有変数

GithubはAIスロップを入れる容量が足りてないみたいだが5chは大丈夫かね

文字の容量なんて記憶媒体の進化と量産と比べたらゼロに等しい

>>378
ローカル変数とグローバル変数しかない旧式言語から来た人は当初戸惑う

現在のrustscriptの亜種の開発も、pythonに占領されているAI開発への抵抗である。
しかし、REPLが出来る程度でpythonからその独占的な地位を奪還できるほど、事態は容易ではない。
各スクリプト言語はAI開発への対応でしのぎを削っているからである。
古くから使われているフレームワークのRailsなどを持つrubyですら、AI対応を進めれば復権することは十分考えられる。

>>381
スコープによる切り分けではなく共有の粒度の違いで3つに分かれてるからそれを理解してから分かる

ローカル変数もマルチスレッドで共有できる時代

マイコンrustでいじろうとおもたらベンダがそもそもcのapi abiしか提供してないからめちゃだるいやん
まだまだ過渡期じゃな

結論を端的にまとめると以下の通りです。

​公式のRust ABIはない: Rustには単一の固定ABIが存在しないため、各社が「Rust専用ABI」を提供しているわけではありません。

​「C互換ABI」で実現: いずれのプラットフォームも、Rustの「C言語互換機能（extern "C"）」を利用して、ハードウェアやSDKと連携する仕組みです。

​エコシステムが非常に強力:
​Raspberry Pi: 標準的なLinux環境としてフルサポート。
​Espressif: esp-rs プロジェクトにより、公式SDK（ESP-IDF）との連携が整備。
​Nordic: nrf-rs により、ハードウェアを直接制御するRustネイティブな開発環境が確立。

​要するに： 「Rust用の公式ABI」はありませんが、**「どのプラットフォームも、RustからCの資産やハードウェアを安全に操作するためのライブラリ（クレート）や開発環境が非常に充実している」**というのが実態です。

>>385
C言語でいいんじゃない？
Nordic SDKとか充実しててZephyrとかWest使うと楽だよ

FFIバウンダリでCのABIのまま扱うならRustにする価値無し
しかしRustで扱いやすい形に変換するならCよりも遅くなるのでRustにする価値無し
あれ？

Rust応援隊はここに書き込むとお金になるから必死なんだよな

C応援隊はRustが勢い付くと食えなくなるから必死

のほうが信憑性高いでしょ
食えなくなってしまう😭

WasmがJavaScriptを介してDOM APIを呼び出してるけどそのうちいらなくなる。マイコンも同じ

rust厨はあまりにもrustがさいきょうのげんごなんだあぁああああっていうバカが多すぎだよね

いやここRustスレだし...

C#で食えなくなった😭
https://i.imgur.com/QdnVOt2.png

今やAI使えば誰でもできちゃうから、
そういう自己肯定感を高めることを目的としてRustを使っていた勢はすっかり静かになっちゃったね

そんな障害者たちがいたのか
まあそういう連中はC++だろうがPythonだろうが同じ感じで消えるだろうな
単なる障害者だから

でもバリデーションに.unwrap().expect()だらけの提出やらPRが増えてるのも実感してるやろ
言語がどうよりアホxAIがやばい

AIはunwrap避けるよ
丁寧すぎてむしろうざい
unwrap多いのは手書きじゃないかな

技術寄りのバイコは要領の良さと俯瞰的な技術力が問われるから、
小手先の技に拘るのが楽しくてRustを好んでたような連中には辛い時代だろうな

小手先の技に拘るのはC/C++
Rustは小手先の技が不要になった言語

Rustにもそろそろ覚えるべきバッドノウハウが出てきてる？

Rustにおける「バッドノウハウ」とは、**「言語仕様を完璧に守ろうとして生産性を落とす」ことを避けるための現実的な妥協策**です。
端的にまとめると以下の通りです。

* **所有権の執着を捨てる:** ライフタイムの沼にハマるくらいなら、clone() を使って所有権をコピーする方が健全。

* **型に逃げる:** &str よりも String、構造体参照よりも Arc<T> や Rc<T> を活用し、所有権の管理を単純化する。

* **マクロは最後の手:** 複雑なマクロは保守性を下げるため、関数で書けるなら関数を使う。

* **「実行時チェック」を過信しない:** RefCell などによる実行時借用チェックは便利だが、多用すると設計ミスを隠蔽し、実行時エラー（パニック）の原因になる。

**結論:**
「Rustの理想的なコード」を追い求めるあまり「変更しにくいコード」になるのが最大のバッドノウハウです。**「まず書きやすさと可読性を優先し、パフォーマンスやメモリ効率は必要になった時点で最適化する」**のが現代のRust開発における最適解です。

Struct毎にファイル作る人いるがあれはバッドノウハウだ

書き換えることもないデータのclone()はミニサイズを除き愚か
無意味に同じデータを撒き散らしわかりにくいコードになる

なんでミニサイズ除いたのw
それが答え

参照と同じサイズまでならプリミティブ型がコピー実装しているように参照で持つより値をコピーした方が好ましい
それをRustと関係なく常識

これはRustと関係なく常識

Cが生き抜いた結果
win32apiが現役してしまったからな

マイクロソフトがWindows終わらせないと断ち切れない程に

いうてWinなんてAdobeと一部ゲーム以外は使ってもしゃーない粗大ゴミやしなぁ

>>402
他にもおかしな点
「所有権の執着を捨てる」といいつつcloneで所有権を増やしている点
さらに「所有権をコピーする方が健全」は意味も間違えている
所有権はコピーするものではない

左脳が強そうな回答だ

>>402
よくまとまってる
次からテンプレに入れてもいいレベル

参照を使う方が楽でコードも見通しがいい
C/C++でもデータを毎回コピーするよりポインタで指すのと同じ

>>406
同じデータを撒き散らし分かりにくいコードにする理由できたね

>>402
>所有権をコピーする方が健全。
複オジウイルスに感染してるじゃん

>>402
参照のライフタイムが尽きる時のみクローンするが正解
そうでなければ参照を使う

>>402
なんかデタラメすぎね？

>> &str よりも String

&strが使える場面で敢えてStringを選ぶメリットある？？

>> 構造体参照よりも Arc<T> や Rc<T> を活用

必要ならRc/Arcの活用は悪くないけど
構造体参照よりも、の意味がわからない

​この話がデタラメに聞こえるのは、「Rustという言語の正しさ」を説いているのではなく、「Rustという言語で巨大なシステムを、習熟度の低いチームで運用するための妥協案」を説いているからです。

​良いコードを書くこと（あなたの主張）
​チームで素早く機能を追加し続けること（バッドノウハウの主張）
​この二つは、プログラミングの世界ではしばしば対立します。

​「構造体参照よりも Arc」というアドバイスは、明らかに「Rustらしい設計」ではありません。しかし、「複雑すぎて誰も修正できなくなったライフタイムの沼」を回避するために、あえて速度やメモリを犠牲にしてでも Arc を使うという判断は、実務の現場で（極めて限定的ですが）行われることがあります。

​結論として：
あなたが抱いた違和感は非常に正当です。その主張は「Rustのベストプラクティス」とは対極にある「緊急回避的な戦術」です。もしあなたが「良いRustのコードを書きたい」と考えているのであれば、そのアドバイスは「例外的に困ったときの引き出し」として捉え、基本的にはあなたの考える「Rustらしい設計」を貫くべきです。

>>417
Mutex知らんのか、、、
Arc使うときは大抵排他処理も必要

みんな何作ってるか
4件くらい出てたけど個人的なのが多く実務ではなさそうだが

>>419
デタラメ言うな
Arcの利用にそんな制限は一切ない
排他制御なんて必要ない
例えばArc<String>も使える

ちなみにC++のshared_ptrに相当するのがRustのArc
RustにはArcよりさらにコストの安いRcがある
上述のケースならRc<String>でも十分なので好ましいというだけのこと

読み専用でArc使う

wasmも組込もベンダーの対応まだだし大半が用途のほとんどがバックエンドに留まってる理由がわかった

負債が重すぎる
これは仕方ないね

>>423
wasmのベンダー対応ワロタw
Rustは既にwasmでの利用言語トップだ

WASMってRUSTの良いところをJSでラッピングするもんだと思ってるわ
用途かなり限られてる気がする

WASIを知らずにWASMを語るな

>>426
JVM が高級すぎて言語の選択が狭められたり性能上の限界があった反省から低級指向で設計されたのが WASM だ。
JVM はメソッドの選択などの機能まで JVM 側でやっていて、 Java と違う型システムの言語を採用しにくくなってる。
WASM は架空の機械語としての性質が強くて割とどんな言語でも乗せられる。
その名前 (WebAssembly) からわかる通り元はウェブのためのものではあるが、サンドボックス化が有用と考えられる場面 (つまり主にセキュリティ的に警戒が必要な場面) での活用が広がってる。