Go language part 1

**デフォルトの名無しさん** · 2013/10/10(木) 12:04:51.78

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

**デフォルトの名無しさん** · 2014/07/24(木) 00:30:01.41

たしかに気にはなるけど
採用されない理由がそれだけのプロジェクトも想像できない

**デフォルトの名無しさん** · 2014/07/24(木) 11:10:30.02

>>203
むしろバッチ処理得意じゃないかと思うんだが。
APIを何万回も叩いて結果をDBに格納するみたいなバッチ処理を書いた時に
チャネルを使うと素晴らしく綺麗に並列化できて感動したんだよね。

**デフォルトの名無しさん** · 2014/07/24(木) 11:45:59.80

>>205
>>203が言ってるのはバッチ処理というより単機能の小さいコマンドみたいなもののことでしょ。
自分らが~/binにたくさんおいてあるbashスクリプトレベルの。

そもそもこのコンパイラは常駐アプリケーションを作るための設計すぎて、実行時間がある程度長くないと無駄なのは事実。
とは言えいい言語だからそういうシンプルな機能を作るためにも使いたい。
使い終わったらプロセスごと落としてくれればいいからGCとかいらないし。

**デフォルトの名無しさん** · 2014/07/24(木) 12:12:06.82

bsd って何の略ですか

**デフォルトの名無しさん** · 2014/07/24(木) 12:22:50.32

BuShiDou

**デフォルトの名無しさん** · 2014/07/24(木) 16:17:04.74

golang.jp を見て見たが、ちょっと最初の構想から外れてるみたいな気がする。
インタプリタみたいな軽量な言語を目指したと言うが、REPLすらないってどう言う事？
サードパーティの物をちらっと見た覚えは有るが、最近目立たないな。

REPLがあれば取り敢えず簡単なスクリプト処理的な物はこなせるけど、いちいちコンパイルGOじゃ面倒臭い。

ジェネリックもいずれ入れると言ってるがもう何年も経つのに入らないってどう言うこと？設計上無理が有るのでは？
今は色んな面で言語的にはかなり低級に思える。

**デフォルトの名無しさん** · 2014/07/24(木) 16:21:26.89

golangってインタプリタとして使えなかった？

**デフォルトの名無しさん** · 2014/07/24(木) 16:22:41.66

go run helloworld.go

**デフォルトの名無しさん** · 2014/07/24(木) 16:23:12.99

buildさえしなければhddを圧迫することはないだろう

**デフォルトの名無しさん** · 2014/07/24(木) 16:35:20.39

>>211 それは単なるコンパイル& Go

**デフォルトの名無しさん** · 2014/07/24(木) 16:39:29.49

え？インタプリタはコンパイルしないと思ってるの？phpもrubyもpythonもコンパイルするんだよ？

**デフォルトの名無しさん** · 2014/07/24(木) 16:44:21.40

>>214 広い意味でのインタプリタはそうだけど、そんな事言ったらJavaですらインタプリタと言い出すだろ。

本来の意味のインタプリタは、1行書いたら即実行が本来だよ。
コンパイルしようがどうしようが良いが、書いたら実行。これがインタプリタ。

perlなんかよりREPLの方がよほどまし。

**デフォルトの名無しさん** · 2014/07/24(木) 16:46:57.30

>>214 それに>>212 は全くのコンパイルじゃ無いか。
どこにインタプリタ的な要素が匂うんだ？

例えば、100行位のプログラムを書き始めたとして、>>212はいつ実行出来るんだ？
アホなこと言うな。

**デフォルトの名無しさん** · 2014/07/24(木) 16:47:30.54

>>211の間違い

**デフォルトの名無しさん** · 2014/07/24(木) 17:50:00.05

定義的にインタプリタであるかどうかにこだわる意味がわからん。
コンパイルが十分に速くてエディタの支援があれば事実上同じ。

**デフォルトの名無しさん** · 2014/07/24(木) 17:59:05.81

>>218 解らんかな？例えばインタプリタなら
>>218 と会話的にプログラム出来る。

コンパイル方式だと、>>218の発言を知ってから全ての218の行動を予測しながらプログラムを書かざるを得無い。どれだけ膨大なプログラムになるかわかるか？

