Go language part 2

あ · 2017/11/11(土) 19:25:26.19

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

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

日本語訳
http://golang.jp

※前スレ
Go language part 1
http://mevius.5ch.net/test/read.cgi/tech/1381374291/

あ · 2017/11/11(土) 19:49:11.79

書き込み待って読んでから8時まで待つべきだったかな。
不要なら立て直してね。
一応言い訳すると、スレタイも変わったしそっから長いから普通に二スレ目だと思っとったわ。

もっかい書いとくと、APIが不足してることはない。

995 あ sage 2017/11/11(土) 19:23:54.10 ID:X8lWnCzG
まあ、要らないカラムが多すぎるだけなら、
row,err:=sql.Queryで、
column,err:=row.Columns()
vals:=Make([]sql.RawBytes,len(column))
args:=Make([]interface,len(column))
for i:= range values {
　args[i]=&vals[i]
}

でvalsとargsつくって、
Scanに(args...)で渡せば、
使うときにvals[i]をstring(vals[i])とかよしなにしちゃえるんじゃないの？

**デフォルトの名無しさん** · 2017/11/11(土) 19:52:22.20

>>1
乙。だがhttp://golang.jp/って推奨されないurlじゃなかったっけ？

あ · 2017/11/11(土) 19:54:54.11

>>3
最早死んでるんだっけ？
申し訳ない。単純に引用した。
今どこか良い日本語のサイトがあれば、書いてもらえるとありがたい。

あ · 2017/11/11(土) 19:57:12.37

>>2
あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。

**デフォルトの名無しさん** · 2017/11/11(土) 23:47:05.71

（前スレ）>>984
> 同意する。Goでデータベース操作の決定版がでないのが物語ってる。
>
> 逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。
> スキーマがGo側に設定することが決まっているから。

再度調べて、また考えて、大体理解した。
RDBはKVSと比較されるからKeyValueではないと勘違いしていたが、実はKeyValueそのものだ。
一方、静的言語は基本的にValueだけの世界で、Keyはコンパイル時に落ちてしまい、リフレクションするしかない。
ここが絶望的に相性が悪い。これはGoの問題ではなく、静的言語一般の問題だ。
だったらもうORMにしてしまえ、ということで、GAE/Goのdatastoreは見る限りそれに近い（と思う）

