Go language part 4

**デフォルトの名無しさん** · 2020/11/16(月) 04:14:40.64

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

※前スレ
Go language part 3
https://mevius.5ch.net/test/read.cgi/tech/1571315884/

**デフォルトの名無しさん** · 2022/02/07(月) 09:14:37.90

お前らが煩いから…

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

最近goよりrustが気になってきた
コンパイラ型の早いモダンな言語ということで安易にgoやってたけど
rustにすべきだったか

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

rustは学習時間がかかる

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

利用範囲というか得意範囲が違うから興味はない
まして癖が強いんで覚えなきゃならんことが多すぎる
出始めのJavaより癖が強くないかあれは
今は皆が馴染んだけどJavaのIO周りとか、解らねぇ！という声が多かった記憶
だから少なくとも10年は待つのが正解

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

>>771
用途が違うんだから、両方やればよろし

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

Goは向いている適用範囲が狭い
他の言語も併用せざるをえない

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

それでいいんだよ

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

Go 1.18 Release Candidate 1 is released 2022/02/18 2:04:17 (昨日)
https://groups.google.com/g/golang-announce/c/QHL1fTc352o/m/5sE6moURBwAJ

**デフォルトの名無しさん** · 2022/02/20(日) 11:21:21.17

> 早いモダンな言語
速くもないしモダンでもない

**デフォルトの名無しさん** · 2022/02/20(日) 12:17:41.07

1.18 finalは3月に持ち越しか

**デフォルトの名無しさん** · 2022/02/20(日) 12:35:50.50

単体のマシンで並列処理をひたすらに行うという涙ぐましい用途特化よね
無駄金がありゃ分散化してロードバランサ使ってしのぐと思う

**デフォルトの名無しさん** · 2022/02/20(日) 13:24:25.85

Goは並列処理が書きやすい簡単な静的型付け言語って感じよな
Goの文法はモダンとはとても言えないけど、わりと早いビルド、gitとの連携、fmt、とかもろもろのエコシステムを総じて言えばモダンと呼べそうではある

逆に、例えばD言語は文法が良いのにエコシステムがウンコだったから人気出なかったんだと思う

**デフォルトの名無しさん** · 2022/02/20(日) 15:45:27.00

分散しないでも程よく性能が出るって点から、ネットワーク関係の組み込み機器(ルータとか)に向いてるような気もする(気がするだけ)んだけど、特に席巻してるとも聞かないから使われてないのかな

**デフォルトの名無しさん** · 2022/02/20(日) 15:47:35.30

busybox的な作りならメモリも圧迫しないだろという考え

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

>>782
ルータの中身なんてlinuxでCだろ
組み込みはCPUパワーと消費電力に厳しいのでC以外に現実的に解がない
逆に言えば、C以外で組んだ時には価格と消費電力でその商品に訴求力が無くなる
Cでは実現不可能な程のファームウェアアップデートの頻度が必要な商品もないだろ

**デフォルトの名無しさん** · 2022/02/20(日) 18:35:18.72

Google的には組み込み向けはFlutter/Dart

**デフォルトの名無しさん** · 2022/02/20(日) 18:37:32.10

>>781
goroutineが正解だと間違えた失敗言語だろ
このチャレンジ自体は良い事だが、正解はasyncだった

複雑になりすぎたC++を嫌い、またWeb系での最速を求めた連中はRustに行った
型を知らなかったWeb系の馬鹿共には丁度良かったが、そいつらはTSに行った
ast木がデフォで出るのは面白いが、あれはプログラマ的にはレベルが低すぎて使えない（自前で正規表現でやるよりはまし程度でしかない）
ならいっそのことあれこれやりまくる実験言語にしてもいいとは思うが、仕様の追加は他言語と比べても遅い

現在新規でGoをやる意味はないから、あとは廃れるだけだろ

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

web系のバックエンドである程度速度求める層には使われてくんじゃないかな。楽だもん。
個人的にはnull安全じゃない点でもういいやって感じだけど。

**デフォルトの名無しさん** · 2022/02/20(日) 21:46:42.94

>>787
> ある程度速度求める層
これは基本的にない。
速度が問題になると分かっていて、チームがRustを使える場合、100%Rustを選択する。
Rustが使えない場合、今現在の第一選択肢はTSだろ。
そこそこ速いし、最悪はJSエンジニアを流用可能だし、全く新規に教育するにしてもフロントエンドでも使えるし。
Web系の現場でGoをわざわざ教育する意味はない。

（飽和した市場においては）商品は尖ってないといけないとよく言われるが、Goは今現在尖ってないんだよ。
速度が欲しくてガッツリ組みたければC#でもいいし、実際にASP.NETのシェアは7.9%でPHPに次ぐ第2位だ。(なおGoは0.0007%、Rustはそれ以下）
https://w3techs.com/technologies/overview/programming_language
TSよりはGoが速いのも事実ではあるが、
https://atmarkit.itmedia.co.jp/ait/articles/1909/13/news133.html
googleがrubyを切った時のようにチーム内で言語を統一するなら、今ならJSかTSになる。Goはあり得ない。
今現在もシェアが低い＝使える奴が少ないのだから、このままだと数多のマイナー言語と同様にポシャって終わり。

バックエンドで速度を求める際、最速はRustだけど、これが嫌ならC#で、ここで終わってしまう。
C#の駄目な点は仕様が重量級で勉強するのが大変な事位で、速度も安全性も生産性もGo以上だから。
Goは、速度がある程度必要だが最速である必要はなく、RustやC#は絶対に勉強したくない層向けになるが、これは現実的に無い。

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

>>788
なるほどね。

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

>>788
JS/TSの人材がNode/Denoでサーバーサイドもいけるからね
そしてそれでは性能面リソース面で満足できないならRustが記述しやすくていい

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

Rustが使えない場合で、かつ速度が必要な場合にTS使う訳無いだろ。
C#はわかるが。
マルチコアに弱すぎるわ。
C#ではなくGo選ぶケースってのはGoならではのメリットがあるシーンが多い。

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

>>791
> Goならではのメリット
だからそれは何？って話だろ。

