Rust part34

公式
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 part33
https://mevius.5ch.net/test/read.cgi/tech/1755247770/

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

>>1
O2

go

Rustスレって急に書き込みが増えて急に書き込みがパタっとなくなるよね
不思議

話題がない状態がデフォルト。
誰かが話題を提供したときにそれに乗っかって投稿し始めるからバースト的に書き込みが増えるという普通の話なので Rust スレに限らずだいたい掲示板というのはそういうもの。

Cloudflareの大規模障害は言語としてのアイデンティティに関わるせいか、にわかに勢いづいてたんでは

安全性に関しては、結局前スレ888の
Rustが保証するのはメモリ安全であって、それ以上の機能を言語自体に期待してはいけないね

という話なんだろうね。
リーナスの「ランタイムエラーでパニックを発生させるのは根本的に問題があると思っている」というのはカーネルだけの話じゃなくてもっと根深い話なんだろうね。

>>6
Rustが望ましいという結論が出たことが大きいね
必ずResultまたはOptionが返り値となるため適切な対応がとれる
一方で得られた教訓として異常時にpanicで終了させるべき通常のプログラムと異常時でも動作を続けるべきプログラムの2種類のどちらであるかを正しく認識して設計と実装をすべきと再認識させられた

>>7
Cloudflareの件で論点となったRustの安全性というのはメモリ安全のことではなくて、「未定義動作をしない」という、もう一段広い意味での安全性だよ
panicでシステムが停止したことによって死人が出たとしても、panic自体は定義された動作だからRustの定義上は「安全」なの

Linux対応でRustはpanicさせないAPIが整備されたから今後は明るい展望に変わった

そういや、リーナスに言われて追加した、いろんなとこにメモリアロケータを引数で指定できる仕様はもう安定化したの？

入院はもう少しかかる

入院ってなんだ？

心の病だろ

本当に「もう少し」かあ？

正規表現が標準ライブラリに入らないのはどういう理由なん？
Rust開発チームが管理しているものだし、公式に近いものに思えるけど
LazyCell とかは標準入りしたし、これも標準に入れて欲しい感じがある

1ヶ月ほど前にRust入れたときにVS2022が一緒にインストールされたんだが
VSだけ2026にしたらRustは影響受ける？
むしろRustでもVS2026使った方が良い？
VS2022消してからVS2026入れた方が良い？

>Rustが望ましいという結論が出たことが大きいね
Rustのスキルは低いままなのに詐欺師のスキルには磨きがかかってるな

>>17
消してVSCode入れるといいよ

>>19
いきなり正解、しかもこの質問色んなスレに一週間前から貼られてる謎の質問

何の役にも立たないクソレスとそれを無意味に持ち上げるドクソレスw

Windows環境だとMSVC使うのが基本だし、Visual Studio 入れるのが真っ当じゃないの？
エディタは VS Code でいいけど、Rustが依存するツールとして Visual Studio のコンパイラやリンカは要る

VS 2026 にしても問題ないけど、Rustから C/C++のコードを呼ぶ可能性があるなら VS 2022 は残した方が良い
(cmakeクレートがまだVS2022までしか対応してないので)

>>17
インストール云々は>>22の書いてる通り

Rustの開発でVSを使うかどうかはどの程度のIDE支援を期待しているか次第
VSはVS CodeほどRust関連のextensionが充実してないので

>>22
MSVCターゲット向けに必須なのはリンカとWindows SDKの一部だけでコンパイラは必須じゃなくない？

WindowsでもMSVCツールチェインより、イメージ的には鈍重そうなMinGWのほうが
実は作られるバイナリの動作速度早いんだっけ？

visual studioてまだ使ってる人おるんかな
c++てmsべったりなのがやっぱキモい

Rustも似たようなもんだろ
今やMSが一番Rustに金突っ込んでるんじゃないか?

C++大好きなビッグテックといえばちょっと前まではMSだったけど、
今ではMSがRustに浮気してGoogleが筆頭になっちゃったね

allocator_api #32838
のissue見たら、アホみたいに長くて笑った
何をそんなにもめてるのか理解できない

初心者：C/C++完全に理解した
中級者：C++チョットワカル
上級者：C++嫌い/Cの方が良い
長老：Rust嫌い

MSがRust++を出したら本気出す

大手でRustを使い始めてないのはAppleぐらいじゃないか？

そこはRust#だろ

>>32
AppleもRust使ってるよ

そこはSwiftだろ
Swiftファンに対する裏切り行為だよ

706 デフォルトの名無しさん sage 2025/11/17(月) 09:11:50.77 ID:rk5/i4ud
Rustの求人はここが毎月レポート出してるけど会社名とか見ると結構面白い
https://filtra.io/rust/jobs-report/oct-25
今月は防衛産業のAndurilが求人数トップだね

707 デフォルトの名無しさん 2025/11/17(月) 12:12:35.65 ID:AtT4RnQG
そのRust求人出してる企業一覧すごいな
知ってる企業がずらりと並んでいて感動した
Amazon
Microsoft
Cloudflare
xAI
Apple
Dropbox
Nvidia
Google
SpaceX
GitHub
Mozilla
Woven By Toyota
Discord
Disney
Fastly
Mercedes
Bloomberg
Toyota Connected
Figma
Astral
KSAT
LINE
Akamai
Meta

Adaの後継はRustでウッドボールか

1画面プログラムとか書いてそう

ビルド遅いのなんとかならんのかな
差分だけでええやろって思ところを毎回フルコンパイルしてるように見えるんだけど

分割方法と変更箇所の関係だろうな

sccache入れれば多少は

>>41
sccache制限きつくね？
・インクリメンタルコンパイルされたクレートはキャッシュできない
・システムリンカーを呼び出すクレートはキャッシュできない

コンパイルの効率は悪いよ

そりゃsccacheの制限じゃなくてRustの制限だからさ

言語に関係ない性質

ビルド眺めてたら、最後のリンクするところがクソ遅いな

Rustのcratesって
.a/.soや.lib/.dllをダウンロードする仕組みじゃなくて
毎回ソースが必要なん？

基本的には毎回ソース

コンパイル済みバイナリをダウンロードできるようにする提案は出ているんだけど実現するかどうかはわからんね。

公式じゃないけどバイナリダウンロードできるようにしてるところがあったような

cargo-binstall の話？

>>51
インデックス登録に申し込みが必要なやつだったからcargo-binstallではないと思うけど
今探しても見つからないからそういうバイナリプロジェクトをインストールするやつと勘違いしたのかもしれん

build.rsで生成済みのバイナリ（.rlib）をコピーする形式ならできそうだけど一般公開向けじゃないな

>>53
バイナリだけならunsafeでは

アーキテクチャ分バイナリ用意しないとならなくなるから
結構難しそう

そもそもABIがstableじゃないからコンパイラのバージョン毎に配布しないといけないのでは

だっさ

いろんな環境でネイティブコンパイルする言語だし労力に見合うリターンが無いよなあ
Windowsのことだけ考えてりゃ後はどうでもいいって時代ならともかく

Cloudflareがまたやらかしたな
Rust界の恥晒し

【CDN】米クラウドフレアが控訴、海賊版サイトめぐり「5億円の賠償命令」判決に不服
https://asahi.5ch.net/test/read.cgi/newsplus/1764907388/

>>59
今回の障害が起きたのはFL1（旧アーキ）のみ

>In our FL1 version of our proxy under certain circumstances, this latter change caused an error state that resulted in 500 HTTP error codes to be served from our network.
>Customers that have their web assets served by our older FL1 proxy AND had the Cloudflare Managed Ruleset deployed were impacted.

Reactのサーバーコンポーネントで見つかったRCE脆弱性対応のため、プロキシのバッファサイズを拡大したことによるバグ顕在化が原因とのこと

>As part of our ongoing work to protect customers using React against a critical vulnerability, CVE-2025-55182, we started rolling out an increase to our buffer size to 1MB, the default limit allowed by Next.js applications. We wanted to make sure as many customers as possible were protected.

