Go language part 5

**デフォルトの名無しさん** · 2022/02/27(日) 07:43:20.04

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/

**デフォルトの名無しさん** · 2022/09/05(月) 23:56:02.82

どういうことですよ？

**デフォルトの名無しさん** · 2022/09/06(火) 00:05:01.14

静的なファイルを送るだけなら。

カーネルの送信バッファが空くのを待つ
↓
送信バッファと同容量だけ非同期にファイルの読み込みを開始する
↓
ファイルデータが読み込まれると、送信を開始する
↓
最初に戻る

この手順で、典型的なTCP通信なら20KB以下のメモリーで足りる。
でも、動的なコンテンツ生成では、そうはいかないのでは?

**デフォルトの名無しさん** · 2022/09/06(火) 00:56:32.90

ヒント:httpは同期通信

**デフォルトの名無しさん** · 2022/09/06(火) 01:32:17.99

>>563 のここがよく分からない

> まともにマルチコアのCPUの性能を引き出せるのはSIMD命令を使った計算のみ

SIMD命令付きのシングルコアCPUもあったじゃん。
古いけど MMX Pentium とか Pentium III とか。
この時代はSIMD命令は何を引き出してたの？

**デフォルトの名無しさん** · 2022/09/06(火) 02:05:21.99

>>566
1なんか一つのgoroutineに上から並べるだけで良いじゃん。

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

えっ？もしかしてこの人
>>574
でもまだ理解してないの？

**デフォルトの名無しさん** · 2022/09/06(火) 03:40:36.05

>>587
httpを同期で実装するなんて昔のダメなシステムと完全ブロックしても困らない末端クライアントだけたぞ
httpクライアントとして動作する時もサーバーで使うなら同期ブロックしてしまうとスレッド資源を無駄に専有
だからhttpを使うなら何らかの非同期にするのが当たり前

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

>>574
多くの言語でasync/awaitキーワードだらけになって反吐が出る気分だわ、これを良いと考えた人たちを殴りたい...
goにpromise/futureなんて絶対不要、こんなの必要だと思ってる人相当アホやぞ

＞「Goは最初から全てがasync汚染されているためasync汚染に気付かずに済む」が正解
なるほど意味わからん
asyncキーワードなんて無いのにスケジューリングで同期実行されるから汚染？ｗｗ新理論ｗ

**デフォルトの名無しさん** · 2022/09/06(火) 08:04:56.91

>>566
1なんてそのまま関数並べるだけだし
2はN件goroutine立ち上げてたらN回チャネル待ち受ければいいだけだよね
タイムアウトもselectで容易に実装できる

100%デッドロックするとか言ってるけどそれはGo超初学者が使った時の話かな？
仮にデッドロックしても検知機構働いてちゃんと落ちるし何が言いたいのか

**デフォルトの名無しさん** · 2022/09/06(火) 10:57:52.38

>>588
その時代のことはよく知らないので
気になって調べてみたがwikipediaによると
2クロックで実行するという実装になっていた模様
なのでその時代に関しては128ビット幅のレジスタを使えるというアドバンテージしかなかったとのこと

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

>>591
通信プロトコルとhttpサーバー/クライアントの実装が区別できないおバカさん乙w
そんなんでよくGoなんて使えるな

**デフォルトの名無しさん** · 2022/09/06(火) 14:37:15.63

今回は実装の話だからサーバー上なら今どきは非同期で実装で合ってると思うよ

**デフォルトの名無しさん** · 2022/09/06(火) 16:35:51.33

>>596
文脈読めないおバカさんその2乙w

**デフォルトの名無しさん** · 2022/09/06(火) 16:56:04.53