C#で駄目でGoってのは学習コストくらいだが、学習コストが問題ならWeb系ならTS/JSで決まりだよ。
Goはgoroutineかgo generateが大当たりすれば良かったが、そうでない以上、C#に勝てる仕様がない。
現在シェアでボロ負けしてて光る仕様もなければ、このまま沈没以外にない。

Rustを考えれば分かりやすいが、シェアでボロ負けしててもC#に速度で勝てるし、
安全性も一応最高を目指してるから、選ぶ理由はあるだろ。
GoはRustが出てきた時に身の振り方を考えなければならなかったんだよ。

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

>>792
そのGoroutineだよ。観測範囲狭いのでは…？
C#のasync awaitとスレッドプールは詰まる。

**デフォルトの名無しさん** · 2022/02/21(月) 00:13:42.23

>>793
asyncな関数を呼べばスケジューラに戻るわけだから
長時間ループで計算のみを続けることでもない限り詰まることはないでしょ

**デフォルトの名無しさん** · 2022/02/21(月) 00:16:41.00

>>793
詰まるって何が？
これ？なら仕様を知らないだけだね
https://oita.oika.me/2016/02/18/task-and-threadpool/

まあいずれにしても、C#で問題があれば、速攻対策されるよ

**デフォルトの名無しさん** · 2022/02/21(月) 00:26:24.14

あとこんなんも出てきた
https://www.rox-note.tech/?p=30

まあスレッドプールはそういう設計なのだから、デフォで問題ない使い方をしないのなら自前で設定してやらないと駄目だね。
でもスレッドプールはプールであって、goroutineみたいにスレッド占有（スタック保持）ではないので、
動いてないスレッドはプールに返されて結果的にCPUは最速で動くはずだけど。

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

長時間、膨大なタスクを動かしたいんだよ。

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

Go使う前はErlang使ってた案件。

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

C#ってサーバというかバックエンドで使えるのか
知らなかった

**デフォルトの名無しさん** · 2022/02/21(月) 03:00:09.00

>>797
膨大なタスクでも途中で何らか入出力すればスケジューラに戻るからタスクが切り替わる
入出力ゼロならばそれは延々と算術計算するだけなのだから別スレッド立ち上げればよい

**デフォルトの名無しさん** · 2022/02/21(月) 03:32:12.85

goroutineが理解できないC#おじさんがのC#のasyncで騒いでるだけ
こいつは数多くの言語が採用してるchannelの原理も理解できない。

**デフォルトの名無しさん** · 2022/02/21(月) 08:43:31.09

>>800
スレッドだと必要な数が多すぎて回らない。
シミュレーションの類やってる。

あとバッチで集計処理していくとかも作ってるけど、これも一億行百万ファイルとかが対象。

**デフォルトの名無しさん** · 2022/02/21(月) 08:44:21.18

>>801
なるほど。説明しても理解できてないから無駄だし、
理解する気が無いのか。

**デフォルトの名無しさん** · 2022/02/21(月) 17:01:09.43

>>802
まず、論理CPU数よりも多いスレッドを立ち上げても余計に遅くなる。
だから長時間膨大なタスクの結果を最速で得るためには、
論理CPU数と同じスレッド数で順に処理する事であり、
当たり前だがC#も含めてスレッドプールはこういう設計になる。

膨大なジョブを論理CPU数よりも多いgoroutineでカバーするのは、一般論としては組み方が悪い。
それで速くなる事はないから。
一般的にはその場合はスレッドではなくただのデータオブジェクトとし、論理CPU数と同じスレッド数で回す。

例えば有限要素法のシミュレーションを行う場合、当然データは100万個とかになるが、
CPUが10個なら10分割して、内部は完全に独立して回し、
他CPU担当と隣接してるノードは致し方ないので通信し、CPU10個で協調させながら回す。
これをgoroutine100万個として組むのがGoの思想なのかもしれないが、速くはならないね。
ただし、プログラムは簡単にはなる。

Erlangはだいぶ思想が違う。
あれはスケールアウト時のパフォーマンス低下を回避するために疎結合にしたもので、
実際スケールアウトしてもほぼ性能低下がないのでひたすら物理で殴れるらしいが、
それならErlangでいいよね、でしかない。

尖るってのは、「○○でも出来る」ではなくて、「○○じゃないと出来ない」の事。
Goにはこれがない。
なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。
https://stackoverflow.com/questions/145312/maximum-number-of-threads-in-a-net-app
一般的には、こんなにスレッドが必要な時点で組み方がおかしい、となる。（上記の通り）

> 一億行百万ファイル
普通は10CPUなら10分割して1,000万行10万ファイル*10ジョブにして投入、
レイテンシがバラつくようなら例えばさらに10分割で100万行1万ファイル*100ジョブにする。
これを1,000,000 goroutineで回すメリットは何？

**デフォルトの名無しさん** · 2022/02/21(月) 17:23:04.30

>>804
その考え方が古いでしょ。goroutineは軽量スレッドで実質async await+スレッドプールだよ。

https://zenn.dev/hsaki/books/golang-concurrency/viewer/gointernal

>>804
チャンネルでfan in/fan outしてる。

**デフォルトの名無しさん** · 2022/02/21(月) 17:48:23.98

>>801
それは例として厳しいかな
C#については全く知らないが
例えばRustではchannelの送受信もasync環境ではasyncとなる
つまりgoroutineのようにchannel送受信だけを永遠にする長時間タスクがあってもタスクは切り替わる
だからそういう例でも大丈夫
おそらくC#でも同じ状況ではないかと推測

**デフォルトの名無しさん** · 2022/02/21(月) 18:21:27.64

goにおけるチャンネルって、概念的には別スレッドのI/Oにデータ渡して発火させる感じだよね
最大スレッド数は開いているチャンネル数以上になることはないし、
メインスレッドには関係ない

async/awaitで詰まるってのはawaitが文字通りメインスレッドで待つからって話ではなく？

**デフォルトの名無しさん** · 2022/02/21(月) 18:35:22.44

