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

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/07(日) 15:41:53.17

とするとC++とPythonの下位は全く同じアルゴリズムを使っているが、
C++の言語性能のおかげで2500msに収まっている

考えてることが同じ人間でそう変わるわけもない

**デフォルトの名無しさん** · 2023/05/07(日) 15:43:48.79

まともにプログラミングができる人ならばC++かRustもやるだろうしな
高速さと省メモリで他の言語とはまるで違う
このスレになぜかJavaのほうが速いと主張してる一匹いるが

**デフォルトの名無しさん** · 2023/05/07(日) 15:46:07.10

効率の良いプログラムを書けない人はAI代替でいいから不要となるんじゃないか
C++とRustだけが残りそうだ

**デフォルトの名無しさん** · 2023/05/07(日) 15:47:17.20

e問題を見れば分かるけどおそらく出題内容をベタにそのままプログラムすると遅くなる
c++の人たちはそんなことはしてないと思う

**デフォルトの名無しさん** · 2023/05/07(日) 15:48:14.10

いいすぎかな
実際自分は解いてないで雰囲気で言ってるだけだから的外れかもしれない

**デフォルトの名無しさん** · 2023/05/07(日) 15:57:11.39

後は手元でのコンパイル時間だろうか
gccとrustcでせいぜい100行200行のコード、コンパイル時間に差が出るとも思えないが

100倍も違ったらさすがに競技プログラミングでは忌避されるがそうじゃあないでしょう
そして書いてすぐ試せるとなるとpythonとかになる
にも関わらずRuby利用者がいないのは悲惨としか言いようがない

**デフォルトの名無しさん** · 2023/05/07(日) 16:01:14.86

競プロに限らず無駄な効率悪いプログラムを書くプログラマーが溢れてる
そいつらで十分な分野はAIで置き換わるのたろう
ちゃんと考えて効率良いプログラムを書けるプログラマーならC++でもRustでも会得すぐだしな

**デフォルトの名無しさん** · 2023/05/07(日) 16:03:17.49

pythonは有名ライブラリ内でavx512使ってたりする
コードが寄贈されたりしてる

**デフォルトの名無しさん** · 2023/05/07(日) 16:20:26.96

あとはCargoと競技プログラミングの相性だろうか

**デフォルトの名無しさん** · 2023/05/07(日) 17:00:28.41

連休最終日だというのにお前らは

**デフォルトの名無しさん** · 2023/05/07(日) 17:27:29.15

>>206
効率の良いプログラムもAIが書いてくれるようになる

**デフォルトの名無しさん** · 2023/05/07(日) 17:44:09.69

>>214
現在のAIの方式だとそれは無理だな
論理の理解がなく例えば素数すら列挙する以外に理解できない
足し算ですら桁が大きくなると間違える
抜本的な大発明が将来起きない限り見込みがないだろう

**デフォルトの名無しさん** · 2023/05/07(日) 18:06:36.61

>>131 みれば、平均したらRustのほうがC++より速いだろ
それどころか、平均したらC++はPythonにも負けてそうだぞ

**デフォルトの名無しさん** · 2023/05/07(日) 18:07:20.74

Pythonクソ速いな
C++より速いな

**デフォルトの名無しさん** · 2023/05/07(日) 18:10:02.13

boxプロットも読めない奴がいるなw

**デフォルトの名無しさん** · 2023/05/07(日) 18:11:19.92

んなもん読まんでええのや

**デフォルトの名無しさん** · 2023/05/07(日) 18:31:40.13

>>215
AtCoderの問題を解くような処理がプログラミングにおいて最もAIを活用できる分野だよ
広く知られたアルゴリズムの最適化なんてお手のもの

**デフォルトの名無しさん** · 2023/05/07(日) 18:36:12.26

>>220
競プロに興味はない
そんな話はしていない

**デフォルトの名無しさん** · 2023/05/07(日) 18:42:35.09

C++がウェブ界に進軍したら、お前らみんな無職だぞ

C++のパワーをまざまざと見せつけられ、しょんベンチビルと思うわ

**デフォルトの名無しさん** · 2023/05/07(日) 18:43:59.40

それにしてもPython速いな

中にRust入ってるのと違うやろな

**デフォルトの名無しさん** · 2023/05/07(日) 20:06:09.85

>>215
AIが理解できなくてもパターンみたいに学習するからできちゃうんじゃん
突飛な想像力が必要なのは無理だろうけど

**デフォルトの名無しさん** · 2023/05/07(日) 20:18:49.70

工夫すれば１行分（＋電球とブロックの位置）の記憶だけで解けるのか
H,Wが1500以下でメモリ制限1024MBだとH＝~Wの確保も許容範囲だからそこで差がつきそう
解答者全体のレベルがよく分からないけどPythonにもガチ勢がいただけでしょ