>>593
その通りだな、安易に実装できるものを標準で欲しがる理論がわからんわ
多くの言語のfutureなんてデータの結果受信同期待ちが起こるだけだし、goのcontext.WithTimeoutは
他の言語では全く実装できていないfutureのプラス機能のようなもので、goはより進んでいると言える
一方promise的なもの、つまり複数のgoroutineを束ねて制御したい人は、欲しい人もいるかもしれないが
goで書いたpipeline処理は手動で書くからこそきめ細かい制御が出来るので、無作為にこれとこれを並列、
これとこれを非同期だけど同期的に実行にしたいとか、効率を考えたらこの流れを組み替えられることには
ほとんど意味もないね。
例えばJSでPromise.allとかすべてを非同期並列に実行して成功の可否で分岐したいなんて、同じ状態が
goroutineとチャネル待ち受けで出来てしまうわけで、それを仰々しいライブラリにする意味が分からん

**デフォルトの名無しさん** · 2022/09/06(火) 17:02:41.68

上では良いことだけ書いたけどif err != nullはもうそろそろダルいので何とか手を打ってほしいわ
副作用のある関数ではgoの第二の戻り値がerrなのは、もはや言語仕様なので別言語でいう
Option/Result/Eitherみたいなものは必要ないにしても、?.のようなNull条件演算、合体演算
のようなErr条件演算が欲しい

**デフォルトの名無しさん** · 2022/09/06(火) 18:25:37.98

きめ細かい制御してるか？
goのモデルは良くも悪くも作った水路に水を流すだけで、実際にその中のどこでどのようにブロッキングが発生するかは気にしないのが正しい使い方
どっちかというとpromise系のほうが制御は明示的だよ

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

きめ細かいGoのpipelineって、もしかしてGoあんまり書けないのでは…？
ランタイムの大勝利な事の方が多いぞ。

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

きめ細かいでしょう？
チャネルが１個なら並列性が1つでブロッキング出来るし、並列性を持たせたいなら複数のチャネル幅を
用意すればいいだけ1段目のパイプライン処理が終わったすぐ後に、次段のパイプライン処理を普通に書く
ことができるし、sync.WaitGroupを使えばパイプライン中の中間データへ同期制御もできる
それ以外にGoで書かれた多くの優れたパイプライン処理は、キャンセルを考慮している。
ブロッキングが発生するかは気にしないなんて事はなく、チャネルのselectでブロッキングが入ることは普通に
当たり前だから気にしないだけ
https://go.dev/blog/pipelines

世にある多くのpromiseはキャンセルやタイムアウトは考慮していない場合が多い、All or Nothingでしかない
大雑把な実行制御でしかない。多くは流れるようなデータの受け渡しもできない。
実行順を決めるだけで、特定の処理に多重度を持たせるとかそんなことは出来ない
これは多くがpromiseというものが非同期処理をベースにした疑似的な実行順制御の仕組みだけであるから

**デフォルトの名無しさん** · 2022/09/07(水) 13:37:16.25

>>599
nullじゃなくてnilな

**デフォルトの名無しさん** · 2022/09/07(水) 16:59:11.50

>>598
そもそも、複数のgoroutineを束ねて使いたいという要請でsync.WaitGroupは作られてるから、自前で作る意義すら無いんだよな
グループを待つ、のだから

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

>>593
だからその程度のことしかしないのにわざわざゴルーチンだのchannelだのselectだのを書かなきゃいけないことがだるいと言う話だよ？
書けるか書けないかで言ったらそりゃ書けるでしょw
あと普通に刺さる可能性が高いと言うことを言ってる

**デフォルトの名無しさん** · 2022/09/08(木) 22:55:49.37

ホントにGo書けないんじゃないの…？

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

意味わかんね

>>566 では promise の利点をこう書いてた

> 1と2についてはpromiseで全て安全に楽に実装できる
> ゴルーチンとchannelを使った実装なんか考えたくもない
> 100%デッドロックが起きる

それに対して >>593 や >>598 が goroutine とチャネルで簡単に実装できるって言ったら >>605

> わざわざゴルーチンだのchannelだのselectだのを書かなきゃいけないことがだるいと言う話だよ？

「だるい」なんて話、一切してなかっただろ。

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

>>607
マジでアスペか？
promiseの方が明らかに楽でバグが生まれない
これはこれまでの議論の流れで一貫してる主張

なんでリクエストのデータ受け取るのにgoルーチンだのchannelだのselectだの書かなきゃならんのだよ

