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

**デフォルトの名無しさん** · 2023/08/31(木) 12:16:53.23

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

っていう雑談スレ。

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

関連スレ(マ板): Google&Microsoft「セキュリティバグの70%はC/C++のメモリ管理ミス。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/09/14(木) 11:25:47.47

>>317
倍精度。

**デフォルトの名無しさん** · 2023/09/14(木) 12:22:56.03

>>318
やはり
単精度マルチスレッドでやると分かるけど
mojoであってもちょっと書いたくらいでは
凄く遅いという事ね

こちらはnumpy openblasで1020GFLOPS位
mojoは150GFLOPS位だった

**デフォルトの名無しさん** · 2023/09/14(木) 12:55:47.67

単精度シングルスレッドは
numpyで140GFLOPS位、mojoは40GFLOPS位だったかな
(どっちも1000x1000 float32)

もともと遅いしマルチスレッドの伸びも良くない印象だった

>>315のシングルスレッドは単精度に引き直すと
結構頑張っていると思う

**デフォルトの名無しさん** · 2023/09/14(木) 13:59:54.79

このスレ的にはZigはどうなんだに？

**デフォルトの名無しさん** · 2023/09/14(木) 15:09:10.16

Zigもありなんだけどバージョン1.0予定の2025年も遅れるだろうし
便利なC言語という需要がどこまであるのかわからん
正反対な方向のZigとRustだが企業がZigを選ぶのはレアケースだろう

**デフォルトの名無しさん** · 2023/09/14(木) 18:02:30.25

>>320
AVX512というチートに手を染めててこのGFLOPSは個人的には不満。ただ、自分のノートパソコンのzmmレジスタが16本しかなくて制約がキツすぎて困ってる。512bit長のsimdであればレジスタは最低でも32本は欲しい。16本だとパイプラインハザードの回避がかなりキツイ上ロード命令と置換命令に対して十分に演算命令を積めないのでかなり苦労している。というかAVX512をレジスタ16本はキツイのでAVX256の方で普通にOpenBLASを目指そうかどうかを検討している。

**デフォルトの名無しさん** · 2023/09/14(木) 18:47:08.14

>>323
zmm レジスタは 32本有るはずだが。

**デフォルトの名無しさん** · 2023/09/14(木) 22:26:51.45

激震のためRust製のゲームエンジンAmethystが注目されてるらしい
https://amethyst.rs/

激震

基本無料のソシャゲ終了のお知らせ。Unity「インストールするならお金払ってね。リセマラも都度料金徴収するから」
https://greta.5ch.net/test/read.cgi/poverty/1694588878/

全ゲーム業界に暗雲　「UNITY税」が始まる事を受け販売中のゲームを削除するとアナウンスするメーカーが出始める
https://greta.5ch.net/test/read.cgi/poverty/1694620134/

**デフォルトの名無しさん** · 2023/09/14(木) 23:17:48.22

ふと試したBLISが良い感じ

単精度
OpenBLAS: 1.940ms 1030.853 GFLOP/s
BLIS: 1.983ms 1008.616 GFLOP/s
MKL: 2.654ms 753.593 GFLOP/s

倍精度
OpenBLAS: 4.139ms 483.190 GFLOP/s
BLIS: 3.584ms 557.981 GFLOP/s
MKL: 4.818ms 415.121 GFLOP/s

MKL倍精度は100回毎のサブ平均が350~550で安定していなかった
MKL単精度は安定して遅かった
OpenBLASとBLISが安定して速かった
(1000x1000 10000回平均マルチスレッド AVX2)

>>323
AVX512はチートと言う程じゃないけど普及度はかなり下がるね

**デフォルトの名無しさん** · 2023/09/15(金) 01:00:20.84

>>325
Amethystはだいぶ前に開発止まったはず

アンチOSSの人はこういう激震が好きなんだろうか

**デフォルトの名無しさん** · 2023/09/15(金) 03:25:46.95

いい機会なので復活したりするのかもね
https://github.com/amethyst/amethyst

まあ、びっくりしたUnity側が条件変えてくるでしょ
金を生まないインスタンスが想像以上に多いらしい

**デフォルトの名無しさん** · 2023/09/15(金) 09:51:13.34

