結局C++とRustってどっちが良いの？ 9traits

MSがVisual Rust++を出してからが本番

>>331
ありそうｗ

>>331
その前にMSが傾いてそう。

EchoAPIは大きな変革をもたらし、APIのデバッグを迅速に行って、スムーズなユーザー体験の構築に集中できるようになる！

MSが一番仕様汚す真犯人では

まあでもヘジルスバーグがどう手を入れるか見てみたい
delphiやc#やtypescriptに影響与えたからな

Visual R＃が出て
Rustが終わるのでは

.NETと接続するための Rust/CLI かもしれない

C++/CLI並に何でもできるが面倒すぎるものだったら使いたいな。

>>337
統計解析が得意そう

小倉智昭さんRIP、ここの住人ならパソコンサンデーみてたよな？

懐かしす
朝生と同じテーマ曲だったよね？

EchoAPIはAPIの問題を迅速にデバッグするのに役立ち、安心して次に進むことができるよ

サイコパスの脳の違いを発見。一般の人に比べ線条体が大きいことが判明
karapaia.com/archives/52313287.html

>>344
でも、本人が性格悪い人に限って、他の人の事をサイコパスと言っていたりするんだよなぁ。

>>344
ずるいことばかり考えてるから後天的に線条体が発達したかも知れないな

南無南無
https://www.youtube.com/watch?v=f6R4T7bYG9k

Rust、zulipに参加してみたけど
あんま活発じゃないのかな、、、

なぜ日本語? Ruatで話すべきでは?

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

RustをLinuxカーネルに導入したい勢力と、C言語主体の開発体制を維持するメンテナとの対立が顕在化し、現在激しさを増している。

Rust勢の怠慢なんだよね
C to Rust を実用化して、一気にpure Rust Linux をフォークすればいいんだよ
みんなそっちに来るはずだろ
C to Rust の成熟・信頼獲得の機会にすべきまである

>>350
このスレと同じ予想できる展開w
Rustは補助輪みたいなもんだ
Rustユーザ「補助輪あると誰が乗っても原理的にコケないよ」
Cユーザ「俺は補助輪なくてもコケない! 補助輪うざい!」

「いつの話だ。Cにも補助輪ついてる」って、はやくなってほしい

Asahi Linuxのリードデベロッパがアップストリームメンテナーを辞任⁠⁠、背景に“C vs. Rust”対立に端を発したブリゲーディング
https://gihyo.jp/article/2025/02/daily-linux-250213

おまえホントLinuxゴシップ好きやな

Rustは開発や拡張には向いていないんよ
固まったコードを描き換えて聖書するには向いてるのは判る

>>353
AIが補助輪になったよ

AIに監査させました、で投資家が納得するかだな

Rustのsafeとの相互運用が完全にできればいい

>>358
Rustは何が監査してるの？

コンパイラ

ついにC/C++が復活の狼煙を上げる

新たなC言語拡張コンパイラ「TrapC」が発表 — ガベージコレクトなしでメモリ安全なC/C++を目指す
https://techfeed.io/entries/67c4d3a9bb060d7fb550d283
Safe C++ Extensions の提案：複雑化する開発エコシステムの強化が目的
https://iototsecnews.jp/2024/09/18/the-safe-c-extensions-proposal-strengthening-security-in-a-complex-ecosystem/

C++陣営を本気にさせただけでもRustの存在意義があったな

しゃあないなあ、と重い腰を上げ…かけたところｗｗ

はよ進化しろ
仕事で使えと言われたらRustでもなんでも使うけど、墓までもっていく言語はC/C++に決めてるんだ

定期的に後継言語来るし普及するの?
Rust以外雑魚

C++に未来は無い
C->C++がそもそも間違った進化なのでC++を治してももう手遅れ
C->C++じゃない何かに進化する必要がある
それはC->Rustかも知れないしC->Nimかも知れないしC->Zigかも知れないし
C->別の何かかも知れない
C++の進化はもう要らない

>>365
願望塗れで意味の無い主張ですなぁ。

X(旧 twitter)で、C++ というキーワードが検索できないんだけど、
俺の環境だけなのか、一般的に他の人の環境でもそうなって
いるのかどっち？

検索出来るけど、Cで始まる言語と軍用機まで色々かかるな

そもそもRustはC++から互換性を取り除いたものでは

Rustはいずれ無くなるのでは？
PascalやBasicのように

C使うなって米国の役所が言ってるからな

C++が上手いこと安全で高速な限定言語作ればいいけど、今の標準委員会はそんなこと考えてなさそうだからなぁ。

開いたパンドラの箱の底には希望が残されているという

C++は規格を刷新してC+++にでもしないと未来はない

C#はC++++なんだよなー一応

C+-0で

>>375
それはコンパイルできない

++C++

operator overheat🔥

「Google Chrome」のフォント処理がC/C++言語からRust言語に
「FreeType」からの移行でメモリ安全性を改善、脆弱性が出にくいライブラリに
https://forest.watch.impress.co.jp/docs/news/1672186.html

先にfirefoxをどうにかしろよｗ

“GitのRust化”が進む？　注目の「Git 2.49」がリリース
https://atmarkit.itmedia.co.jp/ait/articles/2503/31/news035.html

今回のリリースは、Gitプロジェクトにとって大きな節目となる。Gitのコードベースに初めて「Rust」のコードが追加されたからだ。具体的には、このリリースで「libgit-sys」と「libgit」という2つのRustクレート(crate)が導入された。「libgit-sys」はGitのライブラリコードの一部を低レベルでラップする機能を持ち、一方の「libgit」はより高レベルなラッパーとして機能する。

Gitは長年にわたり、コードをライブラリ指向に進化させる取り組みを続けてきた。プログラムを強制終了する関数を、終了コードを返す関数に置き換えることで、呼び出し側が終了処理を決められるようにしたり、メモリリークの修正や管理の最適化を進めたりしてきた。今回のリリースではこうした改善の成果を生かし、Gitの「config.h API」の一部をRustでラップするRustクレートがPoC(概念実証)として導入された。

ただし、今回の導入は“GitのRust化”に向けた第一歩にすぎない。Gitの全ライブラリをRustでラップするには、今後さらに多くの作業が必要となる。しかし、今回の試みはGitの進化にとって重要な一歩であり、非常に意義のある進展と言える。

ただのラッパーじゃだめなんよ

コアをrustで書かないと意味が無いよな

セキュリティ目的なのかね。それだとUIのRust化は優先度高くなるかな

まずはインタフェースからってことかな…と思ったけど、インタフェースだけ気を付けて書いて、あとはAIに実装部の変換頼んだりして
っておもいついてみｔ