例えば今日台湾の航空機墜落事故のニュースを知ってから、それに関連したプログラムをするのと、
全く知らずに何年も前から予測してプログラムするのでどれだけ大きな差が有るのか解らんかな？

**デフォルトの名無しさん** · 2014/07/24(木) 18:05:42.50

>>218 ま、いいや、golangで1行ずつコンパイルして結果が見えるのならそれで良い。

#今いるディレクトリは？
--gogo
#ls
--
#cd xxx

**デフォルトの名無しさん** · 2014/07/24(木) 18:10:26.83

ニュースの例えは効果的ではなかったな

**デフォルトの名無しさん** · 2014/07/24(木) 18:13:08.35

もう少し分かり易く説明して欲しい

**デフォルトの名無しさん** · 2014/07/24(木) 18:17:36.20

そもそもgoはc++の置き換えを狙ったガッツリコンパイル言語目指してたと思うが
インタプリタの話はどっから出てきたのだろうか。

**デフォルトの名無しさん** · 2014/07/24(木) 18:18:07.34

読込み -> 中間式生成 -> 実行 -> 結果表示
こういう流れなら中間式がなんであれインタプリタでよくないか

**デフォルトの名無しさん** · 2014/07/24(木) 19:31:52.41

対話式の環境が使いたいならscalaでも使えばいいんじゃねえの？
コンパイルくっそ遅いけど

**デフォルトの名無しさん** · 2014/07/24(木) 19:35:29.67

ClojureとかGroovyとかもJVM系の言語はコンパイルしてから実行するのに凄い時間がかかるな
REPL的な環境使うと捗る

**デフォルトの名無しさん** · 2014/07/24(木) 21:13:03.11

>>223
http://golang.jp/go_faq
新しく言語を作った理由は？

Go言語は、インタプリタ言語のプログラミングの容易さと、動的型言語の効率、コンパイル言語の静的な型の安全性を併せ持つことを目指しました。

**デフォルトの名無しさん** · 2014/07/24(木) 22:11:05.80

>>224 Javaは含めたく無いな。インタプリタは、基本的にソースコードをそのまま配布する物。
配布されたソースを変更すれば即座に実行出来る物。

**デフォルトの名無しさん** · 2014/07/24(木) 22:34:04.45

>>219
REPLが備わってる言語だと
1行ずつ試しながらプログラムを書けるのが良いっていう主張なんかな
コンパイル方式だと、ある程度まとまった量を書くまで
プログラムの挙動の確認ができないからダメだと

ちょっと興味あるから良かったらもう少し分かりやすく説明してほしいんだが

**デフォルトの名無しさん** · 2014/07/24(木) 23:08:29.15

つまり軽い気持ちでインタプリタという言葉を使ってしまったら
インタプリタに思い入れの有りすぎる人が騒ぎだしたって話か。

**デフォルトの名無しさん** · 2014/07/24(木) 23:30:45.74

>>229
例えば、
system("ls")
でカレントディレクトリ内のファイルを見て、ファイルが有るのを確認してファイルを読み込むとか。
周りの環境が不確かでも確認しながらコーディングを進めて行くことが出来る。

試行錯誤が入る様な場合には力を発揮する。

パラメータを変えながらのテストプログラムとか。

とは言っても、一般的にREPLが力を発揮するのはコーディング時に結果を確認しながら進めていけることだろうな。バグの少ないプログラムが書ける。

例 Java REPL
http://calms.hatenablog.com/entry/2014/03/20/215529

**デフォルトの名無しさん** · 2014/07/24(木) 23:38:19.65

>>231
お前の言いたいことはよくわかったが残念ながらgoは最初の最初からc++後継のガッツリコンパイル言語だ。
REPLなんて全く意識してない。

そこに書いてあるインタプリタがうんたらかんたらはPythonの手軽さり入れてますよくらいの意味だ。

**デフォルトの名無しさん** · 2014/07/25(金) 00:07:36.47

>>232 C++ ですら、CINTや、LLVM でのREPLが有るのに、なんでやらないんだろう？
言語と同等に重要だと思うけどな。

その前にジェネリックとかやることが山積みで残ってるからかもしれ無いが。