goroutineも実質スレッドプールなのは事実だね
async/awaitはawaitの区切りでしか中断できないのに対してgoroutineはGoのユーザーコードならどこでも中断できるので、どちらがより詰まりにくいかといえばGoかもしれない
とはいえGoもシステムコールの中断はできないから、現実には差は出ないだろうね

**デフォルトの名無しさん** · 2022/02/21(月) 18:56:08.62

>>804
Erlangは「スケールアウト時のパフォーマンス低下を回避するために疎結合にしたもの」じゃないよ。プロセスが落ちることを前提にしたもので
パフォーマンスなんて考えてないというのは言い過ぎだが、フォールトトレラントでプロセスが落ちるから沢山のプロセスが起動できるようにした
ものであり、スケールアウトによる性能の保持はその結果に過ぎない。
「一億行・百万ファイル」このように初めから総数が分かっていれば分割できますが、総数が分かっていない場合には、「一行・10億ファイル」
かもしれない。この時に「絶え間なく処理結果が欲しい」ような場合だとスレッドを張り付けた処理は、分割された連続処理群が終わるまで
待たねばなりません。GoやErlangだとこのような処理の次に続く処理があった場合、パイプライン処理として処理します。

**デフォルトの名無しさん** · 2022/02/21(月) 19:20:21.68

>>805
> その考え方が古いでしょ
これがGo界隈のキモさだよね。自分らが先進的だと勘違いしてる。
なら、何故その先進的な言語がここまで無視されてるのか考えるべきだよ。
シェアで見たら、誰も使ってない言語だよGoなんてさ。
なおRustはポリコレを持ち込んだ馬鹿がいて同様にウザがられているが。

C#のスレッドは論理CPU数を越える起動用には最適化されてないはず。
だからそういう使い方をするためにはスタックサイズをいじらないといけない。
出来たはずだがやり方は知らん。
ただしそれやっても速くはならないよ。（Goもこの点は同じ）

