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

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

スレタイ以外の言語もok

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

**デフォルトの名無しさん** · 2022/09/27(火) 11:26:01.22

>>509
汎用言語じゃないから

**デフォルトの名無しさん** · 2022/09/27(火) 11:38:54.13

>>509
その単純な計算やループはたまにしか使わない
JuliaはGC言語なのにヒープメモリをできる限り少なくするプログラミングをプログラマーがしなければいけない
そのへんに気を使わずプログラムを作ると速さに大きな差が出る
つまりメモリ管理は気にせず言語に任せておけばいいという言語じゃない
なのにガベージコレクションが発生する

**デフォルトの名無しさん** · 2022/09/27(火) 12:04:52.19

>>509
今時数値計算をCPUでやるおじさんは老害

**デフォルトの名無しさん** · 2022/09/27(火) 12:51:08.64

Juliaは多重ディスパッチでデータ型とアルゴリズム実装を自由に組み合わせられるみたいなのが売りの一つだと思うけど
ちゃんとテストされてない組み合わせだと簡単に計算結果を間違うという指摘が結構あって
数値計算向けの言語としては致命的なんではないかなぁと思っている

**デフォルトの名無しさん** · 2022/09/27(火) 13:19:39.57

カリー化の要領で単一ディスパッチに帰着するパターンの正式名称が致命的だった

**デフォルトの名無しさん** · 2022/09/27(火) 15:29:16.37

>>511
本当に触ったことありますか？どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。
それはRustだって同じ事、GCというかスコープを外れたらOSが回収するが、決してメモリーを気にしないような
プログラミングなんてしない、これはGoでもJavaでも同じ。これを気にしない人はカッコ付けて再帰呼び出しを
してみたりスタックさえ気にしない人が稀にいる
本当に言いたいことを最後に書く日本人の典型だと思うが、そりゃGCはGC系なので発生するでしょうね

>>512
いまどきならCUDA.jlやAMDGPU.jlというものがある。だがRustだとかGoだとかもGPUを普通は使ったりしない。
前者は標準の高階関数で悦に入ってるのがその証拠であり、後者は多数のgoroutineで疑似パラレル処理を
するわけだが稀にGPUを使うとしても特殊例に過ぎない

>>513
そりゃテストされてない組み合わせなんてまともに動くほうが稀だとおもうけど。Rustでいえば少し昔のactixを
async-stdで動かすようなもんだろう、動的呼び出しのコストを気にして、動的性がほとんどないRustやGoと
比べるのが違うんだろうと思うが、letだのvarだの書かないのは、型推測の究極系からいうとありだと思う。
パターンマッチングもあるし、ライバルはRustとかじゃなく、PythonのDeepleaning系やＲなんだろうと思うが

**デフォルトの名無しさん** · 2022/09/27(火) 15:42:59.62

めっちゃw早口で言ってそうw

**デフォルトの名無しさん** · 2022/09/27(火) 16:39:12.74

>>515
> どんな言語だとしても、ループ内でのヒープメモリ割り当てなんて気を付けて書く。

多くのGC言語では、そんなことを気にせずGC任せのプログラマーが多数派だと思います

> GCというかスコープを外れたらOSが回収するが、

ありえません

**デフォルトの名無しさん** · 2022/09/27(火) 18:30:42.66

Rustみたいなバリバリの実用土方向け言語と比べるのは間違い。

**デフォルトの名無しさん** · 2022/09/27(火) 18:38:52.09

>>515
必死で笑った

**デフォルトの名無しさん** · 2022/09/27(火) 18:56:17.56

>>515
本当まで読んだ

**デフォルトの名無しさん** · 2022/09/27(火) 19:10:24.11

>>518
え？ほとんど誰も使ってないんだけど

**デフォルトの名無しさん** · 2022/09/27(火) 19:50:43.74

>>518
Rustは管理部門がコーダーに押し付けたい言語。
社員監視用にマナー講師を雇うようなもんだ。

**デフォルトの名無しさん** · 2022/09/27(火) 20:02:47.05

>>522
このまえはRustを趣味で使われる割合が多いと叩いていたのに叩く方針変更かね
Rustはプログラマーに愛されているプログラミング言語7年連続1位と記事が出ているけどどうするのかね

**デフォルトの名無しさん** · 2022/09/27(火) 20:09:31.55