そしてpromiseを実装するのは我々ではなくGoコンパイラの開発者たちだよ

**デフォルトの名無しさん** · 2022/09/09(金) 12:35:07.97

promiseって普通awaitするのが普通だよね？
goもチャネルも使わない状態でhttp.Get呼ぶのと全く同じだよ

goroutineの中で実行すれば勝手に非同期になるしfork joinしたいならチャネルがwaitgroup使うだけの簡単なお仕事

**デフォルトの名無しさん** · 2022/09/09(金) 12:39:54.70

>>608 >>607
まずは「goroutine&channelだと100%デッドロックが発生してpromiseだと発生しない状況」について戦えよ。

だるいとかより興味あるわ。

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

>>608
「promiseの方が明らかに楽でバグが生まれない」
そんな統計は１つもないければ、あなたの貧相な頭の中だけですよね？それを証明しなさいと暗黙的に問われているのがわかりませんか？

「なんでリクエストのデータ受け取るのにgoルーチンだのchannelだのselectだの書かなきゃならんのだよ」
じゃあなんで、promiseなんていう出来の悪い非同期処理のために作り出された愚物を、真にマルチプロセスに対応するgoで
エミュレーションしなきゃならないんですか？あなたのためだけですよね、ほとんど誰も欲しがっていませんけど?
このような需要がない機能を、標準ライブラリに求めるものではありませんし、あなたの隠れた真の心は
「学ぶことをしたくない」だけでしょう、ご自分でも気づいてないと思いますが
C#やScalaあるいはJSしか出来ないなら素直にチームに報告しましょう、あなたのやる気を引き出すためだけに我儘を際限なく
広げても誰も理解してくれませんし、当然、味方にもなってくれないでしょう。だってやる気が無いんですから。
言語の基本的な考えが違うのに、他の言語に似たような雰囲気を求めるのは間違っていますし、なおかつ結局同じコードを
書いてしまうなら乗り換えるような利点をすべて消し去るでしょう

「そしてpromiseを実装するのは我々ではなくGoコンパイラの開発者たちだよ」
実装しないと思いますね、あなたのゆがんだ考えでは超保守的なgoチームを説得するのは無理でしょう。１つも有益な
調査結果なり、推測なりが述べられていません。あなたが「ルーチンだのchannelだのselectだの書かなくちゃならない」と
我儘を言ってるようにしか見えません。仮に万が一億が一、必要だとしてもGithubに個人実装のライブラリとしてあるでしょう

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

まあasync/awaitのほうが初心者に対するハードルは低そうな気はする
初心者が雑にchannel使ってるとたいていバグってるわ

**デフォルトの名無しさん** · 2022/09/09(金) 13:34:32.33

async/await手軽で簡単だけど複雑なことやろうとすると難しい
Goroutineとchannelはasync/awaitと比べると確かにとっつきにくいが複雑のことも組み合わせで上手く実現できる応用力がある

**デフォルトの名無しさん** · 2022/09/09(金) 14:08:59.93

>>611
そういうストローマン論法は俺には通用しないって

**デフォルトの名無しさん** · 2022/09/09(金) 14:53:32.39

promise の利点まとめ

- goroutineとchannelを使うと100%デッドロックが起きるが promise だと安全に実装できるものがあるらしい。具体例は不明。
- >>605 にとってだるくない。

**デフォルトの名無しさん** · 2022/09/09(金) 15:05:25.55

非同期で順列な処理やる場合はasyncのがわかりやすい
並列にタスクいっぱい撒いてなんかやるみたいなのはchannelって印象

**デフォルトの名無しさん** · 2022/09/09(金) 15:59:29.38

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がなぜあるかといえば、同じプロセス空間で疑似的な非同期処理による実行制御を行うため
だけの仕組みです。このため、特定の変数（結果を格納する配列や変数）に同時にアクセスされるという考えは
ありませんし、そのような（ロックや待ち）制御は必要ありません。現実に同時に動いていないのですから

隣国のアジア人コミュニティに「ストローマン論法」という言葉を連呼するキチガイ集団がいましたが、本当のバカだった

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

