C vs C++ vs Rust Part.2

**デフォルトの名無しさん** · 2021/12/15(水) 12:35:50.91

競え
※前スレ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

**デフォルトの名無しさん** · 2022/01/01(土) 02:31:24.00

>>335
GCの有無で何が変わりますか？
JavaやRuby、Pythonは組み込みにも使われますし、宇宙にだって行きます。
Rustよりずっと広範囲に使われています。
Rustで作られた実用的なソフトウェアはFirefoxしかないじゃないですか。
しかも、そのFirefoxだって熱心な信者以外誰も使わない。
それと比較したら、これらの言語は実用的に使われています。
GCが在ろうとなかろうと。

**デフォルトの名無しさん** · 2022/01/01(土) 02:32:19.06

>>324
大体代替手段があるのはそうだと思います
例えばnaked functionやglobal_asmは別途asmなりCなりからオブジェクトファイル生成してリンクするという代替手段があります (これがありならC-FFIできる言語は皆同等になってしまいますが...)

もともと C++ でできることは "全て" できるというかなり強い主張をされてた人がいたのでそれは言い過ぎじゃないかと言いたかっただけです

>>332
ご参考まで
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java.html
他の言語との比較もありますよ

**デフォルトの名無しさん** · 2022/01/01(土) 02:33:17.91

Rustのポジションに取って変わりたいなら、RustみたいにLinuxのKernelコードに取り込まれていってくれるとわかりやすいんだけどね
なぜC++を含む他の言語はLinux Kernelに採用されないのか、って考えると差が明瞭になってきそうだ

**デフォルトの名無しさん** · 2022/01/01(土) 02:34:00.98

Firefoxのバグの多さを考えても、Rustはバグを生産する言語のように思います。

**デフォルトの名無しさん** · 2022/01/01(土) 02:35:06.26

>>338
ドライバにクラスは必要ないからでは？

**デフォルトの名無しさん** · 2022/01/01(土) 02:39:59.20

>>336
RubyやPythonは遅すぎ＆メモリ食い過ぎで話にならない
例えばクックパッド社はRubyで書かれていたのをRustへ置き換えて経費節減に成功している

**デフォルトの名無しさん** · 2022/01/01(土) 02:42:24.09

そういえば Windows 10にRust使う話ってどうなったんだろうか

>>336
以下の記事にメモリ安全な既存の言語ではだめでCやC++やRustでないといけない理由
それらの中でもRustが良いとされる理由が書かれていますよ
https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe-systems-programming/

**デフォルトの名無しさん** · 2022/01/01(土) 02:57:17.29

>>339
FirefoxについてC++コードをRustに書き換えたらセキュリティに関わる脆弱性数がどうなるか分析した記事がありました
https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/
結論としては完璧ではないけどRustの方がバグを減らせるということのようです

MS ResearchやGoogleのAndroidチームも類似の調査をやっていてRust採用は効果有りと判断しているみたいです

**デフォルトの名無しさん** · 2022/01/01(土) 04:08:48.59

JavaやHaskellも多くの人がC++より優れていると分析しています。
速く容易で安全なのです。
全ての点でC++を上回っています。
では、それらの言語を比較した場合、どれが最も優れているのでしょう？

**デフォルトの名無しさん** · 2022/01/01(土) 04:11:14.25

ほとんどすべての言語がC++より優れていると主張します。
という事は、C++はもっとも劣った言語のひとつなのです。
Rustはもっとも劣った言語より優れていると主張しますが、優れた言語、例えばJavaやHaskellと比較したら、かなり劣っているのでは？

**デフォルトの名無しさん** · 2022/01/01(土) 07:34:43.36

多くの人がRustとC++と比較している
比較するなら優れたもの同士を突き合わせるはずだ
なのにJavaやHaskellは影も形もないつまり論外ってことだ
全ての言語がC++に対して優位性を主張するのも
C++が最も現実的で優れた言語だと認めているからであって
わざわざ劣っているものと比較する必要なんてないからだ

**デフォルトの名無しさん** · 2022/01/01(土) 09:08:27.19

>>344
JavaやHaskellがC++より常に高速というのは明確に誤りです
https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html

ではC++がこれらの言語より優れているかというとそうではありません
言語にはそれぞれ得手不得手があります
唯一絶対の尺度で優劣を決めようとするのではなく、ある特定の用途に対してどの言語が適しているかという観点で議論した方が生産的かと思います