**デフォルトの名無しさん** · 2014/07/25(金) 00:20:30.83

Does Go provide REPL?
http://stackoverflow.com/questions/8513609/does-go-provide-repl

**デフォルトの名無しさん** · 2014/07/25(金) 00:29:07.50

>>233
まあ確かに話題になってるようにpythonコンソールみたいに使えたらとても楽だ。

**デフォルトの名無しさん** · 2014/07/25(金) 00:49:56.70

>>231
>>229だけどありがとう
REPLはいろいろ試せて便利ということですね
コンパイル方式の言語でもREPLがあれば便利だという意見に納得

**デフォルトの名無しさん** · 2014/07/25(金) 00:55:19.24

>>231
>とは言っても、一般的にREPLが力を発揮するのはコーディング時に結果を確認しながら進めていけることだろうな。バグの少ないプログラムが書ける。

これに関してはIDEでも出来るからREPLの利点になるかは微妙に思うけど

**デフォルトの名無しさん** · 2014/07/25(金) 01:24:46.41

そういう事出来るIDEってそんな多くないような
IDEの機能でREPLに近いのはイミディエイトウィンドウとSmalltalkくらいしか思い浮かばない

**デフォルトの名無しさん** · 2014/07/25(金) 02:11:12.44

ipythonみたいに補完できるツールって無い？

**デフォルトの名無しさん** · 2014/07/25(金) 08:54:10.04

>>238
SwiftのPlaygroundは、補間はおろかREPL機能やリアルタイム描画や変数の時間軸変化のグラフとか、時間軸を遡って確認したり出来る。
https://developer.apple.com/swift/
簡単なデモ動画
https://m.youtube.com/watch?v=vogFSIxprUo
描画結果も表示してる

今後こういったIDEが重要な要素となる。

**デフォルトの名無しさん** · 2014/07/25(金) 10:33:21.59

Swift使ってればいいんじゃない

**デフォルトの名無しさん** · 2014/07/25(金) 10:36:14.11

本当に今欲しいもの
それはその機能ですか

**デフォルトの名無しさん** · 2014/07/26(土) 01:12:14.54

func a() string {
return "aaa"
}
これをstringかintを返したい場合どういうふうにfunc a() stringの部分を書きなおせばいいのか教えてください

**デフォルトの名無しさん** · 2014/07/26(土) 01:38:36.60

func a() interface{} {
...
}

**デフォルトの名無しさん** · 2014/07/27(日) 04:43:42.19

2013-07-18
Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話
http://ryochack.hatenablog.com/entry/2013/07/18/201736

http://i.imgur.com/2sZxU5w.jpg

Go compiler も検討してるが、LLVM Clangには大きな差をつけられてる。

**デフォルトの名無しさん** · 2014/07/27(日) 08:52:04.39

LLVM Clangは、徹底的にループを排除するからな
元のコードがどんなだか知らんけど
他がやってるループをClangは回してない場合がある

**デフォルトの名無しさん** · 2014/07/27(日) 09:13:55.62

>>246 中にソースが書いて有るよ。
1GBのランダムなデータを3種類の読み方で読んで、00のバイト数をカウントすると言う物。
ループを省略するなんてことは出来なさそう。

**デフォルトの名無しさん** · 2014/07/27(日) 09:46:07.39

元のコードのここの部分が
for (i=0; i<fsize; i++) {
if (buf[i] == 0x00) cnt++;
}

例えばこんな感じに書いたみたいに展開されるってことじゃないの？
for (i=0,size=fsize/2; i<size;) {
if (buf[i++] == 0x00) cnt++;
if (buf[i++] == 0x00) cnt++;
}
if (fsize%2==1) {
if (buf[i++] == 0x00) cnt++;
}

**デフォルトの名無しさん** · 2014/07/27(日) 11:02:43.76

コンパイラの最も重要な最適化がループだからね。

**デフォルトの名無しさん** · 2014/07/27(日) 11:07:33.89

変数って型をしてしたほうがいい？
:=にたよったほうがいい？

**デフォルトの名無しさん** · 2014/07/29(火) 21:53:04.26

・【翻訳】Go言語がダメな理由 | POSTD
http://postd.cc/why-go-is-not-good/
　Goは何も新しいことをしない。
　Goは全てにおいてうまく設計されているとは言えない。
　Goは他のプログラミング言語から退化したものである。