希望的観測を語るのは勝手にすればいいが
実際に注目を集めているのはGodotとUnrealなのであった

**デフォルトの名無しさん** · 2023/09/15(金) 13:52:46.64

>>324
何か調べると自分のPCは16本っぽい。何か最初期のPCはZMMレジスタが32本あったんだけど、途中から発熱のせいで16本になって今ではサーバー用のやつ以外は基本16本って何かに書いてあった気がする。これは勘違い？

**デフォルトの名無しさん** · 2023/09/15(金) 18:05:36.94

>>330
一応、EVEX prefix では 32 種類の zmm レジスタ
を区別できるようにはなっているが。

**デフォルトの名無しさん** · 2023/09/15(金) 18:39:42.09

この記事ではシリコンダイ上の実体(レジスタファイル)は(1コアあたり)152(144+8)個みたいだよ
https://chipsandcheese.com/2022/06/07/sunny-cove-intels-lost-generation/

AVX512FのISA上で名前で呼び分けるのが32個(zmm0~zmm31)で実行のスケジュール段階で
144個のレジスタファイルに上手く割り振りながらアウトオブオーダー実行しているイメージです

>>323,330
>何か調べると
これの方が興味あるので差し支えなければリンクを...

**デフォルトの名無しさん** · 2023/09/16(土) 10:27:42.31

zmmレジスタが16本しかないやつは極一部のやつらしい。確認したら自分のPCは32本あった。
ところで、zmm0レジスタにdouble型がロードされてるときこれの2番目の要素をzmm1レジスタにブロードキャストすんのって最低でどれくらいのレイテンシーがいるか教えて欲しい。IntelのSimd命令マニュアルとにらめっこしながらやってるけど、命令の内容があまり書いてないので結構困ってる。レイテンシーとかは書いてあるけど。

**デフォルトの名無しさん** · 2023/09/16(土) 21:12:54.47

>>326の計測に使ったblasバインディングがgemmとgemvしか参照していなかったので
行列積素朴実装をgemmの形にしてdllにしたらそのまま計測出来た(gemvは呼び出されていなかった)

f32 NAIVE
ST
3484.623ms 0.616 GFLOP/s
3540.897ms 0.606 GFLOP/s
3567.409ms 0.602 GFLOP/s
MT
178.104ms 12.057 GFLOP/s
178.895ms 12.004 GFLOP/s
177.376ms 12.107 GFLOP/s

f32 tile
ST
31.727ms 67.686 GFLOP/s
32.086ms 66.930 GFLOP/s
32.020ms 67.067 GFLOP/s
MT
4.042ms 531.307 GFLOP/s
3.924ms 547.233 GFLOP/s
4.065ms 528.281 GFLOP/s

f32 BLIS 目標アーキテクチャ毎にほぼアセンブリで実装されている
ST
14.917ms 143.966 GFLOP/s
14.987ms 143.289 GFLOP/s
15.051ms 142.680 GFLOP/s
MT
2.120ms 1012.808 GFLOP/s
2.145ms 1001.183 GFLOP/s
2.108ms 1018.784 GFLOP/s

**デフォルトの名無しさん** · 2023/09/16(土) 21:14:12.34

f64 NAIVE
ST
4072.215ms 0.527 GFLOP/s
3965.081ms 0.542 GFLOP/s
4069.991ms 0.528 GFLOP/s
MT
284.921ms 7.537 GFLOP/s
297.872ms 7.209 GFLOP/s
271.956ms 7.896 GFLOP/s

f64 tile
ST
72.745ms 29.521 GFLOP/s
72.666ms 29.553 GFLOP/s
72.857ms 29.475 GFLOP/s
MT
9.442ms 227.445 GFLOP/s
9.547ms 224.928 GFLOP/s
9.739ms 220.504 GFLOP/s

f64 BLIS
ST
30.461ms 70.500 GFLOP/s
30.418ms 70.600 GFLOP/s
30.343ms 70.773 GFLOP/s
MT
3.896ms 551.148 GFLOP/s
3.812ms 563.403 GFLOP/s
3.924ms 547.277 GFLOP/s