>As soon as the change propagated to our network, code execution in our FL1 proxy reached a bug in our rules module which led to the following LUA exception:
>[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

Rustで書かれたFL2（新アーキ）で当該エラーは起こっていない

>This is a straightforward error in the code, which had existed undetected for many years. This type of code error is prevented by languages with strong type systems. In our replacement for this code in our new FL2 proxy, which is written in Rust, the error did not occur.

https://blog.cloudflare.com/5-december-2025-outage/

驚いた！Rustすごい！

池沼が

Cloudflareのコンフィグ管理周りの未熟さも気になるが
それ以上にReact Server Componentは仕組み的に危ない

アプリレイヤーでのリクエストbodyのdeserializationにバグがあると
いきなりfull RCEに直結する仕組みとか怖すぎる

もうちょっと警鐘鳴らしたほうがいいんじゃないだろうか

問題は障害がRustに関連したものかどうかではなくて、
Rust採用を大々的にアピールした有力テックの実体がこの程度だったというのを露呈したことだろうな
Rust驚いた勢のプライドを激しく毀損している

警鐘鳴らそうとして実証コード描いたらタイーホされる時代

自作のソフトウェアのコードRustで書いてんだけどやっぱビルド周りが遅いな
cargo testも実行まで時間かかるし
もっと速くならんかな

なんでcと速度は変わらんのにビルドこんな遅いん？

Rustはメモリリーク含めたリスクポイントをコンパイル時点で教えてくれるだけ。
panicで止めるかどうかは、異常系分類による。
停止させると逆に危険な場合もあるので、自前のexceptアナライザーは必須。
とにかく、関心事の放散が防止できれば、メモリアロケーションもリリースもミスは少なくなる。
SOLID原則に従えば、エレベーターも止まらない。　Rustの出発点が変な気もする。
アーキテクチャー不在がエレベーターを止める。

異常系という言葉を気軽に使う人間は絶対に信用してはいけない
重大障害のもと

どういう理屈で？
当該用途にはなんて言葉を使えばいいの？

半永久的に動き続けることが求められるサーバーでは異常系終了を用いない
それだけの話だろう

イージーモード追加してくれんかな
trycatchとかgoみたいなエラー処理やりたい

Goには例外try/throw/catchもなければResultのような代数的データ型もない
Goは多値でエラーを返してif文でそれがnilかどうかを判別するしかなくイージーモードとはかけ離れている

>>72
システム開発における正常／異常系はテストケースの話じゃないの？
異常終了させないためには、なおのこと異常系は肝要なのでは

unwrap()の是非について焼き寿司氏のblog
https://burntsushi.net/unwrap/

仮にリンターでunwrap()の有無をチェックしても
slice[i] や RefCell、場合によっては算術演算のラップアラウンドでもパニックするよ
という指摘にはなるほどと思った

>>76
Linusの指摘そのままじゃない？
「ランタイムエラーでパニックを発生させるのは根本的に問題があると思っている」

OSみたいなクリティカルな用途だから要求も高いというのはあるけど、Rustはc用途を目指しているんだから、他人のコードであってもpanicを制御できるようにならなきゃ話にならんかと。

>>77
std::panic::catch_unwind でキャッチする仕組みはある。
ただ C++ の例外と同じでランタイムサポートの支援で実現するものだから、それより下のレイヤ (OS など) を作ってるときには使いにくいんだよ。
結局のところ OS のレイヤでは C でやってるのと同じやり方でなんとかするしかない。

unwrap()の是非について
https://www.youtube.com/watch?v=TalW9HN9_hI
流行って来た

>>77
slice[i]やRefCellや算術演算で発生するpanicと
OOMをResultでハンドリングする機能がなく避けようがなかったpanicとは種類が違う

前者はプログラムコードのバグ
後者はプログラムコードにバグがなくても環境次第で発生してた

Linusが正確に何と言ったかは知らんけど
環境次第で実行時に発生するエラーを
panicとしてしか扱えなかったことを問題視したんじゃないか？

>>79
複おじに毛が生えたレベルの説明だが
その毛があるかないかの違いが重要なのかもな

iced 0.14.0がリリースされて、ついに日本語入力に対応したらしいよ

> Input method support. #2777

驚き！

なにicedって

UIライブラリや

rustでUIやる意味何？計算量の多いゲームエンジンならわかるけどただのアプリならコンパイルの遅いrustでなんか作りたくねえ

make world と打ち込んで1週間待ってた頃に比べれば全然余裕

Borlandがturbo rustを出すまで我慢だね

turbo visionのcrateはあるんだw

でもgpuiつかったやつめちゃ速くない？
あとrust analyzerのメモリ爆食いどうにかしてクレメンス

実際C++BuilderのGUI生産性と、Rustの言語としての速さと頑強さが組み合わされば無敵じゃね？

まあエンバカデロはもう革新的な製品作りそうにないし
ヘジルスバーグはRustにあまり興味なさそうだけどね

Gemini君に聞いたら、RustはC++のNRVOに相当する最適化をC++よりも広い適用範囲で強力に行います
Destination Passing Style (DPS)
って事らしいけど本当かな？

C++ はオブジェクトへのアクセスが自由過ぎてエイリアス解析が大変 (最適化がしんどい) というのは昔から言われてた。
逆に言えば参照 (オブジェクトの依存関係) を完璧に追える Rust ではもっと上手くやれてもおかしくはないと思う。

面倒くさい奴だけど付き合うと意外と良い奴

>>93
Rustの方針はシンプルかつ効率
関数がレジスタ返しできない大きなサイズのデータを返す時
呼び出し側の関数のスタックフレームに領域を確保
呼び出された関数は最初からその領域にデータを書き込む
もちろんこれらは裏で自動的に行われる

日本語不自由なやつしかおらんのかいな

"Destination Passing Style" で検索するとHaskellの話しか出てこないからハルシネーションか？

RustはUIでも覇権取れる？

はい

C++でもまじめにstd::move()通してればRust並に最適化できるんじゃね？
move後のアクセスをコンパイラが止めないからミスった時に何が起こるか分からんけど

equi

>>101
C++ では返却値は std::move しないのが望ましい場合が多い。
コピー省略できるはずのところでムーブになってしまうことがあるし、ムーブが妥当なときはなにも書いていなくても暗黙にムーブするので書く意味がない。

Rustは概念的には常に自動的にmoveされる
そして生成コードはレジスタ返しか足りなければRVOに自動的になる
だからC++のような複雑さも面倒臭さもない

moveが暗黙で実際どうなんかがわからんのはC++の辛いところ
std::moveって明記してるのにコピーした時は、コンパイルエラーにしてくれてればよかったのに

>>104
現在のC++が自動でRVOになるのは仕様で保証されてるけど
RustのRVOは仕様じゃなく現状そうなることが多い程度の話では？

>>106
むしろRVO以外でどうやって大きなデータを返すんだよ
勝手に裏でヒープでも使うのか？
RVOにならない例を示してみろよ

Rustはできるだけインライン展開してreturn自体を減らしてそう
C++とはコンパイルの単位とプロセスが違うからRVOは重視してないかもしれない

>>107
んな大袈裟な話じゃないし、ボトルネックになってない限り実際にRVOされてるかどうかまで気にする人は少ない
コピーのコストが大きな問題になるようなクソでかい構造体なんて実際問題として滅多にないからね
コンテナは基本的に中でヒープ使ってるってのはさすがに知ってるよな？

non-goalの余白に無限の願望を託す人

>>109
関数からデータを返すだけでヒープを使うのは愚かなことだ
もちろんRustでは戻り型がBox<T>等でなくTそのものならヒープが使われることはないので問題は起きないが

なんでRustはReactに勝てないのか分からんのやが誰か教えてくれ

web apiてなんであんなうんこスクリプト言語で書くってことになったんだろう
js自体の機能てほぼないしweb apiいじってるだけだからcでもいいやん

rustでは値渡しはクローンしなければムーブになるだろうな

>>114
C++のmoveはコピーコンストラクタの呼び出しを回避するのが目的である一方、
Rustの値渡しは(最適化を無視すれば)常に単なるビット毎のシャローコピーであり、RustにC++のmoveに相当するものは存在しない
Rustのmoveは所有権の移動という文脈上の仮想的な操作でしかなく、代入の実行時挙動は一切変化しない点でC++のmoveとは全く異なる概念

JavaScriptへトランスパイルできる言語はいくつかある
TypeScriptは言わずもがなDartとKotlinも公式で保守されてる
JavaScriptを書くために必ずしもJavaScriptを使う必要は無い

>>113

>>112
Webブラウザで動くフレームワークとプログラミング言語を比較するのはヤバい

>>113
JavaScriptは大量のイベントが発生してそれらが非同期に並行して動くけどシングルスレッドだから排他制御は要らないというのが楽に書けるよう設計されてる
Cには無理がある

>シングルスレッドだから排他制御は要らない
お前がそう思うんならそうなんだろうお前ん中ではな

同時実行制御のことを雑に排他制御と呼ぶやつにプログラミングをさせてはいけない
排他制御も同時実行制御もどちらも絶対理解してないから

>>120
誤解してないか？
こういう関係だぞ

https://en.wikipedia.org/wiki/Mutual_exclusion
In computer science, "mutual exclusion" (排他制御) is a property of "concurrency control" (同時実行制御), which is instituted for the purpose of preventing race conditions.

RustのmoveもC++のmoveも、
「(仮に最適化されずとも)構造体のシャローコピーのコストは一般に軽く、多くの場合問題にならない」
というのが大前提なのだけど、>>107>>111は根本的なところを理解してなそう
RustやC++に限らず、GoやC#など構造体の値渡しができる言語に基本的に共通する大前提だね

そういう問題ではない
呼び出し元関数のスタックフレームに直接書き込むのがRVO
配列もヒープを利用しない

レジスタ渡しよりも高速
余分なコードが介在しないCよりも
余分なコードだらけのRustが速くなるとしたらその辺が原因かもな

複オジだらけ

自作自演

>>124
返し値に利用可能なレジスタの範囲内ならレジスタ返しが速い
RVOはそのサイズを超えてから

RVOとは違う話だけどC++は戻り値を std::move した方が良いケースは結構あるぞ
戻り値というか、戻り値の型に渡すコンストラクタに対して渡す時の話だけど
戻り値が std::string や std:: vector をフィールドに持つ構造体やタプルで、最後の return で初期化してるような場合

return { std::move(str); };

こういう場合は str は自動ではちゃんとムーブしてくれなかった気がする
(最近のC++は知らんから、間違ってたら指摘がほしい)

みんな当たり前にC++を引き合いに出しているけど、Rust書いてる人でC++エアプ勢っていないんだろうか

Cのみはいるかもしれないが、少なくともC系統の言語を触れてないと
Rustがこんなに苦労して解決しようとしてる問題への実感が持てなくて
GC言語やスクリプトよりちょっと速いだけの、冗長構文クソ言語以外に感想持てなそう

>>121
何を誤解してると思ったの？

それとその定義だとconcurrency controlは常にmutual exclusionというpropertyを持ってるという関係になるけどCSの一般的定義ではそういう関係ではなくてconcurrency controlを実現する手段の一つとか実現手段の一部という関係

横からだけど、引用文においてもミューテックスは並行プログラミングにおける安全性アプローチのひとつと定義してると思うが
両者共に「並行制御 ⊃ 排他制御」という認識ではないの？
何が論点になってんだ？

>>132
ミューテックスが必要となるのは「並列」プログラミング
拡張ワーカーを使わない限り
JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

>>128
最近のC++では間違い

std::move()を書かなくても自動でムーブしてくれるし、
わざわざstd::move()を書いたことでNRVOを妨害してしまう

>>133
>JavaScriptは「並行」プログラミングかつシングルスレッドなのでミューテックスが不要

そこは JavaScript は並行プログラミング"でありながら"じゃね？
「ミューテックスの要否」は「シングルスレッドであること」で定まり、したがって「並行プログラミングであること」を接続詞"かつ"で「並行させる」のは説明として不適かと

そしてなんについて議論してんの？
おふたりが論点としているものがはたから見ていて判然とせん

>>132が並列と並行の区別ができてないからでしょう

>>136
それは具体的にどの部分からそう読み取ったの？

「シングルスレッドであること」によって、「ミューテックスの要否」は定まる
したがって並列か並行かとは別議論では？
そもそも本件において前者は考慮不要かと

>>137
mutexは同じCPU内の話だから並列＝マルチスレッドでしょ
でも>>132は区別できてなくて並行プログラミングと書いてます
並行プログラミングでは値を同時に更新することがないためmutexは要らないです
並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

>>138
>mutexは同じCPU内の話だから並列＝マルチスレッド

ミューテックスの要否は端的に言えば「共有リソースに対するアクセスの有無」
マルチスレッドは並列を実現するためのいち技術であり、限定するのはミスリード
マルチコア、マルチソケット（NUMAなど）もまたしかり
「同じCPU内」という単位は不正確

>でも>>132は区別できてなくて並行プログラミングと書いてます

「並行制御 ⊃ 排他制御」と同じこと
「並行 ⊃ 並列」で並行は抽象レベルの概念であり、並列は物理レベルの実現方法
前者が後者を含意するのでこれらの記述は極めて自然

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

したがってこれは明確に誤り
>>136 を熨斗付けてお返しいたします

>並行並列プログラミングまたは並列プログラミングの時のみmutexが要ります

同上
レイヤの違う概念、用語を並行させて書いてしまってる
重ねるけれど、ミューテックスの要否基準は「共有状態の同時アクセス可能性」のみ

とりあえず >>121 の引用部分がそもそも間違ってるという主張？
そうであるなら以下に対して反論どうぞ

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

>>139
あなたのような知識が足りなく偏った人を相手にするのは大変だけど
単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ
話題の領域を明確にするために今回はmutexの話だから分散型の話題ではないと限定しているわけ
そういう常識を持たないかあえて無視して無意味に突くだけのダメ人間みたいだからこれ以上はくだらないやりとりしません

>>140
>単に並列プログラミングといえば複数のPCを用いる分散型の並列プログラミングを含むのよ

いやあ、そんなことはないと思うが
少なくともこちらは本件において分散コンピューティングには触れていない

>今回はmutexの話だから分散型の話題ではないと限定しているわけ

心得てるけど
その上で「ミューテックスの要否」は「共有リソースに対する同時アクセスの有無」と言明しているわけであり

あなたが以下のようにミューテックスの用途を誤解、もしくはミスリードをしていたもので、反例をいくつか挙げてわざわざ説明したのであって（マルチコア、マルチCPU = マルチソケット｟同一マシン内のNUMAノード間｠）
マルチスレッドは並列の一形態でイコールではない
共有リソースへの同時アクセスが起こりうるなら、スレッド、コア、ソケットの別なく排他制御はごくごく自然な選択肢
ちなみにNUMAはわかる？複数PCの使用や分散技術の話じゃないよ

>mutexは同じCPU内の話だから並列＝マルチスレッドでしょ

そしてそもそも並列と並行の区別だが、これについてもレイヤが違うと説明したはず
「並行 ⊃ 並列」
並行はより上位の抽象概念だから、並行プログラミングに言及する際、ミューテックス（排他制御）を取り上げるのは当たり前

したがって以下は明確に誤ってるかと

>並行プログラミングでは値を同時に更新することがないためmutexは要らないです

並列だろうが並行だろうが、リソースへの競合状態が起こりえるなら、ミューテックスは要検討

JavascriptのPromise chaining（シリアル実行）は排他制御に含まれると思う
前の処理がPendingの間は次の処理を実行しないから前の処理で更新中のデータが次の処理で参照されない

>>139
間違い多すぎなので正解だけ書くと
並行処理＝同時進行するが同時に実行されることはない
並列処理＝同時に実行されるためメモリ競合などの対策が必要

T型を[T;1]型にするのはゼロコストだよね

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要

教科書レベルのあるある理解（誤解）
既述したよう、並列処理は並行処理のいち手段
「並行」という概念の中に含まれる
それを物理レベルで「並列に処理」（同時実行）するか否かは別議論であり、レイヤが違う

並列でないなら競合しないの？
並列でないならマルチスレッド処理できない？

整理したいけど >>121 の引用部分に異議ある立場？

>In computer science, mutual exclusion is a property of concurrency control, which is instituted for the purpose of preventing race conditions.

「concurrent」をどう訳します？

>>134
不安になって試してみたけど、このケースだと現代のC++コンパイラでも std::move が必要だぞ
>>128 の変数 str の部分を non-copyable なもの (例. std::unique_prt<T>) に変えると、std::move 無しだとコンパイルエラーになる
自作クラスで試しても、std::moveしないとコピーが作られる (外側の構造体そのものはRVO最適化が効くけど、その構造体に渡されるデータは左辺値参照で渡される)

wikipediaを見る限り>>143の区別みたいよ

>並行計算は、並列計算（parallel computing）としばしば混同される。
>
>並列計算はマルチプロセッサ前提であり、独立した各プロセッサが割り振られた計算を同時実行することを指す。
>故にシングルプロセッサでは不可になる[2]。
>分散システム内の各コンピュータが割り振られた計算を同時実行するのもそうである。
>
>並行計算は一つのプロセッサに複数のタスクを存在させて、各タスクに計算を割り振ることを指す[4]。
>そこではタイムシェアリング技術などが使われる。

>>132
AはBのproperty(特性/性質/属性)の一つという定義と
AはBを実現するアプローチの一つ定義は同じではないよ

これはどっちかが絶対的な正解という問題ではなくて
mutual exclusionをどういう意味範囲で使ってるかの問題

compare-and-swapのようなatomic operationでも
レイヤーを掘り下げればクリティカルセクションがあって
mutual exclusionというpropertyを持ってると考えるなら
wikipediaの定義でもおかしくはない
(一般的かどうかはさておき)

あと何を誤解してると思ったのかは書いてもらわないとわからん

>>133
1. ミューテックスと排他制御(mutual exclusion)を区別しよう
ミューテックスは排他制御を実現する方法の一つで
locked/unlockedの状態を管理する変数だったり構造体だったりの実装のこと
排他制御(mutual exclusion)という概念とは別もの

2. ワーカーを使わないシングルスレッドのJavaScriptにおいて排他制御は不要か？
もちろん必要
https://web.mit.edu/6.102/www/sp25/classes/16-mutual-exclusion/

3. ワーカーを使わないシングルスレッドのJavaScriptにおいてミューテックスは不要か？
ミューテックスが必要な状況ももちろんある
例えば複数のダウンロードリクエストを並行処理しているダウンローダーで
特定のサイトは最大1コネクションのダウンロードしか許可しておらず
複数同時ダウンロードをすると全部強制終了されてしまう状況とか

>>149
無知だな
基本を分かっていない

ミューテックスはマルチスレッド時に同時アクセスの競合が起きる可能性がある場合に用いてスレッドを待たせる機能がある

特定のサイトは最大1コネクションのダウンロードしか許可してない場合
ワーカーを用いないJavaScriptは並行処理なのでミューテックスは不要
単なるカウンター変数のみでよい

>>143
>並行処理＝同時進行するが同時に実行されることはない
>並列処理＝同時に実行されるためメモリ競合などの対策が必要
一般的な定義からすると↑これはどっちも間違ってる
並行処理は同時実行されてる部分もあれば同時実行できない部分ももある
同時実行できない部分の制御のため競合対策が必要

並列処理は同時実行可能な処理を指すので競合対策は不要
同時実行できない処理を並列処理とは普通は言わない

>>151
wikipediaの記述やそこで引用している参考文献が正しい
あなたが間違っています

>>150
>単なるカウンター変数のみでよい
それはカウンター変数をミューテックスとして利用しているってことなんだよ
>>149をもう1回読んでね

現実的には単なるカウンター変数をミューテックスとして利用するだけではダウンローダーに必要な機能を満たせないからキューイングできるタイプの非同期ミューテックスを使う

>>153
いいえカウンター変数とmutexは異なります
mutexは他のスレッドがロック中にスレッドを待たされる機能と利用が可能になったときに再開させる機能を伴います
その効率のためOSが提供するfutex機能を用いてmutexを実装する環境が多いです

>>147
参照された記事には並行処理における競合対策は不要と記載されていました？

また、「コンピューティング」という、物理、実装を意識するレベルでの具体的差異をこちらは否定していない
その前段となる概念レベルの関係についての言及であり

>Concurrency is a broader concept that encompasses several related ideas, including:
>Parallelism (simultaneous execution on multiple processing units). Parallelism executes tasks independently on multiple CPU cores. Concurrency allows for multiple threads of control at the program level, which can use parallelism or time-slicing to perform these tasks. Programs may exhibit parallelism only, concurrency only, both parallelism and concurrency, neither.
https://en.wikipedia.org/wiki/Concurrency_%28computer_science%29#Related_concepts

実際に並行、並列処理の実装にあたっては、物理、ハードウェア的な制約に基づき、当然、両者は弁別される
言うまでもないがシングルコアにて並列処理は実装できまい
さりとて逆もしかりとならないわけで
前者は後者を包含している、後者は前者の下位概念であり、具体的な実現手段
「並行 ⊃ 並行、並列」のように概念のポケットに、それとは別に具体的技術としての「並行」「並列」が入るイメージ

そして繰り返すけど、本件論点は競合考慮、ミューテックスの要否では？
並行プログラミングする際、これを不要とする立場？

>>156
並列を用いない場合＝マルチスレッドを用いない場合＝シングルスレッドの場合、
並行処理でメモリアクセスが同時に実行されることはないためメモリ競合は発生しない。
つまりカウンターやフラグなどあらゆる変数についてMutexを用いる必要がない。

これはJavaScriptだけでなくRustでシングルスレッドで非同期タスクを並行処理する場合も同じ。
具体的にはtokioのspawn (並行＆並列)はSendトレイト境界があるため変数共有にMutexなどが必須だが、
spawn_local (並行のみ)はSendトレイト境界がないためMutexは不要という形で表れる。

関連型ってT<U>みたいな型依存型ができないからその代用だよね

シングルスレッドでも２つの非同期処理がawaitを挟んで同じメモリを参照・更新する時は
data raceのリスクがあるから気をつけてくれ
Rustの場合は&mutが他の参照をブロックするから問題になりにくいけど

日本語より
concurrent
parallel
distributed
で議論した方が良いと思うの
https://zenn.dev/koron/articles/3ddcaaeae37f9befdf70

並行はヘテロ
並列はホモ

同時アクセスの可能性があるものにmutexでロックかけろってだけじゃないの

>>162
原則としてはそう。
ただ、データ競合は阻止できてもデッドロックは阻止できないし、性能的に改善できる余地もあるから唯一の正解というわけではない。

>>162
Mutexは別々のスレッド同士が同時アクセスするデータ競合を防げるよ
通常のstd::sys::Mutexだと既にロックを持っている同じスレッドでロックしようとすると動作の保証はなくてパニックするかデッドロックするかなど環境依存なので用いてはダメだけど
つまりそれはマルチスレッド用

一般的なアプリケーションプログラミングにおいては、排他制御の対象はデータというよりコードの特定のセクションであることが多い
当該セクションで扱うのが単一のデータストアである場合はそのデータストアに対する単純なロックに帰着するが、実際にはそうでない場合も多い

ケントンプソンに書き直してもらったほうがいいだろこの言語

自演するにしても、逆に自演ってバレバレになる1レスごとルーパチじゃなく
せめてWi-Fiとスマホ回線でやればいいのに

>>157
まず初手の等式がぶっ飛んでいる
並行、並列という処理の性質とその処理を実際に行う際に用いるモデルの話は直交概念、因果の幅跳び甚だしい
「並列でない」ことによって、ただちに「マルチスレッドでない = シングルスレッドである」ことは定まらないため、「シングルスレッドで共有メモリを同時に操作可能な実行主体が一つしか存在しない」ことは担保しえない
ミューテックスの要否は「共有メモリに対して複数の実行単位が論理的に同時アクセスしうるかどうか」で、「物理的に同時実行されない」ことは必ずしもメモリ安全性を意味しない
すなわちコア数（並列か否か）とマルチスレッドのいかんは別議論
並行処理の実現手段としてマルチスレッドを用いたならば、メモリ競合は生じるし、したがってミューテックスも要検討
重ねるけれど「シングルスレッドである」とする際に、それを前提するのが「並行処理である」からというのは因果の車がパンクしている

>>168
Rustでは>>157のように実装されているのだから君が間違ってるよ

>>169
具体的に何が >>157 のように実装されているという話？
こちらの間違っている点はどこ？

>>170
明確に>>157に書かれているのに理解できないならRustを使ったことすらないんのかな
長文で屁理屈を連投するけどRustの話が全く出てこないので怪しいと思っていたけど

>>171
明確に前半後半で議論が分裂しているね
そして >>168 の指摘は前半の並行、並列、スレッド、競合、ミューテックスなどへの胡乱な認識に基づく主張、説明に対するもので、後半にて言及されてる「シングルスレッド」などに見られる条件下を前提としたケースについては触れていない

前半部分の指摘については既述のとおり
後半については指摘というより、並行、マルチスレッドなどの話で「Rustの話が出てこない」という反論かます時点で概念理解は推して知るべし

おそらく経験した個別ケースを安易に一般化してしまっており、自身の使っている用語が概念、実装、結果のどこに属しているか意識もあまりしていないのでは
だから乱暴な等式を使い、平気で一般化してしまう
Rust（tokioのexecutor）に見られる「設計上の制約（単一スレッドであることを保証）」は、「並行処理」一般とは議論のレイヤがズレている

そちらの議論に合わせるとすれば、spawn_localがmutex不要なのはexecutorが単一スレッドであることをtokioが保証しているからであり、「並行処理だから」が理由ではない

>>172
非同期タスクで並行処理するためのランタイム基盤がRustのtokio
tokioでも並列処理をしない限り並行処理だけならばメモリ競合は発生しない
そのためミューテックスも当然必要ない
これは言語やランタイム基盤の種類に関係なく常に成立する

相変わらず複数データの排他制御を理解していない複おじ

>>173
mutexは必要がないだけでなく使用禁止が正解だよ
同じOSスレッド同士でmutexは機能しない

複数データの排他制御ってなんの話？

LinuxついにRust公用語に

>>173
だから安易な一般化
「並行処理 = 非同期処理」と認識してない？
そちらの主張はtokioをはじめ、その中においての業界標準、常識であって、外に出たら通用しない
「並行処理」におけるメモリ競合の有無やミューテックスの要否じゃなくて、それを実現する実装手段の内側世界における議論

それらを前提してるから、「並行処理 = シングルスレッド = 競合しない = ミューテックスは必要ない」と因果を逆立ちさせてしまう
>>157 のレスを引くなら「並行（非並列） = シングルスレッド = spawn_local = Sendがない」ではなく、「spawn_localを選ぶ = tokioがシングルスレッドであることを保証 = スレッド移動がないためSend不要 = 結果として並行（非並列）になる」が正しい因果

設計段階で「並列か否か」をまず決めて、それに応じたexecutorを選択し、その結果、実装者の期待どおりに「並行（非並列）」or「並列 & 並行」となるわけで
これが本来の思考、理解の順序であって、逆にするから概念自体が胡乱げになる

「非同期処理」に限るのであればいざ知らず、そうでないなら、つまり「並行処理」一般に議論のスコープを広げるのなら、そちらの因果理解は破綻する

>>178
長文くん邪魔だからさ
これ以上中身のない妄想の机上の空論を続けるのではなく、
キミが言う並行処理を実装してるクレートか何かをまずは持ってきなよ

もう並行処理専用スレを作って移動してほしい

長文は読んでないが>>157の複おじの主張に沿うと
実行環境がシングルコアならマルチスレッドでもマルチプロセスでも真の並列ではないから
「カウンターやフラグなどあらゆる変数についてMutexを用いる必要がない」ってことだな

あほらし

今回得られた結論は以下の2つ

1. 「JavaScriptはシングルスレッドだから排他制御は要らない」などと言う人は排他制御を全く理解していないということ

2. 概念と実装の区別ができない人はその概念に対する理解が決定的に欠如しているということ


複オジ先生、反面教師役お疲れ様でした。

複おじは日下部陽一先生と知りあえば仲良くなれると思う

>>181
>>182
あなたは勘違いしてるから解説書や仕様書などまずは基本を勉強した方がいい
ミューテックスはスレッド間もしくはプロセス間で使われると明記されている
そして同一スレッド内でミューテックスを用いた場合の動作はは環境依存になる

Rustの標準ライブラリのMutexでも同様でロックされている状況にて同一スレッドでロックを試みた時の動作は指定されず関数から戻ってこないままpanicやdeadlockなどになりうると明記されている
つまりMutexはシングルスレッド内で用いてはいけないものなのだ

シングルスレッドだからメモリ競合は発生しないって主張が地雷なんだよな

複数の非同期処理で共有してる&Cell<T>の値はawaitの前後で書き換わってる可能性があって
await中の別処理での変更を無視するとマルチスレッドのメモリ競合と同じ不定状態になる
この場合シングルスレッドだからMutexは必要ないというより使えないんだけど
Mutexが必要ないor使えないからメモリ競合は存在しないって結論出すのはやめてほしい

変なタイミングでawaitを挟まなければ回避できる話だから大した問題ではないけど
問題の可能性を理解せずに「メモリ競合は存在しない」って信念を持たれるとこわい

>>185
それはメモリ競合とは言わない
そこにメモリ競合は存在しない

まーた副クン一人で頑張ってるの？
IDコロコロして頑張るねえ

複数CPUからの同時アクセスを制限するものだけを Mutex と呼ぶなら
tokio::sync::Mutex についてはどうなんだ？
これはシングルスレッドのランタイムでも使われるものだし、名前の通り Mutex と呼ばれるものの一種だと思うけど

>>185
>変なタイミングでawaitを挟まなければ回避できる
OSが複数スレッドの実行をインターリーブするのと同じで
タスクも効率や公平性のためにawaitを入れてインターリーブさせるべきケースというのがある
>>149のダウンローダーの例とかね

メモリ競合・データ競合は複数のスレッドもしくは複数のプロセスが互いにどこを実行している知らなくて制御できなかったり不意打ちで切り替わりえる状況で起きるんだよ

>>185
一方でそのケースはシングルスレッドで利用していればそんなことは起きないためデータ競合ではないね
awaitから戻ってきたら値が書き換わっていたというのは関数呼び出しの連鎖から戻ってきたら値が書き換わっていたのと同じようなこと
制御できない知らぬ間に値が書き換わるわけではないためデータ競合とは呼ばれない

競合の話となると特に造語が捗るようですねえ

メモリ競合もそうだけど
データ参照の競合って何だったの？
https://mevius.5ch.net/test/read.cgi/tech/1722354386/966-983

さてと
linuxカーネルはrust化されないとか言ってた低学歴在日朝鮮人の恥ずかしい書き込みを発掘するか

Linuxって使いにくい　古～いUnixを未だにひきずってるから
Linuxに拘る必要あるんだろうか？
もういっそのことすべてを新規設計にしてLinuxに代わるオープンソースOSにして欲しい
モデルにするのは…MSはMSで変に使いにくくしていってるとこあるから、この両者の悪所を全部取り除いたやつにして欲しい

複おじみっともないからそういうのやめなって

排他制御で恥を晒した某オジさんがいつものように別のネタで話題をそらしたいわけですね

Rustがこんなにも多くのアーキテクチャを葬ってしまうのか

https://x.com/ebisan2015/status/1999437822798045373

unix作者はgo作ったしlinuxメンテナに入れて上げたらinじゃねーの？

>>196
s390とホビーじゃねえぞ

Qiitaスレに逃げてんじゃねーよ

>>193
firefoxすらRustで書き直せないのに無理
ていうか、Rustはｵﾜｺﾝ

Go のランタイムがやってる平行処理 (goroutine) は本当は OS でやりたかったが Linux にかわる OS を作るのは非現実的だから諦めたとは聞いたことがあるな。
単純な話としてアプリケーションが Linux の仕様に依存しきっているから Linux のしがらみを捨てた新しい OS を作ったら全てのアプリケーションが作り直しだ。
インフラは正しくあることよりも安定していることが重要であるという Linux 哲学により、改善によって既存のアプリケーションが動かなくなるならその改善はしないことになっている。(深刻な脆弱性ならやむを得ず修正することはある。)
つまり Linux は長期的に安定してバイナリ互換性を維持していて、更にはこれからもそうであると信じられているから今の地位にあるってことだ。 Windows もそう。
機能・性能の良さより長期的な信頼が大事で、それを得るのは本当に困難な話。

新しいOSに引継ぎのためのWSLのようなのを積んじゃえば

BeOSやTRONのようなのでもよかったんだけどなあ
BeOSはなぜかすぐに消えちゃったね、TRONはお国の事情で…

>>201
goroutineはプリエンプティブつまり強制中断スケジューリングなので個別にスタックを持たなければいけないけど
Rustの非同期タスクはawaitでスケジューリング切替なのでyield_now等で自分で制御できるメリットとスタックを持たなくていいメリットがあるね

おじはなんで188だけガン無視なの

もう敗北を認めてるからでしょ

Rustに勝つのは無理すぎる

せっかくノリノリで自演再開したのに蒸し返された途端に止まるの笑える

どういう指標において？
例えば「開発者の人口の多さ」なら主要言語の中では下位だし、そんなもの切り口によりけりだろ

tronはスウィッチ2のコントローラで活躍しとるでぇ🧐

活躍ではないかな

NeXTは死にかけのところをあやうく拾って貰えた
BeOSの方がmac後継の有力候補とまで言われていたのに
ここまで立場がひっくり返るとは

マイナーアーキテクチャ対応はgccrsプロジェクトの成否にかかってると思うんだが
現状どうなってるの？

そんなもんお荷物になるだけだから失敗してくれた方がいい
最新エディションへの対応が遅れる(or放棄される)のは目に見えていて、
ライブラリがそれに引きずられて最新エディションへの移行を渋るようになれば、
俺達イケイケ最先端ウェーイでやってきたRustコミュニティの自尊心に致命的なダメージを与え、開発者離れを引き起こすことになりかねない

アーキテクチャのLLVM対応はベンダーorメーカーの責任では
売りたいなら真っ先に用意するだろうし時代遅れでコストに見合わなければ切り捨てられる

というかgcc対応の本命はrustc_codegen_gccの方じゃない？
最近はRust本体のCIでもテストされるようになってきたし、rustupでの配布も計画されている

>>216
rustc_codegen_gccはrustcのバックエンドとしてLLVMと同様の立ち位置なんだよね
だから>>214の問題は起きないメリットが大きい

bincode がサポート終了になったみたい
それなりに広く使われてるクレートでも突如消えることってあるんだな、と改めて思う…

メンテナの一人が他のメンテナに相談なく脱GitHub作業を始めて履歴の書き換えとかをやりだして揉めたけど
その渦中のメンテナがトランスジェンダーのポリコレだってことで
実名と住所を晒されて、責任取ってプロジェクト自体終わりってことになったのか

devでtestで用いてるクレートが多いな

>>217
rustc_codegen_gccがお荷物になってライブラリではなくてRust本体への変更が遅れるデメリットはある

そこはこれまでもrustcとLLVMとの間の調整でやって来たことだから新たな影響は限りなく小さい
一方でRustの仕様追加変更や標準ライブラリの追加安定化などは当面rustcまわりでの独裁決定事項であることが成長中のRustにとって好ましい

bincodeの件、斜め読みしたけど、こんな感じじゃない？

1. 生成AIのクソissueにブチ切れる
2. 脱GitHubを実行
3. ついでに、トランスジェンダーの関係で改名した新しい名前を使って過去のコミットを書き換える
4. しばらく誰も気づかない
5. 誰かがコミットIDが書き変わってることに気づく
6. うわーサプライチェーン攻撃だーと大騒ぎする
7. 騒ぎの中で、作者の実名や住所を公開する奴が現れる
8. 作者がブチ切れて、メンテナンス終了を宣言
9. ついでに、作者名の欄を独立して編集できないcrates.ioがクソ、と意見

>>221
RFCが承認されてから10年経っても実現できない機能がいくつもある言語だからな
その程度のデメリットはいまさらだろ

ハッシュマップってハッシュ値を保持して値を調べるんじゃなくてキーも保存するんだな
保存したくない場合はキーを完全ハッシュ値にしてハッシュ値をキーにしないとだめだな

キーを保存したくないならHashSetの方があってそう
値にEqが必要だけど完全ハッシュより現実的

恐ろしい誤解だなと眺めてたら
さらに恐ろしいのが来た

>>225
HashMapはハッシュ値を保持しない

>>226
HashSetもキーを保持する

この場合のキーはHashMap<K, V>のKのことだろ
HashSet<T>のキーってなんだよ
ハッシュ値のこと？

検索に使うオブジェクトがキー。
HashSet は値が常に () であるような HashMap だと説明されてる。

普通のハッシュマップは何もしないハッシャーを実装すれば出来るな

Rustの前に基本情報あたりを取る勉強したほうがいいんじゃないか
古臭いのが多いとはいえ応用は基礎の積み重ねの上にあるからな

rustってグローバル変数が使えないんだよね。dfsつらくない？

DFSのためにグローバル変数？？
プログラミングを基礎からやり直したほうがいいぞ

Rustちょっとビルドの度に数分単位の時間掛かるのなんとかならんのかね
多分プロダクションビルドだけでやればいいような最適化とか毎回回してるよねこれ

>>235
マクロのせいでしょ

でかい依存ライブラリのリビルドが必要になったならまだしも自分のコードのインクリメンタルビルドだけで数分もかかるようならマシンのアップグレードを検討したほうがいいかもしれない

Windowsならアンチウイルスのせいかもね

>>235
少なくともデバッグビルドのデフォルト設定では最適化は控えめだよ。
単純にリンクが遅い傾向にある。
Rust プロジェクトの典型的な設計がリンカには負担がかかってしまう要素が多いらしい。
変更が少しだけでもリンカの仕事の量は特に変わらないし。

インクリメンタルリンクをサポートしたリンカ Wild が開発中で、開発中のリンク (修正を少しだけした場合のリンクしなおし) を爆速にする計画は進んでいる。
インクリメンタルリンクは構造がかなり複雑になるので複雑な処理と速度を両立できるのか疑問視されていて従来のリンカ開発者は消極的だったんだが
Rust でなら複雑さと性能を両立したリンカを書けるという自信があるらしい。

C#みたいにプロセス起動したままホットリロードできるようになるのはいつ？

ビルドする時間帯によっては依存cratesの更新確認だけで待たされる時があるな

>>241
その仕組みのない言語はやばい

Rust はシングルバイナリ指向なのでホットリロードは想定してないがバイナリを分割すれば (ホスト環境によっては) 今でもホットリロードできる。
実行環境次第。

ホットリロードが欲しいのはGUIみたいに「ちょっと変えて試す」をしたい分野だと思う
それはRustの得意分野でもないし、そこはC#やJSで良いじゃない
Rustが向く分野とそうでない分野があるというだけの話

ホットリロードはWEB APIにこそ欲しい

>>241
何時間も待たされて(ちょっとずつは進んでる)眠くなったのであきらめて
次の日やり直したら一瞬で終わったことがある

>>243
その仕組みのないOSはやばい

明示的にアップデート指定した時以外はイチイチ外部パッケージのダウンロード＆再コンパイルとかやらないで欲しいな

>>248
クレイト使用バージョンを指定してないからでは

hoge = "1.2.3"
よりも
hoge = ">=1.2.3"
よりも
hoge = "=1.2.3"
推奨ですね判ります

Microsoft、2030年までにC/C++廃止を目指す
https://softantenna.com/blog/microsoft-c-to-rust-2030/

> 私の目標は、2030年までに Microsoft から すべての C と C++ のコードを排除することです。そのための戦略は、AI と アルゴリズムを組み合わせて、Microsoft が抱える最大規模のコードベースを書き換えることにあります。

> マイクロソフトの大規模C/C++システムをRustへ移行する

マイクロソフトに限らず2030年代にはどの企業でもC/C++全廃してるでしょ

>>251
>「Galen 氏の発言を Microsoft 全体の方針と見るな」という冷静な指摘も行われています。

はいおつかれ。解散解散

お前らもExcelのマクロをRustで書きたいだろ？

1ヶ月で1人あたり100万行のC/C++コードのRust化って
コーディングもレビューもテストすらAI丸投げで
誰も確認しない感じじゃないと不可能だよなあ

実際にはWindowsをRustで書き換えるんじゃなくてWindows付属のアプリケーションをRustに置き換えていくんじゃないかな
人を集めるために大きいことを言ってるんだと思うよ

そりゃ Rust のほうが良いとは思うが書き換えとなると書き換えに伴って発生するバグだってあるし、十分に安定している部分まで慌てて書き換える合理性がない

そう言ってるわりにVisualStudio2026でRust対応しなかったよな
結構くるんじゃないかって期待してたんだけど

Rustに書き換えたところで何かが改善されたというアピールがしにくいんだよね
速くなろうがエラーがへろうがそれが置き換えによるものなのかって切り分けにくいだろうし

何かRustコンパイラをMSが自作する必要に迫らればVisual Studio入りもあるだろうけど
結局rustcとrust-analyzer頼みならVsCodeでいいじゃんで終わりそう

処理系が少ないのは健全な状態ではないからマイクロソフトにも手をつけてほしいが、現時点では Rust の言語仕様の文書化があまり進んでないからな……。
https://github.com/rust-lang/spec
リファレンスマニュアルだけで十分に互換性のある処理系を作れるとは思えないし、やるにしても時期尚早かもしれない。

vsてcodeの劣化版でしかないのにあれをまだ使ってる人おるんかな

>>262
VSをエディタとしてしか使ったことないんか？

バルマー時代のMSならいざ知らず、今のMSが今更わざわざWindows専用の新しいツールチェインなんか作るわけないでしょ

Arm版Windowsなら可能性あるかもね。

x86windowsは過去互換性が重要だから互換層をたくさん用意する必要がある。互換層はunsafeまみれでpanicリスクのあるコードになるから、Rustの強みは活かせないだろうね。

Arm版もどっこいかな
結局Rustが使われるとしたらシステムよりもアプリケーションだろうね

Visual R++やぞ

VSやVCそのものがRustで書かれるのは歓迎だがR++は要らん
そもそもRと間違われるやろ

>>251
>「広告表示を許可してください」
はい解散解散

>>267
統計に強くなりそう

>>265,266
Windowsは内部からAPIまで循環参照だらけ

windowsたまに使うとずっとディスクアクセスしててこわい

SSDの寿命あっという間

パソコン、機械のブラック20とそれ以降代入の自動設定プログラムオートセットコード20について



プログラムセットオートコード20

ダイダロディクス20

これがおおざっぱにいって船や重工業用機械向け




プログラムセットオートコード20

バイバロニック20

これがおおざっぱにいってパソコンや家庭用軽機械向け






プログラムセットオートコード20図

左上に船や機械の名前、中央に船の概略図、右下にブラック20とダイダロディックス20
、バイバロニック20などの名前、左下にその船や機械の状態。

パソコンや機械を作る場合は正しく、確認するように。

パソコン、機械のブラック20とそれ以降代入の自動設定プログラムオートセットコード20について



プログラムセットオートコード20

ダイダロディクス20

これがおおざっぱにいって船や重工業用機械向け




プログラムセットオートコード20

バイバロニック20

これがおおざっぱにいってパソコンや家庭用軽機械向け






プログラムセットオートコード20図

左上に船や機械の名前、中央に船の概略図、右下にブラック20とダイダロディックス20
、バイバロニック20などの名前、左下にその船や機械の状態。

パソコンや機械を作る場合は正しく、確認するように。

引用
>>あなたはマイクロソフトのことを全く知らないようですね。
マイクロソフトは互いに憎み合うサイロ化されたチームで構成されているんです。
ジェフリー・スノーバーは、解雇の危機を覚悟でPowerShellとWindows Server Coreを発明しないよう警告されました。
しかし、解雇されたわけではなく、降格させられました。
彼はテクニカルフェロー（Microsoft最高位）まで這い上がりましたが、Windowsチームは抵抗し、
PowerShell 5.1以降のバージョンは統合されませんでした。
スノーバーは2022年にMicrosoftを去りました。他に誰がMicrosoftを去ったかご存知ですか？
マーク・ルコフスキー（バルマー氏の椅子投げ事件の犯人）と
ニールス・ファーガソン（21年間Microsoftに勤務。
英国内務省がBitLockerにバックドアを要求した際、「死んでも構わない」と断言しました！彼はまだ生きています。）
ハントより上位の人物は既にマイクロソフトを去り、彼らのビジョンは実現されていない。
今、この世間知らずの成り上がり者は、マイクロソフトで最も古く、最も実績のあるコードをRustに移植しようとしている！
一体何のために？誰かがRustを神聖視しているのだ。
取締役会は、彼のプロジェクトの費用と利益の少なさを目の当たりにし、次の決算説明会で彼を解任するだろう。
>これがMS帝国ってわけ
言語もフレームワークも開発環境もぜーんぶ縦割り行政のお役所仕事で､縄張りと予算を奪い合う派閥争いを
延々と繰り広げてるんだからそりゃうまくいくわけねーわなwww

Hunt本人は火消し中
何の基幹決定もなくこれまで通りで、ただのポジショントーク

Update:
It appears my post generated far more attention than I
intended... with a lot of speculative reading between the
lines.
Just to clarify... Windows is *NOT* being rewritten in Rust
with Al.
My team's project is a research project. We are building
tech to make migration from language to language
possible. The intent of my post was to find like-minded
engineers to join us on the next stage of this multi-year
endeavor—not to set a new strategy for Windows 11+ or to
imply that Rust is an endpoint.

自由な社風なんだね

米国の企業文化として、個人の責任においての情報発信については比較的寛容な傾向がある
SmartHRのチンパンジー事件みたいなポリコレ的にヤバいのは一発で首が飛ぶだろうが

この図式か
https://i.imgur.com/NZEBKEV.jpeg
https://i.imgur.com/bvrIEQc.jpeg
https://i.imgur.com/3sUSVIT.jpeg
https://i.imgur.com/r8o0gWD.jpeg
https://i.imgur.com/4fA7gcc.jpeg
https://i.imgur.com/NUVsnuR.jpeg
https://i.imgur.com/gNP6w6m.jpeg
https://i.imgur.com/8XSGI4Y.jpeg
https://i.imgur.com/hpvnSsA.jpeg
https://i.imgur.com/k7xHbKl.jpeg
https://i.imgur.com/Mj7BIOO.jpeg
https://i.imgur.com/Jf0KYfG.jpeg
https://i.imgur.com/nW3JL7o.jpeg
https://i.imgur.com/8Q9YYgW.jpeg

一枚で言うと
https://i.imgur.com/dsem2je.jpeg

windows クレートを使ってプログラムを書こうとすると VSCode (とやり取りする rust-analyzer) が型を導出するのに失敗するらしくことごとく ! と表示される。
rust-analyzer の限界っぽいのでこれは現時点ではどうにもならないもんなの？
型がわからないとメソッドの補完も駄目だから結構きついんだけど。

>>282
標準ライブラリの std::os::windows と競合してる可能性がある
もしソースコードの先頭に use std::os::windows と書いてあるなら、それを外してからコードを書き直してみると良いかも
インテリセンスは両方を提示してくるから、windowsクレートの方を選んで tab キーを押す
(そうしないとファイル先頭に自動的に use std::os::windows が自動挿入されることがある)

他の可能性として、 windows クレートを追加した時にフィーチャーフラグを指定してない場合は、中身がほぼ何も無いためにインテリセンスが効かない可能性があるかも
公式のドキュメントを読んで、使いたい機能に応じたフィーチャー (例. Win32_Foundation) を有効化する必要がある
かなり細かく分かれてるので注意

webフレってactixとaxumがスター数いっしょだけどどっちがいいの？まだデファクトはない感じなんかな
goのwebフレ触ったあとこれやるとdieselとか書くのめんどすぎ

tauriでええんでね？

>>285
うん
UIはJavaScript系が安定してる

>>283
ありがとう。
cargo build は可能な状態なのでそのへんの指定がおかしいということはないはず。

色々と調査したところ rustup で入れたツールチェインと msys2 上に pacman で入れたツールチェインが競合してたことが発覚した……。
環境を分けたつもりだったけど失敗してた。

>>284
老舗のactixが本流tokioによる新参axumに追いつかれた状況
actixを既に気に入ってる人を除けば今後はaxumでいいかと
dieselは同期で使うものなのでspawn_blockingなどでくるむしかないね
ORMなdieselより非同期対応のSQLxを使う人多いかな

UAVCANプロトコルのクレイトがあると思ってサイト見てみたらダメダメやね。
ドローンの仕事が増えてきたので、この辺のクレイトはしっかりしてほしい。
プロトコルもV1.5から8年間更新されていないし、たく　さぼり過ぎ。
仕方ない。　俺がやるか。

ああ、Rustが覇権してまうw

Windows 11、C/C++を全面撤廃しRust化 - Microsoftが全社で移行
掲載日 2025/12/25 10:05
https://news.mynavi.jp/techplus/article/20251225-3860427/

むしろマイナスプロモーションでは

マジレスすると周回遅れ

Windows クレートのドキュメントで検索機能を使おうとすると滅茶苦茶に重くて固まるんだがどうにかならんの？
あまりにも重すぎるので Zeal で使える形式にすることも検討してるんだけど ChatGPT が述べるところによれば Zeal でも非現実的な大きさなので
分割するとかでどうにかするしかないのだそう。
みんなどうやってる？

不必要なfeatureを描かない
必要ならfeature毎にcrate分ける

>>293
APIならmicrosoftのサイトで検索した方がいいよ
階層も関数名も大体対応してるはず

そういう場当たり的な方法でやってんのね……

>>284
loco.rs触ってみて

windowsはどうでもいいからvscodeをgpuiで書き直せ

>>298
Rustじゃ無理

>>298
それがZedでは？

>>299
Rust製なのにRustじゃ無理っておまえgpuiが何かすらわかってないのにこのスレにいるんだな

>>301
>>299を普通に読んだらvscodeの話だろう
そりゃZedの現状からしたら無理だろうな

もしかしてWGPU

vscodeがrustで書き直されたらなんかいいことあんの

脆弱性に対する安全性の観点からWindowsのシステムがRustに書き直されるのは分かるが単なるUIをRustで書き直すのはよくわからない🥺
コンパイラとかでもあるまいに🥺

ZedはVSCodeが完成されたエディタ界の王として君臨していた頃の判断としては同じものをより高品質に作り直すことは正しかったんだろうけど、
突然AIエージェントのビッグウェーブによって開発速度勝負の時代に再突入しちゃって完全にルールが変わってしまったのが大誤算だったね

>>304
もっさりもっさりがキビキビになる…
かもしれない

>>306
> ... 高品質に作り直すこと ...
その予定はまだ達成されてなくて、VSCodeとの差が開く一方
意地でもhelixやlapceで頑張ってる人が移って意地で使う程度
単なる宗教上の偶像

Zedの開発陣の方がはるかにモチベーション高かったからまさかAntiGravityみたいな新参に全て持っていかれるとは思わなかった
あれ、もともとGPUの時間貸ししてたさくらインターネットみたいな系統のベンチャーなのに今やGoogleだしな

Rust がどうとかは置いといて VSCode は深刻に遅い。
人間の思考速度は会話速度に依存するという論もあり、
タイピングから一瞬も二瞬も遅れて画面に反映されるようなのは論外なストレス。
ダースベイダーじゃないんだからそんな苦行を受け入れたくない。

CPU がバリバリでメモリがモリモリの最新鋭のマシンを常に使える恵まれた環境ばかりじゃないんだぞ。
使い物にならないなら高品質もクソもねぇんだわ。

Eclipse動かすんじゃねえんだからそんな重くないだろ
メモリ4GBのCelelonノートでも貸与されてるのか

Eclipseωωω

Eclipseも今となっては、よくあんなクソ使ってたなってユーザに馬鹿にされるような振り返りしかされないけど
当時はそれこそVSCode級の開発環境の革命としてもてはやされてたんだよ

>>313
e2stidioで1日10時間開発してる
デバッグするときsegger使いたいから仕方ないんだけど

家ではもちろんantigravityだけ

vscodeが遅いんじゃなくて、クソみたいなプラグイン入れてるから遅いんだろ

vscodeというプラグイン入れてるから遅いんだろ
あ、vscodeがクソって事か

electronとかゆううんこ

やれやれ。間違った理解でドヤ顔している馬鹿を
久しぶりに見た。

鏡

ウェブブラウザ (ウェブウィジット) は重量級のアプリケーションだよ。
それを動かす機械が十分な性能だとしても避けられるものなら避けるに越したことはない。
避けられないなら仕方ないが、避けられる (かもしれない) 選択肢が生まれて歓迎しない理由はなんもない。

>>317
Tauriはうんこ

それ1.0出たばかりのようだけど、モバイルの基本機能レベルのビルドはできるの？

でも10年後やっぱり仕事があるのはeclipseのJava案件だったりしそう

eclipseといえばプラグイン地獄だったが、vscodeもそうなりつつあるの？

>>324
実はビジュアルスタジオコードはあまり使ってないけど、そこまでプラグイン要らないよ
日本語パッチの拡張とあと一個ぐらいで使えてる

プラグインも作業に応じて読み込むもの読まないもの
のセットを選べれば良いのだが

VSCode では基本的には必要になるまで拡張はロードされない。
例えば特定の言語に結び付いているような拡張はその言語で作業し始めるまでは読み込まない。
でも、常識的に VSCode の拡張は使うために入れるのだから入れた拡張のほとんどはロードされる結果になると思うよ。

ワークスペース作らないと普通に読み込まれる定期

定期？

念のために解説しておくと、こういう場合の「定期」は「定期的に言ってる気がするけどさ」くらいの意味で使われるスラング。
話題が落ち着いた頃にまた蒸し返されることにうんざりしているような感情を表している。

>>330
解説ぅまぃね(=^▽^)σ

>>330
なんだ文脈考えずに使ってみたかっただけか
まとめサイトかなんかから流れてきたのかな

>>332
おまい5ch初めてか？ 定期

>>332
文脈的には妥当なので意味が分からなかったり不自然に思うならお前が違う文化ってだけ。

なんJから流れてきたっぽいガキも多いよね

わざわざそんなことを言うのがガキのメンタルだと気づいてくれ

>>333-335
ガキ

「emacs 使えない奴はプログラマじゃねーよ」(戦火の火種)

ところで wasip3 が12月に動きがあるって話だった気がするけど、どうなってます?
サーベイしてる人　教えて、教えて

どうせクセのあるエディタを使うなら vi に慣れておくほうが良いよ。
システムがぶっ壊れて使えるコマンドがほとんどないときにも vi は使えることがあるから最悪の場合に頼りになる。
使い勝手がどうとかもあるけど使えなかったら話にならん。
使えなくなりにくいというのも大事な要素だ。

が……さすがに ed は勘弁な

struct A<'a>{
vec:Vec<String>,
str:&'a str

}

