【Go言語】 webapp GO Part1 【Golang】 [無断転載禁止]©2ch.net

>>330
そう聞かれるとうまい答えが見つからぶ「オブジェクト指向っぽい設計」というアホな回答になってしまう
そもそもインターフェイスとかいう概念がなかったので使いこなすのが難しい
インターフェイスの何が嬉しいんだみたいな疑問が定期的にわいてくるんだが

動的言語だとダックタイピングだからインターフェースがないってことか。

インタフェースはまんまインターフェースだよ
APIはアプリケーションインターフェースだろ。
つまりオブジェクト間で情報をやり取りするための決まり。

例えばfmt.Fprintfをみてみよう。
https://golang.org/pkg/fmt/#Fprintf
第一引数にはio.Writerを満たすインターフェースならなんでも突っ込める
じゃあio.Writerインターフェースって何か？
これはwriteメソッドを備えたもの

例えばhttpのレスポンスだったり、もちろんファイルだったり
それらはとにかくwriteメソッドを実装しているだけなんだ。
自分で作ったオブジェクトもwiteメソッドさえ備えていれば突っ込める。
便利でしょ？

動的言語の場合だって if (typeof xxx.someMethod === ‘function’) みたいなコードを書いたりしたでしょ？
こういうのを一々入れる必要がなくなる。
なぜならインターフェースの条件を満たさないオブジェクトを突っ込むとコンパイルエラーになるから。

心地の良い設計の基本はすべてを知らなくても実装できること。
例えばfmt.Fprintfの中の実装を知らなくても
Writeメソッドを実装すればfmt.Printfが使えるでしょ。
そういう風に自作のオブジェクトも基本的にインターフェースを仲介して
各オブジェクトの詳細は知らなくても使えるようにする。
つまり疎結合にしてやる。

インタフェースは既存のクラスに手を入れられないのがつらみ
C# みたいな this キーワードいれたりとか Haskell みたいなアドホック多相とかあれば別だけど

俺としてはgoaとか勧める。
あれはwebapiを設計してやるとgoのコードを生成する。
webapiの実装例として参考になるし、そのまま開発してもいいし。

なるほど色々ありがとう
インターフェースの嬉しいところはなんとなく分かった。
ある型にたいして既存の関数やメソッドを使いたい→インターフェースを満たすようにメソッドを定義という感じの思考のプロセスでいいのかな？

>>336
例えばテスト主体で考えてもらえればより便利さがわかると思う。
interfaceを満たすだけのダミーなら簡単に用意できるでしょ。
structを直接引数に取る形にすると本番のstructをテスト書く時に用意しなきゃいけなくなる。
この思考プロセスがやがてDIに結びついていくんだけども。

>>337
この話を聞いた上でちょっと色々コード眺めてみるわ
言わんとすることは分かったのであとは自分で書くときにすんなり使えるか…
とにかく参考になったありがとう

goにおける配列操作で目的の要素を取り出すのっていちいちループを回さないとだめ？

標準ライブラリになんかないかな

メソッドのレシーバにnil pointerを渡して有用な場合ってどういうときなの？
メソッド内でフィールドアクセスする際にpanicになったりして良いことない気がするんだが

>>340
別にnilを渡せるのが有用とかいう話は無くて、単にポインタに対してメソッドを呼び出せるとレシーバーがnilになりうるけどどーすんの？って話でしょ

他言語ではメソッドは呼ばれずにNullPointerException的なのが飛ぶようになってるけど
goの場合はメソッド側でnilに対処すれば呼び出し側はレシーバーがnilかどうかを気にしなくてもいいというメリットはある

>>341
それメリットだとは思えないんだが
nilに対処するコードを毎回書かなきゃならないのもダルいし忘れててもコンパイルできてしまって実行時にpanicするしで嬉しくなくね？

go2でnull安全にならないかな。無理？

gaeのdatastoreを勉強できるいい教材ないかな

appEngine使ってる人いないのん？
go1.8にも対応しつつあるし期待しとるよ

GAE勝手にサービス終了しやがった

スレチかもしれないけどGAEってエロあり?

>>346
してないよ。何の話？

goで配列の定義で

[]*T ってよく見るんですが
[]T でダメなんですかね？ []*Tにするメリットを教えて下さい

https://cloudplatform.googleblog.com/2017/09/introducing-managed-SSL-for-Google-App-Engine.html?m=1
ナニコレ
GAE使えばSSL無料で使えるっていう意味？
これはいいな

＞We’re excited to announce the beta release of managed SSL certificates at no charge for applications built on Google App Engine.

コスト的にかなりいいよな
ついでにドメインも無料化してくれないかな…(チラチラ)
Googleが発行するクレカの特典とかでもいいから
(Googleにはクレカ利用料の数％のインセンティブがあるからそれで賄える)

Googleブランドのクレカが欲しいねん

Let's encryptとGAEと自動更新スクリプトで無償SSLは既に実現できてた
それを管理コンソールから簡単に設定出来るようにしたとか、そういうのかね？

http://b.hatena.ne.jp/entry/s/cloudplatform.googleblog.com/2017/09/introducing-managed-SSL-for-Google-App-Engine.html
はてぶで取り上げられてた
やっぱり無料はデカイよな

これでPaaSはGAE一択になったな
今までSSL証明書に払っていたお金をスケールアウト費用に回せるから
コスパぶっちぎりで良い

AWSも追従してくれ

すでにあるがな
https://aws.amazon.com/jp/certificate-manager/pricing/

