Go language part 5

1 ：デフォルトの名無しさん：2022/02/27(日) 07:43:20.04 ID:uWHjNeVw.net

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

公式
https://golang.org

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

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

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


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

2 ：デフォルトの名無しさん：2022/02/27(日) 07:45:13.76 ID:uWHjNeVw.net

公式
https://golang.org

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

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

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

3 ：デフォルトの名無しさん：2022/02/27(日) 07:46:00.05 ID:uWHjNeVw.net

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

4 ：デフォルトの名無しさん：2022/02/27(日) 08:59:11.36 ID:PVy06kKY.net

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

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

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

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

5 ：デフォルトの名無しさん：2022/02/27(日) 09:14:34.62 ID:PVy06kKY.net

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

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

6 ：デフォルトの名無しさん：2022/02/27(日) 09:39:32.40 ID:+yReYAPt.net

ちなみに前スレ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でいいの？とは思うけど)

7 ：デフォルトの名無しさん：2022/02/27(日) 10:24:28.50 ID:c+lx/lLr.net

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

8 ：デフォルトの名無しさん：2022/02/27(日) 14:25:03.95 ID:PVy06kKY.net

>>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の方が断然いいね。(後発だから当たり前だけど)

9 ：デフォルトの名無しさん：2022/02/27(日) 15:40:03.99 ID:F0hGMDSU.net

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

10 ：デフォルトの名無しさん：2022/02/27(日) 16:13:39.08 ID:PVy06kKY.net

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

11 ：デフォルトの名無しさん：2022/02/27(日) 16:48:28.74 ID:F0hGMDSU.net

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

12 ：デフォルトの名無しさん：2022/02/27(日) 17:20:40.92 ID:+yReYAPt.net

>>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ということで矛盾はない

13 ：デフォルトの名無しさん：2022/02/27(日) 17:32:40.97 ID:Xl3wWN+O.net

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

14 ：デフォルトの名無しさん：2022/02/27(日) 17:44:54.95 ID:+yReYAPt.net

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

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

15 ：デフォルトの名無しさん：2022/02/27(日) 20:47:56.30 ID:PVy06kKY.net

>>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だと何ら意義を感じ取れなかったわけだ、納得。

16 ：デフォルトの名無しさん：2022/02/27(日) 21:18:41.64 ID:Xl3wWN+O.net

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

17 ：デフォルトの名無しさん：2022/02/27(日) 21:41:54.35 ID:PVy06kKY.net

>>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じゃないかと思うけども。

18 ：デフォルトの名無しさん：2022/02/27(日) 22:00:44.12 ID:PVy06kKY.net

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

_StackMin = 1024

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

19 ：デフォルトの名無しさん：2022/02/27(日) 22:21:07.92 ID:F0hGMDSU.net

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

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

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

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

20 ：デフォルトの名無しさん：2022/02/27(日) 23:03:35.02 ID:PVy06kKY.net

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

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

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

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

21 ：デフォルトの名無しさん：2022/02/28(月) 00:19:43.12 ID:BEDnUIJv.net

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

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

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

22 ：デフォルトの名無しさん：2022/02/28(月) 00:24:03.28 ID:3SjSMxvC.net

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

23 ：デフォルトの名無しさん：2022/02/28(月) 00:35:47.82 ID:EeqSDih1.net

>>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に変更は出来るか確認出来ると思うけど、面倒なのでそこまではしない。

24 ：デフォルトの名無しさん：2022/02/28(月) 01:17:28.02 ID:qPXeLVFX.net

反論はそこだけ？

25 ：デフォルトの名無しさん：2022/02/28(月) 01:18:12.57 ID:qPXeLVFX.net

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

26 ：デフォルトの名無しさん：2022/02/28(月) 01:33:25.66 ID:EeqSDih1.net

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

27 ：デフォルトの名無しさん：2022/02/28(月) 14:52:59.85 ID:xNWA4laA.net

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

28 ：デフォルトの名無しさん：2022/02/28(月) 15:07:48.45 ID:xNWA4laA.net

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でも投下してこい。それすら出来ないなら
お前は不当に他言語を卑下してる卑怯者だぜ。どうせボコボコにされる

29 ：デフォルトの名無しさん：2022/02/28(月) 15:52:51.20 ID:BKvqTAvD.net

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

30 ：デフォルトの名無しさん：2022/02/28(月) 19:32:24.79 ID:7SSxP2tw.net

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

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

31 ：デフォルトの名無しさん：2022/02/28(月) 19:53:28.26 ID:qPXeLVFX.net

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

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

32 ：デフォルトの名無しさん：2022/02/28(月) 20:02:32.92 ID:pJo2hpV4.net

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

33 ：デフォルトの名無しさん：2022/02/28(月) 20:20:38.66 ID:qPXeLVFX.net

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

34 ：デフォルトの名無しさん：2022/02/28(月) 21:17:53.06 ID:qPXeLVFX.net

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

35 ：デフォルトの名無しさん：2022/02/28(月) 21:21:31.32 ID:BEDnUIJv.net

>>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で済むのなら、速くてコードも綺麗だが、
それ以上なら遅くなるという事。

36 ：デフォルトの名無しさん：2022/02/28(月) 21:59:11.85 ID:BEDnUIJv.net

>>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がそれぞれ「別空間」で動いていると勘違いしてるからだと思うのだが、それはない。
重ならないようにコンパイラが割り当ててくれてるだけで、同一空間だ。

37 ：デフォルトの名無しさん：2022/02/28(月) 22:40:05.81 ID:EeqSDih1.net

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

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

38 ：デフォルトの名無しさん：2022/02/28(月) 23:44:04.73 ID:7SSxP2tw.net

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

39 ：デフォルトの名無しさん：2022/03/01(火) 00:33:28.48 ID:OK3fXqHC.net

>>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ランタイムってカーネルモードで動いてたりする？それなら話は違ってくるが)

40 ：デフォルトの名無しさん：2022/03/01(火) 00:41:23.65 ID:LFBfp70W.net

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

41 ：デフォルトの名無しさん：2022/03/01(火) 00:47:33.18 ID:LFBfp70W.net

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

42 ：デフォルトの名無しさん：2022/03/01(火) 00:59:49.19 ID:OK3fXqHC.net

>>41
君は27？

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

43 ：デフォルトの名無しさん：2022/03/01(火) 01:09:17.06 ID:MT73K7Vw.net

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

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

44 ：デフォルトの名無しさん：2022/03/01(火) 01:58:03.77 ID:OK3fXqHC.net

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

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


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

45 ：デフォルトの名無しさん：2022/03/01(火) 02:03:09.66 ID:LFBfp70W.net

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

46 ：デフォルトの名無しさん：2022/03/01(火) 06:28:53.29 ID:MT73K7Vw.net

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

47 ：デフォルトの名無しさん：2022/03/01(火) 08:12:28.20 ID:aFcqKDVR.net

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

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

48 ：デフォルトの名無しさん：2022/03/01(火) 09:03:50.60 ID:cUOzOJ3p.net

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

49 ：デフォルトの名無しさん：2022/03/01(火) 10:19:27.41 ID:NXJnvaYt.net

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

50 ：デフォルトの名無しさん：2022/03/01(火) 11:47:54.41 ID:IZ7MnaYC.net

気になるだろ…

51 ：デフォルトの名無しさん：2022/03/01(火) 11:58:08.47 ID:MT73K7Vw.net

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

52 ：デフォルトの名無しさん：2022/03/02(水) 00:08:09.90 ID:A3d3IcmJ.net

>>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個のメンバをチェック/更新するコードを通す事になる
＝起動/停止時に「税金」的に数百サイクルは必要、となる。

53 ：デフォルトの名無しさん：2022/03/02(水) 00:08:36.44 ID:A3d3IcmJ.net

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

54 ：デフォルトの名無しさん：2022/03/02(水) 01:42:28.65 ID:WG8WfuCM.net

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

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

55 ：デフォルトの名無しさん：2022/03/02(水) 03:09:53.11 ID:re9dUtRi.net

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

56 ：デフォルトの名無しさん：2022/03/02(水) 03:13:52.18 ID:re9dUtRi.net

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

57 ：デフォルトの名無しさん：2022/03/02(水) 03:34:51.80 ID:S8+3WyDZ.net

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

58 ：デフォルトの名無しさん：2022/03/02(水) 04:07:09.47 ID:re9dUtRi.net

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

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

59 ：デフォルトの名無しさん：2022/03/02(水) 06:39:48.32 ID:re9dUtRi.net

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

60 ：デフォルトの名無しさん：2022/03/02(水) 06:40:13.75 ID:re9dUtRi.net

誤爆

61 ：デフォルトの名無しさん：2022/03/02(水) 07:09:40.23 ID:fOFAuz8H.net

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

62 ：デフォルトの名無しさん：2022/03/02(水) 08:03:15.38 ID:re9dUtRi.net

興味があるならどこの誤爆かだけ書いておく
https://mevius.5ch.net/test/read.cgi/tech/1638086359/447

63 ：デフォルトの名無しさん：2022/03/02(水) 09:14:57.44 ID:WG8WfuCM.net

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

64 ：デフォルトの名無しさん：2022/03/02(水) 12:54:03.99 ID:re9dUtRi.net

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

65 ：デフォルトの名無しさん：2022/03/02(水) 14:10:00.74 ID:S8+3WyDZ.net

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

66 ：デフォルトの名無しさん：2022/03/02(水) 15:24:10.33 ID:mFEJLP5N.net

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

67 ：デフォルトの名無しさん：2022/03/02(水) 16:34:57.55 ID:re9dUtRi.net

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

68 ：デフォルトの名無しさん：2022/03/02(水) 16:54:30.69 ID:S8+3WyDZ.net

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

69 ：デフォルトの名無しさん：2022/03/02(水) 17:04:08.05 ID:re9dUtRi.net

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

70 ：デフォルトの名無しさん：2022/03/02(水) 17:33:02.75 ID:S8+3WyDZ.net

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

71 ：デフォルトの名無しさん：2022/03/02(水) 23:43:26.42 ID:A3d3IcmJ.net

>>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のは遅い、というより動くようにしか出来てない。（そして非同期）
だからそこそこ速い同期チャネルが絶対不可欠なアプリがあれば、と思って考えてみたが、やっぱり俺は思いつかないね。

72 ：デフォルトの名無しさん：2022/03/03(木) 00:21:30.68 ID:r4JzAqw4.net

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

73 ：デフォルトの名無しさん：2022/03/03(木) 00:23:05.45 ID:r4JzAqw4.net

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

74 ：デフォルトの名無しさん：2022/03/03(木) 00:56:08.72 ID:hTxF5AaQ.net

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

75 ：デフォルトの名無しさん：2022/03/03(木) 11:28:44.36 ID:6vq1sG3T.net

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

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

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

76 ：デフォルトの名無しさん：2022/03/03(木) 11:44:33.79 ID:6vq1sG3T.net

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

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

77 ：デフォルトの名無しさん：2022/03/03(木) 13:27:09.03 ID:6vq1sG3T.net

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

78 ：デフォルトの名無しさん：2022/03/03(木) 18:20:17.50 ID:qZcuxxc0.net

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

79 ：デフォルトの名無しさん：2022/03/03(木) 18:47:19.32 ID:3iRkjbfP.net

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

やっぱＧＯは速いね

80 ：デフォルトの名無しさん：2022/03/03(木) 20:31:53.54 ID:DvSNmo59.net

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


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

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

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

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

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

81 ：デフォルトの名無しさん：2022/03/03(木) 20:56:08.85 ID:hTxF5AaQ.net

>>80
coroutine

82 ：デフォルトの名無しさん：2022/03/03(木) 21:23:47.28 ID:DvSNmo59.net

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

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

83 ：デフォルトの名無しさん：2022/03/03(木) 21:54:21.27 ID:oaR2p1R0.net

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

84 ：デフォルトの名無しさん：2022/03/03(木) 22:06:45.01 ID:6vq1sG3T.net

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

85 ：デフォルトの名無しさん：2022/03/03(木) 22:22:12.59 ID:y+UC/h2K.net

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

86 ：デフォルトの名無しさん：2022/03/03(木) 22:27:14.50 ID:6vq1sG3T.net

あーすまん

87 ：デフォルトの名無しさん：2022/03/03(木) 23:09:26.23 ID:1IkAc1iQ.net

いいってことよ

88 ：デフォルトの名無しさん：2022/03/03(木) 23:29:47.34 ID:Rf6M0oqn.net

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

89 ：デフォルトの名無しさん：2022/03/03(木) 23:35:59.34 ID:vRr517/c.net

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

90 ：デフォルトの名無しさん：2022/03/04(金) 00:05:33.31 ID:4zB49VIz.net

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

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

91 ：デフォルトの名無しさん：2022/03/04(金) 07:00:31.23 ID:Ah997PWW.net

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

92 ：デフォルトの名無しさん：2022/03/04(金) 11:17:26.10 ID:2Vo/u60a.net

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

93 ：デフォルトの名無しさん：2022/03/04(金) 13:21:46.53 ID:JMvj/uct.net

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

94 ：デフォルトの名無しさん：2022/03/04(金) 15:27:21.82 ID:e8gLPWot.net

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

95 ：デフォルトの名無しさん：2022/03/04(金) 15:37:03.27 ID:e8gLPWot.net

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

96 ：デフォルトの名無しさん：2022/03/04(金) 15:39:19.04 ID:4zB49VIz.net

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

言語比較がしたいなら↓へ
次世代言語23 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1638086359/

97 ：デフォルトの名無しさん：2022/03/04(金) 15:48:00.84 ID:e8gLPWot.net

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

98 ：デフォルトの名無しさん：2022/03/04(金) 15:52:46.98 ID:4zB49VIz.net

>>97
>>96

99 ：デフォルトの名無しさん：2022/03/04(金) 16:07:29.53 ID:wUg1CCTJ.net

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

100 ：デフォルトの名無しさん：2022/03/04(金) 16:41:14.71 ID:2tyOtSaX.net

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

101 ：デフォルトの名無しさん：2022/03/04(金) 17:03:59.90 ID:k6Ka/u1X.net

>>100
>>96

102 ：デフォルトの名無しさん：2022/03/04(金) 17:23:53.33 ID:wUg1CCTJ.net

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

103 ：デフォルトの名無しさん：2022/03/04(金) 18:00:31.30 ID:JMvj/uct.net

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

104 ：デフォルトの名無しさん：2022/03/04(金) 18:09:02.15 ID:4zB49VIz.net

>>103
>>96

105 ：デフォルトの名無しさん：2022/03/04(金) 18:20:16.68 ID:rY1xxy8+.net

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

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

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

106 ：デフォルトの名無しさん：2022/03/04(金) 18:21:39.81 ID:rY1xxy8+.net

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

107 ：デフォルトの名無しさん：2022/03/04(金) 19:18:02.80 ID:rpzx0HJl.net

Rustに移行すべきでは？

108 ：デフォルトの名無しさん：2022/03/04(金) 19:23:47.26 ID:L8b5lnOt.net

>>107
>>96

109 ：デフォルトの名無しさん：2022/03/04(金) 19:26:20.71 ID:gF7ObJcT.net

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

110 ：デフォルトの名無しさん：2022/03/04(金) 19:27:58.27 ID:2tyOtSaX.net

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

111 ：デフォルトの名無しさん：2022/03/04(金) 19:30:36.16 ID:tHN8vl7V.net

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

112 ：デフォルトの名無しさん：2022/03/04(金) 19:41:10.06 ID:aLx0Ek8o.net

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

113 ：デフォルトの名無しさん：2022/03/04(金) 20:33:03.39 ID:3r4UVkMf.net

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

114 ：デフォルトの名無しさん：2022/03/04(金) 20:34:31.83 ID:JMvj/uct.net

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

115 ：デフォルトの名無しさん：2022/03/04(金) 20:36:30.45 ID:JMvj/uct.net

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

116 ：デフォルトの名無しさん：2022/03/04(金) 20:41:31.76 ID:e8gLPWot.net

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

117 ：デフォルトの名無しさん：2022/03/06(日) 19:22:52.31 ID:oq6skpEb.net

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

118 ：デフォルトの名無しさん：2022/03/06(日) 19:40:37.34 ID:UDoFVzdd.net

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

119 ：デフォルトの名無しさん：2022/03/06(日) 21:05:29.02 ID:Rcp3w968.net

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

120 ：デフォルトの名無しさん：2022/03/06(日) 21:06:19.97 ID:D8Ku8/qP.net

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

121 ：デフォルトの名無しさん：2022/03/06(日) 23:38:19.72 ID:0i0EE3CI.net

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

122 ：デフォルトの名無しさん：2022/03/07(月) 00:39:41.57 ID:kssBp/wX.net

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

123 ：デフォルトの名無しさん：2022/03/07(月) 00:44:33.34 ID:otYxLRpr.net

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

124 ：デフォルトの名無しさん：2022/03/07(月) 08:43:53.50 ID:s5yg+NZx.net

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

125 ：デフォルトの名無しさん：2022/03/07(月) 08:55:53.15 ID:q3eUi8ps.net

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

126 ：デフォルトの名無しさん：2022/03/07(月) 09:07:37.44 ID:MlZ6kc9H.net

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

127 ：デフォルトの名無しさん：2022/03/07(月) 10:35:08.70 ID:otYxLRpr.net

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

128 ：デフォルトの名無しさん：2022/03/07(月) 11:00:36.82 ID:s5yg+NZx.net

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

129 ：デフォルトの名無しさん：2022/03/07(月) 12:03:12.32 ID:2hk0Nxfy.net

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

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

130 ：デフォルトの名無しさん：2022/03/07(月) 14:11:55.83 ID:SxK5Ewlv.net

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

131 ：デフォルトの名無しさん：2022/03/07(月) 15:56:13.82 ID:kssBp/wX.net

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

132 ：デフォルトの名無しさん：2022/03/07(月) 16:06:10.52 ID:won3nIuN.net

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

133 ：デフォルトの名無しさん：2022/03/07(月) 17:12:28.11 ID:otYxLRpr.net

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

134 ：デフォルトの名無しさん：2022/03/07(月) 17:14:22.08 ID:otYxLRpr.net

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

135 ：デフォルトの名無しさん：2022/03/07(月) 17:54:54.88 ID:I/Rzn0lH.net

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

136 ：デフォルトの名無しさん：2022/03/07(月) 17:55:43.77 ID:s5yg+NZx.net

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

137 ：デフォルトの名無しさん：2022/03/07(月) 18:08:24.58 ID:kssBp/wX.net

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

138 ：デフォルトの名無しさん：2022/03/07(月) 18:28:02.87 ID:LwrKIEpB.net

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

139 ：デフォルトの名無しさん：2022/03/07(月) 19:04:12.73 ID:SxK5Ewlv.net

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

140 ：デフォルトの名無しさん：2022/03/07(月) 21:22:24.00 ID:kssBp/wX.net

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

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

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

141 ：デフォルトの名無しさん：2022/03/08(火) 00:26:03.19 ID:4ZhMXz51.net

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

142 ：デフォルトの名無しさん：2022/03/08(火) 02:39:31.07 ID:59Y5NzBD.net

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

143 ：デフォルトの名無しさん：2022/03/08(火) 07:57:09.39 ID:5mhqUY+j.net

Rustのことは忘れて

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

144 ：デフォルトの名無しさん：2022/03/08(火) 08:13:34.51 ID:TkXU//aU.net

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

145 ：デフォルトの名無しさん：2022/03/08(火) 08:17:46.56 ID:TkXU//aU.net

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

146 ：デフォルトの名無しさん：2022/03/08(火) 11:48:16.95 ID:5mhqUY+j.net

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

147 ：デフォルトの名無しさん：2022/03/09(水) 17:10:13.11 ID:ZVLrsraT.net

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

148 ：デフォルトの名無しさん：2022/03/09(水) 18:57:40.54 ID:o8UVaHTv.net

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

149 ：デフォルトの名無しさん：2022/03/09(水) 19:25:13.15 ID:HVZ+1br4.net

