Go language part 3

■ このスレッドは過去ログ倉庫に格納されています
2019/10/17(木) 21:38:04.78ID:wMsZ+t6y
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

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

日本語訳
http://golang.jp

※前スレ
Go language part 2
https://mevius.5ch.net/test/read.cgi/tech/1510395926/
2020/04/17(金) 18:19:15.53ID:fJoVda10
Javaはスレッド跨ぐ場合はスレッドごとにコピーした値をキャッシュしたりはしているし
それで起きる問題を回避するための手段も用意されてる

Goがただ面倒くさいゴミ言語って話でJavaを例えに上げるのは理解してなさそうに見えちゃわない？
2020/04/17(金) 18:27:51.48ID:FR4eJIAH
だって Java thread って context switch が遅いんですもの…（仕方ないけど）
2020/04/18(土) 03:21:59.85ID:7LGZx49d
皆んとこインフラでGo使ってないんか？
クラウドならGo一択だと思ってた
2020/04/18(土) 08:06:56.22ID:dJZrVSnf
Go製のキラーアプリであるDocker
それをRustで書き直すって話無かった？もう公開されてる？
厳密なコンテキスト操作がGoでは実装できないからって
それとも自分の勘違い？
2020/04/18(土) 10:25:08.47ID:xaEKv27U
Dockerの記述言語なんて使う分には関係ないからキラーアプリとは違うような。
2020/04/18(土) 17:50:04.38ID:0gvlJnyA
コンプライアンスに即した範囲でできるテレワークって事で
最近「他社ゲームのアーキテクチャを調査」ってタスクをやったんだけど
Golangは無いね。Node.jsばっか
個人的にはgo使いたいから、家にいる期間になんか一個作りたいけどなぁ…。
2020/04/18(土) 18:26:19.74ID:ZX/dL4qt
ゲーム会社でもコンプライアンスの関係でテレワークできない業務なんかあんの？
少なくともゲーム会社よりはお堅い会社に勤めてるけど、全部在宅で何の問題もないな
コードは主にNode.js(オンライン)とPython(バッチ)で、オンラインについてはGoへの書き直しを進めてる
2020/04/18(土) 18:31:11.51ID:0gvlJnyA
>>407
外注だからね
2020/04/18(土) 18:45:55.45ID:zYPZ4Na5
JavaとかScalaで作ってたものをGoに置き換えるみたいな流れは割とある
2020/04/18(土) 19:32:53.45ID:/YIE32O/
windowsとlinuxで動かさなきゃいけないアプリをJavaで書いてて
全く問題なかったんだけど
実質有償化に伴って他の言語で書き直そうかと思ってるけど
Goってwindows上でも安定して動くのかね？
ちなみに24時間稼働しっぱなしのアプリ
2020/04/18(土) 20:00:40.33ID:7LGZx49d
そんな君にはC#おすすめ
2020/04/18(土) 20:18:48.00ID:C8MVcACH
まあC#だろな
2020/04/18(土) 20:31:40.92ID:/YIE32O/
C#ってlinux上ではmonoとか使うわけでしょ？
流石にないわー
2020/04/18(土) 20:33:06.29ID:nL76etRG
>>406
CATSってスマホゲーがサーバーにGoを使ってるらしい
サーバーにちょくちょくアクセスしながら動作してるんだが、めっちゃ速いよ
この辺はスピンアップが爆速な恩恵なのかも
2020/04/18(土) 20:41:10.89ID:uOWDKjxa
>>406
フロントはNodeでバックエンドがGoだと
外からじゃ調べよう無いよね？
2020/04/18(土) 20:51:17.88ID:3iH77Bzz
>>413
ひどい無知
2020/04/18(土) 20:57:00.49ID:C8MVcACH
>>413
何言ってんのこいつ
2020/04/18(土) 21:20:46.34ID:0gvlJnyA
>>414
個人的興味でちょっと見てみるわ