GAEはAWSと違ってサービスが成長しなければ、ずーっと無料で運営できるのが良いのだよ
失敗時のリスクが低いから挑戦しやすい
ランニングコストがほぼ0円になれば、例え月10万PVしかないサービスでも停止せずに
次の新しいサービスを並列で増やして収益アップできる
月間10万PVのサービスを100個作れば1000万PV、月間150万円の収入が期待できる
資金力がない学生起業にぴったりだわ

GAE/Go SE素晴らしいのに採用事例が一部の野心的な会社しかないんだよな
DeNAとサイバーエージェント、メルカリ(の子会社)くらいしかない

datastoreの学習コストが問題なのかね

HTTPSじゃないとSEO不利だからこれは朗報
趣味サイトに年間1円も掛けたくない

レッツエンクリプトなんて今更感しかないだろ

>>358
datastoreが使いづらいと言ってもgoコード側でスキーマ設定する感じだし
joinできないからこそ結果的に使いやすいかもしれない
dbの挙動もレプリカありきの挙動だとすれば納得できる

いわゆるBtoBの受託開発だと帳票出力があるからjoinないとキツイが
GAE/Goが想定してるのはBtoCのwebサービスだからjoinなくても何とかなる
ページングもカーソル使って次へと戻るだけあればいい

handlerのテストってどこまで厳密にやるべきなの？
DBとのやりとりの部分とかは内部で使ってる関数をテストすればもんだいないから様々なパラメタに対して200を返せるかどうかだけでいいのでは？と思うんだけど

>>363
バリデーションを網羅できてればいい気がする。

>>364
そのバリデーションってどこのことだろう…？
自分の中ではhandlerに対するテストなんかは裏側から取得してきたデータがどういうものかはあまり気にする必要がなくて入力と返ってきたデータの出力の仕方だけが関心点だと思ってるんだけどなかなかそういう記事とか見かけないんだよね

postしたデータは、バリデーションせずにdbに、ぶち込んじゃうの？
get系でも入力パラメーターのバリデーションあるよね。

>>366
そこでのバリデーションならちゃんとテストケースに含めるべきだと思う
一方でたとえばUsersテーブルからデータをとってくるためのgetUsers内でのバリデーションのようなものはテストケースをいちいち考慮したくないということが言いたかった

golangで独自の仮想通貨を作るのって出来る？
gethを改造すればいい感じ？

go test とか go build, go install などのコマンドってどこに定義されてるの？
ソースを読んでみたいんだけど見つからなくて困ってる

cd ${GOROOT}/src/cmd

ありがとう、cmdのinternalにあるの見逃してた

>>370
最近はGOROOTもGOPATHも環境設定不要だから
cd ${go env GOROOT}/src/cmd
ってすべき

ゲーム作るためにgo-gl/glfw使おうとしてmain関数作って実行しようとしたら、
build constraints exclude all Go files in C:\Users\ユーザ名\Desktop\glfw

って出た。GOOS=windows, GOARCH=386で試したんだけど初心者すぎてわからん

予選通過組はGoが半分か。すごいな。
http://isucon.net/archives/51000131.html

Ruby使いはwebデザイナあがりの意識高い系が多い(もちろんMac)
PHP、Perl使いは大昔にHTMLタグを直打ちしてたHTMLコーダー出身のスパゲッティコードを量産していた老害と、その老害を上司に持つ可哀想な若者が多い
Python使いは科学技術や情報工学系(自然言語処理、機械学習、深層学習等)のアカデミア出身者が多い
Go使いは新進気鋭なBtoC系上場企業の社員が多い
JavaはBtoB系受託IT土方が多い

こういう印象あるわ

この結果を受けてweb＆スマホアプリのバックエンドはGoが主流になるんだろうな
当社ではGoエンジニア募集中です

Goは日本語学習サイトを充実させたほうがいい
PHPerがGoに移行するにはネットで検索＞コードをコピペ
この集合でwebアプリケーションが作れないとダメだからな

>>374
単純に力ある人がGo使うようになってるだけだと思うんだよなあ
別にGoがすごいとかではなくそこそこ力ある人はRubyでもPythonでも予選突破できる

インタプリタとコンパイラ言語で速度比較したらそりゃ
Goのほうが有利だろ
省メモリ性やら単純な速度まで桁が違う

将来性あるのかね

俺もうSPA前提でバックエンドにgoaを使うことでwebアプリ書いてるんだけど、いいよね。なんかgoaはマイクロサービス用のフレームワークと名乗ってるんだけど、別にマイクロサービス関係なしに使いたいんだけど。
つーかGAEで使ってるけど良い。

SPAってSEOどうなの？

仕事でwebサービスをGoで書いてるけど、もっとGo使う会社増えないかなー
Go使ってて転職したいと思う会社が無い

>>380
Googleの基幹事業だしDonateで維持してるオープンソースコミュニティ発の言語よりは将来性あるんじゃね
Youtubeのバックエンドで動いてるPythonコードをGolangに変換してパフォーマンス改善してるし
その他にも色々とGolangで動いてるシステムがある

また今の時期にGolangに目をつけてる会社は、経営陣(CTO等)に先見の明がある証拠だから伸びるだろう

どうでもいいけどGolangって書き方に違和感ある。
Goかgolangじゃないの？

C言語
Clang
https://ja.wikipedia.org/wiki/Clang

Go言語
Golang

この伝統に則って大文字だぞ
○＋langのlangはググラビリティを向上させるsuffixでしかない

Dlang
Erlang

あーらんは正式名称じゃん

>>386
qiitaのタグだと
Goかgolangだよね