**デフォルトの名無しさん** · 2022/01/01(土) 09:44:43.30

スレタイ読め。

**デフォルトの名無しさん** · 2022/01/01(土) 10:50:55.11

いつもの人の自作自演

**デフォルトの名無しさん** · 2022/01/01(土) 19:02:54.41

GitHub・Cookpad などは、遅いRuby on Rails から、Go・Rust などへ移行している

2021年10月には、GitHubのコピーのGitLab が上場し、時価総額は約1.9兆円！
こんな大きい時価総額でも、Railsを使い続ける宣言をしている

基本、Railsは中小ベンチャーが、高品質なサービスを作るツール。
2億レコード・取引先が2万社みたいな規模でも、問題ないと言ってた

他には、組み込みのmruby の本も出た。
Webで使えるmrubyシステムプログラミング入門、近藤宇智朗、2020/11

宇宙開発などの組み込み用、MicroPython, Lua, Squirrel の代替になる。
Ubuntu 18.04, C99 対応

人工衛星イザナギ・イザナミで、使っている

**デフォルトの名無しさん** · 2022/01/01(土) 21:35:42.72

C++もJavaも実行時にnull pointerによる参照が起きる可能性があるためどちらも安全性に劣るよね
Rustではenum Option使用でnull pointerによる参照が絶対に起きないことをコンパイル時点で保証した上で
コンパイル後は最適化でOptionがNoneの時にnull pointerを使うという二段構えにより
Rustはコストをかけずに無駄なく安全性の保証を実現しているところに感動した

**デフォルトの名無しさん** · 2022/01/01(土) 21:45:09.34

null安全ぐらいはモダン言語なら当たり前の機能なので、もはやメリットとは感じないわ
例えばTypeScript、Swift、Kotlin、Haskellとか

**デフォルトの名無しさん** · 2022/01/01(土) 21:56:26.71

C++とJavaが前近代的でダメな言語なだけだよな

**デフォルトの名無しさん** · 2022/01/01(土) 21:59:01.05

Javaは速度を追求した言語だから。

**デフォルトの名無しさん** · 2022/01/01(土) 22:39:11.50

Haskellは安全性と並列化を追求した言語です。

**デフォルトの名無しさん** · 2022/01/01(土) 22:58:31.22

RustはHaskellの長所である型クラスをトレイトとトレイト境界で採り入れていたり
HaskellのMaybeモナドやEitherモナドを採り入れてRustの型の核としているところにも感動した

**デフォルトの名無しさん** · 2022/01/01(土) 23:02:32.16

システムプログラミングでCに代替となれるほどRustがイケてるのは、
null安全やメモリ安全はモダンな言語だから当然として、データ競合が起きないことも保証しつつ、実行速度もCに劣らなくて、
それでいてRustと多少のアセンブラだけ使えば、OSや組み込みソフトウェアも普通に記述できるほどフットプリントの小さい低レベルな言語だから

**デフォルトの名無しさん** · 2022/01/01(土) 23:08:54.95

システムプログラミングにはJavaのほうが向いています。
単純に速いからです。
Javaは宇宙でさえ使われる安全で実績のある言語です。
しかも速い。
実行時最適化を行わない言語では無理な速さです。

**デフォルトの名無しさん** · 2022/01/01(土) 23:23:23.09

結局RustはHaskellの真似をするだけの偽物言語にすぎません。
Haskellの並列性、安全保証を移植するには、結局Haskellになるしかないのです。
RustはいずれHaskellになるでしょう。
その時もまだRustと呼び続けるのでしょうか。

**デフォルトの名無しさん** · 2022/01/01(土) 23:45:51.79

>>358
ねー、>>347 無視しないでよー

**デフォルトの名無しさん** · 2022/01/02(日) 01:31:01.49

rustのnull安全？はクリティカルコンテキストでも保証されるんか？

**デフォルトの名無しさん** · 2022/01/02(日) 02:22:18.22

もちろんです。

**デフォルトの名無しさん** · 2022/01/02(日) 08:42:35.10

現状でRustの欠陥は指摘なしなのか
まあ優れた言語だから主流になるとも限らんけど
ここはRust礼賛が多くて参考にならんな