どっちも初心者だけど
Rustのが初心者向きだとは思ったよ
cargoがいいよね

後発なのでその辺はいい

10年後もこのスレが続いているなら見て
みたい。Rustマンセーしている奴らの
お馬鹿発言を楽しみながら

BIOSも含めてRust製のOSってある？

続けるだけでは意味がない。研究が示した「成長できない人の条件」
公開日2025.05.24 13:00:14 SATURDAY
http://nazology.kusuguru.co.jp/archives/177845

>>390
BIOSはOS関係ないような

昔はBIOSの上にOSがどっしり載ってたけど 今ってBIOSは起動し終えたらほぼほぼ用済みよね

マザーボード側の機能だから、評価ボードとかマイナー製品ならRust使ってるのあるかな。なさそう

どちらがというよらホワイトハウス声明やCコードのドランスパイルに国が予算つけてるんだからC/C++のオワコンは必至で新しいパラダイムにアレルギーある老害が喚いているだけw

Unixの共同開発者ブライアン・カーニハン、RustやLinux、LLMについて大いに語る
https://techfeed.io/entries/68b60f6cd0e17253abf4298c

最も盛り上がったのは、Rustに関する質問だった。「RustがCを置き換えるのに妥当性はあるか？　それとも単なるバブルか？」と問われると、カーニハンは「Rustかぁ」と大げさにため息をついて笑いを誘った。

「Rustで書いたプログラムは一つだけだ。だから話半分に聞いてくれ」と前置きしつつ、こう続けた。
「とにかく大変だった。メモリ安全を実現するための仕組みを理解するのに苦労したよ。そもそも、そのプログラムではメモリが問題になる場面なんてなかったのにね。」

さらに彼が強調したのはパフォーマンスの低さだった。「コンパイラは遅いし、生成されるコードも遅い。必要な仕組みが巨大すぎる」と、半世紀以上前にCを開発した人物の口から手厳しい評価が飛び出した。結論としては「すぐにCを置き換えるとは思わない」と語りつつも、「自分の経験が限られているので偏見かもしれない」と柔らかく補足した。

LLVMが頑張るから、パフォーマンスはC/C++並なんじゃないの

クソデカコンパイラは同意 clangも同罪
LLVMもrustで書き直せたらワンチャンある

おっさんだからCは難解って最近聞いてびっくらこいたわ

どんだけ油断していても、バグのないC それが最近のCだぞ

油断したら無理でしょ…

カーニハンはD言語に対しては何て言ってたんだろう
dmcは？

まずC++で作って動作確認できたらそれからRustで書き直すのが正解

>>402
なんでそんな無駄な工程追加してるの？

Rustで動作確認してCでrewrite
C++なんぞハナから相手にしない

既存資産がC/C++の山だったりするんだろ あるいはRustの修練中か

仕事はそんなんでいいんだよ やれと言われれば、PythonだろうがC#だろうが修める
問題は自分用の推し言語

Rustはバイナリも重いしコードも煩雑だよね

バイナリ読めないけど、重たいというか、サイズ大きいのかい？

IT土方ってそういうの気にしないんだよな

動けば正義だし、動くようにエンジニアリングで試行錯誤するからね。ライブラリを理解すればとは中々ならない。

ここには日本語が不自由なやつしかいないみたいね

ここだけじゃないね

「ドッペルゲンガー（極端なそっくりさん）」を調べたら赤の他人なのにDNAが似ていた
2025.09.14 SUN
https://nazology.kusuguru.co.jp/archives/113854

ADHDの脳は実際に普通の人とは構造が異なっていた
2025.09.14 SUN
https://nazology.kusuguru.co.jp/archives/184809
>>各研究で用いられていたMRI（磁気共鳴画像）装置や画像の解析方法に“微妙な違い”があり、その影響が十分に補正できていなかったためです。この問題は以前から専門家の間でも指摘されていましたが、長年、解決が難しいまま残されていました。
>>この問題に対して、千葉大学（Chiba University）、大阪大学（Osaka University）、福井大学（University of Fukui）など国内複数の大学による共同研究チーム（代表：水野義史〈Yoshifumi Mizuno〉准教授）は、実際に複数の装置で同じ被験者を測定してそのズレを正確に補正する「TS法」と呼ばれる手法を本格的に導入し、長年の課題だった技術的ノイズを徹底的に排除しました。
>>その結果、ADHDの子どもたちの脳にどんな“違い”があるのかを、これまでになく明確に示すことに成功したという。
>>これは理屈としてはばらつきを補正する非常に優れた方法ですが、実際には大規模な協力体制と多くの技術的・資金的なサポートが必要となるため、これまで本格的に実施されることはありませんでした。
>>研究グループはこうして、ADHDの子どもとそうでない子ども、計294名（ADHDの子ども116名、定型発達（健常）児178名）の脳画像を比較しました。ここでは、年齢や性別、知能指数（IQ）などの違いも統計的にしっかり調整されています。
>>結果、ADHDの子どもたちの脳には、実際につくりの違いがあることがはっきり示されました。
◇全精神病や知的障碍者も該当しているでしょう！

まるで45億年前の太陽系!? “惑星の誕生”が初めて観測される
2025.09.13
https://wired.jp/article/exoplanet-gap-discovery/

脳から直接脳波を読み取り意思疎通　ALS患者などの生活の助けに　埋め込み型BCI装置開発　2028年の実用化に向けて年内の治験申請を目指す
9/14(日) 9:00
https://news.yahoo.co.jp/articles/cf64abfd0662436950e9bcccf85ddefd84a6b33e

「Rustの長いコンパイル時間が生産性を低下させている」　Rustプロジェクトが公式調査結果を公開
Rustプロジェクトは公式ブログで、2025年夏に実施した「Rust Compiler Performance Survey」(Rustコンパイラパフォーマンス調査)の結果を報告した。
https://atmarkit.itmedia.co.jp/ait/articles/2509/22/news014.html

ツールチェインを今後全内製していきますとかいう布石でしょ

https://mevius.5ch.net/test/read.cgi/tech/1745631298/614
https://mevius.5ch.net/test/read.cgi/tech/1745631298/622

例の人ﾜﾝﾄﾝｷﾝﾜﾝﾐﾝｸﾞｸだったんだな
覚えとこ

Linus⁠⁠、Rustのフォーマットチェックを「無神経でクレイジー」と酷評
https://gihyo.jp/article/2025/10/daily-linux-251006

アレがいいんだよ、とか思ってそうだよな

馬鹿にしてないぞ、あれはあれで脳汁出そうな気がする

Linus は Rust のコードレビューもするのか。凄いな

Cより簡単じゃね

