Rust part36

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) からわかる通り元はウェブのためのものではあるが、サンドボックス化が有用と考えられる場面 (つまり主にセキュリティ的に警戒が必要な場面) での活用が広がってる。

速くてセキュアなRust
なんて賢い言語なんだ...笑

C++ Liteだよな

確実に動いてからチューニングなのは昔からでしょ。
ピーポーウェアで勉強したぞ。

>>421
Arc<String>の使いどころを本当に理解してるのなら
「構造体参照よりも Arc<T> や Rc<T> を活用」の意味も理解できるだろ

そういうずっと動き続けるわけでもない簡易プログラムならleak()で&'staticや&'static mutへ変換するのが一番簡単
特にStringなら&'static (mut) strに変換できる
Vecも&'static (mut) [T]に変換できる
一般的な型TはBox<T>を&'static (mut) Tに変換できる
所有権の管理から解放されてプログラムが簡単になる

>そういうずっと動き続けるわけでもない簡易プログラムなら
そういう？
どういう？

定期的に再起動する場合を除いてサーバー系はアウトだろうな
常駐しないプログラムならメモリ解放は必要ないな

Rustの意味がなくて草

Rustは日常に使われるアプリやツールを書くのにも使われているもんな
それらはメモリの解放を厳密に管理する必要ないまま動作を終える

やっぱりArc<String>の使いどころ理解してなかったのな

Arc<String>しても共有している間は書き換えできないよ
書き換えないならば
leak()して&'static strに変換してしまえばArc使わずともそのまま共有し放題

そろそろメモリ解放してやれよ

例えば"abcde"と書けば&'static strのデータとしてプロセス動作中はメモリ上に存在し続けて解放されることはない
それを問題視する人はいないだろう

趣のある表紙だ
https://i.imgur.com/7tfDE96.jpeg

まあヒトも動物には違いないしな

もっとC言語寄りの文法にしておけばもっと受け入れられたのに
なぜkotlinみたいな文法にしてしまったのか

>>444
ドットネットの影響受けて失敗した
attribute は受けなかったなあ
public -> pub とかもC言語というよりドットネット言語だしやり直せるならpub 無くしたい

っていう文句ありながらも使い続けてる俺らは真のラストシアンだな

>>443
ManningとO'Reillyを勘違いしてないかい？

小説ラストプログラミングの原著かな

>>444
RustはほとんどCと一緒
決定的に違う点は型指定
Cの型指定方法は最悪で皆が一致してる
変えたことで分かりやすくなり大成功
何が不満？

>RustはほとんどCと一緒
複オジって何でこんな嘘を平気でつきまくれるのか不思議

ループをイテレータで指定もあるよな
あとは誤差かな

LLVM が(汎用のコンパイラ基盤を指向しているはずなのに) C/C++ の意味論を前提にしてる部分が多くて Rust もそれに合わさざるをえなかったという事情がある。

**「LLVMの覇権を揺るがす動き」は、実はもう5～10年ほど前から水面下で、しかし猛烈な勢いで始まっています。**

### 1. 「LLVMを部品化する」革命（MLIR）
LLVMプロジェクト自体が、「LLVMという巨大な一枚岩」の限界を認め、**MLIR（Multi-Level IR）**という新しい基盤をLLVMの中に作り上げました。

* **つまり:** LLVMを「1つのコンパイラ」から、「コンパイラを作るための工具セット（フレームワーク）」へと作り替えているのです。

### 2. 「開発速度」を優先するバックエンド（Cranelift）
Rustコミュニティが育てている**Cranelift**は、まさに「LLVMからの脱却」を具体的に実行している例です。
* **なぜ重要か:** LLVMは「最強の性能」を出しますが、コンパイルが非常に遅い。そこで、**開発中は爆速のCraneliftを使い、出荷用だけLLVMを使う**という使い分けが、現実的な解として定着しました。
* **将来:** Craneliftがさらに進化し、最適化能力がLLVMに近づけば、「別にLLVMを通さなくてもいいよね」という選択肢が本格化します。

* **結果:** LLVMが「Cの呪縛」で最適化を渋るような場所でも、独自の最適化でLLVMを超える性能を出すケースすら出てきています。

### なぜこれが「事件」なのか
これまで「コンパイラ＝LLVM（あるいはGCC）」という**二強支配**でした。しかし、今は**「LLVMはあくまで末端のツールの一つに過ぎず、真の最適化や言語の論理は、言語自身が管理する」**という時代に切り替わっています。

**つまり、今は「LLVMという岩盤を少しずつ砕きながら、その破片を組み合わせて自分たちに最適なコンパイラを再構築している」という、非常にエキサイティングな過渡期なんです。**
この「静かな革命」が今後5年でどうなると思いますか？