**デフォルトの名無しさん** · 2022/01/02(日) 08:43:38.07

>>360
キチの相手するならメールかなんかでやってくれ

**デフォルトの名無しさん** · 2022/01/02(日) 12:04:39.89

キチの相手するスレやぞ

**デフォルトの名無しさん** · 2022/01/02(日) 14:18:19.00

良いという人だって使ったことないんだから、欠点なんか出てこないよ。

**デフォルトの名無しさん** · 2022/01/02(日) 14:52:25.82

>>361
クリティカルセクションのこと？

**デフォルトの名無しさん** · 2022/01/02(日) 19:27:00.77

int型(32ビット)でyy/MM/dd/HH/mmの形で日時を実装しているプログラムは、2022年1月1日0時0分(2201010001)に32ビットの最大値(2147483647)を越えてしまい、エラーが発生する。そういう実装をしているMicrosoft Exchangeでは既に問題が発生中。
みんな仕事始めになって気づいて大騒ぎに

**デフォルトの名無しさん** · 2022/01/02(日) 19:33:55.23

DosDateTime爆死確認w

**デフォルトの名無しさん** · 2022/01/02(日) 20:28:27.33

>>367
ハードウェア割り込みの割り込みコンテキストのつもりで書いた
社内独自用語なんだと思う
そこは気にせんでくれ

**デフォルトの名無しさん** · 2022/01/02(日) 21:12:20.77

>>361
Rustのポインタ(参照)および実体にはnull/nil/undefined等が一切ない
そのためnull問題が起きることはなく所謂null安全が保証されている

nullになる可能性がある場合は汎用のオプション型であるenum Option<T>型を用いる
このOption<T>はenumとしてSome(T)とNoneの二値を取り型Tは任意な型
つまり所謂NullはenumのNoneで表現され型Tとは異なるためnull問題が起きようがない

これで効率やコストはどうなるのか？
null(RustではNone)が使われない時は型Tのまま扱うので従来と同じ
null(RustではNone)が使われうる時は型Option<T>として扱う
型Option<T>から型Tを使うにはNoneでない確認が必要だがこれこそ必須な確認コスト
ポインタ(参照)の場合は値がnullすなわち0になることがないためコンパイル後はNoneが0で表現される最適化となる
つまり結果的にはC/C++と同じになるのだがRustは上述のようにコンパイル時点でnull安全を保証できる点で異なる

**デフォルトの名無しさん** · 2022/01/02(日) 22:09:32.73

Javaのほうが安全。

**デフォルトの名無しさん** · 2022/01/02(日) 22:11:45.12

ぬるぽ例外が発生するから安全じゃないとか言う書き込みがあった。
これはウソ。
ないほうが良いならCはヌルポを検出できないから安全って事になる。
Javaは検出して例外を発生させるから安全なのです。
キチガイに騙されるな。

**デフォルトの名無しさん** · 2022/01/02(日) 22:18:47.48

>ないほうが良いならCはヌルポを検出できないから安全って事になる。

発生したことを検出できないことと発生しないことを意図的に混同している

**デフォルトの名無しさん** · 2022/01/02(日) 23:11:16.20

Firefoxの惨状を見れば全然安全でないことがわかるのに。
なぜ安全と言い張るのか。

**デフォルトの名無しさん** · 2022/01/02(日) 23:20:08.47

CもC++もJavaも実行時にヌルポ発生するからいずれもダメ
Rustは実行時にヌルポ発生しないことが保証されているから安全

**デフォルトの名無しさん** · 2022/01/02(日) 23:22:44.87

RustアンチがRustを称賛してるのではないか。

**デフォルトの名無しさん** · 2022/01/03(月) 05:19:23.74

その可能性高いかも

**デフォルトの名無しさん** · 2022/01/03(月) 06:00:15.35

学会が自らキチガイを演出する手口に栗卒

**デフォルトの名無しさん** · 2022/01/03(月) 16:10:29.79

RustはC++と同じ匂いがする

**デフォルトの名無しさん** · 2022/01/03(月) 17:15:54.33

このようにRustをやってる奴は性格が捻じ曲がってる

**デフォルトの名無しさん** · 2022/01/03(月) 17:22:00.01

rustってc++より難解だよな
こんな言語が流行るとは思わない

**デフォルトの名無しさん** · 2022/01/03(月) 17:25:50.42