C/C++は学生時代から使っていて思い入れがあるけど、まだ30代だから時代に取り残されるのも怖いし
Rustを意識して使うようにはしてる。50代なら逃げ切りを考えてたかな

Cとか使うのすごいね。スクリプト言語しか触ってないわ
RustでもCでも仕事で使いたいわ。組込か自動車くらいじゃないかね

たまにC/C++で手作業でメモリ管理したくなる。
けど、仕事でだったら遊んでる暇ないから選べるならGC付き言語かRust。

RustってCの置き換え狙ってなかったっけ?
CかC++かで組み込みじゃ意味合いが違ってくるんだが。
（C++はCより2倍遅い。OS載らない環境だと大きな違い）

Cはわかりずらくてあまりやってこなかったけど
Rustはわかりやすくて一気に理解が進んだよ
axumでweb api作ってる

Cは中級言語というかCPUと人間の中間の役割以上はやらないのよね。将来性能改善で使えそうな詳細機能はあえて未定義にして仕様化しないとかやったりしてる。過渡期の言語よいう感じだから、若い人がアプリで使うならRustでいいよ

rustはセキュアなうえに処理速度も速い
好き嫌い関係なく、覚える必要のある言語だと思う

rust は C より速いっけ？rust の方がどうしてもオーバヘッドが大きいと思うのだけど。

速くはない。Cより遥かに安全だから使える環境なら使った方がいいよ
Cはコボル化していくのだ

コボル化するのはC++のような…。
低スペック帯の組み込みは元より（こっちは普及率次第ではRustが置き換えるかも）、Cは言語間のライブラリ移植に欠かせない。

Rustはゼロコスト抽象化って言ってるから、実行速度は妥当な性能低下で済まそうとしてるはず。コンパイル時間が犠牲に

あんた達本当に実務で使っているの？
サンプルプログラムでゴイゴイスー
と言ってるだけじゃないの？
受け売りで言ってる奴が多すぎる

>>430
なぜそう思うのかは書かない

>>428
組み込みはRust一択
今日もRustで組み込みしちゃった
えへっ

>>432
ワンチップマイコンだとむりじゃね？

えっ

このスレにも驚き屋？

>>432
PICマイコンとかはRustコンパイラないね。
あの規模までコンパイラ出たらCの置き換え成功だけど、今のところC++の置き換えまでしか成功の兆しが無い。

PICはまだstack8段までなんだっけ

RustのコンパイラがあるCPUがうらやましい

まあ、PIC上で(例えば)gcc動かそうとか思わんし、それはいっしょ

>>439
え、PCでクロスコンパイラ使ってコンパイルして書き込みツールでPICに書き込むんじゃ？
OS載らない環境（用語は最近知ったけどベアメタルとかいうらしい）じゃ当たり前だお。

>>416
Linusのフォーマットチェックへの文句は言いがかりだよな。
将来のためとしてああいう書き方をするのは良くないという哲学を徹底してるだけ。手間でもその都度整理してねということ。
自分のローカルで作業してるうちはフォーマットかけなくてよくて、公式リポジトリにアップするときにかけるべき。

逆にC言語では不要になったヘッダやコードとか将来のためと言って使ってないものとかが残骸として残りやすくてあかん。

Linux 6.18-rc2リリース⁠⁠、Linus“ご立腹”のRustフォーマットチェック関連も修正
https://gihyo.jp/article/2025/10/daily-linux-251020

今のところCの置き換えには無理だけど、C++の置き換えにならできるかもしれないという感じなのかな？

気合いと予算次第で全部置き換えられるのでは

トランスレータがしっかりしてたら、トランスレータの実証プロジェクトになると思うんだよね
まあそのうちやるでしょ
Linux側も、フォークしたければ勝手にしろって感じのはずだし
社内向け実験用フォークとか、そっちのほうの必要性はいくらでもあるし遠慮いらない

これがRust推しのレベルですか

なんでRustの環境構築してないのにRust製のツールが動くの？
https://speakerdeck.com/ssssota/why-do-rust-based-tools-run-without-a-rust-environment

そういうのはワッチョイ無しのほうでやるともっと爆釣れやで

>>443
C++製のアプリも、内部の大半は、C流の書き方をしているものが多いから、それはない。

C/C++の事を知らない人の中に、C++のプログラムはCではなく「C++流の書き方」をしていると思っている人が
多いようだが、実際には、C++ の流の書き方は非常に限られた部分に限る、という場合が少なくない。

stl使えばC++と言えるのだが、使ってない方が多いのかね

RAIIしてスマートポインタ使ってればCとは言えないけど、そういうのもやれてないんか?

RustとC++の相性は最悪
RustとCの方が良い
CからRustへの置き換えの方が楽

>>446
このスライドって、ネタで書いてるんだよね？

Goも動くし当たり前じゃ

【海外記事紹介】Rustにはガッカリしている
https://techfeed.io/entries/69261dbc2020c64b2242f9eb

11月24日、bykozyが「Blog - Rust is a disappointment」と題した記事を公開した。この記事では、Rustが期待されてきた「C++の後継候補」としての役割を十分に果たしていないのではないかという問題提起を行い、とくにコンパイル速度の遅さ、言語としての複雑さ、メモリ安全性と信頼性のトレードオフ、可変共有状態の扱いにおける限界について詳しく紹介している。

筆者はRustの中核的な問題として、次の4点を挙げる。

1. コンパイルが非常に遅く、本質的に速くなりにくい。
2. 言語としてC++並みに複雑であり、所有権やライフタイムの管理が常に開発者の負担になる。
3. メモリ安全性を過剰に優先した結果、実用上の信頼性や開発者の「正気」が犠牲になっている。
4. GUIやDB、大規模な状態管理など「大量の可変共有状態」を扱う用途では、設計・実装ともに向いていない。

そのうえで、「Rustが良いか悪いかではなく、膨大な工数が投じられた結果、棚から取ってそのまま使える“そこそこの言語（mediocre）”に落ち着いているに過ぎない」という評価を示す。

C++代替なら、Dの方が向いてそうなイメージ

full Rust でツールチェインがんばるんだろうから、遅さはまだいい
っていうか、最適化度外視モードでずばばっとコンパイルすりゃいいだけなんだろ

C++でちゃんと書ける人はRustでも書けるでしょ?
Rustで書けないような人がC++で書けると宣ってもちょっと...

人間が脳内管理してためんどうな所をコンパイラが見てくれるんじゃぞ
という位置づけ