>>415
そういう調査じゃなくて
スライドシェアとかの公開資料のまとめ
正直引き続き契約延長いただいてありがとうございますというレベル
この状況がまだ続くんなら、流石に家でもほんとに作業するように変わるんじゃないかと思うけどね
または切られるかだな…
2020/04/18(土) 21:42:45.13ID:RW5npENu
今からC#勧めるってお前ら悪い奴やな〜
2020/04/18(土) 22:33:18.98ID:7LGZx49d
今のC#知らない人多そう
特定の言語に拘らず積極的に情報収集した方がいいと思うけどね
スレチだからここまで
2020/04/18(土) 23:45:31.62ID:Fpx5gr7r
今のC#センスいい言語になってると思うよ、俺も。
2020/04/19(日) 00:11:47.49ID:gEgC0AtJ
たまには F# のことも思い出してあげて下さい
2020/04/19(日) 19:53:26.80ID:GbCXYg+t
だが断るっ！
2020/04/22(水) 17:15:41.53ID:2MssAlkL
流石にJavaやScalaからGo移行とかになるとあまりの言語機能のゴミっぷりに開発者がキレそう
今までハサミつかって紙きってたのに石器渡されるようもんだわ
2020/04/22(水) 17:57:25.70ID:gFNuxdvi
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
2020/04/22(水) 18:22:16.77ID:LU+JwGqd
この言語はCでサーバを書いているようなニッチな要求の仕事を置き換えるんだろうな

なに？そんな仕事があるわけない？
…去年回って来ちゃってたよ、そんな仕事が
ミリ秒縛り要求で数十の機器の管制をするサーバ
当時はgo知らなかったんでgccで書いた
427デフォルトの名無しさん
垢版 |
2020/04/22(水) 19:29:43.68ID:5I5B70Wh
リアルタイム性重視なら、GCあるGoは向いてないんじゃ
その用途で置き換えるならRustになりそう
2020/04/22(水) 20:01:17.39ID:LU+JwGqd
Goは半日で理解できたがRustは無理だった
2020/04/23(木) 00:05:34.25ID:b8mXccsZ
鯖は比較的余裕有るけど、クライアント側でGCが痛い子になる事はありそう
Rustは半日では無理だなぁ〜、概念は直ぐ理解出来るけど書き方に統一感無さ過ぎてキレそう<'a>&'a *ref
2020/04/23(木) 00:49:14.99ID:3qWTs6XO
Rustは人類には早すぎる
2020/04/23(木) 00:55:50.26ID:1fYIb7dj
禿しく同意
2020/04/23(木) 08:01:42.02ID:6AabYYA1
Rustはバカ速いとか聞くから覚えたいんだけど
学習コストもバカ高いよなぁ
CとかPascalやっててJavaを始めたときの倍くらい大変な感じがする
C#はJavaを丸パクりで基本構文ができてたから、１日
2020/04/23(木) 08:06:05.23ID:AGd9KY8X
そりゃあif文for文みたいなコードだけなら1日だろうよ
2020/04/23(木) 08:41:47.89ID:Q66hfIcW
rust、利便性のためにライフタイムの省略パターンとか作ったんだろうけれど、逆にわかりづらくなってるわ。
2020/04/23(木) 10:29:03.11ID:6AabYYA1
>>433
クラスの定義の書き方とかもだよ
Javaでない言語のクラスの書き方は、クラス定義にはメソッドの宣言を書いて、定義の外で実装するスタイルが主流だった(他の言語には無いとは言わないが非主流)
これはC++とかObjectPASCAL、そしてGoもこちらのスタイルではある

