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書くのをサボらなければそうそう死なん。