rustを理解してればどんな用途が適しているかは考えて使うよね。
GoだろうがC#だろうが結構簡単にバグるし、安全に書こうとするとそれなりの勉強が求められる。
可変共有を大量に使うプログラムはどのみちバグるから、GC管理のほうがいいというのならそこだけGCのライブラリ使えばと思う。
C++だって言語機能としてはGCは無いが、必要ならライブラリとしてGCを組み込んで使っている。
ゲーム作る人は当たり前のようにやってる。

LinuxカーネルへのRust導入は定着したとの合意、「実験的」タグを外すことが決定
https://gigazine.net/news/20251211-linux-kernel-rust/

Linuxは絶対Rustに置き換わらないって言ってたやつ出てこいよオラ！　もう時間の問題だろ
まだ一部だけとか、カーネルだけとか言うんだろ

bioとかkmallocとかうまく扱えるのかね
Kernel内のAPIはRustから呼べるのかな

>>462
実現方法を理解出来てるかね?
置き換えるというかRustに配慮した互換レイヤーを経由してそのうえでRustコードを使えるように見えるのだが

いつまでもトランスレータを出してこないと思ったら、これを待ってたのね〜って思ってる

反C++派がオラつくのはいい気がしないが、ともかくC++にとっとと技術が流れてきてほしい

提案したりプルリク作ればいいのでは

>>461
リーナスがRustでコード書き始めたら考える

unsafe使いまくれば、行けるんじゃないの？
unsafe使ってもCとは安心感が違う的な。

あとは、コンパイルが速くなれば問題ない。

メモリのレイアウトから違うという話もあったし、ページ管理なんかのコアはRust使えないでしょ
ドライバとか表層の部分はRustにしていいけど奥深くを書き換えはないだろね
影響が大きすぎるし、価値があるか怪しい

そういうところにも使えるRustって進化を遂げる可能性はある

RustでOS書いてLinuxを置き換えるくらい狙った方がいいよ
最初はニッチな用途から始めるのだろうが

なるだけ自由なディストリっていうけど、なるだけC/C++を廃したLinuxってのは需要がありそう

遠い話にはなるよ
ファイルシステムやデータベースは安定稼働して市場で受け入れられるまで10年以上かかるし、systemdのようなものを誰が好き好んで作りかえるのかという問題がある
Waylandも普及に5年以上かかってるし
httpサーバーなんかは独立してて作りやすい部類かもしれないけどnginxとapacheの牙城に食い込めるかな

C領域はトランスレータを書けばほぼ一発のはず
そっからがどうなるかだな
C++は、簡単に書いたものなら

頑張ってくれ
https://jp.quora.com/%E8%87%AA%E5%88%86%E3%81%A7OS%E3%82%92%E9%96%8B%E7%99%BA%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF%E3%81%A9%E3%81%AE%E3%81%8F%E3%82%89%E3%81%84%E3%81%AE%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

ヒゲポンもコメントしててわろた

MonaOSってbootしてGUIっぽく動くけどOSとしては機能不足過ぎない？

そうだよ。個人で始めたらあのくらい端折らないとGUI作れない

bootもkernelも全部Rustで書いたLinuxとは全く別のOSであっても
API(というかシステムコール？)とか互換性高めてCで使えるの用意したら
Linuxの資産そのまま使えないの？
それとも「全く別」とは認めてもらえないのかな

>>479
sed s/Rust/C/g | sed s/Linux/GNU Hurd/g

Linux自体がKernel以外は借り物だろ。って言われたりするから、それでいいよ
それが出来ればすごい

わざわざRustに置き換えることに需要あるかなぁ

>>467
カーネル開発に刺激は求めない
―Linus TorvaldsがOpen Source Summit Japan 2025で語ったLinux開発のこだわり
https://gihyo.jp/article/2025/12/linus-at-open-source-summit-jp-2025

「僕はもうコーディングはしていない」―Dirkから「最近のきみは（カーネル開発で）何をやっているの？」という質問に対し、Linusはこう答えています。2年前のトークセッションも同じように「もうコードは書いていない」と発言したLinusですが、では何をしているのかというと、「⁠ほかの人が開発したコードやほかの人がメンテナンスしたコードを受け取り、マージすること⁠」⁠、つまりマージこそが自分の仕事だと明言しています。

今の若い人Cより先にRustやるだろうし、ミーハーに盛り上がるんじゃね
セキュリティの需要はあるはずだが、表面に出る部分だけか

流石にCより先にRust触ることはないわな

今は大学で教養として教えるプログラミング言語はpythonだな

Julia使ってる講座も出てきてるぞ。有名大学の公開資料を見つけてしまった

過去資産がいまんとこ大きすぎるから、Cが読めないエンジニアは現実にはおらんわな

煽ってないぞ
俺英語さっぱりだが、ドキュメント英語くらいは読める、それと同じレベルで

phpとJavaScriptが得意な30代はCは無理だろう

バグが多いという理由でLinuxがRustにするのなら、Windowsはやらないのか

LinuxはLinux(core)だけでいいが、Windows(全体)はC++が入りすぎてる
トランスレータの構築の難度がダンチだろ

Rust言語で開発したWindowsカーネル、Canaryチャネルで展開開始
C/C++言語よりもメモリ安全性を確保しやすく、速度も遜色ない
https://forest.watch.impress.co.jp/docs/news/insiderpre/1516147.html
WindowsにおけるRust採用はカーネルだけじゃない……Microsoftがちょっと言及
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1536253.html

Win32APIとCOMくらいまではCのみでいけるからな
(x64でも同じ)

チョンボをやらかしてるのがC領域が圧倒的に多いんなら、C領域だけでもRust化すればいい

もっといえば、Rustするにあたって引っかかったところが、何かあやしいところなんだろうから、
そこを直すだけでだいぶ違うのでは

Cのバグにコンパイラとライブラリのバグやテストでは見つからないバグもあるので...
C++ は変化の大きさのせいで、最新を追いかける人には何時までもバグありそうなイメージ
Rust はライブラリも含めて使われる事でバグのあぶり出しが進んでいる段階ではないのか？

いくらなんでもカーネルのコアまでRustで書き直すというわけではないんじゃないの？

ユーザからしたらCかRustかなんて関係ないしな

>>496
ないよ。Kernelモジュールをかけるだけでしょ。ドライバとか外界とのインターフェイスになる部分にRust使えるのはいいよね

>>483
そうだったのかあ

JSF AV C++の例もあるしな。
C++の改変版使うより、Rust使う方向に行くのは当たり前。

まだmisraが動いてないからいいのかも
準拠とか言い出したら地獄の釜が開く🤣

MicrosoftがWindows 11含むコード類からC/C++を全廃。2030年までにAIでRustへ書き換え
https://gazlog.com/entry/microsoft-c-language-to-rust-by-ai/

