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/

**デフォルトの名無しさん** · 2019/10/16(水) 21:25:43.79

うちとこJava/C#が主力な会社
面白そうだから布教してみようと思ったんだけど、結局C言語からの直系なだけで、Java以降とは似て非なるものだから布教は無理なんだと、よくわかった

あいつら新人類は実体とポインタにまみれたC言語の素養がないから、うっかりと参照を代入する気楽さで構造体の実体をコピーして操作する感じのミス連発

C言語の経験なしにも関わらず、苦労せずにGo言語に慣れたって人いる？
そして、今さらポインタと実体を残したgoogleの意図も良くわからない。参照でよくね？

**デフォルトの名無しさん** · 2019/10/16(水) 22:53:56.55

ただの慣れじゃねC#の構造体も値型だし
値型の方が有利な場合がある
例えば構造体のでかい配列を作る場合は値型の方が一気にメモリ確保するから速いはず

**デフォルトの名無しさん** · 2019/10/16(水) 23:11:13.99

>>978
回り見てるとスクリプト言語出身の人はGo移行についてこれてない
Cでそれなりの規模のアプリ書いたことがある人がジワジワと良さを認識してる(すぐに良さがわからないのは共通してる)
C++出身の人はRustを気に入ってるが

**デフォルトの名無しさん** · 2019/10/16(水) 23:48:28.74

ポインタと実体という概念がどうもしっくりと来ないみたい
Java以降だとプリミティブ以外は全部インスタンスの参照で統一されていてシンプルになってるから
そこいらのハードルが新規参入の障壁になってる可能性は高いんじゃないかなとか感じてる

しかし惜しいと思うのは、実体とポインタが混在しえるコンセプト
Cからの派生だからといって実体としてのインスタンス化って、本当に必要だったのかな？
&とか*なんて廃止して、全てはポインタの言い換えである参照を扱うというJavaとかのアイデアは多重間接参照(ポインタへのポインタ)が扱いづらくなる一方で概念的な単純さをもたらしてくれる
ぶっちゃけポインタへのポインタなんて、普通はそんなに使うこと無いから

参照を採用していたら、レシーバーはポインタで記述とか、実体でのセレクタでポインタレシーバーも呼び出せるとかイミフな仕様もスッキリとしたんじゃないかと
多分、ポインタを残したことには深慮遠望があるんだろうけど、使っていてイライラしてくる

**デフォルトの名無しさん** · 2019/10/17(木) 00:01:47.10

具体的には構造体のスライスを使うために構造体ポインタのスライスを書くのがイライラ
でもポインタにしないとrangeでコピーされちゃうから
これって実はエレガントな書き方があったりする？

**デフォルトの名無しさん** · 2019/10/17(木) 00:05:09.89

まあ確かにその辺は混乱する
ローカル変数の実体のポインタをリターンするとか
C脳ならありえない

**デフォルトの名無しさん** · 2019/10/17(木) 00:16:29.41

Goは全然気持ち良いけどDartの酷さがやばい
あれはスクリプト言語出の人らだと大丈夫なんか？

**デフォルトの名無しさん** · 2019/10/17(木) 00:18:24.47

>>979
構造体のデカイ配列ったって、マーシャリングして外部DLLに渡すとか極特殊な用途でしか使わなくない？

**デフォルトの名無しさん** · 2019/10/17(木) 00:53:17.22

Goは確かに気持ち良いね、テストからカバレッジ、マップにスライス、ゴルーチンとチャネル
(でも気持ちよさの基準がCなのは否めない)
interfaceとか目から鱗だった。元ネタはなんだろ？

**デフォルトの名無しさん** · 2019/10/17(木) 17:11:40.24

前は動いてたのに
run も build も

package main: no Go files in hogehoge とか
can't load package: package main: no Go files in hogehoge とか
出るようになって
ハマった

ソースファイル名を _fugaufa.go みたいに _ で始まってたらあかんの？
時間還せ

**デフォルトの名無しさん** · 2019/10/17(木) 17:12:22.77

>>986
>気持ち良い

ガベコレとゴルーチン以外で何があるんです？

**デフォルトの名無しさん** · 2019/10/17(木) 19:03:27.04

var は気持ち悪い

**デフォルトの名無しさん** · 2019/10/17(木) 19:32:11.66

>>987
https://golang.org/pkg/go/build/#Context.Import

In the directory containing the package, .go, .c, .h, and .s files are
considered part of the package except for:

- .go files in package documentation
- files starting with _ or . (likely editor temporary files)
- files with build constraints not satisfied by the context

**デフォルトの名無しさん** · 2019/10/17(木) 19:32:31.41

>>989
言われてみれば、varって昔のBASICのlet並みに要らない子だね

**デフォルトの名無しさん** · 2019/10/17(木) 20:40:18.77

varはバーカよけ

**デフォルトの名無しさん** · 2019/10/17(木) 20:40:53.90

トップレベルの変数どうやって宣言すんだ？

**デフォルトの名無しさん** · 2019/10/17(木) 20:46:45.50

普通にそのまま

**デフォルトの名無しさん** · 2019/10/17(木) 21:25:40.03

変数名型
だけでも、構文として破綻しているようには見えないもんな。C言語もそうだし
当然にvar{}も要らんし
あれ、func も不要じゃね？
なにか必要である理由ってあったかな？

**デフォルトの名無しさん** · 2019/10/17(木) 21:27:23.25

無名関数作るとき用くらい？

**デフォルトの名無しさん** · 2019/10/17(木) 21:37:21.35

次スレ作ります

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:38.42

Go language part 3
https://mevius.5ch.net/test/read.cgi/tech/1571315884/

**デフォルトの名無しさん** · 2019/10/17(木) 21:42:09.40

構文解析が楽とかだった気が

最初の方のトークンでどの構文（変数定義とか関数定義とか）なのかが分かったほうが
後の方のトークンでやっと分かるより楽

**デフォルトの名無しさん** · 2019/10/17(木) 21:56:16.73

んー、:=で型推測をぶちこんでくるアグレッシブさなのに？1000ならIsNil()追加

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 705日 2時間 30分 50秒