というか、静的言語でDB操作の決定版って、ORMじゃないと無理だろ。
自前のリフレクションはかなり死ねるし、そこを隠蔽してくれないと意味がない。
ただ、ORMまで持ち出すのなら「速度の為に」わざわざ静的言語を選ぶ理由がなくなってしまう。
DBで律速するのなら、動的言語でも大して変わらないはずだし、
管理も楽なら、もう動的言語で組んでしまえ、ってことになる。
(型の問題を回避する為にmapを使っても、同様に速度優位性のない無駄なシステムに成り下がってしまう）

意識したことはなかったが、静的言語では「型」を通じてプログラム全体がゆるく密結合してる。
これは「自分のみ」の世界では全く問題ないのだが、
JSON/RDB等「KeyValue前提の他人」と組み合わせる時にはかなり最悪だ。
PHPが糞言語なのは事実として、何だかんだで他を圧倒して生き残っているのには当然理由があり、
この相性問題はかなり大きい。
また、PHPerやJavaScripterが馬鹿にされる割には何とかなってるのにもこれが寄与してる気がする。
Java鹿が「オブジェクト指向で粗結合化(ｷﾘｯ」してるのは割とミクロな粗結合化で、実はあまり意味がない。
今回のようにReadとWriteを丸ごと粗結合化することは静的言語(の優位性を保ったまま)では基本的に出来ない。
動的言語では速度は最初から捨ててて、組みやすさだけを取っており、割り切り感がいい。

この点、Goは若干中途半端なポジションだが、
Go = C+GC+型システム+リフレクションかな？
C++がリフレクションしたらかなり被るね。

あ · 2017/11/12(日) 00:34:07.92

リフレクションせんでも、アサーションで十分じゃないの？
プリミティブ以外が入ってる事もほぼ無いだろうし、
型無しのinterfaceから、特定のinterfaceへアサーションした方が幸せになれるだろ。
Stringerであれば良いとか。

あ · 2017/11/12(日) 00:42:26.80

まずORMって何か考えれば良いと思うが、Object Relational Mappingだ。
リレーショナルデータベースに入れないのであれば、ORMじゃない。
ORMを、単にデータベースにオブジェクトを入れる道具の代名詞にしてるが、全然違う。

DatastoreはRDBではない。
CouchやMongoみたいなオブジェクトを放り込めるDB。そういう部分には向いてなくはない。

あ · 2017/11/12(日) 00:53:31.35

JsonとRDBを同様にキーバリューと考えてるみたいだが、「RDBは同じ列で構成された行の集合」、Jsonは「「キーで表された値の集合」の集合」であって、キーと列はかなり違う。なぜかと言うと、Jsonは「キーで表された値の集合」単体で成立するが、
「値の集合」は列がないと存在できないし、全ての値の列は同じである必要がある。
だから、マッピングせなならん。
別に、RDBでもID,シーケンス,区分列,値列で持ってメタテーブルみたいにしても良いんだから。

そこがテキトーなのは、単に作り方が雑なだけ。

ちなみに、タグに書いとけば、コンパイル時に抜け落ちる事はないので、それこそreflectで取れる。

**デフォルトの名無しさん** · 2017/11/12(日) 02:15:58.04

GoでRDB使う時に本当にきついのはSELECTとかLEFTJOINとか駆使して
カラムの構造がquery毎に違う可能性があるからなんだよね。
結局クエリごとに構造体作るしかない。
つまるところGoとRDBの組み合わせは避けるのがベスト。かも。

queryの結果から構造体をコード生成する方法があると良いんだけど

**デフォルトの名無しさん** · 2017/11/12(日) 02:48:56.74

てか、staticメソッド無しかよ！これどうなのよ？
ファクトリ作りたいんだが、まさか外に転がせと？ひどくね？
とりあえずクラスメソッドをインスタンスnilで呼んでみたがアウトだし。

なんかもう、色々酷い。
この言語は多分、ベタにしか書けないし、それをよしとする言語だ。
Cだと思えばそんなものだとも思えるが、これは逆に言うと、
Cしかやってないか、Cで何も問題を感じない奴が使う言語だね。
確かにこれだとC並みの速度は出るだろうが、これでは開発効率もC並みでしかない。
新しい言語と言うよりは、新しいBetterCの提案、と考えるべきなのか？

というか、これまで20年ほどでだいぶ積み上げたソフトウェア産業の資産、
「ソースコードはどう書けば見やすい/将来に渡ってメンテ出来るか」
をここまでガン無視していいのか？とも思える。潔いと言えば潔いが、どうなのよこれ？
若干意識高い系共によって肥大化した感のあるソフトウェア方法論へのアンチテーゼかよ？
ミニマリズムというか。

最近は一周回ってCを知らない馬鹿も偉そうにしているわけだが、
そいつらにとってはGoは新鮮なのかな？最近の言語とはだいぶ違うから。
ただ、GoはほぼCだぞいろんな意味で。

**デフォルトの名無しさん** · 2017/11/12(日) 03:04:41.10

>>10
> queryの結果から構造体をコード生成する方法があると良いんだけど
evalだね。Goには当然ないが。

C#でLINQでevalモドキを作っていたのがあったはずだが、
(心はC++のExpressionTemplateみたいなノリで、
演算子と評価順をデータとして記録しとけば、式程度ならデータ側だけで出来る、というもの）
それと同じノリで上手くいけるか、だね。
フィールドのオフセットさえ決まればそれは構造体なわけで。
ただ一般的にはオフセットはコードに静的に埋め込まれているから、
回避するにはオブジェクト指向の仮想関数テーブル(vtbl)みたいな仕組みが必要になる。
逆に言えば、これさえあれば動的な構造体を簡単に扱えるようになる。

JavaScriptは無駄に速くなっているが、この手の仕組み持っているんじゃないかな？
V8はプロトタイプ毎に型扱いでnewしてるようだし。（正式名称があったが忘れた）

あ · 2017/11/12(日) 08:19:16.13

>>11
自分の型をポインタで書いたらnilで呼べるだろ。

可変長もそうだし、ちゃんと言語仕様読め

あ · 2017/11/12(日) 08:21:19.77

なんで既存コードが読めないんだろう。
セルフホストされるようになってから長いぞ。

**デフォルトの名無しさん** · 2017/11/12(日) 10:25:55.87

>>11
goにクラスの概念はないぞ、ドキュメント読んで勉強し直せ

**デフォルトの名無しさん** · 2017/11/12(日) 10:28:45.53

>>13
お、ポインタレシーバならnilで受けられるのか？
しかしまあ、ベタで書くことにした。
というか、どうもその手の「ちょっと綺麗に書くテクニック」を全力で否定するノリのようだし。

なまじ隠蔽出来るから無駄に肥大化するのであって、管理が厳しくなったらパッケージを分けろ、なんだろ、多分。
まあ分からなくもない。
JavaScriptの関数スコープは最初は戸惑ったが、結局のところ関数を小分けにすればいいだけであって、
Cとかはなまじブロックスコープなんてあるから無駄にでかい関数になってしまうのも事実だ。
Nodeのコーディングルールなんて段々短くなってて、どうも今は「関数は10行にしろ」と言っているようだし。
（以前は19行だったと思った。今ググったら15行（多分更新されてないだけ）ってのはあった）
同様に、基本的にパッケージ内にベタで転がしておき、無理ならパッケージを分割、というのも妥当な方法ではある。
そもそもメソッドも（見た目は）ベタで転がってる訳だし。

まあこれはいいとしても、generic的な物がもうちょっとないと、昔の定義のコピペプログラムが必要になってしまう。
この点については何で端折ったのかよく分からんなあ。
C++のテンプレートは暴走気味だし、そういうのを嫌ったのかな？
まあいずれにしても、俺にとってはGoはbetterCとして理解した方がいいというのはかなりはっきりしてきた。

**デフォルトの名無しさん** · 2017/11/12(日) 10:39:35.54

もう「味見」は終わった様だし、やっぱり go は使わなくてもいいんじゃないかな

**デフォルトの名無しさん** · 2017/11/12(日) 11:07:28.87

>>17
いやまだ終わってないんだなこれがw
道草食いまくってるからだが。

ただ、GoはWebには不向きというか、新規機能追加等で変更を迫られた場合、
PHP/JavaScript等と比べて3-5倍のコード変更が必要になりそうだ。
そしてこの、変更時のコード量がCと比べてほぼ同量だ。だから開発効率はかなり悪い。
パッケージが揃っているからとっつきやすいだけで、
（ライブラリを熟知している）バリバリのC++使いにとっては魅力はほぼ無いだろう。
とはいえ、「とっつきやすいC」という存在価値があるのかもしれない。
というか、C++は取っつきにくすぎる。あれは完全に暴走してる。Linusが毛嫌いしているのも分かる。

とはいえ、Goでプロトタイピングするのは辛いのは分かった。
というか、はっきり言ってろくな言語がないなこれについては。
JavaScriptは非同期のおかげでかつてのgoto文プログラムみたいな構造になってしまうし、
PHPは言語仕様が糞過ぎて思わぬところでバグって引っかかりまくるし。
RubyもPythonも前方宣言必須のゴミ言語だし。
同期JavaScript（マルチスレッドだよ！）が出れば一人勝ちじゃないのかな、と思うが、
あいつらの非同期はもはや宗教だし。

**デフォルトの名無しさん** · 2017/11/12(日) 11:10:17.27

長文だらけで追い切れんけど

愚、言語がヘボでカラム分からんとDB操作が出来ません
賢、いやいや、アサーションでこう書けば出来るじゃん？
愚、他言語だとこんなので出来るんだけど
賢、じゃ好きなので書けよ、どうぞどうぞ

まとめるとこんな感じ？

あ · 2017/11/12(日) 12:03:16.36

>>16
ちょっときれいに書くテクニック、が他の言語と違うだけだよ。可変長引数に参照のスライスを渡す、とか、
取り敢えず受けて.(type)でswitchしてcaseに型書いて処理するとか。

ジェネリックに関しては、あれば良いなと思う事もあるが、実際やってみたらrangeで事足りたり、
chanにとにかく突っ込んで、空selectとcase xxx<-xxxchでさらに事足りたりと、便利な読み方はある。
システムコールのselectで複数のファイルハンドル待つ感じ。

>>18
多分ウェブに関して言えば、ちゃんとしてればPHPの工数の4番の1くらいになると思うよ。
ちなみに、JavaScriptでマルチスレッドマルチコアは、クライアントならWebWorkerやら、nodeなサーバならclusterとか色々ある。

あ · 2017/11/12(日) 12:10:41.95

そもそも、クエリの結果イコール構造体にならない事の方が多いでしょ。
構造体の入れたいフィールド(と読み捨てるカラムを放り込む値)の参照を持ったinterfaceのスライス投げるのが一番手早い。
入れたいフィールドのカラムを集めてinterfaceのスライスを返す関数用意しときゃ済むじゃん、ゼロクリアは保証されてるんだから。

**デフォルトの名無しさん** · 2017/11/12(日) 12:18:47.91

>>21
ちょっとわかりづらいからサンプルコードある？

**デフォルトの名無しさん** · 2017/11/12(日) 13:50:03.49

構造体を自動生成するとして中身のわからん構造体をどうやって使うんだ？

**デフォルトの名無しさん** · 2017/11/12(日) 13:57:51.09

結局リスレクション使った遅いもんになるだけでしょ
過度の抽象化は害しかないって偉い人が言ってた

あ · 2017/11/12(日) 14:26:56.37

>>22
>>2
hogeって構造体があって、そのxxを取りたいなら、
のargsの、欲しいカラムの場所に&hoge.xを入れるだけ。
構造体を自動精製するんじゃなくて。

リフレクションとアサーションは違うし、そもそもそこまで遅くないぞ。

**デフォルトの名無しさん** · 2017/11/12(日) 15:10:02.64

つーか、これ、構造体のメンバ名を都合3回書く必要があるじゃねーかよ！
度を超したクソッぷりにビビる。つーか、お前らマゾなのか？

1回目：type struct 内 ← うーん、まあ静的言語なら仕方ないか
2回目：rows.Scan 内 ← 速度の為なら仕方ないか、、、
3回目：メンバ名は大文字で始めてjsonタグをいちいち書け ← 死ね

PHPやJavaScriptでは1回も書かなくていいんだぜ！
さすがにこれには切れたよマジで。
https://qiita.com/vvakame/items/6719b3c90dfaa8220e44

**デフォルトの名無しさん** · 2017/11/12(日) 15:14:41.46

>PHPやJavaScript

どうぞどうぞ

あ · 2017/11/12(日) 15:22:14.00

>>26
Scanには書かんで良いだろ。何読んでんだよ。

Jsonなら、*interface{}で受けて、map[string]interfaceで値とりゃフィールド名出てくんの一回だろ
だから、>>9で、RDBのように行と列が分離してねえんだよって言ってんじゃん。

しかし2chで知りたいことがあればdisれというのはホントだな。

あ · 2017/11/12(日) 15:25:33.81

これで、Cをやってたからついてける、お前はGCの動くタイミングが、とよく言えるな。
Scanの実装見て喋ってんのかなぁ。

あ · 2017/11/12(日) 15:31:37.75

dynamicとかnewtonsoft.JsonのJObjectで受けないC#でもクラスのフィールドに属性つけなきゃならんし、こいつが何を問題にしてるかわからん。
cやcppで書いたらライブラリ使ってももっと地獄じゃん。

動的言語しかやった事無いから辛いと言ってるだけに見える。

**デフォルトの名無しさん** · 2017/11/12(日) 18:57:59.72

前スレ>>977

まさか３回も書かされるとは思っていなかったから今更ながらxoを試した。
が、これもちょっと冗長だな。
標準で go generate がついている時点で、公式も糞っぷりを認めてる。
ASTとか完全に屋上屋を架してる。
ろくな解がない。

構造体メンバを１回書くところまでは許すとして、
Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。

**デフォルトの名無しさん** · 2017/11/12(日) 19:10:52.14

(最初に戻って) sqlx 使えば良いんじゃない

あ · 2017/11/12(日) 19:12:41.31

新参を足蹴にするような真似はしたくないが、
3回も書いたのは自分だろ…。

あ · 2017/11/12(日) 19:18:34.25

可変長引数を受ける関数には、...でスライスを渡せる。
構造体渡したら構造体の(カラム名と同じ(！))メンバに入れてくれる事を望んでるんだろうが、
型がハマらなかったらとか、そもそもクエリでasで別名つけてるかもとか、キャストしたけどasで同名つけてる、とか、クエリ側が勝手な事するリスクを全部解決して構造体に入れる手段を考えてから考えれば良いのに。
まぁmap[string]interfaceが落としどころじゃねえの？フワフワ適当なクエリ投げたいなら。

クエリ自体もGoに書かせたいなら、最早SQLと繋げる意味なかろうて。

**デフォルトの名無しさん** · 2017/11/12(日) 19:29:15.19

>>31
> Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。

ま、↓にでも投げてみたら

ExperienceReports
https://github.com/golang/go/wiki/ExperienceReports

**デフォルトの名無しさん** · 2017/11/12(日) 19:30:43.54

>>32
構造体で受けるだけならそうだね。
ただ、毎回リフレクションはかなり厳しいから、うまくキャッシュしてくれるかどうか。
refrectを見る限りシグニチャは発行してくれないっぽいし。
ポインタ演算を禁止しているから、ＣみたいにOffsetofの結果を配列でキャッシュできないのも残念な所だね。
使うときは速度/ソース確認必要といったところか。

今回は速度の味見だし、とりあえずベタで書いた。
ただ2回書きまでは覚悟してたが、3回とはね、、、

あ · 2017/11/12(日) 19:34:45.85

>>36
まあ俺が煽るから無視してるんだろうが、
煽り抜きでとりあえず>>2と>>25やってみたら？
ベタ書きよりはましだと思うが。
なんかそれでダメな点があればまた教えて欲しい。

**デフォルトの名無しさん** · 2017/11/12(日) 19:37:07.63

>>35
さすがにＧｏ歴１週間もないのに投げないよ。背景等もよくわからんし。
てか、同意するなら誰か投げてどうぞ。

てか、Ｇｏ信者はこの言語のどこに惹かれてるんだ？
特に目立ったメリットはないような。

**デフォルトの名無しさん** · 2017/11/12(日) 19:37:19.23

>>31
むしろ標準ライブラリにASTついてるのって魅力じゃないんかな。
goはコード生成してなんぼなんじゃないの

あ · 2017/11/12(日) 19:37:36.02

ただの別名も指定せんクエリなら、構造体渡して、参照がセットされた([]interface{})返す関数だけでいけると思うが、なんかいかんのかな。

**デフォルトの名無しさん** · 2017/11/12(日) 19:44:29.82

>>37
日本語でおｋ

おまえには日本語が通じず、話が空回りするから無視してる。
map/リフレクションを使わない理由は俺は既に>>6で言っているし、
それはむしろ一般論だから、他の人もそれをふまえて話をしている。
おまえだけ空回りしてるんだよ。そしてそれが荒らし行為なんだよ。

煽るとか、そういう表面的な行為は大した問題ではないんだよ。
おまえは馬鹿だからそれも分からない。マジで死ね。

あ · 2017/11/12(日) 19:46:37.12

>>41
マップでもリフレクションでもないんだが。

**デフォルトの名無しさん** · 2017/11/12(日) 19:47:24.84

>>38
俺的に気に入ってる点。

* 構文規約が言語側で確定してるから誰のgoコードでも見やすい。
* コードの管理周り。正直他の言語でもコード管理は真似してる(ghqをつかって)
* 標準ライブラリが学習教材になってる感じ。
* goaがある。

正直一番最初に使いたい理由になったgoroutineは一番最初に触って以降触ってないな。

色々欠点もあるけど、なんかコード生成によるメタプログラミングを体得すれば解決する問題かも。と思っていてAST周りを学習中

あ · 2017/11/12(日) 19:47:27.64

なんで、リフレクションとアサーションと言葉が違うかわかる？

**デフォルトの名無しさん** · 2017/11/12(日) 19:47:57.59

>>39
いや、正直、そういう文化なのかな？とちょっと思ってました。
てかなに？今時の若者はASTとかでさくっとコード生成しちゃうもんなの？
俺はlexとかbisonとかは触らずにきてるんだけどさ。

あ · 2017/11/12(日) 19:52:21.47

かつ、interfaceが指す先の型がScanner実装してたらそれで勝手にやってくれんじゃないかなぁ、これは勘違いかもしれんが。

まぁ、やりもせず、パフォーマンス計測もせず、思い込みで「これはリフレクションである」と言われても困るわ。

空回りしてんの俺か？

**デフォルトの名無しさん** · 2017/11/12(日) 20:00:44.01

>>38
> てか、Ｇｏ信者はこの言語のどこに惹かれてるんだ？
> 特に目立ったメリットはないような。

ある種のシミュレーションプログラムを作るのに goroutine + channel
で割合と簡単に書けちゃって、32 core 使って並列化したら実行時間が
1/25 程度に抑えられて…といった経験からかな。

あ · 2017/11/12(日) 20:04:43.25

ちゃんと言うと、Goのinterfaceはメモリ上に型情報をそもそも持ってるから、リフレクションせんでもほぼノーコストでアサーションできる、はず。
https://research.swtch.com/interfaces

**デフォルトの名無しさん** · 2017/11/12(日) 20:06:46.98

>>43
go fmtとか、パッケージ管理/ディレクトリ構造が言語に密着とか、確かにいい割り切りっぷりではある。
しかし他挙げてくれた点も、Ｇｏ言語自体ではなくて、エコシステムの話だよな？
いやもちろんエコシステムも重要なんだが。

gorutineはパンダだろ。その意見（最初だけしか使ってない）は割とよく見るよ。

> コード生成によるメタプログラミング
まあＣのマクロやC++のテンプレートよりはましかも。ソースが直接見えるという点で。

あ · 2017/11/12(日) 20:08:42.80

goroutineはAPIサーバ書いたり、システム内でメッセージ投げ合うたぐいの物書いたらめちゃくちゃ便利だけどな。
用途次第だろ。

**デフォルトの名無しさん** · 2017/11/12(日) 20:09:45.01

>>45
そんな恐ろしいもんじゃなくGoコードを構造体に変換できるから
改変がし易いってだけじゃないかな。
正規表現で変更とかよりよっぽど安心できる。

**デフォルトの名無しさん** · 2017/11/12(日) 20:10:17.01

>>47
goroutine+channelがはまったケースか。
それなら分かるとして、ただ、そもそもこれがはまるケースがほぼないよな？

あ · 2017/11/12(日) 20:11:26.99

>>51
ハイジェニックなマクロ展開とか書きやすいしね。

あ · 2017/11/12(日) 20:17:42.78

前スレ974で良いところ行ってたのに、突然のシッタカでグダグダ言う上に読解力に欠けてて、しかもリフレクションだと決めつけてて、
人の話も聞かんと、言葉が理解できないならコードは読むだろうと解説代わり書いて、
Cがわかるなら.sに落として眺めるだろうという期待も裏切り、
何やってるかまったくわからん。

**デフォルトの名無しさん** · 2017/11/12(日) 20:19:14.44

>>51
> 正規表現で変更とかよりよっぽど安心できる。
確かに。自前よりは公式解釈済みの構文木をもらえた方が100倍いい。
しかしそれ、渡されましても、、、ってのが普通だと思うが。
てか、これ見せてる言語ってこれまであったっけ？
最近はflycheckみたいなリントも流行ってるみたいだし、見せる方向なのか？

**デフォルトの名無しさん** · 2017/11/12(日) 20:19:33.62

>>49
俺にとってgorutineはたしかにパンダだったな。
構文規約が言語側で確定って割と言語仕様よりなんじゃないの。
Go言語の言語仕様は物足りさは感じつつってのはある。

interfaceがGoにおけるキモなんだけど機能不足感があって
関数の引数がなんでも受け入れokな interface{} 型になるとかなり残念になる。

多分interfaceにプロパティをokにしたり
type interfceC =interfaceA | intrefaceB
(interfaceCはinterfaceA か intrefaceBどちらかを満たす直和型ってやつ)
みたいな定義をokにしたり、シンタックスシュガーだけど
type interfceC =interfaceA & intrefaceB
みたいな定義もokにしたら幸せというかジェネリクスに進化できる気がする

**デフォルトの名無しさん** · 2017/11/12(日) 20:23:04.06

>>55
標準ライブラリじゃないけどjsがそんな進化を遂げてる。
http://efcl.info/2016/03/06/ast-first-step/

**デフォルトの名無しさん** · 2017/11/12(日) 20:23:55.55

>>52
はまる、はまらないで言ったらやっぱり……いや、もう何も言わないよｗ

あ · 2017/11/12(日) 20:24:47.34

人の話きかねえからな。

**デフォルトの名無しさん** · 2017/11/12(日) 20:26:12.38

何か得意分野があるってだけでその言語は魅力的じゃないの？
rustとか言語ヲタじゃないと触ろうってならないし。

goはCLIツールを作るためのライブラリも揃ってるし
ツール作る系でもおすすめ

あ · 2017/11/12(日) 20:35:12.41

他の人もそれを踏まえて、って誰も勘違いしてなくねえか？
呆れるやつ、ASTいじりはいいぞ、気に入ってる点、諸々。

語るに落ちられてバカさらされて、なんでこんな言われなならんのだ。

**デフォルトの名無しさん** · 2017/11/12(日) 20:47:41.28

>>57
まじかよ！JavaScriptならevalできるし無限増殖できるぜ！って思ったけど、
俺が思ってたASTのフォーマットとものすごく違ってた。
これ完全に文字ベースだよな。
もうちょっとファンクションベースなものを期待してた。
メトリックスをASTから抜いたツールもあるようだが、これ相当死ねるだろ。
http://azu.github.io/slide/JSojisan/#7
まああくまでパースした直後のデータで、だからこそすべての用途に使えるってことなんでしょうな。
ただ、ここからコード生成も相当死ねると思うが。

あ · 2017/11/12(日) 20:50:00.50

見えないフリしてないで>>48を百回ぐらい読んでこいよ。
そして長文で語れよ。

あ · 2017/11/12(日) 20:51:23.21

空回りしてて荒らしでそれもわからないバカなのは誰なのか、どうすりゃいいか>>41読んで考えろ。

**デフォルトの名無しさん** · 2017/11/12(日) 21:02:31.33

>>56
interfaceのプロパティってのは何に使うんだ？

俺は一応、Ｇｏのインタフェースシステム「実装してたらその型として使える」はありだと思っている。
平べったいダックタイピングというか、C++のtemplateを野良で転がしているのに近い。
貧弱かどうかって所まではまだ味見できてないから分からない。

直和や直積（でいいのか？）は別名でテンプレート書け、って文化なんだろ多分。
割とベタが好きな言語なんだと思うよＧｏは。

あ · 2017/11/12(日) 21:05:16.25

虚しくなるわ。悪かったな。interfaceの実装知ってて。

あ · 2017/11/12(日) 21:10:33.63

>>62
escodegenがこれ食うからいいんだよ

**デフォルトの名無しさん** · 2017/11/12(日) 21:22:49.77

>>65の訂正
×　別名でテンプレート書け
○　別名でインタフェース書け

**デフォルトの名無しさん** · 2017/11/12(日) 21:30:04.35

とにかく汎用ライブラリを作ろうとするなり触ろうとするとinterface{}型が登場するのは機能不足によるものだからもっと頑張れ。

と言いたい。コード生成で頑張るべきなんだろう。

goaはコード生成に頼りまくりのおかげでinterface{}型に出くわすことがなくて幸せ。

あ · 2017/11/12(日) 21:35:31.60

>>69
interface型は宣言がそうなだけで、実際には型持ってるから、そこまで嫌わんでも良いんじゃないの？
default書くのをサボらなければそうそう死なん。

**デフォルトの名無しさん** · 2017/11/12(日) 22:15:33.55

>>70
んなこと言ったら動的言語だって内部的には型を持ってるよ。
問題はintereface{}型が関数パラメータに使われた場合、
Printlnみたいになんでも受け入れ可能って意味ならいいんだけど、
実際にはGoの表現力が不足していて仕方なくってパターンが多い。

あ · 2017/11/12(日) 22:41:17.16

>>71
動的言語の良いところを取るべくして、ただのvoid*には無い機能をもたせてるんよ。
表現力が足りないと言うより、ではなくて、本来は型にアサーションするんじゃなくて、別の任意のinterfaceにアサーションして便利に使おうね、って感じの思想。
だから、printf渡すだけでも、%sで渡すとStringerとして扱われたり、%+vで中身が見れたり玉虫色の解釈が出来るようになってる。
何でも受け入れ可能だから形無しinterfaceではなくて、こいつの型は提示せんがフォーマット文字列の通りに扱えよ、という意味であの引数。

だから、interfaceは明示的に実装しなくても、満たす関数があれば自動的に実装されるようになってる。
俺が今こうinterfaceを宣言して、そうするとこの構造体には自動的に実装されてるはずだから、俺は与えられた引数を宣言したinterfaceとして扱うってアサーションがかけれる。逆に言えば、俺に処理してほしけりゃこれを実装しとけ、って発想。
後出しジャンケンみたいなジェネリクス。

あ · 2017/11/12(日) 23:03:45.88

話題()のScanの中で、convertAssignってのが呼ばれてるんだけど、こいつがまさに、Scannerとして扱えればScannerに任せるようになってる。
[]interface{}として渡してて、その1つの指す先が「構造体の要素一つ」であっても、
その要素がScannerを実装してればそれに処理を任せてる。
「構造体の要素一つ」をプリミティブな型で宣言せんと、ちゃんとtype IDColumn int等と宣言して、IDColumnとして構造体の要素を宣言しとけば、IDColumnにScanner実装しとけば[]interface{}の中にその参照突っ込んでもそれが呼ばれる。

type IDColumn int
type xxxRow struct {
　　ID IDColumn
}
で、
v:=xxxRow{}
って作って、
>>2のargsを例に上げるとargs[0]=&v.ID
ってして、Scanに(args...)で渡した時、0カラム名はIDColumnのScanで処理されて、v.IDに入る。

APIが足りてないとか大嘘。

**デフォルトの名無しさん** · 2017/11/12(日) 23:11:21.09

長くて読んでないけど静的言語を使いたいものとしては極力コンパイル時に解決したい。interface{}に頼ると実行時エラーが発生する可能性が増えてエラー処理の記述量がふくらむから嫌いなの。

それだけ。

あ · 2017/11/12(日) 23:18:58.92

そりゃまあ、便利さとリスクの天秤でしか無いわな。
あとからStringerにして、そいつの中で実行時に死にうるコード書いたら、全くソース変えてない部分で実行時エラーになるんだし。

実質sprintfなんか使えないコードになってしまう。

あ · 2017/11/12(日) 23:25:50.08

まぁ、interface受けてるのにアサーションしてないとか、default書いてないのが一番悪い。
defaultはエラー処理じゃなくて正常系。

**デフォルトの名無しさん** · 2017/11/13(月) 10:56:59.34

>>76
は静的言語のメリットを全くわかってない。
以下を読めばinterface{}型のデメリットが理解できるはずだから読め。

http://sssslide.com/speakerdeck.com/twada/php-conference-2016

**デフォルトの名無しさん** · 2017/11/13(月) 12:06:00.11

親切な人が多いけど、ウンコが混じってもコミュニティの役にはたたんよ？
リーナスも言ってるでしょ、基本的には去ってもらうこと、これが最も良い解決策。

向上心が有るなら別だが、基本が納得出来ないなら「どうぞ、どうぞ」が一番良い

あ · 2017/11/13(月) 12:18:42.55

>>77
デメリットと言うより、必要悪だろ。
一切キャストしないCも書けるが

このスライド出す時点でナンセンス。
PHPの変数は暗黙的変換で無残なことになる、数や名前や型の不一致はそれこそ、毎度構造体を作る事によって引き起こされる。
val,ok := アサーション
でokが見れるという点で殆ど対応できる。
Bugクラスが未定義、と言うところもおかしいわな。
interfaceを実装してればそれがなんであれそのinterfaceとして扱えるように、ライブラリ書くだけだろ。

ただの型チェックの防御的プログラミングとは違う。
interfaceとのチェックと、interfaceに任せる事での、そのロジック内での処理と切り離した、interfaceへの責任転嫁に近いが、
interfaceをいかに正しく定義、実装するか自体が問題であって、型は無くて良いよねって言ってるわけじゃない。

あ · 2017/11/13(月) 12:22:19.44

オブジェクト指向だと考えるのが一番いかんな。
ToString()を全ての型が実装してる、と言う発想じゃなくて、
プリミティブはあくまでプリミティブ、Stringerならば、Stringerとして処理できる、という逆の発送。

あ · 2017/11/13(月) 16:18:30.89

よーく読んだら、このスライドで話してることが(責務の分担(interfaceとinterfaceへのアサーション)、
　疑いがあるならば即落とすべき(panic)、
　mixedでのリターン(標準)、
　クラスが未定義の場合何をするか(defaultでの無視))
と、全くGoのinterfaceでの設計意図と矛盾しないことぐらいわかるだろうにな。
世知辛いわ。

**デフォルトの名無しさん** · 2017/11/13(月) 19:04:12.10

>>81
の言ってることが全く理解できないのは俺だけかな？なんだろういくら話してもすれ違い感が半端ない。

誰か翻訳して！

あ · 2017/11/13(月) 21:00:03.61

>>82
お前が、interface{}を、なんでも渡せるvoid *的な物として考えてるから理解できんのだろうな。

あ · 2017/11/13(月) 21:06:35.59

コンパイル時に誤りに気づきたいのは、要は、動作させるまで正常に動くことが保証できないのがいかんのでしょ。
あとからファイル足して、既存コードの動きまで変わる(シグニチャがあってればinterfaceが実装される)言語で、何言ってんだってレベルの話。
どう動作させても最悪、処理対象外データとしてスルーするようにdefault書くのと同じようなもんで。

本気で適当にgeneratorで作った得体のしれないものを関数に渡してるような奴でもあるまいし。

すれ違い感半端ないのわ俺だわ。
何か俺が書いたこと間違ってる？

あ · 2017/11/13(月) 21:12:35.14

どう動作させても最悪、処理対象外データとしてスルーするようにdefaultに書いておくのと同じようなもんで、形チェックに通るか通らんなんか、ポインタがある時点でどのみち同じようなもんで、と書こうとしたら大事なところ抜けたわ。ごめん。

あ · 2017/11/13(月) 21:28:25.68

なぁ、俺が持ってるGoの知識は古いのか？

1.8まではソース大体読んでたが。そんなに読み違えてる？

ソース読んで、設計思想まで理解したやつが「黙れ」って言うならもう黙るわ。
今まで俺が書いてたような内容は標準ライブラリがほぼそのまんまの事してる内容ばっかだよ。
fmt.Printfだけでも一読の価値はあるんだが。

もう好き勝手書いてろと思えてきた。

**デフォルトの名無しさん** · 2017/11/13(月) 21:55:59.07

これ、virtual持ってないよな？ジェネリックなんてまるでやる気ないだろ。
OOPが暴走気味でデザパタ廚のようなゴミを再生産しているのは事実として、virtualなしはいかんだろ。
それに対しての
> 多分interfaceにプロパティをokにしたり (>>62)
なら全くもって同意だ。というか、JavaScriptはこれができて便利すぎる。
むしろあれがC++に入らないのが不思議だ。
継承や委譲をこねくり回してデザインパターン（ｷﾘｯするよりは、
JavaScriptのようにメソッドも第一級オブジェクトにしてしまって、簡単にvtblを手組できるようにした方が、
「見りゃ分かるだろ」的なソースを作りやすい。多重継承も楽勝で対応できる。
Goは多分行き過ぎたOOPの反省でinterfaceが１階層しかなく、この点はいいが、
せっかく第一級オブジェクトな関数をメソッドに代入できない点が糞だ。
これはinterfaceをプロパティバッグにしてしまえば解決できる。(62の指摘はこれだと認識している）
動的対応がいやなら再代入禁止で2パスコンパイル
(インタフェース解決+オブジェクトコード生成)にすれば対応可能だ。
Goの作者はよほどOOPが嫌いか、ジェネリックなんて不要と思っているのだろう。
Goのinterfaceは静的ダックタイピングのためのものであって、記述コードを減らすためのものではない。
俺はこの点は全く気に入らないね。というかコードを減らす努力がGoには全く見あたらない。
おそらくそれがここ20年のソフトウェア産業の努力の方向だったというのに。

**デフォルトの名無しさん** · 2017/11/13(月) 21:57:38.79

すまぬ、安価間違えた
>>87内安価は62ではなく>>56

**デフォルトの名無しさん** · 2017/11/13(月) 21:59:25.48

ちなみに味見の結果は出た。PHP比で15%速かった。結論としてはGoは糞だ。

PHPが糞なのは事実として、のさばるのには理由がある。
GoではPHPを殺せないし、今回のようなWebアプリ(掲示板）ならPHPの方がましだね。
PHP/JavaScriptなら数行で書ける処理を、(前スレ978参照)
型のおかげでベタに3回書くかリフレクション等こねくり回して20-30行書くかが必要で、
それで15%しか変わらないのなら全く割に合わない。
5台クラスタを6台クラスタにすれば済む話でしかなく、物理で殴れ、になる。
しかもPHPは毎回起動/停止するので、メモリリークとか
おかしなリクエストを食わされて落とされた場合のことを考える必要がない。うまくできてる。
(これについてはgoroutineで対応できるが）
そもそもWebアプリなんて型がないとつれーわって規模にもならないし。

ただし単品ではそこそこ速い。今回はSQLiteに引っかかるのでそれが見えないが、
Nodeのデータから推定した結果、Node比-40%、JSON.stringify部分だけなら倍速出ている。
ただしこれならC#やJavaと同程度、C++よりは確実に遅いといったところか。

生産性は悪い。コードを集約する方法が用意されてない。

結果、C++/C#/Java使いがわざわざ乗り換える訴求力はない。速度も生産性も利点がない。
ただしこれらの言語は本当に肥大化しすぎていて、新規に始めるのはかなり辛い。
これらの言語を全く知らないWeb系がコンパイラ系言語を始めるとっかかりとしてはちょうどよく、
その辺が受けている理由か。

言語自体にパワフルさはない。C++にWeb系ライブラリが出そろえば簡単に殺されてもおかしくない。
とはいえ、言語としては確実にJavaより出来のいいC#が完全にJavaより出遅れているし、
これまた糞だと言われているPythonがはびこっているし、
言語の成否は言語自体の出来よりはそれを使う人がいるかどうかが問題であり、
Web系向けの「軽量コンパイラ言語」は確かにないので、離陸できればうまくいくのかもしれん。
とはいえ、Web系は声がでかいだけで、実際のプログラマ人口はJavaの方が圧倒的に多いのも事実だし、
関数型()みたいにポシャっても全く不思議ではないけど。

あ · 2017/11/13(月) 22:02:50.75

そうですか、ではそのように他の言語をお使いくださいな。

あ · 2017/11/13(月) 22:17:05.12

一歩引いて、ハサミを買ってきた奴が、
「これカッターナイフみたい使えねえじゃん！クソカッターかよ！クソだ！
　え？挟んで使う？馬鹿じゃねえの？俺はこれが切りたいから刃を立ててるの！
　刃物で挟むとかちょっと違うオペレーションじゃん？それって効率悪いし、危ないだろ、考えろよ。
　こんなもの、カッターナイフのかわりには成りはしないね！
　断然カッターナイフだわ。ほんとクソ」
ってドヤ顔するのを見るのもちょっと面白いな。

あ · 2017/11/13(月) 22:18:20.70

馬鹿とハサミは使いようだが、馬鹿にハサミは使えないもんなんだなあ。

**デフォルトの名無しさん** · 2017/11/14(火) 00:25:35.42

>>87
56だけどまぁ分かる。今TypeScriptでジェネリクス使いまくってるけど
やはり静的言語に自由度を求めるとジェネリクスがほしい。

でもGoの言語設計ってコード生成しようぜって匂いを感じる。
パッケージ内に生成したコードを置けば自作の型にいくらでも機械的にメソッド追加できる。シンプルな構文でこういう自由度を確保してるのは良く出来てる感ある。

問題はコード生成するコードを書くのが大変ってことなんだよねw
コード生成するコードを書くための仕組みがもっと簡単になればかなり使い勝手が良くなる。

実際ジェネリクス自体コード生成するためのコードをショートカットした技術って感じがする。だからちょっと複雑なことをしようとすると難しかったりする。
コード生成するためのコードは素朴な分そういう頭がこんがらがる感じはないかなと。

あ · 2017/11/14(火) 00:39:55.32

なんでジェネリクスが使えるか、型引数がジェネリクス関数の中で行う処理で必要な演算子やらメソッド呼び出しを実装してるか、だろ。
だったら、そもそもinterface受ければいいだけじゃん。>>56でやりたいであろう直積も和も、interface側ではなくて、構造体側がどう実装するかでしかないし、
それも各構造体で両方実装するとか、各構造体を埋め込んだ構造体書くだけじゃん。

それは、型のないinterfaceで受けるべきじゃなくて、パブリックな「型のあるinterfaceで受ける関数に」から、プライベートな「型のないinterfaceを受けるが中でアサーションしてる関数に渡して」やるだけじゃねえの？

その設計が面倒なら、ジェネレーターで組み合わせ爆発起こして遊ぶべきなんだろうが、
実際は型付きinterfaceで事足りないか？それ。

**デフォルトの名無しさん** · 2017/11/14(火) 02:34:26.33

>>93
> でもGoの言語設計ってコード生成しようぜって匂いを感じる。
俺にはその嗅覚はないが、状況証拠からするとこれはその通りだ。公式ブログ(URL後掲)もあるし。
標準コマンドに go generate とか、最初からASTを見せる気満々とか、iota とか、ちょっと行っちまってる。
そしてパッケージ内に階層がなく、 cat >> で全ていける。コード生成に障害が何もない。
首謀者は一般のプロダクトプログラマではなく、
サポート側のプログラマ（Perlでlinter等の作成とか）だったのかもしれんね。

C++のテンプレートはちょっと行き過ぎてしまっていて、余計に見にくくなってる。
例えば、形式的な無駄関数呼び出しがありまくったりする。
しかしそれらはコンパイラが最適化で抜いてくれるので、彼らはそれでよしとしている。
C++erの最優先はオブジェクトコードであって、ソースコードではないんだな。
無駄に回りくどくなったソースを見せられても困るんだが。

しかし考えてみれば、テンプレートなんて所詮はコピペだから、機械的に吐き出すのは極めて簡単だ。
人間がゴリゴリテンプレートを書くのではなく、
自動コード生成前提で、そのために基本ベタ書き、ってのは逆転の発想だがありだろう。
いや正確に言うと、Cのマクロの基本はコピペ的使い方だから回帰か？
とはいえCのマクロもC++のテンプレートも濫用が過ぎてるのは事実だ。
ベタなコードを自動生成してしまえ、ってのはありだろう。

**デフォルトの名無しさん** · 2017/11/14(火) 02:35:07.63

go generateは以下を見る限り追記だけかな？
https://blog.golang.org/generate
https://techblog.haroid.io/go-generate/
https://qiita.com/vvakame/items/6719b3c90dfaa8220e44
これはちょっと回りくどい。go fmt が上書きなんだから、go generate も上書きでいい。
具体的に欲しいのは、MarshalJSONではなく、構造体にJSONタグを追記する機能なのだから。
つまり、
type myStruct struct {
SomeProp int
}
を
type myStruct struct {
SomeProp int `json:"someProp"`
}
に上書き、だ。上書きが怖いのならビルドディレクトリを分ければいいだけでね。

> コード生成するコードを書くための仕組みがもっと簡単になればかなり使い勝手が良くなる。
俺は go generate が別パッケージを呼び出すのが気に入らないね。
とはいえ、自動生成用のコードなんてその場に埋め込まれても困るのも事実だが。
しかしjsonの部分は明らかに糞なんだし、公式で以下のとか用意しとけよなマジで。

元ソース
type myStruct struct { //go:maintain jsonTag -type=lowerCamel
SomeProp int
}
を、
type myStruct struct { //go:maintain jsonTag -type=lowerCamel
SomeProp int `json:"someProp"`
}
にビルドの度に自動的に maintain する、とか。

あ · 2017/11/14(火) 08:17:29.04

上書きしない理由は、本来想定された用途がinterfaceを実装すべくレシーバをもった関数を生やすためだろ。
同一パッケージなら別ファイルで良いんだから。

こりゃ、2にもジェネリクス入るか微妙だな。
欲しい欲しいて声が挙がっても、要らんだろと言われ続けてるのがなんでかわかったわ。
既存機能すら理解してない奴らが欲しいって言ってるのか9割なんだろうな。

あ · 2017/11/14(火) 08:19:24.88

そもそも、「ジェネレータ」なんだから、既存のものを上書きするものでないのは自明だろ。
新しいソースをジェネレートすんだよ。

**デフォルトの名無しさん** · 2017/11/15(水) 23:10:48.87

>>28
>>37
韓国人死ね

あ · 2017/11/15(水) 23:31:53.99

>>99
純然たる日本人だよ、たどれる範囲では。
日本語が解りにくいみたいなそういう言いがかりはナンセンス。
そもそも解りにくい日本語を喋れるのは日本人だけだ。
解りにくい○語を話せるのはネイティブ○語話者だけと大きくも言える。

韓国人が日本語の語順が不安定な部分使ってニュアンス出したりとか、逆にきちんと定義されてる言葉の使い分け使って煽れる訳ねえじゃん。
その結果例え解りにくいものになったとしても、あとから学んだ言葉が不得手な場合の解りにくさとは全く違う読みにくさが生まれる。

英語少々喋れても、口喧嘩はできなかったり嫌味が言えないのと同じようなもん。

**デフォルトの名無しさん** · 2017/11/15(水) 23:48:19.81

>>100
> 解りにくい○語を話せるのはネイティブ○語話者だけと大きくも言える。
そんなわけねえだろドアホ

韓国人はマジで死ね

あ · 2017/11/16(木) 00:49:28.81

>>101
理屈が通じないなんて、まさかそんな日本人、現代人離れした感覚持ってるとは思わなんだ。
説明には充分注意を払わないといかんな。

**デフォルトの名無しさん** · 2017/11/16(木) 15:41:38.90

ASTの話題にちょうどいい動画見つけた。
エディタの壁を越えるGoの開発ツールの文化と作成法
https://www.youtube.com/watch?v=j57mMsJP37Y

**デフォルトの名無しさん** · 2017/11/16(木) 15:56:24.67

>>96
go generate自体はただのコマンド実行なんだから
上書きするコマンドを実行させちゃえばいいと思う。
作法としてNGってことなんかな。

**デフォルトの名無しさん** · 2017/11/16(木) 16:29:37.83

windowsで開発していると
goで作成した実行ファイルを実行するたびにアンチウイルスソフトのAVGが起動して
スキャンを始めます
goがコンパイルしたプログラムをスキャン対象外にする
なんてことは出来なそうですし、スキャンをオフにするしかないのでしょうか？

**デフォルトの名無しさん** · 2017/11/16(木) 16:36:26.26

>>105
gopath以下を検索対象外すればいいのでは？

**デフォルトの名無しさん** · 2017/11/16(木) 23:07:32.53

GO言語って何に使うの？

**デフォルトの名無しさん** · 2017/11/16(木) 23:43:33.13

>>103
23:00- からのIDの話とか、やっぱり筋が悪いと思うぞ。
・IDが大文字じゃないとダメだからタグをつけよう！(Go信者)
・IDが大文字じゃないといけないのがダメだろ。それでソース変更とか頭おかしい(C派)
Linusが嫌っているのはこういったどうでもいいことに余計に手間がかかることであって。

これはGoの仕様が糞だから発生した手間でしかない。
IDが大文字になったら見やすくなり、バグが減るのか？そんなわけない。
ここで必要なのは、lintのwarningを抑止するコメント、 //golint: ignore case `Id` 等であって、
余計なタグを増やすスクリプトではない。
ここら辺の「全部ベタ書きで個別指定しろ」という点がGoの思想の糞な所だ。
次はこれらによって個別に記述されたタグの整合性をチェックするスクリプトが必要になり、以降無限ループだね。
そうではなく、1箇所にしか書かないから不整合が発生し得ない、というのがOAOOなりDRYだというのに。

Goは人間がソースコードをメンテすると仮定してない。それでついてこれる奴が多いかどうかだね。
俺は無理だと思うが。

関数型が急速にポシャった感があるのは、馬鹿しかいなかったからだと思っている。
Goもそんな感じがする。C++についていけない馬鹿しかいない感が酷い。
上記だって目の付け所が反対だ。
linterをフォークして余計な手間が必要ないようにコメント拡張を加え、どちらが支持されるか勝負するのがまっとうだろ。
プログラマとして未熟な奴がGoを支持してる感が酷い。
C++も一応スマポを使えばGC的なプログラミングは行える。
(俺はあれは糞だと思うし、普通にGC言語使えよ馬鹿なのか？としか思わないが)

というか、Goは完全にスタートポイントがCで、C++/C#/Javaじゃないね。
だからC++等がやらかしたことを再現している。歴史に学ばず、経験に学ぼうとしている。
多分Goはポシャる。
今必要なのは肥大化しすぎてデザパタ厨のような「目的と手段を履き違えた馬鹿」を生み出したOOPを整理することであって、
はっきり言ってこの「大文字な構造体メンバにタグをつける」スクリプトなんて既にGo厨化してる。
やることを「減らす」スクリプトを書かなければいけないのに、「増やす」スクリプト書いてどうするんだよ、というね。

あ · 2017/11/17(金) 00:01:51.83

また斜め上の事言ってんのか。

**デフォルトの名無しさん** · 2017/11/17(金) 00:20:20.06

96にあるようにjson用に構造体にタグを機械的に打つツールは既にあるよ。

もちろんそういうことを知らなきゃ、
冗長なコードを手打ちする羽目になるけど、
知らなきゃ苦労するのはどの言語だって同じだし。

俺はむしろgoの構文のシンプルさって人間が修正するだけじゃなく、機械が処理するためでもあるんだなって感動したけど。

**デフォルトの名無しさん** · 2017/11/17(金) 00:28:42.55

>>108
あ、id の話か。
どうだろうね。IDでもidでもIdでも良いとしたら、つまりプロジェクトとして構文規約を作ろうってことになるよね。

それを始まりとして、プロジェクトによってコードの書き方が違うという分断化が起きる。

**デフォルトの名無しさん** · 2017/11/17(金) 00:37:38.60

>>110
Goの言語仕様が糞でなければ、そんなことは最初からする必要が無い。
Go信者にはこの観点がまるでない。
100歩譲って、jsonのEncode関数にスイッチがあってもいい。
しかしそれもないだろ。

Goの仕様なんてかなり糞で、こんなのを教科書にしてたら勘違いすると思うぞ。(>>43)
いちいちやってることが回りくどすぎる。K&Rと正反対だ。
（ただしK&Rはこれまたさっぱりしすぎているが）

とはいえ、ここは合意を形成する必要はない。
俺はGoは糞だと思うし、今後使うことは多分ないだろう。
君がGoに賭けるのはもちろん自由だし、そうすればいい。

あ · 2017/11/17(金) 00:44:31.04

>>112
なら黙って去れよ。つかえねえなぁ。

そもそも、単語単位で命名規則決まってるからlint簡単だし宗教戦争起きないようにしてるんじゃねえか。
go runしか走らして無いんじゃねえの？

**デフォルトの名無しさん** · 2017/11/17(金) 01:05:30.05

>>112
所詮はツールだから宗教戦争にしかならないのも確か。
vim vs emacs的な。

ちなみに一番理想的だと思ってる言語は何なのか知りたい。

俺自身はgoの言語仕様に欠点があるのは認めるよ。
でも、どの言語もコモディ化で割と似たような言語仕様になる中、独自性があって、素敵だとも思う。
何か言語設計者に信念を感じるんだよね。
ジェネリクスが熱心に要望されてる中、
未だに入れないのも何かもっと新しい手法を編み出そうとしてるんじゃないかと妄想してる。

phpなんか、片っ端から言語仕様足しまくってるし。動的言語のくせにinterface入れてみたりとか。

でも確かに最初に触る言語をgoにするのは危険かも知れない。

**デフォルトの名無しさん** · 2017/11/17(金) 01:23:31.18

あとgoはast周りが充実してるってことは究極自分の理想言語を作ってgoのエコシステムを乗っ取るって手もあるよね。

rubyの作者が作ろうとしてるstreemって言語もgoをベースに作ろうとしてると聞いたし

**デフォルトの名無しさん** · 2017/11/17(金) 06:29:15.43

まだ味見してるのかｗ

**デフォルトの名無しさん** · 2017/11/17(金) 09:32:12.45

Goの欠点と言えば、一度使い込むと他の言語で書きたく無くなる事だな
と言うか他をリーディングする時点でストレスを感じるようになる
Goならこう書いてこの辺りを並列したい、と読みながらGo脳になっちゃう

**デフォルトの名無しさん** · 2017/11/17(金) 10:11:41.49

null安全な言語じゃないのはなんとかならないかな。
後付で実装するのは無理があるよね。下位互換性重視する姿勢みたいだし。

あ · 2017/11/17(金) 12:49:59.91

nullはなぁ。
unsafe使うともう闇過ぎるし、cgoとかでさえnullがある他の言語とやりとりできるし、
Kotlinみたいにvarに対してvalとか書けるようにしていったとしても、どのみち誰かが!(に相当するもの)で壊すかもしれない事に怯えるハメになるから、
最初から「nilかもしれないからチェック」って意識付けをさせてるのかもしれん。
タプルでerror帰ってくるのを無視するには_が必要みたいな感じで。

**デフォルトの名無しさん** · 2017/11/17(金) 20:47:26.26

アンケートを募集してるみたい。
https://blog.golang.org/survey2017

とりあえずnil safeな言語にしてくれってお願いしてみた

**デフォルトの名無しさん** · 2017/11/17(金) 22:49:38.93

>>114
宗教戦争は結局自転車置き場の議論と同種で、馬鹿が無理に参加するからだ。
その点ではC++の割り切り、「ソースコードに過度の美を求めず、オブジェクトコードで勝負」ってのは正しいと思うし、
go fmt ってのもありだと思うが。

Goがまずい点は、後発なのに誰にも合わせる気がない点だ。
UpperCamelはC++以来(だと思う）既に30年「クラス」として使われてきており、他言語も全てそうなのに、
「public」と勝手に規定してしまった。このためにjsonがUpperCamelになってしまうわけだが、
これまた世の中JSONで回り始めて10年以上経ち、大体lowerCamelが使われている状況で、スイッチもつける気無いだろ。
略号は全部大文字？それは言われなくても大体そうだし、違反してたとしてもソース改変して再テストする価値はない。
そんなにマメにソースを改変したければ、ユニットテストではなく、形式検証ツールを提供するべきなんだよ。

> でも、どの言語もコモディ化で割と似たような言語仕様になる中、
結局ソフトウェア技術も成熟しつつあるってことだよ。
どう書くべきか、何をやってはいけないのか大体わかってきた。

> 独自性があって、素敵だとも思う。
ないね。独自性ってのはHaskellの「全面遅延評価」みたいなのを言うんだよ。
俺はHaskellが1990製だと知って驚いたが、それ程の独自性があれば20年後に話題になる可能性もあるということ。
Goには独自性なんて無い。一度廃れれば終わる言語だ。
「新機能」といえる物が全くないだろ。むしろ「ちょうどいい頃合」を目指している言語だ。
悪く言えば、全てにおいて中途半端でしかない。

> phpなんか、片っ端から言語仕様足しまくってるし。動的言語のくせにinterface入れてみたりとか。
PHPはミクロな点でゴミだが、マクロな点には多分ほぼ問題がない。（というほど試してないが、今のところそう感じる）
具体的に言うと、引数の順が統一されてなかったり、引数にすべきものを別名関数にしてたりとか、
そういう「1行内」の部分でいちいち引っかかり、ストレスが溜まるものの、
Goみたいに「言語仕様的に3回書かないと無理」みたいな構造的問題は（多分）ない。

**デフォルトの名無しさん** · 2017/11/17(金) 22:53:03.56

> でも確かに最初に触る言語をgoにするのは危険かも知れない。
「いちいち書くことを良し」とするのはまずい。
(昔の意味での)コピペプログラム推奨になってしまう。
これを嫌って、「いちいちスクリプトで整形」なら確かにありなんだけど、実際は書いたほうが早いから書くでしょ。
初心者がスクリプトを書けるわけも無いしね。
メタプログラミング「推奨」ならいいんだけど、メタプログラミング「必須」ってのは多分間違いなんだよ。

**デフォルトの名無しさん** · 2017/11/17(金) 22:53:37.38

> ちなみに一番理想的だと思ってる言語は何なのか知りたい。
(俺は言語コレクターではないのでバリバリに使ってる言語は数えるほどしかなく、偏っているかもしれんが）
ないね。俺は「全ての状況で使える言語」が必要とは思ってない。使い分ければいいだけだ。
そして現状の棲み分け状況を基本的に肯定的に捉える。それは集合知としての結論である、という見方だから。
C++が再統一を目指して全機能を入れてる感があるが、ならまずGC入れろよ、と思うし。

最近気に入っているのはJavaScriptだ。だからAtomだElectronだという気持ちはすごくよく分かる。
・手抜きが出来るわりに動作が速い
・プログラマの邪魔をしない仕様（自分の足を撃てる仕様)
・HTML/CSS
なのがいい。最初は文法が簡素すぎて「こんなんでいいのか？」と思ったが、
慣れると最近のOOPは相当無駄（冗長）なことをやっていたのだなあと実感した。

ただしJavaScriptは言語そのものではなく状況が糞過ぎる。
Web上に間違った情報が氾濫しているし、（これはGoもだが）
マトモにプログラミングできない馬鹿が偉そうに薀蓄たれてるところがどうしようもない。それで馬鹿が再生産されてる。
ただしこれについてはPHPerが原因だと見ている。
PHPerが（CSSの）classを正しく使ったHTMLを書けないから、JavaScripterがそれ以上になれない。
classさえ正しく配置されていれば、圧倒的に楽にJavaScriptを書けることを多分彼らは知らない。
先生が間違ったことを教えるから生徒が上達できない状況だ。
だからJavaScripterは基本的に勘違いしてて、自分が至ってない事を自覚できてない。これが本当にどうしようもない。
PHPerは自分が至らないことについては自覚できてる。
彼らはだいぶ馬鹿にされているらしいが、この点はJavaScripterよりだいぶマシ。

あと、JavaScriptは標準化委員会がマジで糞だ。
Mapに[]が使えず、またsizeとlengthが混ざっていてジェネリック出来ないとか、あれは標準化委員がコード書いて無い。
（ただしこれについては直せる範囲だからさっさと直せ、と思う）

**デフォルトの名無しさん** · 2017/11/17(金) 22:54:01.59

Goはこの辺さらに酷い。JSONの仕様とか、ありえないだろ。
あれはJSONモジュールを作った奴がJSON使ってないんだよ。完全に例の漫画になってる。;
https://twitter.com/frontend_ux/status/692369282626383873
UpperCamelでJSONしてるサイトなんてない。1回使えば分かる。
逆に言えば、1回も使ってない奴が作るからこんなことになる。
そしてそれを弾けない標準化委員会も相当低レベルだと分かる。
他モジュールも相当なゴミが混ざっていると思うぜ。Goがいい教材だと思う奴は程度が低いだけだ。(>>43)
そしてJavaScriptとは違ってGoの間違いは救いようがないレベルだからどうしようもない。

あと俺が気づいた範囲だと、SQLite3はPHPでもNodeでもopenするときにReadOnlyかReadWriteを指定するのだが、
Goのdatabase/sqlではこの指定が出来ない。
俺にはこれがパフォーマンス等にどう影響するのかはよく分からないが、
根本的に間違ってるんじゃないか？と思うよ。
知らない奴/使ってない奴が仕様策定/基本モジュール提供をしてはいけない。
これも多分、普段SQLite使ってない奴が仕様策定してるからこんなことになってるんだよ。
Web系はよくも悪しくもここら辺に躊躇が無い(馬鹿が自重しない)が、結果的にゴミがゴミを再生産しているのはよく見かける。
しかも使ってる連中もそれに気づけないほど馬鹿なんだろ。だからマンセーするとかおかしなことになる。
俺はPHPもそんなに試してないが、Goはその一部分を移植しただけでPHPより問題山積だ。

>>115
> 究極自分の理想言語を作ってgoのエコシステムを乗っ取るって手もあるよね
Goじゃなくて普通はCを乗っ取るだろ。Goも最初はそうだし、今も半分そうだろ。
或いは他言語みたいにJavaのVMに乗ってしまうか。
Goありきなのは既に信者だからだよ。

> streem
何用これ？streemでconcurrency？shellとか言っているし、何に使えるのかよく分からん。

**デフォルトの名無しさん** · 2017/11/17(金) 23:32:31.38

実装は他人に任せてシステム設計に専念する方が良いんじゃないかｗ

あ · 2017/11/17(金) 23:44:12.50

大演説ご苦労だな。
アッパーキャメルも、型が後ろにつくのも、アンダースコアを避けるのも、大文字の定数を避けるのも、Pascalじゃん。
:=で普通は気づくが。

**デフォルトの名無しさん** · 2017/11/18(土) 00:22:54.69

>>124

Uniform Resource Identifiers
https://www.sqlite.org/uri.html

に書いてあるURIフォーマットを使えば良いんじゃないかな。

db, err := sql.Open("sqlite3", "file:hoge.sqlite3?mode=ro")

みたいな。

**デフォルトの名無しさん** · 2017/11/18(土) 00:36:38.80

自宅の裏庭から油田が出た辺りまでしか読めなかった

あ · 2017/11/18(土) 00:56:47.02

JSONがアッパーキャメルじゃない？でもGoはアッパーキャメルだ、だから歪んでる？

ならなんでjsonパッケージにtags.goがあるんだよww

間違いじゃねえよ、そのままタグ書かずにMarshalするからだろ。
ホントドキュメント読まねえやつだな。
「一回間違って使えば誤解する」の間違いだろ。

database/sqlに、ファイルのオープンに依存する関数あるわけねえじゃん。だってsqlのパッケージなのに。
ドライバにやらせろよ。

**デフォルトの名無しさん** · 2017/11/18(土) 01:04:13.32

>>127
それは全ての環境で使える物ではない。

Goの連中は（というかWeb系一般にそうだが)この手の未熟な奴が仕切って暴走しているのをよく見かける。
新しい言語は老害がいなくて心地よいのだと思うが、
結果的に若い奴らが浅知恵で馬鹿なことを繰り返しているだけになっている。

例えばxampp(今年の9月の最新版だったと思う）にバンドルされている物は3.7.6.3でそれは使えない。
なお同じxamppのPHPのSQLiteモジュールは3.15.1で、つまりPHP経由なら使える。（ちなみに最新版は3.21.0)
俺もこのxamppのバージョン管理は奇妙だと思うが、
これもxamppの連中が「一番無難なバージョン」を選んだからこそであって、問題ないのならそのまま使うのが無難だ。
こういうのがあるから、「最新版では要らないから」と早合点して勝手に仕様を削っていいものではないんだよ。
ここら辺がGo（というかWeb系全般）は拙い。プログラミングの経験が全般的に浅く、物事を知らないからだ。
JSONの件も、マジで1回でも使えばどこもUpperCamelなんて使って無いと分かる。あの仕様は本当にありえない。
作っただけ、動くだけで満足している連中しかいないからこういうことが繰り返される。
そして使えない物が再生産されまくってる。
だからWeb系も全般的に馬鹿にされるわけでね。Goも間違いなく同レベルだ。

あ · 2017/11/18(土) 01:54:07.84

>>130
Goでもアッパーキャメルで出すもんじゃねえよ。
ドキュメントに書いてあるでしょ。
変数名が何故あの形かも書いてあるし、一度でもちゃんとfmtから順番にツールにコード通していけば小言が読めただろうに。

xamppは一番無難な初期iniで使うのかねえ、ベルリンで。

**デフォルトの名無しさん** · 2017/11/18(土) 01:56:49.03

要は SQLite の URI format を知らなかったんだろ？

あ · 2017/11/18(土) 02:16:00.03

そもそもsqlパッケージ自体使い方わかってないんだろ。godoc読んだ形跡がここまで無いのも凄い。

あ · 2017/11/18(土) 02:57:09.69

略語が全部大文字どころか、こまごまいちいち指定してこられる事のメリットは、あとからインターフェイス書くときだよ。
関数名のブレようが無いでしょ。

**デフォルトの名無しさん** · 2017/11/18(土) 10:10:59.68

>>121
>> でも、どの言語もコモディ化で割と似たような言語仕様になる中、
>結局ソフトウェア技術も成熟しつつあるってことだよ。
>どう書くべきか、何をやってはいけないのか大体わかってきた。

ここに俺は異を唱えたい。
言語の方向性は歴史的な圧力が絶対あると思う。
仕方なく大多数が採用したから新言語でも採用したみたいな。

例えばclassとstructってなんで２つあるの？って思ったことない？
cの頃はstructはただの構造体だった。もちろんcにはオブジェクト指向の機能はないからstructにメソッドは生やせない。でもその後後発の言語はstructを拡張するのではなくclassを作った。でもsturctはそのまま残した。
swiftでも残り続けてる。値型と参照型の違いということで残したみたいだね。
意味がわかんない。

例外処理
例外が発生する可能性がある関数とない関数でコンテキストが大きく変わる。
そもそも例外処理って横着機能でしかないと思うんだけど。

そんなわけでgoはこの歴史的な圧力に対して異を唱えている。
それは本当に正しいのか！って。

**デフォルトの名無しさん** · 2017/11/18(土) 10:46:35.60

>>132
それはその通り。俺は知らなかった。しかし、PHPとNodeではそれでも何も問題なく使えたのがミソなんだよ。

「Goは覚えることが少ない」なんて言っているのはプログラミング経験が浅い馬鹿で、表面しか見えないから。
或いは、他言語を使えないからGoの問題に気づけないだけ。
実際はこの手のGo特有事例（方言）がものすごく多い。(これについてはPHPより酷い)
だから常識的にプログラミングするといちいち引っかかってしまう。熟練者にとって生産性が著しく悪い。
（ところが他言語を全く知らないド素人にとっては生産性が悪くないのがミソ）

「C++はプログラマを育てる言語だ」と禿は言っていて、実際にC++の連中は育っている感がある。
俺はJavaScriptもかなりいい言語だと思うが、こちらは壊滅的なほどに育ってない。
Goはどうか？俺はGoは間違った方向に育つ（使えない奴が出来る）言語だと思うよ。色々おかしいから。
それでもGoを信じるのは君の自由だが。

新しい言語には老害がいなくて心地よいのだろうが、それは達人もいないことを意味する。
色々仕様がおかしいのは、つまりそれにも気づけない馬鹿しかいないことの証左だ。
(上記のように、熟練者除けを装備してもいるし)
K&Rの評価が異常に高いのは、さらっと書いてあるコードの品質がとんでもなく高いからでもある。
有名なのはmallocだが。
http://www.wdic.org/w/TECH/malloc
そういうコードは今のGoには無いと断言できるね。
今のGoはお山の大将が出来ることがうれしいだけの馬鹿しかいない。だからこんな糞仕様がまかり通る。

それでもGoを選ぶのは君らの自由だが、当然その責任も数年後に負うことになる。
それは自己責任だから、君らが思うようにやればいい。
責任を負うことの出来ない俺が「止めろ」ってのもおかしな話だし。
ただ、俺がもし学校の先生だったら、この言語を教えていいのか？と躊躇する言語だよGoは。

とはいえ、成否は俺には分からんね。
俺達がゆとりに死んで欲しいと思っているのと同様、ゆとりも老害に死んで欲しいと思っているのなら、
ゆとり専用言語で棲み分けするのもいい手だ。Goはここに位置できる。
そこで好き勝手やってみるのも悪いことではない。それでどっちが残るか勝負すればいい。

**デフォルトの名無しさん** · 2017/11/18(土) 11:10:29.94

ま、味見レベルでは何も分からない、ってオチだね。

**デフォルトの名無しさん** · 2017/11/18(土) 11:20:17.67

>>135
> 例えばclassとstructってなんで２つあるの？って思ったことない？
それは歴史的「圧力」というよりはただの後方互換性だ。
冗長といえばそうだが、かといって削除するほどのことでもない、ということ。
C++のstructとclassなんて、デフォがpublicかprivateかの違いしかない。
当然、明確な使い分けはない。では実際どうするかというと、
クラスとして「主体的に動作をする」のか、データとして「外部から操作をされる」のか、で分けるのが一般的か？
つまり、お前らが言うOOPか手続きかで分ける。
しかしこれは、初心者にとっては意味不明すぎるのも事実。
おかしいだろ！整理しろ！というのはごもっとも。Goがstructだけに絞ったのも、別段問題ない。
ただ、これで生産性が上がるわけも無く、だから他言語では放置されてる。
なんつーか、どうでもいいわな、というところ。

> そもそも例外処理って横着機能でしかないと思うんだけど。
その通りだが、要するに、よく使う機能だから言語側にサポートを入れた、というだけ。
無ければ伝言ゲームをする羽目になる。
自前のオレオレ伝言ゲーム構造体よりは、言語側で規定してて言語機能に入っているほうがマシだろ。

ただここに至ってGoの実装はよく分からんね。
あれは自分で「毎回チェック」してthrowするのが必要なだけで、panicした後は従来の例外の様に動く。
catch/finallyでグダグダ書くよりdeferしろってのは一理あるが、
例外を使いたがっている奴はそもそもの「毎回チェック」を書きたく無いからだろ。
Goの例外がどういった層に喜ばれるのか（どういうメリットがあるのか）よく分からん。

**デフォルトの名無しさん** · 2017/11/18(土) 11:50:08.52

>>136
同意する部分は多々あるよ。

>「Goは覚えることが少ない」なんて言っている
>実際はこの手のGo特有事例（方言）がものすごく多い

シンプルさを意図して実際は中味の複雑さがにじみ出ることは多々ある。
nilでも型があるとかね
https://golang.org/doc/faq#nil_error

だから蟻地獄的なものはあるかも。

>「C++はプログラマを育てる言語だ」と禿は言っていて、実際にC++の連中は育っている感がある。
これは知らんかった。禿って誰のこと？
正直C++勢と会ったことはない。web系と断絶してる感じする
なんで育てる言語がC++なの

>だから常識的にプログラミングするといちいち引っかかってしまう。熟練者にとって生産性が著しく悪い。
>（ところが他言語を全く知らないド素人にとっては生産性が悪くないのがミソ）

もしかしてIDE使ってないの？vscodeとか。
俺もTypeScriptとかいろいろな言語を使ってるけど
言語仕様で引っかかってもその場でIDEが指摘してくれるから、生産性に問題は起きない。

**デフォルトの名無しさん** · 2017/11/18(土) 11:50:17.43

そもそも第一言語としてGoだけ使うって輩はないだろ。多様性を楽しむくらいの余裕があってもいいと思うけど。
関数型も書いてて楽しい。Elixirとか。Haskellはちょっと挫折した。

ちょっとぐぐってみたら面白い記事を見つけた
http://gihyo.jp/news/report/01/GoCon2014Autumn/0001

言語が思想に影響するという説（サピア＝ウォーフの仮設）
があるからあえてGoにはあなたが方言と言ってる違いを設けて
多様性を確保したいらしい。

あ · 2017/11/18(土) 11:50:28.50

>>138
ヒープに値が乗るかポインタが乗るかで全然違うだろ。構造体とクラスは。
後方互換製でも何でもなく、使い分けとるわ。

**デフォルトの名無しさん** · 2017/11/18(土) 12:55:59.36

>>141
概念としてそれをclassとstructに分ける必要あるかって話。

あ · 2017/11/18(土) 13:37:23.69

>>142
使い分けてるんだから、必要あるってわかるだろ。
ベクトルなんかをそこそこの量処理したいとき、そのベクトルを表すものがクラスか構造体かでかなり違う。
彼が言ってるような歴史を辿ってきたJavaやC#みたいなGCを持つ言語だと、GC対象か否かという点でもメチャクチャ違う。

**デフォルトの名無しさん** · 2017/11/18(土) 14:51:14.87

>>140
> 同氏は，Go言語はスケーラブルなクラウドソフトウェアのために設計されたきれいな手続き型言語であると述べていました。
あーなるほどね。反OOPか。

Cが生まれて50年弱経ち、ソフトウェアテクニックってのはほぼ固まりつつある。
その状況で若い連中が何か新しいことを思いつき、しかしそれを老害が腐してそのアイデアが埋没してしまうようなら、
それは勿体無いから、若い連中用のプレイグラウンドはあるべきだ。Goはそれに成り得るだろう。
ただし、そこで試されるアイデアの大半は既に誰かが試してゴミだったからポシャった物であり、
つまり「歴史」ではなく「経験」に学びたい若者が「車輪の再開発」をする場でしかないわけだが、
それもまあ必要悪というか、更なる発展の芽を探す為には仕方ないのかもしれんね。
ただそれで無駄言語に傾倒することになる若者は哀れだが、自己責任だから致し方なしか。

心配せずともGo言語で何かめぼしい成果が出れば、C++他は数年後には確実にパクる。
正直、遅延評価を既存言語機能だけで丸パク出来たのには驚かされた。templeteの汎用性を俺は舐めてた。
Go言語で出る成果でC++がパクれない物はたぶんありえない。もともと似てるし。

OOPが暴走気味なのは事実としても、現実解としてOOPしかないからみんなOOPしてるわけで、
そこに刃向かうのはもちろん自由だが、それでpackageが解なの？うーん、といったところか。
それならCでいいじゃん、になってしまうし。

**デフォルトの名無しさん** · 2017/11/18(土) 14:55:03.12

>>139
> 禿って誰のこと？
禿＝ストロウストラップ＝C++作者＝https://ja.wikipedia.org/wiki/%E3%83%93%E3%83%A3%E3%83%BC%E3%83%8D%E3%83%BB%E3%82%B9%E3%83%88%E3%83%AD%E3%83%B4%E3%82%B9%E3%83%88%E3%83%AB%E3%83%83%E3%83%97#/media/File:BjarneStroustrup.jpg
> 正直C++勢と会ったことはない。web系と断絶してる感じする
話してみたいのならスレにでもどうぞ。それがネットの正しい使い方でもある。
ただあいつらの話題って重箱の隅どころでは無いからなあ、、、
> なんで育てる言語がC++なの
知らん。禿が著書でそう主張している。そして確かにそんな感じだ。
おそらくC++の奴らは自分でいろいろ試して、結果的にいろいろひどい目に遭うからだよ。（追体験）
例えば、「グローバルガー」とか言うWeb系の奴、実際にグローバルが問題になるほどの規模のコードを書いたことがないだろ。
そういう、薄っぺらい馬鹿が威張っている感がC++erにはない。
C++erの場合は、実際に「便利だから」グローバルを使い、結果的に苦労して、
どの規模の辺りからグローバルはやばいかを知った後で話をしている。
そういう、地に足が着いている感がある。

一方Web系は「経験に学ぶのは愚者。俺達は歴史に学ぶ」と言い、この手の追体験を拒む。
そしてグローバルガーと連呼したりするが、実際にはその規模ならどうでもいい場合が殆どだ。
ここら辺が地に足が着いてない。教科書（歴史）を妄信してる感ありあり。
しかしそのわりにGoで経験に学ぼうとしているのは、結局OOP流に嫌気が差しており、自由にやりたいだけだろう。
（まあ気持ちは分からなくもない。JavaのOOPとか完全にやりすぎだと思うし）
それが自分達が言っている「経験に学ぶ愚者」に該当する自己矛盾に気づかないのが愚かなところだが、
Web系の連中にとっては経験こそが足りないから、色々やってみるのもいいとは思う。

**デフォルトの名無しさん** · 2017/11/18(土) 14:55:54.32

今はソフトウェア技術の規模が微妙な時期なんだよ。
数学のように「全ての分野を網羅するには人生は短すぎる」程の広がりはなく、
これまでの全ての問題を一つ一つ追体験するのも無理ではない。グローバルしかり、ポインタしかり。
もちろんそれは無駄だとして「歴史」に学ぶのも一つの手だ。
ただし実体験と教科書の知識だけでは重みが違うから、そこらへんがWeb系全般のフワフワ感につながる。
とはいえ、今後ともソフトウェア技術は肥大化する一方だから、今後の学び方としてはWeb系流の方が正しい。
ただ、今はまだそのシンギュラリティに到達しておらず、C++流の学び方も成立するってだけで。

> IDE
文法が分からない＝指摘されてもどう直してよいのか分からない、のだからそれ以前だよ。
ただしvscodeだとC#流の「；が抜けています。追加しますか？はい／いいえ」で行けたのかな？
それなら入れておくべきだったかも。実際はemacs+flyCheckでやった。
ただし既にPHPとNodeで動くコードをGoに移植だから、引っかかるのは全てSyntax/API/Go方言なんだが。

> だから蟻地獄的なものはあるかも
Goは多分、思想がGoだけで完結してるんだよ。
「驚き最小」ってのはGoの世界ではそうなのかもしれんが、
nilがタプル（というよりポインタが全部タプルか？）だとは普通のプログラマは思わないから
そこは「驚き最大」だ。
それならそれでいいとして、だったら最初にそれを言え、なんだが。

Goは割と想定外のところでバグるんだよ。
この点、実はJavaScriptはC的で、文法だけ抑えたらあとは、あー、はいはい、で行けた。
だから俺（というかC使い）にはJavaScriptは相性がいい、というのはある。
Goは妙なところでGoだけの世界を作ってるだろ。これが吉と出るか凶と出るか。

あ · 2017/11/18(土) 15:31:38.82

俺の長文もこんな感じなのかなぁ、注意せな。

**デフォルトの名無しさん** · 2017/11/18(土) 16:28:17.34

>>146
>Goは割と想定外のところでバグるんだよ。
>この点、実はJavaScriptはC的で、文法だけ抑えたらあとは、あー、はいはい、で行けた。
>だから俺（というかC使い）にはJavaScriptは相性がいい、というのはある。

どういうコードでバグったの？

**デフォルトの名無しさん** · 2017/11/18(土) 18:17:51.34

>>148
そりゃ該当するのは君の言うnilとかだよ。
俺の場合は何度も言っているがJSONだ。

問題なのはこの原因が「Goの特殊仕様」であって、「俺の未熟な文法理解」ではないこと。
文法は一通りやれば終わるが、特殊仕様は確認しないと分からず、その都度の対応になる。
新しい領域に踏み込んだら毎回地雷原を歩かされるようなもので、これでは生産性なんて上がらない。
だからプログラミング言語には統一性/一貫性が重要だと言われるわけでね。

C++は今は何でもかんでも仕様に取り入れてる。
あれがいいかどうかはさておき、既に言ったように、Goで何か結果が出れば必ずC++は取り込む。
だったら俺はそれでいいや、という感じだね。

先頭を走らなきゃヤダ！ならGoに集まっている連中とワイワイやるのもいいのではないかな。
ただ、仕様を見る限り面子には非力感がありまくりだが。
そして当然、結果はそう簡単に出ないし、出ても簡単にパクられる。
それも覚悟の上でがんばれ、ってとこだね。

**デフォルトの名無しさん** · 2017/11/18(土) 23:55:49.43

>>149
そんなの言語毎にハマりどころはあるから。
Goだけにある問題点みたいな言い方するから、
どんなのかと思った。
jsだってthisが何指してるかわからなくなる問題とか、独特のハマりどころはあるでしょ。

jsonの問題もjwgとか使えば自動的に理想的なtag付けしてくれるんで。使ってみては？

あ · 2017/11/19(日) 00:27:33.12

ドキュメントに書いてあることができないのが、何で未熟な文法理解に何故起因しないかわからん。
文法理解してるつもりなのに書けないのなら、語彙も足りないんだろ。
ってかドキュメント読めよなぁ。
特に難しい事もないじゃん。
なんか読めない理由でもあんのかね。

**デフォルトの名無しさん** · 2017/11/19(日) 00:31:17.32

>>150
いやGoだけだぞ。
正確に言うとC系(ハロワ系)はCに意図的に似せて作ってあるからこの辺で問題が生じることがない。
俺は関数型には深入りして無いからそっちは知らんが。

君がGoだけかなり特殊だと気づかないのは、他に比べる手持ちの言語が無いからだよ。
ただそれもGoの意図通りのようだし、
確かに他言語の経験者が大量流入すると独自進化できない、というのはごもっともだ。
ジェネリック使いたければ他言語を使え、Goはジェネリックよりいい解を探してみせる！というのもありだろう。
実際、彼らの意図通り、俺みたいなC系経験者にとってはGoは魅力的ではないし、ひとまず静観といったところだね。
上手くガラパゴス化して面白く変化できるかどうかだね。

> jsonの問題もjwgとか使えば自動的に理想的なtag付けしてくれるんで。使ってみては？
これは逆なんだよ。
書かないことこそが素晴らしい、というのが従来型言語であって、俺はそっちを支持する。
そうではなく、自動生成こそが正義、というのならそれはまあがんばってね、という感じだが、
それも結局「正しく自動生成できているか」確認しないといけないんだから、
書くのと比べてやること減ってないだろ。
なんかそこらへんの根本的なノリが違うんだよなあ。

なお、
> jsだってthisが何指してるかわからなくなる問題とか、独特のハマりどころはあるでしょ。
これは違う。あいつらはマトモにオブジェクト指向も出来ないくせに主張するからおかしなことになる。
普通に使えば obj.method なんだから、thisが何を指すかで戸惑うことなんてない。
逆に、それ以外でthisを使うからおかしなことになるのだが、それは根本的に間違ってるんだよ。
(ただし仕様上、関数ポインタにはいちいちbindする必要があるが、これはすればいいだけ)
JavaScriptのthisガーって言っている奴は間違いなく馬鹿だから、無視していい。
ただそいつらが過半数な感じがJavaScriptが終わってるところなんだが、、、、

あ · 2017/11/19(日) 00:34:49.76

なんで糖衣構文ではなく、アロー関数が出来たんだろうねぇ。

まぁ、言ったからには、静観してくれたら良いな。

**デフォルトの名無しさん** · 2017/11/19(日) 02:19:38.32

>>152
Goとjsで平等な視点で比較評価しているとは思えない点は目をつぶるとして

>それも結局「正しく自動生成できているか」確認しないといけないんだから、
>書くのと比べてやること減ってないだろ。

あなたの得意分野のCだって内部的にはプリプロセッサがコード生成してるけどそれを目視チェックしたこと無いよね。
隠蔽しているだけでコード生成を使ってるんだよ。

**デフォルトの名無しさん** · 2017/11/19(日) 02:37:25.16

コード生成を嫌ってるみたいだけど、そして理解もできるけど
静的言語が動的言語並の自由度を確保しようと思ったらコード生成は避けれないと思う。

例えばちょっと前にあったdatabaseとの接続もそう。
コンパイル前にスキーマを収集して型を作るのが静的言語における最適解。
それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。

でも、そもそもコード生成嫌わないで。
生成したコードをデバッグ時に参照できるというのは、バグの解決につながりやすい。
Cで複雑なマクロを組むとエラーがわかりづらくなるけど
プリプロセッサの出力を目視できるようにすると解決できたりする。

だから Goのコード生成もプリプロセッサのコード出力くらいに考えておけばいいと思う。

**デフォルトの名無しさん** · 2017/11/19(日) 04:15:36.04

嫌なら使わなければいい
気に入らないなら思いの丈をブログにでも書いてくれ
そろそろ黙れ

**デフォルトの名無しさん** · 2017/11/19(日) 11:03:39.31

技術的革新について話すだけのヤツはクソだ、黙って手を動かせ、と言った奴を
自分が触ったことのないテクノロジを批評するのは滑稽、と批判してみせた奴

こいつが、その素晴らしい技術でLinuxを超える何かを世の中に残せたのなら説得力が有るのだが…
結局何かしらの技術を語ってる奴は総じてクソなのは揺るがない

**デフォルトの名無しさん** · 2017/11/19(日) 14:16:27.55

>>154
いや俺はマクロは最小限(見りゃ分かる程度)しか使ってない。
そして自動生成を嫌っているのではなくて、手間が増えるのを嫌っている。

PHP, JavaScript：何も書かなくていい
Go：構造体を書き、タグ付けスクリプトを作成し、go generate してタグを付け、正しくタグがついているか確認　←　やること多過ぎ
Go：構造体を書き、タグを書く　←　これのほうがまだまし

>>155
そりゃ公平な評価にはならないよ。俺は既にC言語は十分使える状況なんだから。
そしてPHPとJavaScriptにはC系言語の常識が通用したからさほど苦労しなかったが、
Goはそうではなく、色々引っかかる。
ただこれはGo言語制作陣の意図通りだし、確かにいまさら互換言語を整備する意味はないんだよ。

> それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。
ちょっとこれは厳しすぎ、というか、若干誤解しているか？
(静的クラス機構による）動的型は型を失うわけではなく、一般的には「静的言語としてのメリットを失う」とはされない。
確かに間接呼び出しになる分だけ遅くはなるのだが、これを言うなら世の中のOOP言語は全部糞になる。
(動的言語の)動的型は毎回辞書引きが必要(map扱い)だから効率が悪いとされている。
Goのinterface{}はこれではない。

ちなみにGoのreflectionもC系とはちょっと感覚が違う。
jsonを吐くのにフィールド名が必要なら、普通はjsonモジュール内でreflectionするはずで、
それならpublic(先頭大文字)でなくとも全部取れるはずなんだよ。だからそれを期待してしまうわけ。
そして、あ、あれ？とれないの？みたいな事になる。
C的常識でGoを組んでると、この辺の予想外のところで引っかかる。いろいろ根本からして違うんだよ。
一方PHPだと、「下手糞がフレームワーク組みやがって」とは感じるけど、何でそうなるのかは分かるんだよ。
あっちはベースを共有してる感がある。
だから今の俺だとPHPの方がGoより生産性が高くなってしまうわけ。
しかしGo言語はC系言語出身者お断り仕様で計画通りなのだから、これはこれでいいんだよ。

**デフォルトの名無しさん** · 2017/11/19(日) 16:10:38.42

>>158
>> それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。
>ちょっとこれは厳しすぎ、というか、若干誤解しているか？

単純にIDE連携が静的言語としてのメリットって話
つまりコード補完する時にDBのカラム名が候補に出る状態にできるのが静的言語のメリット。
内部的に型を持つとかそういう話じゃない。

> Go：構造体を書き、タグ付けスクリプトを作成し、go generate してタグを付け、正しくタグがついているか確認　←　やること多過ぎ
じゃなくて
Go：構造体を書き、go genereteを実行する
だけ。正しくタグがついているか確認は不要。ツールを信頼してるから。Cのプリプロセッサを信頼するのと同じ。

**デフォルトの名無しさん** · 2017/11/29(水) 20:31:48.17

長文で会話するのやめろ

**デフォルトの名無しさん** · 2017/12/02(土) 01:31:21.45

aws lambdaに正式対応だから勉強してみるか

**デフォルトの名無しさん** · 2017/12/08(金) 02:34:03.21

外部ライブラリで
import "github.com/hoge/foobar"
みたいにリポジトリ指定みたいに書いたりしますが
そのリポジトリが無くなったら終わりってことですか？

それと、forkした場合などはユーザ名変わるわけですがfork内のimport全部書き換えなきゃならんとか面倒ではないですか？

**デフォルトの名無しさん** · 2017/12/08(金) 14:44:36.27

>>162
vendoring すれば良いんじゃない

**デフォルトの名無しさん** · 2017/12/08(金) 17:33:33.51

ありがとうございます
vendoring という機能を知りませんでした
vendoringで解決できそうです

**デフォルトの名無しさん** · 2017/12/08(金) 21:10:32.89

リポジトリあっても数年更新ないとかあるからな
go-bindataとか

**デフォルトの名無しさん** · 2018/01/21(日) 17:08:27.78

ふむ

**デフォルトの名無しさん** · 2018/01/24(水) 05:47:28.45

goでもwasmへの準備が着々と進行中らしいな

**デフォルトの名無しさん** · 2018/02/08(木) 01:35:20.81

goland使いにくいvscode使いたいです

**デフォルトの名無しさん** · 2018/02/22(木) 17:15:17.70

>>165
こういうのがあるとパッケージプロバイダを経由したほうが良いと思える。アカウントけされたらvendor使ってても無駄だよね

**デフォルトの名無しさん** · 2018/02/23(金) 18:16:11.30

vgo に期待

**デフォルトの名無しさん** · 2018/02/25(日) 10:05:06.21

ビルドしたバイナリにソースコードのパスが含まれちゃうんだけどこれを抑制する方法ってありますか？

**デフォルトの名無しさん** · 2018/02/25(日) 11:14:54.47

>>171
試してないけどgoupxとか試してみたら？

**デフォルトの名無しさん** · 2018/02/25(日) 12:00:11.13

>>172
レスありがとうございます。
upxで圧縮しても解凍したらパスが出てきてしまうので意味がありませんでした。
https://qiita.com/kitsuyui/items/d03a9de90330d8c275c8
↑みたいな方法しかないみたいですね。

**デフォルトの名無しさん** · 2018/02/26(月) 00:18:29.75

なるほどpanic時に使う情報なのか。
でも本番では要らないなぁ

**デフォルトの名無しさん** · 2018/03/05(月) 14:57:47.25

Googleが「Dart 2」発表、Dartを再起動。iOS/Android用ライブラリ「Flutter」と共にWebとモバイルのクライアント開発にフォーカス
http://www.publickey1.jp/blog/18/googledart_2dartiosandroidfultterweb.html

**デフォルトの名無しさん** · 2018/03/22(木) 15:24:45.26

APIサーバでマスタデータ的なものをグローバル変数として最初にDBから読み込んでおくのってアリな設計？

memcacheとか使うのはもう少し流動性のあるデータとか、サーバ間できちんと同期する必要のあるデータ扱う場合って認識でいる

**デフォルトの名無しさん** · 2018/03/22(木) 15:27:09.34

>>176
あり
いつ更新するかは重要

**デフォルトの名無しさん** · 2018/03/23(金) 04:54:04.26

初歩的な質問で恐縮なのですが、
Javaでいう所のSystem.out.print(i + " ");のような記述は、
Goではどのようにすればよいでしょうか？
fmt.Print(i + " ");とするとエラーになってしまうのですが…

**デフォルトの名無しさん** · 2018/03/23(金) 08:37:20.35

>>178
fmt.Print(i, ” ");

**178** · 2018/03/23(金) 16:41:04.93

>>179
分かりました。ありがとうございました。

**176** · 2018/03/23(金) 18:24:39.93

>>177
ありがとう！

**デフォルトの名無しさん** · 2018/03/26(月) 02:30:23.68

intのabsってどこにあるの？

**デフォルトの名無しさん** · 2018/03/27(火) 02:46:00.44

>>182

https://godoc.org/github.com/google/gapid/core/math/sint

https://godoc.org/?q=math

**デフォルトの名無しさん** · 2018/03/27(火) 02:58:17.13

absのベンチの話面白いね

Optimized abs() for int64 in Go
http://cavaliercoder.com/blog/optimized-abs-for-int64-in-go.html

**デフォルトの名無しさん** · 2018/03/27(火) 08:30:30.17

intのabs無いんかい。
まぁ簡単に作れるからいいんだけど、、、なんで？
ジェネクリスができたら実装するんかな

**デフォルトの名無しさん** · 2018/03/27(火) 10:55:24.81

>>184
(・∀・)ｲｲﾈ!!

**デフォルトの名無しさん** · 2018/03/28(水) 03:52:49.62

https://golang.org/src/sort/sort.go

Goのクイックソートの実装を見ると内部でヒープソートとシェルソートをしているように見えるのですが
これはイントロソートの亜種なんですか？

**デフォルトの名無しさん** · 2018/04/08(日) 22:26:49.15

Google CodeJam 提出言語をGoのみにすればGoの普及がもっと加速したんじゃなかろうか

**デフォルトの名無しさん** · 2018/04/08(日) 23:50:10.95

go言語にc++17の [[nodiscard]]属性みたいなのないですかね？

**デフォルトの名無しさん** · 2018/04/09(月) 23:26:18.67

ほう、検査例外みたいな機構がC++に出来るのか
そりゃ楽しみだな

**デフォルトの名無しさん** · 2018/04/10(火) 00:34:02.45

アンダースコアを使用禁止にしたら

**デフォルトの名無しさん** · 2018/05/03(木) 12:05:12.84

wasmまだー？

**デフォルトの名無しさん** · 2018/05/22(火) 10:19:05.51

func calc(x int, y int) (int,int){
return x, y
}

var a int
a, b := calc(1,2)

みたいに定義済みのaと未定義のbに戻り値代入したいときって、
a用の一時的な変数を用意しないと駄目よね？
なんだかんだ一年以上、疑問に思ったまま過ごしてる

**デフォルトの名無しさん** · 2018/05/22(火) 10:20:03.02

もしくはbを先に定義しちゃうか
どっちが一般的なんだろう

**デフォルトの名無しさん** · 2018/05/23(水) 19:52:57.37

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

XC972

**デフォルトの名無しさん** · 2018/05/24(木) 00:39:30.46

RDBをRedisとかでキャッシュしつつ、更新もしてるサンプルない？
ラッパーの実装を参考にしたい

**デフォルトの名無しさん** · 2018/05/25(金) 23:12:31.74

>>193
別にそのまま行けないか？
aに当たるのはerrだったりするよね。

**デフォルトの名無しさん** · 2018/06/19(火) 04:26:11.88

>>192

**デフォルトの名無しさん** · 2018/07/02(月) 16:52:27.70

>> 193
https://play.golang.org/p/l3eB4W6F5Qc
こういうことね
そうするしかない。
「プログラミング言語Go」にも詳しく書いてあるよ。

**デフォルトの名無しさん** · 2018/07/02(月) 16:53:38.24

>>193
みすった -> >>199