>>515
各組み合わせごとに厳密にテストしないと組み合わせられないなら
「多重ディスパッチで簡単に組み合わせられます」とか言うなよってこと
そもそも静的型ならコンパイルエラーになるしPythonとかなら巨大なライブラリにみんなで乗っかる方式だから、組み合わせの問題が発生しやすいのはJulia固有の話

**デフォルトの名無しさん** · 2022/09/27(火) 20:13:06.18

>>523
今までも同じ主張しかしとらんよ。
これからは他人のために使うRustユーザーが増えていくから、愛され言語１位を維持するのは無理だろ。
PythonとかJavaの規模のなっても維持できているなら本物だな。

**デフォルトの名無しさん** · 2022/09/27(火) 20:18:14.18

Rustは他の言語よりコーティングしやすいしプログラマーにとっては嬉しい言語っす

**デフォルトの名無しさん** · 2022/09/27(火) 20:49:24.20

1から自分で好きなように書くならRustは気持ち良い言語なのは同意するけどね
Rustは個人の好みや癖が出やすい言語だから、他人のオナニーの後片付けは辛いぞ
Rubyしかり、創意工夫()の余地が大きくて楽しい()言語はレガシー化すると激しくプログラマに嫌われる傾向がある

**デフォルトの名無しさん** · 2022/09/27(火) 21:06:03.50

>>527
プログラミングしたことのない人には
RubyとRustは創意工夫の余地があって辛くて
他の言語には創意工夫の余地がないように見えているのか
そんなデタラメ書き散らす前にプログラミング経験積んで出直してこい

**デフォルトの名無しさん** · 2022/09/27(火) 21:27:10.63

Go追加>>478(>>450,461)
Language x10 x100 x200 x400 Memory Comment
--------------------------------------------------------------
Zig 0.118 1.073 2.113 4.203 3.2MB (std.HashMap, caller hash by Context(Fnv1a_64))
C(gcc) 0.136 1.146 2.271 4.531 2.0MB (optimized.c, binIO,jemalloc,O4,LTO)
C(clang/LLVM) 0.137 1.147 2.280 4.544 2.0MB (optimized.c, binIO,jemalloc,O3,LTO)
Go 0.152 1.233 2.428 4.832 3.9MB (caller hash,better loop) New
Go 0.164 1.346 2.654 5.279 3.8MB (caller hash)手元再現 New
Go 0.177 1.412 2.733 5.446 3.8MB (caller hash)<--参考値from過去スレ
Rust(LLVM) 0.154 1.425 2.838 5.674 2.6MB (optimized-customhashmap,O3,LTO,caller-hash)

以下、caller-hashではない
Go 0.085 0.366 0.693 1.319 61.9MB (parallel.go,reserve 65536/2)<--マルチスレッド New
Zig 0.162 1.493 2.970 5.935 4.6MB (std.StringHashMap)
Go 0.182 1.563 3.063 6.097 3.8MB (customhash.go,reserve 65536) New
Rust(LLVM) 0.214 1.725 3.396 6.715 3.5MB (optimized,fxhash,O3,LTO)

zig version 0.10.0-dev.4166+cae76d829
gcc 12.2.0/clang 15.0.0
go version go1.19.1
rustc 1.64.0 (a55dd71d5 2022-09-19)
CPU Zen3@boost max~4.75GHz

https://github.com/benhoyt/countwords

予想以上にGoが速かったが、最近の成果かもしれない。
https://go.dev/blog/go1.19 (2 August 2022)
>Go 1.19 includes a wide variety of performance and implementation improvements

**デフォルトの名無しさん** · 2022/09/27(火) 21:40:42.21

アルゴリズムの比較と言語の比較の区別がつかない人が未だに無意味なことを続けてるな～

**デフォルトの名無しさん** · 2022/09/27(火) 22:51:31.16

>>522
なるほど

**デフォルトの名無しさん** · 2022/09/27(火) 23:06:01.46

社畜タイムだな

**デフォルトの名無しさん** · 2022/09/27(火) 23:25:50.78

>>522
そんなホワイト企業があるなら名前教えてくれよ

**デフォルトの名無しさん** · 2022/09/28(水) 11:39:35.28