MicrosoftのAI書き換え発表が突っ込みだらけで取り消し？
https://www.youtube.com/watch?v=qtqQCAQYQOc

1人1ヶ月100万行

AIエージェントがやるんでしょ

502 は、もしワシが偉い人なら AI を信用しないので、そんな事しようと思わないんだけど、そんなに AI ってまともでしたっけ？

馬鹿と鋏は使いようとしか...
出力量がヒトとは桁違いなんだから
使いこなせないとこの先生きのこれない

>>503
AIに任せるられるんならRustいらないんだよな

AIとかより、もっと実直に変換したほうがいいのでは

実直なAIの使い方のノウハウがあるんじゃね

GoogleのOSもRustにならへんのやろか

AndroidはLinuxだけどLinuxより早くRustで書ける部分があったらしい
ChromeOSは分からないがあれもベースLinuxだしLinuxより遅れることはないだろう

AI を使う人間さんの知識次第で読めないコードが量産されそう。

早速unsafeで事故ってるじゃん。

それは事故るだろう。歩留まり100%なんてどこの業界でも実現していない

カトラーが AI に作業させて一人で完成させたらどうしよう...

MS社員ちょまど画伯だけでいいってこと

C++erだが、近頃のRubyのコードの人気パターンが知りたい
なんていうか、写経して覚える人気パターンをまず確認したい

ぐぐると、パターンマッチングのほうが山ほど出てきて、うまくぐぐれない
ないしは、デザインパターンをRustでやってみた、みたいのとか
ちがう、そうじゃない そんな高度なこと言ってないｗ

あっ。RubyじゃなくてRustだ

なんでまちがったかというと、Ruby v4.x系おめでとう
まったく関係ないけどHeroku ってたのしい?

Rubyはオワコン
将来性皆無
>うまくぐぐれない
そりゃそうだろう
Rustでぐぐれ
でもゲームのRUSTがうざい

Ruby がカッコいい時代もあったので。深く使った結果不満があったり、バージョンアップで変わっていく所で止めちゃった人も多いだろうけど

RubyがウザがられたのはKENYAのせいだよ

>>518
「写経して覚える人気パターン」というニュアンスがよくわからないのでもう少し説明を

色即是空空即是色とか?

そういうのはいいから

人気のパターンを写経して覚えたい
ではないかな

形だけ写経するんじゃダメ
大切なのは信心だよ

>>518
最近の書き方か分からないけど自分は図書館にあったので読んだ「プログラミングRust 第2版」の2章のチュートリアルおすすめ

読書百遍意自ずから現わる
自分は理屈から入ろうとしてRust絶賛挫折中だけど、写経を試みてみるかな…

>>526
そこで言う「パターン」とは何なのか相手に伝わるように説明してねってこと

1. (近頃の)人気の「パターン」
2. 写経して覚えるような「パターン」
3. (おそらく入門者が)まず確認したい「パターン」
4. デザインパターンほど高度ではない「パターン」

3と4だけであればチートシートにまとめられてるような基本イディオムを求めている可能性が高いが写経するようなものじゃないし人気・不人気で区別するようなものでもないので1と2に該当しない

よく読んだらどれも捨てがたいが、そう書いてくれるなら、2→1→3→4だな
エスパー助かる

>>528
図書館うらやましいｗ ありがとう、立ち読み狙ってみる

写経？　
写し込んでも、Warningという地獄の責め苦でスキル上がるんじゃないの？
Rustはやる事が大事。
写経以上の刺激がある。

それって、アンチパターンが身についちゃうパターンではｗ

# そんなことを言いつつ、今日はC++でもRustでもないものを勉強中

超絶今更なこと聞きたい

ライフタイム注釈がa,b,c とかなのは、i,j,k を使うくらい慣習的なもの?
たしかに、a,b,c って日頃、使いそうで使わないけど

abcに優先順位すら無い
cbaでもzyxでも一緒
と言うならそうなんだろう

Rust Idiom https://qiita.com/MoriokaReimen/items/b32ebcb0ab23bffd7e9b
Rust Idioms https://zenn.dev/masa0317/articles/8b15ecf94f3ef1
Rust Design Patterns https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651

個々のプログラミング言語の解説書ではなく、型の話しだとか、オブジェクト指向、関数型とかを解説したプログラミング言語論みたいな本でいい本はないですか？

>>536
ありがとう、まずさっそくこれ読む

githubと空目した、(解説は)日本語だったぜ同志よ!

おもろいな!

> let data = data;

おちょくってないぞ、こういうこと学ぶの好きだわ

>>537
AI による概要
プログラミング言語のパラダイム（型、オブジェクト指向、関数型など）を横断的に学べる名著としては、
(箇条書き略)
などが定番です。
これらは言語の「使い方」ではなく「考え方」を深め、プログラミングの本質に迫る良書として評価されています。
定番の良書（プログラミング言語論・パラダイム学習向け）
(箇条書き略)
選ぶ際のポイント
(箇条書き略)
これらの本は、単なる使い方を超えて、プログラミングの本質的な理解を深めるのに役立つでしょう。

ん。こんなのあったぞ

https://github.com/cmc-labo/hybrid-transpiler

既存資産対策、こういうのでいいんじゃねえの

パラダイムというかプログラミング言語を設計できることを目指すような本はないですか？
そのような本を読めば自ずと各プログラミング言語の理解が深まると思います。

>>542
ドラゴンブックはじめ沢山あるぞ
大学の授業も全国でやってるから教材も結構ある

>>543
コンパイラの本ですよね？
それとプログラミング言語の設計って関係ありますか？

>>544
おお、違うのか
文法の設計だけの本はあるかなあ
まつもとゆきひろ　言語のしくみ
という本が手元にあるけど、これもOSやメモリ周りの話が多いな

冬休みだなぁww

純粋に言語だけなら、LISPで終了してそうだね。以上解散

>>545

ありがとうございました。
大きなプログラムを書いたことがないため、なぜ型があるのか、なぜPythonでは型がないのかとか理由が分かりません。
その辺の理由がきちんと書いてある本が読みたいです。

あと、なぜこのプログラミング言語はこういう仕様になっているのかとかを解説した本が読みたいです。
ハードウェア的な制約でそうなっているのか、あえてそういう制約を設けているのかとか。

>>548
Pythonは型がないんじゃなくて動的型付け、C言語のような静的型付けじゃないだけ
ttps://ja.wikipedia.org/wiki/%E5%8B%95%E7%9A%84%E5%9E%8B%E4%BB%98%E3%81%91