他の言語と比べればめちゃくちゃ難解だし、Rustコミュニティでもどうすれば簡単になるのかいろいろ議論されている

**デフォルトの名無しさん** · 2022/01/03(月) 17:32:24.16

ワイじゃないけど必死に褒めてるのにアンチだとか、ウジ沸いてる

**デフォルトの名無しさん** · 2022/01/03(月) 17:37:11.03

Rustファンも、こんなスレに書き込みしないで初心者向け解説でも書けばいいのにな。

**デフォルトの名無しさん** · 2022/01/03(月) 17:41:11.19

https://seiya.me/this-website-is-now-powered-by-kerla
このOS Rustで書かれている割にはメモリリークで落ちたりするらしんだけどなんで？

**デフォルトの名無しさん** · 2022/01/03(月) 17:50:43.83

必須じゃないけど他の言語も知らないRust初心者が異常に増えてきているからトンチンカンな推しをするだけで
コミュニティの増加は良いことだが、初心者が書いた意味不明なコードを直すのはあんたら
Null安全系の推しをしてるのはド素人

**デフォルトの名無しさん** · 2022/01/03(月) 18:13:06.37

メモリ安全が守れればすべてが安全と謳ってる連中は原発は止めれば安心安全とほざいてた奴等と瓜二つ

**デフォルトの名無しさん** · 2022/01/03(月) 20:13:37.59

>>386
そもそもRustはメモリリークが起きないことは保証してくれない
参照カウントが循環参照にならないようにしたり、不要になった参照が残り続けたりしないようにするのはプログラマの責任
なのでプラグラム側になんらかのバグがあったのではないかと

メモリ管理周りを標準ライブラリやOSに全部任せられる普通のアプリケーションとは違って
全部自分でやらなきゃいけない自作OSだからバグなく作るのは難しいというのはあるかと思う

**デフォルトの名無しさん** · 2022/01/03(月) 21:09:45.15

COBOLならメモリーリーク起こらないよ

**デフォルトの名無しさん** · 2022/01/03(月) 21:31:36.31

>>389
結局C++と同じで習熟甘いやつが作れば問題起きまくりなの？

**デフォルトの名無しさん** · 2022/01/03(月) 21:51:41.06

>>387
Rustを含めていまどきの言語がnull安全なのは常識
むしろC++やJavaが古すぎて様々な点で時代遅れにすぎない
もちろんRustはもっとその先へダングリングポインタ排除とGC排除を両立した点にある

**デフォルトの名無しさん** · 2022/01/03(月) 22:09:21.15

このように攻撃性と倒錯を丸出しを両立してしまうと初心者っぽさが出てとても引っ掛かりやすい
どこで覚えたのかNull安全からダングリングポインタという関連性がない事を言い出す。
ゴミくずが降り積もっていく・・・

**デフォルトの名無しさん** · 2022/01/03(月) 22:13:14.24

>>391
一般的にメモリ関係諸問題のうちメモリリークのみはGC利用でしか解消と判明している
しかし一方でRustではメモリリークを起こすのも意図的にしか起こせない
Rustには所有権の概念があるため特別に複数の所有権を認める特別な参照を
自分で明示的に使用した上でさらに循環参照を生じさせた時のみメモリリークが生じうる
もちろんそのような場面でも通常は弱参照を併用するためメモリリークは起きない

**デフォルトの名無しさん** · 2022/01/03(月) 22:14:15.40

>>386
自分で独自OSのランタイムやGCを作って
その上で稼働させるアプリがリークを起こすかどうかは
アプリだけじゃなく作ったランタイムやGCのロジックに依存するよね

**デフォルトの名無しさん** · 2022/01/03(月) 22:17:11.19

nullで落としてるようなバカがnull安全な言語使っても同じく死亡するコード作るだけにしか思えんがな。
あれで救えるコードなんてほとんどないと思うが。

**デフォルトの名無しさん** · 2022/01/03(月) 22:35:34.97

もっとその先へ！草
上のOS記事の作者はリークというかフラグメンテーションの発生だと推測してるが絶対読んでないね。
「意図的にしか起こせない」はい嘘

**デフォルトの名無しさん** · 2022/01/03(月) 22:36:13.58

nullで落としてるようなバカって例えばGoogleのChromeチームとかかな？
まぁ全人類バカなのでしょうがないね