impl<'a> A<'a>{
fn f(&'a mut self){
self.str=&self.vec[0];

}


}

fn main() {
let mut a=A{vec:vec!["a".to_string()],str:""};
a.f();
a.f();
}

これってどうやってもコンパイラ通すのむりだよね

&strて結局文字リテじゃけんstaticでよくね

コンパイルが通る形に修正すれば通るよ。
だけどやりたいことがあって、やりたいことの部分を変形したら意味がないだろ。
何をやりたくてどこは絶対に変更してはならない仕様なのかをきちんとまとめて。
仕様をきちんと説明できないならテストケースの形で提示してくれても良いよ。

nanoでいいんじゃない？

MS様のRust製Editがプラグイン対応したら起こして

今後はAIがないと何もできない人材の増加にあわせて
本番サーバにもAIエージェントが入っていくだろうし
vimしかないみたいな環境も滅んでいくだろう

サーバにai入れてなにすんの
ansibleあるし今どきサーバに直接入ってどうこうするとかあるんかな
mcpでaiに勝手にローカル消されたりてあったし入れるにはセキュリティ的にきびしそう

Rustのスレって毎年年末になると世の中分かってない
>>345
みたいなのが出てくる定期

>>340
自己参照構造体はPinで包まないと扱えないからstd::pinとかouroborosのドキュメントでも読んでみ
この辺のノウハウはnomiconにも書いてないから正直つらい
日本語の情報なら↓とかが分かりやすかった
https://tech-blog.optim.co.jp/entry/2020/03/05/160000