タグなんてユーザーが適当につけるものを論拠にされても

gopherのみんなはGoのinterfaceについてはどう感じてる？
他の言語のinterfaceについて詳しくないんだけど、interfaceのもつメソッドを実装していれば満たしていることになるというのがどうも分かりなくくて辛い
明示的にこのinterfaceを満たしてますよみたいなのが欲しいのは修行が足りてない？

Frank
Golang

>>392
type T struct{}
var _ I = T{}
でT型がinterface Iを満たすかチェックできる

>>393
チェックできるかどうかというより何を満たしてるかパッと見でわからないという意味で辛い

Goのinterface面白いと思うよ
何を満たしてるかぱっと見でわからないっていうのはinterfaceの使い方が良くないんだと思う
必要なメソッドを理解しないまま使おうとしてるからわからなくなるんじゃない？

>>394
393でコンパイルエラーが出て何の実装が必要かわかるんだから、それで問題ない気がするんだけど。

>>395
面白いしJavaとかより柔軟だよね。
もっとinterfaceを拡張してプロパティとか演算子のシンタックスシュガーをもっと付けて欲しいとは思う。
多分上手く拡張できればジェネリクスに近い感じになると思うんだけど

>>396
？
そもそもIの存在を知らないような場合にそういうコードでチェックできないと思うんだが

TにReadメソッドが実装されてる→よく読み進めるとIにはReadメソッドをもつ→TはIを満たしてるという思考の流れが気持ち悪い

>>398
考え方がおかしい。元々の質問は
>> 明示的にこのinterfaceを満たしてますよみたいなのが欲しい
という話だから当然inteface “I”の存在を知っている前提。
構造体Tを作っていてそいつにinterface Iの実装を行いたいという場合に

type T struct{}
var _ I = T{}

とういう風に書くと実装条件を満たすかをコンパイルエラーでチェックできるから
確実に実装できる。

もしかして定義済みの型がどのinterfaceを実装してるのか明示してほしいってことか
でもそれGoのinterfaceの考え方じゃないよ

>>400
アンカーつけないとなんに対しての反論かわからんのだが。
interfaceの概念はべつにGo独自とかそういうもんじゃないし
Goのinterfaceの考え方ってなんのことを指してるのかよくわからんな。
基本的にはJavaと変わらんでしょimplementsが不要ってだけ。

>>401
>>400は>>391,394,398あたりへの憶測

他言語のinterfaceは、imprementsすることでその型が何であるのかを説明するためのもの
Goのinterfaceはオブジェクトが必要な機能を備えているか調べるためのもの
だから考え方が違う

>>402
なんかフワッフワした言い回しすぎて何を説明したいのかがわからんな。

interfaceは、英単語の意味そのものだよ。つまりはメソッド名とパラメーターの並びと、返り値の型の組み合わせそのもの。

それ以上でもそれ以下でもない。
基本的には言語として共通の概念と言える。

goとそれ以外の言語の違いは
型（javaの場合はclass）がinterfaceを満たす条件が違うってだけ。

条件の違いは
java: interfaceを明示的に指定する
go: interfaceと同じメソッドを、実装する

どうでもいい言葉あそびを始めちゃった

PHPerだらけだったうちの会社もとうとうGoの勢いを感じて次のプロジェクトで使うことになった
ISUCONの結果が地味に効いてる
経営陣はAWSの課金が減ることを期待してるみたいだけど、はたしてどうなることやら

>>405
なぜGAE/goを見ない。

他人の書いたソースを読んでて特定のinterfaceの実際の実装を見たい場合
どの構造体や型をみればいいのか探すのが面倒なことはまれによくある

> Goのinterfaceはオブジェクトが必要な機能を備えているか調べるためのもの

これって公式にどっかに書いてあるの？
というかGoにオブジェクトって概念あるか

>>407
guruが対応してるから簡単に探せるで
vscならcmd+f12で実装を探す

>>409
うん
手元にcloneしたソースはguruで探すけど
githubでソース眺めてる時とかがちょっと困る

>>406
GAE/GoでgRPC使えるんだっけ？

GAE/GoやるならStandardで使いたいんだよね

GAE/Go SEとgRPCは色々と苦しい
代替案として挙げられるのはGAE/Goとgoaあたり？

GAE/Go Standardでも gRPC は urlfetch でいけるんじゃないの？ やったことないからわかんないけど

>>410
doxygenみたくinterfaceのコードのところがリンクになってクリックすると
実装一覧が出るようにしてほしいってことね。

バックエンドはGAE/Goとgoa
フロントエンドはReactとReactNative(またはVue.jsとWeex)
この構成でwebアプリ、スマホアプリを作りたい

こういう開発者向けにRailsチュートリアル並に詳細かつ丁寧に解説してあるネット文献
あるいはAmazonで買える技術書が欲しい

>>416
お前は俺か。俺の場合はreact-nativeだけノータッチだけど

ホントはgRPCとGAE/Go使いたいんですぅ…

goaのDSL覚えるくらいならproto3やったほうがいいよね
goaのほうがgRPCより優れている点が思い浮かばない

普通にweb apiを簡単に作れてswaggerと連携って魅力じゃないので？

同じことをgRPCでも出来るがな

goaはWebAPI作るのには便利だけどそれ以外のケースであまり融通が聞くとは言い難い
そもそもWebAPIならどのフレームワークで作っても大差はない

goaはGo言語で記述するDSLからGo言語の各種ソースコードを自動出力する
gRPCは言語非依存のprotoファイル(IDL)から対応言語(Go言語以外のメジャーな言語に対応)の各種ソースコードを出力できる
汎用性が全然違う