結局何がChannelに無くて、何がPromiseでしか解決できない問題なの？
Promiseを解決せずに持ち回ること？

**デフォルトの名無しさん** · 2022/09/09(金) 23:05:27.12

>>617
例1がすでに全然シンプルじゃないw
しかもレスポンスを返さない例で意味ないww
それ以外にも落とし穴満載

現実にこんなコード書いてるやつばっかりならバグりまくってヤバそう

**デフォルトの名無しさん** · 2022/09/10(土) 05:44:14.74

やはり頭がバカ以前のGより脳が小さい、上の人はサンプルをシンプルだとは上でも言ってないが
errgroup.Groupがシンプルだと言っているのに、頭ヤバそう
まあサンプルは十分シンプルだが、レスポンスが要らない事など世の中にいっぱいある

現実にこんな奴がいることは、goより複雑な言語特性や膨大な標準ライブラリを持つ言語を
チーム開発で使えるか、大変考慮すべきことだろうな

**デフォルトの名無しさん** · 2022/09/10(土) 06:14:16.74

#Gopherくんの国葬に賛成します

**デフォルトの名無しさん** · 2022/09/10(土) 06:49:15.74

ストローマン

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

まずは基本的に、シングルスレッドの場合とマルチスレッドだが共有データを使用しない場合は原理的に
データ競合や排他制御のバグは発生しない。
>>611が「promiseの方が明らかに楽でバグが生まれない」と言っているのはそのどちらかに帰着するケース。
マルチスレッドでかつ共有データを扱うケースではpromiseを使おうが競合バグは発生し得る。

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

シンプルシンプルw

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

壺買えばシンプルに見えるよ

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

ストローマン連呼する人が最近5chで増えたと思ったけどこの動画が原因なのねん
youtu.be/mK3Tnxh4Kho

**デフォルトの名無しさん** · 2022/09/10(土) 14:08:04.25

そもそもGoは何もしなくてもマルチスレッドなんよ。
IO待ちとかしたら勝手に他の事しよるよ。awaitなんかしなくても。
だからFutureやPromiseで結果が来る事を持って回るんじゃなくて、
そもそも処理するロジック自体を複数起こしちゃうんだよ。。

これだけの事をいつまで言ってんのよ。。
>>617
の例1がどうして一気に複数リクエストを送りたいかと言うと、その三つを同じ一つの処理で使いたいからであって、
三つの同じ処理を起こすんであればWaitする必要も無いのでは？
それこそchanで受け取れば良いんだし。。

**デフォルトの名無しさん** · 2022/09/10(土) 17:44:57.86

JSのPromiseしか知らないんだな
そりゃ話が噛み合うわけがない

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

JS以外のpromiseだとどう違うって？

**デフォルトの名無しさん** · 2022/09/10(土) 21:23:42.19

内容ゼロのワイ賢者や煽りに煽りで返すスタイルｗww

**デフォルトの名無しさん** · 2022/09/11(日) 01:29:37.61

藁人形♫

**デフォルトの名無しさん** · 2022/09/13(火) 07:00:51.39

韓国人の口癖、ストローマン論法という逃亡手段

**デフォルトの名無しさん** · 2022/09/13(火) 18:17:36.41

ストローマンって本題から離れた部分を、わざと誤解して上げつらう詭弁の手法だから、自己紹介してるんだよ

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

うぬぬぬぬ、issueに送るべきだろうか？

１、「ポインタの」レシーバーでストリンガーを記述すると、fmt.Println()とかに渡してもString()メソッドは呼んでくれない…

２、そして(str{v: 1}).String()とか記述するとコンパイルエラーになる…

変数に一旦格納してからのs.String()は、仕様から(&s).String()と解釈してくれて通る

**デフォルトの名無しさん** · 2022/09/14(水) 11:17:52.77

>>634
あ、１は実体を渡すと

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

>>634
コードサンプル

https://go.dev/play/p/cnLcXtFFQ4j

**デフォルトの名無しさん** · 2022/09/14(水) 11:33:39.56