1024x1024 10回平均
c=a*bのa,bは使いまわし変数cはループ外で初期化してあるけど都度既存メモリ破棄、新規アロケート、ゼロ初期化されていた

**デフォルトの名無しさん** · 2023/09/16(土) 21:16:22.52

gemm自体はアロケート済みのcを受け取るだけなので
簡潔に書いてもcメモリの使いまわしが出来る仕組みが欲しい

端数処理をしてない手抜きTileなので1024x1024でやった

>>333
楽しめるかどうかですね
こちらはどうなることやら

**デフォルトの名無しさん** · 2023/09/16(土) 21:22:50.93

64x64 Tile導入時点でコンパイラがAVX2を多用したコードを自動出力した

なんかマルチスレッドの力で押し切るのが手軽
f32はGPUで
f64は個人向けGPUは遅いからCPU多コアかな

**デフォルトの名無しさん** · 2023/09/16(土) 23:25:02.06

野望の段階だけど、Strassenのアルゴリズムとかの行列積高速化のアルゴリズムを効率良く組みたい。再帰的なアルゴリズムは現状のCPUの構造だとかなり難しいんだよね。
今はCだけど、できれば最終的にRustで組みたい。RustのメモリリークやSegmantation fault, メモリの2重解放がないのはスゴい利点だとと思う。今後OSなどの最深部でも行列積の計算が頻繁に呼び出されるようになるだろうからなおのことRustで目標を達成したい。

**デフォルトの名無しさん** · 2023/09/17(日) 06:43:29.46

カーネルで行列積って使うの？

**デフォルトの名無しさん** · 2023/09/17(日) 09:01:47.58

行列とカーネルを同じ文に書かれると違うほうのカーネルにしか読めん

**デフォルトの名無しさん** · 2023/09/17(日) 10:37:23.77

結論とて現在のRustは糞
来世に期待ってことだよな

**デフォルトの名無しさん** · 2023/09/17(日) 13:55:14.01

どんな紙切れでも金塊以上の価値になれる
その結果Youは乱れ万人に対する加害者になっちゃうわな

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

>>341
脈絡なく「結論」とか言っちゃう症状って生まれ変わるまで治らないの？
若いうちならトレーニングで治せそうだけど年取ると無理なのかな

**デフォルトの名無しさん** · 2023/09/17(日) 14:44:07.73

>>341
うむ。
zmmレジスタやSIMDの話題もRustに不利な事を
書き込まれたから誤魔化そうとしているのだろうね。

**デフォルトの名無しさん** · 2023/09/18(月) 03:18:13.11

>>339
AIがOSに組み込まれるようになるので死ぬほど行列積の関数は呼び出されるようになると思う。

**デフォルトの名無しさん** · 2023/09/18(月) 03:47:49.70

>>345
別にユーザーランドで良いのでは?

**デフォルトの名無しさん** · 2023/09/18(月) 06:24:20.96

スタートレックの世界のコンピュータを目指すならOSに組み込まれるかもね
でもそれはまだ先の話だろう

**デフォルトの名無しさん** · 2023/09/18(月) 10:08:36.50

SIMDなんて非常に簡単で素朴なコードがかけるのに
有利不利なんてないだろ

**デフォルトの名無しさん** · 2023/09/18(月) 10:18:31.61