**デフォルトの名無しさん** · 2014/07/29(火) 21:59:11.76

D言語とGo言語
http://wazanova.jp/post/64086105199/d-go

**デフォルトの名無しさん** · 2014/07/29(火) 23:32:56.57

早くジェネリックは欲しいね。

**デフォルトの名無しさん** · 2014/07/30(水) 07:50:42.52

>>251 >>252
でもRustやDは全然普及していないという決定的に致命的な欠点があるよな

**デフォルトの名無しさん** · 2014/07/30(水) 09:20:20.31

Rustはまだ実験段階だから仕方ない。　金が無いとなかなか進まないね。

Dはスポンサー次第だろ。　Facebookが使った。
http://blog.fenrir-inc.com/jp/2014/07/about-d-language.html
トレンド的な話ではウォルター氏を含むD言語プログラマーが Facebook に雇用されてD言語の開発とD言語製アプリケーションに携わっている状態で、
D言語公式カンファレンスの DConf も Facebook 本社を会場として去年から開催されています。

SUNはDTrace　として使ってるし、DTraceはAppleでも使ってる。

**デフォルトの名無しさん** · 2014/07/30(水) 09:54:57.06

>>255
http://ja.m.wikipedia.org/wiki/DTrace#cite_ref-2
DTraceで使われてるDはまた別のものっぽいよ

**デフォルトの名無しさん** · 2014/07/30(水) 09:58:39.78

D言語のドキュメントは読みにくいから挫折してGo北野に俺が勉強したくなるような余計ななことかくな！

**デフォルトの名無しさん** · 2014/07/30(水) 11:40:53.67

分かりやすい綺麗なコードが書ければプログラム言語なんて何でも良い
ただ、同じ事やるのに色々な表現方法が存在して構文を複雑にしたり
波括弧の位置だの鬱陶しい問題が存在しない方が良い

表現の違いで吐き出したバイナリコードに差が出る言語は
一々最速かつ最良の方法を模索するハメになるので煩わしい

**デフォルトの名無しさん** · 2014/07/30(水) 11:43:17.31

Go北野でツボった
AV男優か何か？

**デフォルトの名無しさん** · 2014/07/30(水) 12:44:24.74

>>259 もしかしてマジに聞いてる？　Go（に）来たの

**デフォルトの名無しさん** · 2014/07/30(水) 15:03:28.86

>>258
あなたはpythonで幸せになるべき

**デフォルトの名無しさん** · 2014/07/30(水) 17:26:23.03

>>258
そういう模索が必要になるレイヤーがあるんだよ

**デフォルトの名無しさん** · 2014/07/30(水) 18:58:50.92

英語読めないからあれだけど
WindowsだとOSのDLL読めるけど
ユーザーが作ったDLLは使えないんだって？
ならGoでグラフィックをやりたければOpenGLよりDirectXのが楽ということか

WinのOpenglは外部DLLないと古臭いから

**デフォルトの名無しさん** · 2014/07/30(水) 21:19:57.41

>>255
Facebookってオープンソースに力入れてたっけ？単に自社の便宜のためにDの開発者を取り込んだだけ、ということではなくて？

**デフォルトの名無しさん** · 2014/07/30(水) 21:50:47.94

facebookはPHP処理系の独自実装とかをオープンに公開してるな

**デフォルトの名無しさん** · 2014/07/30(水) 22:09:01.57

>>260
お前のアスペぶり、最近GoとOcamlの勉強始めた激オポ野郎に似てて笑える。

**デフォルトの名無しさん** · 2014/07/30(水) 22:51:02.01

あそこはサーバもオープンソースでやってたじゃないか

**デフォルトの名無しさん** · 2014/08/04(月) 14:37:29.28

func hoge(x, y int) (x, y int) {
return
}
これはダメで

func hoge(x, y int) (int, int){
return x, y
}
これがいい理由がわからない

**デフォルトの名無しさん** · 2014/08/04(月) 14:39:53.99

スコープの中で一度も出てこないからだろ

**デフォルトの名無しさん** · 2014/08/04(月) 14:44:57.93

