Go language part 5 YouTube動画>1本 ->画像>7枚

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

公式
https://golang.org

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

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

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


※前スレ
Go language part 4
http://2chb.net/r/tech/1605467680/

公式
https://golang.org

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

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

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

あ、これ2のテンプレじゃないのか

>>992（前スレ）
読んだ。で、やっぱり奇妙なんだけど、多分オーバーヘッドはないと思うよ。

一般的にはガードページなんて必要なくて、コピーオンライトと同じで、
ページ境界を跨いだ場合はハードウェアで検出出来るから、まず普通はそれを使う。
この場合は自前でのチェックは必要ない（ソフトウェアには必要ない）ので、オーバーヘッドはない。
だからGoの当初の初期スタックサイズが4kだったのは非常に納得出来た。ここまではいい。

これを小さくするならハードウェアのサポート無しになるから当然自前でチェックするしかないが、この場合、
・2kも大きすぎ。自分でやるならRustのように64Bytesからとか、4kに拘らず凄く小さいスタックサイズから可能だし、普通はそうする。
・そもそも必要スタックサイズを予見出来ない。というか出来るならコンパイル時に確定的に割り当てれば済んでる。
であって、Rustの実装は非常に納得出来るのだけど、Goのは若干意味不明なんだよ。
（ただまあ何かしら理由はあると思うけど）

2kとかいう、4kに拘ったサイズになってるんだから、多分何かしらハードウェアのサポートを受けてて、
自前ではスタックサイズのチェックはしてないと思うよ。（つまりオーバーヘッドがない）
可能性があるのは、2kをはみ出る時には4k境界を跨ぐようにして（つまりまずは上側を割り当てる）
はみ出た時に2kずらしていくとかだけど。
ただこの方式の場合、初期アロケーションだけは4kでされてしまうので、957のベンチでは40MB越えないとおかしくて、矛盾してる。
だから正直よく分からないが、
多分オーバーヘッドのない方式で実装してて、だから2kとかいう中途半端な巨大サイズになってるのではないかと思う。

>>998（前スレ)
分かりやすい説明ありがとう。発想は面白いね。
確かにその方式だと死蔵メモリは最小限に留められ、Goの問題は解決されてるはずだね。

>>986(前スレ)
998の通りだと、外部からのプリエンプションではなく、
コルーチンが処理を(自発的に)返してくるから、その単位での切換だろう。
まあこれでも現実的には問題ない気はする。

ちなみに前スレ1000と同じく、1桁少ない1000スレッドで同じPCでgoを測ると
$ go version
go version go1.13.8 linux/amd64
$ go build main.go && ./t ./main
real 12.02s
user 0.91s
sys 0.22s
rss 3808k
$
やはり4Mを超えない(rssでいいの？とは思うけど)

推奨NGWord
正規表現で「.{50}」を設定
長文を排除できます

>>992（前スレ）
訂正。他も色々漁って、やっぱりオーバーヘッドはあると思えてきた。
ただし多分0～4cycle/関数呼び出し程度だね。

主に読んだのは以下とか。
https://github.com/tinygo-org/tinygo/issues/2000
https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast
https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite

・当初は8kだったが、もっとでかくしろという要求が多かった
・1kに出来てる実装もあるが、こける事もあるから2kがデフォになってる
・同じ図が説明に使われてて、どうやら最初からこの方針らしい