そのわりにベンチで差が出る(らしい

スレ的には、いかに上手に・素直にスタブを記述できるかだね

**デフォルトの名無しさん** · 2023/09/18(月) 12:57:03.60

>>347
OSにAIが標準装備されるとしても
何でそれをカーネル空間で動かさなきゃならんという話になるのかが分からん

**デフォルトの名無しさん** · 2023/09/18(月) 15:52:05.81

>>347
win11にWindows Copilotを搭載することが決定してるので　そう先の話でわネエと思いますケドぬ　まぁ　ドコまでローカルホストでガリガリやらすかまでわ　分からんケドぬ

**デフォルトの名無しさん** · 2023/09/18(月) 22:42:01.51

>>348
それはアセンブラを直接たたくってこたかな？それって生のポインタをさわることになるからRustの目指す安全性とは結構離れてるよな。第一、データがレジスタのサイズにあわせてアライメントされてないとバグるけど、Rustではアライメントを揃えるのすらunsafe扱いだから。simdを組み込みにするのは果てしなく大変なのでは？全てunsafeにして生のポインタを引数にとるなら話は別だけど。それではもはやRustを使う意味がないし。

**デフォルトの名無しさん** · 2023/09/18(月) 23:18:32.41

>>352
理解できてなさすぎ
Rustは標準ライブラリがunsafeまみれなように
いくらでもunsafeを使ってもいいんだよ
そのうえでsafeな部分を作り出せればそこはRustコンパイラによる保証がつく
だからRustだけがアドバンテージを持つ

**デフォルトの名無しさん** · 2023/09/18(月) 23:25:10.97

>>353
理解してると思うよ
煽られてるんだよw

**デフォルトの名無しさん** · 2023/09/19(火) 00:32:50.44

行列ライブラリはぶっちゃけRUSTの運営が直接本来実装するべきなんだよね。ものすごい数の安全テストが必要だから。Rustの標準ライブラリのRCはそうやって安全性を担保してるからな。ただRustの質を担保するならRCよりも遥かに安全テストが必要になるとは思う。

**デフォルトの名無しさん** · 2023/09/19(火) 00:45:08.44

blasやlapackのラッパー書けば良いのでは?

**デフォルトの名無しさん** · 2023/09/19(火) 01:10:39.03

>>356
メモリリークどうすんの？

**デフォルトの名無しさん** · 2023/09/19(火) 01:28:44.07

もうRustの失敗を踏まえた新しい言語の登場を待とうぜ

**デフォルトの名無しさん** · 2023/09/19(火) 01:34:55.82

>>357
blasやlapackの中は干からびるくらいに枯れてるやろ

**デフォルトの名無しさん** · 2023/09/19(火) 01:37:08.15

Rustの目指す安全性ってのと真逆の意味をもつunsafe宣言は
「ここは確率的にunsafeだけど確率を覆すのが人間の仕事」と言ってる
だから確率とか好きそうな人には難しい

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

>>360
unsafeのところは人間が死ぬ気でテストして安全性を担保してねって意味合いが強いけどな。だからRCとかARCはとてつもなく厳重なテストを行ったらしい。

**デフォルトの名無しさん** · 2023/09/19(火) 10:08:39.97

>>359
誰もOSの最深部で使いまわしたけーすなんてないからどんなエラーがでるかは未知の領域だろ。

**デフォルトの名無しさん** · 2023/09/19(火) 10:58:17.73

誰がOSの最深部で使いまわすの?

**デフォルトの名無しさん** · 2023/09/19(火) 13:57:30.99

>>361
テストの戦力を集中できるから合理的なわけだが
当たりくじだけを買う集中ではなく逆にはずれそうな箇所に手間をかける

**デフォルトの名無しさん** · 2023/09/19(火) 15:02:10.87

>>361
RCもARCも複雑じゃないだろーにw

**デフォルトの名無しさん** · 2023/09/19(火) 15:25:44.62

Rustではそういう小さなパーツのみ人間が安全性を保証するunsafeを用い
プログラム全体はコンパイラが静的に安全性を保証する形となって開発効率が良い

**デフォルトの名無しさん** · 2023/09/19(火) 18:13:09.65

人間が安全性を保証するunsafe

**デフォルトの名無しさん** · 2023/09/19(火) 18:33:40.87

人間と契約しないと自然状態になるでしょ

**デフォルトの名無しさん** · 2023/09/19(火) 18:36:21.76

C/C++はプログラム全体がunsafeだから
プログラム全体に対して人間が安全性を保証しなければならず開発効率がよくない

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

じゃあC/C++にunsafe解決？

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

訂正
unsafe導入で解決？

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

コードチェッカとしてAIが搭載されるので
現実的な必要性がなくなると思うよ

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

だよなあ

**デフォルトの名無しさん** · 2023/09/19(火) 20:47:18.93

>>372
今のレベルで信用できる？

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

>>374
ご指摘の通り今のレベルではコードチェッカとしては信用できない

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

この1年の進捗を見ると最早時間の問題

**デフォルトの名無しさん** · 2023/09/20(水) 00:20:23.25

AIチェッカはヒントにはなっても証明にはならんやろ

**デフォルトの名無しさん** · 2023/09/20(水) 03:36:44.11

unsafe{ } を型の内で定義できるのがC++っぽいかなって最近思ってる

**デフォルトの名無しさん** · 2023/09/20(水) 06:28:48.05

>>365
Rustの仕組みで生ポやアドレスに触るような関数やライブラリの安全性の担保は死ぬ程だるいということですよ。実際sind系のクレートが全然安定版にならないのはそれが原因だからね。RCやARCとは桁が違うレベルの安全テストを行わないといけないようだからね。

**デフォルトの名無しさん** · 2023/09/20(水) 06:39:41.43

>>363
使い回されるだろう。stable diffusionとかlammaとかがヌルヌル動くようなPCスペックが標準になってきたらEXCELやパワポとか、DirectXに組み込まれるだろうな。

**デフォルトの名無しさん** · 2023/09/20(水) 08:44:11.37

>>380
カーネルモードという言葉を知ってる？
他の人はそういう話してるけど

**デフォルトの名無しさん** · 2023/09/20(水) 10:05:41.68

コードは公開するが教師データは墓まで持っていく手口はOSSに対抗する側の発想なので
GNU/Linuxと合体する確率は低い

**デフォルトの名無しさん** · 2023/09/20(水) 10:54:44.14

>>380
OSの最深部って話をしてるのになんでアプリケーションの話をしてるの？
低レイヤとか高レイヤとかわからない人?

**デフォルトの名無しさん** · 2023/09/20(水) 11:18:09.13

三位一体みたいな
多神教を回避するしぐさ

**デフォルトの名無しさん** · 2023/09/20(水) 12:12:30.85

>>376
具体的にいつですか？
具体的とかそんなの無い感じですか？

**デフォルトの名無しさん** · 2023/09/20(水) 12:17:54.86

>>382
OSS最大手のRedhatはそんな感じ

**デフォルトの名無しさん** · 2023/09/20(水) 12:20:50.67

Rust製のFirefoxがCPU100％張り付きとかメモリ60GBとか普通にやってくれるやつなので
Rustも宣伝通りの安全性だとは思っていない

**デフォルトの名無しさん** · 2023/09/20(水) 12:40:47.18

>>387
FirefoxにはC++のコードの方が多いし
ピュアRustでもcpu100%やメモリ浪費アプリの
解消なんて謳ってないので意味不明

**デフォルトの名無しさん** · 2023/09/20(水) 14:07:36.47

>>387
Rustでも安全にセキュリティーホールやウィルスを書けるよ

**デフォルトの名無しさん** · 2023/09/20(水) 14:27:23.23

宣伝通りではない問題は普遍的な問題
沈黙は金
雄弁は宣伝通りではない

**デフォルトの名無しさん** · 2023/09/20(水) 15:11:01.56

RustもFirefoxもMozillaの製品だし
どっちも眉唾程度に使ってる

**デフォルトの名無しさん** · 2023/09/20(水) 15:12:44.77

Mozillaのサイトには豊かな生活とか健全なインターネッツとか
アベノミクスの宣伝とだいたい同じことが書いてある

**デフォルトの名無しさん** · 2023/09/20(水) 15:28:18.60

Rustなら安全なマルウェアを書けます

**デフォルトの名無しさん** · 2023/09/20(水) 15:28:22.64

Rustなら安全なマルウェアを書けます

**デフォルトの名無しさん** · 2023/09/20(水) 17:29:29.37

〇🧥

**デフォルトの名無しさん** · 2023/09/20(水) 18:11:16.04

>>392
内容を反省しても無駄
完璧な内容に改善しても雄弁は最善手になれない

**デフォルトの名無しさん** · 2023/09/20(水) 18:17:10.71

>>391
それは昔の話
3年前にMicrosoft・Google・Amazonなど共同によるRust Foundationが設立されてRustはその資金で開発されている

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

>>397
と書くとその資金でサラリーを得る開発者を雇用しているようにも聞こえるが
Rust自体の開発をしている人って専業はほとんどいないのでは?

**デフォルトの名無しさん** · 2023/09/20(水) 20:11:54.99

念の為だがOSSを批判してるんじゃないよ
>>397の認識が違うんじゃないかなってことを言いたくて
資金入れようが入れまいが開発には大して影響ない体制ではないのかな?

**デフォルトの名無しさん** · 2023/09/20(水) 20:46:43.30

各々の企業の内部にRustの開発をする人材がいる

**デフォルトの名無しさん** · 2023/09/20(水) 20:48:43.02

>>398
専業と兼業がいる
Rust Foundationの昨年の年間レポートによるとfull-timeは7名

**デフォルトの名無しさん** · 2023/09/20(水) 20:50:07.85

>>398
専業と兼業がいる
Rust Foundationの昨年の年間レポートによるとfull-timeは7名

**デフォルトの名無しさん** · 2023/09/20(水) 21:32:06.75

各々の企業の内部にRustの開発をする人材がいる

**デフォルトの名無しさん** · 2023/09/20(水) 21:33:02.53

Microsoft・Google・Amazonが資金を入れなかったら
その7名は雇用できないんだろうけど
7名なら兼業で賄えるだろうから大して影響ない体制とも言える

**デフォルトの名無しさん** · 2023/09/21(木) 19:05:02.88

transpose関数でデータを並べかえるのって割りと時間が掛かるんだよな。simd化しても並べ替えの部分でかなり時間が取られるからあまり高速にならないし。マルチスレッド化すれば確実に一定の高速化はできるが。

**デフォルトの名無しさん** · 2023/09/22(金) 21:52:03.87

Rustはもうオワコンだろ

**デフォルトの名無しさん** · 2023/09/22(金) 22:12:19.06

Haskellも終わったし
Rustも終わるだろ

**デフォルトの名無しさん** · 2023/09/22(金) 22:16:08.30

どっちも元々始まらなかっただろ。かつては一世を風靡したが今は終わコンになったPerlやPHPとは違い、
不発のまま忘れ去られる。

**デフォルトの名無しさん** · 2023/09/22(金) 22:29:43.48

>>408
>かつては一世を風靡したが今は終わコンになったPerlやPHPとは違い、
あれ?!終わったの?
今は何に取って代わられた?

**デフォルトの名無しさん** · 2023/09/22(金) 22:43:34.63

これ

Rustの非同期ライブラリをPHPから利用可能にする「php-tokio」が登場

**デフォルトの名無しさん** · 2023/09/22(金) 23:01:35.76

遺憾なことにphpはwordpressやらLaravelやらで今も使われてる
phpは脆弱性の宝庫

**デフォルトの名無しさん** · 2023/09/23(土) 00:26:11.41

https://fabcross.jp/news/2023/dmln530000187b7p-img/dmln530000187b8e.jpg

**デフォルトの名無しさん** · 2023/09/23(土) 02:07:34.62

Cで開発してるとわかるけど、Cの大規模なプロジェクトは確実にメモリリークだらけになってるな。関数が内部で勝手にメモリを、確保してreturnしてるやつとか他人の作った関数だったらメモリの解放忘れること多いんじゃね？この手の部分はRUSTは神って思うことすらある。
ただ、RustはCに比べて一部の最適化オプションの性能がかなり落ちるな。多分、配列とかの境界チェックをアセンブリレベルで行ってるんだろうな。

**デフォルトの名無しさん** · 2023/09/23(土) 02:17:44.92

配列はインデックスでアクセスすると他の多くの言語と同様にインデックス範囲内チェックをアクセス毎にする
しかしC言語でのポインタアクセスと同様にRustでもポインタ(参照)でシーケンシャルアクセスすればポインタ終了条件の比較のみとなりC言語と同じ速さになる

**デフォルトの名無しさん** · 2023/09/23(土) 02:30:07.34

>>411
PHP5系の配列の扱いはトラウマものだったわ。

**デフォルトの名無しさん** · 2023/09/23(土) 06:56:20.93

Rustを踏み台にして、もっとスタックフレーム指向の言語が出てきて欲しいわな。
スタックis god, 再帰構造is god.

**デフォルトの名無しさん** · 2023/09/23(土) 09:29:05.32

>>412
罰ゲームじゃん