くせぇ、くせぇ、泥だらけ漢だらけで土方臭え！forループじゃなくmap使えとか親方ァは細かすぎる・・・
何がワシだって「下積みの頃はC未定義動作で行間を読んだもんだ！」だ！未定義動作書くなよ！？基本だろうが！＃
何が「ここは大手の偉い人が書いたから変えらなかったんだよ！」だ！
Displayトレイトが滅多に表示しない方に使ってて頻繁に表示する方はいちいちdisp_xxxなんて呼ばないといけないんだ！
設計根本から間違ってるだろうが！
「Rustは気持ち良い言語、Rustは気持ちよく書ける」なんて2020年代前半に言われてたらしいが、もう憎しみしかない
お百度参りしても、この恨み晴れるとは思えない
オレこのデスマが終わったら、高給取りのAIのPython業界に転職するんだ・・・

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

>>534
ことごとく勘違いしてるでしょ？

mapは単なる写像にすぎなくてループと対応するものではなくループの中の写像の文 let y = f(x); に対応するものです

未定義動作はunsafeを使わない限り発生しません

disp_xxxといったものは標準ライブラリにありません

以上から貴方はRustではなく異なる別のものを使っている可能性が高いです

**デフォルトの名無しさん** · 2022/09/28(水) 13:39:09.80

顔真っ赤で一行開け必死で笑ったｗｗｗキモッｗ

**デフォルトの名無しさん** · 2022/09/28(水) 18:08:24.66

rustは、haskellみたいにはならないと思う。
ロマンが足りない。オナニーしても気持ち良くない的な。
その点、juliaの方がロマン感じる。

**デフォルトの名無しさん** · 2022/09/28(水) 18:19:46.86

rustは十分ロマンがあるよ

**デフォルトの名無しさん** · 2022/09/28(水) 19:06:02.54

嫌いなのはわかるけど消去法でもRust一択だよ
まずスクリプト言語は速度と安全性がゴミなので論外
(書き捨てのスクリプトにのみ使うならアリ)

C/C++は論外
世界中のバグはこの言語から生まれている

JavaやC#もぬるぽ排除失敗
副作用まみれを助長する言語仕様
クソ重GCとJVM運用でオワコン

Goも結局ジェネリクス導入の失敗で標準ライブラリがジェネリクスなしの涙目に
安全性とは程遠い
言語仕様も一部よくわからない謎
さらにゴルーチンの書きにくさで並行処理の言語としても微妙

その他のモダン言語は結局本質的解決にはなってないから論外

よってRust一択

**デフォルトの名無しさん** · 2022/09/28(水) 19:10:09.32

>>539
Goはnil安全性すらないから前世紀の言語っぽい

**デフォルトの名無しさん** · 2022/09/28(水) 19:15:39.85

Goは色んな機能を削りすぎていて苦痛
ジェネリック導入で明るい未来を期待していたけどあんな使えない仕様になるとは

**デフォルトの名無しさん** · 2022/09/28(水) 19:17:23.82

>>540
あーそれもあるか
err != nilには笑ったわ
なんかエディタのスニペットに登録してるから問題ないらしい

**デフォルトの名無しさん** · 2022/09/28(水) 19:20:37.46

正直NULL安全みたいな機能いるか？
Kotlinとかにもあるけど、結局NULL許容型も書けるし中途半端過ぎる

**デフォルトの名無しさん** · 2022/09/28(水) 19:21:11.66

>>539
Rustは絶壁の学習曲線で多数の初学者が挫折し、エンスー以外使えないエンドコンテンツで終わるだろう。

せめてライブラリとかフレームワークを初心者向けに作り込むことができればまだ可能性はあるが、所有権とライフタイムがラフな使い方を拒否するからそういうことも困難。

まぁ、「３番目に学習する言語」くらいの位置になれれば万々歳だな。

**デフォルトの名無しさん** · 2022/09/28(水) 19:25:13.91

>>543
関数型界隈以外ではその重要性に気がついてなかった
いわゆるシステムプログラミング言語でRustが唯一まともにNULL安全性を持って生まれた言語

**デフォルトの名無しさん** · 2022/09/28(水) 19:30:16.66

>>544
初心者が挫折しがちというのは理解できるのだが
(俺自身C/C++のヘビーユーザーだったが最初はコンパイルを通すのに苦労した)
しかし一旦理解するとコンパイルエラーはほぼ起きないし
Rustの気持ちになって考えることができるようになる
本当にコンパイラの気持ちがわかる