**デフォルトの名無しさん** · 2022/01/03(月) 22:54:33.28

ポインタ(参照)になぜかnull値を許してしまう欠陥言語でのみnull問題が起きる
そうでない普通の言語にとってnull安全は当たり前でありそれを意識することすらない
欠陥言語の存在に対してのみnull安全なる言葉の存在意義がある

**デフォルトの名無しさん** · 2022/01/03(月) 22:56:23.92

>>395
そりゃランタイムやライブラリがバグってたらしゃーないわ

>>396
いや、コンパイルエラーになるからそこでちゃんと直せばいい
まあバカがコンパイルエラーを回避することが目的になって余計ひどいことになる未来もあるけどw

**デフォルトの名無しさん** · 2022/01/03(月) 23:21:21.46

null安全はマジで当たり前すぎてメリットでもなんでもないから
nullの話なんてしたくないわ

**デフォルトの名無しさん** · 2022/01/03(月) 23:22:53.63

そもそもnullのある言語でもnull参照で死ぬなんてのは
よっぽどのクソコードでテストもしてないときだけだろ

**デフォルトの名無しさん** · 2022/01/03(月) 23:26:20.57

関数の定義からnullableが否かが分かるのがOption<T> のうれしいところと思う
加えて引数や戻り値の所有権が分かるのもRustのうれしいポイントかと

**デフォルトの名無しさん** · 2022/01/03(月) 23:28:42.03

fool proofの話をすると Option<T> でも闇雲に unwrap はできるので考えなしのプログラムだとクラッシュする点は変わらない
SEGVじゃなくpanicになるとか、落ちる可能性のある箇所が明示される点でnullよりはマシだが

**デフォルトの名無しさん** · 2022/01/03(月) 23:34:21.19

ほんま、そういうことやな
null安全で助かるケースなんてそもそもわずかしかないんだ
unwrapだとかゼロ除算だとかいろんなロジックミスで結局は落ちる

borrow checkerのおかげでデータ競合が起きない、とからへんが重要なメリットと思う

**デフォルトの名無しさん** · 2022/01/03(月) 23:35:17.83

いやいやww

**デフォルトの名無しさん** · 2022/01/04(火) 00:27:33.52

>>402
> よっぽどのクソコードでテストもしてないときだけだろ
そう言うのがボロボロ転がってますけどw

**デフォルトの名無しさん** · 2022/01/04(火) 00:32:09.36

こちらはNull安全協会です、今なら3,000円お支払い頂くとより安全になり免許証入れまでついてます。
本協会ではNullは許しませんが、DBなどの道路にNullが転がっています。
また外部値など入力が無いことを示すのはResult::Errや特異値:-1やNaNなどで表すものではありませんので
クソ設計はやめてください、Option::NoneでNullを示し、ほかの言語と同じく必ずmatchで検査してください。
unwrapもダメです。Null安全協会では皆様に頂いたご声援でド素人が語れてゴリラのマウントのように
ウッホウッホホと潤っています。またNull安全語り部Rusterの攻撃性は以上ですので近づかないでください

**デフォルトの名無しさん** · 2022/01/04(火) 10:11:55.33

C++の利点は何だろ？

**デフォルトの名無しさん** · 2022/01/04(火) 10:32:59.80

>>409
自由であること

**デフォルトの名無しさん** · 2022/01/04(火) 10:52:02.62

Rustはコーディング刑務所

**デフォルトの名無しさん** · 2022/01/04(火) 11:03:52.07

Null安全性はまともなUXを提供したい場合に生産性を改善する道具
なくても落ちることはほとんどないみたいな視点でしか捉えてないなら価値を理解してない

**デフォルトの名無しさん** · 2022/01/04(火) 12:02:58.31

誰のUXやねん
誰の生産性やねん

**デフォルトの名無しさん** · 2022/01/04(火) 13:26:40.47

>>386
GCはメモリーリークおこすし
どこで起こすかが実装によって変わる

GCはゴミなんよ

**デフォルトの名無しさん** · 2022/01/04(火) 13:32:57.78

>>409
もっとも健全なアプリを作りうること

**デフォルトの名無しさん** · 2022/01/04(火) 14:39:07.88

>>409
鼻から悪魔が出てきたりしても言語仕様を逸脱していないこと