C/C++の古くて腐った仕様にどっぷり漬け込まれたLLVMがRustの最適化の足を引っ張っていて両対応のためにさらに複雑化してコードも肥大化して対応してもらうのに時間がかかっているからなあ
いずれ脱LLVMへ

でもllvmが最適化は一番いいから本番だけllvm使って開発中はCraneliftとかgccrsって感じやろ

現状はそう
LLVMよりコンパイルが爆速のCraneliftを開発中に併用は現実的な選択肢

マイクロソフトやアマゾンやインテルなど大手IT企業たちが会員でWASMやWASIなど環境非依存の基盤構築するバイトコードアライアンスがあって
https://bytecodealliance.org/

そのプロジェクトの一つがLLVMに代わるコンパイラバックエンドのクレーリフトなのね
https://cranelift.dev/

元はと言えばみなギークであるという

横文字がわからん

テスト

爆速っていうからどのくらい速くなるのかと思ったら20~30%かよ
爆速の基準が低すぎ

コンパイル速度？通常は3倍速くらいや

爆速というなら5倍は欲しい

5倍速いPC買おう

しかしsccache, moldに加えcraneliftが使えるわけか
オラわくわくすっぞ

すべての事象を無理やりRustサイコーに持っていくエクストリーム競技

Rustのおかげで病気が治りました

Rustのおかげで暇つぶしできます
感謝してます

Rustのおかげでホルムズ海峡が解放されました

RustのおかげでFirefox一強の時代

>>469
Servo「…」

最近のservoはかなりいいぞ
そろそろ用途を限定すれば実用になりそうな気がしてる

FireFoxはメモリ管理などメインはC++のまま人手も資金も足りなくて動きが鈍い
ChromeやEdgeもRustを採用している

ff以外はchromiumしかないから全部一緒

どのメジャーなブラウザも新たな部分からRustで書いてるから一緒

2026年のServoの動向
・2026年4月13日にServo v0.1.0 が Crates.io に公開
・Rustプロジェクトへ cargo add servo で組み込めるようになりエンジンの利用ハードルが劇的に低下
・stable Rust のみで動作するようになりためnightly 依存によるビルド破壊リスクが解消
・LTS（長期サポート）版の提供開始により企業利用を見据えた安定運用が可能に
・ServoのガバナンスはLinux Foundation Europe傘下でIgalia などが主要貢献
・ChromiumとWebKitに次ぐ第三の選択肢としてServoの存在感が急速に高まっている

>>475
こういうの追いかけて調査している人尊敬する
最近変更履歴もあまり追えてないや

>>473
中身わかってそうだから質問
Leptosとかも中身はchromium使ってるの？

>>469
いまだにメインは火の鳥
グーグルは嫌いだから検索エンジンとしても使って無いなあ

>>476
AI回答を尊敬する人ｗ

実際AI丸投げをAI丸投げと把握できない人は、致命的に経験値が無いんだろうし
今後のAIをAIと見抜けない人はAIをまともに使うのが難しい時代厳しいと思う

今時AI丸投げじゃないソースコードやドキュメントなんて存在しなくなりつつあるからナンセンスだな

そもそもRustがFirefoxのために作られたことをすっかり忘れていた件

FireFoxのMozillaがお金ないのため
2021年にIT各大手が共同でRust Foundationを設立
MozillaはRustの商標もコードも関連サイトも全て譲渡した

「単に資金が尽きて投げ出した」というよりも、「Mozillaの保護下から離れ、業界全体で共有する技術（コモンズ）として独立・発展させるための自立化（独立記念）」**という側面が非常に強いのです。

​まとめ
​Mozillaは確かに経営難の時期にありましたが、Rustの譲渡は、Rustという言語の将来にとって最善の選択として合意形成されたプロセスです。Mozilla自身も、現在も主要なプラチナスポンサーとしてRust Foundationを支援し続けており、Rustの成功に深く関与しています。

同時期2020年11月にMozillaは>>475のServoもLinux Foundationへ譲渡している

大手が共同で設立したRust Foundationもお金ないんだけどね

Rust Foundationは参加企業が社員を供出して開発するので、キャッシュの額はあまり関係がない

Rust Foundation 2025年度 損益計算書要約（単位：千ドル）
収益合計：5,100
【内訳】
・開発者・メンテナー支援：1,200 (23.5%)
・インフラ運用・ツール開発：800 (15.7%)
・事務局・管理費：1,500 (29.4%)
・プロジェクト・コミュニティ：700 (13.7%)
・法務・監査・コンプライアンス：400 (7.8%)
・広報・マーケティング：300 (5.9%)
費用合計：4,900
当期残額：200