func hoge(x, y int) (x, y int) {
x++
y++
return
}

これでもダメ

**デフォルトの名無しさん** · 2014/08/04(月) 14:59:51.43

> func hoge(x, y int) (x, y int) {
> ...
> }

これ、

./main.go:7: duplicate argument x
./main.go:7: duplicate argument y

ってなる(Go 1.3)

**デフォルトの名無しさん** · 2014/08/04(月) 15:04:04.54

馬鹿かこいつ

**デフォルトの名無しさん** · 2014/08/04(月) 15:20:41.03

>>268
goは全然詳しく知らないけど軽くググったら
http://golang.org/doc/effective_go.html#named-results
When named, they are initialized to the zero values for their types when the function begins;
まんま答えがありました

**デフォルトの名無しさん** · 2014/08/04(月) 15:25:59.54

>>273
戻り値が初期化されるからダメってことなんですね
Named resultは便利なようで冗長的になる可能性もあるってわけですね
メモリも食いそうですね
ありがとうございました

**名無しさん＠お腹いっぱい。** · 2014/08/04(月) 15:41:33.25

https://www.youtube.com/user/sesendou/videos

**デフォルトの名無しさん** · 2014/08/04(月) 15:48:57.70

>>274
詳しい人の意見を少し待ったほうがいいんじゃないの？
ダメな理由は素人でも特定できたけど
なんらかのやり方があるかもしれないよ？

**デフォルトの名無しさん** · 2014/08/05(火) 17:28:58.12

見やすさのために変数を初期化すべきかどうかって問題だろ
goの仕様関係ないやん

**デフォルトの名無しさん** · 2014/08/05(火) 17:39:44.90

go は全く知らないんだけど、皆の話を聞いてたら、入力の変数名x,yと出力の変数名x,yは別物みたいだね。
つまり同じ名前をつけるバカとは付き合えんと言われてるの？

inout属性をつけられると良いんだけどね。

**276** · 2014/08/05(火) 17:59:47.02

>>277
いえ、違います。
てか仕様そのものじゃないか。

>>278
いえ違います。
別物ではないから
重複定義でエラーになるんでしょ。

func (x int) (x int) なら
現状だとpseudoで
int x = 0
int x = args["x"]

その内
func () (x=123 int)
などで0以外の初期化子与えたり
func (x int) (x=args["x"] int)
func (x int) (x=args.x int)
func (x int) (x=_x int)
などで引数で初期化とか出来るようになるんじゃないかな
というか既にあるんじゃないのかな

**デフォルトの名無しさん** · 2014/08/05(火) 18:07:02.09

>>279 変数名in x,y で、out x,yにしたかったんだろ。
でも言語仕様上 in x,y とout x,yのx,yを同じ変数に割り当てられないからエラーになるんだろ。
つまりinと、outは別の変数を使えとしかられてるんじゃ無いの？

言語によってはinout属性を付けると、入力変数に値をセット出来て出力とすることが出来る。

**デフォルトの名無しさん** · 2014/08/05(火) 18:10:48.15

>>280 簡単に言うと、
func( 1, 2 ) と渡された時に

勝手に 1, 2 を上書きすんなよとしかられてるんだろ？

**片山博文MZ次期CEO** ◆T6xkBnTXz7B0 · 2014/08/05(火) 18:25:28.35

Goは、重要な言語ではない。

**デフォルトの名無しさん** · 2014/08/05(火) 18:45:40.65

>>280
>>281
面倒だから何でもいいよ。

**デフォルトの名無しさん** · 2014/08/05(火) 21:25:46.03

goでguiが作れない
guiライブラリのコミュニティーがない
あっても個人が作ったライブラリがあるだけ
goでguiに未来はない

**デフォルトの名無しさん** · 2014/08/05(火) 22:21:36.63

まずはジェネリクスを所望する

**デフォルトの名無しさん** · 2014/08/05(火) 22:47:32.36

Go死亡。

はい、時間の無駄でした、残念。

**デフォルトの名無しさん** · 2014/08/05(火) 22:51:32.76

Goはオワコン

**デフォルトの名無しさん** · 2014/08/05(火) 22:56:03.53