**デフォルトの名無しさん** · 2023/05/07(日) 20:20:12.61

>>224
パターンはその通りで得意
しかしそこからの帰納法が無理
例えば素数を多数知っているがそこから素数の性質特徴を理解するのは無理
ただし学習として素数の性質特徴はわかるしプログラムも多数転がってるのでわかるだろう
でもそれじゃダメだ
未知のもの(初めてのもの)に対して出来ないといけない

**デフォルトの名無しさん** · 2023/05/07(日) 20:42:06.12

>>226
そういうことができるプログラマ以外いらなくなりそうだよね

◆QZaw55cn4c · 2023/05/07(日) 21:21:38.60

>>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題

**デフォルトの名無しさん** · 2023/05/07(日) 21:25:03.91

>>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い

**デフォルトの名無しさん** · 2023/05/07(日) 21:34:18.83

>>229
難しくてわかんない
もう少し優しく

**デフォルトの名無しさん** · 2023/05/07(日) 22:10:30.80

バイアスがあった可能性を否定できない　っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ

**デフォルトの名無しさん** · 2023/05/08(月) 00:59:11.95

最大の問題は rustの利用者が何でこんなに少ないかだな
ただこれには複案があっておそらくは C ++から移ってきたやつらがrustをやってると思われる
すると rustの標榜するモットーにも合致すると思われる

**デフォルトの名無しさん** · 2023/05/08(月) 01:13:16.38

もう出ている通りにこの問題を最速で解く機械語は存在するので
あと疑うべきは入出力のオーバーヘッドだけになる

メインのアルゴリズムやらロジックやらが同じなら
遅くしている要因は入出力だ

**デフォルトの名無しさん** · 2023/05/08(月) 01:15:13.32

>>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。

**デフォルトの名無しさん** · 2023/05/08(月) 02:06:52.10

C++のほうが機能が多いので、使える人はC++を使うからだろ

**デフォルトの名無しさん** · 2023/05/08(月) 02:33:43.51

機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな

**デフォルトの名無しさん** · 2023/05/08(月) 02:37:25.24

C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では

**デフォルトの名無しさん** · 2023/05/08(月) 03:00:18.94

IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始

**デフォルトの名無しさん** · 2023/05/08(月) 03:33:40.76

そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ

**デフォルトの名無しさん** · 2023/05/08(月) 03:48:41.01

非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。

**デフォルトの名無しさん** · 2023/05/08(月) 04:02:39.80

C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな

**デフォルトの名無しさん** · 2023/05/08(月) 04:21:48.93

Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう

**デフォルトの名無しさん** · 2023/05/08(月) 04:29:17.13

この流れなら言える

cpp2を知らなかったなんて言えない

**デフォルトの名無しさん** · 2023/05/08(月) 08:23:06.69

実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。

そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。

**デフォルトの名無しさん** · 2023/05/08(月) 09:34:04.39

>>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな

**デフォルトの名無しさん** · 2023/05/08(月) 10:33:58.34

人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。

**デフォルトの名無しさん** · 2023/05/08(月) 10:45:11.11

AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ

**デフォルトの名無しさん** · 2023/05/08(月) 11:29:16.24

AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね

**デフォルトの名無しさん** · 2023/05/08(月) 11:46:17.60

.gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが

**デフォルトの名無しさん** · 2023/05/08(月) 12:11:03.58

AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな

**デフォルトの名無しさん** · 2023/05/08(月) 12:16:11.80

>>174
すばらC洞察

**デフォルトの名無しさん** · 2023/05/08(月) 12:31:11.67

>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:44.96

>>201
これは良いサンプル
https://www.youtube.com/watch?v=U-_43dmdV_I

**デフォルトの名無しさん** · 2023/05/08(月) 12:43:46.40

>>249
内部で呼ばれるcargo packageの仕様っぽいね
https://doc.rust-lang.org/cargo/commands/cargo-package.html
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな

**デフォルトの名無しさん** · 2023/05/08(月) 12:48:52.30

>>228
全ての素数の積でπを造る公式あるな

**デフォルトの名無しさん** · 2023/05/08(月) 12:50:45.02

>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き

**デフォルトの名無しさん** · 2023/05/08(月) 12:56:17.27

Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？

**デフォルトの名無しさん** · 2023/05/08(月) 12:57:11.50

thx!

**デフォルトの名無しさん** · 2023/05/08(月) 13:48:29.03

今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。

**デフォルトの名無しさん** · 2023/05/08(月) 14:22:47.81

>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね

**デフォルトの名無しさん** · 2023/05/08(月) 15:04:56.15

>>245
AIにRustのコード吐かせる理由なんて無いよね