【ポイント】
・サーバー維持費（インフラ運用）は全体の約15.7%に過ぎません。
・予算の大部分は、開発者やメンテナーの支援、および組織の管理・運営、法務的健全性の維持に向けられています。
・Rustエコシステム全体の持続可能性を支える組織として機能しています。

>>488
内情に詳しいな
こういう人が支えてくれてんだな

公開されているのでは？

企業グループだと各会社の単位で手続きするのが煩雑だから全体の権利を便宜的に所有する会社を立ち上げるみたいなことをするだろ。
なんとかホールディングスとか名前がついてるやつ。
Rust 財団はあれの非営利版みたいなことだよ。
実態としては Rust 関係では大手企業同士が協力していて、 Rust 財団はその拠点であるに過ぎない。
実働している人は各大手企業の中にもいて各企業から給料を貰っているのでそういうのは財団の金の動きとしては現れない。

ラスリナファンデはほぼGAFAMみたいなもん

>>488
想像以上に貧乏だなｗ

せやなあ
可能性から考えれば100倍投入しても変ではない

それは>>487>>491の通りで、開発の主力はMSなどの企業から給料貰って活動している社員なので財団とは別の財布

Mozillaを除くと最大の支援者はAmazon

>>491
お前、持株会社の意味も知らんのか
いつも思うが一般常識無さ過ぎじゃね

営利にしないことでベンダーロックを防ぐナリよ～

一人に深く依存してるZigは怖くて辞めた

そういや、Hoare氏はRustに帰ってこないの？

来ない。Swiftのほうに夢中らしい

創始者が居座ると
個人の好みや信念が客観的な良い方向より重視されてあまりよくない

優しい終身の独裁者

の素質はあるけれど本人がいろいろやりたくて執着しないタイプ
そもそも全てを投入して原型は完成したので居ても意味がないという

優しい（優しいとは言ってない）

Rust応援隊って一人か二人でID変えながら沢山書き込んでるんだよなｗ

またC#アルミホイラーか

MS信者でもない限りC#はプログラミング言語の対象にすら入って来ない

>>505
真面目な話このスレの約1/2は複おじのレス
特徴的なのでしばらく見てればすぐわかるようになるよ

応援隊などという生易しいものじゃなくて盲目的な信者だけどねー

なんで自演してるの？

>>501
従来のSwiftは所有権モデルではなくARC (Automatic Reference Counting)による自動管理だったが以下のように問題が山積みだった
・隠れたコピーが発生しやすくパフォーマンス低下につながる
・参照のライフタイムが不透明でメモリ使用量が予測しづらい
・並行処理で データ競合 が起きる可能性
Swiftは様々な点でRustに遅れを取っていた

そのため昨年までのSwift最新版でRustのような所有権モデルが導入されて以下が追加された

・move（ムーブ）：値の所有権を移動し元の変数は無効になる
・borrow（借用）：値をコピーせず一時的に読み取り共有
・consume（消費）：値を受け取った側が破棄まで責任を持つ
・move-only types（ムーブ専用型）：コピー禁止の型

これではまるでRustだ

ところがSwiftはARCに加えて後付けの所有権モデルなので指定がうざくて使いにくい分かりにくい

・move（ムーブ）例
var name = "Taro"
let newName = move name
// 所有権が name → newName に移動し元のnameは使えなくなる

・borrow（借用）例
func greet(_ name: __shared String) {
print("Hello \(name)")
}
// コピーせず複数箇所で読み取り可能

・consume（消費）例
func consume(_ name: __owned String) {
print("Consumed \(name)")
}
// 消費するため呼び出し元は name を使えなくなる

・move-only types（ムーブ専用型）例
@_moveOnly
struct Token {
let id: UUID
}
// コピー禁止で所有権の移動のみ許可

どこから拾ってきたのか知らんが間違いだらけで呆れる
もうちょっとまともなAI使えよ

間違いがあるなら知りたい

そう　所有　が問題なのだ😂

だいたい合ってる
>>512のコード例はSwift所有権モデルガイドと同じ

Swift 5.11 Ownership Model - Step-by-Step Guide
https://dev.to/qmshahzad/swift-511-ownership-model-step-by-step-guide-172c

appleじゃなかったらrustになれてただろうに😵🌚

Rustから10年以上遅れて所有権モデル導入では代わりになれん

>>516
これガチのフェイクじゃんｗｗ
なんでピンポイントでこんなの引いてくるかなｗ

確かにC#で食えないのは事実だしなw

食ってるやつは居るから食えなくはない
しかし、あなたも食えるわけではないって感じよね