もうGoogleは、Android にも言語にも飽きたんだよ。オタクの趣味としてちんたら遊ばせておくつもりだろ。

はた迷惑だよな。
ロボット企業を買いあさってる。日本のSCHAFTも買収された。

**デフォルトの名無しさん** · 2014/08/05(火) 23:31:09.30

ニュース速報。Goが死亡したことについてGoogleは謝罪会見を行わ
ないとのことです。Goのユーザーからは怒りの声が上がっています。
以上、中継でした。

**デフォルトの名無しさん** · 2014/08/06(水) 00:15:13.55

叩きたくて叩きたくてしょうがない奴が2chというゴキブリホイホイにあつまってくる
お陰でネットが平和にはなるけど

**デフォルトの名無しさん** · 2014/08/06(水) 00:15:15.26

Goは、システムプログラミング寄りのことをしない人には関係ないし、GAE使わない人にも関係ない。
WebAPIに使おうという人は増えてはいるけどね。

**デフォルトの名無しさん** · 2014/08/06(水) 01:31:04.59

まだ実験的に使ってる位だろ。本格的に使えるレベルじゃ無いだろ。
WebAPIだと下手するとJAVAにすら負けるんじゃ無いのか？

**デフォルトの名無しさん** · 2014/08/06(水) 02:01:51.39

https://code.google.com/p/go-wiki/wiki/GoUsers
とりあえずGoを使ってる組織一覧あげとく

**デフォルトの名無しさん** · 2014/08/06(水) 02:59:23.20

>>293
GitHubとかHerokuとかマジ？

**デフォルトの名無しさん** · 2014/08/06(水) 08:27:30.42

おまえらDocker関連の盛り上がりを知らんのか？
あれGoで書かれてるんだぞ

**デフォルトの名無しさん** · 2014/08/06(水) 08:38:43.95

この前買ったAsusのM/Bに付いてるユーティリティのセットアップ部分がGo+Walk?で書かれてた
Dos窓の消し方知らん状態で、よく配布出来たなと思うけど

**デフォルトの名無しさん** · 2014/08/06(水) 09:24:52.37

dockerに限らず、CoreOSやOSvの運用ツールもgoだったりする。
https://github.com/coreos/fleet/blob/master/README.md
https://github.com/cloudius-systems/capstan/blob/master/README.md

**デフォルトの名無しさん** · 2014/08/06(水) 09:30:56.39

cloudflareがオープンソースしてるCDNまわりの運用ツールやperconaのMySQLまわりの運用ツールもそうだったか。
まあ、google社内の運用ツール作成者が、cやpythonの代わりにgo使ってるようだが。

**デフォルトの名無しさん** · 2014/08/06(水) 10:06:37.78

1.3からNaClもサポートされたよね。
実際使えるようになるのは1.4からだろうけどWebClient側もGoで書くようになるか。
問題はchromeでしか動かないってことだけど

**デフォルトの名無しさん** · 2014/08/06(水) 10:49:43.03

NaClはサンドボックス用の実装
1.4はarm NaCl
内容分からず書き込むなよボケナス
Web Client向けじゃねーよクソカス

**デフォルトの名無しさん** · 2014/08/06(水) 13:24:50.02

>>300
どっちかいうとPPAPIを1.3でサポートしてないから、サポートする1.4から本格的に使えるって意味ね。

ビジネスロジックをクライアント側で実装するとなるとjsでは丸見えになるから
NaClでクライアントの一部でも実装できるというのはありな気がするんだけど。
ブラウザをchrome固定にしても構わない社内システムとかね。

**デフォルトの名無しさん** · 2014/08/06(水) 13:40:49.32

https://code.google.com/p/go-wiki/wiki/NativeClient
They cannot be run directly in Google Chrome. As such, the NaCl support in Go 1.3 is useful only for running sandboxed environments like the Go Playground.

上記を読めない文盲か？

PPAPIが1.4でサポートされるというソースを出したら全力で謝ろう

**デフォルトの名無しさん** · 2014/08/06(水) 15:57:32.29

go-wiki
There is ongoing work exploring support for the IRT and PPAPI (3 and 4 in the list) but no definite release target. Perhaps they will be in Go 1.4 but perhaps not.

perhaps not
^^^^^^^^^^