> goroutineは軽量スレッド
これも嘘で、今探しても出てこないが、ラズパイ環境でゴミだったからNodeに戻ったというブログが有ったはず。
512MBのRAMで4kB/goroutineでは十分な量のgoroutineを起動できず、(なお今は2KB/goroutineも選べるんだっけ？)
Nodeでシングルスレッドで処理した方が断然速かったというもの。
Go信者はgoroutineのコストがゼロだと仮定しているが、まったくそうじゃない。
メモリも食うし、空間が別なんだからキャッシュの張替えも発生する。
(Cが地味に速いのはキャッシュにひたすらヒットするから、というのもある）

> チャンネルでfan in/fan outしてる。
意味分からんが、ハードウェアのゲートみたいに各チャネルが複数の入力/出力を持っててネットワークが割と複雑だって事か？
ただこの場合はイベントドリブンで組むことになってて、一応それが一番速いはず。
ハードウェアのゲートを１対１でgoroutineにすることはプログラムとしては記述出来るが、
1億ゲートとかだから4kB/goroutineではオーバースペック過ぎて無駄だ。
ゲートシミュレーションなら精々64Byte/goroutineとかじゃないと駄目だ。だけどこれは無理だろ。
(4kBに縛られてるのはCPUのページサイズに因っているから)

**デフォルトの名無しさん** · 2022/02/21(月) 19:28:42.96

>>804
それに「Goにはこれがない。なおC#、.NET4.0の64bit環境では32767個のスレッドが上限らしい。」という中途半端な知識表現に
ついても一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前で、それはスレッドがあまりにもOSにとっては
重すぎるから。(メモリやコンテキストスイッチなど払う代償が大きい）
Erlangはだいぶ思想が違うのはその通りだけど、GoはErlangほどではないが、小さいコストで多数の軽量スレッドを用意したもので
あり、これが何のために「Erlangで良いよね？」にならなかったのかといえば、背景にあるのは多数コアを搭載した近年のハードウェアを
生かし切れていない言語が溢れていたから
じゃあGoの役割はなんなのと言えば、Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、Goはコンパクトな
1つのマシンの中で上記のようなパイプライン処理をコンパクトに「なるべく早く」出来るよう考えられた。

**デフォルトの名無しさん** · 2022/02/21(月) 20:10:22.24

>>810
あんたのほうがキモイけど、C#の先進性なんて何があるの？俺スゲーのシンタックスシュガーだけでしょ？C#がスタックサイズなんて
弄るのはJavaと同じで基本がClassであり、さらには意味不明な意識高いバカが再帰処理などでメモリーが足りなくなるからです。

シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？当然作り方次第でご自慢のC#も
同じになるはずですし、RustやCでも同じことが起こりえますが？逆に言えばGoであってもgoroutine数を少なめにして、スレッドで
アフィニティを設定して使用するCPUをPinningしてやればほぼシングルスレッドと同じ状態を維持できるはずです

「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです、Goを始めたばかりの人だけです。こんなことを言っているのはｗ

膨大な配列を処理するときにCPUのコア数にきっちり分割して、間にコンテキストスイッチなどを挟まないほうが速いのは当たり前で
鬼の首を取ったように書かなくても多くの人はわかります。だが、Goの開発目的はそうではありません。同様に、Erlangのように
プロセスが落ちる前提で高い耐故障性を前提にするためでもありません。
また今はデフォルトは2kのスタックであり、「4kBに縛られてるのはCPUのページサイズに因っているから」とか、どこの知識なのか逆に
問いたいぐらいです。世の中いろいろなCPUアーキテクチャがありますが？現に多くのCPUは4kですが、s390は2kです

最速を求めるのであればGoもC#でもRustでもなく、ランタイムチェックのないCやアセンブラで書いてなさい。またCが速いのは
「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです、近年のマイクロベンチマークを１回でも
見たことありますか？近年のCPUのキャッシュサイズはMB級あるのを知っていますか？

**デフォルトの名無しさん** · 2022/02/21(月) 20:13:57.83

>>810
お前読んでるか？

**デフォルトの名無しさん** · 2022/02/21(月) 20:27:03.44

Goのランタイムのフットプリントはかなりでかいし、GCだけでなくそういうコストも許容できる贅沢な環境で、手抜きをして並列処理を書ける言語だよ

ようするに、RustやCで書くのはめんどいしメモリ食われてもいいけど楽してM:Nスケジューラ使いたい、みたいなときには適してる、っていえる言語ではないかと
非同期シングルスレッドしか使わない、っていうんならいろんな言語が選択肢に入りそう

**デフォルトの名無しさん** · 2022/02/21(月) 20:29:37.24

>>812
>「Go信者はgoroutineのコストがゼロだと仮定」これもダウトです

これ確かにGoroutineがコスト高いことを知らない人たちが意外に多い
例えばRustのタスクなんかはGoroutineに比べたら本当にコストゼロ
スタックレスであるし素朴な状態マシンとしてコルーチンとして機能するだけ
だからGoroutineよりリソース的にも軽いし起動も軽いし
巨大なランタイムを必要とするGoと違って非常にシンプル

**デフォルトの名無しさん** · 2022/02/21(月) 20:46:25.71

>>809
いやErlangは電話交換機用に開発された言語で、メタル回線時代だから最初から物理で殴る前提だ。
（収容数が増えたらラックを増やすしかない）
プロセスどうのこうのはOSの話だ。ただしErlangが生まれた80年代はそこまで綺麗に分離してなくて、
ErlangのランタイムがOS扱いだったのだろうけど。
フォールトトレラント性も多分最初から考えられていたのだとは思う。

> 「一行・10億ファイル」
論理CPU数を数万倍越えるジョブがあると分かっているのなら、纏めればいいだけの話。
単に1ジョブ毎に放り込むのではなく、100ジョブ纏めて取ってきてから放り込めばいい。
原理的にはgoroutine*100と同じ速度が出る。

**デフォルトの名無しさん** · 2022/02/21(月) 20:54:53.07

>>811
> 一般的なOSではスレッドの上限は16bitの域を出ないで少ないのは当たり前
そうじゃなくて、そういう風に作ってないだけ。
つまり、現行のOSでは、スレッドはそこまで使わない前提、そういう風には使わない前提だ。

> 小さいコストで多数の軽量スレッドを用意したものであり、
これをどう見るかだが、本来ならそれ用のOSを作らないといけないんだよ。
ただし実際はGoのランタイムでどうにかなる（=ハードウェアサポート無しでいい）から
そういう動きもないのだろうけど。

> Erlangはプロセスがネットワーク分散を簡単にできるが（その分遅め）、
> Goはコンパクトな1つのマシンの中で
これはその通り。Erlangは疎結合にしすぎてて、近年のハードウェア向きではない。
とはいえGoもまた行きすぎだよ。
論理CPU数を遙かに越える数のgoroutineを起動しても、速くはならない。
(ただ、コードは簡単に書けるだろうけど)

**デフォルトの名無しさん** · 2022/02/21(月) 21:16:05.40

>>812
一応言っておくが、俺はC#書いてないぞ。

> C#の先進性なんて何があるの？
いや色々ありまくりだろ。asyncもlinqもそれ以外も色々有ったと思うけど。
今現在メジャー言語で一番先頭走ってるのはC#だろ。
それぞれの機能は他マイナー言語で既にあった物を取り込んだだけなのかもしれんけど。

> C#がスタックサイズなんて弄る
基本いじらないけどね。
デフォで2Mのはずで、少々アホな再帰をやったところで埋まらない。

> シングルスレッド言語とマルチスレッドでメモリ量を比べて起動できないなんて意味ありますか？
これは書き方が悪かったか？
要はラズパイみたいに貧弱なハードウェアだとGoは機能せず、Nodeの方が速いというだけの話。
goroutineで楽して速いってのは贅沢なハードウェアありきの話。
なおJSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制するから、
その分CPUは無駄なく動く(スタックとかが小さくて済む)ので
同一ハードウェアだと他言語でシングルスレッドにするよりは原理的に速いけど。
(実際は動的言語の分遅いが、TSコンパイラとかが出てくれば面白くなるとは思う）

> s390は2kです
ほう、メインフレームのはそうなんだ。初めて知ったよ。
ただ知ってるつもりなら、現行で普通に使われてるCPU、例えばx86なりARM等で4kじゃない奴を挙げてみろよ。
ないと思うぜ。

> 「キャッシュにひたすらヒットするから」ではありません。ランタイムチェックが無いからです
違うぞ。ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、
それだとCとC++でCの方が速い理由を説明出来ないだろ。

**デフォルトの名無しさん** · 2022/02/21(月) 21:18:38.69

で、Rust vs GoだとConcurrencyどっちがすごいんよ？
https://deepu.tech/concurrency-in-modern-languages-final/
https://i.imgur.com/JGoa8Xe.png
これだとRustがさいつよらしいけど

**デフォルトの名無しさん** · 2022/02/21(月) 21:25:14.63

そら最速を求めるならクソデカランタイムが仕込まれてるGoが勝てるわけがない

**デフォルトの名無しさん** · 2022/02/21(月) 21:25:40.43

>>813
ああすまん、リンクは完全に失念してた。

で、読んだが、何だ？知ってたような内容しか書いてないが。
わざわざ指摘してくるのだから、fan in/fan out の説明があるのかと期待したが。

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

書きやすさ&ビルドのしやすさ、なんてのも実務的には大切。
ザクッと書いてクロスでコンパイルして大量のサーバに撒く、がめちゃくちゃ楽だよ。

**デフォルトの名無しさん** · 2022/02/21(月) 21:52:17.85

>>821
実際、軽量スレッドな事は知らなかったじゃん。
知ってたような事が書いてたけど誤解してたの？間抜けだな。

**デフォルトの名無しさん** · 2022/02/21(月) 21:56:26.38

>>819
フレームワークを使うともっと速くなるみたいで、最初はRust負けててactix使ったら勝ったらしい
フレームワークのベンチならこっちにある
https://www.techempower.com/benchmarks/
フレームワークを使わないケースだと、同じような実装にする努力の跡は見えるが、結果が言語単品の性能を表しているのか標準ライブラリの質を表しているのか、はたまた測り方なのか、何を表しているのかは知らない

**デフォルトの名無しさん** · 2022/02/21(月) 22:05:32.26

>>823
いや知っててあの内容だが？
それで納得出来ないのならそれでいいが、
goroutineは軽くはないし、ゼロコストでは全然無いよ。

**デフォルトの名無しさん** · 2022/02/21(月) 22:10:46.33

>>819
サンプルコード見たけど酷いな
言語そのものの速度を比較するためのものとは思えない
典型的スクリプトキディのおじさんだ

**デフォルトの名無しさん** · 2022/02/21(月) 22:19:17.65

>>819
本文は全部読んだ。(コードまでは見てない)

まずグラフがどうかだが、これを信じるなら、
Rusr/Java/Goは妥当、異様なのはJS(multi-threaded)の速さだよ。

詳細は本文に書いてあるけど、色々苦労してる。
問題はGo(HTTP)がぶっちぎりに速かったので、これは何だ？って事で、
どうやらライブラリの最適化に因るらしく、
わざわざ他言語でも最適化ライブラリを持ってきて比較し直してる。
で、Rustの方がGoの倍速く、JavaはRustと同程度（微妙に速いが）とかなってる。

ただこれ見る限り、CPU時間とかバラバラだし、
最適化ライブラリを用いたらRust/Java/Goどれも6倍になってるので、
言語の差よりもライブラリの最適化の方が断然重要って事になる。
本人は言語の実力の差をベンチマークしたかったのだろうけど、
ライブラリの最適化で6倍も変わる状況で言語での差をあぶり出すのは難しい。

本人が結論に書いてある事はまあ同意。なお、
> The community consensus when it comes to concurrency performance is quite split.
> For example, both Rust and Go communities claim to be the best in concurrency performance.

**デフォルトの名無しさん** · 2022/02/21(月) 22:26:10.00

Goは何も考えんでも、公式の実装がハズレ無いのでオーダーさえ考えて実装してれば間違いは無い。
まぁ、そもそもオーダーの計算を失敗しがちなmapとかflatMap無いからな。全部ループ。
そのおかげでめちゃくちゃキャッシュにきれいに載るというのもある。
思ってるより早いよ。

**デフォルトの名無しさん** · 2022/02/21(月) 23:09:18.19

まあ一応書いておくと、最適化云々言ってるけど、標準ライブラリのコンパイルオプションを変えたのでなく、標準ライブラリをactixで書き換えただけな
■標準ライブラリ版(遅い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/main.rs
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rustws/src/lib.rs
■actix版(クソ速い)
https://github.com/deepu105/concurrency-benchmarks/blob/nosleep/rust_actixweb/src/main.rs

**デフォルトの名無しさん** · 2022/02/21(月) 23:34:23.82

>>819
.NET他環境の半分程度の性能しか出ないのかよ
C#おじさんのご高説はなんだったの？戯言？

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

>>830
Goも同程度に遅いけどな。
と言うかこれはUndertow(Java)がずば抜けて速いんだよ。これは本人も書いてるとおり。

本来は

Rust(ネイティブ、ランタイム無し)
Go(ネイティブ、ランタイムあり）
Java/C#(VM)

の順になって然りで、VMと同レベルになってしまってるGoは遅すぎ。
C#は一応ネイティブにする方法はあるらしい。
VMからネイティブにすれば本来は1.5～2倍速程度は期待出来る。
https://docs.microsoft.com/ja-jp/windows/uwp/dotnet-native/
現在これが現実的に使えるものなのかは知らん。

ただまあ、同速しか出ないのなら、Goを選択する理由はないだろ。
まともな頭ならC#を選択する。
サーバーシェアだけでも10,000倍違うし、しかもC#の主戦場はunityであって
ASP.NETなんて連中からするとオマケかもしれない状況でこれだ。
ただしC#は重量級であって、日曜大工でやろうというものではないが。

**デフォルトの名無しさん** · 2022/02/22(火) 00:59:20.84

>>831
C#のAOTはこのケースにはあんまりきかないない。
なおそこてはなくてこっち。
https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/docs/using-nativeaot/README.md
刺さるときはめちゃくちゃ刺さる。制約にひっかからないかぎりよく使うよ。
ただこれでもダメならGo書いた方が楽。

Goらしいコードが書けてないのでは？と言う印象だな。

C#の主戦場はUnityは言い過ぎでは？
お前業務システムエアプ勢か？

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

>>831
コネクション増える程.NETの性能悪化してgoとの差開いてるだろ
都合の悪い所は見えなくなるのか？

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

>>819
なんでこれdotnetはDebugビルドで実行してるの？？

**デフォルトの名無しさん** · 2022/02/22(火) 10:13:55.17

>>818
「ランタイムチェックがないのも要因の一つで、RustやJavaの連中の言い訳になってるが、それだとCとC++でCの方が速い理由を説明出来ないだろ。」

おまえ酷い言い訳ばっかだな？ C#のLinqなんて正にシンタックスシュガーだろ。2MBもスタックとってる糞言語やってて口だけ饒舌でよく恥ずかしくないね？
「貧弱なハードウェアだとGoは機能せず」そんなことはありません、ラズパイのようなハードウェアを使ってGoogleはkubeクラスターと似た機能をN1クラスタで
使ってGoやRustで使用しています、ハードウェア使用効率の良くないNodeでなんか（ほとんど）使用していません。

Nodeが早いのはV8が速い（=Cで書かれている）からであり、「JSはCPUをひたすら突っ走らせる構造にすることをプログラマに強制」などと
いう嘘出鱈目で相手の反応を誤魔化すためではありません。JSが言語特性として速い訳ではありません。どう見ても言語に型が本来は無い
言語に速くなる要素があると考えられますか？TSが型を持った言語だとしてもしょせんはJSへのトランスレーターです。

さらにJSの次に使用されているwasmはページサイズは64Kでありx86なりARM等であっても2kに比べたら非常に大きなメモリー管理をされています。
あなたの言う4k/2kでもデカい64Bじゃないとと比べると実に1000倍です。「挙げてみろよ。ないと思うぜ。」こういう態度があなたを周りの人から
敬遠される１つの要素です。自分で調べもせず、コードで計測したこともなく、伝聞で偉そうな態度は馬鹿にされる要素の１つでしょう

また「CとC++でCの方が速い理由を説明出来ない」これがキャッシュのおかげにして説明できないのはあなたがプログラムをほとんど書いたことが
無いからです。配列などの連続するデータをループ処理するときに、if文などのCMP命令が1つ挟まれば、プログラムは低速化します。ループ１回に
付きCPU命令1つで済む処理では、if判定するために2つ以上になるため、多くは2倍程度低速化します。
これは、GoやRustなどは、範囲外にアクセスしてないか常にRange Bounds checkingで行っています。unsafeコードでも外せません。決して
キャッシュおかげでも、あなたの足りない語彙のせいでもありません。

**デフォルトの名無しさん** · 2022/02/22(火) 11:00:46.11

>>827
>>831
また多くのweb系のベンチマークの使用にされているRequest/Secは速さの指標の１つですが、本来は現実的にユーザーに利益のある
レテンシー速度のほうが近年は重要視されます。Javaや比較的昔からあるメジャー言語が速くみえるのは、歴史を積み重ねて最適化が
施されているからです。決して言語特性として速い訳でありませんし、Request/secを主眼とした速さの議論は、海外でも馬鹿にされます

RustがRequest/secで多く処理できるのはベンチマークなどの超高負荷環境においてgcが走らないからです。現実的にいえばそのような
環境で運用するのではなく、分散させてサーバーを複数立てるのが本来望ましい。上にあげられたような条件も見えない画像で判断する
のではなく、重要なのは99%タイルにおける高並列において応答のレテンシーが数秒以内に収まり、なおかつRequest/secが出せることで
あり、50%の応答速度が最悪、20秒になってしまうような使い物にならないものを比べるべくもありません

https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,express,actix

**デフォルトの名無しさん** · 2022/02/22(火) 12:57:29.93

一応訂正しておくよ。以前書いたフレームのベンチでも
https://www.techempower.com/benchmarks/#section=data-r20&;hw=ph&test=plaintext
このベンチが一番近いはずだが、nodejsは決して速くない。
js勢だとjustが速い。

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

> Goらしいコードが書けてないのでは？と言う印象だな。

ある程度書いてないとらしさみたいなもんは分からんわな
どんな言語でも
よってここに天下一武道会を開催する
各言語のらしさの粋をあつめたコードで
Concurrencyの雌雄を決したい

**デフォルトの名無しさん** · 2022/02/22(火) 20:10:03.17

>>837
nodejsはフレームワークとは言えんような。
justはnodeインストールしてなくても動くのかい？

**デフォルトの名無しさん** · 2022/02/22(火) 20:45:10.67

>>838
まずはぜひGoらしいコードを叩き台として出して

**デフォルトの名無しさん** · 2022/02/22(火) 20:59:43.80

自分で手を動かせ
誰かに何かを「やってもらう」ところじゃねーんだよ
自分でできないやつは書き込むな

**デフォルトの名無しさん** · 2022/02/22(火) 21:28:03.19

>>835
なるほど君が色々分かってないのは分かった。
が、まあ、これは後日だ。

>>836
その比較見てもGoが.NETに勝ってるようには見えないよ。
スループットは劣るが、レイテンシなら.NETの方が伸びないようにチューニングしてある。
そちらの主張するようにレイテンシの方が重要なら、.NETの方がいい。

GoとJSの比較のつもりなら、どうせならNANOexpressを使ってみては？
https://web-frameworks-benchmark.netlify.app/compare?f=fiber,aspnetcore,actix,nanoexpress
ほぼ全部のグラフでJSの方が上になってしまうが。
home見れば分かるけど、fiber(Goで最速)、.NET(C#で最速)、actix(Rustで最速）でexpress(JSでは27番目)は比較として酷いだろ。
知名度で選んだだけかもしれんけど。
nanoexpressが使えるレベルの仕上がりかどうかは知らんが。

**デフォルトの名無しさん** · 2022/02/22(火) 21:46:51.86

>>832
> > 制約にひっかからないかぎり
> 動的ロード無し
> evalなし
> COM/WinRT相互サポート無し
> リフレクション無し
まあ普通に静的言語のノリで書いてたら大丈夫だとは思うが。

>>837
俺はサーバー系JSの総称としてNodeと言ってた。
フレームワークを正確に識別する気だったらすまん。

justだとNodeの10倍なら、819のベンチで他言語が6倍速になってるのと同様だから、それなりの値になるのだろう。
いずれにしても言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えないね。

>>839
just-jsは多分これ。
https://github.com/just-js/just
> A very small v8 javascript runtime for linux only
というわけでNodeの代わりだな。ただしドキュメントがないので実体は不明。
justというほぼ同じ名前の、ただしGitHub垢は別の物があるのだけど、これと組み合わせて使うのかな？
https://justjs.github.io/

**デフォルトの名無しさん** · 2022/02/22(火) 21:49:46.37

別に.netをディスってる訳では無いんだが、代理戦争みたいな真似する理由がわからん。

GoがWebフレームワークのベンチマーク弱い理由はだいたいこの記事にまとまってる。
https://zenn.dev/nobonobo/articles/e651c66a15aaed657d6e
同じ事したら他のフレームワークと同じかもう少し早い。

ヘイトに関してはだいたいこれじゃん。
https://zenn.dev/nobonobo/articles/74808a8d5e6f1e

**デフォルトの名無しさん** · 2022/02/22(火) 21:50:53.96

>>843
ホントにやってみて言ってるか？ひっかかるぞ。

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

>>845
リフレクションを常用してるのなら、それは基本的にお前の組み方が悪い。

**デフォルトの名無しさん** · 2022/02/22(火) 22:03:10.10

>>844
「GoがWebフレームワークのベンチマーク弱い理由」が書かれていない記事に見えるがリンク合ってる？

**デフォルトの名無しさん** · 2022/02/22(火) 22:43:58.08

>>834
これ。Debugビルドでやって何の意味があるの？そりゃあ最適化されてなかったら遅いわ…

**デフォルトの名無しさん** · 2022/02/22(火) 23:07:19.97

>>844
> https://zenn.dev/nobonobo/articles/74808a8d5e6f1e
> Rob Pike氏はあらゆる既存のプログラミング言語が互いに発案した特徴を取り込みあって、
> あらゆる言語が同じような言語に向かっていることに異を唱え、そうではない言語を作ろうとして
> (略)
> Goのアイデンティティのひとつに「厳選された必要十分な機能セット」というものがあり、
> 過去ここを壊すような多くの提案には「No!」が突き付けられてきました。

Goはなんか言語としてのウリが弱くて
逆に言語としての機能不足を非難されたりするけど
ここにC++を持ってくると急に腑に落ちるな
ブヨブヨに肥大したC++の現状の惨状を見ると
そらロブの言いたいことも分かるってもんよ
Goに対する一部の批判はそら的外れってもんよ

**デフォルトの名無しさん** · 2022/02/22(火) 23:13:49.19

かなり後発のRustが先発言語たちから厳選された機能を洗練して上手く採り入れていって
純粋に言語としての比較ではGoを抜き去って行った感がある

**デフォルトの名無しさん** · 2022/02/22(火) 23:17:51.21

個人的に趣味でゲーム作ってて、
（仕事はPythonとかのスクリプト言語）
そのバックエンドに高速そうなGo使おうと思って勉強してるんだけど
そういうレベルの俺からするとRustはものすごく難しそうというか、厳しそうに思えてしまうんだよな
メモリリークって一番やりそうだもん

**デフォルトの名無しさん** · 2022/02/22(火) 23:25:51.36

>>851
何か勘違いしてない？
RustはC言語と違って
使われなくなった瞬間に自動的にメモリ解放してくれる言語

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

>>846
リフレクション以外もひっかかる。
試してから言え。

>>847
APIの秒間リクエスト処理数比較などもそうです。HTTPヘッダパース遅延評価機能を持つものと持たないもののベンチマーク等ではヘッダへのアクセス不要な簡易負荷で比較しているような状況になりがちです。特にデータベースアクセスなどを伴わないような場合だとその性能差は大きな差として現れます。

実際、Goのサードパーティライブラリ「fasthttp」はHTTPヘッダパース遅延評価機能を持っており、この場合ベンチマーク結果の数値は最速実装にかなり近づきます。しかし、HTTPヘッダは実用の現場の場合、評価しないわけにはいかないので実用上の性能は標準のnet/httpと大差ないということが実際にあり得ます。

**デフォルトの名無しさん** · 2022/02/23(水) 00:49:45.29

>>852
ガベージコレクションが無いって事しか知らない
違うのか
ってかスレチかもすまん

**デフォルトの名無しさん** · 2022/02/23(水) 06:07:59.41

>>854
Rustは使われなくなったら即座に自動的にメモリを解放してくれるため
ガベージコレクションを必要とせず速い

**デフォルトの名無しさん** · 2022/02/23(水) 07:24:21.07

>>842
nanoexpressなんて、HTTPもまともに実装してないウンコでドヤァってんじゃねーよハゲ(笑)しかも、star数3桁だぞｗ
https://www.techempower.comの不正だらけのベンチマークばっかり見てるから、(xxで最速）なんて恥ずかしい言葉が言える。
高機能なほかがサポートしてないフルスタックとHTTPの単純なGETだけ最速になるように調整(不正ではないが）したもの比べて、
中身を、全く見てないのに「なるほど君が色々分かってないのは分かった」なんてマウント取りたいだけだろお前？

普通に使用されてるもので選ぶのが当たり前、「nanoexpressが使えるレベルの仕上がりかどうかは知らんが」しらねーのかよハゲ！！
知らないのに語りすぎだろｗ

>>843
そのくせ次に出してくるのがjust-js/justかよｗｗｗ、just.cc, main.ccがJSに見える病ですか？just-jsのmarkdownにも書かれてるが
「non-async by default - can do blocking calls and not use the event loop」
おまえがさんざ言語の優位性として言ってるasyncすらデフォルトですらねーわｗｗ

なんでおまえ最速が好きなの？
「言語の特性なんてフレームワークの最適化の陰に隠れてほぼ見えない」何度も言ってるけど、明らかに高い同時並列接続はシングル
スレッドな言語では限界があり、レテンシーが極端に落ちるのどんなベンチマーク見てもその傾向。明らかに言語の傾向は出ています、
Rustがreq/secでスループットが「最も高い」という結果も、明らかに言語特性として高負荷でgcではないのでSTWが動かないという
言語の特性がキチンと出ています。
Goが非常に高い同時の並列接続数での、レテンシー速さが一部では、Rustよりも上回る場合があることが、ベンチマークで出ています。

「フレームワークの最適化の陰に隠れてほぼ見えない」見えないのではなく、おまえは見ることが出来ないだけ。だからjust-jsなんて
恥ずかし気もなく言い出せる。オープンソースなんだからコードぐらい追えよ？

**デフォルトの名無しさん** · 2022/02/23(水) 09:06:25.43

>>851
順当なら間違いなくJS/TS。
どのみちフロントエンドも必要だからJSは習熟するしかない。
それでバックエンドも出来るのだから、Python鯖が嫌ならJS鯖になる。

ただしJSは最速ではない。
(アーキは良いのでコンパイラが出てくれば最速になる可能性もあるが、5～10年は無いだろう）
だから順当には、JS鯖で負荷的に無理になったタイミングで移行を考えればいい。
そして個人レベルのゲーム鯖でこれが必要になる事はまずない。
もし仮に大当たりしてこうなっても、マネタイズがそれなりに出来ていれば、人を雇う事/外注も出来る。

もしコンピューターについて学びたいと思ってるのなら、順当にはCになる。
Rustを最初にやっても、色々意味が分からないはず。
一般的にはRustはC->C++->Rustと学ばないと良さを理解出来ないと言われていて、
Rustやるんだったら結局はCもやる事になるので、最初からCやっとけとなり、
「RustのおかげでRustよりもCを学ぶ連中の方が多くなってしまったではないか！！！！」とRust界隈で話題になってたのが2019だったと思う。
ただし最終的にRustを使うつもりならCの熟練者になる必要はない。ただ、知っておく必要はある。

この辺最近、こいつらはこの処理が何故重いのか全く理解出来てないんだな、と感じる事が多い。
これはコンピューターが複雑化した事もあるが、コンピューターの物理面を知らないで済ませようとしてるからだ。
（論理的なプログラミングに留めている。それを目指したのがJavaでもあるのだが）
だからベンチマークに頼らないといけなくなる。何故それが速いか遅いかを自分で判断出来る能力がないからだ。
だからこの辺、自分で判断出来る能力が欲しければCをやるべきだし、
とはいえ現実的にはフレームワークを使うわけで、フレームワークが最適化されてればそれで良し、駄目なら駄目、
と一生ベンチに頼るのもありだし、現実的にこれでも大した問題がないのも事実だろう。
この場合はCなんてやるだけ無駄、ってことになる。だからどういう能力が欲しいかを自分で考えるべきだね。

ちなみにRustもTSもNodeも無かった時代に同じ事を聞かれるとGoと答えただろう。
Go界隈の最大の問題はここで、最初に運良くブーストした？のに浸ってる。
今はもう違う事を認識出来てない。

**デフォルトの名無しさん** · 2022/02/23(水) 09:13:45.39

>>857
なぜ不便なCを勧めるのか理解できない
Cをやるくらいなら自動的にメモリを解放してくれるRustが楽で良い
スクリプト言語と似た感じで便利にプログラミングできる点も良い

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

Cもなんだけど、TSなんか特に。
マルチコア使うのがめちゃくちゃ下手な言語を、どうしてGoの対抗馬に持ってこれるの？
それら全ての言語を使ってないのでは？

nodeはnodeで便利だがGoと代替にはならんよ。
RustはRustで早いけどGoの代替には簡単にはならない。

**デフォルトの名無しさん** · 2022/02/23(水) 09:27:29.73

objective-c: objectiveが売りなんで頭にもってきたネーミング
c++: cのフリしつつ拡張するつもりの邪悪なネーミング
go: いちにーさんしーごーでシンプルにしーの後に躍り出る命名

**デフォルトの名無しさん** · 2022/02/23(水) 09:46:33.29

>>858
モロクソ書いてるだろ。3行しか読めない馬鹿か？

オレオレゲーム鯖立てるつもりならJS/TS、個人ゲーで負荷的に無理になることはまず無いし、フロントエンドでどのみち使うし。
コンピューターについて学ぶつもりならC、Rustを先にやったところでRustを使えるようにしかならない。
現段階でGoを選ぶ理由がない。Goを学ぶ事が目的ならどうぞだが。

**デフォルトの名無しさん** · 2022/02/23(水) 10:36:48.23

フロントエンドなら最近はWASMが増えてきて記述言語で一番適していて多数派がRustといった状況
もちろんサーバーサイドもRustで行ける
Goは巨大ランタイムのせいでWASMと相性がよくない

**デフォルトの名無しさん** · 2022/02/23(水) 11:07:50.59

>>862
そもそもGoは外部と相互運用する事を前提としてない言語だと思う。
少し互換性は失われるけど、isomorphicにしたいならTinyGoかなぁ。

**デフォルトの名無しさん** · 2022/02/23(水) 11:12:09.17

node-jsもjust-jsもJavaScriptの実行環境。just-jsでも
(async()=>{await Promise.all([...Array(10)].map(async(_,i)=>{just.print(i);}));})();
が普通に実行できる。並列かどうかは知らない。

**デフォルトの名無しさん** · 2022/02/23(水) 12:45:46.30

JSである以上、asyncなんて書いてもコールバックであり並列でもなければ、平行ですらありません。というかほんの数年前のJS使いなら
setTimeout()と書いて非同期タイマー呼び出しぐらい理解してるはずなんだが？今では、Nodeなら、nextTick()だろうけど
普通に実行できるとか、そりゃ言語仕様としてGoogleが携わってるV8使ってんだから出来るでしょうよｗ
just-jsおじさんｗ

**デフォルトの名無しさん** · 2022/02/23(水) 13:09:37.82

JavaScriptのアーキテクチャが良いと言うのもよくわからんよな。
シングルスレッドだし、別プロセスは前から立てれたが、別スレッドを満足に立てられるようになったのは最近。

epoll使ったイベントループの事を褒めるのであれば、それこそGoのselectの方が賢いんだし。

**デフォルトの名無しさん** · 2022/02/23(水) 14:41:59.08

一応書いておくけど何かをディスってるわけではないよ。訂正してるだけ。
V8はエンジン。言語仕様はES～。
>>856がnon-async by default - can do blocking calls and not use the event loopを引き合いに出していたので、asyncが使えることを示した。
並列になることを期待している可能性もあったが、コードを追って確認したわけではないので、単に「知らない」と書いた。

**デフォルトの名無しさん** · 2022/02/23(水) 15:37:31.02

>>866
JSが何故ここまで蔓延ってるのか理解出来ない奴がGoを使っているのは分かった。
844の記事にもあるが、「脳死」プログラマ向き言語がGoなのだろう。
>>828の
> Goは何も考えんでも
も同じ方向を示してる。

ただな、みんなよりマシな物を使いたがるんだから、広く使われている物にはそれなりの理由があるんだよ。
そういうのを考えたくない奴がGoを使ってて、その中で満足出来る人にとっては、小さく閉じた幸せな世界なのだろうけどさ。

>>867
> cat hello.js | just --
> non-async by default - can do blocking calls and not use the event loop
このjustってもしかして鯖ではなくコマンドラインから使う用？なら欲しいかも。
今はスクリプト業務でJSを使いたい場合、DevToolのコンソールで無理矢理やってるから。
(冷静に考えてみればNodeでも出来るはずだが、やろうとした事はなかったな…)

**デフォルトの名無しさん** · 2022/02/23(水) 15:51:46.27

>>868
just-jsのjustコマンドはnodejsのnodeコマンドに相当
consoleオブジェクトがないなど癖が強いので、一般利用なら個人的にはnodeでいいと思う