**デフォルトの名無しさん** · 2022/09/28(水) 19:40:17.57

>>543
Javaのヌルポは散々馬鹿にされていたからなぁ。
実際には、正常値としてのNullならnull objectの方が素性が良い。optionalみたいなNullが良いのは、異質なケースとして明示的に処理したい場合のみ。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:30.85

>>546
その「一旦理解する」というのが絶壁だっつうの。

**デフォルトの名無しさん** · 2022/09/28(水) 19:43:33.10

データ構造含めてスパゲッティでも動いてくれるGC言語と
データ構造が整理されていないとコンパイラが通ってくれないRust
保守性の良いコードを強制してくるRustはウザいよな

**デフォルトの名無しさん** · 2022/09/28(水) 19:51:26.79

>>547
ポインタであろうとデータであろうと
nullやnilなどはその型と全く別の型であるべきであり
型が異なればコンパイルエラーとすることができるため
nullやnilをうっかり使ってしまう悲劇を確実に回避できる
この仕組みを備えることをnull安全性と言う

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

>>543
kotlinは割りとバランスいいと思う。
Option<T> みたいな冗長な型にならず T? で済ませてるから。
Rust はそこはちょっとダルい。

**デフォルトの名無しさん** · 2022/09/28(水) 20:27:35.31

はぁ？w

**デフォルトの名無しさん** · 2022/09/28(水) 20:37:57.86

>>539
そんな優等生な実用性は求めてないんだよ。

次世代なら、超すごいGCとかなんでも推論してハマればすごいけれど外れるとクソみたいなのをやってくれよ。

**デフォルトの名無しさん** · 2022/09/28(水) 21:50:06.42

>>553
その辺はcopilotなど最新のAIの分野だと思われる
モダン言語としてはまず言語仕様をしっかり安全性の高いものにするのが大事
それに俺はヤンキーを否定してるわけではない
pythonとかライブラリの充実度は世界一だろうし
雑なツールを作るには一番早くできるだろう
TypeScriptもスクリプト言語の型システムとしてはよくできている
しかしその手の言語を最初に使っても結局そのスクリプトを人がどんどん改造してスパゲッティになる様子を見てきた
スクリプト言語である程度実装可能なことがわかったら
すぐにRustに切り替えるべき

**デフォルトの名無しさん** · 2022/09/28(水) 22:09:10.05

>>548
C/C++を理解していないと難しいとは思う
所有権の移動はあらゆる変数参照で起きうるから
ひとまず借用しまくること
Rustの借用はコンパイルが通る限り安全なのだ
所有権を移動しない
これで既存の言語のように書けるのではないかな

**デフォルトの名無しさん** · 2022/09/28(水) 22:56:28.26

>>555
move不要説って、RefCellで複雑なことやろうとするでしょ

Cellでreplaceしまくったほうが簡単だよ

**デフォルトの名無しさん** · 2022/09/28(水) 23:45:50.98

moveでもborrowでも呼び出し階層のどのレイヤーで所有権を持つか常に意識しないといけないから既存の言語と同じ感覚では書けないよ

それが良い面もあれば悪い面もある

**デフォルトの名無しさん** · 2022/09/28(水) 23:54:28.10

>>556
Cellや動かせないOptionの中身に対してはreplaceだな
生成コストかかるものならtakeで一時的に借りるしな
moveはいつでもコスト安い

**デフォルトの名無しさん** · 2022/09/28(水) 23:56:03.77

>>543
いるに決まってんだろ。
お前意味なくいつもnull許容ばかり使ってるのか？ありえねーわ。

**デフォルトの名無しさん** · 2022/09/28(水) 23:58:55.54

>>557
それは>>515も書いているように
どんな言語でもまともなプログラマーならば内心で意識してプログラミングするっしょ
そしてその意識の差で速度が大きく変わって来るから言語に関係なく重要な

**デフォルトの名無しさん** · 2022/09/29(木) 00:25:48.05

moveは速い
cloneも速くするためにはRcに入れて循環参照とかいうリスクを取る

逆に言えば、最適化の意識が低いスタイルを確立すれば循環参照問題が無くなるのでは？

**デフォルトの名無しさん** · 2022/09/29(木) 01:02:09.01

>>561
聞きかじりだけでRustを使ったことがないからそんな間違えをする
Rcのcloneと中身のcloneは全く別物かつ独立
例えば中身がclone実装なく不可でもRcはcloneできる