プログラミング言語設計者のインタービューをまとめた本なら
- 言語設計者たちが考えること (THEORY/IN/PRACTICE) (あまぞん/dp/4873114713)
があるけど、なんかコンピュータサイエンス全体の基礎知識が足らないように見えるから、
プログラミング言語関係だけでなくもっと幅広く勉強したほうがいいと思う

KNUTH先生のThe Art of Computer Programmingとかパタヘネみたいなハードウェアに
関する本とかMINIXの本のようなOS関係とかそういう感じのもの

コンピュータはなぜ動くのか
プログラムはなぜ動くのか
矢沢久雄
の2冊がいいかね。ちゃんと読んでないけど第3版出てるのは、この手の本では珍しい。良さそう

>>550
ありがとうございます。

>>551
Knuthさんからは誤りを指摘したため小切手をもらったことがあります。
ハードウェアやOSやコンパイラについてほとんど知らないので基礎知識をつけようと思います。

>>552
なるほど、ご紹介ありがとうございました。

コンピュータの動作原理については和田秀男著『コンピュータ入門』という高校生向けの初歩的な本を読んだことがあるだけです。

>>542
古いけど読んだ中ではカーニハン著のUNIXプログラミング環境おすすめ
UNIXのシェルの使い方、プログラム基本原則である入力-処理-出力、既存コマンド活用とプログラム作成のどちらを採るかの判断、Cライブラリやカーネルのシステムコールの紹介と詳しい調べ方、コンパイラの作り方、manページ作成や製本の基礎
厚みの割に網羅量は圧倒的でこの類の原典なのではないかと思う
オブジェクト指向の流行以前にも興味が持てるなら是非

>>555

ありがとうございました。
古すぎるということはないですか？

>>555

偶然ですが、その本が本棚にありました。

https://imgur.com/4GnyGEH

処分しようと思っていたところです。

横から
UNIX環境のいにしえの部分は変わらず今でもほぼ使えるよ

>>558
読んでみようと思います。ありがとうございました。

>>542
こういうの?

プログラミング言語の概念と構造
https://www.kinokuniya.co.jp/f/dsg-01-9784894717701

コンピュータプログラミングの概念・技法・モデル
https://www.weblio.jp/content/コンピュータプログラミングの概念技法モデル

古い本なので手に入るかどうか

環境と同じ著者のプログラミング作法も馬鹿馬鹿しくて良い

>>560

ご紹介ありがとうございました。

>>561
その本の翻訳書も持っています。
ありがとうございます。

それらの本読んでたらアラフィフのおっちゃんだわｗ
温故知新というのはこの業界繰り返されるから面白い

主にハードウェアの進化で温故知新が回るんだよね
CPUの性能、メモリの容量、分散コンピューティング、GPGPUとか
何もしなくてもアプリの性能が上がるフリーランチな部分も多いけど、環境の進化で新しいことができるようになると、流用できる古い概念がほじくり出される

プログラミング言語C を最初に読んだ時、面白かったよ。
本を買った後の移動中の列車の中だけど

青木 峰郎　ふつうのコンパイラをつくろう
中田育男　コンパイラ ―作りながら学ぶ

>>555
コンパイラじゃなくてインタープリタじゃなかった？

>>557
その本ですね、読んだのは和書です
購入当時は私もUNIXに馴染めずに途中で断念しましたが、10余年を経る間に触れる機会もあったためか、今年読み返してみたところ楽しく読むことができましたよ

>>568
記載されているhocプログラムはインタプリタでした、失礼しました
C+yaccソース全掲載の規模で制御文や関数機能搭載しているのが素晴らしいと思います


スレチになりそうなのでC++に関する書籍にも触れておくと、コーニグら著のAccelerated C++が良かった。これも古い
Cを知らなくてもよい構成、後半でSTLのVectorクラスやStringクラスの簡易版を作る流れ、途中でイテレータや共有ポインタ？も作っており、解説も端折らないの姿勢が良く、完成したコードも骨組みだけなので本物STLよりずっと読みやすい。完成コード掲載はないので実習ができる人向け

おまけ
https://www.youtube.com/watch?v=5_UCkcb7iGY

時代の流れ的に、自分もC++からRustに移行していった方がいいんだろうなと思いつつも、なかなかできていない

このスレを見ているような人だと、どんな新しいプログラミング言語が現れても似たようなものだからすぐに使いこなせますか？

Ｃ＋＋にしがみついて新しきを否定する人は習得困難だろうね。

コードの書き方はいいけど、設計とかエコシステム使いこなすのは大変じゃね
例えば非同期処理どうするのがいいかは、Goのチャンネルの場合、Rustでtokio,sync使ったり、Boostの何かを使う場合で、それぞれ同じレベルで設計出来るようになるかね。簡単ではない

libuvは使ったけどなあ。同じシステム違う言語で作り直すとかなかなかないから

関数型のなんとかいうのは、ちょっとついていけるか自信なかった

関数型って新しいのかね。
C++やってれば暗黙に使ってるものに、明に名前つけて騒いでるだけに見えるんだよね。
要はshのパイプ程度のことを再発見して喜んでいるという。概念レベルで習得済みのベテランは気にしないでいいだろう

Lispのカッコ見ただけで諦めた

気にすんな。ライブラリ設計の要件なんかの方が重要だし難しい

2026年にもなって関数型を全く理解できてない自称ベテランC++プログラマーｗ
概念レベルで終わってるｗｗ

>>580
いらっさいませ解説どうぞ

JavaScriptやJavaでもフィルタくらいだよね。高度なお話を聞きたいな

templateメタプログラミングって関数型プログラミングでしょ?
そういやスレッドなくなったな

圏論とかテンプレート使ってれば利用してるじゃろ

>>579
Erlang は言語は楽勝だけど大変なのは OTP だよな

トヨタが独自の“ゲームエンジン”「Fluorite」を開発：FlutterとDartで次世代デジタルコクピットを再定義
https://xenospectrum.com/toyota-fluorite-flutter-game-engine-digital-cockpit/

Fluoriteの心臓部には、データ指向のECSアーキテクチャが採用されている。これはC++で記述されており、計算能力の限られた組み込みハードウェアにおいて最大級のパフォーマンスを引き出すための選択である。ECSはオブジェクト（Entity）に属性（Component）を持たせ、システム（System）が一括して処理する手法で、近年の高性能ゲームエンジンでは標準的な構造だ。これにより、メモリ効率の最適化と並列処理が容易になり、低スペックなハードウェアでも安定した高フレームレートを実現している。

>>586
Rustとは何の関係が？

ぼ、僕
こんなニュース見つけちゃった
皆んなに知らせなきゃ！

Rustじゃなかった! 新規採用にC++! ってとこかと