企業目線だとgRPC選ぶのが多いんじゃないかな
実際にメルカリ、DeNA、CA、その他スマホアプリ大手のバックエンドはgRPCだし

GAE/Go SEで何の苦労もなくgRPCが使えれば平和になれそう

go-json-restはどうなん？正直これぐらいが一番好きなんだが

>>422
いやいやwebapiならgoa一択だと思うんだけど。もちろんゼロから構築という前提でですが。

gRPCならprotoを覚えるとGoのサーバーサイドも自動生成って認識で合ってる？DBとのつなぎ込みの部分はどう書くの？

goaやgRPCは「定義ファイル→ソースコード＆ドキュメント生成」
go-json-restは直接ソース弄る系だからアプローチが全然違うな

goaもgRPCもDBまわりのビジネスロジックは手書きです
そこまで忖度はしてくれませんよ

>>428
ですね。アホな質問しました。
goaだとフレームワークも含めた形でコード生成するんですが
protoによるgRPCの場合はどうなのかなーと。例えばミドルウェアはサポートしてます？


goaもv2でgRPCをサポートするっぽいんですが、protoでのサーバサイドGoコード生成がいい感じならお役ゴメンもあり得るんですかね。

自動生成されたサーバーのハンドラ部分を各種フレームワークに繋ぐだけ
フレームワーク上のミドルウェアとも組み合わせることが出来る

ちなみにちょっとググったらjsからgRPCは使えないみたいですね。
reactNativeからは使えるんですかね。
jsから使えないのは痛い

いや使えるよ
https://github.com/grpc-ecosystem/grpc-gateway

なんか知らんけど急に役立つスレ化する時あるよな
ここでEchoがGAE/Goで動かない報告(>>223)したら
瞬時にパッチ当ててくれたり(>>239)
Go言語界の実力者が見てるっぽい

mattnさんgoのコントリビュータだし古参の2chねらーだからなあ

>>432
えー。これってrestAPIに変換してるってだけでは？
それってjsから使えるって言っていいんすか。

slackだとあんましアホなこと言えないしね

https://twitter.com/search?f=tweets&;vertical=default&q=GAE%20gRPC&src=typd&lang=ja
TwitterでGAE gRPCを検索したらお前らがいたw

Qiitaでよく見かける人だらけやw
ISCON参加者もいるだろ絶対
レベルたけぇわこのスレ

>>435
grpc-webみたいなのなかったっけ？

goa使ってたらv2になったタイミングで勝手にgRPC対応してついでにGAE対応になってたらよい

>>438
でも俺1人でスレのレベルを大きく下げてるからな
油断すんなよ

>>441
ふざけんな俺もだわ

俺も俺も。正直slackは怖くて書き込めない。匿名だとクソな意見も言えるから大事

>>439
grpc-web-clientをGAE/Goで動かしてみた
https://qiita.com/koki_cheese/items/f2a1a1bc58b7ed881374
これでいいんじゃね

>>444
これやってみたけどgen.shがWindowsだとエラー吐きまくるなぁ…
やっぱりみんなMac上でしか動作確認してないのか
周りもMacかUbuntuだらけだしweb系はMac買ったほうがいいのだろうか

>>445
普通にエラー報告したら？
やってくれる人いると思うし知っていれば難易度が低い作業。ほぼワンライナーコマンドみたいだし。

protoコマンドがwin対応してないなら詰むけど

ドッカーでドカドカやればええんや！

docker+windowsは相性が悪くて
ファイルパスが￥と/で違うから
共有フォルダ設定が上手く行かず苦労した記憶ある
おとなしくmacかlinux上でやったほうがいい

個人的にWindows上で開発するのつらい
Windows用のアプリ作るときもLinuxで作ってクロスコンパイル
Goはその点すばらしいよね

(ただWindowsにしか対応してないpackageがある時は辛いけど)

>>449
winにしか対応してないパッケージがあるの？
そんなんあるんだ。逆じゃなくて？

でもコントリビュートするチャンスじゃん

例えばコレとか
https://github.com/lxn/walk

A Windows GUI toolkitだから当たり前じゃね

GAE/Go　Datastoreライブラリ
https://speakerdeck.com/vvakame/golang-dot-tokyo-number-11
https://medium.com/@timakin/mercari-datastore%E5%AE%9F%E6%88%A6%E6%8A%95%E5%85%A5-a7211c56b77a

良いな
GAE/Goの発展に寄与してくれるメルカリに感謝

Using GopherJS with gRPC-Web
https://blog.gopheracademy.com/advent-2017/gopherjs-grpc-web/
これもいいな

インフラエンジニア分の人件費を完全にカットできるからROE高そうだな
10人くらいのチーム規模で月商5億くらいのサービス支えられそう
少数精鋭でいけるのが大きい

goon と gosto を統一したようなパッケージなのか
便利そうだな
俺も使ってみよう

インフルエンザ

https://qiita.com/koki_cheese/items/369cdfc6e3250185ccdb
この記事を見ながらGoogle App Engine上でgRPCを動かすテストをしているのですが
Windows環境だとproto_gen.shが動きません
https://github.com/k2wanko/gae-grpc-web/blob/master/build/proto_gen.sh

--plugin=protoc-gen-go=${GOPATH}/bin/protoc-gen-go \
この部分で指定されたファイルが見つからないエラーが出ているみたいですが
その場所にちゃんとprotoc-gen-go.exeは存在していますし、環境変数にGOPATHもしっかり設定されていました