>>347
いつもだろ定期

C++ みたいなメンバを指すポインタ (実体としてはオフセットアドレス) は Rust にないの？

>>349
std::ptr::address_of マクロ、可変参照ならstd::ptr::address_of_mut マクロかな？

可変参照は正しくないな。
*mut Tとして、オフセットアドレスを返すマクロかな？

340がやろうとしてるのはVec<String>のヒープの参照だから構造体のオフセットとは違うな
参照を諦めて素直にポインタ使うか&'static strに偽装（transmute）して頑張るか
どっちにしてもunsafeでてくる
Vecに入れたStringの値を後で変更するつもりならどう頑張っても無理だけど

>>340
struct A {
v: Vec<String>
}
impl A {
fn s(&self) -> &str{
&self.v[0]
}
}
fn main() {
let a = A{v: vec!["a".to_string()]};
println!("{}", a.s());
}

何をやりたいのか良く判らないけど
書き換えたいなら
struct A {
v: Vec<String>
}
impl A {
fn s(&self) -> &str{
&self.v[0]
}
fn s_mut(&mut self) -> &mut str{
&mut self.v[0]
}
}
fn main() {
let mut b = A{v: vec!["bbb".to_string()]};
println!("{}", b.s());
unsafe { b.s_mut().as_bytes_mut()[1] = b'x'; }
println!("{}", b.s());
}
どうせunsafe使うなら* mut ptrもあり