驚くべきなのか、驚くべきじゃないのかｗ

ゲームエンジン？
実車にはそんなもの要らないだろ、と思うのと
ゲーム用でC++はよくあるじゃねーか、で車輪の再発明か、元ネタはあってのフォークかなと思った

クルマのダッシュボードにゲームエンジン作ったのかね
5年くらいかけてそう

実車のシミュレーションに使うんだろ？

実験用にはUE5をワークステーションで動かせばいいと思うのだが、制限された環境は実車のことじゃないのかな

Rustはフレームワーク作りにくいんだよね
かなり工夫しないとRustのメリットを活かせないしクライアント側のコードが複雑になりがち

日産のルークスつうクルマのダッシュボードが3D表示で見通しの悪い交差点の死角のネコを表示したりするってCMでやっていたぞ。これはゲームエンジンだな。トヨタのも実車用であろう

テスラはgodotを利用してるんだね
初めて知った

>>586
トヨタだったか忘れたが、セガにCM用の車のモデリングを依頼していたらしい

将来のChrome代替ブラウザとして注目されるLadybirdがC++からRustへの移行を開始
https://gigazine.net/news/20260224-ladybird-cpp-rust/

ウェブブラウザのLadybirdがC++に代わるプログラミング言語としてRustを採用したことを発表しました。すでにJavaScriptエンジンをRustベースに置き換えることに成功しています。

LadybirdのGitHubリポジトリを確認すると、プロジェクト全体の59.8％がC++で構築されていることが分かります。しかし、開発チームはC++に代わるメモリ安全性の高い言語への移行を模索してきたとのこと。Apple発のSwiftも候補に上がりましたが、「Appleエコシステム以外でのサポートが限定的である」という理由から却下され、FirefoxやChromiumで採用例のあるRustを採用することが決定しました。

なお、C++からRustへの移植作業は「長期的で副次的な作業」として位置付けられており、今後もブラウザエンジンの開発ではC++が使われます。

RustフレドリなC++ができる前段階 正直楽しみでしかない

俺はC++をあきらめない

それもいいよね。数値計算用のコードなんてRustに変換する意味ないから

CPythonはRustの夢を見るか　Rust for CPythonがPython 3.16に向けた計画を公表
https://atmarkit.itmedia.co.jp/ait/articles/2604/14/news017.html

uvやruffなど、Rustで書かれたパッケージが幅広く使われるようになってきましたが、それらはあくまでも独立したツールをRustで実装したものです。ここで取り上げるのはCPythonの拡張モジュール（import文でインポートできるモジュールのこと）をRustで書こう、最終的にはCPython自体のコードベースにもRustを含めたい（そこまでいくといいな）というお話です。

計画段階の今はまだRustで拡張モジュールを書けるようにすることが目標ですが、CPython自体のコードベースでもRustが採用されることになったら、メモリ安全性やスレッド安全性の向上が期待されます。特にフリースレッド版Pythonの普及を考えると、その意義は小さくないでしょう。さらにCPythonの課題とされている実行速度を含めて、いろいろな改善が見られることになるかもしれませんね（今も進んでいるPython高速化計画との兼ね合いも気になるところです）。

うーん🤔Cより遅いんでしょ

うん、Cで慎重に書いてくれた方が嬉しい

誰が移植コスト払うんや。コタツ記事

AIにトランスレータを書かせる、くらいになると思うが、AI代もタダじゃないしな

やねうら王がトランスレーター書かせてたわ

ミトスに堅牢なCコードを書かせるのがベストソリューションになったな
今となってはRustの安全性は必要なかったと結論出た
覚えるだけ損だったぜ

所有権安全なCが成立すればなおいい

AIに監査させるのが現実的になったし、AIフレンドリ(人間には必ずしも優しくない)でいいぞ

>>608
それRustやなあ

>>609
Go がこれからそうなるかも

Ubuntu 26.04 LTSで本格的に進むRust版coreutilsへの移行
https://gihyo.jp/admin/serial/01/ubuntu-recipe/0913

「RustがLinuxをAIから救う」--大御所カーネルメンテナーが語る安全の仕組み
https://japan.zdnet.com/article/35248150/

今こそC++復活の時

C++言語に「ネコミミ」演算子!? かわいい顔して強力なメタプログラミング機能を提供
「C++26」で導入へ
https://forest.watch.impress.co.jp/docs/serial/yajiuma/2117584.html

それでは、その演算子を評価するC++コンパイラを屏風から出してください

C++ 機能追加、関係している人達は凄い馬力あるな

【海外記事紹介】「RustもバグるならC++と同じ」は誤解 — CVE報告基準の根本的な違いをcurlで解説
https://techfeed.io/entries/6a306798931f6b51a25b8eb3

C++標準ライブラリが15年間自分を否定し続けている - std::functionは「遺産、新コードでは避けよ」
https://techfeed.io/entries/6a1366c1d7ab5858a6347998

記事の発端は、Sandor Dargoが公開したstd::copyable_functionに関する記事の一覧表に書かれた衝撃的な一行だ。C++11で導入されたstd::functionについて、こう記されている。
std::function: Legacy. Avoid in new code.（遺産。新しいコードでは避けよ）
C++11はわずか15年前の仕様だ。にもかかわらず、その目玉機能の一つがすでに「遺産」扱いされている。これは異常事態ではない。C++標準委員会は過去15年間、驚くほど一貫して自らの機能を否定し続けているのだ。

std::auto_ptr（C++98）は、コピー時の移動セマンティクスが標準コンテナを破綻させた。C++11で非推奨化、C++17で削除された（N4190）。
動的例外仕様（throw(X, Y)）は18年間標準にあったが、C++11で非推奨、C++17で削除された（P0003R5）。代替はnoexceptである。
最も恥ずかしいのはC++11のガベージコレクション・インターフェースだ。委員会はstd::declare_reachableなどを標準化したが、主要実装は一度も真のガベージコレクタを提供しなかった。この機能はC++23で削除された（P2186R2）。12年間、誰も使わない機能のために標準文書が費やされたのだ。

正式に非推奨化されていないが、業界のシニアC++エンジニアが皆、新人に初日から避けるよう教える機能もある。

std::regex（C++11）について、委員会自身の論文P1844R1は「std::regexのパフォーマンスは他の利用可能な解決策と比較して非常に劣る」と記録している。
std::listについては、Bjarne Stroustrupが2012年のGoingNative基調講演で、「大きなコンテナの中央への挿入」というstd::listの教科書的用途でさえ、std::vectorが勝つことを実証した。線形スキャンが支配的で、ポインタチェースがキャッシュミスを引き起こすためだ。
std::async（C++11）も同様だ。返されるfutureのデストラクタが非同期操作の完了までブロックし、N3679にはデッドロックの罠が文書化されている。代替は15年後のC++26でようやく導入されるsender/receiver（P2300）である。

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