やっぱりMac買ったほうが良いんでしょうか…
windowsだと本筋とは関係のないエラーに遭遇しまくりで萎えてしまう

'.' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

あぁ謎…

古いMacbookでテストしたら普通に動作しました…
Windowsで開発はやめときます

誰でも簡単にネットで稼げる方法など
参考までに、
⇒　『半藤のブブイウイウレレ』 というサイトで見ることができます。

グーグル検索⇒『半藤のブブイウイウレレ』

6BTU26N0P5

保守

twitchtv/twirp いいよね

☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆

web系じゃなくてすまんが仮想通貨業界ってGoの存在感大きいんだな
東大発のベンチャーAIxブロックチェーン企業の求人がGo言語エンジニア直指定だった

ちなみにこれな
https://en-gage.net/daisy_hr/work_60316/
<必須要件>
> プログラミング言語
・Go （半年以上の実務経験）

イーサリアムがgoで実装されてるから。(C++とpythonもあるが)

skycoinもgolangだった
フィンテック系にも浸透してきてるね

プログラミングを誰でも習得できる方法は、「前場アキドルのプログラミングマスター方法」というブログで見られるらしいよ。ネットで調べると見られるらしいです。

2C3G9

progateにメルカリ監修でgoの講座できてる

>>469
メルカリ相当力入れてるよな

ついでにバンナム＆スマホアプリの採用例も置いておく

https://cloudplatform-jp.googleblog.com/2018/07/google-app-engine-bandainamcostudios.html

＞GCP の採用においては、エンジニア側の熱意も大きかったようです。
＞「GAE と Datastore、Go 言語でやりたいという思いがエンジニアにすごくあったんです。
お前らがいたぞ

progateのgo初級編やってみたけどドットインストールと大差ないな
出来ればGAE/Goで作られたカウルをフルスクラッチで作れるくらいの内容を中〜上級編として公開して欲しい

>>472
カウルって何？

>>473
http://ascii.jp/elem/000/001/499/1499741/
>現在、メルカリ(中略)新規事業として(中略)本やCDなどに特化した「メルカリカウル」を提供している。
＞メルカリカウルにおいては、すべてGAEで構築している。

>>474
何だ。専門用語かと思ったが略称なのね

gRPCをGAE/Goで使いたい。

この本の中身ってさ
https://techbooster.booth.pm/items/715936
第3章 Google App EngineでgRPC Webを使う
@k2wanko

この記事とほぼ一緒？
https://qiita.com/koki_cheese/items/369cdfc6e3250185ccdb

http://nodir.io/post/138899670556/prpc
pRPC: gRPC on Classic AppEngine today

こういうのもあるんだな
色々調べてみるか

仕事でgoでgRPC使ってるけどさ、正直何がいいのかわからない
JSON返しゃよくねと思ってしまう

本当に仕事で使ってたらその発想は出ないはずだが・・・
webの相手しかしてないの？スマホアプリのバックエンドとして普通使うよね？

WebView使った側ネイティブアプリだとJSONしか使えなくね

マイクロサービス間の通信にgRPC
フロントエンドにはGraphQL

別にサーバとクライアント間ではjsonでも困らんと思うが。
どっちかというとクライアント内のデータ構造がjsonのままはきつい。

OpenAPI(Swagger)とgoa使ってる人いる？
webアプリにしか使わないならこっちのほうがいいよね？

俺は普通のwebアプリでも使ってるけどね。spaなら全然行ける

>>483
使ってると言いたかった。
マイクロサービスとか言うけど、結局webサーバーとして使えるから

gRPCあきらめてTwirp使おうぜ

Twirp良さそうだな
HTTP1.1→2.0の過渡期限定だけどさ
.protoが同じなら生産性も学習コストも同じだし

Twichもgolang使ってたのか
覇権確定だな…
邪悪なOracleの支配下になったJavaを捨ててgolangに来たかいがあった
技術選定を見誤ると数年以上の遅れに繋がる

Google、Go Cloudを発表――クラウド開発ツールでGo言語の普及加速を目指す
https://jp.techcrunch.com/2018/07/25/2018-07-24-google-wants-go-to-become-the-go-to-language-for-writing-cloud-apps/

Googleが用意したGoのライブラリを使うだけで
GCPやAWS等のクラウドプラットフォームを自由に切り替えできる
ポータビリティの高いwebアプリケーションが開発できる、ってことかな？
これは良いね

ksk

goでwebサーバ建てる場合ってwebapiサーバだよね。
普通のwebアプリ。html返すようなのにgoを使うメリットってあるかな？

というか向いてるgoのフレームワークある？

goでhtmlはやめたほうがいい

今どきhtml吐き出し系のwebしか見てない設計を選択するのはやめたほうが良いと思うけどな
RESTないしgRPCないしTwirpにしてプラットフォーム共通にすべき
ネイティブスマホアプリ対応が二度手間になる

>>492
動作が高速

>>495
俺も最初はそう思ったけど、クライアントサイドのバグ対応を考慮すると、
必ずしもSPAが正解とは言えない気がする。
インスタンスの生存期間が短いほうがシンプル何だよね

うちはgoやめてrustに移った
えーん

>>497
requestに対するresponseのみの構成。
ぶっちゃけSSRな方式のほうが

うちはgoのプロジェクトだらけになってきた。
ちなみに時価総額数千億の大手。

メルカリか

ストックオプションうらやましい
俺ならヤングリタイアするわ