C#では、基本的にデフォルト仮想なJavaメソッドに対して、デフォルトは非仮想って程度の差(充分にでかい差ではある、ちなみにジェネリックはまだない時分)
だから、覚えるというより慣れるのに１日
SalesforceのAPECはまた面白くて構文はC#以上にJavaなのにデフォルト非仮想だったかな
よく似た兄弟すぎて、仕事とプライベートそれぞれ違う言語で書いてると混乱する
2020/04/23(木) 10:36:37.69ID:AGd9KY8X
>>435
完全にコーダーの発想だな
2020/04/23(木) 10:37:35.02ID:6AabYYA1
>>433
ああ、そういえばCとかではエントリがmain関数だったのが、クラスになっているスタイルもJavaで覚えた
そのためC#でもほぼ同じだから、そこで引っ掛かることが無かった
そういう観点であってifとかforなどの構文じゃないよ
2020/04/23(木) 10:39:55.23ID:6AabYYA1
>>436
笑わせるなよ
学習コストの話なんだからコーダー視点に決まってるだろ
2020/04/23(木) 10:55:34.68ID:AGd9KY8X
キチガイに触ってしまったごめんなさい
2020/04/23(木) 10:55:50.60ID:3P7Oolim
JavaとC#では技術スタックが全然違うだろう
サーバーの構築から通信方法からフレームワーク等の選定から何から、
そういう足回りを全部すっ飛ばして全部あらかじめ他人に与えられた環境を使って
「さあ、アプリケーションコードを書いてください」ならそら大差ないだろ
俺は436じゃないが「コーダー」ってそういう意味じゃないかな
2020/04/23(木) 11:30:36.92ID:1fYIb7dj
ハゲしくスレ違い
2020/04/23(木) 14:11:43.18ID:6AabYYA1
出だしが学習コストの話で、人格攻撃やらサーバの構築とか的外れな事を言い出してくるやら
詭弁術だけはお得意なことはよくわかりました
2020/04/25(土) 02:28:33.10ID:wAZrgsxC
ギスギスしててワロ
Goは誰でもある程度のレベルくらいまでなら使いこなせる優しい言語
2020/04/26(日) 19:49:45.56ID:xNjL7Ex+
ものすごく当たり前の落とし穴に落ちた

ファクトリから構造体アドレス返してたのをインタフェース返すように変更したらテストでコケた
キャストチェックのテストだったんだけど、レシーバのシグネチャが同じ別のインタフェースがあって、そいつにキャストできちゃった

インタフェースが同じなら同じものとして使えるってことは、そういう問題を想定しとかないとならなかった
2020/04/28(火) 19:31:28.17ID:Ce9HOSET
大きくなってきたんでパッケージを分割

設定とか全体を管理するAパッケージ
httpのリクエストを管理するBパッケージ
webAPIのロジックを管理するCパッケージ
ロジックのインスタンスは設定で作って、リクエストから呼び出して処理してもらう

さて、ここで落とし穴
Cパッケージから設定を参照するためにAパッケージをインポートすると import cycle not arrowed 発生
AパッケージではCパッケージをインポートして、ロジックのファクトリを呼び出してる

インポートの循環の制約とか、それは厳しすぎやしませんかね
第三の上位パッケージを作ればなんとかなるのかなぁ？
2020/04/28(火) 20:20:55.63ID:iogl+PJs
arrowed ?
447デフォルトの名無しさん
垢版 |
2020/04/28(火) 20:31:42.46ID:ghSBG3zr
>>445
Goに限らずモジュール境界はインタフェースで抽象化するもんじゃ？
そうしないとユニットテストつらい
2020/04/28(火) 20:48:56.59ID:SLRJSTJf
> 設定とか全体を管理するパッケージ
インターフェース云々以前に、そんなふわっとしたモジュール強度の低いパッケージが存在することが問題
設定なら設定で分けろ
設定はデータ構造自体がインターフェイスなんだからカプセル化とか要らん
2020/04/28(火) 20:51:51.61ID:OCson2MM
>>445
AからC呼び出すっておかしいだろ
設計やり直せ
2020/04/28(火) 22:00:57.39ID:Ce9HOSET
>>449
ロジックのインタフェースの実体を得るファクトリ関数なんだがおかしいのか？