循環参照は意図的に作らない限りRustでは自然に生じることはない
そして作らないことが正解

**デフォルトの名無しさん** · 2022/09/29(木) 01:13:01.23

>>560
GC言語では全く意識する必要ないよ
性能にも関係ない話

**デフォルトの名無しさん** · 2022/09/29(木) 02:20:18.96

>>563
GC言語でも意識しないと性能に直結するぞ
>>515が言うループの内外どちらかで速度差を測ればすぐ分かる

**デフォルトの名無しさん** · 2022/09/29(木) 04:16:41.47

複オジ相手しても時間の無駄だぞ

**デフォルトの名無しさん** · 2022/09/29(木) 04:19:15.74

>>562
聞きかじりがどうのと、そんなメンドクサイ言語はダメだわ。
バグのもとだわ。

**デフォルトの名無しさん** · 2022/09/29(木) 08:16:59.79

>>560 >>562
そんな前提が無いと使えないんじゃ、やっぱりRustは絶壁の学習コストだな。

コミニティも初心者に配慮する気配無いし、>>544が正解か。

**デフォルトの名無しさん** · 2022/09/29(木) 08:35:25.13

>>566
>>567
じゃあC++についても知らないのね
C++のshared_ptrもRustのRc/Arcもどちらも機能もその件も同じで
そのスマートポインタのコピー(clone)をしても中身はコピーされないんだよ
中身はそのままで共有する仕組みであって基本知識の入門レベル

GCのある言語でもオブジェクトの参照のコピーとオブジェクト自体のコピーの違いがありますね
それと同じことだからこの2種類のコピーの違いを理解できていないのはマズいですよー

**デフォルトの名無しさん** · 2022/09/29(木) 08:50:17.22

ホントRustをわざと嫌われるように仕向けてるように見えるよなあ

**デフォルトの名無しさん** · 2022/09/29(木) 10:17:24.11

Rustはなぜ開発者に愛されているのか、そして「人を選ぶ」理由とは？実案件でRustを採用するゆめみに聞く
https://codezine.jp/article/detail/16416

**デフォルトの名無しさん** · 2022/09/29(木) 11:33:20.73

まずは既存言語の延長として借用ベースでコードを書いてから
適切にムーブもするというスタイルをお勧めしたいね
本来のRustのスタイルとしてはムーブベースで考えるべきなのだけど
ハードルがかなり高いと思う
(C++のムーブコンストラクタやムーブ代入演算子を使いまくってた俺クラスの人間じゃないと無理)
借用の乱用でライフタイムの指定が嫌になったころにムーブを覚える
これこそアハ体験

**デフォルトの名無しさん** · 2022/09/29(木) 11:38:34.00

>>568
2種類のコピーが同じではない証拠があればそうなる
証拠を得ることができない仕組みをわざと作れば、両者は速度以外同じになるので最適化に利用される

**デフォルトの名無しさん** · 2022/09/29(木) 12:05:38.59

毎回ID変えて書き込む理由って結局何なの？

**デフォルトの名無しさん** · 2022/09/29(木) 13:45:27.89

自分の名刺に知らない会社の名前が書いてある理由は？

**デフォルトの名無しさん** · 2022/09/29(木) 13:48:46.01

Rust初心者なのになぜ強がって墓穴を掘りたがるのか
複オジ病の心理が理解できん

**デフォルトの名無しさん** · 2022/09/29(木) 14:01:28.67

>>575
承認欲求だろ
他で承認されることがないから
匿名掲示板で嘘ついても虚勢を張ってでも
承認してもらいたくてしょうがない心理状態

子供が親に褒めてもらおうと嘘をつくのと同じ
大人でそれが常態化してれば病気だよね

**デフォルトの名無しさん** · 2022/09/29(木) 14:30:58.29

>>571
消費する時はムーブ
消費しない時は借用

**デフォルトの名無しさん** · 2022/09/29(木) 17:55:07.76

>>572
参照のコピーと実体のコピーは異なる
後者はそれ以後二つの実体へ分岐となる

**デフォルトの名無しさん** · 2022/09/30(金) 16:19:35.52

ファミコンで動作するGUI付きOS「NESOS」が爆誕
2022年09月30日 11時06分