ヤングリタイアならいいけど
仲間数人雇って独立はやめとけよ
人件費だけであっという間に数千万飛んでいくから…
まともに稼げるプロダクトがないのに見切り発車で起業して
自殺してしまった人を知ってる…

1人でも起業できるのがITの良いところなので
自称ニートしながらPeingみたいな小粒サービスを何個も作ってたほうがいい

>>503
いいね。

一つ聞きたいんだけどgoでweb apiサーバ建てるとしてwebクライアントはどうしてる？
spaってインスタンスの生存時間が長くなりがちだし、バグったときに全体が止まるから好かんのだけど、どう作るのが一番手軽？

API次第

goaを使う

Twirpを使う

Visual Studio Code使ってるんだけどさ
ビルドタスクのtasks.jsonの記述冗長すぎないか？
結局make使ってるわ
シンプルで理解しやすいし
やりたいことはprotocくらいだしいいよね？

goはmakeしか使ったことないわ

鯖は全部jsonで返して
クライアント側はVueかRiot

reactっていったい何だったんだろうな
最終的にｖｕｅ．ｊｓの天下になった

anguler

VueよりRiotの方が簡単でシンプルで再利用性が高いと思うの

https://m-fetishism.com/vr/
https://m-fetishism.com/puke/
https://m-fetishism.com/joi_mania/

reactの方が単価高いけどな

Vueは結局jQueryと同じになりそうだが...
githubのissueもreactよりずっと少ないし、
npmの週刊ダウンロード数見ても数倍差がある...

結局単価高いのはtypescriptでreact書いてるところだし

Vueは結局jQueryと同じになりそうだが...
githubのissueもreactよりずっと少ないし、
npmの週刊ダウンロード数見ても数倍差がある...

結局単価高いのはtypescriptでreact書いてるところだし

vueだとどうしても型で固めきれないよね。
reactはflowとか型付言語と合わせて使うのがほぼ前提になってるから。

Go言語チームとGoogleが「Go Cloud」プロジェクト発表。同一コードでAWSやGoogle Cloudなどに対応できるポータブルなクラウドアプリの実現へ
https://www.publickey1.jp/blog/18/gogooglego_cloudawsgoogle_cloud.html

やっときたか

gRPC-Webが正式リリース。WebブラウザからgRPCを直接呼び出し可能に
https://www.publickey1.jp/blog/18/grpc-webwebgrpc.html

関数の引数にstringを渡しているときは常に値渡しで、
文字列をコピーしているって公式の記載で書いてあるところどこにありますか？
探しているんですが見つからず。arrayは値渡しなのは書いてあるんだけど、、、

えっと、その情報のソースはどこにあるの？
ソースください（公式に記載があることを断定していることからするとソースがあるんだと思いますが）。

そして、文字列のコピーってのは何を言っているんですか。

Go の文字列は immutable だから、中身のバイト配列をコピーする必要ない。
https://golang.org/ref/spec#String_types
ただ Go の文字列は、配列というよりスライスに近くて、
実際のバイト配列へのポインタをそのサイズを持った構造体である。
https://golang.org/pkg/reflect/#StringHeader

この StringHeader についてはコピー（値渡し）される。
でも中身の Data はコピーされない。
別に、Data もコピーすると思い込みたければ思い込んでもいいけど、
immutable だからコピーしてもしなくても変わらない。

実際に試してみれば：
https://play.golang.org/p/qsaq4AET8ac

>>523
おーありがとうございます。
https://blog.golang.org/go-slices-usage-and-internals
見ながら文字列=arrayなのかと想像していたんですが
実際には文字列=sliceだったんですね
そのへんの記述が見当たらなくて悩んでたんですが、公式のドキュメントには書いてないんですかね。実験で確かめるしかない感じ？

>>523
そのページの Related articles に書かれてますよん。
https://blog.golang.org/slices

> Now a brief section about strings in Go in the context of slices.
> Strings are actually very simple: they are just read-only slices of bytes
> with a bit of extra syntactic support from the language.

> An important consequence of this slice-like design for strings is
> that creating a substring is very efficient.
> All that needs to happen is the creation of a two-word string header.
> Since the string is read-only, the original string and
> the string resulting from the slice operation can share the same array safely.

>>525
亀レスですがありがとうございます。
ところでStringHeaderで言語内部のデータ構造にアクセスできることに感銘を受けたんですが同じようにsliceにもアクセス可能なSliceHeader的なのもあったりしますか？
とおもったらStringHeaderの上にもあったw

Hugoいい

【自衛隊内闇組織、別班】　安倍晋三・田茂神俊雄によるクーデター未遂事件、大垣新幹線ボルト抜き事件
http://rosie.5ch.net/test/read.cgi/liveplus/1541727683/l50

go modulesめっちゃ便利やな
GOPATH関係なく動くのが本当にいい、開発時に嫌だった制限がとうとう無くなってハッピー

>>529
確かに便利だわ。

GAEのstandardも1.11からurlfetchとかが消えてハッピー
ベータとれたらやっと人に勧められるわ

すれち

ええねん

TwirpってことはHTTP/1.1なREST使いたいんだろ？
双方向通信やストリームを使わないのであればgRPCよりも
GraphQLのほうがいいと思う

nuxt.jsとGraphQLを組み合わせてサービスAに統一するほうがいいぞ
nuxt.jsのserverMiddlewareでフックしてGraphQLのエンドポイント出すだけ
https://qiita.com/takanorip/items/d1e8618800d951780f4b

https://twitter.com/ydnjp/status/1066529802142674945
参考までに
https://twitter.com/5chan_nel (5ch newer account)