Cでポインタで悩むこともなくて、メモリリークとかも起こさないちゃんとしたCプログラマーがいまさら勉強するメリットって何があるのRust

俺はメモリリークとかも起こさないちゃんとしたCプログラマーとか自信満々に言う奴がいたら
十中八九自分の能力もまともに理解できてない能無し

>>355
そんな人はいない
熟練プロでも必ず見落とす

あとrustはriscvの公式ターゲットだから相性がいいってのもこれからの時代強い

そんな人がいるとしたらRustを勉強する必要どころかCを触る必要すらないから機械語書いてる方がいい

>>355
自分以外の人もメモリリーク起こさなくなるから
個人で遊ぶ程度の趣味グラマならメリットないかも

>>360
会社だと自分が仕込んだわけではない、ぬるぽ、踏むことあるんだよな
組み込みやっててC使わざるを得ないが20年前のコードの地雷踏んだりとか

yacc のメモリ関連バグが 33 年も潜んでいた話で、そんなユーザー数が多いソフトでもなかなか顕在化しないバグもあるんだなと思ったことがある。

>>355
そんな人いないから各企業がRustに乗り換えようとしてるんや

まぁ若くて体調が良くスケジュールに十分余裕があれば
その瞬間だけ完璧なプログラムを書ける人はいるだろうが
それを数十年間維持し続けるのは無理だろうね