**デフォルトの名無しさん** · 2022/01/04(火) 17:56:16.15

Rustはコンパイルできたら問題は起きないみたいに思ってたけど違うのね
これじゃやっぱり初心者に毛が生えたようなのがゴミコード量産するのかな

**デフォルトの名無しさん** · 2022/01/04(火) 18:04:30.86

ゴミコーダ矯正所

**デフォルトの名無しさん** · 2022/01/04(火) 18:35:43.62

それはそう
たとえPrologを使ってもバグはなくならない

でもコンパイラのチェックでなくせる類のバグならなくしたいよね

**デフォルトの名無しさん** · 2022/01/04(火) 19:10:18.46

コンパイルを通すために問題の発生するコードを書くとかも考えられるんじゃねーの
そっちのほうが分かりにくいような気がする

**デフォルトの名無しさん** · 2022/01/04(火) 19:35:35.54

>>417
あらゆる問題が起きないかというとそうではない(というかそんなプログラミング言語存在しないと思う)けど
大部分のコードのメモリ安全性がコンパイル時に保証されるのはかなり大きなメリットだと思う

例えばuse-after-freeやバッファオーバーフロー、データ競合なんかは問題が発生してもプログラムかその場でクラッシュするとは限らず、しばらく正しく動くように見えてしまう場合もある
この手の異常の原因特定は難しいので、rustでコンパイルエラーや実行時の問題発生時のpanicなどで即問題箇所が分かるようになっているのはかなり嬉しい

**デフォルトの名無しさん** · 2022/01/04(火) 19:41:25.66

初心者に毛の生えたようなのがゴミコード量産しないようなプログラミング言語ってそもそもどういったものなんだろうか
記述に自由度がなく誰がどう書いても同じになるような言語？

**デフォルトの名無しさん** · 2022/01/04(火) 19:51:44.75

それpythonがうたってたきがする

**デフォルトの名無しさん** · 2022/01/04(火) 19:52:02.24

386みるとメモリリークの原因が不明っぽいんだけど
言語処理系にメモリ関連任せられるにしても結局原因不明のバグが残るんじゃ意味ないんでわ

**デフォルトの名無しさん** · 2022/01/04(火) 20:04:11.59

>>424
OS書いてるのに言語処理系にメモリ管理任せられるわけないだろ
自作したメモリアロケータのバグとしか思えんが

**デフォルトの名無しさん** · 2022/01/04(火) 20:06:56.90

>>424
バグの数が0じゃなきゃ意味がないというのは違うのでは
100個バグがあるのと1個しかないのでは開発効率が全然違う

**デフォルトの名無しさん** · 2022/01/04(火) 20:50:34.04

>>409
C++の利点は過去資産
既にバグが枯れた過去資産を活用するのが得策
その他の点ではRustが全て完全に有利

**デフォルトの名無しさん** · 2022/01/04(火) 20:53:09.33

Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2022/01/04(火) 21:18:13.95

C++でうまくかけないヤツとか構造化の仕方がヘタクソなだけだろ

**デフォルトの名無しさん** · 2022/01/04(火) 21:26:13.33

>>424
そう思うんならそれでいいじゃない
意味ないってことで

**デフォルトの名無しさん** · 2022/01/04(火) 22:20:27.31

>>430
それでいいということを認めるなら、>>424にもちゃんと反論しろ

**デフォルトの名無しさん** · 2022/01/04(火) 22:35:39.57

>>428
で、バグが減ったか？まるで変わらんやろ。馬鹿馬鹿しい。

**デフォルトの名無しさん** · 2022/01/04(火) 22:39:34.49

C++の存在意義がゼロになったわけではない
C++で作られた過去の莫大なライブラリは今後も併用される
C++しか使えない過去のプログラマーの活用のためにC++を用いる案件もしばらくは残る

**デフォルトの名無しさん** · 2022/01/04(火) 22:40:33.65

議論したいならまず相手を選ぼうね
ルサンチさんを相手にしても理性的な議論にはならんから

**デフォルトの名無しさん** · 2022/01/04(火) 22:57:10.37

個人的には大規模なC/C++の組み込み開発で散々メモリ破壊系の不具合に泣かされてきたから組み込みでRustを使う流れがきてるのに期待してる
国産RTOSだとKMCのToppersベースのOS、SOLIDが最近Rustに対応し始めた