それならサービスBにプレーンなApollo-server(graphqlサーバ)デプロイして
サービスA(nuxt.js側)からクエリ投げてJSON取得する構成のほうがよくないか

せっかく境界つくるんだから疎結合にしとこうぜ
Microservice化して作業担当者の責任を明確にしたほうがいい
負荷に応じてインスタンスのグレードやインスタンス数を上げたり下げたり出来るメリットも生まれる

フロントエンド(SSR)担当のサービスA
バックエンド(GraphQL)担当のサービスB

スッキリするじゃん

まぁ例のQiita記事はApollo-clientとNuxt.jsのやり方だから、Serverには触れてないけどな
＞nuxt.jsのserverMiddlewareでフックしてGraphQLのエンドポイント出すだけ
これに対しての意見な
serverまでnuxt.jsに密結合させる必要はない

GoでGraphQL(GAE)
https://outcrawl.com/graphql-server-go-google-app-engine
https://qiita.com/trrrrrys/items/44e839134af1a0155be2
https://tech.mercari.com/entry/2018/10/24/111227
https://github.com/99designs/gqlgen
>まず個人的な理由から。 筆者はGoogle App Engine/Standard Environmentの信者であり、
>それ以外のプラットフォームを使う気は今の所ありません。

いま日本企業で一番、エンジニアの採用に力入れまくってる
最先端ベンチャー企業の社員がここまで言い切るってことは
今後はGAE/Go注目かもしれんな

俺もGAE/Go信者やで
実はその他のPaaSやIaaSクラウドにはない魅力がGAE/SEにはある。
それは「1日の予算設定」だ。
GAE/SEだけ、EDDoS(エコノミックDDoS)で予期せぬ損害を被るリスクが低いのである。
予算使い果たしたらOver Quotaエラーでて終わり。サービスは停止するが破産は免れる。
他のサービスは予算ライン超えても警告メール出すだけで止まらない。
パケ・ホーダイのないスマホでYoutube動画を見るくらい恐ろしい行為なのだ。
資金力のない零細ベンチャーが、悪意ある競合他者から身を護るために有効な選択である。

GAE/Node.jsとGAE/Goってどっちがスピンアップ早いのだろう？と思って調べたらこうなった

https://www.bunkei-programmer.net/entry/2018/06/13/232912
Go　平均0.495秒
Node.js 平均0.6516秒

Javaは問題外だな

JavaScript界隈のエコシステムが羨ましくなってきた…
Nuxt.jsでSSR出来るのNode.js環境だけだし
パッケージマネージャーのYarnは高速かつ進捗表示が親切だし
(go get だと-vオプション付けても分かりにくい…)
GraphQLもApollo Server楽ちんだしドキュメントもわかりやすい

Go言語だとスキーマ定義が冗長だったり(graphql-go)
プレーンで可読性の高い定義ファイルから自動作成できる便利なgqlgenは
gqlgenコマンドバイナリが何かトラブってdeplicatedになってるし
いまいちすっきりしない

jsみたいなコンパイラ通さない言語はテストが大変すぎて使いたくない
ほんのちょっとしたものを作るのはいいけど規模がでかくなると苦痛のほうが遥かに大きくなると感じてる

巨大なプログラムを書けない人はセンスが無いだけ
そういう人はコンパイラ使っても破綻する

頭悪そうなレスだな
出来る出来ない論じゃなくて？

くゃしぃのぅ

>>543
Typescriptあるやん

GoにはGoの良いところがあるから心配するな

https://github.com/prisma/prisma/issues/1708

prisma/prismaはいつGoogle Cloud Datastoreに対応してくれるんだい？

何事も適材適所

(1)Google App Engine Datastore
　import "google.golang.org/appengine/datastore"

(2)Google Cloud Datastore
　import "cloud.google.com/go/datastore"

(3)Google Cloud Firestore
　import firebase "firebase.google.com/go"

この関係が複雑で分かりにくい
将来的には(3)からbetaが取れて本流になるんでしょ？
あとgo111の第二世代GAE/SEと旧世代のコードが分散してて辛いな
最新の情報はここを見て！という道標が欲しい
公式ドキュメントは散らかりすぎてて訳わからない

(3)Google Cloud Firestoreは、betaなので東京リージョンが存在しない。
(2)Google Cloud Datastoreは2019年中に自動で(3)にアップグレードされる
おそらく(1)も？

Firestoreの裏側にはSpanner(単独で使うとめっちゃ高い)がある。
またDatastoreモードとNativeモードがある。

Datastoreの裏側にはBigtableがある。旧世代の制約はここから来てる。

FirestoreがGAになったらDatastoreは用済み。
Firestore Native Modeのほうがいいならbetaであること、東京リージョンがないことを覚悟して使うべし。

spanner使ってるけどつらみがある

それは課金額が原因？

原因不明のabortが多いのよね

なるほど

Get Go-ing with Cloud Functions: Go 1.11 is now a supported language | Google Cloud Blog https://cloud.google.com/blog/products/application-development/cloud-functions-go-1-11-is-now-a-supported-language
いいぞ！

GraphQLの定義ファイル書いてCUIでコマンド打つだけで
Google App Engine / SEで動作するwebアプリケーションが
完成するシステムを開発して欲しい

誰か頼むよ
マッツン、わかめ氏よろしく

Golangの魅力って結局なーに？

Go! Go! Go!
And goes on!

>>558
GAE/SEで動かせる言語の中でスピンアップが一番高速
これが最大のメリット

Java→クソ遅い、10秒かかる
PHP、Python→普通
Node.js→やや早い
Golang→チョッパヤ

