91(1): デフォルトの名無しさん [sage] 2019/11/23(土) 12:27:33.32 ID:1tA3t0n1(1/2) AAS
>>90
俺もvscodeの再起動で治ったけど、module周りはちょいちょい不具合でるなあ。
importの警告がいきなりでてきたり

142(1): デフォルトの名無しさん [sage] 2019/12/16(月) 01:56:43.58 ID:oBdKFKCd(1/2) AAS
取り出す数が配列の大きさと同じならシャッフルすれば良さそう
外部ﾘﾝｸ:golang.org

155(1): デフォルトの名無しさん [] 2019/12/19(木) 17:58:01.30 ID:E0rD8pHx(1/2) AAS
go testの内部処理を追ってどうぞ

外部ﾘﾝｸ[go]:go.googlesource.com

264(1): デフォルトの名無しさん [sage] 2020/02/03(月) 21:09:34.89 ID:gvFxJnFo(2/2) AAS
>>259
もちろんライブラリやフレームワークの学習は前提だけど、
仮にプログラミング初学者がGo勉強して基本的なCRUDアプリを作れるようになったとして仕事あるか？
極端な話、初学者がSpringとかASP.NETとかRailsとか覚えたら、
サーバーを起動する方法もその上でアプリを動かす方法も知らなくても仕事はいくらでもあるわけだよ
一方Go名指しの求人って、ほぼ例外なく、複数言語が使えてAWSもわかるフルスタックな人が期待されてると思うんだよな
もちろんGoが使えたらプログラミングの素質はあるだろうってことでの採用はありうけど、
そうやって入った環境では多分Goを書かせてはもらえないだろう

542(1): デフォルトの名無しさん [sage] 2020/05/17(日) 08:26:21.18 ID:8deP89zB(5/10) AAS
スレチになるのでちょっとだけ。
ブラウザが送るって言う解釈とはちょっと違うけどjavascriptで
fetch(url, {
method: 'POST',
headers:{"Content-Type": "application/json"},
body: JSON.stringify(data)
}).then(res => res.json()).then(function(resp) {
// ...
})
みたいにapplication/jsonでリクエストできます。

757(2): デフォルトの名無しさん [] 2020/10/28(水) 11:33:48.41 ID:Mf8tEr2f(1/2) AAS
C / C++ のプリプロセッサのマクロって
#define A(X, ...) X A(__VA_ARGS__)
みたいな再帰的な処理出来ないけど
この問題昔から指摘されてるのに
40年経っても1000年経っても解決されないよね
解決しようと思えば出来るのに C++ の拡張とかばっかりやってる

784(2): デフォルトの名無しさん [sage] 2020/11/01(日) 10:42:25.33 ID:0aiHjqpe(2/12) AAS
>>782
逆に言えばそれ以外の環境では他言語に劣るわけだろ。

元々は多分、命名からして、コルーチンをgoroutineで、ということなのだと思う。
コルーチンは通常は本体側と交代で間欠的に動作する前提で書かれているから、スレッドで切り離すことはしない。
ただ、もしそれが本体と並行に動作可能なら、スレッドとして切り離せば、
本体側が動いている間に次のyieldまで動作させられ、コルーチン部分の処理時間を見た目ゼロに出来る。
実際、大半のコルーチンはこれが可能なはずで、これまでは単に面倒/スレッド生成消滅のコストの為にそこまでやらなかっただけ。
だから、スレッドよりもっとお手軽で軽いgoroutineを用意すれば、という訳だ。

OSでの並行はprocessだが、multi processは重すぎるのでアプリ内processとしてthreadが出来た。
それと同様に、thread内の並行として、goroutineという、もう一段軽い物を用意した。

だからここまでのストーリーは辻褄が合っているとして、それがどこに適用出来るかだよ。
CPUが精々数個しかないそこら辺のPCだと、threadだけで埋めきれるので、普通にそれが最適解になる。
threadだけでは埋めきれないほどのCPUがあり、積極的に並行goroutineとして切り出してくれないといけない、
という、いわゆるメニーコアならGoの方が有利になる可能性があるけど、実際この場合はキャッシュコヒーレンシの問題が発生してくる。
勿論チャネルだし、後はオブジェクトの中身も含めてインミュータブル、
つまりErlangの世界まで行けたらこの辺の問題も無くなるけど、Goはそういう感じじゃないでしょ。
そもそもメニーコアの筆頭のXeonPiも死に体だし。(これはGoのせいではないけど)

785(1): デフォルトの名無しさん [sage] 2020/11/01(日) 10:42:50.15 ID:0aiHjqpe(3/12) AAS
だから、>>782の観点だけなら、
Goは素晴らしい実験用言語だったけど、現実的ではなかったね、で終わると思うよ。
実際、Goって使用者は増えてるのか？
Rustは前年度「Rust新規に始めた人数よりCを新規に始めた人数の方が多くなっちまったよオイオイ」とか話題になっていたが。

JSはプログラマに、I/Oを明示的に切り離して高速化することを求め、(実際あの非同期は壮絶にウザイが)現実的にはものすごく機能してる。
Goはプログラマに、並行可能な部分を積極的に切り離すことにより超並行によって高速化を目指している、と捕らえることは出来るが、
実際これは全く上手く行ってないし、今後とも上手く行く気配もないでしょ。
一時期、CUDAよりもXeonPiだ、という時期もあったはずだけど、なんか話題はCUDAに戻ってるしさ。

788(1): デフォルトの名無しさん [sage] 2020/11/01(日) 11:11:59.03 ID:MfA1nG9+(3/13) AAS
yieldが必要なコルーチンとは全く関係なく、昔で言うグリーンスレッドを超低コストで実現してるという方が正しい。
エアプしてる時間があったらスケジューラの動きとか調べてみたらいいよ。

791(2): デフォルトの名無しさん [sage] 2020/11/01(日) 11:35:22.25 ID:MfA1nG9+(5/13) AAS
メインスレッドすらグリーンスレッドで、数本立ってるネイティブスレッド上でタスクを持ち回りで実行してるから、await asyncは自動的にされてると思って良いぐらい。