CPUを信じる時代でもなくなってるって感じだな C/C++は進化から逃げるな

運よくチェックサム不一致を検出できたときだけみたいに書いてあるけど、普通はデータが壊れたらチェックサム不一致になるよな
Rust版はチェックサムをスルーして速度を稼いでるのかね

ルストのこうゆう誇大評価みたいなの大嫌い

ネコミミ演算子😺

Rustはイメージだけで絶賛する層がいるからね
Linuxでも使えるようになって実力十分だろ

ここからC++大逆転のシナリオを教えて

圧縮時(伸長時？)のCPU不具合によるチェックサム異常を検出した時、Cならそのままエラー処理ができてRustはクラッシュするしかない様に読めてしまうのだが

>>625
エプスタインみたいな人がRust製アプリで秘密情報を管理していたのに、中国やNSAが勝手に共有していたと分かれば、エロい人達が自主的にRust利用を止めるんじゃね

Rustは北朝鮮
C++は欧米

>>626
そうっぽいね

アルゴリズム的にpanicになるのは別にいいと思うんだけど
それがページ全体のクラッシュだったりブラウザのクラッシュにつながるのは
Rust特有のpanicハンドリングの問題だな

バグ回避はcopy_from_slice使って最初からまとめて書けばいいと思うんだけど性能に差が出るのかね？

buf[0..2].copy_from_slice(&dist.to_le_bytes());
だと
mov word ptr [rcx + rdi], si

let [dist1, dist2] = dist.to_le_bytes();
buf[0] = dist1;
buf[1] = dist2;
だと
mov byte ptr [rsi + rdi], cl
mov byte ptr [rsi + rdi + 1], ch //<-CPUバグの引き金

panicしない未定義動作よりもpanic推奨

Linux内ならpanicでいいんじゃね。Cでもpanicした方がデバッグ助かる。言語仕様としてのpanicのことなら、どうしてんだろな

Rustでもpanicにするかどうかは自由に決められる
あくまで標準ライブラリがそうするというだけであって、言語仕様的に強制されることはない
C++でもCでもそうだけど、標準ライブラリと言語仕様は分けて考えないと

標準ライブラリを使わないアプリケーション実装なんて考慮する必要はあるのかね
さすがに特殊するすぎるきがするわ。慣習や文化も含めてその言語だろ

>>634
C / C++ / Rust などはシステムプログラミング言語なので、アプリケーション実装に限定された言語じゃない

>>629
それは単にスレッドやプロセスを適切に分けてないからだぞ

CもLinuxカーネル内ではprintfすら使えないからね。OS内の開発で標準ライブラリ使えない。あれはユーザーランド向けのものだ

そんな事言うならstrncpyのバッファオーバーラン問題はC言語の責任じゃないぞ

カーネル内で使えるstrncpyは標準ライブラリの仕様だけ真似てるだけだからね。
標準ライブラリでもディコンした方がいいのじゃね

>>636
そういう問題じゃない
原因はなんであれRustのコードは常にpanicする可能性がある
にもかかわらずpanicが発生した場合にどう処理するかを全く考えていないのが問題

スレッドやプロセスを適切に分けるというだけでは不十分
たぶんそれを理解してないRust開発者が多いから繰り返し同じ問題が起きてる

Rustはサンプルにunwrap()が多過ぎる
むしろunwrap()禁止で良いくらい

// 初心者
let value = result.unwrap();

// 級位者
let Ok(value) = result else { unreachable!() };

// 有段者
let value = result.unwrap();

let value = result?;

>>640
それはRustについてちゃんと知らないからやね
panic するのは panic してもいい環境で使われる、むしろ panic した方がデータを守れる標準ライブラリの一部機能だけ
言語仕様に panic は組み込まれてないから「常にpanicする可能性がある」は普通にウソ

>>638
そもそもC言語の責任だなんて誰も言ってないぞ
ミスでそれが起こる環境を撲滅しようって話でしかない

>>639
関係ないと思うが

>>640
>Rustのコードは常にpanicする可能性があることを忘れないでね
「panicする可能性が常にある」のは確かだけど
『「常にpanic」する可能性』は排除出来る

>>646
それも違って、panicする可能性が常にあるわけでもなく、panicする可能性があるコードを書くとpanicする可能性があるだけなんだよな

Cと同じでよくね

>>648
なぜか全力で違うって根拠なく言い張りたいらしいんだよな

LinuxのRustで開発してみたら理解が深まると思うよ

panic を体験する為に Rustを使う会か

標準ライブラリを除いたRustってみんなそんなにLinuxのカーネル開発にコミットしてるの？

一番現実的で有用な開発対象で、各自の固有事情が排除できそうだから挙げてる

>>618
一番恥ずかしいのはこの記事を載せた奴だろｗ
使われない規格が生まれることや、古い非効率なやり方があることがそんなに嫌なら、常に現在主流の機能しか載せない言語作ってろよ
更新の度に猛スピードで互換性が破壊され続ける言語を誰が使うのかは知らんが

>>627
それはプログラミング言語というものを理解していない
暗号化が破られるかどうかは暗号化のアルゴリズムの問題であって、Rustの品質がどうという問題ではない

>>618
最も恥ずかしいのはこの記事だ

Rustはシンプルに書きやすい

書きやすいかな?
String, to_str, to_string, Boxあたりは結構ひどいと思うし
糖衣構文の余地(&=参照・借用 vs @=所有etc.)はあると思う
オレオレ言語作るほど若くもないからバニラのまま使ってるけど

「書きやすい(ということにしときたいという願望)」を本気で受け取るなｗ

Rust終了早かったな

Fil-C：開発者を二分するメモリ安全革命
https://biggo.jp/news/202511081813_Fil-C_Memory_Safety_Debate
Rust に書き直さなくても C 言語をメモリ安全にできる Fil-C を試した
https://zenn.dev/mattn/articles/cace8c5a00b9cc

Rustより遅いCはさすがに擁護できない

瞬間的にはunsafeで良い、とかいう最適化がそのうち出る

早期の最適化はなんとかっていうし、まずは足場固め

>>659
頭悪いとそう思うんだなｗ

Rustifying Image Codecs in Chromium
https://microsoftedge.github.io/edgevr/posts/Rustifying-Image-Codecs-in-Chromium/
「Chromium」の画像デコードをRustに 〜脆弱性削減、処理時間も最大50％短縮
https://forest.watch.impress.co.jp/docs/news/2127553.html