スピンアップが早いのでインスタンス寝かせておいてもすぐ反応できる
(課金節約)

○○砲などのアクセス殺到スパイクが来てもスピンアップが早いので瞬時にスケールする
他のIaaS、PaaSは割と遅い

gaeでgo動かしてるんですが、jsonpayload形式でログって出せないですか？

くさあっ

Goのwebasmって最小でも2MBって馬鹿なの死ぬの？
この大きさってなんの意図があるんだろう

ランタイム込みだからじゃないの？

Go失速したのかissueマネージメントやら方向性の意思決定に難があるようだな
このまま使い続けて大丈夫だろうか

112の話題ないのか。

Goって流行ってるのか流行ってないのか分からん

Dよりはhot

>>565 氏が難が無いようにしてくれれば、このまま使い続けても大丈夫ですよ！

いわゆる声の大きいstaticおじさんたちにissue占拠されて進化しなくなったな…マジで何とかしてくれ！

みんなのGo言語改訂されるのか。
Goの書籍少ないから買う。

GraphQLとGo言語をテーマにした専門書が欲しいわ
今は学習ソースへのアクセスのしやすさでNode.jsを選びがちになってる
SSRはNode.jsしか出来ないのでそのアドバンテージもデカイ

macでgoenvを使って最新の1.12.xをインストールしようと思ったら一覧に出てこないのですが何か理由はあるのでしょうか？
goenvは1.23.3です。

>>573
goenv v2 で対応される予定だけど、まだそれがβだね。
https://github.com/syndbg/goenv/releases

急ぎの場合はHomebrewとかじゃなくて、直接masterをチェックアウトすると良いよ。

>>574
なるほど、ベータか、、、
無理に最新を追いかけないのがいいかな。
ありがとうございます。

https://i.imgur.com/YiwIqnW.jpg

>>574
試しに入れてみた。
やっと1.12で開発できるぞ。

あのエラーハンドリングDraftが提案されてからもう1年くらい経つが
結局どうなったのかGitHub覗いたら話がまとまるどころか別提案が乱立してた！

えぇ・・・

アクティブなErrHandling提案を分類すると4つくらいかな？類似提案多すぎで追いきれん他にもありそう

a. 公式draftみたいなHandler独立定義タイプ
b. try等の制御キーワード導入で関数コール前に置くタイプ
c. @や!や?等の制御記号をerr変数前後に付与して処理に繋ぐタイプ
d. val := func() onerror(err Error) { ... }みたいな後置ブロックタイプ

aにはそもそも何だったかの不備があって提案が乱立した経緯があるけど
bは他言語の失敗から見ても今更感で大多数が反対
cの記号導入はperl等々のスクリプト言語みたいにsigil,twigilと複雑化していずれ初見殺しになるからGo wayじゃないという反応
dは次の行にif err != nilを書くのと大差なくてerr戻り値が末尾側に固定されるデメリットが増えてるだけと指摘

フロー制御とは別にError型のほうも雲行き怪しいね

Go失速したっけ？むしろ上がり調子な気がする。
案件はある。

V言語がこのまま成長したらGoは完全にお役目終了にならんか少し心配ではある
TypeScriptが出たときのDartを思い出す

C言語にトランスパイルするだけの言語だから
V言語ソース→トランスパイル→C言語→コンパイル→実行バイナリになるので
C言語の弱点(コンパイルが遅い)を強化する糞言語にしかみえないけどな

V言語とか完全にネタ枠じゃん

初期のC++と同じCへのトランスパイル方式なのかVは
Goの文法にRust等のmatchとか?制御とか追加してあったりコンパイルもサイトの説明通り速いな
ホント毎年あたらしい言語増えるの楽しい中学生のやつも

このスレ生きてる？

あべし

死んではいない。

閑古鳥で草
時代はRUST

RUST使いは性格悪いなぁ(´・ω・｀)

新しいことがないからね

go人気落ちてきたな
筋が悪い

エラー制御いまだに決着つかないし
しばらく見ないうちにDenoもgoからrustに変わってたし
Go2出な杉でPerl6みたいな末路にならないか心配

泥船の予感

この言語、やろうかなと思ったらC#より全然遅いのね。
スクリプトよりは早いけど、コンパイルする言語としてはVMでもなくネイティブなわりにめっちゃ遅い。

>>594
まじかー

>>594
別にコンパイルした後早ければ問題ない。

だからコンパイルした後でC#より遥かに遅い。
つか名のあるコンパイル型ではワーストに近いんじゃないか。

>>596
阿呆

しーしゃーぷがまた暴れてるのか、Rustの手のものか、この攻撃性が気に入らん

Go(fasthttp)、C#(aspcore)、PHP(swoole)
https://web-frameworks-benchmark.netlify.app/compare?f=aspnetcore,fasthttp,swoole-coroutine
処理できるリクエスト毎秒はGoの方が1.5倍、レテンシーは50%まで2倍速い、99%になると2倍遅い、平均は同等

てか言語よりも構成だし、後は誰が作るかでしょ。

【２月、２万人】　超過死亡が東日本大震災より多い
://rio2016.5ch.net/test/read.cgi/lifeline/1651735156/l50

Goってもうあかんのか？
Rubyにかえろかな

さよなら。

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

これから学びたい人気言語上位なのにまるでスレが書き込まれてないのは何故？

困ってないから

学ぶやつは5ch関係なく、自分で学ぶ
むしろ、5chで質問するやつは、コピペしかできないし、何をやってもできない

Σ(○д○ノ)ノ