AI時代にどこまで価値を維持できるかは怪しいけどね
最先端のモデルにRust書かせれば、コンパイルエラーを出す頻度はかなり下がってきてる
それは即ち、Rustコンパイラの補助無しで安全なコードを書けるようになりつつあるってことだ
まあ、だからって敢えてRustのガードレールを外すメリットはほぼ無いわけだけど、
人間がコードを意識しなくなればRustを使うことで一部のプログラマの自尊心を高める効果は無くなるわな

Rustを使って GPU 上で動くボードゲーム用強化学習フレームワークを作成したいんだけど
rust-gpu と rust-cuda のどっちを使うべき?
それとも Rust で書くのは諦めて Python/Jax で書いた方がいい?

Pgx (https://github.com/sotetsuk/pgx) みたいなのを想定してる

コンパイルエラーが出ないコードをAIがポン出しできることがあれば
すなわちAIの生成するコードは常にunsafeでも安全？？？？？？？？？

そりゃ論理的にはそうだろ
コーディングを完全にAIに置き換えられるかどうかはともかく、
コードの静的検証に関して今後AI活用が進んでいくことは疑いようがなく、従来より遥かに強力だが非決定論的な静的検証が行われるようになる
その流れの中において、今のRustのボローチェッカーのようなルールベースのチェックの位置付けは自然と変わっていき、相対的なものになっていくはずだよ

>>355
AIもあるしほとんどメリットはないんじゃね

AIとRustの相性良いもんな
C/C++は使用禁止になる日も近い

安心安全はAIに任せればいいんだよ
だからRustはオワコン

>We now ban every reporter INSTANTLY who submits reports we deem AI slop. A threshold has been reached. We are effectively being DDoSed. If we could, we would charge them for this waste of our time.

>We still have not seen a single valid security report done with AI help.

https://www.linkedin.com/posts/danielstenberg_hackerone-curl-activity-7324820893862363136-glb1

>>371
つ >>372

出力の再現性があるかないかの違いはあるけどRustコンパイラの検証もAIみたいなもんだろ

こんにちAIという際、それは言外に生成モデルを指しているかと

生成AIを前提とするならば最後の番人としてRustを使うしかないな

人間にとって扱いやすいプログラム (を書く言語) は AI にとっても扱いやすいと考えられている。
根本的には「複雑さ」の問題で、複雑になると計算量が超爆発して手に負えなくなるので型などで制約するのは理に適ってる。
ポインタが無効かどうかなんて検証しきるのは無理。
計算量が爆発するってのは無量大数倍とかそれ以上のレベルで増えるって話なので AI ならなんとか出来ると夢を見るのはやめたほうが良い。
将来的にそのレベルの計算量が誤差になるくらいのコンピュータが登場したら話は別だけどさ。

そう思ってた時期が私にもありました

rustはcpuに負荷かけすぎな希ガス
h264に対してのav1みたいな漢字

一昨年ぐらいにAIに1万円ちょい課金してRust書かせたがクソコードすぎて全部自分で書き直した。GoogleとかOpenAIとかいろいろやったが全部ダメ

文法やらアーキテクチャわかる人なら自分で書いたコードの方がはるかに効率よくてエレガントな設計にできる

一万円札ドブに捨てて以来、全くAI信用してないわ
あいつらコンパイルエラー消すために無茶苦茶なコード書きやがるし
真面目にオライリー読んで自分で書いた方が仕事が早い

生成AIは挨拶に応答するだけで500mlの水を消すぐらい無駄にエネルギーを使うのに
仮に生成AIがC言語で書いたプログラムについて、総当たりでメモリ脆弱性を正確に検査することができるようになっても
500mlの水を使うこともなく、言語の仕組みでそれを防げるRustを使えばいいじゃんで終わる

生成モデルのそういうマシンパワー頼りというか、ありきなところがしょせんブームでバブルとうがった見方をする理由
いずれハードの面が隘路になって停滞するのが自明では

IME (漢字変換) は漢字の形のうろ覚えは補助してくれるが文章の内容や構成は補助してくれない。

AI によるコード生成補助もそれと同じくらいの感じ。
ごく小さな範囲の補助には有用でも大きなプログラムは任せられない。
一度に生成するのが30行を越えるくらいになるとまるでデタラメになる。

個人的にはドキュメントを元に説明をさせるみたいな使い方をしてる。
根拠になる箇所を示させれば妥当性の判断は自分で出来るから。

一昨年ってGPT-4oくらいか
年寄りの戦時中の昔話くらいだな

AI の電力消費量は想像以上に大きいからなぁ……
仮に充分に賢い AI が登場したとしても
誰もが AI を前提としてプログラミングをするような世界は無理だろ。

>>384
言うて生成モデルの抱える根本的な問題が解決したわけでもなく、それによって何か代表的なサービスが生み出されたわけでもなく
ただただスロップとプルリクDoS、驚く仕事をする人たちが増えただけ
企業がひり出すハイプとナラティブ混ぜた糞

>>386
仕事してないから知らないだけじゃない？
最近のSaaSとかのコードって実際ほぼAIが書いてるよ

過去にはこういったナイーブな考え方をする人がまだ多くいた時代もあったのです。

>>387
いくつか具体例をば

>>389
あなたがまともな職場で仕事をしているのなら周りを見れば明らかだが、最近だとこんな例もある
https://www.reddit.com/r/Anthropic/s/s66maSblvI

なんでコメントでボコボコにされてる、よりによってAIエージェント屋のポジショントークを貼るんだろう？
AI BOTでももうちょっとマシなもの貼るんだろ

>>390
>Claude Code creator confirms that 100% of his contributions are now written by Claude itself

つ >企業がひり出すハイプとナラティブ混ぜた糞

当該レスへの反証として >>386 でまさに引き合いに出している"企業"のそれを持ってくるのはツッコミ待ちのボケなのか、ガチな認知のほうなのか
副詞「いくつか」が目に入らぬか

>仕事してないから知らないだけじゃない？
>あなたがまともな職場で仕事をしているのなら周りを見れば明らかだが

そちらはどんなお仕事されてるの？
経験、スキルセットはどのようで？

>>390
ちなみにそちらの引用した彼が別のインタビューで言ってる内容が次のもの
あなたがまともな職場で仕事をしているのなら、これを読んでどう思うかは明らかでしょうか？

>Claude Code's creator says vibe coding falls short when it comes to producing "maintainable code."
>The models are still "not great at coding," he added.

>The creator of one of the most popular AI coding tools says vibe coding can only go so far.

>It works well for "throwaway code and prototypes, code that's not in the critical path," he said.
>"I do this all the time, but it's definitely not the thing you want to do all the time," Cherny said, referring to vibe coding.
>"You want maintainable code sometimes. You want to be very thoughtful about every line sometimes," he added.

>Dec 16, 2025, 2:07 PM JST
https://www.businessinsider.com/claude-code-creator-vibe-coding-limits-boris-cherny-anthropic-2025-12

省電目的でクラウドだとarm risc-v流行ってるしはよコンシューマにも降りてきてほしいナ

株式会社アイ・エス・ビー
https://kizuna.5ch.net/test/read.cgi/infosys/1756826944/

>>380
ほんそれ

AIと相性悪そうだよな

Rust は大規模言語モデルの AI と相性が良い部類だと思う。
それでもなおそんなもんってこと。
LISP 系言語だと括弧の対応すら合わない。

ついこないだグーグルで働いてるvtuberもaiはrustだと古いコードしか吐かないてゆってた

こないだ
ゆってた

うーん小卒？