まーた(ry

150 ：デフォルトの名無しさん：2022/03/09(水) 19:26:23.08 ID:BXzHKdLE.net

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

151 ：デフォルトの名無しさん：2022/03/09(水) 19:37:39.05 ID:o8UVaHTv.net

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

152 ：デフォルトの名無しさん：2022/03/09(水) 19:52:31.32 ID:2cDF56sN.net

>>151
>>96

153 ：デフォルトの名無しさん：2022/03/09(水) 23:07:53.69 ID:JjWHIxM6.net

>>151
Goの欠点だな

154 ：デフォルトの名無しさん：2022/03/09(水) 23:15:13.75 ID:kryzQ0zI.net

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

155 ：デフォルトの名無しさん：2022/03/09(水) 23:56:47.85 ID:jIAUAwVH.net

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

156 ：デフォルトの名無しさん：2022/03/10(木) 00:16:27.61 ID:EmAP5Zv6.net

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

157 ：デフォルトの名無しさん：2022/03/10(木) 08:01:20.84 ID:p2fYNkNX.net

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

158 ：デフォルトの名無しさん：2022/03/10(木) 08:05:56.68 ID:EmAP5Zv6.net

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

159 ：デフォルトの名無しさん：2022/03/10(木) 08:06:54.36 ID:EmAP5Zv6.net

別に行かない

160 ：デフォルトの名無しさん：2022/03/10(木) 11:26:24.44 ID:yulIAHTW.net

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

161 ：デフォルトの名無しさん：2022/03/10(木) 14:34:23.63 ID:oQD86hL5.net

JAVAから来ました

162 ：デフォルトの名無しさん：2022/03/10(木) 23:25:33.20 ID:mPwUhQcz.net

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

163 ：デフォルトの名無しさん：2022/03/11(金) 04:48:59.22 ID:/mQhQdeo.net

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

164 ：デフォルトの名無しさん：2022/03/11(金) 10:28:51.56 ID:MsCX3gC/.net

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

165 ：デフォルトの名無しさん：2022/03/11(金) 11:06:27.12 ID:kr68tprG.net

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

166 ：デフォルトの名無しさん：2022/03/11(金) 11:39:54.49 ID:H8qFXNfY.net

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

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

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

167 ：デフォルトの名無しさん：2022/03/11(金) 11:59:46.52 ID:0bHD9k1s.net

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

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

168 ：デフォルトの名無しさん：2022/03/11(金) 12:02:29.15 ID:0bHD9k1s.net

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

169 ：デフォルトの名無しさん：2022/03/11(金) 12:17:23.16 ID:YhXLzsgi.net

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

170 ：デフォルトの名無しさん：2022/03/11(金) 12:19:29.55 ID:YhXLzsgi.net

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

171 ：デフォルトの名無しさん：2022/03/11(金) 12:42:59.72 ID:MsCX3gC/.net

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

172 ：デフォルトの名無しさん：2022/03/11(金) 13:38:23.24 ID:XWreYn/x.net

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

173 ：デフォルトの名無しさん：2022/03/11(金) 13:49:54.80 ID:uv7nfwNg.net

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

174 ：デフォルトの名無しさん：2022/03/11(金) 14:38:59.33 ID:2kEBQcz7.net

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

175 ：デフォルトの名無しさん：2022/03/11(金) 14:45:54.90 ID:laeBnhbM.net

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

176 ：デフォルトの名無しさん：2022/03/11(金) 14:48:37.14 ID:H8qFXNfY.net

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

177 ：デフォルトの名無しさん：2022/03/11(金) 19:15:19.80 ID:qrl8XqzC.net

>>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/

178 ：デフォルトの名無しさん：2022/03/11(金) 20:08:22.23 ID:o63L8Mvt.net

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

179 ：デフォルトの名無しさん：2022/03/11(金) 20:56:16.13 ID:QqXcHrRr.net

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

180 ：デフォルトの名無しさん：2022/03/11(金) 21:03:32.08 ID:parWzd9L.net

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

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

181 ：デフォルトの名無しさん：2022/03/11(金) 21:17:23.70 ID:o63L8Mvt.net

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

182 ：デフォルトの名無しさん：2022/03/11(金) 21:27:24.13 ID:uv7nfwNg.net

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

183 ：デフォルトの名無しさん：2022/03/11(金) 21:36:55.19 ID:o63L8Mvt.net

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

184 ：デフォルトの名無しさん：2022/03/11(金) 21:58:49.55 ID:qrl8XqzC.net

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

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


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

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

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

185 ：デフォルトの名無しさん：2022/03/11(金) 22:23:28.57 ID:wdcjWAJU.net

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

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

186 ：デフォルトの名無しさん：2022/03/11(金) 22:27:06.80 ID:/JvA5shV.net

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

187 ：デフォルトの名無しさん：2022/03/11(金) 22:57:33.99 ID:qrl8XqzC.net

>>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には生き残る理由がない。

188 ：デフォルトの名無しさん：2022/03/11(金) 23:09:09.74 ID:egx2H9Pr.net

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

189 ：デフォルトの名無しさん：2022/03/11(金) 23:13:16.62 ID:/JvA5shV.net

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

190 ：デフォルトの名無しさん：2022/03/11(金) 23:43:25.63 ID:qrl8XqzC.net

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


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

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

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

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

191 ：デフォルトの名無しさん：2022/03/11(金) 23:50:45.41 ID:/JvA5shV.net

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

192 ：デフォルトの名無しさん：2022/03/12(土) 00:13:31.67 ID:JgaGU6xu.net

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

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

193 ：デフォルトの名無しさん：2022/03/12(土) 00:39:34.87 ID:MeH0OP6r.net

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

194 ：デフォルトの名無しさん：2022/03/12(土) 01:12:13.25 ID:jQJpzSFj.net

Go の G の字もないなｗ

195 ：デフォルトの名無しさん：2022/03/12(土) 01:23:48.74 ID:SUJjbHcC.net

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

196 ：デフォルトの名無しさん：2022/03/12(土) 01:28:54.16 ID:JgaGU6xu.net

>>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年間。

197 ：デフォルトの名無しさん：2022/03/12(土) 03:16:10.27 ID:JxEFMwOe.net

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

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

198 ：デフォルトの名無しさん：2022/03/12(土) 04:40:23.33 ID:ykq+YJH5.net

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

199 ：デフォルトの名無しさん：2022/03/12(土) 04:49:23.73 ID:ykq+YJH5.net

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

200 ：デフォルトの名無しさん：2022/03/12(土) 04:52:53.03 ID:ykq+YJH5.net

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

201 ：デフォルトの名無しさん：2022/03/12(土) 05:00:12.51 ID:ykq+YJH5.net

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

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

202 ：デフォルトの名無しさん：2022/03/12(土) 06:14:51.35 ID:f9B4ek7q.net

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

203 ：デフォルトの名無しさん：2022/03/12(土) 08:30:46.88 ID:JgaGU6xu.net

>>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の連中はすさまじいエコーチェンバーの中で生活してる事は分かった。

204 ：デフォルトの名無しさん：2022/03/12(土) 08:34:30.70 ID:SV7jSkht.net

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

205 ：デフォルトの名無しさん：2022/03/12(土) 09:40:04.46 ID:aEfI8PjB.net

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

206 ：デフォルトの名無しさん：2022/03/12(土) 12:00:36.41 ID:MMCseHWC.net

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

207 ：デフォルトの名無しさん：2022/03/12(土) 12:22:07.70 ID:EqbJSpHR.net

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

208 ：デフォルトの名無しさん：2022/03/12(土) 12:34:33.53 ID:ARhhT+a7.net

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

209 ：デフォルトの名無しさん：2022/03/12(土) 12:59:10.90 ID:6Ov0/1Y8.net

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

210 ：デフォルトの名無しさん：2022/03/12(土) 13:13:55.79 ID:4DPn029u.net

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

211 ：デフォルトの名無しさん：2022/03/12(土) 13:17:12.31 ID:IpH8+wiy.net

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

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

212 ：デフォルトの名無しさん：2022/03/12(土) 13:29:40.57 ID:JgaGU6xu.net

>>96 読んでみたが、なるほどここと同じような話が展開されてる。
ただ、C11に移行しようとしてるじゃないか。 >>202
> https://mevius.5ch.net/test/read.cgi/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と同じ。
(&*が既に使われてるから%^になってて初見で拒絶されるのは仕様）

213 ：デフォルトの名無しさん：2022/03/12(土) 13:30:00.30 ID:JgaGU6xu.net

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

214 ：デフォルトの名無しさん：2022/03/12(土) 13:48:18.60 ID:ARhhT+a7.net

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

215 ：デフォルトの名無しさん：2022/03/12(土) 18:45:21.44 ID:IpH8+wiy.net

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

216 ：デフォルトの名無しさん：2022/03/13(日) 17:26:43.65 ID:fVzSesSr.net

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

217 ：デフォルトの名無しさん：2022/03/15(火) 11:20:02.60 ID:9ud1N6mP.net

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

218 ：デフォルトの名無しさん：2022/03/15(火) 11:47:39.11 ID:UpdRUhUR.net

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

219 ：デフォルトの名無しさん：2022/03/15(火) 11:58:47.19 ID:9ud1N6mP.net

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

220 ：デフォルトの名無しさん：2022/03/15(火) 12:36:58.99 ID:sRZMI6dS.net

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

221 ：デフォルトの名無しさん：2022/03/15(火) 13:34:26.14 ID:DIDzUA9i.net

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

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

222 ：デフォルトの名無しさん：2022/03/15(火) 14:08:20.21 ID:/twmJcjK.net

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

223 ：デフォルトの名無しさん：2022/03/15(火) 15:44:18.88 ID:DIDzUA9i.net

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

224 ：デフォルトの名無しさん：2022/03/15(火) 15:45:27.48 ID:DIDzUA9i.net

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

225 ：デフォルトの名無しさん：2022/03/16(水) 12:58:38.59 ID:7fdw8GJ5.net

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

226 ：デフォルトの名無しさん：2022/03/17(木) 00:28:51.50 ID:+BzvG1OL.net

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

227 ：デフォルトの名無しさん：2022/03/17(木) 00:57:28.83 ID:R5Hf13zE.net

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

228 ：デフォルトの名無しさん：2022/03/17(木) 01:41:25.22 ID:bsoficKO.net

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

229 ：デフォルトの名無しさん：2022/03/17(木) 01:44:14.40 ID:+BzvG1OL.net

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

230 ：デフォルトの名無しさん：2022/03/17(木) 03:24:50.03 ID:OxdqHDsn.net

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

231 ：デフォルトの名無しさん：2022/03/17(木) 22:55:16.78 ID:fLlxA/2d.net

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

232 ：デフォルトの名無しさん：2022/03/19(土) 14:59:48.35 ID:lmd9ivJq.net

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

233 ：デフォルトの名無しさん：2022/03/27(日) 19:47:35.42 ID:4kGrQ90w.net

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

234 ：デフォルトの名無しさん：2022/03/27(日) 20:03:34.05 ID:AzR4xInv.net

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

235 ：デフォルトの名無しさん：2022/03/28(月) 00:04:31.98 ID:9wMV4I/Y.net

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

236 ：デフォルトの名無しさん：2022/04/01(金) 09:14:02.94 ID:Z5kUzNXs.net

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

237 ：デフォルトの名無しさん：2022/04/01(金) 10:24:23.29 ID:Z5kUzNXs.net

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

238 ：デフォルトの名無しさん：2022/04/01(金) 15:58:41.67 ID:Z5kUzNXs.net

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

239 ：デフォルトの名無しさん：2022/04/01(金) 16:36:14.26 ID:CvDUeZYP.net

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

240 ：デフォルトの名無しさん：2022/04/01(金) 17:16:02.47 ID:Z5kUzNXs.net

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

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

241 ：デフォルトの名無しさん：2022/04/01(金) 17:22:16.71 ID:Nf7Dhk5p.net

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

242 ：デフォルトの名無しさん：2022/04/01(金) 17:23:53.64 ID:Z5kUzNXs.net

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

243 ：デフォルトの名無しさん：2022/04/01(金) 17:39:03.75 ID:LyJwVbZX.net

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

244 ：デフォルトの名無しさん：2022/04/01(金) 18:48:56.14 ID:Z5kUzNXs.net

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

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

245 ：デフォルトの名無しさん：2022/04/01(金) 18:51:47.52 ID:LyJwVbZX.net

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

246 ：デフォルトの名無しさん：2022/04/01(金) 18:55:28.61 ID:LyJwVbZX.net

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

247 ：デフォルトの名無しさん：2022/04/01(金) 19:00:06.78 ID:Z5kUzNXs.net

あと珍妙に思えるような気もしなくもない文章が
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を制約型推論の最終結果とする、でいいのかなあ

248 ：デフォルトの名無しさん：2022/04/01(金) 19:06:19.64 ID:Z5kUzNXs.net

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

249 ：デフォルトの名無しさん：2022/04/01(金) 20:49:31.03 ID:5iHnQC+v.net

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

250 ：デフォルトの名無しさん：2022/04/01(金) 21:03:43.90 ID:Nf7Dhk5p.net

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

251 ：デフォルトの名無しさん：2022/04/01(金) 21:14:52.99 ID:jxgGur0i.net

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

252 ：デフォルトの名無しさん：2022/04/01(金) 23:17:37.92 ID:Z5kUzNXs.net

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

253 ：デフォルトの名無しさん：2022/04/01(金) 23:32:09.14 ID:Z5kUzNXs.net

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

254 ：デフォルトの名無しさん：2022/04/01(金) 23:56:13.72 ID:auc7zK9Q.net

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

255 ：デフォルトの名無しさん：2022/04/02(土) 00:13:08.30 ID:YOvjIKEd.net

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

256 ：デフォルトの名無しさん：2022/04/02(土) 01:04:35.98 ID:m+vvtGqp.net

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

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

257 ：デフォルトの名無しさん：2022/04/02(土) 02:22:24.01 ID:xHH5TZmF.net

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

258 ：デフォルトの名無しさん：2022/04/02(土) 05:33:45.87 ID:tnnDyMVL.net

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

259 ：デフォルトの名無しさん：2022/04/02(土) 06:10:04.85 ID:BAqmRjl3.net

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

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

260 ：デフォルトの名無しさん：2022/04/02(土) 06:14:33.15 ID:BAqmRjl3.net

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

261 ：デフォルトの名無しさん：2022/04/02(土) 06:20:24.88 ID:tnnDyMVL.net

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

262 ：デフォルトの名無しさん：2022/04/02(土) 06:27:00.86 ID:BAqmRjl3.net

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

263 ：デフォルトの名無しさん：2022/04/02(土) 12:45:39.96 ID:BAqmRjl3.net

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

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

264 ：デフォルトの名無しさん：2022/04/02(土) 13:41:36.50 ID:m+vvtGqp.net

おじさん消えて

265 ：デフォルトの名無しさん：2022/04/02(土) 14:52:46.43 ID:YPKLSNfQ.net

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

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

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

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

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

これが大原則

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

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

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

266 ：デフォルトの名無しさん：2022/04/02(土) 15:00:01.25 ID:YPKLSNfQ.net

generics は、Rust にもあるから

267 ：デフォルトの名無しさん：2022/04/02(土) 16:04:50.21 ID:4HZvLFXe.net

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

268 ：デフォルトの名無しさん：2022/04/02(土) 16:31:43.87 ID:BAqmRjl3.net

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

269 ：デフォルトの名無しさん：2022/04/02(土) 16:33:42.78 ID:vRBLByq+.net

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

270 ：デフォルトの名無しさん：2022/04/02(土) 17:47:27.46 ID:K3ABhaa3.net

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

271 ：デフォルトの名無しさん：2022/04/02(土) 18:14:01.71 ID:+a+ANJVh.net

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

272 ：デフォルトの名無しさん：2022/04/02(土) 18:30:53.19 ID:FvAcb10F.net

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

273 ：デフォルトの名無しさん：2022/04/03(日) 08:15:05.26 ID:YAESyHF/.net

>>270

274 ：デフォルトの名無しさん：2022/04/04(月) 01:10:11.27 ID:2YLoUSsE.net

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

275 ：デフォルトの名無しさん：2022/04/04(月) 08:08:03.11 ID:dKoFZlg8.net

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

276 ：デフォルトの名無しさん：2022/04/04(月) 08:11:46.50 ID:GOjfDlOJ.net

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

277 ：デフォルトの名無しさん：2022/04/04(月) 08:24:54.17 ID:dKoFZlg8.net

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

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

278 ：デフォルトの名無しさん：2022/04/04(月) 08:27:50.29 ID:dKoFZlg8.net

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

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

279 ：デフォルトの名無しさん：2022/04/04(月) 09:23:36.60 ID:2YLoUSsE.net

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

280 ：デフォルトの名無しさん：2022/04/04(月) 09:37:43.77 ID:iJ6pcz9H.net

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

281 ：デフォルトの名無しさん：2022/04/04(月) 16:06:42.84 ID:yu8UGqfF.net

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

282 ：デフォルトの名無しさん：2022/04/04(月) 21:28:48.99 ID:dKoFZlg8.net

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

283 ：デフォルトの名無しさん：2022/04/06(水) 03:19:36.92 ID:kWgOKN13.net

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

284 ：デフォルトの名無しさん：2022/04/06(水) 03:39:50.83 ID:PLeFIjOG.net

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

285 ：デフォルトの名無しさん：2022/04/06(水) 03:46:30.81 ID:wPZ6Wy+h.net

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

286 ：デフォルトの名無しさん：2022/04/06(水) 08:16:27.53 ID:+qYubc5F.net

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


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

287 ：デフォルトの名無しさん：2022/04/09(土) 15:23:53.03 ID:dkIcbWyn.net

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

288 ：デフォルトの名無しさん：2022/04/09(土) 15:41:49.71 ID:s1DYUnBK.net

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

289 ：デフォルトの名無しさん：2022/04/09(土) 17:58:03.72 ID:P2GNRI+e.net

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

290 ：デフォルトの名無しさん：2022/04/09(土) 18:00:08.15 ID:P2GNRI+e.net

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

291 ：デフォルトの名無しさん：2022/04/09(土) 18:01:35.73 ID:P2GNRI+e.net

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

292 ：デフォルトの名無しさん：2022/04/09(土) 18:06:47.65 ID:P2GNRI+e.net

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

293 ：デフォルトの名無しさん：2022/04/09(土) 18:09:17.78 ID:9GFACAI5.net

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

294 ：デフォルトの名無しさん：2022/04/09(土) 18:18:21.65 ID:dkIcbWyn.net

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

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

295 ：デフォルトの名無しさん：2022/04/09(土) 18:38:01.40 ID:P2GNRI+e.net

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

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

296 ：デフォルトの名無しさん：2022/04/09(土) 20:29:16.25 ID:ALVqghU/.net

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

297 ：デフォルトの名無しさん：2022/04/11(月) 18:36:29 ID:E/+8nzoc.net

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

298 ：デフォルトの名無しさん：2022/04/12(火) 08:34:50.45 ID:rpFygdst.net

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

299 ：デフォルトの名無しさん：2022/04/12(火) 15:46:20.46 ID:3xd8M5tv.net

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

300 ：デフォルトの名無しさん：2022/04/13(水) 23:15:55 ID:6kED4GhE.net

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

301 ：デフォルトの名無しさん：2022/04/14(木) 02:13:38.39 ID:YSgRDOi4.net

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

302 ：デフォルトの名無しさん：2022/04/14(木) 02:38:48.48 ID:dvnOt0Zc.net

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

303 ：デフォルトの名無しさん：2022/04/14(木) 17:51:07 ID:mUuUh3T2.net

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

304 ：デフォルトの名無しさん：2022/04/14(木) 20:18:22.21 ID:biX3AFA3.net

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

305 ：デフォルトの名無しさん：2022/04/15(金) 18:58:00.93 ID:Or3DM27q.net

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

306 ：デフォルトの名無しさん：2022/04/16(土) 23:24:07.47 ID:3G5k9Hnh.net

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

307 ：デフォルトの名無しさん：2022/04/16(土) 23:24:23.08 ID:3G5k9Hnh.net

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

308 ：デフォルトの名無しさん：2022/04/30(土) 04:35:01.90 ID:JVPX2fHb.net

ほしゆ(・ω・)

309 ：デフォルトの名無しさん：2022/05/04(水) 00:52:17.30 ID:J0ifRt83.net

良スレ緊急浮上age

310 ：デフォルトの名無しさん：2022/05/05(木) 13:14:14.01 ID:NIrZVW5R.net

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

311 ：デフォルトの名無しさん：2022/05/06(金) 10:59:50.63 ID:Vl/2oQCy.net

漏れら極悪非道のageブラザーズ！
今日もネタもないのにageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 ∧＿∧ 　 ∧＿∧ 　　　age
　（・∀・∩）（∩・∀・）　　　　age
　（つ　　丿 （ 　　⊂）　age
　 （　ヽノ　　 ヽ/　　）　　　age
　 し（＿）　　 （＿）Ｊ

312 ：デフォルトの名無しさん：2022/05/07(土) 18:02:14.22 ID:gG9SW2bz.net

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

313 ：デフォルトの名無しさん：2022/05/07(土) 18:37:06.23 ID:kTkslme4.net

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

314 ：デフォルトの名無しさん：2022/05/07(土) 21:15:14.23 ID:GY9FH+9n.net

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

315 ：デフォルトの名無しさん：2022/05/08(日) 11:42:43.42 ID:fLgVumqc.net

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

316 ：デフォルトの名無しさん：2022/05/09(月) 10:46:12.95 ID:f1SUg2PP.net

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

317 ：デフォルトの名無しさん：2022/05/09(月) 14:34:17.30 ID:mdmZLJk+.net

・

318 ：デフォルトの名無しさん：2022/05/10(火) 08:55:51.13 ID:MTgcEKBT.net

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

319 ：デフォルトの名無しさん：2022/05/10(火) 17:22:50.19 ID:RB5OHzJN.net

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

320 ：デフォルトの名無しさん：2022/05/10(火) 18:51:52.61 ID:lt5Lk+zW.net

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

321 ：デフォルトの名無しさん：2022/05/11(水) 12:20:04.50 ID:PHtWPQ6d.net

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

322 ：デフォルトの名無しさん：2022/05/11(水) 17:22:36.20 ID:RR+m2Q5s.net

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

323 ：デフォルトの名無しさん：2022/05/11(水) 19:40:14.48 ID:MNr0qB9P.net

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

324 ：デフォルトの名無しさん：2022/05/13(金) 07:55:24.36 ID:Wz0AIi2I.net

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

325 ：デフォルトの名無しさん：2022/05/13(金) 07:57:59.19 ID:ChGB8Ii1.net

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

326 ：デフォルトの名無しさん：2022/05/14(土) 10:01:06.26 ID:Up3XZ1NA.net

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

327 ：デフォルトの名無しさん：2022/05/14(土) 10:49:33.99 ID:UjtsEluP.net

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

328 ：デフォルトの名無しさん：2022/05/14(土) 12:19:38.49 ID:Nj4b7tCX.net

　　　　　　　　　　　　　　　　　　　　　　　　　　　　_　ー――--＿　　　　.＿
　　　　　　　　　　　　　　　　　　　　　　　　　　＜;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;＼r ´;;;;;;;￣Y
　　　　　　　　　　　　　　　　　　　　　　 ／￣/＼ヽ;;;;／;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Y;;;;;;;;;;;;;;;;|
　　　　　　　　　　　　　　　　　　　　　Y　　　/ ＼.＼　＼;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Y;;;;;;;;;;;ﾉ
　　　　　　　　　　　　　　　　　　　　 t――/　;○;＼　　　＼／|;;;;;;;;;;;;;;;;;;;;;;|―イ
　　　　　　　　　　　　　　　　　　　　/　　　{　"' '　　　　＼＼　.|;;;;;;;;;;;;;;;;;;;;;;|
　　　　　　　　　　　　　　　　　　　/　　　　{　　 ．　　　;○;＼＼ヽ;;;;;;;;;;;;;;;;ｲ
　　　　　　　　　　　　　　　　　　 Y　　　　 Y　　　　　　　, , , ,　　 ヽ;;;;;;;;;;;;;ハ
　　　　　　　　　　　　　　　　　　 /　　　　　 ＼　　ｪ‐-ｭ　　　　　　 ﾚ-‐-ｲ　 ヽ
　　　　　　　　　　　　　　　　　　/／　　　　　　Y　 .｀´　　　　　 ＿＿　　 Y　　Y
　　　　　　　　　　　　　　　　　／　　　　　￣|　 ﾚ――￣￣入＿　　　＿ﾉ　　 |
　　　　　　　　　　　　　　　／　　　　　　　　<　　　￣|　　　　　　 ￣￣　|　　 .ﾉ
　　　　　　　　　　　　　　/　　　　　　　　　　　　　　　　　　　　　　　　　 |　 メ
　　　　　　　　　　　　　/　　　　　　　　<　　　　　　　　　　　　　　　　　 .|イ
　　　　　　　　　　　　 /　　　　　　　　　　　　　　　　　　　　　　　　　　　|
　　　　　　　　　　　／　　　　　　　<　　　　　　　　　　　　　　　　　＿＿|
　　　　　　　 ＿ ／　　　　　　　　　　　　　　　　　　　　　　 _―￣
　　 ＿-ー￣　　＼　　　-―ﾅ　　　　　　　　　　　　　　　√
　　 V　　　　　　　 ＼／　 /　　　　　　　　　　　　　　　/
　　／V　　　　　　　　　　く　　　　　　　　　　　　　　／
.／　　 V　　　　　　　　　　＼　　　　　　　　　　　／
　　　　　V　　　　　　　　　　　＼　　　　　　　　 /

329 ：デフォルトの名無しさん：2022/05/14(土) 14:13:32 ID:97r1y8hR.net

　　　　　　　　　　　　　　　　　　　 　 　 ／⌒ヽ
　　　　　　　　　　　　　　　　　 　 　 　 ｛:: :{
　　　　　　　　　　　　　　　　　　　　　　_＼{‐…‐-.. .,_
　　　　　　　 　 　 　 　 　 　 　 　 ､丶｀:: :: :: :: :: :: :: :: :`: ､
　　　　　　　　　　　　　　　　　 ／:: :: :: /:: :: :: :: :: :: :: :: :: ::＼
　　　　　　 　 　 　 　 　 　 　 /:: :: :: :: √ :{:: :: :: :: :: :: ::V/:: ::ヽ
　　　　　　　　　　　　　　 　 /:: :: :: :: ::.{:: : {:: :: ::{:: :: :: :: :V/:: ::‘,
　　　　　　　　　　　　　 ＿.厶　--― 　￢:ﾟ, :: :: V/:: }:: : }､＼:: }
　　 　 　 　 　 　 　 　 Ξ, , , , /////, , 　}!:{ ―- V/ }:: : }::＼＼
　　　　　 　 　 　 　 　 Ξ///////////　}!::〉 ,ｘぃ､V:}:: : } :: :ﾊ;_:〉
　　　　　　　　 　 　 　 Ξ//ⅣﾑＶ/Ⅳ// }!´ ′ん心,}:: :,ﾞ､ ::{
　　　　　　　　　　　 　 Ξ /{　￣ ￣ Ⅵ/ }!　　 乂ソﾉ::./ ﾉ:: {
　　　　　　　　　　　　　Ξ/｢　0　　 ＜ }/ }!　　　:.:./::_/ィ:: ::！
　　　　　　　　　　 　 　 -‐㍉　　　　 　 }/.}! _､-''⌒`ヽ､{ :: ‘,:＼
　　　　　　　　　　　　/　　　 ’, ＼ ／　 }'／　　　　　　 ＼ :‘,ｰ-
　 　 　 　 　 　 　 　 ′　 　 -‘,　 　 　 __{　 　 　 　 　 　 ‘, ::`:: ┐
　　　　　　　　　 　 ,′ 　./　 　}＿_＿〈　‘,　 　 　 　 　 　 ‘,` ｰ┘
　　　　　　　 　 　 ,′　　{　　 ./ 　 　 ハ　‘,　　 　 　 ﾉ　 　‘,　 〔_
　　　　 　 　 　 　 {　{　　{　　/　/　〔￣(‘,　丶　　_∠ __　 　 ′ 〔_
　　　　 　 　 　 　 {　丶　 ｰ 1 ./　 / / }'T !ｰ^'ｰ'"{　　　　　　 ',　〔_
　　 　 　 　 　 　 /　 　 ` ‐　}/　 / / / ｜} . {　　 {　　　 　 　 ‘,⌒i

330 ：デフォルトの名無しさん：2022/05/14(土) 17:49:19.77 ID:CDz+vuVC.net

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

331 ：デフォルトの名無しさん：2022/05/14(土) 18:21:37.53 ID:RPnYOvNJ.net

キモナイ

332 ：デフォルトの名無しさん：2022/05/14(土) 20:29:18.94 ID:htcmp6+i.net

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

333 ：デフォルトの名無しさん：2022/05/14(土) 21:32:37.80 ID:CDz+vuVC.net

GopherくんのAAください

334 ：デフォルトの名無しさん：2022/05/15(日) 05:14:48.52 ID:0uh5p1OH.net

ʕ◔ϖ◔ʔ

335 ：デフォルトの名無しさん：2022/05/15(日) 15:32:41.40 ID:tfU5J4ah.net

>>334
www

336 ：デフォルトの名無しさん：2022/05/15(日) 18:08:41.50 ID:t8huU0D2.net

>>334
これだわw

337 ：デフォルトの名無しさん：2022/05/15(日) 18:19:52.67 ID:hvviJfuV.net

>>334
完璧やんけ

338 ：デフォルトの名無しさん：2022/05/15(日) 22:07:53 ID:/wKxlXf8.net

>>334
天才かよ

339 ：デフォルトの名無しさん：2022/05/15(日) 22:33:07.76 ID:XVIQic88.net

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

340 ：デフォルトの名無しさん：2022/05/15(日) 23:04:07 ID:13rYFiCc.net

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

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

341 ：デフォルトの名無しさん：2022/05/16(月) 01:46:22.06 ID:d0iqnG7G.net

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

342 ：デフォルトの名無しさん：2022/05/16(月) 05:55:28.93 ID:x9xW3Kri.net

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

343 ：デフォルトの名無しさん：2022/05/16(月) 12:50:00 ID:4NIJMXSL.net

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

344 ：デフォルトの名無しさん：2022/05/16(月) 20:21:36.29 ID:VWkobluj.net

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

345 ：デフォルトの名無しさん：2022/05/16(月) 22:39:51.10 ID:+h1PRcU6.net

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

346 ：デフォルトの名無しさん：2022/05/16(月) 22:54:07.95 ID:0w7ItVYY.net

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

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

347 ：デフォルトの名無しさん：2022/05/17(火) 04:15:40.09 ID:m02nVi8y.net

地溝油

製造方法

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

348 ：デフォルトの名無しさん：2022/05/24(火) 12:35:29.96 ID:Kl1KnEA9.net

保守age

349 ：デフォルトの名無しさん：2022/05/25(水) 21:23:55.21 ID:7RZ1XdGR.net

ほしゆ(´・ω・)

350 ：デフォルトの名無しさん：2022/05/25(水) 21:33:26.26 ID:9VfmR61D.net

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

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

351 ：デフォルトの名無しさん：2022/05/25(水) 23:50:38 ID:o5yOJbyP.net

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

352 ：デフォルトの名無しさん：2022/05/26(木) 07:51:36.31 ID:DSAsGiq3.net

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

353 ：デフォルトの名無しさん：2022/05/26(木) 08:32:25 ID:eMWKjdxZ.net

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

354 ：デフォルトの名無しさん：2022/05/27(金) 12:51:06.65 ID:HtJjrKPX.net

良スレage

355 ：デフォルトの名無しさん：2022/05/28(土) 08:41:36 ID:X7r5mWHS.net

ほｓ

356 ：デフォルトの名無しさん：2022/05/28(土) 09:13:50.20 ID:J4aLLI1r.net

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

357 ：デフォルトの名無しさん：2022/05/28(土) 09:56:04.69 ID:TjhvK20u.net

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

358 ：デフォルトの名無しさん：2022/05/29(日) 00:03:28.97 ID:gGGconts.net

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

359 ：デフォルトの名無しさん：2022/05/29(日) 00:10:52.22 ID:KjtlvxgT.net

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

360 ：デフォルトの名無しさん：2022/05/29(日) 10:24:41 ID:RueAH8As.net

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

361 ：デフォルトの名無しさん：2022/05/29(日) 11:13:23.02 ID:awmGnFTR.net

ぬるぽ

362 ：デフォルトの名無しさん：2022/05/29(日) 12:35:29.89 ID:vQDLB6Zc.net

おヒマなら来てよネ!

363 ：デフォルトの名無しさん：2022/05/29(日) 22:07:08.64 ID:A97dCucU.net

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

364 ：デフォルトの名無しさん：2022/05/30(月) 16:23:22.11 ID:4zxh/3Pl.net

テスト

365 ：デフォルトの名無しさん：2022/05/31(火) 00:46:57.29 ID:9sDYyILN.net

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

366 ：デフォルトの名無しさん：2022/06/01(水) 00:20:40.11 ID:BGkpRkuF.net

6月age

367 ：デフォルトの名無しさん：2022/06/01(水) 12:28:52.22 ID:t4/V77Jz.net

go!

368 ：デフォルトの名無しさん：2022/06/02(木) 19:12:38.94 ID:5CwDqghz.net

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

369 ：デフォルトの名無しさん：2022/06/03(金) 16:01:17.30 ID:/+UrJdaf.net

・

370 ：デフォルトの名無しさん：2022/06/04(土) 18:18:41.66 ID:zGOsyJWT.net

hosyu

371 ：デフォルトの名無しさん：2022/06/05(日) 09:59:18.23 ID:fCJN3MO9.net

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

372 ：デフォルトの名無しさん：2022/06/05(日) 14:47:02.95 ID:TG15kEdi.net

go

373 ：デフォルトの名無しさん：2022/06/05(日) 16:57:00.43 ID:2BXg1+dB.net

Hiromi

374 ：デフォルトの名無しさん：2022/06/05(日) 20:39:41.94 ID:upZoiudQ.net

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

375 ：デフォルトの名無しさん：2022/06/05(日) 20:45:22.32 ID:C0pCYYy2.net

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

376 ：デフォルトの名無しさん：2022/06/05(日) 21:48:52.30 ID:JM/j7ObI.net

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

377 ：デフォルトの名無しさん：2022/06/05(日) 23:18:43.83 ID:ZScjncWB.net

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

378 ：デフォルトの名無しさん：2022/06/06(月) 07:09:48.46 ID:kGAOGhGe.net

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

379 ：デフォルトの名無しさん：2022/06/06(月) 17:50:20.14 ID:SyuHO3EY.net

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

380 ：デフォルトの名無しさん：2022/06/06(月) 18:50:51.79 ID:kGAOGhGe.net

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

381 ：デフォルトの名無しさん：2022/06/06(月) 19:32:52.22 ID:qw/y7lM2.net

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

382 ：デフォルトの名無しさん：2022/06/11(土) 23:08:51.11 ID:AbK+zg/T.net

保全

383 ：デフォルトの名無しさん：2022/06/12(日) 15:58:23.25 ID:kUS96AVF.net

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

384 ：デフォルトの名無しさん：2022/06/12(日) 19:28:08.83 ID:X7K1W3yv.net

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

385 ：デフォルトの名無しさん：2022/06/14(火) 17:37:05.86 ID:Ypv3OCUB.net

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

386 ：デフォルトの名無しさん：2022/06/14(火) 18:20:09.37 ID:VOaVS0+Q.net

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

387 ：デフォルトの名無しさん：2022/06/14(火) 23:51:33.83 ID:JLIeltNP.net

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

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

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

Ruby が簡単

388 ：デフォルトの名無しさん：2022/06/15(水) 01:49:19.21 ID:SBK/Y+J6.net

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

389 ：デフォルトの名無しさん：2022/06/15(水) 02:58:16 ID:tT/4QRGb.net

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

390 ：デフォルトの名無しさん：2022/06/15(水) 05:30:30.87 ID:l/JMV/GH.net

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

391 ：デフォルトの名無しさん：2022/06/15(水) 08:21:25 ID:vYUVRfEQ.net

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

392 ：デフォルトの名無しさん：2022/06/15(水) 08:25:08 ID:G4MQ5N+4.net

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

393 ：デフォルトの名無しさん：2022/06/15(水) 08:41:01 ID:icfWO5Ii.net

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

394 ：デフォルトの名無しさん：2022/06/15(水) 10:21:02.38 ID:UTH2ZdYL.net

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

395 ：デフォルトの名無しさん：2022/06/15(水) 10:33:53.80 ID:pb2ts3YG.net

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

396 ：デフォルトの名無しさん：2022/06/15(水) 11:06:51.75 ID:eDRIEaUs.net

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

397 ：デフォルトの名無しさん：2022/06/15(水) 12:52:09.46 ID:manFTcsW.net

>>392
遅延評価とは反復を使い込んで消費する関数を呼ぶまで効果がない事です。どこをどう見たら即時評価だっていってますか？
明らかにチェーン生成で遅延評価です。
func Of[T any](ss []T) OfSlice[T] {
　　return OfSlice[T]{ss}
}

それと上記ライブラリにはforeachなんてファンクションはありません。Rustのforeachが副作用を伴う操作が出来てしまうが過去の互換性を
維持するための現在の仕様のことを見聞きして言っていますか？通常多くの言語や高階関数操作が出来るライブラリでmapとforeachの違いは
値を返すかどうかの違いでありエラーを返せるかどうかではありません。またRustがtry_for_eachが存在するのもあくまでも利便性のための
例外であり、普通は特に高階関数操作中のエラーが起こることこそが例外でダメなコード設計です。

もしコード中でコレクションに含まれるデータにより例外エラーを伴うようなコードを乱造しているのであれば”大きく”反省してください。
それとも全く分かってないのに言葉遊びしている？印象を受けます。「foreachでエラーを考慮しないのでダメ」の理由を示してください

398 ：デフォルトの名無しさん：2022/06/15(水) 13:27:56.57 ID:LjsAAUyE.net

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

399 ：デフォルトの名無しさん：2022/06/15(水) 14:22:43.40 ID:U1nmudTR.net

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

400 ：デフォルトの名無しさん：2022/06/15(水) 14:31:21.29 ID:LjsAAUyE.net

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

401 ：デフォルトの名無しさん：2022/06/15(水) 14:37:28.29 ID:xX6WUJu5.net

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

402 ：デフォルトの名無しさん：2022/06/15(水) 15:16:09.46 ID:eDRIEaUs.net

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

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

403 ：デフォルトの名無しさん：2022/06/15(水) 15:20:29.18 ID:eDRIEaUs.net

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

404 ：デフォルトの名無しさん：2022/06/15(水) 18:44:38.49 ID:vYUVRfEQ.net

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

405 ：デフォルトの名無しさん：2022/06/15(水) 19:45:11.38 ID:LjsAAUyE.net

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

406 ：402：2022/06/15(水) 19:52:07.91 ID:eDRIEaUs.net

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

407 ：デフォルトの名無しさん：2022/06/15(水) 20:33:08.01 ID:LjsAAUyE.net

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

408 ：デフォルトの名無しさん：2022/06/15(水) 21:34:23.56 ID:KoNFWfWJ.net

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

409 ：デフォルトの名無しさん：2022/06/15(水) 22:33:42.84 ID:vYUVRfEQ.net

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

410 ：デフォルトの名無しさん：2022/06/15(水) 22:39:20.20 ID:vYUVRfEQ.net

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

411 ：デフォルトの名無しさん：2022/06/15(水) 22:48:49.45 ID:8rndrL7k.net

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

412 ：デフォルトの名無しさん：2022/06/15(水) 23:39:49.40 ID:icfWO5Ii.net

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

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

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

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

413 ：デフォルトの名無しさん：2022/06/16(木) 00:21:02 ID:wccj32jk.net

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

414 ：デフォルトの名無しさん：2022/06/16(木) 01:51:06.21 ID:lg2Mpz7e.net

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

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

415 ：デフォルトの名無しさん：2022/06/16(木) 02:11:04.77 ID:TlphqPPg.net

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++とか使うべき

416 ：デフォルトの名無しさん：2022/06/16(木) 08:44:05.77 ID:wccj32jk.net

>>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.

417 ：デフォルトの名無しさん：2022/06/16(木) 10:46:03.49 ID:8bJC6Uow.net

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

418 ：デフォルトの名無しさん：2022/06/16(木) 11:54:55.58 ID:4wdIdA1r.net

>>417
PHPてw

419 ：デフォルトの名無しさん：2022/06/16(木) 17:42:32.41 ID:T9ZCQ85W.net

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

420 ：デフォルトの名無しさん：2022/06/16(木) 19:30:57.98 ID:33b0nQQ5.net

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

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

421 ：デフォルトの名無しさん：2022/06/16(木) 21:18:25.47 ID:fyAXkPds.net

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

422 ：デフォルトの名無しさん：2022/06/17(金) 03:52:06.95 ID:pTlTSB96.net

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

423 ：デフォルトの名無しさん：2022/06/17(金) 11:18:37 ID:/u2pEQ+2.net

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

424 ：デフォルトの名無しさん：2022/06/17(金) 11:32:30.80 ID:G5rhOs4/.net

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

425 ：デフォルトの名無しさん：2022/06/17(金) 11:45:45.87 ID:G5rhOs4/.net

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

426 ：デフォルトの名無しさん：2022/06/17(金) 12:50:08.27 ID:tKb8DSRU.net

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

427 ：デフォルトの名無しさん：2022/06/17(金) 12:53:28.19 ID:/u2pEQ+2.net

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

428 ：デフォルトの名無しさん：2022/06/17(金) 13:28:49.58 ID:G5rhOs4/.net

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

429 ：デフォルトの名無しさん：2022/06/17(金) 13:29:03.78 ID:G5rhOs4/.net

なんかスレ間違えたわ

430 ：デフォルトの名無しさん：2022/06/17(金) 15:44:02.84 ID:NvTbuTZi.net

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

431 ：デフォルトの名無しさん：2022/06/17(金) 19:22:44.65 ID:JVB9uh57.net

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

432 ：デフォルトの名無しさん：2022/06/18(土) 15:13:54.54 ID:ixLj3AWV.net

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

433 ：デフォルトの名無しさん：2022/06/22(水) 23:33:10.33 ID:DzsA87OB.net

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

434 ：デフォルトの名無しさん：2022/06/26(日) 19:36:20.90 ID:n40xbeTi.net

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

435 ：デフォルトの名無しさん：2022/06/26(日) 19:37:58.18 ID:vl5UtIOz.net

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

436 ：デフォルトの名無しさん：2022/06/26(日) 21:04:51.85 ID:PhXCrOZE.net

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

437 ：デフォルトの名無しさん：2022/06/26(日) 21:48:32.78 ID:n40xbeTi.net

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

438 ：デフォルトの名無しさん：2022/06/26(日) 23:06:38.35 ID:yMoKMg46.net

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

439 ：デフォルトの名無しさん：2022/06/26(日) 23:08:45.74 ID:yMoKMg46.net

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

440 ：デフォルトの名無しさん：2022/06/27(月) 08:35:06.00 ID:YooYWD1s.net

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

441 ：デフォルトの名無しさん：2022/06/27(月) 08:37:17.96 ID:YooYWD1s.net

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

442 ：デフォルトの名無しさん：2022/06/27(月) 08:40:10.32 ID:YooYWD1s.net

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

443 ：デフォルトの名無しさん：2022/07/02(土) 23:20:51.48 ID:IZ1AfdFM.net

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

444 ：デフォルトの名無しさん：2022/07/02(土) 23:36:14.32 ID:IZ1AfdFM.net

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

445 ：デフォルトの名無しさん：2022/07/02(土) 23:50:10.91 ID:WXVFk7BC.net

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

446 ：デフォルトの名無しさん：2022/07/03(日) 08:48:25.27 ID:7pvv3VrN.net

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

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

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

447 ：デフォルトの名無しさん：2022/07/03(日) 08:55:03.83 ID:7pvv3VrN.net

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

448 ：デフォルトの名無しさん：2022/07/03(日) 11:51:42.83 ID:l1HGgLKC.net

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

449 ：デフォルトの名無しさん：2022/07/03(日) 13:48:43.92 ID:7pvv3VrN.net

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

450 ：デフォルトの名無しさん：2022/07/03(日) 13:59:46 ID:7pvv3VrN.net

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

451 ：デフォルトの名無しさん：2022/07/03(日) 15:10:23.33 ID:Z8jWnyOJ.net

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

452 ：デフォルトの名無しさん：2022/07/03(日) 23:23:15.49 ID:kM3791I8.net

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

453 ：デフォルトの名無しさん：2022/07/10(日) 17:20:12.05 ID:EjhmXdOb.net

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

454 ：デフォルトの名無しさん：2022/07/11(月) 19:28:21.15 ID:QgABBT19.net

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

455 ：デフォルトの名無しさん：2022/07/11(月) 20:06:52.63 ID:BS7kt+k9.net

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

456 ：デフォルトの名無しさん：2022/07/12(火) 09:01:35.03 ID:r0oulnz0.net

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

457 ：デフォルトの名無しさん：2022/07/12(火) 09:02:55.76 ID:r0oulnz0.net

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

458 ：デフォルトの名無しさん：2022/07/12(火) 09:14:17.91 ID:bpFuPlMn.net

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

459 ：デフォルトの名無しさん：2022/07/15(金) 23:35:22 ID:1DD1sO9i.net

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

460 ：デフォルトの名無しさん：2022/07/16(土) 13:38:45.14 ID:Gzq+vhF3.net

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

461 ：デフォルトの名無しさん：2022/07/16(土) 14:06:11.73 ID:F7RlRzGb.net

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

462 ：デフォルトの名無しさん：2022/07/17(日) 05:50:18.02 ID:p7xubc+G.net

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

463 ：デフォルトの名無しさん：2022/07/17(日) 08:32:38 ID:Em8OpVY9.net

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

464 ：デフォルトの名無しさん：2022/07/17(日) 09:17:16.84 ID:mx7kwKTp.net

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

465 ：デフォルトの名無しさん：2022/07/17(日) 19:27:05.51 ID:Em8OpVY9.net

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

466 ：デフォルトの名無しさん：2022/07/17(日) 19:36:44.11 ID:Em8OpVY9.net

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

467 ：デフォルトの名無しさん：2022/07/17(日) 19:43:13.12 ID:EABPDou+.net

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

468 ：デフォルトの名無しさん：2022/07/18(月) 09:02:04.30 ID:unHGOtJd.net

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

469 ：デフォルトの名無しさん：2022/07/18(月) 16:09:24.37 ID:k+MW10XJ.net

Viperを使え

470 ：デフォルトの名無しさん：2022/07/21(木) 22:26:13 ID:CXPkj94/.net

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

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

471 ：デフォルトの名無しさん：2022/07/21(木) 22:30:02 ID:2u+uMLjG.net

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

472 ：デフォルトの名無しさん：2022/07/21(木) 23:21:18.30 ID:CXPkj94/.net

そうだったのか。。

473 ：デフォルトの名無しさん：2022/07/22(金) 02:56:37.89 ID:J1VsK1aI.net

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

474 ：デフォルトの名無しさん：2022/07/22(金) 03:45:47.87 ID:GTjCaUbk.net

俺はchiがおすすめ

475 ：デフォルトの名無しさん：2022/07/22(金) 12:01:47.88 ID:wu+YttEu.net

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

476 ：デフォルトの名無しさん：2022/07/22(金) 13:57:48.11 ID:sWmP1lOI.net

>>473
さんきゅー！

477 ：デフォルトの名無しさん：2022/07/22(金) 14:20:09.64 ID:whw2xWQR.net

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

478 ：デフォルトの名無しさん：2022/07/23(土) 09:09:18.33 ID:e1dxODSm.net

echo はcontext の扱いが良くない

479 ：デフォルトの名無しさん：2022/07/29(金) 12:06:04.77 ID:Nm1LHugv.net

Fiberこそ至高

480 ：デフォルトの名無しさん：2022/07/29(金) 12:08:16.31 ID:CmFCr4CU.net

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

481 ：デフォルトの名無しさん：2022/07/30(土) 02:29:49.54 ID:Wzbfhtrr.net

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

482 ：デフォルトの名無しさん：2022/07/30(土) 05:26:38.23 ID:fJ4AJJUc.net

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

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

483 ：デフォルトの名無しさん：2022/07/30(土) 17:20:05 ID:wZaxY20D.net

Goのmapをfor分で回すと順序が不定というのはなんでそうなったの？

484 ：デフォルトの名無しさん：2022/07/30(土) 17:42:37 ID:54mLdGPJ.net

>>483
将来的な最適化の余地を確保するため。
大抵の言語では、標準のハッシュ表はその内容が変更されない限りは順序が変わらないような実装がなされていることが多い。
しかし、プログラマにそれを期待したコードを書かれてしまうと、内容が変わらなくても順序が変わりうるような実装に将来的に変更したときに既存のコードが破壊される可能性がある。
Goはそれを避けるために順番を意図的にシャッフルしている。
例えば、将来的にはGCがmapのメモリレイアウトを自動的に最適化するかもしれない。仮にそうなればプログラマが内容を変更したつもりがなくても順番が変わるだろう。

485 ：デフォルトの名無しさん：2022/07/30(土) 18:14:58 ID:wZaxY20D.net

>>484
なるほど
意図的にやってるのか・・・

486 ：デフォルトの名無しさん：2022/07/30(土) 23:59:57.16 ID:H9aJG6PT.net

Rubyとかは逆に不定じゃなくしたよね。いつだったかのタイミングで。

あれは変な判断だと思ったなぁ。

487 ：デフォルトの名無しさん：2022/07/31(日) 00:35:32.67 ID:FStFDS54.net

Rubyの連想配列(Hash)にはshiftっていう変テコなメソッドがあるせいかなあ

488 ：デフォルトの名無しさん：2022/07/31(日) 00:47:08.11 ID:tsdyYOt0.net

RubyやPythonの用途なら挿入順でイテレートできるようにするためにかかるコストよりも
利便性が優先されるからじゃないかな

489 ：デフォルトの名無しさん：2022/07/31(日) 02:02:03.13 ID:fu2FWHQK.net

ですな。

490 ：デフォルトの名無しさん：2022/08/03(水) 10:05:50.52 ID:pR7q6wnw.net

Go 1.19 is released!
https://go.dev/blog/go1.19

もう出た
今verは早かったな

491 ：デフォルトの名無しさん：2022/08/03(水) 12:30:49 ID:HH6IlM8W.net

Pythonはordered dictがいつの間にか標準dictになってたな
便利だからいいけど

492 ：デフォルトの名無しさん：2022/08/09(火) 14:19:29.00 ID:/hRQdNQg.net

最近の言語仕様書はDeepLすら受け付けない英文なのはどうにかしてくれんかな
ほかにもインターフェース関係の解説でいつの間にか話に出てきてないFileインターフェースが混じってきたり
絶対にレビューしてないよな

なお1.17を読んでる(1.18 からはジェネリクスで更に混迷が進んでる)

493 ：デフォルトの名無しさん：2022/08/18(木) 10:59:30.64 ID:uJ4JpjWj.net

ふと

channel はチャンネルと読んでる？チャネルと読んでる？

494 ：デフォルトの名無しさん：2022/08/18(木) 12:00:31.81 ID:I3eJj73g.net

チャネル

495 ：デフォルトの名無しさん：2022/08/18(木) 12:23:20.11 ID:cEC5FUVy.net

正確な発音はチャノォ

496 ：デフォルトの名無しさん：[ここ壊れてます] .net

んゅにぇぅな？

497 ：デフォルトの名無しさん：[ここ壊れてます] .net

茶野ぉ？

498 ：デフォルトの名無しさん：2022/08/18(木) 16:47:44.68 ID:sstdM9KK.net

チャノルなぞ使わん！
男は黙って共有＆mutex

499 ：デフォルトの名無しさん：2022/08/20(土) 04:18:43.73 ID:O8Vd08Ya.net

>>473
ginのルーティングが糞なのは直ってるの？

500 ：デフォルトの名無しさん：2022/08/20(土) 08:17:30.29 ID:9Gwmc6Wf.net

実際goをつかいはじめのころはチャンネルの仕様とか使いかたとか調べるのが面倒で
勝手しったるmutexばっかりつかっていた

501 ：デフォルトの名無しさん：2022/08/20(土) 08:27:18.78 ID:jhGGjByr.net

よーわからんし、echoで問題ないから使ってる

502 ：デフォルトの名無しさん：2022/08/20(土) 11:47:33.07 ID:O8Vd08Ya.net

俺もecho

503 ：デフォルトの名無しさん：2022/08/20(土) 23:47:54.29 ID:McSzx8ex.net

gin → beego → echo → chi イマココ

504 ：デフォルトの名無しさん：2022/08/30(火) 15:48:26.25 ID:F+/knOGo.net

言語仕様書の1.17を底本として翻訳してるんだけど、文書的に酷い(～;～の使いすぎが特に…)し、構成的にもクソだなぁ
underlying type に関係した性質なんて文書全体を読まんと把握できないわ

メソッド式の話では、ポインタによるレシーバーのメソッドは値による呼び出しは出来ないとか書いてあるけど、レシーバー宣言が値だろうがポインタだろうが、現行じゃ問題なく呼べるようになってる(更には値でセレクタ呼んでもポインタで呼んでも動く
つまりどこかで仕様が拡張されてるのに、仕様書は更新されてないっぽい疑惑

505 ：デフォルトの名無しさん：2022/08/30(火) 15:50:42.61 ID:F+/knOGo.net

仕様書なんて熟読しなくても、フィーリングで書いて動いちゃうから、今まで気にしたこともなかったし
気にしなくても動くんだからいいじゃない？とも思いはする

506 ：デフォルトの名無しさん：2022/08/30(火) 22:31:49.83 ID:1po1mIkW.net

そんないいかげんな感覚で思い付きどんどん拡張したその結果が今のC++のていたらくだ！！
反省しなさい！

507 ：デフォルトの名無しさん：2022/08/31(水) 00:35:38.08 ID:Pib5lp7c.net

C++があんなことになったのはむしろ、C++プログラマたるもの仕様書くらい熟読しているだろうと開発陣が高を括ってきた結果だろう

508 ：デフォルトの名無しさん：2022/08/31(水) 10:19:04.29 ID:3xNaBMUA.net

あんなブ厚いARMを読むなんて苦行が過ぎる
悟りに至りかねない危険な行為だ

509 ：デフォルトの名無しさん：2022/08/31(水) 12:04:18.42 ID:3xNaBMUA.net

あるえー？
仕様書で終了ステートメントに続くステートメントに関する記述が無いんで、Playgroundでmainの最初にreturnを書いたらコンパイルエラーにならんかったし実行時エラーも起きない
到達不能ステートメントはチェックされないんだな

510 ：デフォルトの名無しさん：2022/08/31(水) 12:08:28.43 ID:rT6IO02J.net

そもそも規格化されてる言語じゃないし、コミュニティが用意した言語仕様書にそこまで大きな意味はないんじゃないの？
仮に処理系と内容が違っててもどっちのバグなのか第三者にはわからないこともあるだろう

511 ：デフォルトの名無しさん：2022/08/31(水) 14:11:42.15 ID:LHsSKudI.net

いかにも仕事が雑なグーグルらしい雑な仕様の言語

512 ：デフォルトの名無しさん：2022/08/31(水) 15:08:28.04 ID:ZrN/2uvg.net

そうか？Googleの割にはまともだったから普及したんだと思うぞ
いつものGoogleはWeb系のノリで言語作るからこんなもんじゃない、そして大コケする

513 ：デフォルトの名無しさん：2022/08/31(水) 16:28:21.64 ID:wsiOIOpJ.net

Rustほど初心者が書きにくくはないし
PythonやRubyよりは確実に速い
ちょうど良いところを付いたと思うよ

514 ：デフォルトの名無しさん：2022/08/31(水) 17:49:58.71 ID:QWrElnZY.net

だがバグらないために気を付けないといけないことが多い

515 ：デフォルトの名無しさん：2022/08/31(水) 18:35:42.76 ID:rT6IO02J.net

なんかしらんけどGoがしんどいなら使わなくてもいいんだよ

516 ：デフォルトの名無しさん：2022/08/31(水) 20:53:39.37 ID:3xNaBMUA.net

バグらないために気を付けなきゃならんことなんて、他の言語に比べるとそんなに多くないだろ

517 ：デフォルトの名無しさん：2022/08/31(水) 21:04:49.54 ID:v1Af5w53.net

100 Go Mistakesを読むといいよ

518 ：デフォルトの名無しさん：2022/09/01(木) 09:53:36.13 ID:dbQKPphW.net

言語設計でしくじってるよなぁと思うのは、構造体の生成回りの構文というか思想
Cに引っ張られ過ぎてて生成の基本が実体を作ることになってる
構造体はデフォルトでアドレスとして出現し、Javaとかのように参照と命名しとけばよかった

そうすればスライスとかマップのイテレーションがクソみたいな落とし穴にならないし、マップをインデックス式でアクセスしてセレクタとしてフィールドにアクセスも出来るようにできた

実体を使いたい場合は*でデリファレンスして使う
実体ちゃんの変数も*Tという型とする
実体配列は[]*Tという配列を記述するようにする

*に関しては、レシーバーとか宣言で(r *T)とかデリファレンス演算子をポインタを示す記号に使うような一貫性のなさも解消する
プリミティブな変数が実体で、そのアドレスを&で取得するということからの一貫性に拘ってるんだろなぁ

実体配列なんて、Dockerの管理用配列以外で見たことないよ…少なくともレアな宣言だと思う

519 ：デフォルトの名無しさん：2022/09/01(木) 11:44:46.07 ID:8wwpfCzj.net

欠点を挙げる流れだ
やっぱ入れ子の構造体の初期化でしょいかんよあれは

520 ：デフォルトの名無しさん：2022/09/01(木) 12:50:03.20 ID:cWwvmbGP.net

この辺の問題が起きないようにしっかり対策取ってる？
https://www.uber.com/blog/data-race-patterns-in-go/
https://blog.acolyer.org/2019/05/17/understanding-real-world-concurrency-bugs-in-go/

521 ：デフォルトの名無しさん：2022/09/01(木) 12:54:11.77 ID:dbQKPphW.net

複合リテラルとして書けばいいんだし、落とし穴的な問題はなくない？
俺は悪くないかなと思ってるんだけど

522 ：デフォルトの名無しさん：2022/09/01(木) 13:00:51.78 ID:dbQKPphW.net

>>520
「これらの多くは、チャネルでの送信または受信の欠落、またはチャネルの閉鎖が原因です」
いや、mallocしといてfreeしてませんでしたレベルの話をされてもどうしろと？
普通に対策考えないでプログラミングなんてできないだろ

523 ：デフォルトの名無しさん：2022/09/01(木) 14:02:59.57 ID:dbQKPphW.net

>>518
ポインタを示す型なら&を使ってT &pにしてデリファレンスは*p
とか実際に書いてみたら物凄い違和感に襲われてしまった

…C言語の呪いって凄いわ

524 ：デフォルトの名無しさん：2022/09/01(木) 14:17:02.40 ID:3zc//kWQ.net

>>522
それってプログラマー任せのノーガード戦法ってことでしょ？
リストアップされてるような各種バグに対してシステマティックに検知・防止する仕組みを実装できてる？

525 ：デフォルトの名無しさん：[ここ壊れてます] .net

データ競合はあまり遭遇したことないな
無駄に並列化したがるバカがチームにいると地獄を見るだろうというのはわかる
channel絡みのミスで固まるのはよくある

526 ：デフォルトの名無しさん：2022/09/01(木) 18:05:50.03 ID:Wlby5VAy.net

>>522
けっこう終了時の後処理とか難しくない？
適当なツールとかだと雑に済ましちゃうし、割ときちんとやろうとすると書けない人多い印象。

527 ：デフォルトの名無しさん：2022/09/01(木) 18:16:08.12 ID:0As8hqIp.net

きつい現場のGoは他の言語より殊更きつそうだというのはわかるわ

528 ：デフォルトの名無しさん：2022/09/02(金) 02:30:51.60 ID:bNDG9t//.net

channelは複雑なデータのやり取りに使うには難しすぎると感じるね
どこで詰まるかわかったもんじゃないし
公式がまともなフレームワーク用意するわけでもないし

529 ：デフォルトの名無しさん：2022/09/02(金) 03:08:08.96 ID:xpSIPhaW.net

epollを使うよりかはマシだし

530 ：デフォルトの名無しさん：2022/09/02(金) 08:58:55.58 ID:0WCZpZUS.net

いや、Goに限らない問題でGoのダメなところとか言われてもなぁ

531 ：デフォルトの名無しさん：[ここ壊れてます] .net

いや、けっこうGoに限った問題
channelのユースケースの大部分は現実にはpromise/futureで十分で、遥かにミスを引き起こしにくい

532 ：デフォルトの名無しさん：[ここ壊れてます] .net

例えばCとかでファイルを排他オープンしたままクローズし忘れて書き込みのままになってて、別の箇所で読み込もうとしたけど開けなかったとして
これはC言語の不備だとか言うのか？と

533 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>531
chan のユースケースといったら、パイプとしてストリーム的にデータを流すのが主だと思うんだが、promise, future でどうやって代替するの？

534 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>531
select文のあたりでも書かれてたと思うけど、同期を取る目的じゃなくてパイプからの機能だよチャネル

535 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>531
同期取るなら、sync.WaitGroup 使えばよくない？

536 ：デフォルトの名無しさん：2022/09/02(金) 12:33:43.05 ID:Xv0heE2X.net

>>532
そういうことにならないようにGoのdeferやC#のusingやPythonのwithみたいな仕組みを言語機能として提供してるよね？

それらが不要だとでも？

537 ：デフォルトの名無しさん：2022/09/02(金) 12:45:23.85 ID:bNDG9t//.net

いや普通に同期を取る使い方もできるだろw
完了通知を待つ使い方
俺もその使い方しかしてない
async/awaitなんで構文として追加しても良いと思うのだけどね
channelは非同期機構を実装するパーツとしては優秀だから
フレームワークが欲しい

538 ：デフォルトの名無しさん：2022/09/02(金) 13:40:10.47 ID:D0FuWgPr.net

そもそも本当にパイプとしてストリーム的にデータを流す必要のあるケースなんて稀
Goがchannel推しだから利用者もそれに引き摺られてストリームっぽい設計になりがちなだけで、結果として単一の値(又は配列)を返せれば殆どのケースでは十分
本当にストリームが必要ならJavaScriptのasync generatorのような設計も可能で、producerとconsumerが協調するからchannelより遥かに安全だ

539 ：デフォルトの名無しさん：2022/09/02(金) 13:56:23.23 ID:iQ46VdDW.net

そもそもストリームモデルが必要なユースケースってほぼ
分散環境だと思うんだよな

540 ：デフォルトの名無しさん：2022/09/03(土) 12:27:35.16 ID:62gf404N.net

分散環境なら外部のメッセージバスに投げるだけだよね
せっかく小さいgoroutineを気軽にポコポコ起こせるデザインなのに、
結果を受け取る方法が、データ競合を起こさないように最大限注意して共有変数を使うか、パラダイムのミスマッチなchannelを使うかなのは片手落ちに感じる
単純にgoroutineの返り値をwaitできるようにしない理由ってあるんだろうか？既に議論されてたら知りたい

541 ：デフォルトの名無しさん：[ここ壊れてます] .net

>パラダイムのミスマッチなchannel

kwsk

542 ：デフォルトの名無しさん：2022/09/03(土) 20:41:16.91 ID:eoULSfLD.net

>>541
そりゃ>>533の通りで、channelはストリームでありfutureではない、ってことだ。
futureで済むケースにchannelを使うと、複数の値を返す可能性はないのか？1つも結果を返さなかったら？
そんな余計な心配が常に付き纏うことになる。futureなら全く無縁な心配がな。そしてその心配が現実になればプログラムは容易にデッドロックする。

543 ：デフォルトの名無しさん：2022/09/03(土) 20:49:18.55 ID:CkDP1XSv.net

>>536
だからdeferあるんだし、ちゃんとリソース管理しろよ、という
Goのせいにするのはお門違いだろ、な？

544 ：デフォルトの名無しさん：2022/09/03(土) 20:53:14.26 ID:CkDP1XSv.net

>>542
promise, future 程度のことをやりたきゃ、>>535で書いたけどsync.WaitGroup使ったらどうだ？

545 ：デフォルトの名無しさん：2022/09/03(土) 21:09:58.32 ID:2QtFsvwZ.net

パラダイムのミスマッチという理由がわからん。
goroutineは一つの関数を呼ぶためのもんじゃないぞ。
goroutine立てて一連の処理を同期的に書くためのもなんよ。普通に考えれば結果を受け取る必要が無いはずだよ。
どうしても集めるならfan inするように一つのchanで受ける。

Futureは要らないんよ。awaitとかしなくてもそこでCPU占有したり、ioなりなんなりが起これば自動的に別goroutineに制御が渡る。

546 ：デフォルトの名無しさん：2022/09/03(土) 21:10:11.97 ID:Aru3Abt3.net

>>542
ストリームだとミスマッチでfutureだとミスマッチじゃないということか？
何と何がミスマッチなのかというところがよくわからんが。

547 ：デフォルトの名無しさん：2022/09/03(土) 21:14:31.20 ID:eoULSfLD.net

>>544
その場合は「共有変数を注意深く使う必要がある」よね

548 ：デフォルトの名無しさん：2022/09/03(土) 21:22:59.76 ID:eoULSfLD.net

>>545
だからそう言ってるでしょ
goroutineとchannelをfutureのように使おうとすればミスマッチのために煩雑でバグの生じやすいコーディングを強いられることになる
もちろんGoにはGoのやり方があるのは分かるが、一方でその結果が>>520の状況なのが事実だよね

549 ：デフォルトの名無しさん：2022/09/03(土) 21:29:09.46 ID:2QtFsvwZ.net

>>548
goroutineで処理すべき単位とか、ワークスティーリングの話してなかったかなと。

550 ：デフォルトの名無しさん：2022/09/04(日) 00:29:35.08 ID:ULs4IOBU.net

まさかこのスレにホーアのCSP本読んでないやついないよな？な？

551 ：デフォルトの名無しさん：2022/09/04(日) 00:54:37.91 ID:6UpdVUMR.net

いや、読んでませんが？

552 ：デフォルトの名無しさん：2022/09/04(日) 17:28:10.39 ID:GIlWqA7r.net

>>550
読もうとしたけどガチの論理学的数学で挫折
しかしよく調べたらGoが参考にしたのはその本ではなく
最初にホーアが出したもっと簡単な論文の方だった
つまりその本は読む意味はない(Goの並行モデルの理解という意味で)

553 ：デフォルトの名無しさん：2022/09/04(日) 18:08:07.32 ID:VepAvQjQ.net

>>547
それは認めざるを得ない
Mutexと会わせ技で使ってるから

554 ：デフォルトの名無しさん：2022/09/04(日) 19:08:07.89 ID:VepAvQjQ.net

>>547
だけど、120行(+テスト75行)の隠蔽ライブラリを書いて使ってる
共通変数の管理なんてその程度の共通化でカバーできるタスクじゃん

555 ：デフォルトの名無しさん：[ここ壊れてます] .net

すまない誰かリングにかけろで例えてくれないか？

556 ：デフォルトの名無しさん：2022/09/05(月) 01:58:21.42 ID:7mfke0+F.net

Goがpromise(future)/async/awaitをサポートしてくれれば今より容易に安全に書けるケースが増えるのは事実だが、
この件も他の件と同様にGoはサポートしてくれないだろうという悲観的な現実と向き合って、
今ある手段で頑張って代替手段を安全に実現しよう。

557 ：デフォルトの名無しさん：2022/09/05(月) 04:13:05.73 ID:098gBdTn.net

結局ゴルーチンの実装が中途半端だったんだろうね
分散環境でのストリームモデルならNodeみたいなノンブロッキングIOで外部のソケットを叩けるようにして
シングルスレッドにするのが良かったし
そうでないならFuture/Promiseみたいに安全にデータを受け取れる仕組みが欲しかった
この２つがちょうどうまくできないデザインになっちゃった

558 ：デフォルトの名無しさん：2022/09/05(月) 04:31:49.54 ID:098gBdTn.net

またGoの言語仕様にも問題があった
ジェネリクスだ
ジェネリクスがない状態でfuture/promiseを安全に実装できない
なぜかアンチジェネリクス勢がGoには多く
コミュニティでの議論も進展しなかった
つまり全てがゴテゴテに回ってしまった
それならGoogleが並行処理のフレームワークを作ってくれるのかと期待していたが
その気配は全くなく使いにくいcontextのみを放り投げた状態でさあ作れと言った状態
そりゃ普通のユーザーは付いてこれない

559 ：デフォルトの名無しさん：2022/09/05(月) 06:36:04.94 ID:oqoL/iqD.net

マルチコアを効率よく使うってのがそもそもコンセプトで作られたんだがNodeみたいにしろって意味わからん

560 ：デフォルトの名無しさん：2022/09/05(月) 07:31:00.89 ID:yL+fAGmc.net

Goのようにマルチコアを効率よくスケジューリングできて
Goのgoroutineのように多数のタスクを身軽に簡単に起動できて
Goのようにそれらタスク間でchannel通信をすることができて
それらに加えてFuture / async / awaitもサポートしているプログラミング言語がありますよ

偶然ですがその言語は
Goと同じくclassや継承がなく
Goと同じく例外try-throw-catchもなし

561 ：デフォルトの名無しさん：2022/09/05(月) 09:08:23.21 ID:wt43bW0T.net

>>558
まずpromiseがどう有利なのか自分の口からどうぞ
そこにメリットを見いだせないから無視されるんだよ

562 ：デフォルトの名無しさん：2022/09/05(月) 10:05:06.21 ID:rnwYkZ6l.net

Goのモデルと比較してのpromiseの優位点としてはこんなとこかな
・一般に、並行性が多少犠牲になる代わりに並行処理の複雑性を局所化する方向へとデザインが誘導される傾向がある。結果としてバグが入り込みにくい。
・ワークフローを集約して記述しやすいため可読性保守性に優れる。
・(channelではなく共有メモリを使う場合と比較して)処理結果を他のスレッドで利用する際にデータ競合が生じない。
・channelと比較して、結果として単一の値を生成するというセマンティクスが型として明確に表現される。デッドロックや閉じ忘れの心配もない。

563 ：デフォルトの名無しさん：2022/09/05(月) 10:15:26.20 ID:098gBdTn.net

うーん今の時代にpromiseの利点を理解できない人がいるとは驚きですが仕方ない出血大サービスだ

まず最初にマルチコアを活かすという点についてだが
基本的にゴールチンのような仕組みでは全く活かせないという点を強調しておく
まともにマルチコアのCPUの性能を引き出せるのはSIMD命令を使った計算のみ
SIMDが何なのかわからない人は調べてください
SIMD演算を直接言語でサポートしていないので計算の高速化は論外
ただのマルチスレッドと変わらない
マルチスレッドはOSレベルで実装されており
コンテキストスイッチの負荷も高くCPUキャッシュも消えるし
マルチコアを活かすような作りになってないのはご存知の通り

564 ：デフォルトの名無しさん：2022/09/05(月) 10:28:17.92 ID:FE5GsYYc.net

>>562
嘘ついちゃだめ
promiseでもデッドロック起きる

565 ：デフォルトの名無しさん：2022/09/05(月) 10:29:00.06 ID:FE5GsYYc.net

データ競合も起きる

566 ：デフォルトの名無しさん：2022/09/05(月) 10:37:15.25 ID:098gBdTn.net

次にpromiseの利点について

並行処理の考え方としては大きく以下がある

1.処理をシーケンシャル実行して1つずつ結果を受け取る
Aが終わったらBを実行して
Bが終わったらCを実行する

2.複数の処理を同時に実行して結果をまとめて受け取る
A、B、C...の処理を同時に実行してその結果をreduceして受け取る

3.ストリーミングモデル
いわゆるproducer/consumerに代表されるようなモデル

1と2についてはpromiseで全て安全に楽に実装できる
ゴルーチンとchannelを使った実装なんか考えたくもない
100%デッドロックが起きる

3についてはゴルーチンとchannelが本来想定してるモデルなのだが
これを適切に実装するのが難しい
CでBlockingQueueの実装したことがある人は分かると思うが極めてデッドロックが起きやすい
複数のproduer/consumerを生成したい場合など考えたくもない
さらにこのモデルの場合は基本的に大規模な分散環境で実行することがほとんどである
シングルノードでproducer/consumerなどサンプルコードでしか有り得ない
こういう用途では複数ノードのソケットにリクエストを投げて結果を待つということになるので結局2に帰着される

567 ：デフォルトの名無しさん：2022/09/05(月) 10:37:39.78 ID:098gBdTn.net

つまりpromiseがあれば全ては安全に解決される
ちなみにpromiseはスレッド実装する必要はないことに注意
rustはスレッドで実装されているがNodeはノンブロッキングIOを使っている
他にもグリーンスレッドを使うなどいろいろある
言語側が安全性を担保できるように実装できるのだ
そしてpromiseを型安全に実装するためにはジェネリクスは必須である

以上が私の考える
「ゴルーチンは実装が中途半端で実際のユースケースを考えた場合に非常に残念なことになっている」理由である
反論があればどうぞ

568 ：デフォルトの名無しさん：2022/09/05(月) 10:37:59.16 ID:rnwYkZ6l.net

そりゃpromiseでも共有メモリ触ったり外部のリソースをロックしようとしたりすればデッドロックするでしょう
promiseモデルとは関係ない話

569 ：デフォルトの名無しさん：2022/09/05(月) 10:56:03.27 ID:88BZgezt.net

>>560
その言語はRustだな

>>565
Rustならデータ競合が絶対に起こらない
データ競合を起こすコードはコンパイラがエラーにできる言語仕様

>>567
ちょっと違う
RustのFuture(＝Promise相当)はOSスレッドとは全く別で関係なく
Goroutineとほぼ同様の気軽に大量に作れる非同期タスクとして扱える
もちろん安全に解決できる

今回の話で言えば大雑把に分けるとRustは3種類ともサポート
① Futureおよびそのasync/await
➁ Goと同様のchanel
③ メモリ競合を絶対に起こさない安全な共有メモリ

570 ：デフォルトの名無しさん：2022/09/05(月) 11:03:44.74 ID:098gBdTn.net

>>569
なるほど流石Rust

571 ：デフォルトの名無しさん：2022/09/05(月) 11:12:30.51 ID:098gBdTn.net

ぐちぐち言ってきたが
Goにはゴルーチンとchannelとcontextという良いプリミティブがあるのだから
適切にpromiseを実装して使えるようにして欲しいということ
であれば並行処理がメインのアプリにおいては第一選択にもなり得ると思う
ジェネリクスも入ったのだしやれるはずなんだよ
Googleがもうやる気ないのかもしれないけど

572 ：デフォルトの名無しさん：2022/09/05(月) 12:10:29.88 ID:E0SFrHzH.net

>>568
channelと比較してデッドロック起きないとか痛い事言っといてそれはないわw

573 ：デフォルトの名無しさん：2022/09/05(月) 17:07:29.06 ID:oqoL/iqD.net

Nodeしかさわったことないから詳しくは知らんけどasyncawaitモデルだと
async関数を使うには呼び出し元にどんどんasyncが汚染されて使いづらいイメージがあるな

その点Goは同期的なコードの一部を並行処理にするってのが非常にやりやすいと思う
タイムアウト処理もselectで簡単に実装できるし、シンプルなfork joinだったらsync.waitgroupで楽に実装できるし
何も困ったことがないな

そんなに優位性があるとは全然思わない

574 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>573
Goは見かけ同期と誤認するけど
同じOSスレッド上でもメインや複数のGoルーチンがスケジューリングされて交互に非同期で動いているよ

例えばGoで
　func1()
　func2()
　func3()
と見かけ同期に書いているのは
async/await対応言語で
　await asyncfunc1()
　await asyncfunc2()
　await asyncfunc3()
と書いた時と同じ状態
つまり見かけ同期のGoの実態は非同期

「Goは最初から全てがasync汚染されているためasync汚染に気付かずに済む」が正解

575 ：デフォルトの名無しさん：2022/09/05(月) 22:10:30.31 ID:oqoL/iqD.net

>>574
goキーワードなかったら同期的に動くだろ
ライブラリの中でgoキーワードが使われてるから暗黙的に使われるが正しいね。

非同期にしたい部分でgoをつけるのであってつけてないのに全部非同期だってのはおかしな話だな

576 ：デフォルトの名無しさん：2022/09/05(月) 22:24:10.45 ID:M8mFZMdW.net

>>575
それは見かけ上だけ
goを付けなくても読み書きなど含めて時間がかかるものは
見かけ上だけ同期ブロックしているが
実際には非同期で動いており裏で別のgoroutineにスケジューリングされている
そしてその読み込みや書き込みが可能となると
見かけ上だけ同期ブロックしていたところへスケジューリングが戻る仕組みであってGoは常に非同期に動いている

577 ：デフォルトの名無しさん：2022/09/05(月) 22:30:51.53 ID:oqoL/iqD.net

ユーザーに見せてるのは全てブロッキングなコードなわけじゃん
それをgoキーワード使って複数立てた時に非同期で動くって話で、単体の場合はあくまでも同期的に動くよね

mainルーチンでhttp.getってやったら同期的に動いてるよね？
これを別のgoroutineを立てて複数立ち上げればブロックする後は勝手に非同期で動くってだけの話

async汚染はユーザー目線で言ってるね
Goのモデルは既存のコードや構造に手を加えずに一部だけを非同期にするのが容易、これが一つのメリットではあると思う

578 ：デフォルトの名無しさん：2022/09/05(月) 22:40:11.19 ID:oqoL/iqD.net

Node/Denoの作者も同じこと言ってるし、async/awaitモデルの方が優れている一言も言ってないな
むしろGoのモデルをほめてるわ
https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/

必死にasync/awaitの方が優れてるとか言ってるみたいだけど、逆にGoのモデルの方が使いやすいって人もいるわけだよ
自分の意見が全てだと思わない方がいいんじゃないかな
感覚的な話で優れてるって言われてもね

579 ：デフォルトの名無しさん：2022/09/05(月) 22:48:10.04 ID:bm2FICIw.net

>>577
> ユーザーに見せてるのは全てブロッキングなコードなわけじゃん

それは見かけだけだな
例えば>>574の
|　await asyncfunc1()
|　await asyncfunc2()
|　await asyncfunc3()
これも(同じく見かけだけ)全てブロッキングな同期で実行されるコード
そしてGoと同様に実際には裏で非同期に動く

> 単体の場合はあくまでも同期的に動くよね

それは見かけだけ
つまりasync/await対応言語がawait文で見かけだけ同期的に動いているように見せかけるのと完全に同じ

580 ：デフォルトの名無しさん：2022/09/05(月) 23:00:13.19 ID:oqoL/iqD.net

うんだからユーザーに見せるコードが同期的なことろがわかりやすくて良いって言ってるんだけど？最初その話してたよね？同期的なコードって言ってるよ？
裏でepollやら使ってて非同期だから云々の話はしてないんで
ちなみになんでいちいちID変えるの？

581 ：デフォルトの名無しさん：2022/09/05(月) 23:32:28.26 ID:9iTWKe04.net

>>576
＞見かけ上だけ同期ブロックしているが
＞実際には非同期で動いており裏で

んなこと言ったらIO操作のあるあらゆる言語が低レベルでは非同期で動いてるじゃんよ。

582 ：デフォルトの名無しさん：2022/09/05(月) 23:43:38.07 ID:iWQD5HeB.net

C10K問題から非同期が流行ったのに、メモリーを使いまわしてたら意味ないのでは？

一つのスレッドに一つのスタック、典型的に一つのスタックは1MB準備される。
10Kのスレッドがあれば、10GBのメモリーが必要。
256MBのSUNでは無理。

でも、非同期でも1MBの配列を用意してデータが届くたびに書き足していくなら同じことでは？

583 ：デフォルトの名無しさん：2022/09/05(月) 23:47:49.38 ID:iWQD5HeB.net

ウェブ・サーバーが静的なファイルを送り出していた2000年ごろなら非同期が大それた力だっただろうけど。

全てが動的な現代において、非同期はめんどくさいだけなのでは？

584 ：デフォルトの名無しさん：2022/09/05(月) 23:53:52.32 ID:YaRYiHc+.net

昔より回線が安価になって接続数が多くなったんだから非同期が必要でしょ

585 ：デフォルトの名無しさん：2022/09/05(月) 23:56:02.82 ID:iWQD5HeB.net

どういうことですよ？

586 ：デフォルトの名無しさん：2022/09/06(火) 00:05:01.14 ID:btul1bBo.net

静的なファイルを送るだけなら。

カーネルの送信バッファが空くのを待つ
↓
送信バッファと同容量だけ非同期にファイルの読み込みを開始する
↓
ファイルデータが読み込まれると、送信を開始する
↓
最初に戻る

この手順で、典型的なTCP通信なら20KB以下のメモリーで足りる。
でも、動的なコンテンツ生成では、そうはいかないのでは?

587 ：デフォルトの名無しさん：2022/09/06(火) 00:56:32.90 ID:jgCBXC4T.net

ヒント:httpは同期通信

588 ：デフォルトの名無しさん：2022/09/06(火) 01:32:17.99 ID:h7zKo1Kf.net

>>563 のここがよく分からない

> まともにマルチコアのCPUの性能を引き出せるのはSIMD命令を使った計算のみ

SIMD命令付きのシングルコアCPUもあったじゃん。
古いけど MMX Pentium とか Pentium III とか。
この時代はSIMD命令は何を引き出してたの？

589 ：デフォルトの名無しさん：2022/09/06(火) 02:05:21.99 ID:haU306kC.net

>>566
1なんか一つのgoroutineに上から並べるだけで良いじゃん。

590 ：デフォルトの名無しさん：2022/09/06(火) 02:06:28.41 ID:haU306kC.net

えっ？もしかしてこの人
>>574
でもまだ理解してないの？

591 ：デフォルトの名無しさん：2022/09/06(火) 03:40:36.05 ID:4pNI/aXz.net

>>587
httpを同期で実装するなんて昔のダメなシステムと完全ブロックしても困らない末端クライアントだけたぞ
httpクライアントとして動作する時もサーバーで使うなら同期ブロックしてしまうとスレッド資源を無駄に専有
だからhttpを使うなら何らかの非同期にするのが当たり前

592 ：デフォルトの名無しさん：2022/09/06(火) 06:52:34.65 ID:JHpT8XfS.net

>>574
多くの言語でasync/awaitキーワードだらけになって反吐が出る気分だわ、これを良いと考えた人たちを殴りたい...
goにpromise/futureなんて絶対不要、こんなの必要だと思ってる人相当アホやぞ

＞「Goは最初から全てがasync汚染されているためasync汚染に気付かずに済む」が正解
なるほど意味わからん
asyncキーワードなんて無いのにスケジューリングで同期実行されるから汚染？ｗｗ新理論ｗ

593 ：デフォルトの名無しさん：2022/09/06(火) 08:04:56.91 ID:g0koBBSB.net

>>566
1なんてそのまま関数並べるだけだし
2はN件goroutine立ち上げてたらN回チャネル待ち受ければいいだけだよね
タイムアウトもselectで容易に実装できる

100%デッドロックするとか言ってるけどそれはGo超初学者が使った時の話かな？
仮にデッドロックしても検知機構働いてちゃんと落ちるし何が言いたいのか

594 ：デフォルトの名無しさん：2022/09/06(火) 10:57:52.38 ID:ItiT2cL1.net

>>588
その時代のことはよく知らないので
気になって調べてみたがwikipediaによると
2クロックで実行するという実装になっていた模様
なのでその時代に関しては128ビット幅のレジスタを使えるというアドバンテージしかなかったとのこと

595 ：デフォルトの名無しさん：2022/09/06(火) 11:23:36.25 ID:7Nc33VtP.net

>>591
通信プロトコルとhttpサーバー/クライアントの実装が区別できないおバカさん乙w
そんなんでよくGoなんて使えるな

596 ：デフォルトの名無しさん：2022/09/06(火) 14:37:15.63 ID:ax+JnAgH.net

今回は実装の話だからサーバー上なら今どきは非同期で実装で合ってると思うよ

597 ：デフォルトの名無しさん：2022/09/06(火) 16:35:51.33 ID:E35zydsp.net

>>596
文脈読めないおバカさんその2乙w

598 ：デフォルトの名無しさん：2022/09/06(火) 16:56:04.53 ID:rOGll//o.net

>>593
その通りだな、安易に実装できるものを標準で欲しがる理論がわからんわ
多くの言語のfutureなんてデータの結果受信同期待ちが起こるだけだし、goのcontext.WithTimeoutは
他の言語では全く実装できていないfutureのプラス機能のようなもので、goはより進んでいると言える
一方promise的なもの、つまり複数のgoroutineを束ねて制御したい人は、欲しい人もいるかもしれないが
goで書いたpipeline処理は手動で書くからこそきめ細かい制御が出来るので、無作為にこれとこれを並列、
これとこれを非同期だけど同期的に実行にしたいとか、効率を考えたらこの流れを組み替えられることには
ほとんど意味もないね。
例えばJSでPromise.allとかすべてを非同期並列に実行して成功の可否で分岐したいなんて、同じ状態が
goroutineとチャネル待ち受けで出来てしまうわけで、それを仰々しいライブラリにする意味が分からん

599 ：デフォルトの名無しさん：2022/09/06(火) 17:02:41.68 ID:rOGll//o.net

上では良いことだけ書いたけどif err != nullはもうそろそろダルいので何とか手を打ってほしいわ
副作用のある関数ではgoの第二の戻り値がerrなのは、もはや言語仕様なので別言語でいう
Option/Result/Eitherみたいなものは必要ないにしても、?.のようなNull条件演算、合体演算
のようなErr条件演算が欲しい

600 ：デフォルトの名無しさん：2022/09/06(火) 18:25:37.98 ID:rAtefbER.net

きめ細かい制御してるか？
goのモデルは良くも悪くも作った水路に水を流すだけで、実際にその中のどこでどのようにブロッキングが発生するかは気にしないのが正しい使い方
どっちかというとpromise系のほうが制御は明示的だよ

601 ：デフォルトの名無しさん：[ここ壊れてます] .net

きめ細かいGoのpipelineって、もしかしてGoあんまり書けないのでは…？
ランタイムの大勝利な事の方が多いぞ。

602 ：デフォルトの名無しさん：2022/09/07(水) 08:09:00.20 ID:KZnrapZJ.net

きめ細かいでしょう？
チャネルが１個なら並列性が1つでブロッキング出来るし、並列性を持たせたいなら複数のチャネル幅を
用意すればいいだけ1段目のパイプライン処理が終わったすぐ後に、次段のパイプライン処理を普通に書く
ことができるし、sync.WaitGroupを使えばパイプライン中の中間データへ同期制御もできる
それ以外にGoで書かれた多くの優れたパイプライン処理は、キャンセルを考慮している。
ブロッキングが発生するかは気にしないなんて事はなく、チャネルのselectでブロッキングが入ることは普通に
当たり前だから気にしないだけ
https://go.dev/blog/pipelines

世にある多くのpromiseはキャンセルやタイムアウトは考慮していない場合が多い、All or Nothingでしかない
大雑把な実行制御でしかない。多くは流れるようなデータの受け渡しもできない。
実行順を決めるだけで、特定の処理に多重度を持たせるとかそんなことは出来ない
これは多くがpromiseというものが非同期処理をベースにした疑似的な実行順制御の仕組みだけであるから

603 ：デフォルトの名無しさん：2022/09/07(水) 13:37:16.25 ID:ossJLtb4.net

>>599
nullじゃなくてnilな

604 ：デフォルトの名無しさん：2022/09/07(水) 16:59:11.50 ID:GTdTGsfv.net

>>598
そもそも、複数のgoroutineを束ねて使いたいという要請でsync.WaitGroupは作られてるから、自前で作る意義すら無いんだよな
グループを待つ、のだから

605 ：デフォルトの名無しさん：2022/09/08(木) 16:15:42.84 ID:+22QbHY9.net

>>593
だからその程度のことしかしないのにわざわざゴルーチンだのchannelだのselectだのを書かなきゃいけないことがだるいと言う話だよ？
書けるか書けないかで言ったらそりゃ書けるでしょw
あと普通に刺さる可能性が高いと言うことを言ってる

606 ：デフォルトの名無しさん：2022/09/08(木) 22:55:49.37 ID:AWp4/fcz.net

ホントにGo書けないんじゃないの…？

607 ：デフォルトの名無しさん：2022/09/09(金) 08:28:18.12 ID:5SEsta+Y.net

意味わかんね

>>566 では promise の利点をこう書いてた

> 1と2についてはpromiseで全て安全に楽に実装できる
> ゴルーチンとchannelを使った実装なんか考えたくもない
> 100%デッドロックが起きる

それに対して >>593 や >>598 が goroutine とチャネルで簡単に実装できるって言ったら >>605

> わざわざゴルーチンだのchannelだのselectだのを書かなきゃいけないことがだるいと言う話だよ？

「だるい」なんて話、一切してなかっただろ。

608 ：デフォルトの名無しさん：[ここ壊れてます] .net

>>607
マジでアスペか？
promiseの方が明らかに楽でバグが生まれない
これはこれまでの議論の流れで一貫してる主張

なんでリクエストのデータ受け取るのにgoルーチンだのchannelだのselectだの書かなきゃならんのだよ

そしてpromiseを実装するのは我々ではなくGoコンパイラの開発者たちだよ

609 ：デフォルトの名無しさん：2022/09/09(金) 12:35:07.97 ID:OI70qo+4.net

promiseって普通awaitするのが普通だよね？
goもチャネルも使わない状態でhttp.Get呼ぶのと全く同じだよ

goroutineの中で実行すれば勝手に非同期になるしfork joinしたいならチャネルがwaitgroup使うだけの簡単なお仕事

610 ：デフォルトの名無しさん：2022/09/09(金) 12:39:54.70 ID:ppztOn1H.net

>>608 >>607
まずは「goroutine&channelだと100%デッドロックが発生してpromiseだと発生しない状況」について戦えよ。

だるいとかより興味あるわ。

611 ：デフォルトの名無しさん：2022/09/09(金) 13:19:10.61 ID:WCKL/dzA.net

>>608
「promiseの方が明らかに楽でバグが生まれない」
そんな統計は１つもないければ、あなたの貧相な頭の中だけですよね？それを証明しなさいと暗黙的に問われているのがわかりませんか？

「なんでリクエストのデータ受け取るのにgoルーチンだのchannelだのselectだの書かなきゃならんのだよ」
じゃあなんで、promiseなんていう出来の悪い非同期処理のために作り出された愚物を、真にマルチプロセスに対応するgoで
エミュレーションしなきゃならないんですか？あなたのためだけですよね、ほとんど誰も欲しがっていませんけど?
このような需要がない機能を、標準ライブラリに求めるものではありませんし、あなたの隠れた真の心は
「学ぶことをしたくない」だけでしょう、ご自分でも気づいてないと思いますが
C#やScalaあるいはJSしか出来ないなら素直にチームに報告しましょう、あなたのやる気を引き出すためだけに我儘を際限なく
広げても誰も理解してくれませんし、当然、味方にもなってくれないでしょう。だってやる気が無いんですから。
言語の基本的な考えが違うのに、他の言語に似たような雰囲気を求めるのは間違っていますし、なおかつ結局同じコードを
書いてしまうなら乗り換えるような利点をすべて消し去るでしょう

「そしてpromiseを実装するのは我々ではなくGoコンパイラの開発者たちだよ 」
実装しないと思いますね、あなたのゆがんだ考えでは超保守的なgoチームを説得するのは無理でしょう。１つも有益な
調査結果なり、推測なりが述べられていません。あなたが「ルーチンだのchannelだのselectだの書かなくちゃならない」と
我儘を言ってるようにしか見えません。仮に万が一億が一、必要だとしてもGithubに個人実装のライブラリとしてあるでしょう

612 ：デフォルトの名無しさん：2022/09/09(金) 13:32:44.23 ID:eDV4BhqD.net

まあasync/awaitのほうが初心者に対するハードルは低そうな気はする
初心者が雑にchannel使ってるとたいていバグってるわ

613 ：デフォルトの名無しさん：2022/09/09(金) 13:34:32.33 ID:KNCe5V0g.net

async/await手軽で簡単だけど複雑なことやろうとすると難しい
Goroutineとchannelはasync/awaitと比べると確かにとっつきにくいが複雑のことも組み合わせで上手く実現できる応用力がある

614 ：デフォルトの名無しさん：2022/09/09(金) 14:08:59.93 ID:+r9uXbjm.net

>>611
そういうストローマン論法は俺には通用しないって

615 ：デフォルトの名無しさん：2022/09/09(金) 14:53:32.39 ID:5SEsta+Y.net

promise の利点まとめ

- goroutineとchannelを使うと100%デッドロックが起きるが promise だと安全に実装できるものがあるらしい。具体例は不明。
- >>605 にとってだるくない。

616 ：デフォルトの名無しさん：2022/09/09(金) 15:05:25.55 ID:+6O98yvA.net

非同期で順列な処理やる場合はasyncのがわかりやすい
並列にタスクいっぱい撒いてなんかやるみたいなのはchannelって印象

617 ：デフォルトの名無しさん：[ここ壊れてます] .net

promiseに似てるけど、全く違うものはerrgroup.Groupと呼ばれます。これもpromiseなんぞと比べれば
コンテキストなどと組み合わせキャンセルやタイムアウト処理が容易にできますし、実行順の制御や包括した
エラー処理以外にパイプラインまで簡単に拡張できます。

例1：ページをフェッチして全ての処理が終わるまで待つグループ制御（１つでもエラーならエラー処理）
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-JustErrors

例2：単純な並列タスクを同期するためのグループ制御
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Parallel

例3：多段ステージを設けたパイプライン処理をグループ制御
https://pkg.go.dev/golang.org/x/sync/errgroup#example-Group-Pipeline

例1、例2はJSでいうPromise.all() のような動きをしますがpromiseなんていう融通の利かない非同期のため
だけの劣った機能より格段にシンプルな仕組みです。
上の例でいえば、並列タスクなどではchannelを使用せず、複数起動された軽量ルーチェンから元ルーチェンへ
results配列の結果を戻していますが、これは並列タスクが一段で終わるからです。
次の（例3の）pipeline処理にあるように、並列と並列が連鎖する多段処理においてはchannelのような
仕組みを使うのがとても合理的です。もちろん、処理の終わりの同期のために、selectによる結果受信待ちは
入りますがこれはデットロックではありません

もともとJSのPromiseがなぜあるかといえば、同じプロセス空間で疑似的な非同期処理による実行制御を行うため
だけの仕組みです。このため、特定の変数（結果を格納する配列や変数）に同時にアクセスされるという考えは
ありませんし、そのような（ロックや待ち）制御は必要ありません。現実に同時に動いていないのですから

隣国のアジア人コミュニティに「ストローマン論法」という言葉を連呼するキチガイ集団がいましたが、本当のバカだった

618 ：デフォルトの名無しさん：2022/09/09(金) 18:31:46.48 ID:RxEWaepL.net

結局何がChannelに無くて、何がPromiseでしか解決できない問題なの？
Promiseを解決せずに持ち回ること？

619 ：デフォルトの名無しさん：2022/09/09(金) 23:05:27.12 ID:zn1Qb1Bt.net

>>617
例1がすでに全然シンプルじゃないw
しかもレスポンスを返さない例で意味ないww
それ以外にも落とし穴満載

現実にこんなコード書いてるやつばっかりならバグりまくってヤバそう

620 ：デフォルトの名無しさん：2022/09/10(土) 05:44:14.74 ID:z/endEmr.net

やはり頭がバカ以前のGより脳が小さい、上の人はサンプルをシンプルだとは上でも言ってないが
errgroup.Groupがシンプルだと言っているのに、頭ヤバそう
まあサンプルは十分シンプルだが、レスポンスが要らない事など世の中にいっぱいある

現実にこんな奴がいることは、goより複雑な言語特性や膨大な標準ライブラリを持つ言語を
チーム開発で使えるか、大変考慮すべきことだろうな

621 ：デフォルトの名無しさん：2022/09/10(土) 06:14:16.74 ID:JxBHu2/s.net

#Gopherくんの国葬に賛成します

622 ：デフォルトの名無しさん：2022/09/10(土) 06:49:15.74 ID:0VnbKdes.net

ストローマン

623 ：デフォルトの名無しさん：2022/09/10(土) 09:36:19.36 ID:hVWagXFo.net

まずは基本的に、シングルスレッドの場合とマルチスレッドだが共有データを使用しない場合は原理的に
データ競合や排他制御のバグは発生しない。
>>611が「promiseの方が明らかに楽でバグが生まれない」と言っているのはそのどちらかに帰着するケース。
マルチスレッドでかつ共有データを扱うケースではpromiseを使おうが競合バグは発生し得る。

624 ：デフォルトの名無しさん：2022/09/10(土) 10:19:58.24 ID:wD6Hc2YL.net

シンプルシンプルw

625 ：デフォルトの名無しさん：2022/09/10(土) 10:24:38.51 ID:LoWL2Dfj.net

壺買えばシンプルに見えるよ

626 ：デフォルトの名無しさん：2022/09/10(土) 10:34:19.91 ID:JxBHu2/s.net

ストローマン連呼する人が最近5chで増えたと思ったけどこの動画が原因なのねん
youtu.be/mK3Tnxh4Kho

627 ：デフォルトの名無しさん：2022/09/10(土) 14:08:04.25 ID:t/MG+nKm.net

そもそもGoは何もしなくてもマルチスレッドなんよ。
IO待ちとかしたら勝手に他の事しよるよ。awaitなんかしなくても。
だからFutureやPromiseで結果が来る事を持って回るんじゃなくて、
そもそも処理するロジック自体を複数起こしちゃうんだよ。。

これだけの事をいつまで言ってんのよ。。
>>617
の例1がどうして一気に複数リクエストを送りたいかと言うと、その三つを同じ一つの処理で使いたいからであって、
三つの同じ処理を起こすんであればWaitする必要も無いのでは？
それこそchanで受け取れば良いんだし。。

628 ：デフォルトの名無しさん：2022/09/10(土) 17:44:57.86 ID:xFpfY3aA.net

JSのPromiseしか知らないんだな
そりゃ話が噛み合うわけがない

629 ：デフォルトの名無しさん：2022/09/10(土) 20:27:53.18 ID:hVWagXFo.net

JS以外のpromiseだとどう違うって？

630 ：デフォルトの名無しさん：2022/09/10(土) 21:23:42.19 ID:iWyUjfem.net

内容ゼロのワイ賢者や煽りに煽りで返すスタイルｗww

631 ：デフォルトの名無しさん：2022/09/11(日) 01:29:37.61 ID:VONtFQ6w.net

藁人形♫

632 ：デフォルトの名無しさん：[ここ壊れてます] .net

韓国人の口癖、ストローマン論法という逃亡手段

633 ：デフォルトの名無しさん：2022/09/13(火) 18:17:36.41 ID:Ma8GSz9P.net

ストローマンって本題から離れた部分を、わざと誤解して上げつらう詭弁の手法だから、自己紹介してるんだよ

634 ：デフォルトの名無しさん：2022/09/14(水) 11:14:58.88 ID:xpCSG28g.net

うぬぬぬぬ、issueに送るべきだろうか？

１、「ポインタの」レシーバーでストリンガーを記述すると、fmt.Println()とかに渡してもString()メソッドは呼んでくれない…

２、そして(str{v: 1}).String()とか記述するとコンパイルエラーになる…

変数に一旦格納してからのs.String()は、仕様から(&s).String()と解釈してくれて通る

635 ：デフォルトの名無しさん：2022/09/14(水) 11:17:52.77 ID:xpCSG28g.net

>>634
あ、１は実体を渡すと

636 ：デフォルトの名無しさん：2022/09/14(水) 11:22:55.99 ID:xpCSG28g.net

>>634
コードサンプル

https://go.dev/play/p/cnLcXtFFQ4j

637 ：デフォルトの名無しさん：2022/09/14(水) 11:33:39.56 ID:xpCSG28g.net

>>634
この辺(レシーバー)の仕様って、訳してみると何かガバッてるように思えてならないんだよなぁ

638 ：デフォルトの名無しさん：2022/09/14(水) 11:40:44.99 ID:xpCSG28g.net

>>634
実体のレシーバーはレシーバー内のフィールドを更新しても反映されないから、レシーバーはポインターとして書くのが定石だけど
ストリンガーだけ実体のレシーバーとして書けば回避できる
回避できるなら放置でもいーじゃん？とか言われると反論しづらい

639 ：デフォルトの名無しさん：2022/09/14(水) 15:53:22.22 ID:xpCSG28g.net

>>638
ポインタのレシーバーを記述していると、インタフェース型変数には実体は代入できずポインタでなければならない
という制限もイミフ
代入可能性の仕様は単に、xがインタフェースTを実装していること
実体でもメソッドセットx.String()とx.Str()は呼び出せるのだから実装されている、とは「ならない」事から上記の制限がイミフと言ってる

本当に仕様が厳密じゃなくてガバガバ
大真面目に仕様書を読み込んでる俺の純情を返せ

640 ：デフォルトの名無しさん：2022/09/14(水) 16:03:17.92 ID:xpCSG28g.net

>>639
セレクタ式で実体からポインタレシーバーを呼び出すと&xと解釈されるという仕様が、インタフェースの代入可能性には波及していない、という点でコンパイラのバグと難癖つけられるんじゃないか？
とissueに書いてもいいんじゃないか？という多分にメンドクサイ系おじさんの怒り

仕様書にどう書かれていようが、インタフェースに実体を入れようとするな！で済む話ではあるかも

最終的には「仕様書は信用するな」に帰着

641 ：デフォルトの名無しさん：2022/09/14(水) 17:25:20.47 ID:e1B1zDJm.net

インターフェース型変数という訳のわからないものを導入したのがそもそもの間違いなんだよな

642 ：デフォルトの名無しさん：2022/09/14(水) 20:14:22.35 ID:KrdCg/Z1.net

で、なんでそんなもんを導入したかというとそもそもジェネリックスがなかったから
「ジェネリクスがなくてもプログラムは書ける(キリッ」みたいなイキりにこだわって結局かえって醜いことになるっていうまるでド素人みたいな失敗

643 ：デフォルトの名無しさん：2022/09/14(水) 20:52:01.05 ID:OtPAbKwR.net

一人で喋ってる怖い

644 ：デフォルトの名無しさん：2022/09/15(木) 09:41:05.37 ID:zCeWb7Zl.net

理解できないから人格攻撃に出るあたり、お里(国)が知れるというもの

645 ：デフォルトの名無しさん：2022/09/15(木) 10:04:39.44 ID:I85rKOcV.net

いきなり国がどうとか言い出す人って日常会話出来るのか気になる

646 ：デフォルトの名無しさん：2022/09/15(木) 22:29:29.36 ID:zCeWb7Zl.net

インタフェース変数は普通に色々な言語にあるだろ？
そこにケチをつけるのは筋が悪すぎるのではないか？

647 ：デフォルトの名無しさん：2022/09/16(金) 15:06:43.28 ID:rsr6X2sj.net

ないわw
空インターフェースとか訳がわからんわ

648 ：デフォルトの名無しさん：2022/09/16(金) 16:29:46.84 ID:AcRFw2zF.net

>>636
1. &elem2{}で渡してるのに、func (e elem2) String() stringなんて呼び出すわけないじゃん？どういう事？
2. func (s *str) String() string で普通は定義するので、同じように呼べないからコンパイルエラー
もっと言えば、s := str{}にしても (*str).String(&s)とコンパイル時に解釈されるだけで呼んでるのはポインタメソッド

下のインタフェース型変数云いいは、全く理解ができていないで我儘いってるだけで読んでる人に伝わってないし
マジ何が言いたいのかサッパリ...
goの仕様ほど厳格なものはないと思うけど（比べるのはC/C++や2015年代以前の言語ね、2016年以降の言語と
比べても、いまだに詳細なメモリレイアウトさえ公表できない某錆より厳格だ）本当に大真面目に読んでる？
golangを始める必要性に駆られて、こんな簡単な入門初めのプログラムでケチ付けたいだけじゃ？
issue書いても良いけど、保守的なgolangメンテナーに絶対相手にされないよ

649 ：デフォルトの名無しさん：2022/09/16(金) 16:48:33.54 ID:2lkKV8fn.net

>>648
ちゃんとコードを読みなよ
elemはポインタレシーバーで実装、elem2は実体レシーバーで実装
そしてポインタレシーバーでストリンガーを書くと、fmtパッケージとかでは認識されないケースがあるってサンプルコードよこれ

つまりあなたの主張する func (e *elem)String() string という「普通の定義」では動かないケースを示している
実行してみ？俺も「普通の定義」だと思っていたからこそのレスなんだから

650 ：デフォルトの名無しさん：2022/09/16(金) 16:58:05.87 ID:2lkKV8fn.net

func (e *elem) String() string
と書くとストリンガーとして認識してくれないと説明して
サンプルコードまで載せて確認を求めてるのに
実行すらしてもらえないとは

651 ：デフォルトの名無しさん：2022/09/16(金) 17:11:32.64 ID:fXetx5ML.net

仕様書にポインタ変数.は勝手に*(ポインタ変数).

に変換されるとか書いてあるけどインターフェースでも行われるってのはどこに書いてあるの？

652 ：デフォルトの名無しさん：2022/09/17(土) 02:32:12.33 ID:z62v58Fz.net

>>651
ない
むしろ、インタフェースを実装しているという定義が、全てのメソッドセットを満足している、という程度しか書かれていない

あれ？仕様書だと逆に値は (&x).xxxx に変換されるとしか書かれてなくなかったか？後で確認してみる

653 ：デフォルトの名無しさん：2022/09/17(土) 02:40:37.19 ID:z62v58Fz.net

ポインタと値レシーバーは特に注意しなくても相互にセレクタとして呼べるんで気にしていなかったんだけど、ポインタでストリンガーを書いたらfmtパッケージの関数では認識してくれなかった
んで、これは不味いと総当たりで確認してみた

しかし、単に自分の勘違いかなと確認コードを公開してみて、レビューを求めている←イマココ

654 ：デフォルトの名無しさん：2022/09/17(土) 02:47:40.39 ID:z62v58Fz.net

まだfmtパッケージの中は見ていないけど、ポインタレシーバーで書くと型スイッチかリフレクションではインタフェースを満たしていないと見なされたりするんじゃないか？とか不安になってきた

上でも書いたけどfunc (e *elem)String()は自分も「普通の」書き方だと思ってたんで

655 ：デフォルトの名無しさん：2022/09/18(日) 09:35:57.42 ID:Ymh3f8Pk.net

な、仕様なんてこいつ読んでないだろ？5chぐらいでしか自分の連投でしか意見言えない
issueとかこいつは言ってみただけでそれすら出来ない

656 ：デフォルトの名無しさん：2022/09/18(日) 09:58:37.38 ID:pgs2ObNe.net

>>655
そいつ次世代言語スレで機能精神崩壊してたんだぜ

自分のRustの実力(知ったか)で仕事にありつくのが難しいと観念して これからはGoに粘着するよ

ここが新しい 隔離スレ よろしく頼む

657 ：デフォルトの名無しさん：2022/09/18(日) 10:43:21.71 ID:d4i41YBr.net

理解できない

・ポインタでストリンガーを書いてしまうと動かないケースがある
・実例をプレイグラウンドで上げたから間違っていたなら指摘してくれ

に対しての回答になってない
これこそ関係のない些事を上げ連ねて議論を避けるストローマン話法の典型じゃね？

658 ：デフォルトの名無しさん：2022/09/18(日) 11:17:33.27 ID:6lT6OUda.net

Promise最強ストローマンおじさんw
仕様書なんて読んでないんだろ？そもそも英語読めないから読んでないどころか読めないんでしょ？w

659 ：デフォルトの名無しさん：2022/09/18(日) 22:39:49.75 ID:ds+slurx.net

なんか勘違いしてるけど相互運用ではないよ

レシーバが値のメソッドはポインタと値に対して呼び出すことができるが
ポインタのメソッドはポインタに対してのみ呼び出すことができる

これは仕様書に書いてある

660 ：デフォルトの名無しさん：2022/09/18(日) 22:48:21.16 ID:YN5s6Pjv.net

>>659
これで全部解決しててワロタ
二度と喚き散らすなよ

661 ：デフォルトの名無しさん：2022/09/19(月) 08:13:25.10 ID:uG07qrUI.net

>>659
んにゃ
「メソッド呼び出しと同様に、アドレス指定可能な値を用いたポインタレシーバーによる非インタフェースメソッドへの参照は、自動的にその値のアドレスを取りますのでt.Mpは(&t).Mpと等価になります」Method values より
とあるよ

662 ：デフォルトの名無しさん：2022/09/19(月) 08:20:33.46 ID:uG07qrUI.net

>>659
As with method calls, a reference to a non-interface method with a pointer receiver using an addressable value will automatically take the address of the value; t.Mp is equivalent to (&t).Mp.
のトコね
誤訳してるなら指摘してくれな

663 ：デフォルトの名無しさん：2022/09/19(月) 08:24:13.55 ID:uG07qrUI.net

まあ、こんな感じにぜーんぶ読み通さないと系統だった仕様の把握ができそうにない、という点で、かなり品質は良くないんよ
これ、どっちが優先されるの？？？という話が多すぎて、実際に試行するとアレ？となる

664 ：デフォルトの名無しさん：2022/09/19(月) 08:35:15.69 ID:uG07qrUI.net

仕様書の全訳に挑んでオカシイとサンプルコード書いて確認してみてレスしてるのに
仕様書を読んでない奴がそのサンプルコードをRunすらせずに、お前が勘違いしている、とか
へそで茶わかしていいでしょうか？

665 ：デフォルトの名無しさん：2022/09/19(月) 08:42:10.25 ID:Uuvgp4zf.net

>>662
いや、それ暗黙的にポインタに変換してるからポインタに対して呼び出してるよね？
理解できてる？

666 ：デフォルトの名無しさん：2022/09/19(月) 08:45:47.87 ID:wNLDibxP.net

>>664
なんだ英語読むのに苦労してる人か

そういう人が日本語訳に取り組むと迷惑

オカシイところがあると言うなら原文の方にPR出せ

667 ：デフォルトの名無しさん：2022/09/19(月) 08:51:12.18 ID:Uuvgp4zf.net

はいサンプルね
interfaceはポインタレシーバーだとポインタ変数しか代入できないのに対して
メソッド呼び出しは全部成功しているよね？

https://go.dev/play/p/X71811pJ1sQ

メソッド呼び出しとインタフェースの仕様を混同しているから話にならない
英語読めない文盲ってことが証明されたな

668 ：デフォルトの名無しさん：2022/09/19(月) 13:12:10.62 ID:TLnbUxjm.net

>>667
わかってないふりしてるけどもう理解できたんだろ？
インターフェースのマッチ時のメソッド呼び出しについては>>659
明示的に呼び出す場合は>>662で変換される
(自分で呼び出すのだから当然インターフェース云々とは無関係)

669 ：デフォルトの名無しさん：2022/09/19(月) 14:35:47.93 ID:DYtWz9pX.net

言語的にケチ付けたいだけでしょ？
http://hissi.org/read.php/tech/20220914/eHBDU0cyOGc.html
http://hissi.org/read.php/tech/20220917/ejYydjU4Rno.html

こんなに一生懸命書く奴がほかに書き込んでない訳ないわ、またいつものRustかC#かアホみたいな他を攻撃する信者のオッサン

670 ：デフォルトの名無しさん：2022/09/19(月) 14:40:24.76 ID:TLnbUxjm.net

でもGoの知識増えたしいいんじゃない？
育成は成功だ

671 ：デフォルトの名無しさん：2022/10/14(金) 19:27:35.90 ID:BY1P2csp.net

Googleのたかが1プロジェクトが C++で始まるからと言ってGoの終わりを感じ始めるなんてどういう審美眼で生きてんだよ。

672 ：デフォルトの名無しさん：2022/10/14(金) 19:30:06.02 ID:5TqK6JoH.net

>>671
そうなんだろうけど、言いっぷりがなんかちょっと引っかからんか
お前やる気ないんか？ってメンションしたいくらいだわしないけど(´・ω・｀)

673 ：デフォルトの名無しさん：2022/10/14(金) 20:40:12.25 ID:B3yPY6eO.net

審美眼w

674 ：デフォルトの名無しさん：2022/10/14(金) 21:08:37.72 ID:lXZRrdjw.net

>>672
普通にリプで使われまくってるって言ってるが

675 ：デフォルトの名無しさん：2022/10/15(土) 20:39:15.62 ID:oepRuRjK.net

Googleってコーディングに関しては無茶苦茶保守的というか統制的だからな
開発者の好みより合理的判断を優先した結果だろう
そういう文化だからこそGoみたいな極右言語が生まれたとも言えるのだが

676 ：デフォルトの名無しさん：2022/10/15(土) 21:16:18.42 ID:i2DHISwU.net

数多の捨てられたプロジェクトに比べればGo言語は成功した部類だろうよ。

677 ：デフォルトの名無しさん：2022/10/16(日) 20:12:43.19 ID:rzkq3MMZ.net

オッス！オラGo！

678 ：デフォルトの名無しさん：2022/10/16(日) 23:36:46.06 ID:sPVu6wa4.net

オラGolang
いっちょやってみっか

679 ：デフォルトの名無しさん：2022/10/19(水) 22:35:19.30 ID:wI0tEVCM.net

なんでC++なんて使ってるんだよ
新プロジェクトで使う言語じゃねーだろ

680 ：デフォルトの名無しさん：2022/10/20(木) 01:44:44.00 ID:5E4liKFh.net

Googleは独自のビルドシステムなど過剰に最適化された開発環境を持ってるから、簡単に言語変えられないんだよ

681 ：デフォルトの名無しさん：2022/10/20(木) 02:39:12.77 ID:ce/AQgdF.net

いや、たんに仕事が雑なだけだとおもう
とりあえず新プロジェクトやるぞー！
で？言語は？
C++で。
あれ？ウチの会社なんか新しいのはGOでやるとかいってなかったけ？
そうだっけ？べつにいーじゃん、Goはマスコットきもいし、C++のほうが楽だから俺んとこはこれでヨロシク！
こんな感じだろう

682 ：デフォルトの名無しさん：2022/10/20(木) 04:11:13.86 ID:XisYbstq.net

RustじゃなくてC++なのが逆張りっぽくてキモい

683 ：デフォルトの名無しさん：2022/10/26(水) 14:45:01.27 ID:bQQxHwPn.net

Goは低落傾向だよな

684 ：デフォルトの名無しさん：2022/10/27(木) 12:55:24.22 ID:8IxaEUdi.net

Goの後は何がくるの？

685 ：デフォルトの名無しさん：2022/10/27(木) 13:56:20.40 ID:dR6kLI3k.net

Rock(´・ω・｀)

686 ：デフォルトの名無しさん：2022/10/27(木) 14:48:53.91 ID:JD5Xibbr.net

Goの前はなんだったん？

687 ：デフォルトの名無しさん：2022/10/27(木) 14:57:45.98 ID:NvTdXXa8.net

PHPかRubyじゃね

688 ：デフォルトの名無しさん：2022/10/27(木) 15:21:32.99 ID:dR6kLI3k.net

C（しー）だろ(´・ω・｀)

689 ：デフォルトの名無しさん：2022/10/27(木) 15:51:18.10 ID:JD5Xibbr.net

dR6kLI3k
超好き

690 ：デフォルトの名無しさん：2022/10/31(月) 23:02:39.22 ID:sD6lQxmd.net

Dが2001年、F#が2005年、Goが2009年(年はwikipediaに書いてあった登場時期)
うまく並びそうだなと思たんだけどEがない

Goの次はHack(2014年)で間違いないよね。

691 ：デフォルトの名無しさん：2022/11/07(月) 21:16:50.51 ID:CyGVtWq4.net

最小とか最大を求める関数は自分で作れって話なの？
あと、整数の絶対値とか

692 ：デフォルトの名無しさん：2022/11/07(月) 21:23:29.28 ID:Jjz79PGF.net

>>691
https://aiprogrammer.hashlab.jp/

https://i.imgur.com/VZsGFBV.png
このサービスは適切にライブラリ使ってくれるはずだから、
多分無いんだろうな

693 ：デフォルトの名無しさん：2022/11/07(月) 21:46:44.70 ID:FtLbuDZg.net

二分探索できたりする場合もあるからそういうライブラリはあえて作ってないんだと思われる
ライブラリ側で最適な実装で作れる場合はちゃんと用意されてることが多い
（http2とかDB周りとか）

694 ：693：2022/11/09(水) 22:20:34.16 ID:lnZKpzqz.net

お二人ともありがとうございます。

695 ：デフォルトの名無しさん：2022/12/08(木) 18:39:09.15 ID:uxR4Nxrs.net

windows環境でGoをアップデートするにはどうしたらいいでしょうか？
新しいバーションで上書きインストールしちゃえばいいんでしょうか？

696 ：デフォルトの名無しさん：2022/12/08(木) 18:52:51.60 ID:CQKYsqd2.net

Chocolateyでやってるのを見てみると、上書きっぽいけど

697 ：デフォルトの名無しさん：2022/12/10(土) 13:20:48.86 ID:tbDvYRlN.net

wingetUIであらゆるものを一括アップデート

698 ：デフォルトの名無しさん：2022/12/10(土) 17:41:52.62 ID:pF+bGi+J.net

GoなんかどうせWinネイティブで使う意味ないんだから、WSLでHomebrewでも使って入れたらいいんじゃない

699 ：デフォルトの名無しさん：2022/12/10(土) 18:33:44.18 ID:EIv2riio.net

暇だったから>>691を流行りのChatGPTに書いてもらった

https://i.imgur.com/ObP9Twg.png

700 ：デフォルトの名無しさん：2022/12/10(土) 18:54:44.75 ID:wODlVXAD.net

>>699
テストコードも書いてもらってみて

701 ：デフォルトの名無しさん：2022/12/10(土) 19:02:48.17 ID:EIv2riio.net

>>700
https://i.imgur.com/z6DYfbM.png
https://i.imgur.com/xLZMGaq.png
https://i.imgur.com/aMF42Kk.png

おもろいから無料βの今遊んどくことをおすすめするぞ
アセンブラ（65816）も書いてくれた

702 ：デフォルトの名無しさん：2022/12/10(土) 19:27:57.88 ID:EIv2riio.net

ちなみにChatGPTはセッション的に一連の会話を一時的に覚えててくれるらしいから、
二回目には同じ関数のコメントが省略されてる
関数の名前を明示すれば、「○○のテストコード書いて」でやってくれたかも
まあスレチだな

703 ：デフォルトの名無しさん：2022/12/10(土) 22:11:37.20 ID:44qA0nvq.net

>>701
テストケース考えるときの助けによさそうだな
たいしたもんだ

704 ：デフォルトの名無しさん：2022/12/11(日) 20:52:12.36 ID:5Jzg/4z6.net

Go言語はこの先生きのこれるのか？聞いてみたら面白いかもな。

705 ：デフォルトの名無しさん：2022/12/11(日) 22:00:53.37 ID:OomiNZje.net

あとゴーファーくんがキモいかどうか聞いてくれ

706 ：デフォルトの名無しさん：2022/12/11(日) 23:59:02.05 ID:E83NyA42.net

https://i.imgur.com/XeXqmNB.png

707 ：デフォルトの名無しさん：2022/12/12(月) 00:36:12.57 ID:lSFKnCD8.net

やはりChatGPTだめだな！
"かわいらしい外観が特徴で愛される存在となってる"
こんな回答では人類の知性にまだまだおよばない！
ただしい知性ある回答はこうだ!
"きもかわいい外観で一部のマニアックなgo開発者に愛されています"

708 ：デフォルトの名無しさん：2022/12/12(月) 05:06:40.93 ID:3lAXikmn.net

地元のマイナーなサッカーチームについて聞いたら「日本でも見逃すことのできないチームの一つ」とか適当に答えたぞコイツ
IT系以外は知ったかする

709 ：デフォルトの名無しさん：2022/12/12(月) 10:35:46.50 ID:+aBs88Ma.net

>>708
ITでも知ったかするよ
N88BASIC書いてもらったら大嘘な奴が出てきた
ちゃんと下げ親指ボタン押して運営にレポートするとよろし

710 ：デフォルトの名無しさん：2022/12/12(月) 14:23:40.21 ID:Sd/ABjr2.net

真面目な話、わからんことを素直に「それについてはわかりません」と言ってくれないのはかなりタチがわるいな
新入社員だったら要注意人物だよ

711 ：デフォルトの名無しさん：2022/12/12(月) 15:22:25.27 ID:+aBs88Ma.net

>>710
わかりません　と答える場合もある
AI君がわかった気になってるだけ
更にタチが悪いけどもｗ

スレに沿って書くなら、エンジニアの仕事はまだまだ安泰だが、使いようによっちゃ楽はできる
って感じね

712 ：デフォルトの名無しさん：2022/12/27(火) 22:42:29.20 ID:zgwkOx1T.net

rainu/go-command-chain: A go library for easy configure and run command chains. Such like pipelining in unix shells.
https://github.com/rainu/go-command-chain

713 ：デフォルトの名無しさん：2022/12/28(水) 10:01:43.96 ID:/bZ5g76e.net

CLIの引数の読み取りするライブラリーは何がおすすめ？

kingpinは最近更新されてないからkong試してみたが
なんか使いづらい
ここに挙がってる他のやつ試そうかと思う
https://www.reddit.com/r/golang/comments/9uybnt/choosing_a_library_for_cli_application/

Neither, personally I like https://github.com/jessevdk/go-flags. I like the declarative approach a lot more than the imperative one used for many other options, and it's extremely feature-rich.

714 ：デフォルトの名無しさん：2022/12/28(水) 10:02:39.35 ID:/bZ5g76e.net

https://github.com/jessevdk/go-flags

715 ：デフォルトの名無しさん：2022/12/28(水) 10:04:18.11 ID:Vd7DA+tc.net

https://github.com/spf13/cobra
これ

716 ：デフォルトの名無しさん：2022/12/28(水) 10:25:06.75 ID:/bZ5g76e.net

>>715
Cobraはこんな感じのこと書かれてるけど
どんなコードを指してるのか分からん

kingpinは直感的に使える気がするけどメンテナンスされてない
問題なければこのまま使えば良いか？

Both cobra and urfave/cli both enforce a globals-heavy, inversion-of-control architectural pattern that's difficult to maintain.
IMO, Kingpin is the only widely-used CLI library that takes an appropriate architectural approach.

717 ：デフォルトの名無しさん：2022/12/28(水) 18:14:44.71 ID:Vd7DA+tc.net

>>716
読んできて判断すればいいじゃん。そんなに読めないものじゃないし使い方も難しくない。アーキテクチャはたしかに理想的ではないと俺も思ってるけど、利用面からの意見としては、、
実戦で使用されていて信頼できる
機能面でも多言語の相当品と同じことがまあまあの書きやすさで書ける。ただしやや歴史的機能があったりして隅々まで洗練されてるとは言い難い印象
コマンドラインの補完などほかの言語では少々保守が面倒な機能があって便利

っと思ってる。でもとにかく評判より自分で確かめたらいいよ

718 ：デフォルトの名無しさん：2023/01/03(火) 22:07:17.76 ID:nBTO23xG.net

cobraはサブコマンドを無限に生やすような大規模向け、Kubernetes/dockerで使用されてる。
そこまで拡張する予定がない場合はgo-flagsかもっとシンプルな mitchellh/cliかな？ちょっとオプションがあるだけなら標準?のflagsだろうけど、普通に*nixのfindぐらいオプションがあるならやっぱりgo-flagsがおすすめだわ
大した関連性がないのに１つのバイナリのサブコマンドになってるより、別プログラムのほうが設計もメンテも楽だしcobraが**とても**メンテしやすいという話だけど、それは変らない。
本当にそこまで多数のオプションで動きが変わるようなプログラムを作るのか？という自問自答が必要だと思う、いやcobraは良いと思うけどね

719 ：デフォルトの名無しさん：2023/02/02(木) 11:00:03.89 ID:aD0kITwS.net

https://go.dev/blog/go1.20

720 ：デフォルトの名無しさん：2023/02/02(木) 22:07:10.87 ID:u1Hba8Dd.net

正式版リリースされたんだろうね。

721 ：デフォルトの名無しさん：2023/02/05(日) 14:04:47.63 ID:hlR7Lbz4.net

ジェネリックスって、有名どころのOSSのライブラリで活用されたりしてるの?
それとも手遅れ?
ORMあたりでこねぇかな

722 ：デフォルトの名無しさん：2023/03/03(金) 19:04:29.44 ID:E2W0QKCP.net

Go言語でマイクロサービスの実装を解説してる書籍はありますかねえ？

723 ：デフォルトの名無しさん：2023/03/13(月) 22:26:20.80 ID:i1e+c7zN.net

>>475
今まさに使ってるよ

724 ：デフォルトの名無しさん：2023/04/05(水) 05:10:28.93 ID:DRPu7HQc.net

>>722
以下は、Golangを使用してマイクロサービスを開発するための書籍です。

"Goで学ぶマイクロサービス設計入門" - 田中 充史 著
　　この本は、Golangを使用してマイクロサービスを設計する方法を解説しています。サンプルコードを使用して、マイクロサービスの作成、展開、スケーリングなどを実践的に学ぶことができます。

"GoによるWebアプリケーション開発" - 佐藤 幸一 著
　　この本は、Golangを使用してWebアプリケーションを開発する方法を解説しています。マイクロサービスの設計と開発に必要な概念と技術を学ぶことができます。

"Goマイクロサービスパターン" - マテウス・カルステンス 著
　　この本は、Golangを使用してマイクロサービスを実装するためのパターンを紹介しています。パターンに従って実装することで、マイクロサービスの堅牢性、柔軟性、スケーラビリティを高めることができます。

以上の書籍は、Golangを使用してマイクロサービスを開発する際に役立つ情報が含まれています。どの書籍も、実践的なアプローチを採用しており、Golangの基礎から応用まで幅広くカバーしています。

725 ：デフォルトの名無しさん：2023/04/24(月) 17:12:53.41 ID:cAv437kT.net

Go言語入りユニクロTシャツ、Akamaiが提供　コードを動かしてみた人も=ITmedia

726 ：デフォルトの名無しさん：2023/06/02(金) 19:10:27.48 ID:iTDmv0FSX

Go言語って流行ってるんですか。Go言語での仕事ってたくさんあるんですか。
ま〜どうでもいいけど。

727 ：デフォルトの名無しさん：2023/06/09(金) 20:38:28.47 ID:cm/uNDIo.net

1.20.5リリース

728 ：デフォルトの名無しさん：2023/06/25(日) 22:02:04.84 ID:i+k3hE2N.net

ビルトインmin,maxやっときたか

729 ：デフォルトの名無しさん：2023/07/26(水) 21:01:05.26 ID:gfwPzIhn.net

今期の公式調査が来たからみんな答えよう

以前の発表通りエラー制御に本腰入れ始めるのかまたもや意識調査が含まれてた
AIについての質問もあったし標準で組み込まれる未来もあるのかしら

730 ：デフォルトの名無しさん：2023/07/26(水) 23:19:31.81 ID:y7c46OWN.net

Goはこの中途半端な立ち位置のまま
この限られた用途以外で一般的に使われる言語にはならないと思われる

731 ：デフォルトの名無しさん：2023/07/27(木) 08:50:36.21 ID:avMPxvPz.net

昔Rubyがブイブイいわせていた時、私はPythonを選びました
本物には本物が分かります、そして私は静的言語としてGoを選択します
そうです、これが本物の回答なのです
いえ、これは私が優れているということではありません
Goが優れているということなのです

732 ：デフォルトの名無しさん：2023/07/27(木) 13:33:27.28 ID:PeWu9EZy.net

goもこのまま衰退してしまうのだろうか。
今からならrust覚えた方がいいかな。

733 ：デフォルトの名無しさん：2023/07/27(木) 22:38:03.18 ID:3hHUpwom.net

そういえばジェネリクスはもう実装されたんだよな。もうinterface{}地獄じゃないのかな。

734 ：デフォルトの名無しさん：2023/07/29(土) 17:37:17.23 ID:meVoqp2J.net

まだ地獄やろ、
そんなはやくライブラリに取りこまれないんじゃないか
ORMとかどうなったのかな

735 ：デフォルトの名無しさん：2023/07/31(月) 00:39:34.75 ID:vFPs2eWw.net

agoutiのかわりのライブラリでないかなー

736 ：デフォルトの名無しさん：2023/08/18(金) 16:42:15.53 ID:hpPc67cT.net

かなり早い段階で翻訳が出たな
原著公式レポがあるから動かす手間を惜しまなければ何がダメなのか分かるけどね
https://github.com/teivah/100-go-mistakes/blob/master/09-concurrency-practice/68-string-formatting/main.go

“開発の失敗学”から生産性とコード品質を高める。『Go言語 100Tips ありがちなミスを把握し、実装を最適化する』
Goプログラミングの間違いを網羅的に解説した一冊
https://forest.watch.impress.co.jp/docs/bookwatch/news/1524131.html

https://www.アmazon.com/100-Mistakes-How-Avoid-Them/dp/1617299596
翻訳者ご本人 柴田芳樹 5.0 out of 5 stars The equivalent of "Effective Java"
>However, please note that there are many minor errors in the book, so if you can read Japanese, I recommend the Japanese version that I have translated.

なおreadme翻訳募集中
README: Japanese translation 🇯🇵
https://github.com/teivah/100-go-mistakes/issues/30

737 ：デフォルトの名無しさん：2023/09/03(日) 01:50:02.49 ID:Cy9pNCnO.net

最近goはじめたけど、例外処理になれないわ

今まで安易にスローしてきたつけが出てる感じ

738 ：デフォルトの名無しさん：2023/09/17(日) 01:24:19.14 ID:gmX20b6T.net

身内に不幸があったので

739 ：デフォルトの名無しさん：2023/09/18(月) 10:08:19.99 ID:CekIHz6dr

私利私欲のために莫大な温室効果ガスまき散らして気候変動させて災害連発させて人殺して石油需給逼迫させて物価暴騰させて社会に莫大な
損害を与えながらノコノコスーダンやらに行ってなにやら巻き込まれてるボケどもが、クソ税金泥棒公務員利権のネタにされながら人件費だの
食料だのと1億は税金をドブに捨ててるだろう何の関係もない国民から強奪した莫大な税金使って迎えに行くとか唖然とするが、こいつら
ひとり1000万ほど徴収すべきだし、こういうことのために今後は邦人の出国税ひとり100０万は徴収しないとな、入管収容て゛税金泥棒
1０0%のクソ公務員の過失責任を税金で肩代わりするとかやってるカ゛イジン入国税も1000万は徴収するのか゛筋だし、クソ航空機には
航空燃料税1KL1千万円、離発着税1回1億円、上空通過税1Km100万円、それ以前にスティンカ゛―解禁して、私有地からのクソ航空機
撃墜を合法化するのは住民としての普遍的な権利だし．憲法ガン無視て゛都心まて゛数珠つなぎでクソ航空機飛ばして私権侵害して私腹を肥やす
強盗殺人の首魁斎藤鉄夫ら世界最悪の殺人腐敗組織公明党を壊滅させないと，お前らの生活は苦しくなる−方だという現実に気つ゛かないとな!
(羽田)ttps://www.call4.jp/info.php?type=items&id＝I000０062 , ttps://haneda-Рroject.jimdofrеe.com／
(成田)tｔps://n-souonhigaisosУoudan.amebaownd.com/
(テロ組織)ttPs://i.imgur.Ｃom/hnli１ga.jpeg

740 ：デフォルトの名無しさん：2023/09/28(木) 18:02:19.03 ID:58VlP50A.net

みんなgoに帰ってくる

741 ：デフォルトの名無しさん：2023/09/28(木) 18:30:24.70 ID:gS/5M63X.net

女性がイクときは3パターンある
1.come(欧米)
2.go(日本)
3.end(日本ではあまり知られていない)

742 ：デフォルトの名無しさん：2023/10/14(土) 18:38:23.73 ID:fMt8uhtsz

自閉隊員が自閉隊員を銃殺とか税金泥棒殺人組織丸出した゛が岸田異次元増税憲法カ゛ン無視地球破壞軍国主義税金泥棒文雄に殺されたも同然
結局少子化が國の存続ガーだの嘘八百こいてんのは利権確保とてめえか゛自由に殺せる兵隊か゛ほしいという邪悪な権カ欲求によるものだしな
日本に原爆落とした世界最悪のならず者国家と共謀して軍事演習た゛なんだと隣国挑発して正当防衛権行使させて白々しく安全保障ガーだの
プロパガンダ放送連発させてバカ丸出しのJアラートだの国民煽って憲法9条無視して軍事増税して軍事大国化
相当の盆暗でもなければこの悪質な茶番劇に怒りを覚えるわな
無意味極まりない上空撮影のために私権侵害報道ヘリか゛グルク゛ル飛び回ってむしろ殺人自閉隊員よりもこいつらこそが莫大な温室効果カ゛ス
まき散らして地球破壞して氣候変動させて災害連発させて人殺してるのは明らか、カによるー方的な現状変更によって都心まて゛数珠つなぎで
憲法カ゛ン無視でクソ航空機に私権侵害させて人殺しまくってるしお前ら惡質自民公明を殲滅するか殺されるかのどちらかだぞ
［羽田)ttps://www.call4.jｐ/info.phｐ?type=iｔеms&id=I00０0０62 , tｔps://haneda-project.jimdofrｅe.com/
（成田)TТps://n-souonhigaisosｙoudan.amebaownd.ｃom/
(テロ組織)ttps://i.imgur.com/hnli1ga.jpeg

743 ：デフォルトの名無しさん：2023/11/27(月) 22:53:28.32 ID:9f7xeaaD.net

mattnさんのGo本半額だったのに買い忘れた…
昨日でセール終わってた

744 ：デフォルトの名無しさん：2023/12/31(日) 23:28:43.30 ID:dxC8BLNX.net

もっと盛り上げてもらっていっすか？

745 ：デフォルトの名無しさん：2024/01/10(水) 20:53:52.31 ID:lwrDTIi6.net

goいいよな
わかりやすい

でもpythonのあほみたいな量のライブラリ使った後は自分で作んなきゃいけないんかとなる

746 ：デフォルトの名無しさん：2024/01/10(水) 21:15:00.66 ID:3AggmXC7.net

マイクロサービス向けの言語だから
APIサーバーとか小さな特化したものを
サクッと作るのに適してる

それ以上のことやると死ぬだけ
まさしく適材適所

747 ：デフォルトの名無しさん：2024/01/11(木) 20:28:02.09 ID:dlUe/OEx.net

コピペ地獄

748 ：デフォルトの名無しさん：2024/01/15(月) 10:36:24.87 ID:dnGwE3TA.net

勉強がてらGoでwebサービスやってるけどLaravelで良いじゃんって気がしてしょうがないw
PHP Laravel再評価の時代来そう

749 ：デフォルトの名無しさん：2024/01/15(月) 11:07:21.77 ID:WLI3YoB9.net

> PHP Laravel再評価の時代来そう

こない。

750 ：デフォルトの名無しさん：2024/01/16(火) 00:18:43.14 ID:OEv0o386.net

プロの労働市場は、Ruby, AWS Solution Architect だけ。
Java は多重請負構造のIT 土方

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5〜7

PHP : 5
Dart : 4.4

PHP, Dart は、コンピューターサイエンスを勉強していない高卒用言語

フレームワークは、
Ruby on Rails : 9 万ドル
Django : 6
Laravel : 3.8

YouTube で有名な雑食系エンジニア・KENTA が言ってる。
初心者のキャリアパスは、Rails → Go のみ

Ruby/Goの神・HashiCorp のMitchell Hashimoto がそう。
Ruby製のVagrant → Go製のTerraform。
今は、Goプログラマーしか求めていない

PHP, Scala はKENTAがオワコン認定したので、絶対にやってはいけない言語です！

751 ：デフォルトの名無しさん：2024/01/17(水) 20:06:14.83 ID:IsM8Z7mt.net

なるほど尊師様がおっしゃるのなら間違いないw

752 ：デフォルトの名無しさん：2024/01/19(金) 05:11:59.56 ID:P4Evroye.net

地雷原を歩かせるスパルタ…！

753 ：デフォルトの名無しさん：2024/01/28(日) 11:18:59.19 ID:pEbeI3Z0.net

Goしか勝たん

754 ：デフォルトの名無しさん：2024/02/07(水) 17:22:45.49 ID:eJRtBQFR.net

Googleがプログラミング言語「Rust」に100万米ドルを助成
「C++」との併存・置き換えを図る
https://forest.watch.impress.co.jp/docs/news/1566662.html

755 ：デフォルトの名無しさん：2024/02/07(水) 17:32:10.04 ID:6WfYYP7P.net

スレ違い

756 ：デフォルトの名無しさん：2024/02/13(火) 21:58:15.14 ID:ty/4roqG.net

.22 のmuxのパラメタさぁ

757 ：デフォルトの名無しさん：2024/02/14(水) 13:09:52.21 ID:gybktDWa.net

mux使ってないけど、なんかあったん？

758 ：749：2024/02/14(水) 20:05:40.85 ID:73JEoiws.net

米国年収でも、Rubyは、Go/Rust/Elixir の3大言語を超えた！

2022 -> 2023

Ruby : 9.3 -> 9.9 万ドル
Elixir : 9.3 -> 9.6
Go : 8.9 -> 9.3
Rust : 8.7 -> 8.7

多くの言語 : 6.5〜7 -> 7.3〜7.8

PHP : 5 -> 5.9
Dart : 4.4 -> 5.6

759 ：デフォルトの名無しさん：2024/04/03(水) 16:01:02.02 ID:eNgZCM35.net

>>754
GoogleはGoにしたいのか、Rustにしたいのか

760 ：デフォルトの名無しさん：2024/04/03(水) 16:23:26.97 ID:V8E7QtS4.net

したいって現状用途が全然違うのに

761 ：デフォルトの名無しさん：2024/04/03(水) 16:40:24.82 ID:eNgZCM35.net

>>760
確かに現状用途が異なる。GoがWeb、Rustがシステム記述
しかし、本来はGoもRustと同じところを狙っていたのではないかと

762 ：デフォルトの名無しさん：2024/04/03(水) 16:51:21.63 ID:V8E7QtS4.net

goとrustじゃあ全然言語機能違いすぎるよ
goは言語自体くそシンプルでだからバックエンドのマイクロサービスみたいな
小さなサービス自体を実装するのに使われてる(用途)
goでそれ以上のことをやると死にかけると思う

GoとRustはC#とJavaみたいなにたもんじゃないと思う

763 ：デフォルトの名無しさん：2024/04/03(水) 17:00:55.33 ID:V8E7QtS4.net

逆にRustでバックエンドのWebサービス実装する
フレームワークあるけどコンパイル時間長すぎて
Webとか時間の流れ速い分野ではこれはこれで地獄だし

GoとRustは色々比較して別物だからな
用途も現状すみわけられてると思う

764 ：デフォルトの名無しさん：2024/04/03(水) 17:16:01.43 ID:V8E7QtS4.net

本来についてはどうなんだろうね
Goはシステム記述を最初から狙ってたの?
システム記述がどこを指すのかにもよるけど

765 ：デフォルトの名無しさん：2024/04/03(水) 17:37:49.09 ID:iMBIpEa8.net

でも実際GoogleはGoで書かれたものもRustに移行してる
生産性は同程度だけど不具合の数が圧倒的に少なくなったらしくかなり前向きっぽい

766 ：デフォルトの名無しさん：2024/04/03(水) 19:14:38.98 ID:IrOohhoZ.net

RustはC/C++の代替言語なわけで結局メモリ管理のための記述が必要な低級言語なんだよ〜
ガベージコレクションの無い低級言語なんか触りたくないぽよぉ〜、Goしか勝たん！

767 ：デフォルトの名無しさん：2024/04/03(水) 19:19:11.96 ID:SPeUFyxp.net

シンプルな言語機能でコードの保守性を高めることがGo言語の目的で、それはRustと真逆のような

768 ：デフォルトの名無しさん：2024/04/03(水) 19:21:07.80 ID:i4V1+m9a.net

Rustが人気な理由は
完全にメモリ自動解放しかも必ず安全
を実現しつつC言語と同等の速さで動く点

769 ：デフォルトの名無しさん：2024/04/04(木) 22:12:02.80 ID:vlvoJs2w.net

つかメモリ管理が～とか中級者まででしょ
普通の頭があれば25歳までに卒業してるわ

770 ：デフォルトの名無しさん：2024/04/04(木) 23:05:06.38 ID:G0cwdLmq.net

javaがウケたのもcがウケたのも
シンプルだったからなんやろねえ
実際のプログラミングってのはどうしたってクソみたいな
状態の山、依存の山みたいなもんに取り組んでいくわけで
余計な複雑さを持ち込まないでほしいってのは現場のリアルな声だと思う

もちろんgoも、それをわかってて、それを押さえてる

771 ：デフォルトの名無しさん：2024/04/04(木) 23:26:31.09 ID:Chhm4gg1.net

>>770
Cが受けたのは他が糞だったから。勿論Cの完成度は超高いにしても。
あとその当時はCPUが非力すぎて軽くないと話にならなかった。
Javaが受けたのはCで鬼門だったポインタを廃止してGCも導入し、馬鹿でもバグが出にくくなったから。
その後スクリプト言語が受けてるのは富豪プログラミングの方が断然楽だから。
ただ効率を考えたらポインタを直接扱える方が断然有利なので、Goは簡単な範囲でポインタを使える言語の位置づけだと思う。

772 ：デフォルトの名無しさん：2024/04/04(木) 23:40:17.98 ID:vlvoJs2w.net

ただしJavaは敷居を下げすぎて業界にバカが多数流入した
ポインタを取り扱える/扱えない がハードルとして機能していた
Go関係ない話ですまん

773 ：デフォルトの名無しさん：2024/04/05(金) 00:59:31.65 ID:wkA5bdgA.net

>>763
初老のおっさんのyoutubeで見たけど
actix-web使ったプロジェクトのビルドに10分位掛かってた。
もうちょっと頭使って環境作ればいいのに

ちなワシの環境なら10秒程度

774 ：デフォルトの名無しさん：2024/04/27(土) 20:42:50.26 ID:PtA3qgXN.net

こんばんは

Goってネームバリューあるけどそんなに盛り上がってる感じじゃないよね
javaの後継になるかと思ってたけどそうでもないし

775 ：デフォルトの名無しさん：2024/04/27(土) 21:13:07.86 ID:K8Ze6DJO.net

言語仕様が簡素な点が特徴だけど
Javaのような大規模開発には向いてないかな
ガベージコレクションがあるからC/C++の分野も不向き
守備範囲が意外に狭い

776 ：デフォルトの名無しさん：2024/04/27(土) 23:58:02.43 ID:9h9dlcQc.net

Goはもう衰退傾向に入った

777 ：デフォルトの名無しさん：2024/04/28(日) 10:43:50.01 ID:ebtFAx8m.net

>>775
Javaが大規模開発に向いてるのは「文化」であって、「言語機能」ではないだろ
Goで技術的に出来ない事はない。ただしやる意味もないが
Goが糞なのは「全部書け」という言語ポリシーだが、これはJavaも同じだし

>>774
Javaの代わりにGo使うメリットってポインタが使える事くらいか？
ならJavaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、
> javaの後継になるか
これ自体が間違いだな

ただまあ、GC付きCの需要は以前からあったし、この分野ではそこそこ生き残り続けるのでは？

778 ：デフォルトの名無しさん：2024/04/28(日) 10:57:35.16 ID:vYBqVrR0.net

javaの代わりにGo使うメリットってネイティブコード吐き出すことだと思うけど
処理速度が早くなればそれだけマシンのリソースが少なくて済む

779 ：デフォルトの名無しさん：2024/04/28(日) 11:46:19.27 ID:ebtFAx8m.net

>>778
ああその点は完全に失念してた。
ただなんつーか、今時鯖代より人件費の方が高いので、Web鯖なんて物理で殴る方が安いというソリューションになってしまってる。
Javaも同様の状況だと思う。
Webに比べて製品寿命は長いので、状況異なるかもしれんが。

処理速度が絶対的に必要なのは物理で殴って逃げられないケースで、
これは例えばディスコードやFPS等のゲーム、つまりユーザー間でのデータのやりとりが大量にある状況で収容数を増やしたい場合で、
現在はRust/C++ということになっている。この分野でJavaを選択する奴は居ない。

Javaが使われてるのは大概インフラ、つまり銀行の送金システムや自治体の戸籍管理等だが、
負荷がかかって物理で殴って逃げられないのはDBであってJava記述部分ではないので、
最大でも精々2倍程度にしか速くならない現状で、Goに書き直す事はない。
それよりも書き直す際のバグを嫌うはず。

つまり、Rustが存在せず、鯖代が今の10倍くらい高ければ、JavaをGoに書き直す需要は発生してたはずだが、そうではなかった、ということ。

780 ：デフォルトの名無しさん：2024/04/28(日) 13:33:28.92 ID:PewOJWl2.net

3行で

781 ：デフォルトの名無しさん：2024/04/28(日) 13:57:24.88 ID:MN1XFv8I.net

> Javaの連中はポインタが使えない(使わなくて済む)からJavaに行ったのだから、

アマチュアさんからはそう見えるんだね
職業マにとって言語なんて案件次第なんよ

782 ：デフォルトの名無しさん：2024/04/28(日) 14:28:40.83 ID:ebtFAx8m.net

>>780
速度面も機能面も、GoはJavaの後継ではない

>>781
ゆとり乙

顧客次第というのなら、現時点でのJava案件は今後ともJava案件だろうよ
顧客は公務員かお堅いところで、「もし何かあったら誰が責任を取る？」しか考えない連中だから
C++しかなかった時代ならともなく、現時点でJavaを「安全」とする技術的意味はないが、
顧客はそれを理解出来ず、また、責任逃れの為に誰も先陣を切らない
ただオラクルが妙な動きを見せ始めてるから、その辺どうなるかだが、それでも公務員連中は金払って終わりだろうよ
所詮は税金であって、自分の金ではないから
そういえば三菱銀行は10-15年前にC++で書きました、Haskell使いました、とかやってたが、続報は聞かないね

783 ：デフォルトの名無しさん：2024/04/28(日) 14:52:46.56 ID:MN1XFv8I.net

素人ならではの発想ほほえましい

784 ：デフォルトの名無しさん：2024/04/28(日) 15:24:23.74 ID:P9GmgsNY.net

しょうもないマウント合戦

785 ：デフォルトの名無しさん：2024/04/28(日) 15:26:16.67 ID:ebtFAx8m.net

>>783
ゆとり引きニート乙


>>774
一応捕捉しておくと、773がGoを「速いJava」と『個人的に』考えたのは間違いではない。
ただし『言語として』なら完全に間違いだ。

Javaはビルジョイが「Cでのバグの大半はポインタがらみで、ポインタ使用ケースの9割がStringだった。
だからStringを言語がサポートすればポインタをなくせると考えたんだ」とリーナスに語ったとおり、
ポインタを無くしてバグを減らす為の言語として作られてる。
そして実際、大受けして天下を取った。(なお「大半」と「9割」は逆だったかも)

ただ、速度チューンにはポインタでの効率化が必須で、この意味でGoは「速いJava」として『個人レベルでは』使える。
ただしJavaにはそもそもポインタがないのだから、
この発想、つまり「ポインタを使えば速くなる」とはJava使いは考えないし、実際、出来ない。
(個人レベルなら出来るのは混ざってるだろうが、Java流の開発方針だとチーム全員が出来ないと意味がなく、機能しない。
そしてポインタにまつわる問題をデタラメに吹聴してる震源はJava使いであって、具体的に言えば「メモリリークガー」だが、
C使いがメモリリークに悩まされる事はない。それはCの使い方を知らない馬鹿がデタラメやってて勝手にバグってるだけ。
この意味で ID:vlvoJs2w は正しい事を言ってる。なお俺は ID:Chhm4gg1)

786 ：デフォルトの名無しさん：2024/04/28(日) 15:55:49.27 ID:SU2rs0/X.net

そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによってセキュリティホールが生み出し続けられている
結局C/C++を使用禁止にするしか解決策はない
アメリカでは政府レベルで決断して声明を出したので日本も後を追うだろう

「ソフトウェアはメモリ安全でなければならない」との声明を発表、米ホワイトハウス：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html

787 ：デフォルトの名無しさん：2024/04/28(日) 18:01:20.89 ID:cGfg508i.net

AIによるコンパイラによってC/C++は復活する、コンパイル時にメモリ安全がAIによって保障されるのだ
さらにAIコンパイラがはくエラー＆提案によって誰もがC/C++マスターとなる
つまりRustの人間にメモリ安全を強制する構文ルールは瞬く間に錆ついてしまうのさｗ

もちろんAIの恩恵はガベージコレクションにも及びGo、Pythonなどの実行速度も劇的に上がる
つまりRustはすぐに錆びついてしまうのさｗ　AIという母なる海によってね

788 ：デフォルトの名無しさん：2024/04/28(日) 18:22:25.79 ID:OBzO61ZB.net

めちゃくちゃ頭の悪い妄想だな

789 ：デフォルトの名無しさん：2024/04/28(日) 18:41:43.21 ID:ebtFAx8m.net

>>786
そう思う人がC/C++を使わなければ済むだけ。

> そのようにC/C++を自分は使いこなせると思い込んでいる多くの人たちによって
なお、これはただのコンプレックスで、
ポインタの概念を理解すら出来ない馬鹿はお引き取り下さいではあるが、
ポインタを理解できたがリークするのは、やり方を知らないだけ。
(そしてここはGoスレであり原則後者だから、前者は死ねでいい)

ただ問題は、Javaの連中が「メモリリークガー」とデタラメに吹聴してるのに騙され、
文法にて縛ってしまうRustに逃げてしまってる事。まあ初心者は文法しか見えないから致し方ないが、
実は定番の手法があり、踏襲すれば絶対にリークしないだけ。
賢いからリークしないわけではなく、知ってるか知らないか、守るか守らないか、でしかない。
そしてRustは実際はC->C++->Rustと来ないと意味もメリットも理解出来ず、
「RustのおかげでCを入門する奴が増え、現在RustよりCの入門者の方が多いじゃねえか！」とか2019頃に言われてた気が。
RustはCを駆逐したいようだが、間抜けな話だ。

そして、Javaが「安全」とされていたのは、
・ポインタにまつわる問題が無い
・配列の境界チェックあり　(←これGoはどうだったっけ？忘れた)
・GCありなのでリークしない
・サンドボックス
だと思ったから、技術的に見れば確かにGoはJava＋ポインタ＝高速版Javaとしての側面はあるのだろうよ。
ただ、マーケティング的に(781)、また技術者リソース的に(784)、当面は無いが。

この意味では俺はRustの方が詰んでると思うよ。AIで出来るとは思って無いが、(>>787)
・動的な境界チェックをやってる限り、Cの速度に勝てない
・静的な境界チェックが出来るようになれば、C++にも導入されるだけ
で、出口が無い。
そして意味もなくマウントを取って来た780が言う様に、現在のJavaプログラマはポインタを扱えるのなら、
Java->Goへの大移動は起きるのかもしれんよ。この意味ではRustよりGoの方がワンチャンある。
(けどまあ、普段やってないことがいきなり出来るわけも無く、ゆとり引きニートの言い分なんてお察し、だが)

790 ：デフォルトの名無しさん：2024/04/28(日) 20:18:11.49 ID:MN1XFv8I.net

童貞が女の口説き方教えてくれてるような長文

791 ：デフォルトの名無しさん：2024/04/28(日) 21:47:54.49 ID:J0uaAvkZ.net

例え方がキモすぎる

792 ：デフォルトの名無しさん：2024/04/28(日) 23:14:08.57 ID:/3v3RYNX.net

そんな心配しなくてもAIが進化すればGOもC/C++もRustもなくなって別の高級言語が生まれるよ、もう会話してればプログラムができちゃうような感じになる

793 ：デフォルトの名無しさん：2024/04/28(日) 23:51:58.46 ID:CS4j+YiY.net

>>789
配列の境界チェックは任意に与えられたインデックス値に対してはC言語であろうとなかろうと境界チェック必須
一方で配列の内部であると確認されているなら不要(にすることができる)

例えば配列の内部であると確認されているならその配列内部へのポインタとして持ってしまえば
読み書きアクセスのたびに境界チェックは不要となる

よく使われる配列の全体もしくは一部分の範囲を順にシーケンシャルアクセスする場合もポインタにすれば境界チェックを不要にできる
なぜならその範囲の終端条件に達するまでは内部であると確認されてるため個別の境界チェックは不要

RustがC/C++と同じ速さで動くのもこの原理のため

794 ：デフォルトの名無しさん：2024/04/29(月) 00:43:52.99 ID:Cj8RVhlf.net

>>793
言ってる事は知ってるが、そうではなく、

> 任意に与えられたインデックス値に対して
の時に実際どうしてるか聞いてる。

C言語の場合は、境界チェックして無い。
Rustの場合はするらしい。だからこの部分でどうしてもCより遅くなる。
Javaは勿論やってる。だから馬鹿が書いて添字範囲をオーバーしたら、例外が返されたはず。
Goはどうだったっけ？という事。

で、Javaが792の手法でゴリゴリに高速化し、C比3倍遅かったのが1.8倍程度まで盛り返したのも知ってる。
そしてC#の方はJavaが6,7で留まってた際にも言語自体が進化してたので、高速化がまだJava程には至ってない。

あと、ついでに言うと、（別人かもしれんが)
> セキュリティホールが生み出し続けられている
> 結局C/C++を使用禁止にするしか解決策はない
これも間違いで、C/C++の場合は788に書いたとおり、
・（プログラマの技量により)バグを生みやすい
・ベアメタルなので問題があった場合に直撃する
だが、アプリとしてはバグが無い（上記上側がクリアされてる)、という前提なら、RustはC/C++と比べて安全ではなく、同程度でしかない。
セキュリティホールは設計上のバグだから、言語関係なく発生する。
(だからLinuxをRustで書きなおそうという馬鹿は居ないし、居てもポシャる。
そういえば10-15年程前はLinuxをC++で書き直そう、という連中が居たはずだが、消息聞かないところを見ると、完全にポシャったようだし)
ただ、Javaの場合はセキュリティホールを突いてもVMだから、さらにVMのセキュリティホールを突く必要があり、この意味では安全。
Goの場合はランタイムだから、VM程ではないにしても、ベアメタルよりはまし。ランタイムの実装によっては、VMと同等の堅牢さも確保できる。

ただ、言っちゃ悪いが、Rustの連中がやたら布教に熱心なのは、所詮はその程度の言語なんだと思うよ。
JavaScriptなんて悪口しか聞かないが、蔓延る一方だろ。プログラマに支持されてる言語はこうなるという例だよ。
Rustは精々ポリコレがんばってください。俺はRustは死ぬと予想してるし、そう望んでます。

795 ：デフォルトの名無しさん：2024/04/29(月) 01:08:13.38 ID:ZxN+lFnq.net

>>794
配列の境界チェックをしなければどんな言語でも範囲外アクセスで続行となり致命的な穴となります
だからC/C++以外はどんな言語でも境界チェックが行われています
C/C++でも自分で境界チェックを行わなければ致命的な穴となります
したがってそこで速度差は生じません

796 ：デフォルトの名無しさん：2024/04/29(月) 05:43:48.04 ID:OeTjgfob.net

なんかスレが進んどる。半分は読んでない。
けど大規模開発になると些細なパフォーマンスは関係なくなることには同意した。
それを差し引いても自分はGoが好き。

797 ：デフォルトの名無しさん：2024/04/29(月) 08:46:16.16 ID:Cj8RVhlf.net

>>795
Cで境界チェックしてる奴なんて、世界中でも誰もいない。
境界オーバーは純粋にバグであり、プログラマの責任でデバッグしておけ、というのがCの文化。
そしてずっとそうやって来てる。

だから動的に境界チェックをしてる限り、RustはCよりも原理的に遅く、実際そう。
この意味ではRustは補助輪付きCであり、補助輪の分だけ遅い。
Rust＝馬鹿向けC、といえば分かりやすいか。
そして、C/C++でなんら問題なかった連中からすると、
Rust？記述がウザくなるがリークがなくなって境界チェックしてくれる？
いやリークなんて元々しないし、デバッグもちゃんとやってるから間に合ってるよ、であり、
何もメリットが無いからRustなんて使わない。

798 ：デフォルトの名無しさん：2024/04/29(月) 08:47:08.70 ID:Cj8RVhlf.net

とはいえ数は力である。
Cの場合は「リークや境界オーバーするような馬鹿がコード書くな」であり、
コードを募る場合は中～上級者だけに対象を絞る大前提だが、

799 ：デフォルトの名無しさん：2024/04/29(月) 08:47:32.78 ID:Cj8RVhlf.net

Rustの場合は「文法に従ってさえすればリークは防げます、境界オーバーは動的チェックしてます」らしいので、
大多数の馬鹿からもコードを募れる。これが今の時代には向いているのも確か。

ただ、馬鹿向けCなら、Goの方が上だと思うよ。境界チェックしてたかは忘れたけど。

800 ：デフォルトの名無しさん：2024/04/29(月) 09:45:04.56 ID:yABvkw5a.net

>>799
Goももちろん正しく配列境界チェックをしていてindex out of rangeのランタイムエラーが出るよ
Cだけが基本的なこともできない古い失格言語で範囲外をアクセスしてしまう

801 ：デフォルトの名無しさん：2024/04/29(月) 11:03:19.56 ID:Cj8RVhlf.net

>>800
なら馬鹿向けCはやはりGoで決まりだな。

そして、「僕は馬鹿だから補助輪ください」か、
「俺はちゃんとデバッグするから補助輪なんてイラネエ、100%の速さをくれ」か選べる。
それでいいのでは。
(というかこの辺グダってるのはRustだけで、Go使う連中は最初から100%の速度なんて求めてない。
Rustが原理的にCより遅いのは回避しようも無い事実なのに、嘘ぶいてるからおかしなことになる。
そしてこの手のことを「選択肢を絞り、政治的に解決する」のがパヨクの常套手段で、典型的には>>786
パヨってるRustは当然嫌われてるだけ)


ただまあ、もう一度整理すると、Goは
・ポインタにまつわる問題はそれなりに対策されてる
・配列の境界チェックあり
・GCあり
・ランタイム
だから、経緯とか界隈の文化とか技術者の状況を無視して、単に純粋に言語の技術的側面だけを見ると、Goは
> javaの後継 (>>774)
は言えてるのかもしれんね。
そういえばJavaは「元祖馬鹿向けC」、Goは「２代目馬鹿向けC」と言われてたし、自然な発想なのかも。
ただ「安全」に関しては、一度保険をかけたら二度と戻れないものだから、Javaの連中がGoを「安全」と見なす事はなかなか無いとも思うが。
(ランタイムエラーを吐いてくれる環境で動いているソフトは、
ランタイムエラーで誤魔化せてるから動いているのか、
そもそもバグが無いからランタイムエラーは絶対にないのか、区別付かない。
だから、ランタイムエラーがある環境でどれだけ動かした実績があっても、『保険』をはずしてベアメタルに持って行くことは出来ない)

802 ：デフォルトの名無しさん：2024/04/29(月) 11:07:50.34 ID:2zp3j2iQ.net

Cと違ってGoは賢い

str := "01234"
a := []byte(str)

fmt.Println(a[3]) // → 51 (3のascii code)
fmt.Println(a[3:5]) // → [51 52] (3と4のascii code)
fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
fmt.Println(a[3:9]) // → panic: runtime error: slice bounds out of range [:9] with capacity 8

803 ：デフォルトの名無しさん：2024/04/29(月) 11:37:52.73 ID:Cj8RVhlf.net

>>802
> fmt.Println(a[3:7]) // → [51 52 0 0] (範囲外の値は0になる)
これはランタイムエラーのほうがいいのでは？

804 ：デフォルトの名無しさん：2024/04/29(月) 12:54:08.59 ID:DB9NwYGr.net

キータにでも行ってくれ

805 ：デフォルトの名無しさん：2024/04/30(火) 23:59:10.31 ID:QUZ1c+LP.net

>>803
なぜ？

806 ：デフォルトの名無しさん：2024/05/01(水) 08:22:11.43 ID:0mD/sHeG.net

>>805
動作の一貫性が無いから。
或いは

fmt.Println(a[3:9])　を [51 52 0 0 0 0 ] (範囲外の値は0になる)

でもいいが、べき論ならランタイムエラーに揃えるべき。
境界オーバーはプログラマ起因の単なるバグであり、修正することを期待されるので。

ランタイムエラーは本来
・メモリ不足
・DB開こうと思ったが応答が無い、或いは何らかの理由でDBに書き込みが出来ない
・ユーザー文字列をevalしようとしたが、エラーになる
等の、『プログラマのミスではない』問題に遭遇する可能性がある局面でtry-catchするものであって、
プログラマ起因のバグがあってもそれなりに動かす為の仕組みではない。

けどまあ、実際はお前のように後者だと勘違いしてる奴が多いのも事実。
だからJavaは基本的に低品質、というかCでは許されない品質のコードが大量に混入することになる。
これをもって「安全」とするのは本来は間違ってる。
(低品質のコードでもそれなりに動かせる環境自体は研究する価値があるのも事実だが、これは本来は明確に別件としてやるべき。
なおGoの場合はpanicから復旧する手段はなかったような気がするので、この点は多少ましかも)

807 ：デフォルトの名無しさん：2024/05/07(火) 01:44:11.10 ID:YTph46y4.net

んで、けっきょく今時点だとGoとRustはどっちがええねん
どうせ「用途による」とか玉虫色の回答しか言えないやろ

808 ：デフォルトの名無しさん：2024/05/07(火) 04:24:12.21 ID:Usgj6GuW.net

>>807
人による
君にはGoがお似合い

809 ：デフォルトの名無しさん：2024/05/07(火) 06:37:23.80 ID:uUsSNCvM.net

長文を連投してる人、Goのことを知らなすぎて草

>>794
> Javaは例外が返されたはず。
> Goはどうだったっけ？という事。

>>806
> Goの場合はpanicから復旧する手段はなかったような気がする