>>634
この辺(レシーバー)の仕様って、訳してみると何かガバッてるように思えてならないんだよなぁ

**デフォルトの名無しさん** · 2022/09/14(水) 11:40:44.99

>>634
実体のレシーバーはレシーバー内のフィールドを更新しても反映されないから、レシーバーはポインターとして書くのが定石だけど
ストリンガーだけ実体のレシーバーとして書けば回避できる
回避できるなら放置でもいーじゃん？とか言われると反論しづらい

**デフォルトの名無しさん** · 2022/09/14(水) 15:53:22.22

>>638
ポインタのレシーバーを記述していると、インタフェース型変数には実体は代入できずポインタでなければならない
という制限もイミフ
代入可能性の仕様は単に、xがインタフェースTを実装していること
実体でもメソッドセットx.String()とx.Str()は呼び出せるのだから実装されている、とは「ならない」事から上記の制限がイミフと言ってる

本当に仕様が厳密じゃなくてガバガバ
大真面目に仕様書を読み込んでる俺の純情を返せ

**デフォルトの名無しさん** · 2022/09/14(水) 16:03:17.92

>>639
セレクタ式で実体からポインタレシーバーを呼び出すと&xと解釈されるという仕様が、インタフェースの代入可能性には波及していない、という点でコンパイラのバグと難癖つけられるんじゃないか？
とissueに書いてもいいんじゃないか？という多分にメンドクサイ系おじさんの怒り

仕様書にどう書かれていようが、インタフェースに実体を入れようとするな！で済む話ではあるかも

最終的には「仕様書は信用するな」に帰着

**デフォルトの名無しさん** · 2022/09/14(水) 17:25:20.47

インターフェース型変数という訳のわからないものを導入したのがそもそもの間違いなんだよな

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