本人達が「チェックしてる」って言うんだからやっぱりそうなんだろう。
一番ありそうな実装は、呼ばれた関数側で最初にチェックする方法で、
つまりローカル変数をスタックに確保するためにスタックポインタからサイズを引く時にチェックする。
これだと、 mov, (sub,) xor, and, jne の追加4命令で(subはチェック無しでも必要）
主にINTパイプで最悪で4cycle、大体の場合はこのあとのLSパイプ(スタック上へのレジスタ待避）に隠れて見えなくなるのではないかと。
だから関数呼び出し毎に0～4cycのペナルティになる。
ただし、速くなる事はないし、隠れると言っても演算リソースは消費するので、
ハイパースレッディングの場合に相手側のCPUの速度が落ちるのは否めないが。

2k以下にもやれば出来るのだろうけど、やる気がないだけだね。
だから2kで問題なら、コンパイラをいじれば何とかなるのだろうけど、
そこまでやるくらいならRustの方が断然いいね。(後発だから当たり前だけど)

関数呼び出しのオーバーヘッドだけど、高階関数らしい高階関数も無いしそういうややこしいことはジェネレーター使う文化だと思ってるな。Genericsが本流になってきたらどうする気だろうもも思ってる。
なお、比較する関数程度の関数はインライン化される。
https://github.com/golang/go/wiki/CompilerOptimizations

>>9
> 高階関数らしい高階関数も無いし
いや高階関数は普通に出来る。
https://go-tour-jp.appspot.com/moretypes/25
標準やフレームワークにそれを活用する文化がない、という主張なら俺はその辺は知らん。

>>10
できるけど、Goではやらんのよ。
凄く纏まってる。
https://zenn.dev/nobonobo/articles/e0af4e8afc6c38b42ae1

>>6
自己レスです。
Goは1.4からamd64だとスタック2k
https://github.com/golang/go/issues/7514
今回試した1.13.8だと当該コードがCからgoに変わったりして跡形もなかったが、_StackMin = 2048はそのままだった
https://github.com/golang/go/blob/go1.13.8/src/runtime/stack.go
つまり2Mであれば残り1.8Mということで矛盾はない

>>12
1000個立ち上げなんて1桁減らして測定してるからメモリ使用量がわかりにくいような
素直に1万個と10万個で調べて差を見れば1個あたりがはっきりするような

>>13
時間かかるのが嫌で減らしただけです。。。

ちなみに後ろにウェイト入れて、cat /proc/[pid]/statusした結果
VmHWM: 3296 kB
VmRSS: 3296 kB
VmSwap: 0 kB
なので、rssだけでいいと思います。

>>11
> 結局のところ素直にforループを書くのがGoには適していて、
> 汎用の型に適用可能な高階関数を実装しようとするのはミスマッチ
これってforEachを実装しようとするのが間違いって事？
或いはmapに高階関数を食わせるのを嫌ってるのか？
いずれにしても、やりたきゃやれよ、だと思うが。

オレオレコーディングルール集だが、全般的に現状肯定的なので、
目指すコーディングではなく、今のGoコンパイラ/ランタイム向けのTips集になってる。
これがどれくらい賛同されるのか不明だけど、革新/改革派からは気に入らない内容だろうよ。
Python出身のようだから、この辺C系の「何でもやっていいけど、結果責任は取れ」文化とは根本的に違うのだろう。
一種類のコードになる事を良しとしてる。

> goroutiineのスケジューラはもちろん依頼処理コストが大きい場合をフォーカスしてチューニングされています。
> ひとつのgoroutineがCPUを占有しすぎないように分散してくれる仕組みがありますが、
> 小さすぎる処理コストをまとめるのは実装者の責任で行わなくてはなりません。
> 小さすぎる処理を頻繁に繰り返すだけであればシングルスレッドの方が速い結果が出るのは当たり前なのです。
これとか、1,000,000goroutine全否定だよね。俺は
Go信者：1,000,000goroutineでも軽いし速い←嘘つくな
GoUser：遅いけど1,000,000goroutineで書きたいんだよ←うむ、遅いと認めるならよろしい。しかし速くなる努力はしたまえ

> Goはデバッガビリティのために末尾再帰最適化をあえて実装していません。
いや怠慢でしかないだろ。再帰がデバッグしづらいとか聞いた事無いわ。

ちな、
> 自作ライブラリの利用方法をメソッドチェインで作ろうとする
考えた事無かったけど、try-catchのメリットってメソッドチェインできることか。
なるほどだからろくにメソッドチェイン出来ないPHPだと何ら意義を感じ取れなかったわけだ、納得。

>>15
Goと同じくtry-catchの無いRustはメソッドチェーンが基本の言語だぜ
関数の返り値が基本的にenumとなってエラーも正常値もメソッドチェーンで処理できるようになってる

>>14
もしかして俺が前スレ962で単純に40MB足してたのが気になってたのなら申し訳ない。
あれは足しすぎだった。RSSの意味は以下。
https://stackoverflow.com/questions/7880784/what-is-rss-and-vsz-in-linux-memory-management
十分なメモリがある状況で普通に実行させた直後（スワップされてない状況）なら、RSSで問題ない。（はず）

以下は前スレ992内にある図だが
https://commons.wikimedia.org/wiki/File:Table_of_x86_Registers_svg.svg
これ全部を待避するのに1kB程度かかるらしく（真面目に数えれば正確な数値は出せるが、やる気無し）
この分をOS側が待避するので、単純に言えばスレッド数*1kB程OS側のメモリを食ってる。
これがgoroutineだと必要ない(Goランタイム管轄で待避で、RSSに計上されてる）ので文句付けられてる。

だから公平に見るなら、goroutineはRSSそのままで良く、OSのthreadを使うならスレッド数*1KB程度追加かと。
(40MBはスレッド数*4kBにしてるので、多すぎ。
アクセスのない、単なる待避領域なので、ページ単位である必要はない。）


そして関数呼び出しのオーバーヘッドについてはそこにモロに書いてあるな。(GitHub上ソースの17行目～60行目)
0～4Cycleのオーバーヘッドになる。
方式としては、スタックの底に96Bytes(=40+56)の領域があらかじめ確保してあって、
これらはメモリが足りない時に呼ばれるdeferproc()とmorestack()に必要なスタックサイズなのだが、
逆に言えば96Bytes以下のスタックしか使わない関数ならスタックポインタがそこを越えてなければ問題ないわけで、
以下チェックを通してる。(guardがスタック満タン-96Bytesのアドレスを示してる)
> CMPQ guard, SP
> JHI 3(PC)
> MOVQ m->morearg, $(argsize << 32)
> CALL morestack(SB)
まあスタック増加がなければINT/BR/NOP/NOPなので、オーバーヘッドは通常1か2Cycleじゃないかと思うけども。

>>12
ちなみにコードが素晴らしくメンテされてれば、

_StackMin = 1024

にするだけで、スタックサイズが1kBになるような気もします。

>>15
そもそも革新、改革がしたいならGoじゃない言語でやれば良いんよ。ひたすらに後方互換を維持してんだし。

1種類のコードになることを良しとしてるのは当初からよ。そうでなければ、gofmtが一切のオプションを持たないはずがない。

多数のgoroutine全否定ではなかろうに。
遅いように書いたgoroutineは遅いとしか言ってない。

ちなみに末尾再起はgdbなんかでデバッグしてるとデバッガビリティ低いと思うよ。俺もそう思う。
普通はデバッグビルドだと末尾再起無効では？cppなんかでも。

>>19
いやあれは「べからず集」なのだから否定だと思うぞ。
まあいいが。

> 普通はデバッグビルドだと末尾再起無効では？cppなんかでも。
そもそもデバッグビルドなら『全ての』最適化は無効だ。そしてその状態で全てのデバッグを行う。
それでリリースビルドでは一発で動く、というかデバッグしないのが基本だ。
（同じ出力を生成する事だけを確認する）
「デバッグビルドでは動くのですが、リリースビルドでは動きません。これってコンパイラのバグですよね？」は初心者あるあるだが、死ねでいい。

リリースビルドでデバッグすると、ブレークポイントも当たらなかったりで、ろくな事はない。
深い再帰とかが例えば演算系なら、毎回再帰前にprintfで全部の値をログに出し、
リリースビルドで動かした出力とdiffを取り、完全一致になってなければバグとして、あくまでデバッグビルドでデバッグする。
そのファイルが数GBになって、普通のdiffでは無理になったら、完全一致専用のdiffを手作りする。
実は浮動小数点だと完全一致はしないが、それなら誤差範囲を指定したスクリプトを書いて比較だ。
というのが俺流で、つまり別の戦術で回避済みだから、
リリースビルドでどんな最適化がされてても、コンパイラがバグってない限り関係ないね。
そしてコンパイラなんてバグってない。俺は誰でも書いてるようなコードしか書かないし。

それ、リリースビルドでデバッグしてる事が問題なのでは？
(まあ気持ちは分かるけども。俺も最初はそうしてて、駄目だったので上記になってる)

>>16
以下9章だけは読んだ。
https://doc.rust-jp.rs/book-ja/ch09-00-error-handling.html

俺はこれで全く問題ないけども、try-catch派は多分文句を言うような気はする。
あと、これは型をResultで統一すればどの言語でも出来るので、言語と言うよりはフレームワークの設計なのだろう。
(フレームワークを跨いでも統一してる方がいいから、言語としてこれだ！というのは意味はあるが）

ただ、エラー処理って方式が統一されてる事が重要だから、今更ではある。
そんな事よりGoはRustのasyncをパクるべきだろう。
コルーチンみたいな名前で実はスレッドではないか！という批判が無くなる。
実は当初goroutineと名付けた時に欲しかったのは、これだったんじゃね？とも思う。
yieldさえあればあっさり出来るのだろうけど。(無くても無理矢理やれば出来るが）
つか、無い理由は何なんですかねこれ？

template feature実装したgolangのstable公開3月だっけか
作者がc++嫌いだからのgoなのに偉大なるc++への一歩を踏み出そうとしてるのは皮肉な事だが
ライブラリ等もかなり便利になるのではないかとかなり楽しみ(´・ω・｀)

>>17 >18
むしろ前スレ957のベンチ(元記事)では、

"In particular, 10k threads with default stack sizes need about 40mb of page tables to map virtual memory."

と訂正しているのだから、前スレ962の計算で40MB足してるのはおかしくない。
ただ、>>4で再び「957のベンチでは40MB越えないとおかしくて、矛盾してる」と言ってるのが、普通に考えるとRSS対象なので、スレッド数を10kから1kにした俺版でも前スレ1000のC++版との対比する意味もあり、改めてgo版の結果を同じ条件で出した(>>6)だけ。
結論は同様にRSSは4MBを超えないので、仮想メモリ側にあるという元記事の主張で正しいようにも見える。
しかし、go処理系が不明な元記事と違い、自分でやっていれば実際バージョンは分かるわけで、そこが分かればスタックサイズはソースを見れば一目瞭然ということで経緯と一緒に調べたのが、>>12で結論としては2Kだったということ。
すると元記事の推測と自分の計測結果には矛盾があり、2KBが仮想メモリにあるかどうかを明確にする必要が出たため、>>14で/procに頼った。
結論は仮想メモリ(swap)使ってないよって話だったので、少なくとも俺の環境では元記事とは違いRSSでいいという結論が出て、>12の結論とも整合が取れた。

別にdistro標準(ubuntu 20.04)のgo処理系を使っているので、ソースを引っ張ってくれば簡単に１KBに変更は出来るか確認出来ると思うけど、面倒なのでそこまではしない。

反論はそこだけ？

>>21
これだけ指摘されて、まだスレッドだと思ってるのは少ないのでは？

一般には
coroutine + thread -> goroutine, async/await
という認識の人が多数だと思う

このasyncおじさんは何も分かってないと思う・・・
nodeでasync/awaitが通るのは、シングルスレッドですべてのメモリーが一緒のためで、Goのようにgoroutineで実際に
割り当てられているCPUやスレッドが分からないようにあえてしている言語で、asyncなんて導入するわけない。
async/awaitがある言語でそれがThreadを混ぜ込める言語もあるが、それだってI/Oをブロックしている処理の終わりに
ただ同じスレッドを再割り当てするだけ。スレッド境界を越えてメモリーコピーあるいは同期なんてしてたら破綻する
async/awaitのもとになるような、多くのスクリプト言語でyield、つまりジェネレータの重要なユースケースは、I/Oブロックの
待ちで違う処理を行うことだが、それはI/Oバウンドな待ちでしか処理が切り替わらないことを意味する。

async/await,そしてyieldが唯一優れているのは、Goでいうchannelのclose処理が要らないことだけ。

他は全部劣っているし、CPUバウンドでは切り替わらないし、async/awaitなんていうキーワードがプログラミングがしやすいか
といえば全然そんなことは無く、async/awaitで書かれたコードと、完全同期の一直線で進むプログラミングでは、互換性に
乏しいライブラリばかりができる。async前提で作られたコードは同期プログラミングでは使えなかったり、同期プログラミングで
作られたライブラリは処理がI/O待ちになっても、asyncが入っていないため非同期では効率が劣る。
決定的には、並列性が大きく劣っている事は言うまでもない。
もちろんこれは速度などという効率の指標ではなく、理論上はCPUコア数=スレッド数で、他はすべて非同期にしたほうが
速いのは、何も考えずとも当たり前。（無駄なコンテキストスイッチや同期処理が発生しないから）

「当初欲しかったのはこれじゃね？」なんていう超ド素人の勝手な想像と思い込み、調べもしない無知でこんなところで
ダベっていてもまったく意味ない。
Go言語の作者の一人であるRob Pike氏が「OSスレッドではなく、ユーザー空間スレッド」「メモリ使用量がOSスレッドに
対して、500倍ほど有利」「OSコンテキストスイッチよりも有利」といい、Cの作者として有名な、Kenneth Thompsonが
「C++が嫌いだということで意気投合」「いかなる理由があっても言語にゴミを入れません」と語っているように
I/O非同期なんていう半端な偽物は、眼中にない中で、まさしくasync/awaitは１つの利点だけの無用な長物であり
プログラミングを複雑にするだけで、つい最近まで総称型さえも、強烈に拒んでいた保守的で長く使えるよう言語仕様を
守り続ける言語に入るわけない。
そんなにやりたかったらお前がforkしてやれ、じゃなきゃGithubでIssueでも投下してこい。それすら出来ないなら
お前は不当に他言語を卑下してる卑怯者だぜ。どうせボコボコにされる

>>27
流石にその理解はヤバいぞ
asyncおじさんをバカにしてる場合じゃない

>>27
その主張は間違い
例えば現実にある反例として
RustでもGoと同じくワークスティーリングをするM:Nモデルで非同期タスクが動きasync/awaitが導入されている

>>28
あまりにも偏った思い込みと勘違いが激しすぎる

Rustでもできる、は聞き飽きたんだが、Rust話がしたいのか？
Rustの話はRustスレで聞きたいんだが、とうしてRustスレではN:Mグリーンスレッドの優位性の話してないの？

実際Rustでtokioをランタイムとして使ってみたけど、思ったより書き味が良くないしな。
Goのサクッと書いてサクッと、しかも依存の無い、クロスビルドと比べたら相当面倒。
しかもcopreemptiveじゃん。
色々な意味でGoの相手ではない。

>>31
どちらもメリット・デメリットあるからそれは言いすぎでしょ
しかも肝心な速度でGoが負けているのだから用途ごとに使い分ければよい話

>>32
その通り、メリデメある、使い分ければ良い→その時点で「相手ではない」と言ってる。
ずっと言ってるけど、1番2番論争は無意味なんよ。
速度ばかりが大切な訳でも無いんだし。

これ貼っとくわ。
https://thenewstack.io/enough-with-the-zero-sum-game-of-rust-vs-go/

>>23
いや、元記事もそこはちょっと間違ってる。
とはいえ本質は「RSSで全部計上されてるか？」なので大筋は問題ないが。

RSSは「ユーザープロセス空間で、メモリ上に配置されてる物」なので、元記事の通り、スワップされてれば計上されないが、
そもそもこの計測方法では普通はスワップされない。
ただ、考慮してるのは"Thread bookkeeping"であって、
kernel(OS)がこれに使うメモリがRSSに計上されてないから問題だ、というのはあってる。
だから俺はそれを足してる。

Goでは、実はこの部分も売りにしてて、以下は8の2つ目だが
> https://dave.cheney.net/2014/06/07/five-things-that-make-go-fast
> The switch between goroutines only happens at well defined points, when an explicit call is made to the Go runtime scheduler.
> The compiler knows the registers which are in use and saves them automatically.
むやみにプリエンプトせず、スイッチングポイントを考えて、必要ないレジスタは待避してない。
考えられるのは
・そもそもセグメントレジスタなんて普通は使わないから待避する必要がない。（レガシー）
・関数の途中でプリエンプトせず、関数呼び出し単位でスイッチなら、
呼び出し規約上の破壊レジスタ(a,b,c,d)は待避する必要がない。
・そのgoroutineの処理にSSE命令が存在しなければ、SSE系レジスタを待避する必要がない。FPU(x87)も同様。
とかになる。
(なおこれを突き詰めたらRustの「コルーチンのyieldでスイッチすれば、スタックも要らん」になる)
そして現実的に多くの場合SSE系命令は不要で、必要待避領域は多分半分以下にはなるので、（面倒だから数えてないが）
Goは半分以下にする努力してるのにRSSだと計上され、OS任せだと丸々必要なのにRSSには計上されないので、
当然の如く突っ込まれる事になる。
（その他細かいフラグ類は沢山あるだろうけど、多くはbit単位であり容量としてはゴミなので無視)

だから最小フットプリントなら1/3程度で、
あまり余計なことしなければスイッチングコストも1/3程度としていいのではないかと。
逆に言えば、threadよりも3倍程度のgoroutineで済むのなら、速くてコードも綺麗だが、
それ以上なら遅くなるという事。

>>27,28
どこから突っ込めば状態なので、最初の部分だけ。

> nodeでasync/awaitが通るのは、シングルスレッドですべてのメモリーが一緒のためで、
これは多分プロセスとスレッドの区別が出来てない。
プロセスは別空間だがスレッドは同一空間で、逆に言えばその程度の違いしかないが。
> e.g. Linux doesn’t distinguish between threads and processes and both are called tasks.
> https://codeburst.io/why-goroutines-are-not-lightweight-threads-7c460c1f155f#396b

> Goのようにgoroutineで実際に割り当てられているCPUやスレッドが分からないようにあえてしている言語で
一般的に非同期の場合はどのCPUにどの順番で処理されても動くように組む必要があり、
実際にC#でもそう。
JSもそう。(ただしJSのプログラミングモデルからは見えない)
この発言は上記の勘違い、（とは言っても普通の勘違いとは逆で）
Goはgoroutineがそれぞれ「別空間」で動いていると勘違いしてるからだと思うのだが、それはない。
重ならないようにコンパイラが割り当ててくれてるだけで、同一空間だ。

>>35
元記事はGoのバージョンが確認できず、goroutine当たりのスタックサイズは不明なため、断定してないだけで、時期を考えると2KBだから恐らくRSSだろうとは思っている(明確に言えるのは自分で計測した方だけ)。
カーネルで管理されているメモリは4KB/2KBとかじゃないと思うし、数字としてはどこにも表れないので、それは差があるとだけしておけばいい。
元記事の筆者が加算しているのはgoroutineスタック分以外は全てRSSに入る前提の元、未計測の仮想メモリには最大40MB入ることがあるはずという計算。

> Goでは、実はこの部分も売りにしてて、以下は8の2つ目だが...コルーチンのyieldでスイッチ...
Goの「スイッチングポイント」は現状誰も明示しておらず、保存しているものも、どこなのかも、推測の範疇を出ておらず、議論は無意味。

>>33
Rustはどう見てもGoの相手でしょう
2019年に非同期本対応のRustが誕生するまでは明らかにGoの独壇場だった
今はRustがGoと同様にN:M非同期タスクを実現してGoのようにチャネルを使って全く同じ動作が可能となった上でasync/awaitも対応
そしてRustのほうが速いのだから比較対象として話が出るのは仕方ない

>>37
> goroutineスタック分以外は全てRSSに入る前提の元
いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
そしてスワップアウトは「必要ない限りやらない」のが基本だから普通にベンチマークしてれば問題ない。
(同時にメモリイーターなプロセスを走らせておかないと速攻スワップアウトなんてされない）

> カーネルで管理されているメモリは4KB/2KBとかじゃないと思うし
『プロセス』を管理するために必要なカーネル側のメモリは4kBとかではない。
PTE(PageTableEntry=MMUの中身データ）だけでもメモリ128MBなら4k/pageだと128kB(=32kentry*4Bytes)必要になる。
（ただしラージページ《2M/page》なら256Bytesで済むが)
だから『プロセス』は軽くない。

一方、『スレッド』についてはこの部分は必要なく、追加のスレッドによって増えるカーネル側メモリは、
スレッド管理分のフラグ類の数Bytesと、待避領域の1kBだけで済むはず。
4k/threadの見積もりは多すぎ。(多分)

> Goの「スイッチングポイント」は現状誰も明示しておらず、保存しているものも、どこなのかも、推測の範疇を出ておらず、議論は無意味。
それはそうだが、多分合ってると思うよ。ただ、
> どこなのかも、
これについては間違いなくユーザー空間のはずだよ。カーネル側に保存する意味がないし、余計に遅くなる。
誤解無いようにくどいが言っておくと、
OSの管轄でマシンスレッドからプリエンプトする場合、各マシンスレッドの状態待避はカーネルがカーネル空間側に行う。
Goランタイムの管轄でgoroutineを切り替える場合、各goroutineの状態待避はGoランタイムがユーザー空間側に行う。
(まさかGoランタイムってカーネルモードで動いてたりする？それなら話は違ってくるが)

>>38
明らかにユースケースが違うし、コンビニに行くのにF1乗るみたいな話だぞそれ。
スクーター以上のそれなりに早い二輪車が欲しいんだよ。

>>39
違うのでは？
ユーザスレッドでもカーネルスレッドでも動いてる。
普段はgoroutineはユーザ空間で動いてるが、その上でカーネルスレッド毎に偏りがあったらスティールするでしょ。

>>41
君は27？

> 普段はgoroutineはユーザ空間で動いてるが、その上でカーネルスレッド毎に偏りがあったらスティールするでしょ。
これは明らかに分かってない奴の言い分だが。

>>39
> > goroutineスタック分以外は全てRSSに入る前提の元
> いやgoroutineスタック分はユーザー空間だからスワップアウトされてない限りRSSには計上される。
だから元記事の筆者がそう考えているという話で、これは俺の環境とは違うからRSSなのか仮想メモリなのか断定できないと言ってるだけ。
よく読んで欲しい。

> > どこなのかも、
> これについては間違いなくユーザー空間のはずだよ。カーネル側に保存する意味がないし、余計に遅くなる。
アドレス空間の話ではなく、スイッチングポイントは典型的にはyield直前とかのはずなんだけど、そこ実際にどこだか誰も調べてないよね？と言ってる。
多分とか入るのに他所様のお庭と比較するのはおこがましい。

>>43
> だから元記事の筆者がそう考えているという話で
それはそうだが、俺らはそのデータを見てる立場なので、それが正しいかをチェックする事になるだろ。
これも誤解無いように言っておくと、
元記事の作者は、(彼的には)正しいと思ってるからそう書いている。俺から見てもRSSで問題なく、正しくデータは取れてると思う。
(ただし考察の一部に微妙に間違いが含まれているので、その部分を指摘してるが、大局に影響はない)
ちなみに君のデータも、正しく取れてて、問題ないように見える。
RSSでいいのか心配のようなので、こちらからも「RSSで問題ない」との意見を付けた。

> アドレス空間の話ではなく
上記RSSの話に引っ張られてしまって勘違いした。すまん。


これ以上進めるには精度が足りないというのは了解した。
俺的にはこの程度の精度でも前進して構わないというノリなのだが、
もっと厳密に正確に確認していきたい人だとストレスが溜まるとは思う。
掘り下げたい人がいれば、12みたいにソースの該当箇所を提示してくれれば、確認の手伝いくらいはする。

>>42
24とか。
どう違うん？

>>44
了解。すまんがこれ以上は俺はやらない。main.goのスレッド数に対するRSSのグラフ(svg)だけ貼っとく。
https://jsfiddle.net/9b0kujsL/
そのうち消えると思うけど、ここには貼れないサイズだったので仕方ない。

>>38
Rustのビルド速度は凄まじく遅いだろ。競合にならん。

Rust信者はgoスレに書き込む前に"Build fast, reliable, and efficient software at scale"を100万回唱えろ。

昔は遅かった
今は特に問題ない

今も結構遅いけどな…ま、気にする必要はないが

気になるだろ…

>>46
うっかりスレッドって書いちゃったけどgoroutineの間違いです(グラフも)

>>46
了解。では感想だけ。
今時はグラフはsvgで作るのかーとちょっと驚いた。ググったら結構あるみたいだけどさ。まあそれはさておき、

> f(x) = 2.6396 x + 1186.8
完全にリニアで、2kBはスタックとして、残り0.6はちと多い。G構造体は以下(前スレ805内のリンク内)
https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L403-L498
にあるが、51個もメンバがある巨大構造体で、こんなに必要なのか？とは思う。
まあ「税金」として0.6kBかかるのなら、無理にスタックを1kBにケチる意味はないから、デフォ2kBは妥当な判断に見える。
これについてはlinuxと比較しないと妥当性は検討出来ないが、

妥当性を検討するためにはLinuxを見る必要がある。これは同様に(前スレ805内の記事11章)以下にある。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/sched.h#n657
見た目goよりでかいし、ifdefが多すぎて数える気にすらならない。

とはいえlinuxのはプロセスと共用だし、そもそも大量に起動する用途向けではないので多少大きくても問題ない。
おそらくあれこれ機能を足していくうちに肥大化したのだろうとは思う。
ただこれに対抗するならgoのはでかすぎ。
10倍起動するつもりなら、サイズは1/10に抑えないと並べない。(今は多分数分の一程度)
JSはここら辺はただのFIFOで、1ジョブ当たりポインタ数個分で実装出来る程度の機能しかない。だから速い。
Goのも既に肥大化しすぎてる。
ちょっと考えてみ？600Bytes=ポインタ*75個分で、一体何の制御をしたらそんなに必要なのかと。
51個のメンバがある＝起動/停止時にその51個のメンバをチェック/更新するコードを通す事になる
＝起動/停止時に「税金」的に数百サイクルは必要、となる。

ここら辺はやっぱりチューニングが狂ってる。
『軽量』OSじゃないといけないんだけど、
オレオレOS作りたい奴がランタイム作ってて機能が肥大化してるのではないかと。
スケジューラが売りのようだが、ベアメタルではなくOS上で動かすのだから、無くてもOS側がそれなりにはやってくれる。
それをスケジューラ作りたいだけの奴が作っただけのように見える。
アプリを速くしたいのではなく、スケジューラを作り込みたいだけだから、チューニングが狂う。
この辺、JSはエンジン内の仕組みなんて誰も評価しないでしょ。
速いか遅いかだけ。だからチューニングが狂わない。

OSがそれなりにさばかないよ。グリーンスレッドの価値を全否定だな。

JSのエンジン、定期的に話題になるだろ。
V8もTurbofan+Ignitionに変わってすぐはソース読んでたぞ。

https://jsfiddle.net/z1bvwt3L/1/
1:1スレッドでのC++/Rustの結果も併記した(Rustのバージョンは1.58.1)
標準機能で記述する縛りでロジックだけ同じにすると現状ではこうだということ
M:NをC++/Rustで自前準備すれば別の比較ができるかもね

あ、C++はgcc9.3、C++14で記述。

>>55
全く意味のない比較になっている
Goではm:nグリーンスレッド利用
C++とRusyでは1:1つまりOSスレッド利用
ちゃんと3者ともにm:nグリーンスレッド利用で比較しなさい

>>57
「標準機能で記述する縛りでロジックだけ同じ」という条件だとそれは無理な相談
むしろm:nでないとならない条件では成立しない

> ちゃんと3者ともにm:nグリーンスレッド利用で比較しなさい
上記条件にはならないが、どうしてもやりたければお前がやれ
C++は20を使えば標準機能だけで実装できるはず
Rustが標準機能だけで実装可能かは知らない

Rustの標準ライブラリはunsafeのオンパレードだなｗ

誤爆

ライブラリもOS機能を使うならunsafeも致し方ないのではないだろうか、と誤爆にレス

興味があるならどこの誤爆かだけ書いておく
http://2chb.net/r/tech/1638086359/447

>>58
わざわざGoスレでくだ巻いてる方がやれよ。
できなけりゃGoを使うよ。

>>63
俺はGoのパフォーマンス測定をGoスレで尋ねてその後も調査してるだけだけ(すでに終了は宣言した)
ただまだ妥当性がどうのと言ってる人がいるから、とりあえず恐らく同じくデフォルトが通常2KなOSスレッドスタックを使ったRustとC++の結果を貼っただけ
結果は1:1でthreadが動いてるRust/C++の完敗だが、ロジック同程度で標準機能だけという条件なら仕方ないねって話をしただけだぞ
まだ文句があるなら自分でやれと言って何が悪い
お前がGoを使おうと何を使おうと俺はどうでもいい

>>64
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することは無意味
比較したいならばC++&Rust側でもm:nでやりなさい

>>64
勝ち負けを認めさせたいから言ったのでは無く、それ以上はRustスレでやれと言ってる。

>>66
俺に言うなよ
>>65に言え

C++スレでもRustスレでもここでも同じで無意味
m:nとなるgoroutineを用いたGoと
1:1となるOSスレッドだけを用いたC++&Rustを比較することはナンセンス

thread単品で制御できないgoじゃこういう計測ができないのも理解できないとは・・・
何しにgoスレに来てるのやら

C++とRustでもOSスレッドではなくm:nグリーンスレッドを使えばよいだけだろ

>>64
妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
君のデータは妥当だし正確だと思うよ。


>>54
> OSがそれなりにさばかないよ。
GOMAXPROCSがCore数と同じ事に拘ってるからだよ。だから完全な（＝高価な）スケジューリングが必要になる。
Core数よりも多いMにして、優先順位を低く設定しておけば、CPUが空いてればそのMで実行される。（これはOSがやってくれる）
これなら今のランタイムがやってるようなスケジューリング管理なんて丸々必要なくなる。
C#がこれで、空きCPUがあれば新規スレッドをプールに追加して、実行させるだけでしょ。
(ただしGoの場合は同期チャネルなので一々止まりまくり、この場合は確かにそのままOSに任せても駄目で、
Rustみたいに同期受信待ちをコルーチン化して送信時に受信側goroutineのコードを直接実行する実装の方が向いてるが、
《だからthreadなのにコルーチンと名付けたのか？》
ここら辺はジョブの重さと同期チャネル量の兼ね合いで、第一選択肢として力業（スケジューラ）で解決、という判断は妥当ではあるが)

> グリーンスレッドの価値を全否定だな。
「コンテキストスイッチのオーバーヘッドを減らす」Goより、
「コンテキストスイッチ自体を無くす」非同期の方が原理的に速い。
ただし非同期はソースがうざかったが、async文法でまあ何とかなった。
よって肯定する部分がない。当然他言語も全く追従しない。（今後出てくるかもだが）
逆に非同期はJS/C#/Rustと来てるだろ。良いと見られている証拠。

> V8もTurbofan+Ignitionに変わってすぐはソース読んでたぞ。
それは君が興味があるからだろ。
大半のJSerはC++は読めないし、読む気もない。ブラウザが速ければそれで良しだよ。


わざわざ自前でスレッド管理するのなら、OSと被ってないところをやらないと。
スケジューリングはOSがやってくれるのだから任せておけばいいし、自前でやっても余計に遅くなるだけ。
残ってるとすればスレッド間通信で、これは確かにOSのは遅い、というより動くようにしか出来てない。（そして非同期）
だからそこそこ速い同期チャネルが絶対不可欠なアプリがあれば、と思って考えてみたが、やっぱり俺は思いつかないね。

やり方がわからんのだろ。

チャンネルが同期なのはバッファが無いとき
お前は本当に人な話を聞かないし何も読まないな。

>>71
> 妥当性がどうのこうのは「GoランタイムのG実装」であって、君のデータについてではない。
うん、それは分かってたんだけど、定量的なデータがないとその妥当性分からんでしょ
M:Nのgoroutineだからと言って調子に乗って1:1の10倍積むと、俺の環境だとrssは超えてしまうってことがデータから分かる
データは簡単に取れる状況だったから、取っただけ

Windowsでアップデート後にVScodeでテストを走らせると1.14.13でコンパイルされてるためツールバージョン1.17.7とマッチしませんと言われる
setting.jsonでgo.gopathを環境変数のGOPATHに合わせてビルドしてもダメ
かといってアップデートされたディレクトリを指定してもダメ

環境変数のGOPATHのgo.exeがアップデートでは更新されていないためなのか
でもツール類はアップデートされてたりしてもう訳がわからない
どう処置したらいいの？

ちなみに、システム環境変数のPathには$GOPATH\binのパスが入れてある

いや…落ち着いてエラーログを見たら、例えばruntime/internal/sysが、とか言ってる
参照モジュール？

で、go.sum を消して再ビルドしたけど同じ結果

とりあえず全部をアップデート先に統合する方向で納めた
バージョン混在状態だとどうしたらベストなのだろう？
環境的には最新に統合してgo.modでのバージョン記述に頼ればいい？

>>74
つまりリソース的にGoroutineはOSのスレッドの数倍しか立ち上げられないということ？

https://zenn.dev/mattn/articles/c453f42393778a
numpy より速い？Go の行列演算ライブラリ nune

やっぱＧＯは速いね

>>74
それはご丁寧にどうも。ついでなら、
> C++は20を使えば標準機能だけで実装できるはず (>>58)
これについてもキーワードかURLだけでも教えてくれれば助かる。見に行く。
greenthreadが採用されたって事か？
(C++の場合は『全部入り』を目指してるからいつかは入るとは思うが）


>>73
あの文法は同期が主目的で非同期も問題なく書けるだけ。

OSのスレッド間通信は非同期しかなく、
同期したければ自前でループかサスペンド/ウェイクアップするしかない。
だからそんなに同期を取る事はなく、仕方なくやる程度。
そしてそれで何とかなってる＝従来分野は非同期で問題なく書けてる。

同期の場合、シェークハンド等の単純な方法なら同期プリミティブ無しで書ける。
多分もっと複雑な事も出来るのだろう。だけど俺にはそれに適した分野が分からない。
(従来分野は問題ないので、従来既に困ってたか新分野かだが、思いつかない)

ランタイムの仕様が無駄に大きいと、実行速度がそのまま低下する。
JSが無駄に速いのは、仕様が小さい(最小限に絞ってる)のもある。
チャネルの実装は以下(前スレ805内リンク8章)にあるが、
https://zenn.dev/hsaki/books/golang-concurrency/viewer/chaninternal
こんなまどろっこしい実装になってる理由は、同期（も出来る構造）だからだ。
非同期専用ならもっと単純な実装で済むし、速い。

だから優位性を発揮するためには、「同期チャネル」がないと辛いアプリがあれば分かりやすいが、
俺には今のところ思いつかないって話。
（非同期チャネルだと「空になったら止まる」という間抜けな同期しか出来ないが、実際それで十分という話）

>>80
coroutine

>>81
あ、そういう事ですか、なるほど。

まあ見てみましたが、相変わらずというか、何というか。
https://cpprefjp.github.io/lang/cpp20/coroutines.html

Docker CLIのダウンロードみたいな
複数のプログレスバーを出せるライブラリほしい
何がおすすめ？

GUIなぞ基本的には管轄外です
お引き取りを

CLIでのプログレスバーの話だろ？

あーすまん

いいってことよ

>>64
そこは標準機能だけ対象といってもその定義が難しい
そのRustは標準(std)ライブラリーは最小限のものしかなくて
例えば乱数も暗号関係(TLS含む)も正規表現もJSONもHTTPも非同期ランタイムも何もかもstdに含まれていない
全てデファクトスタンダードで賄う方針だからそれらを標準機能として採用して比較してよい？

rustはもう少し標準ライブラリにも機能増やして欲しい。

>>88
俺が依頼してる話でもないから俺に聞かれても・・・ではある。そもそもここgoスレだし何のためにそれをしたいのかすら分からない。

単純に話を聞く限り
・goは言語機能で賄っているのに標準ライブラリ以外を使うとか流石に比較にならないと思う
・C++の標準ライブラリにもjsonやhttpや暗号はない
・同じロジックにこだわらず、追加のロジックで不足機能を補うなら、可搬性(プラットフォームごとに実行コードが変わらない)が必要
のではないかと思う

非同期処理ですら紛糾して仕上がったのが2019/11な赤ん坊に無茶言うなって
Rustのコンセプトは分かるけど、学習難易度とライブラリの貧困さを何とかしないと浮かばれずにいつの間にか沈むぞ

そんなにライブラリ貧困なの？
おれもまだ勉強中なんだけど何のライブラリで困るのか具体的に教えてくれ
勉強がてら試しに作ってみるかも

>>91
学習難易度はキノコードが動画作れば解決w

>>91
Rustも難易度は高くなくて広く色んなプログラミング言語をやってきた者には容易
例えばC言語などのenumを関数型言語の代数的データ型で拡張したのがRustのenum
そういうのを理解しているとメソッドによる代数的演算やパターンマッチングなどRustの基本機能も習得がすぐ
あるいは例えばGoでも構造体ベースのイテレータパターンを書いたことあればRustのイテレータも楽勝といった具合
GoやCのfor ; ; 文はRustには存在せずイテレータに集約されており更にメソッド連鎖させて操作の分離と抽象化でわかりやすく書くことが多い

>>92
むしろRustは民主主義方式なのでライブラリは多種多様に豊富
異なる考え方で作られたものが両立している分野もあるし後から優れたものが出てきてシェア拡大も起きたりしている
代わりに標準ライブラリ(std)は必要最小限のものしかなく
その一部であるコア標準ライブラリ(core)はヒープがなくても動作する更なる最小セットを提供

間違ってる上にスレ違いすぎるな

言語比較がしたいなら↓へ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
http://2chb.net/r/tech/1638086359/

>>96
間違ったことは書いていない
質問や話題があったからそれに対して答えたまで

>>97
>>96

>>95
民主主義方式はc++みたいに標準委員会方式の場合だろ。
実装複数でデファクトスタンダードを競わせるってのは戦国時代方式だよ。

>>99
あの標準委員会方式は強いて言えば一党独裁制だが紛糾ちぐはぐに近い
そしてC++の標準拡張が失敗してきた歴史を見ても反面教師としたのは理解できる

>>100
>>96

確かに、いい加減Goの話に戻そう。

>>102
荒らしに荒さないでって言ってるようなもんだぞ
話が通じる相手ならとっくにやめてるだろ
相手にせずにNGなどで無視したほうがいい

>>103
>>96

そうだね
じゃあ 1.18 の話でもしよう

せっかく Generics が入るみたいのに、slice での Map、Reduce、Filter みたいなユーティリティが提供されないっぽいよね？
今はとりあえず準標準といえるものがこれ https://pkg.go.dev/golang.org/x/exp/slices
だと思うんだけど、そのうち増えるのかな？

例えばこんな感じの実装↓でいいと思うんだけど、本家でなんか議論されてるん？ Go追いかけてるひとおせーて！
https://gotipplay.golang.org/p/Y2cpCCPjKqr

他のインタフェースが検討されてるとしたら、メソッドチェーンできるようにしたい、とかかな？

Rustに移行すべきでは？

>>107
>>96

GoスレでRustRust言う奴から得るもんは何もない
失せろ

>>106
メソッドチェーンの途中で>>105の実装のように毎回スライスを生成するのは無駄で遅いから
各メソッドをイテレータとして実装して中間生成物を作らないようにすべきかな

たしかに効率的にするならイテレータにしないとね
それで簡単に仕様が決まらんのかな

今一番rustの話で盛り上がるのがこのスレだからな

Rust スレはどうなっているんだｗ

NGword: Rust
なんでこれしないのか？

>>113
Tauriで盛り上がってる
electronをRustで実装しなおしたら性能上がりすぎRust覇権とかwww
馬鹿だね～

>>110
それ7年前のRust 1.0公開時からサポートしてる機能だが
Rustはプル型にすることで無駄な動きをゼロにしつつメソッドチェーンの形になってもヒープを使わずスタック上のみで動く特徴がある
しかしGoでは受け入れられる方針なのだろうか？
一方でプッシュ型であるチャネルを使った実装だとプッシュ型にすることでのムダよりもgoroutineを使うオーバーヘッドが大きい

>>40
そのとおり。
決定的なのは、goをRustで実装してしまえばいいw
それがすべてだろw逆にRustをgoで実装することは何万年立っても不可能なんだからw
なぜならgcのある言語でgcのない言語を実装できないから

Istioがまさにそうだよ
> RustをGoで実装

フリーランスだけど未経験OKのところに応募してみた。
採用されたらよろしくな。

>>117
なんでだよw
言語処理系にGCがあるかないかと、それから作られるバイナリにGCがあるかないかなんか関係ないだろwwww
インタプリタじゃあるまいし。

>>117
コンパイラの処理って何か知ってる？

>>117
あのーGoもRustも最終的に吐き出すのは機械語のコードだよ？
その場合GCはランタイムに含まれるんですがそれは実装する言語関係ないですよ？

>>122
goでメモリ管理まで書くの？そしたら所有権とかの概念があるRustに軍配があがるだろ

>>123
Rustの所有権とかのメモリ管理はコンパイル時に行われる静的な処理が中心となるので
どんな言語でも書けると思う

RustあげてるやつがRustの良さを何も理解できてないのがホント阿呆らしい

>>123
既にGoでGoのGC書いてるじゃん。

>>124
単に書けるのと言語でサポートされてるのとはちがうんだよなあ
特に多くのは人が関わるプロジェクトでは

>>127
Rustのメモリ管理の実現方式を理解出来てないと思う
コンパイル時に行われることと、コンパイルされた機械語が行うことの区別は出来てる？
Rustの所有権の処理はコンパイル時に行われるので、そのコンパイラがRustで書かれていようとGoで書かれていようと関係無い

>>127
「サポート」じゃなくて「強制」。

ほんと、Rust信者はRustのメリット・デメリットを知らんな。

>>123
どの言語に対するコンパイラもインタプリタも別のほとんどの言語で書ける
例えばプリミティブ以外は全てオブジェクト型になってしまうJavaScriptでもGoやRustのコンパイラを記述可能
もちろん記述可能性とは別の話として言語機能の強力さや高速性と省メモリ等の点から現存言語ではRustが最も有利であるだけにすぎない

>>123
いやだからコンパイル後に動くのはランタイムのコードなの
Goとか関係ないの
ランタイムって意味わかる？
機械語に含まれる標準ライブラリやメモリ管理のコードのことだよ

>>117 >>123
フルボッコでワロたʬ

>>132
痛いところをつかれた証拠だな
よほど都合が悪いらしいwwww

>>129
そうそれ
だが強制するとしないでは天と地の差がある
つまりセキュアが保証されるかされないかということに影響する

コンパイラの仕事が何なのか知らない人がRustを推すのは流石に恥ずかしいからやめてくれ
Rust使ってる身としてはすごく迷惑

>>134
Rustの言語仕様の所有権による実行コードの安全性の保障は、コンパイラをRustで書いてもGoで書いても、同じように得られる
逆にRustでコンパイラ書いたとしても、それによってコンパイルされたコードがRustの所有権による安全性を得られるわけじゃない

やはりおじさんはVM系言語しか使ったことがないようだな
会話が成立しない訳だ

GoスレでマヌケなRust推しが暴れているという地獄

Rustの方が言語機能の強力さや高速性と省メモリ等の点から最も有利なだけにすぎないからね
ほとんどの言語でGoのコンパイラもRustのコンパイラも作ることが可能
この両者の区別ができないとね

いわゆるVM系の言語(Java、C#、JavaScript、Python、Rubyなど)はランタイム自体がインタプリタに含まれてるので意識しないんだろうな

なんか普通に恥ずかしいよね
コンパイルが何をしているのかも知らなかったなんて
最近のVM系言語でもJITしてるし理解してるものかと思ってた
JITはインタプリタのランタイムのスタックとマシンコードのスタックを引き継ぐ処理とか内部でやってる
そういうのもわからないんだ

rustだなんだという前に大学に編入してCSを勉強した方が良いのではないか

なんでここまでボロが出る前にスッとROMに徹せられないんだろうね？

>>140
そんなの知らなくていいよ

Rustのことは忘れて

スライスってよく考えたら中にサイズとキャパシティ持ってるだろうからlen(スライス)はそれを見てるだけなのか？

>>143
おそらくそうだったと思うよ。

これが良いかな。
https://stackoverflow.com/questions/28204831/how-do-gos-len-and-make-functions-work

struct の中にスライスと長さを持たせてたよ…orz

RustのVecだって同じじゃん...orz

RustのスライスとGoのスライスは概念が異なる
Rustのスライスはポインタと長さの2点のみを持ち常に「参照」である
つまり「参照」ということは「本体」がある
本体は配列(＝そのままだとスタック上で長さ固定)やVec(＝ヒープ上で長さ可変)など
Rustのスライスはそれら本体の一部(もしくは全体)を指す「参照」という従属物
このように概念を整理して分離したことがGCのないRustの効率の良さに繋がっている

まーた(ry

>>148
Go のスライスの内部実装も知らない男の人って・・・

Goのスライスはうっかりデータ競合を起こしても自己責任
別変数に代入して各々に対して値を書き換えたりappendしたり可能だがもちろん互いに競合する
そして苦肉の策の結果としてappendでキャパシティを超えた時に両者がそこから分岐
一方でRustは言語仕様でデータ競合を起さないことを保証している

>>151
>>96

>>151
Goの欠点だな

Goのスライスは実質的には可変長配列として使うからね

嘘つきはRustの始まり。std::syncだって同期とが標準モジュールに入ってるし、atomic型だって同じ。並列操作ではgoは他の
言語に抜き出ている。goが競合を起こすのはgoroutine同士でデータを共有するような、”古い老人のような作り方”をしている
からでchannelを通さない、sync.Mutexを使ったこともないasync/awaitだけでRustライブラリの中がArc<Mutex<T>>に
なってる事も知らないド素人がイキがってるだけ。
スレ違いなので荒らすのは止めましょう

refrect.DeepEqual() って便利
だけど、単体テストでNG出たんで今日は寝ますね
(…どこが食い違ってるのか教えてはくれない)

Javaやpythonからgoに来た人って絶対Rustにも行くよね?w

皆さんストリンガーって保険のためにとか実装してる？

別に行かない

別にRustを使ってもデータ競合は防げるけど競合状態は防げないし、データ競合を防ぐ目的のために面倒なメモリ管理をやる気にはならないな

JAVAから来ました

>>151
Goのスライスは言語設計ミスだけど
言語仕様を複雑にしたくないために起きている不幸の一つ
データ競合についてはGoは言語としてサポートせずプログラマーの腕に任せる方針

>>162
中途半端な仕様だな
それって意味ないだろ

今からGoですを勉強するのって意味ない？
rustとかいうやつのほうがいいの？

Goの採用はスタートアップなんかでも結構多いので意味無くはない
Rustは実際にはまだほとんど無い
とはいえGoをあえて勉強する必要があるかは微妙だな
こんなの経験なくてもチームに入ってからなんとなく空気読んで十分使えるし、
それができる程度に他言語の経験がないのであればGoはあまり意味のない言語だ

>>164
「勉強」の意味による。

仕事につながる技術を身に着けたいなら、普及率が高くて求人も多いJavaやcのほうがいい。
学問としてプログラム言語を勉強したいなら、より原理的なlisp(scheme),haskell,cのほうがいい。
趣味でプログラムするのに勉強したいなら、手軽で教本も多いpythonあたりかね。

goやRustは中途半端なので、最初の選択肢にはならない。

Goの戦場はニッチだからねぇ

汎用を求めるならJavaやC#
ハイエンドならC++
いっちょ大穴狙うならRust (次の次くらいに来るかも)

Java, C# は使えて当然、C++が分かるなら誉めてもらえる

>>164
勉強はいつだって意味があるよ
2〜3日入門書を読めば大体分かるだろ
入門書の値段分ぐらいは価値があるよ

goは言語自体はあまり面白くないからね
仕事で使う予定がないならもっと尖った言語の方が面白いだろう

みなさんありがとうございます。
Javaとphpを仕事で使っていますが、Goの何でも自力で書く的なものに惹かれて将来的には仕事で使いたいと思いました。

>>164
goかrustの2択だったらrustかな？
goは中途半端になってしまった。

>>166の言う通りケースバイケースすぎてなんとも
もうちょっと素性や目的を明かしてくれないとね
あらゆるケースを想定して書くのはめんどう

Goは文法だけなら超簡単だけど
channelを使った並行プログラミングのパターンをしっかり身につけてないと使い物にはならない

Dust信者暴れないでください

>>171
そういう志向ならgo もいいけどcのほうが勉強になると思う。
なんだかんだ言ってもサンプルとか解説はcのほうが多いし。

>>171
> Javaとphpを仕事で使っています （中略） 将来的には仕事で使いたい
どう考えてもJS一択。現在Javaメインで鯖周りだけPHPなら、明日から使える。

> 何でも自力で書く的なものに惹かれて
分野ごとに言語が違って一々勉強が必要なのはナンセンスじゃね？とは思うだろうが、
実際はJavaでも何でも出来るが、
例えばJavaでGUIやるよりは勉強の手間含んでも他言語の方がマシなのでみんなそうしてる。


Javaを既に普通に使いこなしているのなら、Goを『学ぶ』意味はない。方言程度で使えるはず。
引っかかるとしたらポインタだが、ポインタを学ぶならCの方がいい。
俺はパラダイム違いという意味でもJSだと思うけどね。関数ポインタ/クロージャを常用する言語をやった方がいい。
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E%E3%81%AF%E8%A4%87%E6%95%B0%E7%BF%92%E5%BE%97%E3%81%99%E3%81%B9%E3%81%8D/

>>176も>>177も勧めてるけどC言語は基礎教養として必須
C言語のあとRustへ進めば進みやすい上に今どきの各種プログラミングパラダイムを押さえられていいかな

Cへの理解があればまあ何とかなるっしょ

>>178
JavaやっているやつにRust勧めるなよ。c++でRAIIとunique ptr勉強してからじゃないと無理。

GC前提のgo のほうが近道だわ。

>>180
C++は以前の「筋が悪いが代替がないから使う」から今は「避けることができる」言語
今となっては学ぶべきでない言語として大方のコンセンサスがあります
C→Rustと進むのが非常にわかりやすくてベスト

ウェブ業界にいるんなら、Rustの案件は将来も少ないだろうし、
>>171が仕事で使う目的で学ぶっていう意味でいうならGoのほうがええやろ
教養としてならRustのほうが学ぶこと多くて面白いけど

>>182
それならばウェブ業界で今急速に進んでいるのがWebAssembly
そしてWebAssemblyの記述言語は圧倒的1位がRust

>>180
ただGoだと何も「新しくは」できなくね？

ガチ鯖はJavaで、ライト鯖はPHPで既に書けるなら、Goが他に活躍してる分野って何？
今時のデスクトップアプリはGUI無しとかあり得ないから、CLIアプリとか？ならJavaで全く問題ない。
Javaが動かせない貧弱環境(=非x86、非linux、つまり大体組み込み)ならC一択だし。


>>181
> C++は （中略) 今となっては学ぶべきでない言語として大方のコンセンサスがあります
これはない。お前の周りがトチ狂ってるだけ。Rust界隈はそうなのかもしれんが。

俺はRustは最終的に死ぬと思ってる。
C++とはコミュニティの規模が多分4桁違うし、FireFoxを殺したのはRustだし。
(まあ俺はGoも最終的に死ぬと思ってるんだが）

初心者は「全機能を使いこなす事が必要」だと思ってるみたいだが、これは明確な間違いで、
C++なんて全部入りなんだから全機能なんて使ってる奴は居ない。
(例えばインラインアセンブラも普通に出来るが、常用されても困るわけだし）
C++は元々「必要な機能を選んで使う」思想で、
初心者は「何が必要で何が不要か」判断出来ないから適切に使うのはかなり無理。
で、そういう奴は大体C++の悪口を言う事になるわけだが、ほぼ「肥大化してる」だけだろ。
それはお前が適切に取捨選択出来ないだけだ馬鹿タレ、でしかない。

>C++は元々「必要な機能を選んで使う」思想で、
>初心者は「何が必要で何が不要か」判断出来ないから適切に使うのはかなり無理。

一人で使う分には自分が理解したところから使えばいいんだがチーム開発だと悩ましいよな。
書いた本人以外理解が難しいコードなんてのも簡単に量産されるし。

>>184
そこは冷静になって純粋に言語機能をC++とRustで比べてみればいいんじゃないか
言語としてはC++が勝っている点がほぼなくC++の様々な欠点をRustが改善解消
だからこそ大手IT各社が揃って共同でRust foundationを起ち上げるなど垣根を超えて惚れ込んでいる

>>185
だから「コーディングルール」で切るんだよ。

つか、多分、C++とそれ例外では「コーディングルール」自体の意味が違う。
C++のは機能も使い方も制限する。Goとかだと見た目だけだろ。
(Goの場合は見た目もディレクトリ構成も画一だからもしかして何もない？
googleもC++/JS/PythonはあるがGoのはなさそう)

C++に問題があるとすれば、「難しいコードを書くことに何らブレーキがない」事で、
これをコーディングルールで補ってる。
C++以外の言語は「使うべきでない機能はそもそも入れない」で、これは正しいが、
後出しじゃんけんじゃないと無理。


>>186
言うてRustってC++で廃止されたauto_ptrを焼き直しただけだろ。
ヒープの生存期間をスタックと連動させるのはいいが、それはCでも書けるしCだと基本だった手法。（ただし手動）
だからRustで生成されるコードはC++でも書けてしまう。
そしてRustは境界チェックがある分だけ遅い。よって最終的に勝てる理由がない。
この点FireFoxの連中は大馬鹿もいいところで、スピード競争してるのに速度優位性がない言語を選んだ時点で自殺だった。

RustはCの代替になろうとしていて、勿論ネイティブバイナリを吐くわけだが、
これを潔く諦め、Cのコードを吐く（TS/JSの関係と同じ）だったら、覇権とれたかもとは思うけど。
この方法だと組み込み全分野に無理なく浸透していけるし。
(ただしこれだとC++の代替にしかならないから気に入らないのだろうけど)

RustでOS書こうとしてる馬鹿もいるだろ。誰も使わないよ。
Linuxより速くて小さい物を提供出来る技術的理由がないし、
仮にそれが出来てもCでも書けてしまうからLinuxももっと小さくなり、永久に追いつけない。
Rustには生き残る理由がない。

このおっさん勢いあるスレならどこでも湧くな。そして偏った知識で見境なく喧嘩ふっかける。かまってちゃんが過ぎる。

>>187
そこまで無知だとは思わなかった
叩きたいならばまずは知識を身に着けないと恥ずかしいよ

>>189
エコーチェンバーが欲しいのなら他言語スレに出てくるべきではないよ。


Rustが提供してる機能は結局のところ、プログラマの補助でしかない。
Rustで書かないと実現出来ないコードなんて存在しない。

元祖馬鹿向けCはJavaで、大ヒットして覇権を取った。
ただし関数ポインタが無かったのでGUIには全くフィットせず、そこは全滅してる。
とはいえ覇権言語であり、現在でも1/3はJavaだろ。

2代目馬鹿向けCがGoで、これもそこそこヒットしてる。(とはいえC/C++の規模からするとゴミだが）
RustなんてGo以下のゴミだし、そもそも人数は馬鹿>>>選ばれし勇者なんだから、
ずっとGoよりもゴミのままだと思うけど。
んで、元祖選ばれし勇者にはC/C++で十分だし。

俺はRustはC++のコーディングルールの一部になると見てるし、そうなる事を望んでる。

>>190
C/C++の欠点はメモリ安全性等の欠如により発生する欠陥の多さであるとグーグルとマイクロソフトが意見を同調している
そこへ現れたRustはコンパイルが通ればメモリ安全性やデータ競合ゼロを保証するため彼らにも歓迎され用いられている

>>191
C/C++の欠点は「馬鹿が『ひとりでも』混ざるとどうにもならない」事だよ。

ただ、静的解析で何とかなるものなら、「全部入り」のC++にもいずれは導入される。
現在C++は3周遅れ(9年遅れ）程度だから、
9年のうちに優勢になれば勝ちだが、これは多分無いでしょ。

>>192
ところがC++には不可能
Rustには簡潔な借用ルールとライフタイムがあるために成立している
さらにRustにはunsafe操作の分離という導入もありこれが安全性の保証に大きく寄与している

Go の G の字もないなｗ

次スレまで待とうかと思ってたけど流石にワッチョイスレ作った方がいいか？
完全にスレが崩壊してる

>>193
> ところがC++には不可能
『今の』C++にはね。
ただ、C++の場合は少しでもその方がコード効率がよくなる、とされると採用される。（ので良い物はいつか採用される）
それが「全部入り」

> 安全性の保証
要するに補助輪でしかない。Rustのは全部これ。

> 簡潔な借用ルールとライフタイム
これは俺は筋が悪いと思ってるけど。
プログラマに生存期間をマニュアルで管理させてるだけ。（これはCと同じ）
そしてRustの場合はこれの整合性を静的に解析出来る。（これはC++にはない。が、コンパイラ側で対処出来る話。そのうち導入される）
だいたいそもそも「貸し借り」なんてやってる事自体、
一般的プログラミングにおいての生存期間と合致してないからであって、根本的に筋が悪い。

そもそもプログラマは管理したいとは思ってないから、GCの方が筋がいい。
GCだと駄目な件については、例えば以下なら、（このブログは有名なので色々言われてるようだが）
https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=bd6f6b9c5be3
そもそも大量の生存オブジェクトが存在する場合はGCには不向きなので、
Goについてなら例えば「GC非対象の変数宣言」構文が用意出来れば済んだ話。
(この思想がGCとフィットしないから一般的に導入される事はないが、
VC++ならnew/gcnewでGCなし/ありを切り替えられるし、俺はこれで十分だと思うよ）


まあ心配しなくても、所有権の貸し借りが素晴らしいってことになれば、C++にも確実に導入される。
そのときRustは死ぬよ。その猶予が9年間。

>>196
合成の誤謬ってやつだね
C++は全てを含むから最強
あとはC++から必要な機能のみを抜き出せないユーザーの責任

完全チューリングマシンでもやっとけ

VScodeで自前のパッケージを使おうとしたら、importの追加のクイックフィックスが出ないんだけど
これって昔からだっけ？

あ、違うわ
プロジェクトのルートに置いてると /cmd/internal 以下のパッケージは参照できないみたい
なんだこれ？こんなルールあったっけ？1.17.7

外部パッケージの参照の仕様はまあ仕方ないんだけど
なんで内部パッケージで相対参照できなくなったんだろう
どっかにブログとか理由の解説ない？

ディレクトリ名とpackageでの宣言、二重に記述しないとまともに動かないパッケージ名ルール
物凄く不満

それでいてcmdとかのディレクトリだろうがmainはmainパッケージだし
一貫性よりも何か重要な理由があるのか？

ITの9年は長いでよ、ロートルには短いかもしれんが。
そして30年という長い年月を持ってしてもC++はLinuxカーネルに入れなかったのにRustは入った。この違いよ

>>202
> ITの9年は長いでよ、ロートルには短いかもしれんが。
長いという程長くもない。お前もオッサンになれば分かる。まあこれはさておき、
実際、現在のプログラミング言語のアイデアは既に80年代に出尽くしており、
今はそれを実装していってるだけ、とは言われてるだろ。言う程進化はしてない。
Rustだって何一つ「新しいアイデア」はないだろ。

> Rustは入った
ググってみたが、まだforkして勝手に起こしただけじゃね？
> https://japan.zdnet.com/article/35174333/
> https://thenewstack.io/rust-in-the-linux-kernel-good-enough/#:~:text=When%20we%20first%20looked%20at%20the%20idea%20of,the%20standard%20C%20normally%20used%20in%20Linux%20development.
多分知らないのだろうけど、オブジェクト指向最盛期(2005頃)には、
・Linuxのコードを『安全な』オブジェクト指向で書き直そう！
というプロジェクトはあった。今はググッても出てこない程跡形もないが。
これと同じだよ。
安全に書き直したコードは、書き直してないコード(既に世界中で使われてる)よりバグが多いから意味がない。
この反省を踏まえてRustは「書き直すわけではない」というスタンスのようだが。

LinusはC++の依存性を持ち込む文化を毛嫌いしている。だからC++は入らなかったが、Rustも同じ。
Rustのコードを入れれば、Rustが読み書き出来ないと参加出来なくなり、つまり開発人数がコミュニティ規模に比例して小さくなってしまう。
今現在のRustのコミュニティ規模なんて、C/C++からすると多分4桁くらい小さいだろ。それは開発人数を1/10000に削るのと同じ。
(C++ではコードそのものの依存性が問題だが、Rustの場合は他言語への依存が問題）
馬鹿じゃなければやらないし、Linusは馬鹿ではないと思うけど。


まあRustの連中はすさまじいエコーチェンバーの中で生活してる事は分かった。

Rustスレで相手してもらえないからってこっち来るの止めてもらっていいですか

何を勘違いしているのか知らんが、俺のこのスレの直前の書き込みは>>104

cppの話はcppスレでやれよ。
しかしgcnewってC++/CLIの話じゃないの？

gcnewってなんだこれ、.Net専用とはいえなかなか邪悪な代物だな……

>>196
それは知識が足りていない
借用ルールの借用とは当然ポインタを含む概念でありC++でも借用は普通に行われている
そして借用をよく見ると読み取りのみの借用と書き換えもありの借用の2種類がある点はどの言語でも同じ
読み取りの借用がある状況で書き換えの借用を許せばデータ競合が起きることはわかるだろ？
もちろん書き換え借用がある状況で読み取り借用を許してもデータ競合が起きうる
一方で読み取り借用だけならば複数の読み取り借用を許してもデータ競合は起きない
つまり『multiple reader XOR single writer』となりこれが借用ルールだ
もちろん全てのプログラミング言語においてこの借用ルールに違反するとデータ競合が起きうる
Rustはこの借用ルールに違反がないかどうかをコンパイル時に判定できる言語仕様となっている
だからRustはメモリ安全性だけでなくデータ競合安全性も保証することができるわけだ

荒らしまくるRusterと不愉快仲間たち

最近他のどのプログラミング言語スレいってもRustの書き込みあるな
飛ぶ鳥を落とす勢いとはこのことか
そういえばJavaが出現した頃、C++erがよくJava厨に噛み付いてたっけ

>181 >186 >187 >190 >191 >193 >196 >197 >202 >203 >208 >210
>>96
荒らしに反応するやつも荒らしだからな。誘導だけしろよ。

>195
早いところワッチョイ立てようぜ。
NGが捗る。

>>96 読んでみたが、なるほどここと同じような話が展開されてる。
ただ、C11に移行しようとしてるじゃないか。 >>202
> http://2chb.net/r/tech/1638086359/542
> トーバルズ氏、Linuxカーネルを「C89」から「C11」コードに移行する準備
> https://japan.zdnet.com/article/35184296/
このペースならあと10年はRustなんて入らないね。


>>208
> それは知識が足りていない
これはその通り。俺はRustやる気はないし、借用だ何だかんだの顛末を見て、様子見する事にした。

C++で既に慣らした奴ですら戸惑うのは、
自然な（直感的な）ライフタイムと言語の管理機能がマッチしてないからだよ。

そもそも俺はCでもメモリリークに困った事はない。
ただこれは「困らない範囲でやってる」(＝ごくごく安全運転に徹してる)からであり、俺が賢いわけではないが。
この辺の「安全運転を強いられる」のが嫌でC++的にやりたいのも分かるし、Rustも良い実験だとは思うが、
余計な事を考えて、しかもそれでコンパイルが通らない事に悩まされるのは、そもそも設計が悪いからだよ。
つか、そんな事で悩むくらいならGCの方がいいから、実際ほぼ全部の言語はGC持ってるわけだし。

GCの問題点は色々あるけど、discordについては、Goに「GC非対象」を明示する構文があればGoのままで行けてたはず。
何も考えたくないんだよ、っていうGCの思想に反するけど。
Goはポインタのキャストって出来たっけ？出来るのなら、自前で大きめに確保して(数百MB)、
そこから小分けするmalloc/freeを用意してやれば済む。(現行の機能だけで出来る）
システムプログラミング言語だ！OSだって書けるんだ！って言ってるんだから、まあ何とかなるんだろうけどさ。


>>207
魔合体されてるVC++が見た目異様なだけで、
gcnewは単にgc対象ヒープから取るだけ。使い方はGC言語のnewと同じ。
(&*が既に使われてるから%^になってて初見で拒絶されるのは仕様）

>>211
96読んだ。俺は移動に同意でいいが、移動する権利は相手に与える。
つまり、レスが投下されたスレに俺もレスを投下するから、
俺にレス付けるなら、やりたい方のスレでレスしてくれ。

>>212
全てのプログラミング言語の中で
コンパイラメッセージが最も親切でわかりやすく修整点も具体的に指摘してくれるのがRustコンパイラ
この状況でどうしてもコンパイルが通らないのだとしたら知能がよっぽど低いのではないだろうか？
標準的な知能があれば問題とならないような点でつまずいたのかね

>212 >213 >214
>>96
とっとと行け。スレ違い続けんな。

ワッチョイ無いとほんと不便ね

Goってどうやって勉強すればいいの？

>>217
Goに限らんけど俺の場合は実際に動くコードの載ってる本で写経しつつ読み進めるのが一番短時間で覚えるみたい。
俺って頭じゃなく体で覚えるタイプなのかも。
結局、文法的なものは他の言語触った経験あれば新しい言語も難しくないんだけど、キーワードの要不用やライブラリやそれの使い方とか、その辺記憶するのが一番面倒。

>>218
やっぱ自分の能力次第だよな。
俺はなんかサイト一個作ったほうが覚えられそうだから作ってみるわ。
何作ろう

標準的なソースコードを集めたコードサンプル集とかあればいいんだけどな。

ハイエンドというほどじゃないが、みんなのGo第二版はよく参考にしてる
flag使ったときとか

でも言いたいのは多分、ファイル読み込みとかごく基本のコード断片だろなー

https://qiita.com/takehanKosuke/items/9034e3d993df337eb669
こういうのの巨大なバージョン、誰かgitに公開してたりしないかね

テーブルドリブンテストはなんか標準かでGenerateされるようになったね

テスト対象の呼び出しまで完璧にサポートされてて便利すぎる

Go 1.18 is released!
https://go.dev/blog/go1.18

ジェネリクス使ったmapやsliceのユーティリティが乱立するのかな

やっっっとジェネリクス医薬品きたのかよ
どれどれどんな塩梅よ

>>225
よっしゃ！
そしたら1.17入れる準備するか。

やっとこういうのできるようになったか
https://github.com/samber/lo

>>229
使いにくいインタフェースで筋が悪いな
あと多段適用するにしても途中で毎回配列生成は無駄すぎる

GoCVのWindows版一生動作しなくて泣いてる
動作してる人がいたらmingwとgocvのバージョンの組み合わせとか教えてほしい

>>231
解決した
gocv 0.28.0
mingwgcc 8.1.0
go 1.8
で動いた

今更案件に採用したいとの連絡が来やがった。
もう他に決まっちゃったよ…

go案件一回だけ行けたことあるけど
バージョンが古くてきつかった記憶あるなぁ
下手にでかいシステムだとそういうのあるんだよな

もう go modules 無しで開発できる自信がない…

構造体のブランクフィールド
struct {
_ int
}
って、どこかのソースで使ってるのって見たことある？

1.18 で ~T って、T を実装している型という認識で正しいのかな？

1.18 の言語仕様読んでるけど
ジェネリックスいらんわホントに
HTMLコメントでは書き足りてないとか、ホントにホントに…

>>238
どう言う意味でいらない？

>>239
ジェネリックス入れる上では仕方のない事なんだけど、
型関係の言語仕様が山になって追加されてた

spec の単純行数にして
1.17 - 2823 行
1.18 - 3265 行 (+442行)

これからガンガンでかくなるはずなので、これに耐えられないなら早く逃げてくださいね
お疲れさまでした

>>239
ライブラリ開発者くらいじゃないのか？
欲しがってるのは正直、一部の開発者だよな
そのために仕様を10%単位でブクブク肥らすのは許容できるトレードなのか？

>>242
通常のユーザーがジェネリック使うの強制なんだっけ？
ライブラリアン専用なら気にする必要無い気がするけど。

>>243
初学者が仕様書を読むとき、ハードルがかなり上がってしまう
何故かというと、至るところで型統一やらジェネリクスの用語の汚染が進んでいるから

もう、初心者には1.17の仕様書で勉強させるべきに思える

>>244
初学者は仕様書読ませるのがそもそも間違い。
入門書読ませなさい。

>>245
s/初学者は/初学者に/
typoすまんね。

あと珍妙に思えるような気もしなくもない文章が
The result of constraint type inference
is final substitution map M
from type parameters P
to type arguments A
where no type parameter P appears in any of A.

引数Aから型パラメータPがなくなるまで置換するマップMを制約型推論の最終結果とする、でいいのかなあ

>>245
あー、自分基準で初学者としてCのベテランレベルを想定していたわ
gccでインターネットサーバを書いてた層
半日でだいたい理解して三日でアプリを組み始めた

プログラム作る側からすると便利なライブラリが増えるからいいと思うわ

map/reduce/filterみたいな操作をたくさんするとき、マジで面倒だったしジェネリクスあればいろんな場面で助かる

>>247
意訳すると型パラメータの方程式を解いた結果の制約集合が推論結果です、ということか
もったいぶった文章だな
Rob pikeのチェックは入ってるのか？

>>251
1.18の言語仕様の一部
その文は、Constraint type interface の中頃

とにかく読みづらい仕様書になっちまった！
と言いたい

そうですね
もうGoを使うのはやめたほうがいいですよ^^

初心者は仕様書なんか見ない

システムプログラミングしかしてないので
あんまりいらないけど
Web系とかはあったろうが便利なんじゃないだろうか

コレクションの中身が何の型かって基本的なことがわからないのはキツいよ

Goでコレクションなんか使うか？
プロダクション運用してるけどsliceとmapしか使ったことないわ

>>248
ベテランでも仕様書は読まないだろ。
普通はクイックツアー -> やりたいことのサンプルコードだと思うわ。

>>258
普通は仕様書からチェックすると思うが
CでもC++でもJavaでもGoでも

あれ？C#の言語仕様書って見た覚えがない…

>>259
ああ
C#はマイクロソフトのヘルプで見てったから文法書形式のは覚えがないのか
JavaScriptもMDNばかりで仕様書をよんだことないや

>>259
ANSIとかISOとか持っているやつがそんなに居るかね。

>>261
CとかC++やってりゃ赤とか緑とかARMとか持ってないか？
もっともインターネット以前だけど

たまには仕様書も読みなおすと新鮮
いつの間にか妙ちきりんなルールが追加されてたりするし

_ &= flag というように、算術代入の左辺に空白識別子は置けません、とか誰得？
NOOPだとばかり思ってたけど変わったのか(わざわざ確認する気もない

おじさん消えて

日本の製造業何十社から、トップが集まった、MISRA-C 研究会でも言ってた

日本には、C の仕様書に詳しい香具師はいない！
だから、仕様書で議論する事ができないので、

組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
という本が書かれた

これが実際のコーディングルールのバイブル

抽象的な仕様書で、議論をしない事。
必ず、具体例・コードで議論する事

これが大原則

仕様書で議論するのは、現実的じゃない。
江添のC++ 本を見ても明らか

仕様書を表現した無数のコード例が書いてあるけど、細部は省略しますばっかり。
細部まで突き詰めていくと、切りがない

江添レベルの人間が、日本に2人もいないので、仕様書で議論することは無理

generics は、Rust にもあるから

またジジイが暴れてんのか

じゃ、どういう話題なら気に入るのかね若い人

>>266
そこは有る無いという話ではない
そこはRustの方が使いやすい
特にトレイト境界がありがたい

最近マシにになったと思ったが我慢できないのかな？
Go Nimスレに閉じこもっててくれ
そこは好きに使っていいから
個別スレでは大人しくしといて

>266 >269 >270
>96
餌与えんな。

MISRA出してくるのも相当おかしいけどな。

>>270

1.18の言語仕様はどこで公開されてるの？

>>274
https://go.dev/ref/spec
1.18 はもう安定版だから現在の言語仕様がそれ

>>274
https://go.dev/ref/spec
じゃないの？

定数、変数、型やらの基本的な言語仕様で型パラメータやらコア型とかのジェネリクス関連の概念も持ち込んで記述する必要がある
けれどもライブラリ、それも今までinterface{}を引数に持ってたような関数を書いてたライブラリにしか関係ない概念を何故か皆が学ばないとならなくなった
単純に仕様書の行数から、学習コストは10%悪化したと見なせる

ジェネリクスは項として別枠に記述して、そこで定数やらでのジェネリクスの影響について書いてもらいたかった

>>277
いや、無茶振りだとは分かってるただの愚痴

愚痴ばかりだから老がいとか言われてるんだよな

>>275
なるほど、ココ読んでみるよ。

Goの長所はシンプルさ
その長所を劣化させてまで今さら導入すべきものではない
どうしても必要なものならば最初から仕様に含めるべきだった

ロブパイクが実質リタイアしたから通ったんじゃないかな

一応、大昔からジェネリクスは入れるとロードマップで予告はされてた

ジェネリクスなんていらん、ていってるやつのほとんどがロートルジジイばっかりでわらう

いや、ジェネリクス導入が遅すぎたこととそれが中途半端であることを問題視する人々が多数派
そのために全体のシンプルさを失い更なる中途半端な状況を招いている

コンパイラの実装を大幅に変えなくていいから
この仕様に落ち着いた感はあるよな

大体がJava5でジェネリクスが導入されてから、自分で書いた奴ってどれくらいいるの？
居るなら自分のプロジェクトリポジトリ晒してみ？


とか書いてから
ArrayListに散々お世話になっていながら、その言いぐさはないよなーと反省

golang.org/x/text/encoding/japanese でshiftjisをデコードすると
不正バイトはU+FFFDに変換されるんだけど
エラーを返してほしいときはどうすればいいの

ちんちんシュッ！シュッ！シュッ！

コードを見ても変換失敗時にエラーを返すロジックないし
ルーン '\ufffd' の変換結果をdstから探したら？
[..., 239, 191, 189, ...] という並びがあればエラーだと思うけど
https://go.dev/play/p/8ALF1MMIQPz

https://go.dev/play/p/8ALFIMMIQPz か？

https://go.dev/play/p/8ALFlMMIQPz …

だめだplaygroundのURLがどこで間違ってるのかわからん

playground側の問題かもしれんね
別のサービスでコード共有したら？

https://github.com/golang/go/issues/18898
もともとエラーを返すようにしてたのをFFFDに置換するようにしたのね

> ルーン '\ufffd' の変換結果をdstから探したら？
それしかないかー

>>293
5chはタブレットで見てて、コードを書くのはPC
手打ちで書き写してるせい
lとかIとか使う邪悪なシステムが悪い

fffdをバイトにデコードしてるだけだから上の配列値があればいいかな

>>285
ジェネリクスなんて糞みたいなもののためだけにビルド速度落としたらgo使う意味がそもそもない。

golangの機能追加によるビルド速度低下なんて他の言語のコンパイルの遅さに比べれば毛の生えたようなものでしょ・・・
ビルド速度とは関係ないが、1.18から関数の呼び出しがスタック参照ではなくレジスタ引数で呼べるようになったので
実行速度が5%-15%改善してる。

否定的意見じゃないんだけど
レジスタ渡しって%単位で効くもんなのかな？
実処理の5-15%がスタック渡しに費やされていたって話だよね

速度的にはキャッシュに乗る乗らないとか色々ありそうだから
定量的に測るのは難しそうだが
そもそもマシンコードの関数呼び出しがレジスタ経由でしょ
なので普通になっただけかと

そんなわけない、レジスタに乗らないデータは普通にスタックポインタレジスタでスタックに格納される。golangが
スタックだったのは実装が簡単になるからという理由が最も大きかった

関数の引数をレジスタ渡ししても
その関数内で別の関数を呼ぶときにスタックへ退避しなければならない
だからC言語でも引数はスタックに積んで渡す

たしか処理系がどのABIを採用しているのかによるんだと思うし、そんな十把一絡げにC言語やらの話を一般化されて話されてもツッコミどころが多い
__fastcall宣言とか使うとまたさらに挙動かわるし

少なくともLinuxのCでは第6引数まではレジスタで渡すよ
6個以上の引数なんてクソコード以外では存在しないから
実質レジスタ経由だよ
windowsは知らん

x86はレジスタが少ないからスタックだった

cみたいに他からも呼ばれるような言語の場合はスタック積みじゃないかね。
ABIの互換性の便利さと比較して、キャッシュ考慮したらそこまで性能出るとは思えんし。

開発者が実装が簡単だったからと言ってるのでレジスタ数とか、GCCの第六天の魔王とか関係ないよ

開発者が実装が簡単だったからと言ってるのでレジスタ数とか、GCCの第六天の魔王とか関係ないよ

ほしゆ(・ω・)

良スレ緊急浮上age

もう30代くらいの若いお父さんだと菖蒲湯知らないんだな
子供より先に「ネギが入ってる！」ってリアクションするもんだから笑い堪えるのに必死だったわ

What’s Next: GoLand 2022.2 Roadmap
https://blog.jetbrains.com/go/2022/04/28/goland-2022-2-roadmap/

GoLandとか使ってる人いるの？
Goを使う開発って腰を据えてGoだけがっつり書くという状況が少ないからクソ非効率だと思うんだが

つまりGo以外も書けるGoLandは効率的ということ

ちんちんシュッ！シュッ！シュッ！

ちょっとVSCodeに不満を感じてなくて他に目移りしてないんだよな

・

ヽ(*ﾟдﾟ)ノｶｲﾊﾞｰ

最近まともなレスが無いけどGoってやっぱ廃れたんだね
Ruby使いで良かった(^_-)

廃れた言語同士仲良くしよう

yoshikiはもうx japanのアルバムは出せないみたいな事言っちゃったしな

20年後もメンテナンスし続けられる業務用言語

>>321
全く売れないだろうしな
今更アルバムとか時代遅れ

ちんちんシュッ！シュッ！シュッ！

もうGoは終わりだな
俺はこれからPHP使いになる。じゃあな

俺はGo使いからC使いになるよ
結局全てのことはCで出来るんだし、森羅万象の神になるためにもCを極めるよ

俺は魔法使いから妖精になるよ

GopherくんがキモすぎたからGo言語廃れちゃった……

キモナイ

ごふぁーは見ててイライラするよね

GopherくんのAAください

ʕ◔ϖ◔ʔ

>>334
www

>>334
これだわw

>>334
完璧やんけ

>>334
天才かよ

見たことあるなと思って検索してみたら2012/06か

(ｏﾟДﾟ)＝◯)`3゜)∵

これと組み合わせられないかと思ったけど難しいな

ていうかさ
仮にゴーがこのまま静かにフェイドアウトして廃れてしまったらきっと
「やはりマスコットがキモすぎたのが敗因か」とか言われるに決まってるが、逆に
何かの手違いでうっかりプログラミング言語の王者となった場合にもやっぱり
「マスコットがキモすぎたのにもかかわらず、これだけの人気を獲得したGoとは！？」とか言われちゃうんだろう
どっちにしてもキモいとしか思われないゴーファー君かわいそう

10年ぐらい前なら美少女化とかしてイラスト描いてる人いそう

(´・ω・｀)はこBOON最強伝説

ʕ◔ϖ◔ʔ
これ商標登録していいですか？

D言語のマスコット凄くかわいかった
何で流行らないんだろう

マスコットはネタになるくらいだしまあどうでもええけどな
LinuxのTuxやJavaのDukeはそこそこかわいいけど、Hadoopはヤバキモいゾウにも関わらずかなり使われてるし

とはいえやっぱLispエイリアンくらいにキモかったりする許せないな・・・

地溝油

製造方法

マンホールの蓋を開け、下水道内の黒く濁り、赤みを帯びたのり状の物体を掻き出し、一昼夜かけて濾過した後、
不純物を凝固させる薬品と共に煮詰めて精製、沈殿、分離など複数の工程を経て、再生食用油に仕上げる。
悪臭を放っていた物質は、この工程によりほとんど無臭になり、腐敗したドロのような廃棄油は澄みきった食用油となる。
見た目や臭いだけでは地溝油と本物の食用油を見分けることは困難であるとされる。
ただし、糞尿を加工して生産しているのではなく、レストランからの下水などに流れ込む油分を地溝油の生産に使用している。

保守age

ほしゆ(´・ω・)

Rustスレ→毎日論争が起こるぐらい盛り上がってる
Goスレ→言語とは関係ない雑談、保守レスのみ

俺悲しいよ。Goが覇権取るんじゃなかったのか？

読んでみたら論争ではなく罵り合いだった

ここは平和なスレッドですね

もう煽りにはスルーで対応してるからな

良スレage

ほｓ

もう誰もGoの話してない(´・ω・｀)

う、うん…(´・ω・`)

じゃあとりあえずゴーファー君の話からしてみようか

ʕ◔ϖ◔ʔ＜見ーあーげてGolang～♪

>>294
utf8.ValidStringというのは使えないの？
tutorial勉強中に出てきたけど

ぬるぽ

おヒマなら来てよネ!

言語仕様をそれなりに語れる言語って実質rustしかないからな
C/C++の全盛期を思い起こされる

テスト

おやすみなさい(´・ω・｀)

6月age

go!

いつの間にか世間じゃ1.18の時代なんだなぁ
Lambda の Go 実装を試しながら

・

hosyu

このスレって何を語るんですか？
プログラミングに関係無いスレですよね？

go

Hiromi

ここまで空気になるとは思わなかった

やはりマスコットがキモすぎたのが敗因だな

今は色んな現場に数年前にGoで作られたLambdaがたくさんありそう
1.11とか1.13ぐらいの

Goは互換性高いからいきなりランタイムのバージョン上げてもまず問題ないでしょ

AWS の Lambda Node.js runtime の EOLに疲れたのでGoにしていってる話、とかあるね
インタープリタじゃないので実行時に最新のランタイムで動くことを強制されないからだって
他の言語は半年とかのスパンでランタイムがバージョンアップされその度に確認やらしないとならない、という主旨

AWS側でランタイムの検証負荷が高いって話？
Goだとそのあたりの責任は各利用者に丸投げできるわな。

いや、Go だけ特殊でLinux用にコンパイルした実行イメージをzipしてデプロイするのと、Lambda実行環境との依存がnet/rpcという枯れた技術しかない
そのためバージョンアップの影響を受けそうにないという理由
つまりランタイムがないんよ

Lambdaはコンテナイメージがサポートされたから他の言語も塩漬けできるようになったけどね

保全

Genericsが出て暫く経ったので聞いてみます。ʕ◔ϖ◔ʔ
イテレーション可能な汎用的なコレクションをmap/reduce/filterなど高階関数で操作できるGitHubスターが多いライブラリは何ですか？

そんなものは無い
ループを回せ

>>383
A Lodash-style Go library based on Go 1.18+ Generics (map, filter, contains, find...)
https://github.com/samber/lo

>>385
これはセンスないわ
エラーを扱えないしメソッドチェーンもできない

AWS Certified Developer - Associate の教科書に書いてあるけど、

AWS Lambda で、deploy package のサイズの上限が、
ZIP は250MB だけど、Docker コンテナイメージは10GB

AWSベースイメージである、Amazon Linux 2 以外にも、
Alpine, Ubuntu などで、カスタムランタイムも作れる

Ruby が簡単

>>386
https://github.com/elliotchance/pie
これはチェーンが出来る。
多くの言語でコレクション操作中のエラー状態を返すという動作はあまり見ない、Rustなんかでもそう。GitHubスター数多いから挙げたが、チェーンもGoの模範的な１行の長さなどがあるし、Goはメソッドチェーンそのものをあまり勧めていない。（慣例的にエラーを2番目の戻りにするから）
エラーを扱えて、チェーンができる言語ってなーに？

>>388
RustはResult型やOption型によってチェーンでエラーが扱われている

goはそもそもエラーを扱う気概にかける言語だからどうしょうもない
毎回いちいちエラーコード返すのが作法とか何時の時代だよって感じだ

>>390
「例外」がないからGo言語はイケてないとか言ってるヤツが本当にイケてない件
という記事があるから、それに対して反論してからどうぞ

>>388
即時評価だね0点
百歩譲ってfilterやmapはエラー扱えなくてもいいとしても、foreachでエラーを考慮しないのはダメでしょ

Rustも例外が無くエラーを返す点でGoと全く同じだが
OptionやResultといった代数的データ型で返すため抽象度の高い取り扱い及び記述がむしろシンプルさと利便性を両立させている
例外を無くした同じ方針なのにまるで原始時代への戻りと未来への発展の差を感じさせる異なる結果となった

例外はgotoと同じだぞ
現代のネットワークやデータベースといった外部依存が沢山あってエラーがありふれる世界にはそぐわないからGoの値で返す方針は正しいよ

Goにあと20年のキャリア賭けてみても大丈夫かね。
未経験可の案件あるから飛び込んでみようと思うんだが…
40ちょいだからあと20年は戦えると嬉しいんだが。

>>394
Web系のエラー処理はオールオアナッシングが基本であまり細かい個別のケアが必要ないから、むしろ例外向きなんだよ

>>397
rustのitertools::foreachはそもそも遅延評価じゃないし、過去の互換のために残されているのはその通り。ドキュメントに明記されている
遅延評価じゃなく積極的な評価だから例外が考慮できるといえるがrustの真価は高階関数操作が共通的であれば最適化されること。goが同様の操作を最適化するかどうかは知らん

GoはそもそもGCがあってランタイムが重たい高水準言語で、ローカル変数でも必要ならヒープに確保するし、
GCどころかヒープすらなくても動くRustとは最適化の文脈が違いすぎて・・・

アホか、レジスタ数が限られてる現代未来において必要ならローカル変数なんかヒープやスタックに確保するのは当たり前だ。
そもそもマルチタスクOSで動く今のプログラムは普通に変数はヒープの間を行ったり来たり
ランタイムが重いんじゃなく、ランタイム大きい。最適化の度合いも近代的な言語で大手企業が支援あれば大差ない。
そんな事やってるからRustが嫌われるんだぞ、馬鹿野郎

Rustは低レベルなシステムプログラミングに使えることが目的な特殊な言語なので

>>397
ストリーム系APIでいう遅延評価というのは一般にいくつかのレベルがある
例 : items.a().b()
1. 最終的に結果を列挙しようとする段階でaとbの操作を実行する。実行順序は、aの操作をitemsの全ての要素に対して実行した後にbの操作を全ての要素に対して実行する。
2. 可能な限り列挙を繰り返さない。可能であれば、1要素毎にaとbの操作を実行し、次の要素に進む。一時バッファを使用しない。
3. 実際に要素が必要になるまでitemsの各要素を生成しない。つまり無限に続くシーケンスの実装が可能。

例えばシーケンスの順序を逆転させるような操作は一度全てを列挙しないといけなかったりするから、普通はこれらのハイブリッドな実装となる。
>>388で実現されてるのはこのレベル1までだね。

>>397
見落としてるだけだと思うけど、
>>388にはEachがあるよ。エラーを扱えない欠陥品だけど。

半分禁じ手に近いけど、deferでrecoverするという手も無くはない
あれは日和ったと見るべきか

>>402
遅延評価と「無限に続くシーケンスの実装」はまた別問題だ。ほとんどのプログラムはfilterやmapも有限長だけで十分機能する。
Pythonのコルーチェンyield中断と同じく、それを基にしたRubyの.lazyや、さらに進んだC#のLINQなどは無限長の操作を可能にするが
Rustの無限長イテレーターはRangeやstd::iter::repeatにおいて無限長を扱えるだけであり、yieldはまだ実験的。
というか迷惑だからRustスレか言語比較してるスレでやって攻撃的な人格疲労しろよ

>>405
俺はRust信者じゃないぞ？
十分機能するかどうかは個人の感想の問題だが、いちいちリストのコピーが発生するから非機能面では十分に問題になりうる

>>406
そうか？チョットでも知ってればGoはyieldなんてキーワードはサポートしてないので安易な無限長をサポートするわけない。
最初の何も見ずforeach言ってるRustバカと一緒で、コレクションに含まれる高階関数操作で例外を考慮する状況がなぜ正しいのか説明できていない。
それだったらまだ蛇足的に挙げた無限長が扱えない事のほうが欠点だ、ほとんどの状況は高階関数系で例外なんてforeachでもEachでも考慮しない
上のライブラリはチェーン連鎖でコピーが発生するのはその通りだが、例えばfilterにmapをつなげて最後にcollectするような操作は上記の遅延評価や
無限リスト、そして例外とは何の関係もない。言語的な宗教戦争をやってるバカようにしか見えない、とてつもなく迷惑この上ない行為だ

>>407
無限リストを扱うための前提として要素毎のストリーミング処理ができることは必須だから全然関係なくないぞ
なんか勘違いしてるようだが、俺はGoを貶しているのではなくただ>>388のライブラリがヘボいと言っているだけだ
別にyieldがなくたって今のGoで無限リストは実現できるよ

Goならyieldみたいな妙なことしなくてもgoroutine内でループしてチャネルで送りつければいいだけだもんな

妙でない==基本的な機能の中で説明できる
yieldなんてgoto並みに不自然じゃん

>>395
Go一本に掛けるの厳しくないか。

>>405
それは君の理解が間違っている

> Rustの無限長イテレーターはRangeやstd::iter::repeatにおいて無限長を扱えるだけであり、

その部分が完全にウソ
Rustのイテレータは誰もが自由に任意の無限長イテレータを作成可能
そしてその無限長イテレータに対して任意の別のイテレータを好きなだけチェーンさせて動作可能

これはRustのイテレータが中間生成物(リストや配列やベクタ)を作成しないため可能となっている
Goで整備するときもここが重要なポイントとなってくる

無限リストって実際に無限長の何かを使うことは滅多になくて、あくまで遅延リストとして適切に実装されているかどうかの判定基準なんだよね
無限長リストを扱える構造になっていることは、メモリに乗らない巨大なファイルを一行ずつ読むような、文字通りストリーミング処理が必要な状況で非常に有用なんだよ

結局2種類のうちどちらを選ぶか、だけの問題
(A) 遅延処理
　・メソッドチェーン時の中間生成配列などを無くせる
　・無限長も扱える
　・無駄がなく有利
(B) 即時処理
　・メソッドチェーン時の中間生成配列などが必ず必要となる
　・無限長を扱えない
　・(A)よりも不利

RubyのlazyやRustのイテレータはもちろん(A)タイプ
Goでも欲しいのは(A)
(B)タイプのものは検討する必要がない

Go 2のProposalを見ると

https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md
> We do not expect approaches like the C++ STL iterator types to become widely used. In Go that sort of idea is more naturally expressed using an interface type. In C++ terms, using an interface type for an iterator can be seen as carrying an abstraction penalty, in that run-time efficiency will be less than C++ approaches that in effect inline all code; we believe that Go programmers will continue to find that sort of penalty to be acceptable.

って書いてあるけどまあGoはそういう言語で、そこまで最適化にこだわる言語じゃない
最適化にこだわるひとはRustとかC++とか使うべき

>>415
これは遅延リストを否定しているのではない
C++のようなゼロオーバーヘッドは目指さないよ、もしイテレータを抽象化するなら実行時のオーバーヘッドを受け入れて普通にInterface使う想定だよと言っていて、
将来的に>>414の(A)のスタイルのイテレータを導入する可能性は下記の通り肯定している
> As we get more container types, we may develop a standard Iterator interface. That may in turn lead to pressure to modify the language to add some mechanism for using an Iterator with the range clause. That is very speculative, though.

>>411
JavaとPHpだけじゃ不安なんだ

>>417
PHPてw

>>416
つまり将来Go3になる頃には>>414の(A)がGoでも出来るようになる可能性が残されていると

>>417
なんだ、プログラミングは経験者か。
ならGo未経験案件でも収入大幅に減らないならスキル増やすつもりで行っていいかと思うけど。

>>418
案件多いのはPHPなんだぜ涙

>>419
単なるデザインパターンだから今のGoでもできる
イテレータのinterfaceが標準化されてないだけ

>>421
本当に出来るならばなぜGoではやらないの？
速いし便利だしコードも分かりやすくなることが多いため色んな言語で使われているのに

>>422
標準無視のコードで俺スゲーしたい系の人はRustに行っちゃうからだろうね

イテレータを使うようにしたら、こんなふうになるのかな？
https://github.com/Soft/iter
いちいち関数呼び出しすることになるから普段使いにしようとするとパフォーマンス悪くなりそう

もっと最適化されるようになったら良いけどね

RustのイテレータがCのfor文と同じ速度が出るのも最適化された設計と実装によるものだもんね
あとはGo開発陣のやる気次第

>>424
これはダメだね
パフォーマンス以前に、イテレータを閉じる方法がないからファイルをストリーミング処理するようなユースケースに対応できない
ちゃんと言語機能の背景を考慮せずにRustを猿真似しちゃった失敗作だね

何をどう見ても許されてないしロシアが核持ってなかったら、
集団的自衛権をもとに連合軍が作られてプーチン政権が倒されるか、ロシアも同盟を集めて世界大戦に発展してるよ

なんかスレ間違えたわ

いやだいじょうぶだ、つづけろ

>>409
その通り。Goで中間コンテナを作らないようなGeneric版高階関数ライブラリを作ろうと思うと、yieldのような中断じゃなく確かにチャネルの受け渡しになる。
それでfilter->map->collectのようなRust的な中間コンテナを作らないようなコードを書くことになると、中間の加工データの受け渡しはチャネルになるので、Rustで
そのままでは安易に並列化できずにrayonライブラリなどを使うより、遥かに簡単にスケールできる並列化まで踏み込む可能性がある。
これをGoogleはパイプライン処理と呼んでいるが、421の言うように1.18はイテレータの標準化とコレクションの操作の一般化を変更に含めなかっただけ
やる気というか現代のソフトウェア開発は、世に出たら0から255まで揃ってる訳ではなく、小まめな段階リリースだから

おじさんがくるとこうなるのね
本当にこの世から消えて欲しい

この世から消えて欲しいチュウニおじさん

モックって何使ってる？
gomock, testfy, mockery
オススメは？

いらない
インターフェース埋め込みで十分

>>435に一票
Goでモックフレームワークが欲しくなるようなら設計と開発スタイルがおかしい

カバレッジ100%目指さないの？
共通ライブラリのエラーのパスとか

別におすすめじゃないけどgomock使ってる
gomockはinterface{}だらけで静的型チェックが効かないからたまにイラッとする

間違えた
gomockじゃなくてtestifyだ

がーん、週明けで確認したらGCPでホストしているサービス二個ともが、のきなみサーバーエラー500で動いてない
Memorystore の障害なのか？これは

Firestoreのクエリ結果をキャッシュしてるから確かに使ってる

あ、よく考えたらGoスレではスレ違いな話題だったスマン
ホストしてるのはGoだけど

質問
xxxx_test.go は go test だけで、go build からは無視されるとかって本当？
だとすると package xxxx_test とかパッケージを分けるのって意味がない？

あー、テストで xxxx をインポートしてる別パッケージをインポートしたいときに、xxxx からじゃ循環参照としてコンパイルできないから意味はあるのか

ごくまれに package xxxx_test を作ったほうが簡単に解決できることもあるね

*bufio.Scanner とか *os.File といった、interface じゃなく struct な戻り値を返す標準関数で、scanner.Scan() とかの戻り値による分岐をカバレッジしたい

標準関数は関数ポインタによるフックに変更して、モックで差し替えられるようにしたんだけど、関数ポインタのシグネチャが struct を返す形なんで、上記の scanner.Scan() とかを差し替えられない

そこで bufio.NewScanner() を直接に使うのではなく、scanner を interface で返すラッパー関数を作って、そのラッパー関数ポインタをモックで置き換えさせることを考えたりしてるんだけど
…やり過ぎ？(そもそもこの説明で分かるかな？)

そもそも例外なケースのカバレッジのために、そんなクソ複雑なメカニズムを入れるのは、保守性を下げてしまうから本末転倒だろうか？

Go的には、差し替えが必要なんだったらScannerを直接使わずに最小限のアドホックなinterfaceを定義し、
それを関数の引数に受け取るかstructのメンバに持たせるのが筋

>>448
うん、そんな感じ
https://pastebin.pl/view/d979ea5b
該当部分を抜粋
しかし無駄に複雑なコードかなぁと
そこまでする意義はあるのかないのか

>>449
これだけ複雑なのに、os.Open() と s.Err() がエラーを返すパスを通せるだけというのは、
コードの保守性悪化に見合うメリットたりえるのか
そう感じてしまって悩んでる
これが Java ならクラスローダーでプロキシインスタンスに差し替えるという手段で対象コードには手を触れなくて済むから…

>>450
そのへんはGo云々というより設計センスの問題だな
textLinesがhookを持つのではなく、LoadFromの引数にfilenameの代わりにiScannerを渡して、その実装を提供するのは呼び出す側の責任にした方が良いと思う
filenameを受け取る便利関数を提供したいなら、それとは別にLoadFromFileNameみたいな関数作ってFileやScannerをインスタンス化してLoadFromに投げればいい
そうすればインスタンス化の部分とそれを使う部分とでテストケースを分離できるでしょ

そうだな、設計の話だなあ
コードがそこそこの規模になるんだったらとりあえずDI的なことをやったほうがいいよ

普通に自前でScanner作れよ
大して難しい話じゃないだろ

構造体のコンストラクタのコードを見ると必ず構造体のポインタを返していますが、ポインタにするメリットと値を返したときのデメリットを教えて頂きたいです

>>454
受け渡しの際に毎回コピーするのではなく同一のインスタンスを引き回すことを想定している場合、
それを利用者に主張するために値ではなくポインタを返すことが多い
ポインタで受け取ったものをわざわざデリファレンスしてコピーなんて普通あまりしないからね
構造体をオブジェクト指向言語におけるミュータブルなクラスのように使っていると、コピーされると意図せぬ挙動になりやすい

>>453
>>449 見れば分かるがファイル名を受け取ってos.Openして得たFileからScannerを作ってるわけで、これをどうやって差し替えるかという話

>>453
だから、ScannerではなくNewScanner関数をどう差し替えるかという話

>>455
よく分かりました
ありがとうございます

コンパイルするファイル内に設定値も全部入れたいんだけど、
その場合は設定値だけのファイルを読み込むことって可能ですか？
関数にしてmapで返す感じしかないですか？

jsonファイルをgo-assetsとかgo:embedで組み込んで、それをjson.Unmarshal()で構造化データとして使えばいいと思うよ

個人的には設定はビルド時に埋め込むならソース内にjson風にハードコードする派
設定ファイル嫌い

てめーの好き嫌いなんか知ったことじゃない

組み込みjsonをデフォルトとして、カスタム設定ファイルは外部のjsonにする
デフォルトから取り込んでカスタムで上書き
これでjsonからの取り込み部分を一本化できるのでバグを防止できる
ハードコードしてると取り込み部分が共有できない (json文字列を返す関数でもいいんだけど

>>463
組み込み設定は構造体をハードコードし、カスタム設定ファイルはそれをjson等で上書きすればいいだけ
どうせ上書きされるのは極一部の項目だけなんだから、大部分はコンパイル時のチェックによりバグを防止できる

>>464
と、思っちゃうよな
構造体定義して、初期化で初期値書き込んで、それとは別にカスタム設定取り込みコードを書く
対して、構造体定義して、設定取り込みコードを書く
すると設定取り込みには普通にバリデートも書くから初期化での値バグが起きない

>>464
まあ、好きずきの話に近いことは近い
ハードコードした設定値をバリデーターにかけてチェックさせる作りなら解決できなくもない
でも取り込みの各段階でバリデーションしていったほうがミスりにくいと俺は思うから

そんなにバグが怖いならそもそもそんな柔軟な設定ファイル要る？というところを見直すべきでは
汎用的なOSSでも作ってるんでない限り、設定なんぞ環境変数で十分
あとは全部ハードコードすればバリデーションなんか要らん

バグが怖いというより、適切なアナウンスかな
設定のどこが、どう不味いのか

Viperを使え

フレームワークのginでWebアプリ作りたいなと思ってるんですけど、ginの勉強にいい教材ありますか？
Pythonでツール作ったことあるくらいで、Goの基礎は一通りやったくらいのスキルです。

日本語ドキュメント見てもいまいちピンときてません
https://gin-gonic.com/ja/

gin自体が良くないからいい教材なんか無い
Goはnet/httpパッケージを使うんだよ

そうだったのか。。

いやGinでいいだろ
今どきnet/httpだけでWebアプリ作ってるとこなんてねーよ
Gin+Vueとかで作ってみな
5chにいる玄人()のおっさんに惑わされんな

俺はchiがおすすめ

最近いじってないけど
Echoは少数派なの？

>>473
さんきゅー！

gin、chi、echoどれも薄っぺらいんだから対して変わらない
どれでもええわ

echo はcontext の扱いが良くない

Fiberこそ至高

月額報酬が最も高い開発言語ランキング 3位は「Python」、2位は「Go」、1位は？ フリーエンジニア向け仕事仲介サービス調べ

URLを貼らないあたり仕事できなさそう

Goは単価高いけどGoだけ出来ればいいってわけじゃないからなぁ

ECSとかTerraformみたいなクラウド技術も使えて当然だよね？って雰囲気が全体的にある