Rustは日本じゃまだ食えんが
求人無いよなぁRust

C#貧民はフェイクニュース流し過ぎ
だから食えなくなるんだよ😭

もう言語とかどうでもいい
偉い人が用意したSDKやライブラリに従うだけ

もうSDKやライブラリのAPIは意識しなくなったな
AIにやりたいこと伝えて、AIが提案したSDKやライブラリにOK出すだけ
もうすぐそれすらも気にしなくなるだろう

雑なフェイク記事に騙される底リテラシーおじさんにホッコリ

真実がほしいって？w
https://i.imgur.com/QdnVOt2.png

>>526
C/C++厨だった

AIが出現しなかったらRustにもワンチャンあったと思う
ご愁傷さま

>>528
AIのおかげでRust利用が広がってる
他の言語よりRustを使うメリットが大きい
最終的にシェアトップになる可能性も

>>528
なぜ知的障害者は謎の念仏を連呼するんだろ

AIに組んで貰えるなら動作早い方がいいし
ブラックボックスになるなら中身は安全の方がいいよね

>>528
むしろAIに書かせられるし
書かせながら学べるからチャンス広がってるだろ
少なくともC++よりはAIと相性良いのは間違いない

終わったのはRustではなく、Rustを使えること自体によって差別化/マウンティングできていた異常な時代
そしてRustが一時期バズっていたのは、まさにその差別化によってシニアを出し抜こうとしていた若い連中のエネルギーによるものだったから、
そういう層にとっては文字通りRustは終わっちゃったんだよね

一山いくらの案件であえてトークン効率の悪いRustを採用するケースは少ないだろうし、
Rustを非機能的な要請から本当に採用したいケースに対してRust使えるだけのジュニアが食い込むのが難しくなったのは確か
異常な時代が終わっただけとも言えるが、いずれにせよRustはもはや夢のブルーオーシャンではなくなってしまった

複おじ並みに視野狭窄
そらマウンティングもされるわ

単なるツールを目的より成功を軸に考えてる障害者
そらなにも成せませんわ

RustでAI使わんな
手で書いたほうが早いし欲しい設計にできるから
細かく設計書作る時間あれば完成版コード書けてしまう
コード書きながら設計するタイプの人間にはAIは使いにくい

ありえなくて草
どんなショボいコードなんだろ

>>536
こういう煽りはいらんわ

単なるツールを目的より成功を軸に考えてる障害者
そらなにも成せませんわw

>>540
コピペするほど気に入ってんのかそのフレーズ

>>537
もちろん完璧な設計をいきなり出来る人は存在しなくて、図で描くか文章で書くかコーディングするか、何らか始めてから不足が見つかりそれを繰り返しながら設計が育っていく。

ま清書用言語ではなくなった感はある

いきなりRustでコーディングを始めながらAIに支援してもらう形が最も効率がいい

AIが清書するでしょ

Rust製zlib実装がIntel CPUバグを回避。C言語なら黙って壊れていた
https://joho-todai.com/rust-zlib-intel-cpu-bug-workaround/

ふーむ、控えめに言って最強

プログラマーが気を揉まなくてもC++よりもコンパイラがよしなにやってくれる楽なC++の位置づけにもかかわらず
一部のニワカプログラマーがjavascriptに変わる高速なスクリプト言語と勘違いして飛びついた結果こてんぱんに打ちのめされたのがRust

ガベージコレクションみたいにメモリを自動的に安全解放してくれるのでRustへ移行したよ

自動で安全になるのはありがたいが逆に細部を自分で制御したい場合に多少の面倒さはある。

>>550
そこで面倒さがRustにあるかね？
まさかの危険なコードよりは面倒とか言い出す？

ご愁傷様です

最強言語は今後300年はRustやな

C++で書いて、AIでRustに移植するのが正解か

低レイヤー同士なら最初からRustだろ

>>554
書きにくいC++で書くメリットが全くない

アメリカ政府「c+からrustに移行汁！ｗ」

AIスレじゃないが
AIに書かせたものはAIにレビューさせないと無駄な手間が増える
今のAIは知ってることとやることがバラバラな分裂症みたいなものだからな
でもこういう自己レビューと修正までオートで回した結果を一発で出せるようにプロンプトやスキル組み立ててるやついるのかな？
もう自己レビューさせたらわらわら指摘が出てくるコードをいちいち見せられるの飽きたわ

Rustはまずコンパイラにレビューさせるから

Claudeは空気読んで迷走しやすい印象だな
対してCodexは比較的straightforwardかつ、明確にスコープを絞ってその範囲できっちり内省して仕上げてくるから
Rust使う人ならCodexの方が好みに合いそう