でも、そもそもが設定情報のパッケージにシステムを管理するデータの生成を担わせてる設計が原因臭いとはうすうす
やっぱそこを別パッケージに分離して結合を弱めないとだめだな
2020/04/28(火) 22:23:30.36ID:Ce9HOSET
結局、日和ってロジックのインスタンスはCパッケージにシングルトンとして実装してBから呼ぶことでallowedを回避した
根本的な解決ではないが、動けばいい！(うわっ自分で言ってて恥ずかしい
2020/05/01(金) 06:16:44.51ID:txiwXjh+
VScodeなのかdelveなのか、デバッガでスライスを見たとき64個までしか見えません
どこの設定を弄れば最後まで見せてもらえるのか、調べてみたけれど分かりません
→ githubのgo-delveとかvscode-goとか
このカスタマイズについて情報があれば教えてください
453デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:36:26.80ID:txiwXjh+
各プラットフォームのランタイムのせいだろうとは思うけど・・・
io パッケージの
func Copy(dst Writer, src Reader) (written int64, err error)
と
type Writer interface {
Write(p []byte) (n int, err error)
}
で戻り値に一貫性がない事に気づいて、ちょっとイラっときた

(io.Writer).Write() では n の合計が len(p) になるまで繰り返さないとダメ？
かと思ったけど、
Write must return a non-nil error if it returns n < len(p).
って書いてあるよ・・・
454デフォルトの名無しさん
垢版 |
2020/05/01(金) 11:43:36.06ID:txiwXjh+
ああっ
The built-in functions len and cap take arguments of various types and return a result of type int.
だからなのか

いいのかそんな仕様で
2020/05/01(金) 12:06:06.92ID:Ia4c8IgS
Goではintのサイズと配列の最大長は環境依存だからそれで正しい
そして、CopyはWriteを一発呼ぶだけじゃなくて指定された長さをコピーし終えるまで読み書きを繰り返すように実装するもの
だから配列の最大長とか無関係
やってることが全然違うんだから一貫性もクソもない
2020/05/01(金) 12:20:25.30ID:OD5xAYpx
Rob Pike interview: “Go has become the language of cloud infrastructure”
https://evrone.com/rob-pike-interview
2020/05/01(金) 13:10:50.80ID:txiwXjh+
>指定された長さ
ダウト
Copy見てきてください

こいつはReaderからバイトストリーム(厳密には意訳)をEOFに達するまでWriterに書き込み、その書き込みバイト数を返します
サイズなんて指定しません

Writerに書き出すソースが固定のスライスではないだけで、Writerに書き出すという目的から見ればWriteと同じでしょ
まあ違うとあえて言うなら、私とあなたは考え方が違うんでしょうね (私は「何をするか」という目的で言ったので)
2020/05/01(金) 23:48:52.57ID:txiwXjh+
log.Logger の出力でファイル名も出させるようにして気づいたけど、ソースファイルのパスって実行ファイルの中にしっかりと記録されてる？

Loggerでファイル名を指定すると内部でruntime.Caller呼んでスタック情報拾うんだけど
ログにはソースファイルの完全パスがしっかりと出てくる
実行ファイルを別ディレクトリはにコピーして実行しても出るから、実行ファイルの置き場所を利用している訳じゃない
また、runtimeパッケージがソースファイル情報をもってる訳もないからリンカが埋め込んでるんだろうと推測
runtimeパッケージを使う使わないで、リンカが埋め込む埋め込まないを切り替えるなんて器用な真似はさせていないだろうし
だとすると、ソースファイルの情報って全て記録されているはず(stringsで実行ファイルの中を見た訳じゃないけど)
という推測

完全パスで困るのはユーザ名がしっかり出ちゃうことなんだよな
それが嫌ならユーザディレクトリで開発するなという事なのか
459デフォルトの名無しさん
垢版 |
2020/05/02(土) 08:59:25.19ID:+Au1iQ6P
みんなはGW中は嫁さんとセックスしまくりなの？
独身の俺からすると羨ましいんだけど
2020/05/02(土) 13:46:40.57ID:iDDOId/p
嫁さんとセクロスなんて1年で飽きるぞ
461デフォルトの名無しさん
垢版 |
2020/05/02(土) 14:11:11.13ID:H63qqmuN
セクロスはセフレとしかしないな
2020/05/02(土) 14:12:11.64ID:1t1QmWMu
疲れるだけだぞ
2020/05/02(土) 14:21:57.66ID:z5TAOMiI
飽きるか？全然飽きないんだが。
嫁ともっとセクロスしたいわ。
2020/05/02(土) 14:26:10.42ID:jSLKT64y
　　　　　　　　∧∧　　ミ　＿　ドスッ
　　　　　　　 (　 　,,)┌─┴┴─┐
　　　　　　　/　　　つ.　 終　 了 │
　　　　　〜′　/´　└─┬┬─┘
　　　　　　∪ ∪　　　 　 ││　_ε３
　　　　　　　　　　　　　　 ゛゛'゛'゛
2020/05/02(土) 16:06:20.88ID:3+K3/vn9
GoのスレなんだからせめてGopherくんで抜けるかどうかの議論しろよ
2020/05/02(土) 16:30:21.85ID:1t1QmWMu
gopherくんみたいな女いるよな
目がでかくて歯並び悪いやつ　

抜ける
2020/05/02(土) 17:53:36.77ID:+BhrZUVp
常駐しつつ標準入力からのコマンドを受け付ける構成のプログラム書いてる
だけど、デバッグターミナルからの標準入力はサポートされないんだな(vscode-go/
issues/219)
VScodeの問題かと探したのにdelveの問題？
2020/05/02(土) 17:56:31.80ID:+BhrZUVp
ちなみにシグナル使えという話は横に置いといてね
os.Interruptとかのハンドリングはもう入ってる
Windowsでkillしても受け取らないんだこれが
2020/05/08(金) 09:06:51.86ID:+d3XVyIT
「プログラミング言語Go完全入門」の期間限定公開のお知らせ
https://tech.mercari.com/entry/2020/03/17/120137

PDF版もあるよ
2020/05/08(金) 09:16:00.33ID:le9A8gSm
どうでもいい内容なんだよなーそれ
2020/05/08(金) 09:28:21.26ID:/imhMepR
ところどころ抜けてて口頭説明前提の作りで肝心な内容が無い資料公開されてもな
472デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:47:37.47ID:oIDbptWL
>>469
ʕ ◔ϖ◔ʔ
ありがたや

人
473デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:48:51.29ID:oIDbptWL
https://qiita.com/mattn/items/b7889e3c036b408ae8bd
474デフォルトの名無しさん
垢版 |
2020/05/08(金) 09:50:21.63ID:oIDbptWL
https://write.kogus.org/articles/S78LHt
2020/05/08(金) 16:04:03.09ID:SpWQlQbz
言語仕様より標準ライブラリのクックブック的な本が充実して欲しいかな
結局Goのソースやテストコード読まなきゃ使い方がわからないのが多過ぎるし
2020/05/08(金) 18:12:47.83ID:QcJ6udj9
>>475
みんなのGoは、flagパッケージとかの使用例が役に立った
よく言われるように初心者向けではないだろうなとも思った
2020/05/08(金) 22:59:05.96ID:tAyMPd7a
Golang逆引きレシピ（version1.14対応）

って本出してくれ
kindleで5000円までなら買う
2020/05/09(土) 18:13:17.56ID:m4Vh3zrv
2.0はいつリリースされますのん？
2020/05/09(土) 18:28:27.39ID:4jg1EkWA
予定は未定
2020/05/09(土) 19:27:11.31ID:CUL9xwyE
開発陣のモチベーションはどうなんだろう。
なんかrubyと同じような臭いが。
2020/05/10(日) 09:38:46.23ID:XQ0sO87J
サーバで使われることが割と一般的なコンパイル言語（Java以外）って
Go以外になんかあったっけ
482デフォルトの名無しさん
垢版 |
2020/05/10(日) 11:01:30.61ID:hDQHcieg
apache は何でコンパイルされてる？
2020/05/10(日) 11:02:41.97ID:ot41mX7+
C#
海外を含めるならWin鯖除外でも今やGoよりは多いんじゃないか
2020/05/10(日) 11:59:28.84ID:XQ0sO87J
>>482
訂正、サーバでバックエンドとして
C#かー
2020/05/10(日) 13:04:42.48ID:+Vdduh76
C++
2020/05/10(日) 14:28:40.79ID:p9tAaMVr
Javaじゃね？って言葉を無視するのであれば、Scalaは聞いたことある。
487デフォルトの名無しさん
垢版 |
2020/05/10(日) 15:35:37.07ID:FhPtT+Xo
コンパイル言語で伸びそうなのはKotlin
2020/05/10(日) 18:14:39.27ID:onDYsAIY
javaがinnullable化すればいいんだ
いつ達成されるのか
2020/05/10(日) 18:21:05.86ID:BbBbqgLD
凄いスレ違い
2020/05/13(水) 07:56:28.24ID:p0Yu02SZ
Goは学習コストが少ないっていう嘘に騙されてるやつとそう信じてる信者が多いのが最大の失敗
コード読むだけじゃ見落とすような罠が簡単につくれるし直感的に分かりづらい仕様と機能不足が多すぎる
書き捨てるだけなら簡単だがチーム開発で採用するには残念すぎる言語
2020/05/13(水) 08:32:08.19ID:Q3kP6cCa
　 /＼＿＿_／＼
／　／　　 　ヽ ::: ＼
|　（●）,　、（●）、　| 　　 ／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ 　 .:::::| 　　 ＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼
2020/05/13(水) 08:34:54.68ID:+HM7ZWjz
見えない罠が多すぎる言語よりは数段マシなんだよな
2020/05/14(木) 17:27:46.77ID:ljUxN++I
>>447
ものすごく遅い話なんだけど
そっかー、インタフェース定義とファクトリの実装が同じパッケージにある必然性って全くなかったんだな
io.Reader の実装が到るところにあるように、定義と実装を分離させれば済む話だった

あーでもない、こーでもない
いつの間にかそうリファクタリングしていて、アレ？となった
2020/05/15(金) 00:10:35.84ID:WhbhAQET
>>490
他と比べたら、って話でしょ
2020/05/15(金) 01:28:18.31ID:kU/eypzI
>>493
ていうかinterfaceを返すファクトリというもの自体があまりGo的ではない
その辺は思想がJavaなんかと大きく違うところで、Goでは戻り値には具象型を使うのが基本
interfaceは関数の引数に使うもんで、その関数を使う側のパッケージが必要に応じてinterfaceを実装するんだよ
それに従えば結果的にファクトリとinterface定義は別パッケージになる
2020/05/15(金) 05:05:48.78ID:02fpr2+t
>>495
あ、脊椎で反射的に反論しそうになったけど指摘されてみると全くその通りだね
ファクトリからインタフェースを返すのは悪手だわこれ
2020/05/16(土) 11:46:57.57ID:e+rgeli+
1.12 の http/request.go に、でっかい落とし穴が

こいつは、1210 行目で ContextType == "multipart/form-data" の処理が未実装

そして、 Chrome は FormData オブジェクトを XMLHttpRequest で send() すると問題のマルチパートで送りつける

よって、FormData は使えない……

他のブラウザだとどうなんだろ？困るな
2020/05/16(土) 12:28:15.83ID:bJ5k+aLx
xmlHttpRequest.setRequestHeader( 'Content-Type', 'application/x-www-form-urlencoded' );

じゃダメなん？
2020/05/16(土) 12:29:08.12ID:e+rgeli+
うーん、コード追ってみたら未実装は間違いでParseMultipartFormを使うらしいけど、わけわかんない
単純にParseFormを置き換えたら、エラーかえしやんの
2020/05/16(土) 12:30:20.91ID:e+rgeli+
>>498
いや、ブラウザ側の話じゃないから
ブラウザがどんな方法で送ってきても受けられなきゃ駄目でしょ
2020/05/16(土) 12:34:33.17ID:e+rgeli+
普通、ParseForm が判定して取り込むよね
なんで分離してんの？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況