で、なんでそんなもんを導入したかというとそもそもジェネリックスがなかったから
「ジェネリクスがなくてもプログラムは書ける(キリッ」みたいなイキりにこだわって結局かえって醜いことになるっていうまるでド素人みたいな失敗

**デフォルトの名無しさん** · 2022/09/14(水) 20:52:01.05

一人で喋ってる怖い

**デフォルトの名無しさん** · 2022/09/15(木) 09:41:05.37

理解できないから人格攻撃に出るあたり、お里(国)が知れるというもの

**デフォルトの名無しさん** · 2022/09/15(木) 10:04:39.44

いきなり国がどうとか言い出す人って日常会話出来るのか気になる

**デフォルトの名無しさん** · 2022/09/15(木) 22:29:29.36

インタフェース変数は普通に色々な言語にあるだろ？
そこにケチをつけるのは筋が悪すぎるのではないか？

**デフォルトの名無しさん** · 2022/09/16(金) 15:06:43.28

ないわw
空インターフェースとか訳がわからんわ

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

>>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メンテナーに絶対相手にされないよ

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

>>648
ちゃんとコードを読みなよ
elemはポインタレシーバーで実装、elem2は実体レシーバーで実装
そしてポインタレシーバーでストリンガーを書くと、fmtパッケージとかでは認識されないケースがあるってサンプルコードよこれ

つまりあなたの主張する func (e *elem)String() string という「普通の定義」では動かないケースを示している
実行してみ？俺も「普通の定義」だと思っていたからこそのレスなんだから

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

func (e *elem) String() string
と書くとストリンガーとして認識してくれないと説明して
サンプルコードまで載せて確認を求めてるのに
実行すらしてもらえないとは

**デフォルトの名無しさん** · 2022/09/16(金) 17:11:32.64

仕様書にポインタ変数.は勝手に*(ポインタ変数).

に変換されるとか書いてあるけどインターフェースでも行われるってのはどこに書いてあるの？

**デフォルトの名無しさん** · 2022/09/17(土) 02:32:12.33

>>651
ない
むしろ、インタフェースを実装しているという定義が、全てのメソッドセットを満足している、という程度しか書かれていない

あれ？仕様書だと逆に値は (&x).xxxx に変換されるとしか書かれてなくなかったか？後で確認してみる

**デフォルトの名無しさん** · 2022/09/17(土) 02:40:37.19

ポインタと値レシーバーは特に注意しなくても相互にセレクタとして呼べるんで気にしていなかったんだけど、ポインタでストリンガーを書いたらfmtパッケージの関数では認識してくれなかった
んで、これは不味いと総当たりで確認してみた

しかし、単に自分の勘違いかなと確認コードを公開してみて、レビューを求めている←イマココ

**デフォルトの名無しさん** · 2022/09/17(土) 02:47:40.39

まだfmtパッケージの中は見ていないけど、ポインタレシーバーで書くと型スイッチかリフレクションではインタフェースを満たしていないと見なされたりするんじゃないか？とか不安になってきた

上でも書いたけどfunc (e *elem)String()は自分も「普通の」書き方だと思ってたんで

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

な、仕様なんてこいつ読んでないだろ？5chぐらいでしか自分の連投でしか意見言えない
issueとかこいつは言ってみただけでそれすら出来ない

**デフォルトの名無しさん** · 2022/09/18(日) 09:58:37.38

>>655
そいつ次世代言語スレで機能精神崩壊してたんだぜ

自分のRustの実力(知ったか)で仕事にありつくのが難しいと観念してこれからはGoに粘着するよ

ここが新しい隔離スレよろしく頼む

**デフォルトの名無しさん** · 2022/09/18(日) 10:43:21.71

理解できない

・ポインタでストリンガーを書いてしまうと動かないケースがある
・実例をプレイグラウンドで上げたから間違っていたなら指摘してくれ

に対しての回答になってない
これこそ関係のない些事を上げ連ねて議論を避けるストローマン話法の典型じゃね？

**デフォルトの名無しさん** · 2022/09/18(日) 11:17:33.27

Promise最強ストローマンおじさんw
仕様書なんて読んでないんだろ？そもそも英語読めないから読んでないどころか読めないんでしょ？w

**デフォルトの名無しさん** · 2022/09/18(日) 22:39:49.75

なんか勘違いしてるけど相互運用ではないよ

レシーバが値のメソッドはポインタと値に対して呼び出すことができるが
ポインタのメソッドはポインタに対してのみ呼び出すことができる

これは仕様書に書いてある

**デフォルトの名無しさん** · 2022/09/18(日) 22:48:21.16

>>659
これで全部解決しててワロタ
二度と喚き散らすなよ

**デフォルトの名無しさん** · 2022/09/19(月) 08:13:25.10

>>659
んにゃ
「メソッド呼び出しと同様に、アドレス指定可能な値を用いたポインタレシーバーによる非インタフェースメソッドへの参照は、自動的にその値のアドレスを取りますのでt.Mpは(&t).Mpと等価になります」Method values より
とあるよ

**デフォルトの名無しさん** · 2022/09/19(月) 08:20:33.46

>>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.
のトコね
誤訳してるなら指摘してくれな

**デフォルトの名無しさん** · 2022/09/19(月) 08:24:13.55

まあ、こんな感じにぜーんぶ読み通さないと系統だった仕様の把握ができそうにない、という点で、かなり品質は良くないんよ
これ、どっちが優先されるの？？？という話が多すぎて、実際に試行するとアレ？となる

**デフォルトの名無しさん** · 2022/09/19(月) 08:35:15.69

仕様書の全訳に挑んでオカシイとサンプルコード書いて確認してみてレスしてるのに
仕様書を読んでない奴がそのサンプルコードをRunすらせずに、お前が勘違いしている、とか
へそで茶わかしていいでしょうか？

**デフォルトの名無しさん** · 2022/09/19(月) 08:42:10.25

>>662
いや、それ暗黙的にポインタに変換してるからポインタに対して呼び出してるよね？
理解できてる？

**デフォルトの名無しさん** · 2022/09/19(月) 08:45:47.87

>>664
なんだ英語読むのに苦労してる人か

そういう人が日本語訳に取り組むと迷惑

オカシイところがあると言うなら原文の方にPR出せ

**デフォルトの名無しさん** · 2022/09/19(月) 08:51:12.18

はいサンプルね
interfaceはポインタレシーバーだとポインタ変数しか代入できないのに対して
メソッド呼び出しは全部成功しているよね？

https://go.dev/play/p/X71811pJ1sQ

メソッド呼び出しとインタフェースの仕様を混同しているから話にならない
英語読めない文盲ってことが証明されたな

**デフォルトの名無しさん** · 2022/09/19(月) 13:12:10.62

>>667
わかってないふりしてるけどもう理解できたんだろ？
インターフェースのマッチ時のメソッド呼び出しについては>>659
明示的に呼び出す場合は>>662で変換される
(自分で呼び出すのだから当然インターフェース云々とは無関係)

**デフォルトの名無しさん** · 2022/09/19(月) 14:35:47.93

言語的にケチ付けたいだけでしょ？
http://hissi.org/read.php/tech/20220914/eHBDU0cyOGc.html
http://hissi.org/read.php/tech/20220917/ejYydjU4Rno.html

こんなに一生懸命書く奴がほかに書き込んでない訳ないわ、またいつものRustかC#かアホみたいな他を攻撃する信者のオッサン

**デフォルトの名無しさん** · 2022/09/19(月) 14:40:24.76

でもGoの知識増えたしいいんじゃない？
育成は成功だ

**デフォルトの名無しさん** · 2022/10/14(金) 13:17:00.05

https://twitter.com/anicolaspp/status/1579960864639455232

Googleにやる気がなさすぎる
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2022/10/14(金) 13:31:24.87

Rustでもないのか

**デフォルトの名無しさん** · 2022/10/14(金) 19:27:35.90

Googleのたかが1プロジェクトが C++で始まるからと言ってGoの終わりを感じ始めるなんてどういう審美眼で生きてんだよ。

**デフォルトの名無しさん** · 2022/10/14(金) 19:30:06.02

>>673
そうなんだろうけど、言いっぷりがなんかちょっと引っかからんか
お前やる気ないんか？ってメンションしたいくらいだわしないけど(´・ω・｀)

**デフォルトの名無しさん** · 2022/10/14(金) 20:40:12.25

審美眼w

**デフォルトの名無しさん** · 2022/10/14(金) 21:08:37.72

>>674
普通にリプで使われまくってるって言ってるが

**デフォルトの名無しさん** · 2022/10/15(土) 20:39:15.62

Googleってコーディングに関しては無茶苦茶保守的というか統制的だからな
開発者の好みより合理的判断を優先した結果だろう
そういう文化だからこそGoみたいな極右言語が生まれたとも言えるのだが

**デフォルトの名無しさん** · 2022/10/15(土) 21:16:18.42

数多の捨てられたプロジェクトに比べればGo言語は成功した部類だろうよ。

**デフォルトの名無しさん** · 2022/10/16(日) 20:12:43.19

オッス！オラGo！

**デフォルトの名無しさん** · 2022/10/16(日) 23:36:46.06

オラGolang
いっちょやってみっか

**デフォルトの名無しさん** · 2022/10/19(水) 22:35:19.30

なんでC++なんて使ってるんだよ
新プロジェクトで使う言語じゃねーだろ

**デフォルトの名無しさん** · 2022/10/20(木) 01:44:44.00

Googleは独自のビルドシステムなど過剰に最適化された開発環境を持ってるから、簡単に言語変えられないんだよ

**デフォルトの名無しさん** · 2022/10/20(木) 02:39:12.77

いや、たんに仕事が雑なだけだとおもう
とりあえず新プロジェクトやるぞー！
で？言語は？
C++で。
あれ？ウチの会社なんか新しいのはGOでやるとかいってなかったけ？
そうだっけ？べつにいーじゃん、Goはマスコットきもいし、C++のほうが楽だから俺んとこはこれでヨロシク！
こんな感じだろう

**デフォルトの名無しさん** · 2022/10/20(木) 04:11:13.86

RustじゃなくてC++なのが逆張りっぽくてキモい

**デフォルトの名無しさん** · 2022/10/26(水) 14:45:01.27

Goは低落傾向だよな