ファミリーコンピュータ上で動作するGUI付きのOS「NESOS」が開発されました。
NESOSではタスクバー付きのデスクトップ画面を表示したり、デスクトップ上のアイコンを自由に並び替えたり、テキストの編集を実行したりできます。
デスクトップ上のアイコンは自由に並び替え可能で、タスクバーにファイルやアプリを配置することもできます。
テキストエディタでは、ファミリーベーシック用のキーボードを使ってアルファベットと各種記号を入力可能。

NESOSは無料配布されており、公式ページのダウンロードリンクからダウンロード可能です。
https://gigazine.net/news/20220930-family-computer-nesos/

**デフォルトの名無しさん** · 2022/09/30(金) 18:09:21.49

最近の流行りが静的型付けと型付きラムダ系FPからの便利機能輸入だから逆風だけど、雑に書くのに向いてる言語ってなんだろうね
Nimはかなり書き味意識してるって話だし、ベタッと実装するならGolangは向いてると思ってる

**デフォルトの名無しさん** · 2022/09/30(金) 18:32:32.92

開発環境も含めてならC#は雑に書くのに向いてると感じたな
最近のバージョンだとクラスやmainメソッドを省いてスクリプト言語みたいに書けるし、IDEの補助が神がかってるから迷わずに書けてミスしにくい
まあ書き味も大事だが、雑に書く場合は極力テストの手間も抑えたいから、ミスしないことは超重要

**デフォルトの名無しさん** · 2022/09/30(金) 21:42:44.42

型推論できる？

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

C#はF#みたいにネイティブでスクリプト実行できるようになった？

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

nodeとgoとrustで/helloを受け取ったら、hello worldと返すだけのAPIを立ててベンチマークしたんだけど何でここまで差が出るかわかる人いる？30倍も違うんだけど
12スレッドのwsl linuxだけどtaskset -c 1で1コアに制限しても
Goでは 36345.50rps avg102.03ms, Rustでは 82382.92rps avg43.57ms と依然として差があるんだが
シンプルなAPIでもここまで差が出るんだから、Nodeは論外ってことなのかな
コード: https://pastebin.com/cWdaC2rZ

wrkを使用
$ wrk -c 4000 -d 5 http://localhost:3000/hello

node (express)
Thread Stats Avg Stdev Max +/- Stdev
Latency 466.94ms 73.50ms 669.37ms 81.57%
Req/Sec 4.09k 678.72 4.82k 82.98%
38284 requests in 5.07s, 8.73MB read
Requests/sec: 7547.73
Transfer/sec: 1.72MB

go (net/http)
Latency 8.72ms 5.33ms 102.98ms 96.17%
Req/Sec 122.50k 6.37k 135.10k 69.57%
1163747 requests in 5.10s, 144.28MB read
Requests/sec: 228242.97
Transfer/sec: 28.30MB

rust (active-web)
Latency 8.77ms 3.15ms 31.07ms 76.16%
Req/Sec 115.76k 18.13k 156.46k 62.22%
1085310 requests in 5.08s, 133.52MB read
Requests/sec: 213464.53
Transfer/sec: 26.26MB

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

ひょっとすると JavaScript だから遅いんじゃなかろうか

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

IO処理が主体ならそんなに変わらない認識だったけど10行程度のWebAPIでここまで変わると思ってなかった

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

>>583
なった

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

スパゲッティにならなきゃRustは最速だな

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

Goは1コアに制限したらGCのペナルティが大きいんじゃね。今は複数コアある前提でコンカレントマークでしょ？

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

>>584
起動時にモジュールを大量に読み込んでるしJITもしてるからそんなベンチじゃ遅いのは当たり前

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

スクリプト言語とコンパイル言語を比較する場合はランタイムのオーバーヘッドに差がありすぎるのだから
そこで差が出るようなベンチは無意味
実際のアプリケーション相当の処理を想定しないと

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

>>590
はあ？
1分やっても2分やっても全く同じだけど？
もしかして平均の意味すら知らないのかな？

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

>>592
偉そうにいう前にまともなベンチしろ

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

>>593
いやだから10秒だろうが1分だろうが5分だろうが変わらないって
偉そうなこと言ってるのはお前だろ

あらゆるノイズを排除してここまで差が出るんだから起動時のコストなんて関係ないだろ
適当なこと言ってマウント取ってんじゃねーよゴミ

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