**デフォルトの名無しさん** · 2023/05/08(月) 15:39:48.45

Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので

**デフォルトの名無しさん** · 2023/05/08(月) 15:42:47.04

速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。

**デフォルトの名無しさん** · 2023/05/08(月) 16:19:16.98

>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな

**デフォルトの名無しさん** · 2023/05/08(月) 16:35:56.27

>>263
llvmの方がgccより性能良くなった?

**デフォルトの名無しさん** · 2023/05/08(月) 16:41:27.47

>>265
12年前から既にclangの方が速いです:
https://stackoverflow.com/questions/3187414/clang-vs-gcc-which-produces-faster-binaries

**デフォルトの名無しさん** · 2023/05/08(月) 17:24:13.85

>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し

機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい

**デフォルトの名無しさん** · 2023/05/08(月) 18:43:10.50

>>266
その手の話は信用ならねえな

**デフォルトの名無しさん** · 2023/05/08(月) 20:09:42.31

>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？

**デフォルトの名無しさん** · 2023/05/08(月) 22:23:28.00

>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない

ちなウォーターフォールね

**デフォルトの名無しさん** · 2023/05/08(月) 22:48:34.95

そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない

**デフォルトの名無しさん** · 2023/05/09(火) 02:35:37.18

公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ

**デフォルトの名無しさん** · 2023/05/09(火) 02:55:17.89

yank

**デフォルトの名無しさん** · 2023/05/09(火) 03:40:24.06

>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。

**デフォルトの名無しさん** · 2023/05/09(火) 06:12:08.21

そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな

**デフォルトの名無しさん** · 2023/05/09(火) 07:51:20.97

yankしても消えないやん？

**デフォルトの名無しさん** · 2023/05/09(火) 08:28:08.83

いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ

**デフォルトの名無しさん** · 2023/05/09(火) 09:22:12.89

プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ

**デフォルトの名無しさん** · 2023/05/09(火) 10:03:50.18

vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち

**デフォルトの名無しさん** · 2023/05/09(火) 10:17:59.79

とフィボナッチイテレータより高度なプログラムが書けない人が申しております

**デフォルトの名無しさん** · 2023/05/09(火) 10:29:01.80

>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ

**デフォルトの名無しさん** · 2023/05/09(火) 11:12:55.99

>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt

>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt

>まあClone回避パターンもありRustは完璧だ
doubt

よくこんな短文で嘘ばかりかけるな

**デフォルトの名無しさん** · 2023/05/09(火) 11:27:29.07

複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい

**デフォルトの名無しさん** · 2023/05/09(火) 11:41:48.76

オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん

**デフォルトの名無しさん** · 2023/05/09(火) 12:08:20.62

オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ

**デフォルトの名無しさん** · 2023/05/09(火) 12:19:41.76

な、単発だろ

**デフォルトの名無しさん** · 2023/05/09(火) 12:27:45.30

プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい

**デフォルトの名無しさん** · 2023/05/09(火) 13:50:33.38

>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。

**デフォルトの名無しさん** · 2023/05/09(火) 14:18:30.40

>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利

**デフォルトの名無しさん** · 2023/05/09(火) 14:27:49.18

>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。

**デフォルトの名無しさん** · 2023/05/09(火) 14:49:54.81

>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る

**デフォルトの名無しさん** · 2023/05/09(火) 15:08:56.17

https://stackoverflow.com/questions/57259126/why-does-the-rust-compiler-not-optimize-code-assuming-that-two-mutable-reference

だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます

**デフォルトの名無しさん** · 2023/05/09(火) 15:10:24.05

>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。

**デフォルトの名無しさん** · 2023/05/09(火) 15:21:42.16

>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね

**デフォルトの名無しさん** · 2023/05/09(火) 16:23:47.59

重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです

**デフォルトの名無しさん** · 2023/05/09(火) 16:57:31.86

>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる

Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い

**デフォルトの名無しさん** · 2023/05/09(火) 17:04:50.38

コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな

**デフォルトの名無しさん** · 2023/05/09(火) 17:08:17.41

>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする

**デフォルトの名無しさん** · 2023/05/09(火) 17:09:31.38

そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です

**デフォルトの名無しさん** · 2023/05/09(火) 17:30:52.58

Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど

**デフォルトの名無しさん** · 2023/05/09(火) 17:33:18.67

おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな

**デフォルトの名無しさん** · 2023/05/09(火) 17:35:11.58

普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ

**デフォルトの名無しさん** · 2023/05/09(火) 17:49:39.63

速度じゃないわな
実行時間だ
速度だと
c > c++ > rust

**デフォルトの名無しさん** · 2023/05/09(火) 21:13:21.70

>>300
Rustは適当に書いたらコンパイル通らない。