次世代言語28 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/09/03(土) 09:12:44.80

>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ

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

>>128
配列の一部分はスライス　(配列全体も可)
Vecの一部分もスライス　(Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(＝元の範囲内)なので最適化が可能となる

**デフォルトの名無しさん** · 2022/09/03(土) 09:24:37.68

さすが複オジ隔離スレやで
今日もいい仕事しとるww

**デフォルトの名無しさん** · 2022/09/03(土) 09:27:25.47

Rustの実行速度がCと同等だと何か困ることでもあるの？

**デフォルトの名無しさん** · 2022/09/03(土) 09:30:24.03

>>129
関数内でlenが決まる場合でもいちいちスライス作るのか？

**デフォルトの名無しさん** · 2022/09/03(土) 09:32:15.16

C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14

**デフォルトの名無しさん** · 2022/09/03(土) 09:37:13.56

>>131
Rustアンチの人にとって「Rustは遅い！」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。

**デフォルトの名無しさん** · 2022/09/03(土) 09:45:26.31

困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ

**デフォルトの名無しさん** · 2022/09/03(土) 09:47:19.22

Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある

**デフォルトの名無しさん** · 2022/09/03(土) 09:52:51.38

>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ

あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く

>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい

**デフォルトの名無しさん** · 2022/09/03(土) 09:54:03.17

境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね

**デフォルトの名無しさん** · 2022/09/03(土) 09:54:19.38

>>135
コンパイルオプションでチェック無効に出来ないの？

**デフォルトの名無しさん** · 2022/09/03(土) 09:56:34.91

>>139
C#はできるね

**デフォルトの名無しさん** · 2022/09/03(土) 09:59:58.21

>>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは（C言語脳としては）無駄に思える

**デフォルトの名無しさん** · 2022/09/03(土) 10:03:47.05

>>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう

**デフォルトの名無しさん** · 2022/09/03(土) 10:06:50.84

>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い

あのー、わざとやってるのかバカなのかどっちなの？

**デフォルトの名無しさん** · 2022/09/03(土) 10:11:51.77

>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう

**デフォルトの名無しさん** · 2022/09/03(土) 10:14:07.95

実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど

**デフォルトの名無しさん** · 2022/09/03(土) 10:17:36.98

チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな？

**デフォルトの名無しさん** · 2022/09/03(土) 10:20:44.15

>>144
ホントに常に消えるの？
ダメなケースは存在しないの？

**デフォルトの名無しさん** · 2022/09/03(土) 10:20:52.59

>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ

**デフォルトの名無しさん** · 2022/09/03(土) 10:22:44.18

>>148
同じじゃなく遅くなると認めろよ

**デフォルトの名無しさん** · 2022/09/03(土) 10:28:32.67

>>149
遅くなる具体例ありそう？それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw

**デフォルトの名無しさん** · 2022/09/03(土) 10:32:05.60

いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち

**デフォルトの名無しさん** · 2022/09/03(土) 10:49:11.71

>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw

**デフォルトの名無しさん** · 2022/09/03(土) 10:52:15.27

境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね

**デフォルトの名無しさん** · 2022/09/03(土) 11:03:40.39

結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2022/09/03(土) 11:21:29.31

マジキチだった

**デフォルトの名無しさん** · 2022/09/03(土) 11:53:26.95

>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？

**デフォルトの名無しさん** · 2022/09/03(土) 11:55:04.03

この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？

**デフォルトの名無しさん** · 2022/09/03(土) 12:31:15.03

Rustは安心安全でC言語と同等の速度ってことでFAだな

**デフォルトの名無しさん** · 2022/09/03(土) 12:34:45.63

体言止めおじさん

**デフォルトの名無しさん** · 2022/09/03(土) 12:53:59.17

最近のレベル低下には目を見張るものがあるな

**デフォルトの名無しさん** · 2022/09/03(土) 12:58:26.77

>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい

**デフォルトの名無しさん** · 2022/09/03(土) 13:35:09.09

いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw

**デフォルトの名無しさん** · 2022/09/03(土) 13:37:41.33

Cこそ最強！
1個でもCより遅いケースあったらダメね！

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:08.80

次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:32.50

1個でもCより遅い場合あったら、他にメリットあっても意味ないから！

**デフォルトの名無しさん** · 2022/09/03(土) 13:50:50.43

誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？

**デフォルトの名無しさん** · 2022/09/03(土) 14:31:36.61

このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

**デフォルトの名無しさん** · 2022/09/03(土) 14:36:16.07

ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない

**デフォルトの名無しさん** · 2022/09/03(土) 14:49:28.41

>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう

**デフォルトの名無しさん** · 2022/09/03(土) 17:15:49.49

>>167
最終レスが8月18日とか終わってんじゃねえか

**デフォルトの名無しさん** · 2022/09/03(土) 17:17:49.88

TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが

**デフォルトの名無しさん** · 2022/09/03(土) 17:37:42.10

>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

**デフォルトの名無しさん** · 2022/09/03(土) 18:07:45.82

Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる

**デフォルトの名無しさん** · 2022/09/03(土) 18:32:15.93

>>137
>>109は RustがC言語より圧倒的に遅いコードです

>>166 172
＞Rustが速いのは非常にキツイxor条件を満たす範囲だけ
＞「Rustは安全で高速」とか言うのは詐欺
＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない

＞173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？

**デフォルトの名無しさん** · 2022/09/03(土) 18:40:11.28

え？↓これってデマなんだよね？

https://qiita.com/shadowTanaka/items/5fb99819629dcaab3e05

**デフォルトの名無しさん** · 2022/09/03(土) 19:00:48.70

>>174
わざわざ　w = v; 　してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな

**デフォルトの名無しさん** · 2022/09/03(土) 19:10:31.55

>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?

**デフォルトの名無しさん** · 2022/09/03(土) 19:29:43.18

>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ

**デフォルトの名無しさん** · 2022/09/03(土) 19:37:31.78

>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ

**デフォルトの名無しさん** · 2022/09/03(土) 20:06:47.23

>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが

**デフォルトの名無しさん** · 2022/09/03(土) 20:09:49.33

>>109のコードを見てみたが書き方が酷いな
とりあえずそれと全く同じ関数仕様に合わせるとして
Rustならもっと簡潔にこのように書く

fn max_value_slice_vw(v: &[u32], w: &[u32]) -> u32 {
　std::iter::zip(v, w)
　　.map(|(m, n)| m + n)
　　.max()
　　.unwrap_or_default()
}

C言語バージョンより遥かに分かりやすいし
通常Rustでは返り値をu32でなくOption<u32>とするから最後のunwrap_or_default()も不要となる

これでC言語バージョンと全く同じ結果を得られるし
境界チェックも行われないし
そのC言語バージョンと全く同等のアセンブリコードが生成されることも確認できる
つまり今回の>>109の件もRustとCは同じ速さで動作する

**デフォルトの名無しさん** · 2022/09/03(土) 20:17:46.35

>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ

**デフォルトの名無しさん** · 2022/09/03(土) 20:34:30.71

「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている

**デフォルトの名無しさん** · 2022/09/03(土) 20:45:21.45

>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し

**デフォルトの名無しさん** · 2022/09/03(土) 20:48:32.94

>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね

**デフォルトの名無しさん** · 2022/09/03(土) 20:51:48.37

>>185もはや自虐ネタ。嫌味ですか？

**デフォルトの名無しさん** · 2022/09/03(土) 20:52:15.80

Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件

**デフォルトの名無しさん** · 2022/09/03(土) 21:07:27.69

こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ

**デフォルトの名無しさん** · 2022/09/03(土) 21:10:15.24

for文を使わずにメソッドチェーンで書いたことが気に入らないのならば
>>181はfor文を使って以下のように書ける

fn max_value_slice_vw2(v: &[u32], w: &[u32]) -> u32 {
　let mut max = 0;
　for (m, n) in std::iter::zip(v, w) {
　　if max < n + m {
　　　max = n + m;
　　}
　}
　max
}

これもC言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる

**デフォルトの名無しさん** · 2022/09/03(土) 21:13:41.03

せめてID変えずにやってくれればいいのにな
何回NGさせるんだか

**デフォルトの名無しさん** · 2022/09/03(土) 21:15:53.68

>>189
確認乙
POC(>>177,182)積み増し乙

**デフォルトの名無しさん** · 2022/09/03(土) 21:25:28.83

Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから

**デフォルトの名無しさん** · 2022/09/03(土) 21:30:23.63

本人はバレてないと思ってるらしいw

**デフォルトの名無しさん** · 2022/09/03(土) 21:34:03.97

>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝

**デフォルトの名無しさん** · 2022/09/03(土) 21:55:58.00

Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
　　println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
　　println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。

**デフォルトの名無しさん** · 2022/09/03(土) 22:05:33.75

Rustがそんなに速いならなんで競プロはC++一択なの

**デフォルトの名無しさん** · 2022/09/03(土) 22:19:33.41

>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り

**デフォルトの名無しさん** · 2022/09/03(土) 22:30:44.07

まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然

**デフォルトの名無しさん** · 2022/09/03(土) 22:31:15.35

>>196
解説本がc++が多いからかな

**デフォルトの名無しさん** · 2022/09/03(土) 22:34:08.49

例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg

**デフォルトの名無しさん** · 2022/09/03(土) 22:38:11.41

Rustはコーディングに時間がかかるから競プロでは使えない。
競プロにC++とPythonは良い選択。

**デフォルトの名無しさん** · 2022/09/03(土) 22:41:39.07

>>200
競プロでもRustが速いね

**デフォルトの名無しさん** · 2022/09/03(土) 23:18:47.73

>>196
そもそもC++もちゃんと書けるとは言えないでしょ
mainとグローバル変数しか使わないし

**デフォルトの名無しさん** · 2022/09/03(土) 23:28:32.01

他言語を貶しても、Rustが使える言語にはならない。

**デフォルトの名無しさん** · 2022/09/03(土) 23:28:44.38

>>200
Pythonを選んだ時点でPyPy3にしたとしても負け戦が確定かよ
Rustは競プロでも強いのか

**デフォルトの名無しさん** · 2022/09/03(土) 23:33:58.57

>>200 懐かしいなあ
ttps://ビット.ly/3CS8AuV
トップのuzzyさん始めC++勢がじわじわ最適化を進めているのがカッコイイ
ちらほらいるRust勢は一発屋だけでインクリメンタルな最適化が出来ていないね。
Rustは一貫性がない(>>177,>>182)から下手に弄れなかったのかな？

**デフォルトの名無しさん** · 2022/09/03(土) 23:43:22.86

>>204
その定型文のどこが「使える」と思ったのかがさっぱり分からないよ

**デフォルトの名無しさん** · 2022/09/03(土) 23:47:27.33

>>207 Rustって一発作ったらそれ以上で弄れないって開発現場では使えない言語だね(>>206)

**デフォルトの名無しさん** · 2022/09/04(日) 00:08:42.58

>>206
インクリメンタルに最適化したと本気で思い込んでる？
uzzyの上位4つとも全てソース同じまま変化していない
つまり何度も同じのを提出してトライしただけ

**デフォルトの名無しさん** · 2022/09/04(日) 00:27:20.06

で、その競プロでのc言語での参加率はどれくらい？> cオジ

**デフォルトの名無しさん** · 2022/09/04(日) 00:31:23.21

4回ともC++コード同じだな
ただしその一つ前だけコードが違っていて二次元配列を一次元へと書き換えて改善してる
一方でRustの人は最初から一次元にしてるからその改善が必要なかった
つまり>>208はRustを叩きたいだけの完全に的外れ

**デフォルトの名無しさん** · 2022/09/04(日) 02:03:59.28

たぶん必要なのは
葡萄を食べるべきでない理由ではなく
食べない自由なんだな

**デフォルトの名無しさん** · 2022/09/04(日) 08:04:17.58

>>200
プログラミング言語間の速度差が激しくて勝負にならないな
競プロで勝つためにはRustかC++を選ばざるを得ないのか

**デフォルトの名無しさん** · 2022/09/04(日) 08:07:09.64

>>213
いいや
Pythonは論外だけど他の言語で十分戦える

**デフォルトの名無しさん** · 2022/09/04(日) 08:19:18.55

>>200
Rust最速レベルやん
てかC++の分布笑えるな
ギリ合格からトップクラスまでみっちり

**デフォルトの名無しさん** · 2022/09/04(日) 10:34:00.57

本日のRustあげ会場はこちらですか？

**デフォルトの名無しさん** · 2022/09/04(日) 11:16:04.09

貶めれば誹謗中傷かも知れんけど、ほめれば気持ち悪いだけ
こんなの消去法でほめるに決まってんだろ

**デフォルトの名無しさん** · 2022/09/04(日) 11:23:49.03

参加者自体はRustも多い。
C++と同じくらい居る。
時間内に提出できる人が少ないだけ。

**デフォルトの名無しさん** · 2022/09/04(日) 11:27:19.04

つまりRustは生産性が低いor利用者の能力が低いってこと？

**デフォルトの名無しさん** · 2022/09/04(日) 11:52:32.99

普通にガチ勢は昔からC++を使ってて今さら他の言語にしないというだけだろうな

**デフォルトの名無しさん** · 2022/09/04(日) 12:28:01.29

CオジはCとC++比べてもやっぱCの方が早いからC++はダメとか言うのかな？

**デフォルトの名無しさん** · 2022/09/04(日) 12:29:11.61

ダメな香具師が描いたダメなC++コードは本当に糞
Cのがマシ

**デフォルトの名無しさん** · 2022/09/04(日) 12:57:20.84

>>201
Pythonはよほどうまくチューニングしないとすぐ時間制限越えるんで競プロだと使い物にならないんですわ
>>200のグラフから実行時間でのランキングができそうだけどぶっちゃけ時間内に結果が出れば速かろうが遅かろうが大差無いのでPython以外なら何使ってもいい
言語よりプログラマーの能力が大事だし、それよりむしろ暇の方が大事
とにかく参加し続けてなるべく正解を出してれば上位に行ける

**デフォルトの名無しさん** · 2022/09/04(日) 13:11:43.10

pythonでアルゴリズム性能出ると思ってるのお前だけだよ。。

**デフォルトの名無しさん** · 2022/09/04(日) 13:31:05.58

お前がアルゴリズムという言葉を知らないと言うことがわかった

**デフォルトの名無しさん** · 2022/09/04(日) 14:04:04.57

行列の和と積を英単語ではなく記号で書けるだけでC++と互角みたいになったのがPython

argv + 1000000 がnullを返したり計算中に例外を投げる実装が可能なだけでRustと互角になれる

**デフォルトの名無しさん** · 2022/09/04(日) 14:42:33.66

何と戦ってるのか知らんがイミフな基準