>>594
ゴミはお前
論点ずらしするな
ただのストローマンだぞ
俺の言ったことをまずやれ
そしてそれでも差があるなら反論しろ
それが正当なやり方だろ
お前は手を動かさずに自分の意見が正しいと言ってるだけ

もしかして数分実行しただけでキャッシュができると思ってる？
しかもそんなよくわからんサンプルで？
そもそもキャッシュができる条件など仕様にはない
できない可能性もある
そういうことを含めてのベンチなんだよ

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

「俺の意見が間違ってる」ことをコードで証明しろ
ストローマンの口八百で語ってもなんの意味もない
それこそただのマウント野郎だろ

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

いくらなんでもNode遅すぎで気になるね
レスポンスしてるヘッダの内容とかも比べてみなよ
HTTP/1.1が使われてるのか、cookieセットされてるかとか、keep-aliveはどうかとか

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

俺の意見を無視するならここに書く意味はないし
はろーわーるどのベンチでnodeは遅いね、で終わる話
ここに書かずに1人で納得しとけ
ここに書く以上何か意見を求めてるんだろ？
その意見を言ってやってるのに無視する
正しい人間の態度とは思えんな
あまりの自分勝手さに怒りさえ覚える

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

とりあえず家帰ったら動かしてみる
俺のローカル環境だが

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

>>597
試したけどcurl -vで複数回投げた時にconnection left intactとRe-using出るからコネクション使いまわせてるね
HTTP1.1だからデフォルトでkeepaliveになってる
wrkはHTTP1.1対応

Nodeは日付とか色々ヘッダに入ってみたいだから公平な比較にはなってないけどそれにしても差があるすぎると感じるね

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

>>584
Q：なぜ何でここまで差が出るのか？
A：この場合、rust (active-web) は、asyncなどでI/O待ちを切り替え起点とした非同期処理を行うが
goは1リクエストに対してgoroutineが1つ付く。細かく言うとRustはソケットI/Oへ受・送信が終わらないと
次のリクエストは処理待ちになる。
結果はReq/Secに出て高速で(効率的な)スイッチングを行えるgo (net/http)のほうが最終的に処理できる
リクエスト数は高いが、平均処理時間avgはRustのほうがほんの少し速くなる。

goでavgが遅くなるのは、処理中にI/Oを起点としない時分割で別リクエスト処理へ切り替えるために
切り替えコスト+処理コストの合計で1つのリクエストを完了する時間は長くなる

余談だが、wrkは５秒だと並列テストなどをするには短い。より厳密な計測ができるwrk2とかあるが
この場合は並列での負荷テストではないのでそんなに変わらない。ただ最初の1秒が参考にならない
上の例はあくまで1コアだが、多コア高負荷環境(1000同時スレッド・3万リクエスト・30秒ぐらい）だと
50%はgoのほうが速くなり、Req/SecはRustのほうが多くなる

node(express)は、express自体の重厚さJS/TS自体の重さがかなり効いていると思う

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

ただWSLであってもLinuxのbacklog当たりのカーネルパラメータを弄れば結果は変わるかもしれない。
並列・高負荷ではなくても4000コネクションだと標準の状態だと足りない気がする

$ sudo sysctl -a 2>&1 | grep -E 'somaxconn|tcp_max_syn_backlog'
net.core.somaxconn = 128
net.ipv4.tcp_max_syn_backlog = 512

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

WSLでやってんのか、WSLってパフォーマンス的にはなんか特徴あるのか？
このあと気が向いたらおれもちょっと気になるとこのベンチ比較してみる

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

とりあえずNodeは遅いゴミってのが証明されてるな

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

>>597
その木なんの木。

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

もう１つ言うと高負荷で比べるならrust (active-web) なら、go側はSO_REUSEPORT/SO_REUSEADDRを
効くようにするか、fasthttp系(fiber)などを使用すべきで、net/httpを普通に使っただけだと極限の性能では
無いので注意が必要です、今回は高負荷でないので関係ありませんが

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

利用者数が全然違うので、今はGo言語を使うほうが良いのでは？
もしもRustが使われるようになったなら、その時使えば良い。
今はまだHaskell候補の状態。
そのうちHaskellのように誰も見向きもしなくなるんだろうなあと。

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

万能言語は作れない
用途別だ

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

並行プログラミングなら、関数型のElixir

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

型なしのゴミ