◎正当な理由による書き込みの削除について: 生島英之 とみられる方へ:Go language part 2 YouTube動画>2本 ->画像>7枚
動画、画像抽出 ||
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク: http://5chb.net/r/tech/1510395926/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。
公式ドキュメント
http://golang.org/doc/ 日本語訳
http://golang.jp ※前スレ
Go language part 1
http://2chb.net/r/tech/1381374291/ 書き込み待って読んでから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])とかよしなにしちゃえるんじゃないの?
>>1 乙。だが
http://golang.jp/ って推奨されないurlじゃなかったっけ?
>>3 最早死んでるんだっけ?
申し訳ない。単純に引用した。
今どこか良い日本語のサイトがあれば、書いてもらえるとありがたい。
>>2 あ、これrangeでvals受ける所をvalues受けてる。あとからargsが4文字だからvaluesもvalsにしよう、とか文字数とか調整してはいかんかったな。
(前スレ)
>>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++がリフレクションしたらかなり被るね。
リフレクションせんでも、アサーションで十分じゃないの? プリミティブ以外が入ってる事もほぼ無いだろうし、 型無しのinterfaceから、特定のinterfaceへアサーションした方が幸せになれるだろ。 Stringerであれば良いとか。
まずORMって何か考えれば良いと思うが、Object Relational Mappingだ。 リレーショナルデータベースに入れないのであれば、ORMじゃない。 ORMを、単にデータベースにオブジェクトを入れる道具の代名詞にしてるが、全然違う。 DatastoreはRDBではない。 CouchやMongoみたいなオブジェクトを放り込めるDB。そういう部分には向いてなくはない。
JsonとRDBを同様にキーバリューと考えてるみたいだが、「RDBは同じ列で構成された行の集合」、Jsonは「「キーで表された値の集合」の集合」であって、キーと列はかなり違う。なぜかと言うと、Jsonは「キーで表された値の集合」単体で成立するが、 「値の集合」は列がないと存在できないし、全ての値の列は同じである必要がある。 だから、マッピングせなならん。 別に、RDBでもID,シーケンス,区分列,値列で持ってメタテーブルみたいにしても良いんだから。 そこがテキトーなのは、単に作り方が雑なだけ。 ちなみに、タグに書いとけば、コンパイル時に抜け落ちる事はないので、それこそreflectで取れる。
GoでRDB使う時に本当にきついのはSELECTとかLEFTJOINとか駆使して カラムの構造がquery毎に違う可能性があるからなんだよね。 結局クエリごとに構造体作るしかない。 つまるところGoとRDBの組み合わせは避けるのがベスト。かも。 queryの結果から構造体をコード生成する方法があると良いんだけど
てか、staticメソッド無しかよ!これどうなのよ? ファクトリ作りたいんだが、まさか外に転がせと?ひどくね? とりあえずクラスメソッドをインスタンスnilで呼んでみたがアウトだし。 なんかもう、色々酷い。 この言語は多分、ベタにしか書けないし、それをよしとする言語だ。 Cだと思えばそんなものだとも思えるが、これは逆に言うと、 Cしかやってないか、Cで何も問題を感じない奴が使う言語だね。 確かにこれだとC並みの速度は出るだろうが、これでは開発効率もC並みでしかない。 新しい言語と言うよりは、新しいBetterCの提案、と考えるべきなのか? というか、これまで20年ほどでだいぶ積み上げたソフトウェア産業の資産、 「ソースコードはどう書けば見やすい/将来に渡ってメンテ出来るか」 をここまでガン無視していいのか?とも思える。潔いと言えば潔いが、どうなのよこれ? 若干意識高い系共によって肥大化した感のあるソフトウェア方法論へのアンチテーゼかよ? ミニマリズムというか。 最近は一周回ってCを知らない馬鹿も偉そうにしているわけだが、 そいつらにとってはGoは新鮮なのかな?最近の言語とはだいぶ違うから。 ただ、GoはほぼCだぞいろんな意味で。
>>10 > queryの結果から構造体をコード生成する方法があると良いんだけど
evalだね。Goには当然ないが。
C#でLINQでevalモドキを作っていたのがあったはずだが、
(心はC++のExpressionTemplateみたいなノリで、
演算子と評価順をデータとして記録しとけば、式程度ならデータ側だけで出来る、というもの)
それと同じノリで上手くいけるか、だね。
フィールドのオフセットさえ決まればそれは構造体なわけで。
ただ一般的にはオフセットはコードに静的に埋め込まれているから、
回避するにはオブジェクト指向の仮想関数テーブル(vtbl)みたいな仕組みが必要になる。
逆に言えば、これさえあれば動的な構造体を簡単に扱えるようになる。
JavaScriptは無駄に速くなっているが、この手の仕組み持っているんじゃないかな?
V8はプロトタイプ毎に型扱いでnewしてるようだし。(正式名称があったが忘れた)
>>11 自分の型をポインタで書いたらnilで呼べるだろ。
可変長もそうだし、ちゃんと言語仕様読め
なんで既存コードが読めないんだろう。 セルフホストされるようになってから長いぞ。
>>11 goにクラスの概念はないぞ、ドキュメント読んで勉強し直せ
>>13 お、ポインタレシーバならnilで受けられるのか?
しかしまあ、ベタで書くことにした。
というか、どうもその手の「ちょっと綺麗に書くテクニック」を全力で否定するノリのようだし。
なまじ隠蔽出来るから無駄に肥大化するのであって、管理が厳しくなったらパッケージを分けろ、なんだろ、多分。
まあ分からなくもない。
JavaScriptの関数スコープは最初は戸惑ったが、結局のところ関数を小分けにすればいいだけであって、
Cとかはなまじブロックスコープなんてあるから無駄にでかい関数になってしまうのも事実だ。
Nodeのコーディングルールなんて段々短くなってて、どうも今は「関数は10行にしろ」と言っているようだし。
(以前は19行だったと思った。今ググったら15行(多分更新されてないだけ)ってのはあった)
同様に、基本的にパッケージ内にベタで転がしておき、無理ならパッケージを分割、というのも妥当な方法ではある。
そもそもメソッドも(見た目は)ベタで転がってる訳だし。
まあこれはいいとしても、generic的な物がもうちょっとないと、昔の定義のコピペプログラムが必要になってしまう。
この点については何で端折ったのかよく分からんなあ。
C++のテンプレートは暴走気味だし、そういうのを嫌ったのかな?
まあいずれにしても、俺にとってはGoはbetterCとして理解した方がいいというのはかなりはっきりしてきた。
もう「味見」は終わった様だし、やっぱり go は使わなくてもいいんじゃないかな
>>17 いやまだ終わってないんだなこれがw
道草食いまくってるからだが。
ただ、GoはWebには不向きというか、新規機能追加等で変更を迫られた場合、
PHP/JavaScript等と比べて3-5倍のコード変更が必要になりそうだ。
そしてこの、変更時のコード量がCと比べてほぼ同量だ。だから開発効率はかなり悪い。
パッケージが揃っているからとっつきやすいだけで、
(ライブラリを熟知している)バリバリのC++使いにとっては魅力はほぼ無いだろう。
とはいえ、「とっつきやすいC」という存在価値があるのかもしれない。
というか、C++は取っつきにくすぎる。あれは完全に暴走してる。Linusが毛嫌いしているのも分かる。
とはいえ、Goでプロトタイピングするのは辛いのは分かった。
というか、はっきり言ってろくな言語がないなこれについては。
JavaScriptは非同期のおかげでかつてのgoto文プログラムみたいな構造になってしまうし、
PHPは言語仕様が糞過ぎて思わぬところでバグって引っかかりまくるし。
RubyもPythonも前方宣言必須のゴミ言語だし。
同期JavaScript(マルチスレッドだよ!)が出れば一人勝ちじゃないのかな、と思うが、
あいつらの非同期はもはや宗教だし。
長文だらけで追い切れんけど 愚、言語がヘボでカラム分からんとDB操作が出来ません 賢、いやいや、アサーションでこう書けば出来るじゃん? 愚、他言語だとこんなので出来るんだけど 賢、じゃ好きなので書けよ、どうぞどうぞ まとめるとこんな感じ?
>>16 ちょっときれいに書くテクニック、が他の言語と違うだけだよ。可変長引数に参照のスライスを渡す、とか、
取り敢えず受けて.(type)でswitchしてcaseに型書いて処理するとか。
ジェネリックに関しては、あれば良いなと思う事もあるが、実際やってみたらrangeで事足りたり、
chanにとにかく突っ込んで、空selectとcase xxx<-xxxchでさらに事足りたりと、便利な読み方はある。
システムコールのselectで複数のファイルハンドル待つ感じ。
>>18 多分ウェブに関して言えば、ちゃんとしてればPHPの工数の4番の1くらいになると思うよ。
ちなみに、JavaScriptでマルチスレッドマルチコアは、クライアントならWebWorkerやら、nodeなサーバならclusterとか色々ある。
そもそも、クエリの結果イコール構造体にならない事の方が多いでしょ。 構造体の入れたいフィールド(と読み捨てるカラムを放り込む値)の参照を持ったinterfaceのスライス投げるのが一番手早い。 入れたいフィールドのカラムを集めてinterfaceのスライスを返す関数用意しときゃ済むじゃん、ゼロクリアは保証されてるんだから。
>>21 ちょっとわかりづらいからサンプルコードある?
構造体を自動生成するとして中身のわからん構造体をどうやって使うんだ?
結局リスレクション使った遅いもんになるだけでしょ 過度の抽象化は害しかないって偉い人が言ってた
>>22 >>2 hogeって構造体があって、そのxxを取りたいなら、
のargsの、欲しいカラムの場所に&hoge.xを入れるだけ。
構造体を自動精製するんじゃなくて。
リフレクションとアサーションは違うし、そもそもそこまで遅くないぞ。
つーか、これ、構造体のメンバ名を都合3回書く必要があるじゃねーかよ!
度を超したクソッぷりにビビる。つーか、お前らマゾなのか?
1回目:type struct 内 ← うーん、まあ静的言語なら仕方ないか
2回目:rows.Scan 内 ← 速度の為なら仕方ないか、、、
3回目:メンバ名は大文字で始めてjsonタグをいちいち書け ← 死ね
PHPやJavaScriptでは1回も書かなくていいんだぜ!
さすがにこれには切れたよマジで。
https://qiita.com/vvakame/items/6719b3c90dfaa8220e44 >>26 Scanには書かんで良いだろ。何読んでんだよ。
Jsonなら、*interface{}で受けて、map[string]interfaceで値とりゃフィールド名出てくんの一回だろ
だから、
>>9 で、RDBのように行と列が分離してねえんだよって言ってんじゃん。
しかし2chで知りたいことがあればdisれというのはホントだな。
これで、Cをやってたからついてける、お前はGCの動くタイミングが、とよく言えるな。 Scanの実装見て喋ってんのかなぁ。
dynamicとかnewtonsoft.JsonのJObjectで受けないC#でもクラスのフィールドに属性つけなきゃならんし、こいつが何を問題にしてるかわからん。 cやcppで書いたらライブラリ使ってももっと地獄じゃん。 動的言語しかやった事無いから辛いと言ってるだけに見える。
前スレ
>>977 まさか3回も書かされるとは思っていなかったから今更ながらxoを試した。
が、これもちょっと冗長だな。
標準で go generate がついている時点で、公式も糞っぷりを認めてる。
ASTとか完全に屋上屋を架してる。
ろくな解がない。
構造体メンバを1回書くところまでは許すとして、
Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。
新参を足蹴にするような真似はしたくないが、 3回も書いたのは自分だろ…。
可変長引数を受ける関数には、...でスライスを渡せる。 構造体渡したら構造体の(カラム名と同じ(!))メンバに入れてくれる事を望んでるんだろうが、 型がハマらなかったらとか、そもそもクエリでasで別名つけてるかもとか、キャストしたけどasで同名つけてる、とか、クエリ側が勝手な事するリスクを全部解決して構造体に入れる手段を考えてから考えれば良いのに。 まぁmap[string]interfaceが落としどころじゃねえの?フワフワ適当なクエリ投げたいなら。 クエリ自体もGoに書かせたいなら、最早SQLと繋げる意味なかろうて。
>>31 > Scanは構造体を受けろ、JSONはlowerCamelスイッチをつけろ、ってとこだね。
ま、↓にでも投げてみたら
ExperienceReports
https://github.com/golang/go/wiki/ExperienceReports >>32 構造体で受けるだけならそうだね。
ただ、毎回リフレクションはかなり厳しいから、うまくキャッシュしてくれるかどうか。
refrectを見る限りシグニチャは発行してくれないっぽいし。
ポインタ演算を禁止しているから、CみたいにOffsetofの結果を配列でキャッシュできないのも残念な所だね。
使うときは速度/ソース確認必要といったところか。
今回は速度の味見だし、とりあえずベタで書いた。
ただ2回書きまでは覚悟してたが、3回とはね、、、
>>36 まあ俺が煽るから無視してるんだろうが、
煽り抜きでとりあえず
>>2 と
>>25 やってみたら?
ベタ書きよりはましだと思うが。
なんかそれでダメな点があればまた教えて欲しい。
>>35 さすがにGo歴1週間もないのに投げないよ。背景等もよくわからんし。
てか、同意するなら誰か投げてどうぞ。
てか、Go信者はこの言語のどこに惹かれてるんだ?
特に目立ったメリットはないような。
>>31 むしろ標準ライブラリにASTついてるのって魅力じゃないんかな。
goはコード生成してなんぼなんじゃないの
ただの別名も指定せんクエリなら、構造体渡して、参照がセットされた([]interface{})返す関数だけでいけると思うが、なんかいかんのかな。
>>37 日本語でおk
おまえには日本語が通じず、話が空回りするから無視してる。
map/リフレクションを使わない理由は俺は既に
>>6 で言っているし、
それはむしろ一般論だから、他の人もそれをふまえて話をしている。
おまえだけ空回りしてるんだよ。そしてそれが荒らし行為なんだよ。
煽るとか、そういう表面的な行為は大した問題ではないんだよ。
おまえは馬鹿だからそれも分からない。マジで死ね。
>>41 マップでもリフレクションでもないんだが。
>>38 俺的に気に入ってる点。
* 構文規約が言語側で確定してるから誰のgoコードでも見やすい。
* コードの管理周り。 正直他の言語でもコード管理は真似してる(ghqをつかって)
* 標準ライブラリが学習教材になってる感じ。
* goaがある。
正直一番最初に使いたい理由になったgoroutineは一番最初に触って以降触ってないな。
色々欠点もあるけど、なんかコード生成によるメタプログラミングを体得すれば解決する問題かも。と思っていてAST周りを学習中
なんで、リフレクションとアサーションと言葉が違うかわかる?
>>39 いや、正直、そういう文化なのかな?とちょっと思ってました。
てかなに?今時の若者はASTとかでさくっとコード生成しちゃうもんなの?
俺はlexとかbisonとかは触らずにきてるんだけどさ。
かつ、interfaceが指す先の型がScanner実装してたらそれで勝手にやってくれんじゃないかなぁ、これは勘違いかもしれんが。 まぁ、やりもせず、パフォーマンス計測もせず、思い込みで「これはリフレクションである」と言われても困るわ。 空回りしてんの俺か?
>>38 > てか、Go信者はこの言語のどこに惹かれてるんだ?
> 特に目立ったメリットはないような。
ある種のシミュレーションプログラムを作るのに goroutine + channel
で割合と簡単に書けちゃって、32 core 使って並列化したら実行時間が
1/25 程度に抑えられて…といった経験からかな。
ちゃんと言うと、Goのinterfaceはメモリ上に型情報をそもそも持ってるから、リフレクションせんでもほぼノーコストでアサーションできる、はず。
https://research.swtch.com/interfaces >>43 go fmtとか、パッケージ管理/ディレクトリ構造が言語に密着とか、確かにいい割り切りっぷりではある。
しかし他挙げてくれた点も、Go言語自体ではなくて、エコシステムの話だよな?
いやもちろんエコシステムも重要なんだが。
gorutineはパンダだろ。その意見(最初だけしか使ってない)は割とよく見るよ。
> コード生成によるメタプログラミング
まあCのマクロやC++のテンプレートよりはましかも。ソースが直接見えるという点で。
goroutineはAPIサーバ書いたり、システム内でメッセージ投げ合うたぐいの物書いたらめちゃくちゃ便利だけどな。 用途次第だろ。
>>45 そんな恐ろしいもんじゃなくGoコードを構造体に変換できるから
改変がし易いってだけじゃないかな。
正規表現で変更とかよりよっぽど安心できる。
>>47 goroutine+channelがはまったケースか。
それなら分かるとして、ただ、そもそもこれがはまるケースがほぼないよな?
>>51 ハイジェニックなマクロ展開とか書きやすいしね。
前スレ974で良いところ行ってたのに、突然のシッタカでグダグダ言う上に読解力に欠けてて、しかもリフレクションだと決めつけてて、 人の話も聞かんと、言葉が理解できないならコードは読むだろうと解説代わり書いて、 Cがわかるなら.sに落として眺めるだろうという期待も裏切り、 何やってるかまったくわからん。
>>51 > 正規表現で変更とかよりよっぽど安心できる。
確かに。自前よりは公式解釈済みの構文木をもらえた方が100倍いい。
しかしそれ、渡されましても、、、ってのが普通だと思うが。
てか、これ見せてる言語ってこれまであったっけ?
最近はflycheckみたいなリントも流行ってるみたいだし、見せる方向なのか?
>>49 俺にとってgorutineはたしかにパンダだったな。
構文規約が言語側で確定って割と言語仕様よりなんじゃないの。
Go言語の言語仕様は物足りさは感じつつってのはある。
interfaceがGoにおけるキモなんだけど機能不足感があって
関数の引数がなんでも受け入れokな interface{} 型になるとかなり残念になる。
多分interfaceにプロパティをokにしたり
type interfceC =interfaceA | intrefaceB
(interfaceCはinterfaceA か intrefaceBどちらかを満たす 直和型ってやつ)
みたいな定義をokにしたり、シンタックスシュガーだけど
type interfceC =interfaceA & intrefaceB
みたいな定義もokにしたら幸せというかジェネリクスに進化できる気がする
>>52 はまる、はまらないで言ったらやっぱり……いや、もう何も言わないよw
何か得意分野があるってだけでその言語は魅力的じゃないの? rustとか言語ヲタじゃないと触ろうってならないし。 goはCLIツールを作るためのライブラリも揃ってるし ツール作る系でもおすすめ
他の人もそれを踏まえて、って誰も勘違いしてなくねえか? 呆れるやつ、ASTいじりはいいぞ、気に入ってる点、諸々。 語るに落ちられてバカさらされて、なんでこんな言われなならんのだ。
>>57 まじかよ!JavaScriptならevalできるし無限増殖できるぜ!って思ったけど、
俺が思ってたASTのフォーマットとものすごく違ってた。
これ完全に文字ベースだよな。
もうちょっとファンクションベースなものを期待してた。
メトリックスをASTから抜いたツールもあるようだが、これ相当死ねるだろ。
http://azu.github.io/slide/JSojisan/#7 まああくまでパースした直後のデータで、だからこそすべての用途に使えるってことなんでしょうな。
ただ、ここからコード生成も相当死ねると思うが。
見えないフリしてないで
>>48 を百回ぐらい読んでこいよ。
そして長文で語れよ。
空回りしてて荒らしでそれもわからないバカなのは誰なのか、どうすりゃいいか
>>41 読んで考えろ。
>>56 interfaceのプロパティってのは何に使うんだ?
俺は一応、Goのインタフェースシステム「実装してたらその型として使える」はありだと思っている。
平べったいダックタイピングというか、C++のtemplateを野良で転がしているのに近い。
貧弱かどうかって所まではまだ味見できてないから分からない。
直和や直積(でいいのか?)は別名でテンプレート書け、って文化なんだろ多分。
割とベタが好きな言語なんだと思うよGoは。
虚しくなるわ。悪かったな。interfaceの実装知ってて。
>>62 escodegenがこれ食うからいいんだよ
>>65 の訂正
× 別名でテンプレート書け
○ 別名でインタフェース書け
とにかく汎用ライブラリを作ろうとするなり触ろうとするとinterface{}型が登場するのは機能不足によるものだからもっと頑張れ。 と言いたい。コード生成で頑張るべきなんだろう。 goaはコード生成に頼りまくりのおかげでinterface{}型に出くわすことがなくて幸せ。
>>69 interface型は宣言がそうなだけで、実際には型持ってるから、そこまで嫌わんでも良いんじゃないの?
default書くのをサボらなければそうそう死なん。
>>70 んなこと言ったら動的言語だって内部的には型を持ってるよ。
問題はintereface{}型が関数パラメータに使われた場合、
Printlnみたいになんでも受け入れ可能って意味ならいいんだけど、
実際にはGoの表現力が不足していて仕方なくってパターンが多い。
>>71 動的言語の良いところを取るべくして、ただのvoid*には無い機能をもたせてるんよ。
表現力が足りないと言うより、ではなくて、本来は型にアサーションするんじゃなくて、別の任意のinterfaceにアサーションして便利に使おうね、って感じの思想。
だから、printf渡すだけでも、%sで渡すとStringerとして扱われたり、%+vで中身が見れたり玉虫色の解釈が出来るようになってる。
何でも受け入れ可能だから形無しinterfaceではなくて、こいつの型は提示せんがフォーマット文字列の通りに扱えよ、という意味であの引数。
だから、interfaceは明示的に実装しなくても、満たす関数があれば自動的に実装されるようになってる。
俺が今こうinterfaceを宣言して、そうするとこの構造体には自動的に実装されてるはずだから、俺は与えられた引数を宣言したinterfaceとして扱うってアサーションがかけれる。逆に言えば、俺に処理してほしけりゃこれを実装しとけ、って発想。
後出しジャンケンみたいなジェネリクス。
話題()の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が足りてないとか大嘘。 長くて読んでないけど静的言語を使いたいものとしては極力コンパイル時に解決したい。interface{}に頼ると実行時エラーが発生する可能性が増えてエラー処理の記述量がふくらむから嫌いなの。 それだけ。
そりゃまあ、便利さとリスクの天秤でしか無いわな。 あとからStringerにして、そいつの中で実行時に死にうるコード書いたら、全くソース変えてない部分で実行時エラーになるんだし。 実質sprintfなんか使えないコードになってしまう。
まぁ、interface受けてるのにアサーションしてないとか、default書いてないのが一番悪い。 defaultはエラー処理じゃなくて正常系。
親切な人が多いけど、ウンコが混じってもコミュニティの役にはたたんよ? リーナスも言ってるでしょ、基本的には去ってもらうこと、これが最も良い解決策。 向上心が有るなら別だが、基本が納得出来ないなら「どうぞ、どうぞ」が一番良い
>>77 デメリットと言うより、必要悪だろ。
一切キャストしないCも書けるが
このスライド出す時点でナンセンス。
PHPの変数は暗黙的変換で無残なことになる、数や名前や型の不一致はそれこそ、毎度構造体を作る事によって引き起こされる。
val,ok := アサーション
でokが見れるという点で殆ど対応できる。
Bugクラスが未定義、と言うところもおかしいわな。
interfaceを実装してればそれがなんであれそのinterfaceとして扱えるように、ライブラリ書くだけだろ。
ただの型チェックの防御的プログラミングとは違う。
interfaceとのチェックと、interfaceに任せる事での、そのロジック内での処理と切り離した、interfaceへの責任転嫁に近いが、
interfaceをいかに正しく定義、実装するか自体が問題であって、型は無くて良いよねって言ってるわけじゃない。
オブジェクト指向だと考えるのが一番いかんな。 ToString()を全ての型が実装してる、と言う発想じゃなくて、 プリミティブはあくまでプリミティブ、Stringerならば、Stringerとして処理できる、という逆の発送。
よーく読んだら、このスライドで話してることが(責務の分担(interfaceとinterfaceへのアサーション)、 疑いがあるならば即落とすべき(panic)、 mixedでのリターン(標準)、 クラスが未定義の場合何をするか(defaultでの無視)) と、全くGoのinterfaceでの設計意図と矛盾しないことぐらいわかるだろうにな。 世知辛いわ。
>>81 の言ってることが全く理解できないのは俺だけかな?なんだろういくら話してもすれ違い感が半端ない。
誰か翻訳して!
>>82 お前が、interface{}を、なんでも渡せるvoid *的な物として考えてるから理解できんのだろうな。
コンパイル時に誤りに気づきたいのは、要は、動作させるまで正常に動くことが保証できないのがいかんのでしょ。 あとからファイル足して、既存コードの動きまで変わる(シグニチャがあってればinterfaceが実装される)言語で、何言ってんだってレベルの話。 どう動作させても最悪、処理対象外データとしてスルーするようにdefault書くのと同じようなもんで。 本気で適当にgeneratorで作った得体のしれないものを関数に渡してるような奴でもあるまいし。 すれ違い感半端ないのわ俺だわ。 何か俺が書いたこと間違ってる?
どう動作させても最悪、処理対象外データとしてスルーするようにdefaultに書いておくのと同じようなもんで、形チェックに通るか通らんなんか、ポインタがある時点でどのみち同じようなもんで、と書こうとしたら大事なところ抜けたわ。ごめん。
なぁ、俺が持ってるGoの知識は古いのか? 1.8まではソース大体読んでたが。そんなに読み違えてる? ソース読んで、設計思想まで理解したやつが「黙れ」って言うならもう黙るわ。 今まで俺が書いてたような内容は標準ライブラリがほぼそのまんまの事してる内容ばっかだよ。 fmt.Printfだけでも一読の価値はあるんだが。 もう好き勝手書いてろと思えてきた。
これ、virtual持ってないよな?ジェネリックなんてまるでやる気ないだろ。
OOPが暴走気味でデザパタ廚のようなゴミを再生産しているのは事実として、virtualなしはいかんだろ。
それに対しての
> 多分interfaceにプロパティをokにしたり (
>>62 )
なら全くもって同意だ。というか、JavaScriptはこれができて便利すぎる。
むしろあれがC++に入らないのが不思議だ。
継承や委譲をこねくり回してデザインパターン(キリッするよりは、
JavaScriptのようにメソッドも第一級オブジェクトにしてしまって、簡単にvtblを手組できるようにした方が、
「見りゃ分かるだろ」的なソースを作りやすい。多重継承も楽勝で対応できる。
Goは多分行き過ぎたOOPの反省でinterfaceが1階層しかなく、この点はいいが、
せっかく第一級オブジェクトな関数をメソッドに代入できない点が糞だ。
これはinterfaceをプロパティバッグにしてしまえば解決できる。(62の指摘はこれだと認識している)
動的対応がいやなら再代入禁止で2パスコンパイル
(インタフェース解決+オブジェクトコード生成)にすれば対応可能だ。
Goの作者はよほどOOPが嫌いか、ジェネリックなんて不要と思っているのだろう。
Goのinterfaceは静的ダックタイピングのためのものであって、記述コードを減らすためのものではない。
俺はこの点は全く気に入らないね。というかコードを減らす努力がGoには全く見あたらない。
おそらくそれがここ20年のソフトウェア産業の努力の方向だったというのに。
すまぬ、安価間違えた
>>87 内安価は62ではなく
>>56 ちなみに味見の結果は出た。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の方が圧倒的に多いのも事実だし、 関数型()みたいにポシャっても全く不思議ではないけど。
そうですか、ではそのように他の言語をお使いくださいな。
一歩引いて、ハサミを買ってきた奴が、 「これカッターナイフみたい使えねえじゃん!クソカッターかよ!クソだ! え?挟んで使う?馬鹿じゃねえの?俺はこれが切りたいから刃を立ててるの! 刃物で挟むとかちょっと違うオペレーションじゃん?それって効率悪いし、危ないだろ、考えろよ。 こんなもの、カッターナイフのかわりには成りはしないね! 断然カッターナイフだわ。ほんとクソ」 ってドヤ顔するのを見るのもちょっと面白いな。
馬鹿とハサミは使いようだが、馬鹿にハサミは使えないもんなんだなあ。
>>87 56だけどまぁ分かる。今TypeScriptでジェネリクス使いまくってるけど
やはり静的言語に自由度を求めるとジェネリクスがほしい。
でもGoの言語設計ってコード生成しようぜって匂いを感じる。
パッケージ内に生成したコードを置けば自作の型にいくらでも機械的にメソッド追加できる。シンプルな構文でこういう自由度を確保してるのは良く出来てる感ある。
問題はコード生成するコードを書くのが大変ってことなんだよねw
コード生成するコードを書くための仕組みがもっと簡単になればかなり使い勝手が良くなる。
実際ジェネリクス自体コード生成するためのコードをショートカットした技術って感じがする。だからちょっと複雑なことをしようとすると難しかったりする。
コード生成するためのコードは素朴な分そういう頭がこんがらがる感じはないかなと。
なんでジェネリクスが使えるか、型引数がジェネリクス関数の中で行う処理で必要な演算子やらメソッド呼び出しを実装してるか、だろ。
だったら、そもそもinterface受ければいいだけじゃん。
>>56 でやりたいであろう直積も和も、interface側ではなくて、構造体側がどう実装するかでしかないし、
それも各構造体で両方実装するとか、各構造体を埋め込んだ構造体書くだけじゃん。
それは、型のないinterfaceで受けるべきじゃなくて、パブリックな「型のあるinterfaceで受ける関数に」から、プライベートな「型のないinterfaceを受けるが中でアサーションしてる関数に渡して」やるだけじゃねえの?
その設計が面倒なら、ジェネレーターで組み合わせ爆発起こして遊ぶべきなんだろうが、
実際は型付きinterfaceで事足りないか?それ。
>>93 > でもGoの言語設計ってコード生成しようぜって匂いを感じる。
俺にはその嗅覚はないが、状況証拠からするとこれはその通りだ。公式ブログ(URL後掲)もあるし。
標準コマンドに go generate とか、最初からASTを見せる気満々とか、iota とか、ちょっと行っちまってる。
そしてパッケージ内に階層がなく、 cat >> で全ていける。コード生成に障害が何もない。
首謀者は一般のプロダクトプログラマではなく、
サポート側のプログラマ(Perlでlinter等の作成とか)だったのかもしれんね。
C++のテンプレートはちょっと行き過ぎてしまっていて、余計に見にくくなってる。
例えば、形式的な無駄関数呼び出しがありまくったりする。
しかしそれらはコンパイラが最適化で抜いてくれるので、彼らはそれでよしとしている。
C++erの最優先はオブジェクトコードであって、ソースコードではないんだな。
無駄に回りくどくなったソースを見せられても困るんだが。
しかし考えてみれば、テンプレートなんて所詮はコピペだから、機械的に吐き出すのは極めて簡単だ。
人間がゴリゴリテンプレートを書くのではなく、
自動コード生成前提で、そのために基本ベタ書き、ってのは逆転の発想だがありだろう。
いや正確に言うと、Cのマクロの基本はコピペ的使い方だから回帰か?
とはいえCのマクロもC++のテンプレートも濫用が過ぎてるのは事実だ。
ベタなコードを自動生成してしまえ、ってのはありだろう。
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 する、とか。
上書きしない理由は、本来想定された用途がinterfaceを実装すべくレシーバをもった関数を生やすためだろ。 同一パッケージなら別ファイルで良いんだから。 こりゃ、2にもジェネリクス入るか微妙だな。 欲しい欲しいて声が挙がっても、要らんだろと言われ続けてるのがなんでかわかったわ。 既存機能すら理解してない奴らが欲しいって言ってるのか9割なんだろうな。
そもそも、「ジェネレータ」なんだから、既存のものを上書きするものでないのは自明だろ。 新しいソースをジェネレートすんだよ。
>>99 純然たる日本人だよ、たどれる範囲では。
日本語が解りにくいみたいなそういう言いがかりはナンセンス。
そもそも解りにくい日本語を喋れるのは日本人だけだ。
解りにくい○語を話せるのはネイティブ○語話者だけと大きくも言える。
韓国人が日本語の語順が不安定な部分使ってニュアンス出したりとか、逆にきちんと定義されてる言葉の使い分け使って煽れる訳ねえじゃん。
その結果例え解りにくいものになったとしても、あとから学んだ言葉が不得手な場合の解りにくさとは全く違う読みにくさが生まれる。
英語少々喋れても、口喧嘩はできなかったり嫌味が言えないのと同じようなもん。
>>100 > 解りにくい○語を話せるのはネイティブ○語話者だけと大きくも言える。
そんなわけねえだろドアホ
韓国人はマジで死ね
>>101 理屈が通じないなんて、まさかそんな日本人、現代人離れした感覚持ってるとは思わなんだ。
説明には充分注意を払わないといかんな。
ASTの話題にちょうどいい動画見つけた。
エディタの壁を越えるGoの開発ツールの文化と作成法
VIDEO >>96 go generate自体はただのコマンド実行なんだから
上書きするコマンドを実行させちゃえばいいと思う。
作法としてNGってことなんかな。
windowsで開発していると goで作成した実行ファイルを実行するたびにアンチウイルスソフトのAVGが起動して スキャンを始めます goがコンパイルしたプログラムをスキャン対象外にする なんてことは出来なそうですし、スキャンをオフにするしかないのでしょうか?
>>105 gopath以下を検索対象外すればいいのでは?
>>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厨化してる。
やることを「減らす」スクリプトを書かなければいけないのに、「増やす」スクリプト書いてどうするんだよ、というね。
96にあるようにjson用に構造体にタグを機械的に打つツールは既にあるよ。 もちろんそういうことを知らなきゃ、 冗長なコードを手打ちする羽目になるけど、 知らなきゃ苦労するのはどの言語だって同じだし。 俺はむしろgoの構文のシンプルさって人間が修正するだけじゃなく、機械が処理するためでもあるんだなって感動したけど。
>>108 あ、id の話か。
どうだろうね。IDでもidでもIdでも良いとしたら、つまりプロジェクトとして構文規約を作ろうってことになるよね。
それを始まりとして、プロジェクトによってコードの書き方が違うという分断化が起きる。
>>110 Goの言語仕様が糞でなければ、そんなことは最初からする必要が無い。
Go信者にはこの観点がまるでない。
100歩譲って、jsonのEncode関数にスイッチがあってもいい。
しかしそれもないだろ。
Goの仕様なんてかなり糞で、こんなのを教科書にしてたら勘違いすると思うぞ。(
>>43 )
いちいちやってることが回りくどすぎる。K&Rと正反対だ。
(ただしK&Rはこれまたさっぱりしすぎているが)
とはいえ、ここは合意を形成する必要はない。
俺はGoは糞だと思うし、今後使うことは多分ないだろう。
君がGoに賭けるのはもちろん自由だし、そうすればいい。
>>112 なら黙って去れよ。つかえねえなぁ。
そもそも、単語単位で命名規則決まってるからlint簡単だし宗教戦争起きないようにしてるんじゃねえか。
go runしか走らして無いんじゃねえの?
>>112 所詮はツールだから宗教戦争にしかならないのも確か。
vim vs emacs的な。
ちなみに一番理想的だと思ってる言語は何なのか知りたい。
俺自身はgoの言語仕様に欠点があるのは認めるよ。
でも、どの言語もコモディ化で割と似たような言語仕様になる中、独自性があって、素敵だとも思う。
何か言語設計者に信念を感じるんだよね。
ジェネリクスが熱心に要望されてる中、
未だに入れないのも何かもっと新しい手法を編み出そうとしてるんじゃないかと妄想してる。
phpなんか、片っ端から言語仕様足しまくってるし。動的言語のくせにinterface入れてみたりとか。
でも確かに最初に触る言語をgoにするのは危険かも知れない。
あとgoはast周りが充実してるってことは究極自分の理想言語を作ってgoのエコシステムを乗っ取るって手もあるよね。 rubyの作者が作ろうとしてるstreemって言語もgoをベースに作ろうとしてると聞いたし
Goの欠点と言えば、一度使い込むと他の言語で書きたく無くなる事だな と言うか他をリーディングする時点でストレスを感じるようになる Goならこう書いてこの辺りを並列したい、と読みながらGo脳になっちゃう
null安全な言語じゃないのはなんとかならないかな。 後付で実装するのは無理があるよね。下位互換性重視する姿勢みたいだし。
nullはなぁ。 unsafe使うともう闇過ぎるし、cgoとかでさえnullがある他の言語とやりとりできるし、 Kotlinみたいにvarに対してvalとか書けるようにしていったとしても、どのみち誰かが!(に相当するもの)で壊すかもしれない事に怯えるハメになるから、 最初から「nilかもしれないからチェック」って意識付けをさせてるのかもしれん。 タプルでerror帰ってくるのを無視するには_が必要みたいな感じで。
アンケートを募集してるみたい。
https://blog.golang.org/survey2017 とりあえずnil safeな言語にしてくれってお願いしてみた
>>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回書かないと無理」みたいな構造的問題は(多分)ない。
> でも確かに最初に触る言語をgoにするのは危険かも知れない。 「いちいち書くことを良し」とするのはまずい。 (昔の意味での)コピペプログラム推奨になってしまう。 これを嫌って、「いちいちスクリプトで整形」なら確かにありなんだけど、実際は書いたほうが早いから書くでしょ。 初心者がスクリプトを書けるわけも無いしね。 メタプログラミング「推奨」ならいいんだけど、メタプログラミング「必須」ってのは多分間違いなんだよ。
> ちなみに一番理想的だと思ってる言語は何なのか知りたい。 (俺は言語コレクターではないのでバリバリに使ってる言語は数えるほどしかなく、偏っているかもしれんが) ないね。俺は「全ての状況で使える言語」が必要とは思ってない。使い分ければいいだけだ。 そして現状の棲み分け状況を基本的に肯定的に捉える。それは集合知としての結論である、という見方だから。 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が混ざっていてジェネリック出来ないとか、あれは標準化委員がコード書いて無い。 (ただしこれについては直せる範囲だからさっさと直せ、と思う)
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とか言っているし、何に使えるのかよく分からん。
実装は他人に任せてシステム設計に専念する方が良いんじゃないかw
大演説ご苦労だな。 アッパーキャメルも、型が後ろにつくのも、アンダースコアを避けるのも、大文字の定数を避けるのも、Pascalじゃん。 :=で普通は気づくが。
>>124 Uniform Resource Identifiers
https://www.sqlite.org/uri.html に書いてあるURIフォーマットを使えば良いんじゃないかな。
db, err := sql.Open("sqlite3", "file:hoge.sqlite3?mode=ro")
みたいな。
JSONがアッパーキャメルじゃない?でもGoはアッパーキャメルだ、だから歪んでる? ならなんでjsonパッケージにtags.goがあるんだよww 間違いじゃねえよ、そのままタグ書かずにMarshalするからだろ。 ホントドキュメント読まねえやつだな。 「一回間違って使えば誤解する」の間違いだろ。 database/sqlに、ファイルのオープンに依存する関数あるわけねえじゃん。だってsqlのパッケージなのに。 ドライバにやらせろよ。
>>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も間違いなく同レベルだ。
>>130 Goでもアッパーキャメルで出すもんじゃねえよ。
ドキュメントに書いてあるでしょ。
変数名が何故あの形かも書いてあるし、一度でもちゃんとfmtから順番にツールにコード通していけば小言が読めただろうに。
xamppは一番無難な初期iniで使うのかねえ、ベルリンで。
要は SQLite の URI format を知らなかったんだろ?
そもそもsqlパッケージ自体使い方わかってないんだろ。godoc読んだ形跡がここまで無いのも凄い。
略語が全部大文字どころか、こまごまいちいち指定してこられる事のメリットは、あとからインターフェイス書くときだよ。 関数名のブレようが無いでしょ。
>>121 >> でも、どの言語もコモディ化で割と似たような言語仕様になる中、
>結局ソフトウェア技術も成熟しつつあるってことだよ。
>どう書くべきか、何をやってはいけないのか大体わかってきた。
ここに俺は異を唱えたい。
言語の方向性は歴史的な圧力が絶対あると思う。
仕方なく大多数が採用したから新言語でも採用したみたいな。
例えばclassとstructってなんで2つあるの?って思ったことない?
cの頃はstructはただの構造体だった。もちろんcにはオブジェクト指向の機能はないからstructにメソッドは生やせない。でもその後後発の言語はstructを拡張するのではなくclassを作った。でもsturctはそのまま残した。
swiftでも残り続けてる。値型と参照型の違いということで残したみたいだね。
意味がわかんない。
例外処理
例外が発生する可能性がある関数とない関数でコンテキストが大きく変わる。
そもそも例外処理って横着機能でしかないと思うんだけど。
そんなわけでgoはこの歴史的な圧力に対して異を唱えている。
それは本当に正しいのか!って。
>>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はここに位置できる。
そこで好き勝手やってみるのも悪いことではない。それでどっちが残るか勝負すればいい。
>>135 > 例えばclassとstructってなんで2つあるの?って思ったことない?
それは歴史的「圧力」というよりはただの後方互換性だ。
冗長といえばそうだが、かといって削除するほどのことでもない、ということ。
C++のstructとclassなんて、デフォがpublicかprivateかの違いしかない。
当然、明確な使い分けはない。では実際どうするかというと、
クラスとして「主体的に動作をする」のか、データとして「外部から操作をされる」のか、で分けるのが一般的か?
つまり、お前らが言うOOPか手続きかで分ける。
しかしこれは、初心者にとっては意味不明すぎるのも事実。
おかしいだろ!整理しろ!というのはごもっとも。Goがstructだけに絞ったのも、別段問題ない。
ただ、これで生産性が上がるわけも無く、だから他言語では放置されてる。
なんつーか、どうでもいいわな、というところ。
> そもそも例外処理って横着機能でしかないと思うんだけど。
その通りだが、要するに、よく使う機能だから言語側にサポートを入れた、というだけ。
無ければ伝言ゲームをする羽目になる。
自前のオレオレ伝言ゲーム構造体よりは、言語側で規定してて言語機能に入っているほうがマシだろ。
ただここに至ってGoの実装はよく分からんね。
あれは自分で「毎回チェック」してthrowするのが必要なだけで、panicした後は従来の例外の様に動く。
catch/finallyでグダグダ書くよりdeferしろってのは一理あるが、
例外を使いたがっている奴はそもそもの「毎回チェック」を書きたく無いからだろ。
Goの例外がどういった層に喜ばれるのか(どういうメリットがあるのか)よく分からん。
>>136 同意する部分は多々あるよ。
>「Goは覚えることが少ない」なんて言っている
>実際はこの手のGo特有事例(方言)がものすごく多い
シンプルさを意図して実際は中味の複雑さがにじみ出ることは多々ある。
nilでも型があるとかね
https://golang.org/doc/faq#nil_error だから蟻地獄的なものはあるかも。
>「C++はプログラマを育てる言語だ」と禿は言っていて、実際にC++の連中は育っている感がある。
これは知らんかった。禿って誰のこと?
正直C++勢と会ったことはない。web系と断絶してる感じする
なんで育てる言語がC++なの
>だから常識的にプログラミングするといちいち引っかかってしまう。熟練者にとって生産性が著しく悪い。
>(ところが他言語を全く知らないド素人にとっては生産性が悪くないのがミソ)
もしかしてIDE使ってないの?vscodeとか。
俺もTypeScriptとかいろいろな言語を使ってるけど
言語仕様で引っかかってもその場でIDEが指摘してくれるから、生産性に問題は起きない。
そもそも第一言語としてGoだけ使うって輩はないだろ。多様性を楽しむくらいの余裕があってもいいと思うけど。
関数型も書いてて楽しい。Elixirとか。Haskellはちょっと挫折した。
ちょっとぐぐってみたら面白い記事を見つけた
http://gihyo.jp/news/report/01/GoCon2014Autumn/0001 言語が思想に影響するという説(サピア=ウォーフの仮設)
があるからあえてGoにはあなたが方言と言ってる違いを設けて
多様性を確保したいらしい。
>>138 ヒープに値が乗るかポインタが乗るかで全然違うだろ。構造体とクラスは。
後方互換製でも何でもなく、使い分けとるわ。
>>141 概念としてそれをclassとstructに分ける必要あるかって話。
>>142 使い分けてるんだから、必要あるってわかるだろ。
ベクトルなんかをそこそこの量処理したいとき、そのベクトルを表すものがクラスか構造体かでかなり違う。
彼が言ってるような歴史を辿ってきたJavaやC#みたいなGCを持つ言語だと、GC対象か否かという点でもメチャクチャ違う。
>>140 > 同氏は,Go言語はスケーラブルなクラウドソフトウェアのために設計されたきれいな手続き型言語であると述べていました。
あーなるほどね。反OOPか。
Cが生まれて50年弱経ち、ソフトウェアテクニックってのはほぼ固まりつつある。
その状況で若い連中が何か新しいことを思いつき、しかしそれを老害が腐してそのアイデアが埋没してしまうようなら、
それは勿体無いから、若い連中用のプレイグラウンドはあるべきだ。Goはそれに成り得るだろう。
ただし、そこで試されるアイデアの大半は既に誰かが試してゴミだったからポシャった物であり、
つまり「歴史」ではなく「経験」に学びたい若者が「車輪の再開発」をする場でしかないわけだが、
それもまあ必要悪というか、更なる発展の芽を探す為には仕方ないのかもしれんね。
ただそれで無駄言語に傾倒することになる若者は哀れだが、自己責任だから致し方なしか。
心配せずともGo言語で何かめぼしい成果が出れば、C++他は数年後には確実にパクる。
正直、遅延評価を既存言語機能だけで丸パク出来たのには驚かされた。templeteの汎用性を俺は舐めてた。
Go言語で出る成果でC++がパクれない物はたぶんありえない。もともと似てるし。
OOPが暴走気味なのは事実としても、現実解としてOOPしかないからみんなOOPしてるわけで、
そこに刃向かうのはもちろん自由だが、それでpackageが解なの?うーん、といったところか。
それならCでいいじゃん、になってしまうし。
>>139 > 禿って誰のこと?
禿=ストロウストラップ=C++作者=
> 正直C++勢と会ったことはない。web系と断絶してる感じする
話してみたいのならスレにでもどうぞ。それがネットの正しい使い方でもある。
ただあいつらの話題って重箱の隅どころでは無いからなあ、、、
> なんで育てる言語がC++なの
知らん。禿が著書でそう主張している。そして確かにそんな感じだ。
おそらくC++の奴らは自分でいろいろ試して、結果的にいろいろひどい目に遭うからだよ。(追体験)
例えば、「グローバルガー」とか言うWeb系の奴、実際にグローバルが問題になるほどの規模のコードを書いたことがないだろ。
そういう、薄っぺらい馬鹿が威張っている感がC++erにはない。
C++erの場合は、実際に「便利だから」グローバルを使い、結果的に苦労して、
どの規模の辺りからグローバルはやばいかを知った後で話をしている。
そういう、地に足が着いている感がある。
一方Web系は「経験に学ぶのは愚者。俺達は歴史に学ぶ」と言い、この手の追体験を拒む。
そしてグローバルガーと連呼したりするが、実際にはその規模ならどうでもいい場合が殆どだ。
ここら辺が地に足が着いてない。教科書(歴史)を妄信してる感ありあり。
しかしそのわりにGoで経験に学ぼうとしているのは、結局OOP流に嫌気が差しており、自由にやりたいだけだろう。
(まあ気持ちは分からなくもない。JavaのOOPとか完全にやりすぎだと思うし)
それが自分達が言っている「経験に学ぶ愚者」に該当する自己矛盾に気づかないのが愚かなところだが、
Web系の連中にとっては経験こそが足りないから、色々やってみるのもいいとは思う。
今はソフトウェア技術の規模が微妙な時期なんだよ。 数学のように「全ての分野を網羅するには人生は短すぎる」程の広がりはなく、 これまでの全ての問題を一つ一つ追体験するのも無理ではない。グローバルしかり、ポインタしかり。 もちろんそれは無駄だとして「歴史」に学ぶのも一つの手だ。 ただし実体験と教科書の知識だけでは重みが違うから、そこらへんが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だけの世界を作ってるだろ。これが吉と出るか凶と出るか。
>>146 >Goは割と想定外のところでバグるんだよ。
>この点、実はJavaScriptはC的で、文法だけ抑えたらあとは、あー、はいはい、で行けた。
>だから俺(というかC使い)にはJavaScriptは相性がいい、というのはある。
どういうコードでバグったの?
>>148 そりゃ該当するのは君の言うnilとかだよ。
俺の場合は何度も言っているがJSONだ。
問題なのはこの原因が「Goの特殊仕様」であって、「俺の未熟な文法理解」ではないこと。
文法は一通りやれば終わるが、特殊仕様は確認しないと分からず、その都度の対応になる。
新しい領域に踏み込んだら毎回地雷原を歩かされるようなもので、これでは生産性なんて上がらない。
だからプログラミング言語には統一性/一貫性が重要だと言われるわけでね。
C++は今は何でもかんでも仕様に取り入れてる。
あれがいいかどうかはさておき、既に言ったように、Goで何か結果が出れば必ずC++は取り込む。
だったら俺はそれでいいや、という感じだね。
先頭を走らなきゃヤダ!ならGoに集まっている連中とワイワイやるのもいいのではないかな。
ただ、仕様を見る限り面子には非力感がありまくりだが。
そして当然、結果はそう簡単に出ないし、出ても簡単にパクられる。
それも覚悟の上でがんばれ、ってとこだね。
>>149 そんなの言語毎にハマりどころはあるから。
Goだけにある問題点みたいな言い方するから、
どんなのかと思った。
jsだってthisが何指してるかわからなくなる問題とか、独特のハマりどころはあるでしょ。
jsonの問題もjwgとか使えば自動的に理想的なtag付けしてくれるんで。使ってみては?
ドキュメントに書いてあることができないのが、何で未熟な文法理解に何故起因しないかわからん。 文法理解してるつもりなのに書けないのなら、語彙も足りないんだろ。 ってかドキュメント読めよなぁ。 特に難しい事もないじゃん。 なんか読めない理由でもあんのかね。
>>150 いやGoだけだぞ。
正確に言うとC系(ハロワ系)はCに意図的に似せて作ってあるからこの辺で問題が生じることがない。
俺は関数型には深入りして無いからそっちは知らんが。
君がGoだけかなり特殊だと気づかないのは、他に比べる手持ちの言語が無いからだよ。
ただそれもGoの意図通りのようだし、
確かに他言語の経験者が大量流入すると独自進化できない、というのはごもっともだ。
ジェネリック使いたければ他言語を使え、Goはジェネリックよりいい解を探してみせる!というのもありだろう。
実際、彼らの意図通り、俺みたいなC系経験者にとってはGoは魅力的ではないし、ひとまず静観といったところだね。
上手くガラパゴス化して面白く変化できるかどうかだね。
> jsonの問題もjwgとか使えば自動的に理想的なtag付けしてくれるんで。使ってみては?
これは逆なんだよ。
書かないことこそが素晴らしい、というのが従来型言語であって、俺はそっちを支持する。
そうではなく、自動生成こそが正義、というのならそれはまあがんばってね、という感じだが、
それも結局「正しく自動生成できているか」確認しないといけないんだから、
書くのと比べてやること減ってないだろ。
なんかそこらへんの根本的なノリが違うんだよなあ。
なお、
> jsだってthisが何指してるかわからなくなる問題とか、独特のハマりどころはあるでしょ。
これは違う。あいつらはマトモにオブジェクト指向も出来ないくせに主張するからおかしなことになる。
普通に使えば obj.method なんだから、thisが何を指すかで戸惑うことなんてない。
逆に、それ以外でthisを使うからおかしなことになるのだが、それは根本的に間違ってるんだよ。
(ただし仕様上、関数ポインタにはいちいちbindする必要があるが、これはすればいいだけ)
JavaScriptのthisガーって言っている奴は間違いなく馬鹿だから、無視していい。
ただそいつらが過半数な感じがJavaScriptが終わってるところなんだが、、、、
なんで糖衣構文ではなく、アロー関数が出来たんだろうねぇ。 まぁ、言ったからには、静観してくれたら良いな。
>>152 Goとjsで平等な視点で比較評価しているとは思えない点は目をつぶるとして
>それも結局「正しく自動生成できているか」確認しないといけないんだから、
>書くのと比べてやること減ってないだろ。
あなたの得意分野のCだって内部的にはプリプロセッサがコード生成してるけどそれを目視チェックしたこと無いよね。
隠蔽しているだけでコード生成を使ってるんだよ。
コード生成を嫌ってるみたいだけど、そして理解もできるけど 静的言語が動的言語並の自由度を確保しようと思ったらコード生成は避けれないと思う。 例えばちょっと前にあったdatabaseとの接続もそう。 コンパイル前にスキーマを収集して型を作るのが静的言語における最適解。 それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。 でも、そもそもコード生成嫌わないで。 生成したコードをデバッグ時に参照できるというのは、バグの解決につながりやすい。 Cで複雑なマクロを組むとエラーがわかりづらくなるけど プリプロセッサの出力を目視できるようにすると解決できたりする。 だから Goのコード生成もプリプロセッサのコード出力くらいに考えておけばいいと思う。
嫌なら使わなければいい 気に入らないなら思いの丈をブログにでも書いてくれ そろそろ黙れ
技術的革新について話すだけのヤツはクソだ、黙って手を動かせ、と言った奴を 自分が触ったことのないテクノロジを批評するのは滑稽、と批判してみせた奴 こいつが、その素晴らしい技術でLinuxを超える何かを世の中に残せたのなら説得力が有るのだが… 結局何かしらの技術を語ってる奴は総じてクソなのは揺るがない
>>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系言語出身者お断り仕様で計画通りなのだから、これはこれでいいんだよ。
>>158 >> それ以外は動的な解決(interface{}を使う)しかなくなり、静的言語としてのメリットを失う。
>ちょっとこれは厳しすぎ、というか、若干誤解しているか?
単純にIDE連携が静的言語としてのメリットって話
つまりコード補完する時にDBのカラム名が候補に出る状態にできるのが静的言語のメリット。
内部的に型を持つとかそういう話じゃない。
> Go:構造体を書き、タグ付けスクリプトを作成し、go generate してタグを付け、正しくタグがついているか確認 ← やること多過ぎ
じゃなくて
Go:構造体を書き、go genereteを実行する
だけ。正しくタグがついているか確認は不要。ツールを信頼してるから。Cのプリプロセッサを信頼するのと同じ。
aws lambdaに正式対応だから勉強してみるか
外部ライブラリで import "github.com/hoge/foobar" みたいにリポジトリ指定みたいに書いたりしますが そのリポジトリが無くなったら終わりってことですか? それと、forkした場合などはユーザ名変わるわけですがfork内のimport全部書き換えなきゃならんとか面倒ではないですか?
>>162 vendoring すれば良いんじゃない
ありがとうございます vendoring という機能を知りませんでした vendoringで解決できそうです
リポジトリあっても数年更新ないとかあるからな go-bindataとか
>>165 こういうのがあるとパッケージプロバイダを経由したほうが良いと思える。アカウントけされたらvendor使ってても無駄だよね
ビルドしたバイナリにソースコードのパスが含まれちゃうんだけどこれを抑制する方法ってありますか?
>>171 試してないけどgoupxとか試してみたら?
>>172 レスありがとうございます。
upxで圧縮しても解凍したらパスが出てきてしまうので意味がありませんでした。
https://qiita.com/kitsuyui/items/d03a9de90330d8c275c8 ↑みたいな方法しかないみたいですね。
なるほどpanic時に使う情報なのか。 でも本番では要らないなぁ
Googleが「Dart 2」発表、Dartを再起動。iOS/Android用ライブラリ「Flutter」と共にWebとモバイルのクライアント開発にフォーカス
http://www.publickey1.jp/blog/18/googledart_2dartiosandroidfultterweb.html APIサーバでマスタデータ的なものをグローバル変数として最初にDBから読み込んでおくのってアリな設計? memcacheとか使うのはもう少し流動性のあるデータとか、サーバ間できちんと同期する必要のあるデータ扱う場合って認識でいる
初歩的な質問で恐縮なのですが、 Javaでいう所のSystem.out.print(i + " ");のような記述は、 Goではどのようにすればよいでしょうか? fmt.Print(i + " ");とするとエラーになってしまうのですが…
>>179 分かりました。ありがとうございました。
intのabs無いんかい。 まぁ簡単に作れるからいいんだけど、、、なんで? ジェネクリスができたら実装するんかな
https://golang.org/src/sort/sort.go Goのクイックソートの実装を見ると内部でヒープソートとシェルソートをしているように見えるのですが
これはイントロソートの亜種なんですか?
Google CodeJam 提出言語をGoのみにすればGoの普及がもっと加速したんじゃなかろうか
go言語にc++17の [[nodiscard]]属性みたいなのないですかね?
ほう、検査例外みたいな機構がC++に出来るのか そりゃ楽しみだな
func calc(x int, y int) (int,int){ return x, y } var a int a, b := calc(1,2) みたいに定義済みのaと未定義のbに戻り値代入したいときって、 a用の一時的な変数を用意しないと駄目よね? なんだかんだ一年以上、疑問に思ったまま過ごしてる
もしくはbを先に定義しちゃうか どっちが一般的なんだろう
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 XC972
RDBをRedisとかでキャッシュしつつ、更新もしてるサンプルない? ラッパーの実装を参考にしたい
>>193 別にそのまま行けないか?
aに当たるのはerrだったりするよね。
>> 193
https://play.golang.org/p/l3eB4W6F5Qc こういうことね
そうするしかない。
「プログラミング言語Go」にも詳しく書いてあるよ。
>>204 ゴルーチンって何?
コルーチンなら知ってるけど
>>205 ハァ?その言語の識別子も把握してないの?死ねば?
FORTRANマイスターが他の勉強方法を始めたのかもしれん
呼び方とかどうでもいいけど 当たり前だけどcapacityはメモリ持ってかれるから チャンネルに飛んでくる数が不定な場合はstack使わないとgoroutine爆発する ググるとまさにってのがstack overflowにあったけど緩衝するのが普通なの? なんなんこれ
C言語に挫折してGoに来たけどやっぱダメでした ポインタも残ってるし、むしろCより覚えることが増えて難しくなってないか
自分でなんとかしてる capacity小さくても止めとけと、耐えろよと思うわけよ そのひと手間が普通ならなんだこれはと思うわけよ Go言語のスレが未だにpart 2な理由よくがわかった
スクリプト言語ばっか触っててGoに移行しようとして1月近く経ったけどシンプルなのは良いけど他だと標準で出来ることしようとしたら必要以上に複雑になるな
Go自体が他の次世代言語とくらべて低機能にしてある 複雑な機能つけても使いこなせない人がいるから単純にしてあるのさ それがGoの利点ともいえる
じゃあ俺go使いこなせないから言語ごと消えてどうぞ
行番号振ってVRAMアドレス意識してた古代からタイムワープして来たがLLのがむずい
Goでは定数同士の演算はコンパイル時に行われるという認識で正しいですか?
Goに限らずCでも最適化オプションオフにしない限りコンパイル時に計算してくれるんじゃないかな
cのunionとかpackされた構造体の扱いがめんどくさいな せめて自動でsetter/getterを付けてくれたらいいのに
僕もただのデータの入れ物的な扱いしてました、何年くらい前だろうか15年くらいかなぁ
Pyhtonの遅さに耐えられずGoを学び始めたんだけど 型の記述がしんどい これが何を意味するのか読み解くのに土日を要した func compute(fn func(float64, float64) float64) float64 {
ツアーof goからやらないと。型を後置する意味について分かるよ
Cの関数のポインタ型の分かり肉さに比べるとだいぶマシになったんやで
型無しやるとマジストレス、他人が書いたBugFixとかマジ地獄
>>231 typescriptが人気出たのもそれだよね
>>232 公式の解説にあったのよ。Cの型が読みにくいからGoはこうしたって。
ワイが池沼とか関係ない
>>226 四つのfloat64、二つのfuncで混乱してしまった
後置はVBAで慣れているのだが、 as がないとまるで別物に見える
スライスとかマップで普通に使いそうな関数を集めた定番のライブラリとかある?
>>235 cで関数を引数に取るようなのを見たら卒倒しそうだな。かなりわかりやすい方だと思うけど。単純に関数名や、引数名を取り除いただけだよね
今日学んだこと ・IdをIDにしろって注意される ・ログがインターフェイスじゃない
MongoDBのRESTインターフェイスを作って、windowsのサービス化まで出来た これでブラウザのユーザースクリプトでデータ使いまくれて捗る Goは始めたばかりだけどサクッと作れた。まったくすごい言語だわ
現在の時刻が日付に関わらずある時間帯に含まれるかどうか判定したいです time.Timeのbeforeやafterを使うと日付まで考慮されてしまうので いちいち時刻だけをとりだして比較しているのですが、もっと簡潔な方法ってありますか?
時刻取り出して比較する以上に簡単な方法なんて無いでしょ そういう関数なりライブラリが欲しいってこと?、無駄な機能無いのが取り柄だし必要なら作れば良いのだが 流石にt.Hourの比較程度を言語で抽象化するのは畑が違うとしか
趣味で作ってるアプリのAPIサーバーをGoに置き換えてみようと思うんだけど、 フレームワークはやっぱりechoが鉄板だと思っていいの?
goaもginも知らなかったよ、ありがとう。 とりあえずAPIサーバー用途ならgoaが1番良さそうだからこれ使ってみる。 気が向いたらrailsで動かしてるサービスサイトもどれかに移行するかも。
>>246 それはオライリー片手にやったけど、外に出せるようなレベルまで作り込むつもりはないw
ちょっとしたものならgorilla/muxだけでやってる
goaの肝はコード生成だから、結構素直なコードが生成される。 そのコード次第も勉強になる。 web apiの作法をむしろ教えてもらった。
変数への代入に := を使うか = を使うかはどうやって判断するのだろう 例えば for i := 1 は普通に for i =1 ではダメなのか
var unko = 1 unko := 1 下は上の省略形だと理解してるけど
>>254 ループ変数のiが先に宣言されてれば後者で良いけど、特別な理由が無い限りは使わないな
indexの値から開始したい場合、for i := indexとした方が良いだろ
:=を代入にあえて使う言語は=には透過性の意味を、:=には定義の意味を持たせて数学寄りにしてるだけだと思ってたが
Cしか経験ないのに Go言語でつくるインタプリンタとか 買ってしまった
奇遇だな、1週間くらい前にその本をAmazonのほしいものリストに入れたわ
失礼 インタプリタじゃなくてインタプリンタを作るのか
俺もその本読んでるけど難しいわ Token tokenToken とか、冗談だろみたいな記述がゴロゴロ出てくる 型強制言語はこれが嫌なんだよなー 本質的なロジックに関係ないキーワードでコードが埋め尽くされる
goって仕様がシンプルで習得しやすいって触れ込みだけど意外と複雑だよね。 直交性が低い「ここだけのルール」みたいなのが意外と多くて辟易する。なんだよrange節って。
すごく頭の良い人が合理性だけでデザインしちゃった感はある。直感的じゃない。 エンジニアだけで作った、便利だけど死ぬほど使いにくいWebサービスみたいな感じ。 まあそれでも他の最近の言語に比べりゃ覚えなくちゃいけないことの絶対量は少ないよ
色々な意味で異質だから慣れるまでは面食らうかもね 慣れてしまえばそんなことはなくシンプルで良い言語
夏休み使ってGo入門したけど、良いなこれ なんかのCUIツールでも作ってみたくなったけどアイデアはない
上の長文合戦全部読んできたけど、結局Goってバカでも使いやすくするために文明の利器を捨てたプリミティブな言語ってことなんだな
と思ったら
>>270 って書かれてるし、合理性のために無駄を削ぎ落とした言語なのか?
プログラマーに期待する事をやめた言語かな どうせバカしかいないんだから 管理・使い分けが必要な要素は与えない触らせない
実用的でいいんだよ。言語オタクな人には物足りないだろうけど
インタプリタはないのかなあ いちいちコンパイルすんのめんどくさい
二者択一じゃなくてswiftやkotlinみたいにREPLもあったら良かったってことじゃないの。
>>280 go run
じゃダメかね。コンパイルと実行を続けてやってくれる
goが生まれた経緯を調べるとなんでああいう言語が生まれたかわかる。 要は実用性重視で、過去の言語仕様見直して、削られるだけ削った言語と言える。 たぶん1番の使命はコンパイル速度を早くすることかな。
そういや昔Delphiが最速のコンパイラとか言われてた時代が懐かしいな
>>285 削って大丈夫な部分は全て削った感じよな
個人的にはいくらなんでも削りすぎな気もするけど、やるからにはそれくらい徹底しないとダメなんだろうな
>>280 Go言語でつくるインタプリンタ
を読んでGoのインタプリンタを作ればいい
>>287 そうかな?
やたら省略形とかシンタックスシュガーが多かったり、同じ構文で別の意味に用いられたり、
最近の言語にしてはけっこうごちゃごちゃしてるという印象なんだが。個人的には。
scala,rust,haskellとかむずい(;_;)
それは2000年頃のJavaのポジションか。ワイはペーペーで高給は取れなかった
>>289 予約語の数とか見てみればわかると思うが。
予約語の数は一つの目安だけどそれがすべてじゃあないよね。
記号はカウントされていないし他言語なら予約語になりそうな定義済み識別子がごっそり抜けている。
それよりも
>>289 で言いたかったのは、例えば型アサーションの構文に型名じゃなくて
予約語のtypeを渡したら型switch内で使えるとか、そういう一貫性の無さからくる複雑さ。
同じような構文に機能を詰め込むから表面上は予約語が増えたりしないわけ。
返り値型宣言したらreturnだけで値が返るとかか。 あれはいらんね
>>294 一貫性がないというより他の言語には無い書き方が引っかかるって感じじゃ無いかな?
それは理解できる。
どこをどう読んだらそうなるw 型アサーションの括弧に渡すものが型名のみに限定されていればシンプルだったのに、 それがswitchの中でだけ予約語のtypeを使うことが許されていたりするから一貫性がないって 言っているんだよ。
/\___/\ / / ヽ ::: \ | (●), 、(●)、 | / ̄ ̄ ̄ ̄ ̄ ̄ ̄ | ,,ノ(、_, )ヽ、,, | < まーたはじまった | ,;‐=‐ヽ .:::::| \_______ \ `ニニ´ .:::/ /`ー‐--‐‐―´´\
もともとグーグルの天才たちが内輪で使うために作った言語だろ? Cと同じで、俺ら凡才には理解できない・向かない部分があるのは仕方ないと思う
>>297 それに引っかかるのってせいぜい数時間だよね。
俺は仕事でさわるコードの一貫性のなさに苦しんでるけど、そっちのほうがしんどい。
一貫性が無いのは事実なのにズレた話で絡み続けるのはなんなんだ 場当たり的な構文糖衣も多いのに削るだけ削ったとか嘘もいいとこだろ 妙な幻想持ちすぎ
話の腰をブチ折ってすまんが、「Go言語でつくるインタプリタ」の 最終章のマクロ展開(expansion)のトコ、マクロを再定義しても元 の定義で展開されちゃうんだけど、誰か試した奴おる?
>>302 気に入らない事どんどん上げていきなよ。
他にはどんな問題を感じてんの?
やっぱりGo言語来そうだね。 だがGoogleでしか使えないのが心配。
Google様に逆らったらインターネットに住めなくされちまうだ
>>306 一応、念のため確認しておくけど、GASと混同してないよね?
>>314 え、まじで何の話をしてるか分からないからどういう意味なのか教えて
>>308 Googleのクラウドでしか使えないと思った
>>316 awsのlambdaとかで使えないのかと思っただけ
ああそういうことね なんか、割と根本的なところをあまり理解してなさそうだね
Node.jsとかPythonとかとは根本的に違うの?
はいはい初心者は退散しますよ せいぜい威張っててください 下らねえ
ちなみにNodeとかPythonとかとはすごく大きなところで違いがあって、それがGoたんの大きな大きな特徴の一つだったりする。
いつまでたっても具体的な噺が出てこないところを見ると あまり詳しい人はこのスレにはいないようだな
素直に教えてくれって言えよw もうここまで来たら誰も教えてくれないだろうけどw
もったいぶって言わないってことは そいつにとってそれが限界だってこと
実はGo言語のマスコットがとても可愛いんだ それが大きな違いだな
>>336 Pythonの間抜けそうな蛇よりははるかに可愛いだろ
マスコットで言えばD言語もかなり人気だけど言語自体を使ってる人って殆ど見たことないよね
D言語なんて存在は知ってるけどHello Worldすら書いたことがない
Plan9とGoは作ってる人が一緒(ケン・トンプソン)だからかな?
プロファイリングが簡単にできるのもいい…あるプログラムを調べて いたら、整数値の 2^n 乗を計算するのに math.Pow() 使ってる部分が あって、そこを直すだけで 15% 高速に
Plan9インストールしたことあるのはこのスレでは俺ぐらいだろうな
>>344 むむ。お主やるな。
BeOSなら俺もある。ブラウザが不安定で使い物にならなかった。
>>345 どちらも一応うごいた
くらい・・・
BeOSのほうがPlan9よりはうごいた
かな
隔離されてある程度守られて監視うけてるから死んでないよ。死んだことにしたいらしいが。
>>352 コイツがどうしたって?
お作法外と知りつつ、コーディング中の簡易的な動作確認としてテスト作ってfmt出力しちゃう 自動テストにゴミ混ざるしやめたいんだけど、どうするべき? 関数名引数で受け取ってリフレクション実行するようなプロジェクト作るとかしか浮かばない
>>357 俺もよくやるけど。必要な機能をテスト上で書き始めて、動かしてモジュール化して。
最後に必要なテストとして残る。
だからプロジェクトとしてなんの問題もない。
静的型付言語でリフレクション使いすぎるとあんまり良くない気がする
外部APIの動作確認とかから始まって SQLにレコード追加するバッチ処理を1件分だけ回すやつとか きれいにテストに昇華させてく、は間違いないな
学習し始めたからスレ見に来たら結構やべーやついたんだな…
5ちゃんだぞ。やべー奴しかいないに決まってる。 俺もお前もやべー奴だ。
go modでGOPATHのsrc以下にある自分のパッケージはどうやって使うの? // main.go package main // import "a/b" import "a/hello" // go.mod module a/b $ go build build a/b: cannot find module for path a/hello
おい、Go2がアナウンスされたのになんで誰も話題にしないんだ
1.11がリリースされても誰も話題にしないし もうこのスレは死んでるんだよ
Errorのハンドリングで迷い出してんのな、今の仕様の方が時点の処理を考えるようになったし 冗長に見えるが実際堅牢さに貢献してると思うのだが
>>366 go mod も自作パッケージ使う場合は src 以下で作らないといけないんですかね?
// import "a" とか // import "a/b" みたいな src 外では自分のパッケージを使えないということなんですか
>>369 んー。でも冗長コードはあんまり書きたくないし、良いことじゃないの?
>>371 俺もそう思うんだけど、これは思想の問題だから揉めそう
確かに思想の問題なんだよな、例外的なの望んでる人は大抵デプロイするまでのプロセスの簡略化 現状で良い人は少ないと思うけど、リリースしてからの堅牢さを実感した人らで双方のステージが違う感じがする
そういえば os.Exit() だと defer で登録した処理が実行されない、って 仕様はそのままなのかな
ところが runtime.Goexit() の場合はしてくれるんだよね…
go触ってみようかと思うんだけどどこまで低水準なこと出来る? Cと同程度?
基本サーバアプリとモバイルアプリだけど、組み込みに使えたりするのかなと
グーグルの中の人のインタビューを雑誌で見たことがあるけど 組込みには向かないって言ってた 動的型付けやリフレクションをサポートするための情報がバイナリに入るので サイズが大きくなるとか あとガベージコレクションのある言語は、基本的に組込みには向かないんじゃないの?
mapをmakeで作る利点は何ですか? m := map[ int ] int {} と m := make(map[ int ] int) は使い分けする場合があるんですか?
空 map 作るなら全く同じ 前者は値の初期化ができる m := map[int]int{1, 10} 後者は map のサイズを指定(メモリ獲得)ができる m := make(map[int]int, 10)
OSがない環境だとGCなぞ動かすランタイムも一緒に移植しなきゃいかんでしょうな
最近致し方なくGoを触ったが忌み嫌ってたほど悪くない むしろいいね! 食わず嫌いはよくない
まわりがJava信者ばっかりでGoを使ってくれない SpringBootに慣れすぎて移れないとか
Javaで済むならそのままでいいのでは。 いままでのノウハウや資産を捨ててまでGoを使うという決断は中々大変そう
自分では何も選択しなかったヤツがJava使ってるんだから 今後も新たな選択とかできないだろ
Javaの開発が止まったとか大事件がなければそのままでもいいんやで。 あとは、Goにした方が明確に経済的メリットがある状況になるとか
今流行ってるものは別にGoだけじゃない Pythonだってブームはまだまだ全盛だし Rustだって最近は注目されてきてる React NativeやElectron、Nodeみたいなブラウザ外のJavascriptだって流行りと言えば流行り
そもそも何を持って流されてると定義するかという哲学的な問いかけをされている気がする
別に流されることを否定していない javaの連中はおれも嫌いだけど、goの連中が揶揄するのは笑い種だ
javaの連中ってのもものすごいラベリングだなw 書いてる言語で人を分類してるのかw
―┼‐ ノ / | --ヒ_/ / \ヽヽ ー―''7 `」 ┼, 二Z二 レ / /´レ' \ ―7 ̄} | ー-、 / (__ (|フ) (__ノ _ノ ∨` ノ / / _ノ \_ ─┼- / | ‐┼- | ー|― ─┼─ | \ レ /  ̄Tー / ノ -─ (二フヽ \/ _ノ (二フ\ ヽ_ノ / 、__ i';i /__Y ||真|| /⌒彡 _ ||露|| /⌒\ /冫、 ) ・・・・・・。 \ || || ̄ ̄ ̄ ̄ ̄ ̄ ̄\ `./⌒ i ` /ゝ _,,..,,,,_ ||\`~~´ (十万石) \( > ('\\ ./ ,' 3 `ヽーっ ・・・・・・。 ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄\`つ ⌒ _) l ⊃ ⌒_つ .|| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|| `'ー---‐ ( 'A) ・・・。 〃∩ ∧_∧ <⌒/ヽ___ /(ヘ)ヘ ⊂⌒( ・ω・) ・・・。 <_/____/ zzzz・・・ `ヽ_っ⌒/⌒c
Javaしか知らない人の反応 ・クラスも継承もないとか時代遅れも甚だしい ・例外を使わないエラー処理なんて考えられない ・Javaは20年以上の歴史があり、極めて安定しており実績が豊富だ ・Oracle様が万全の態勢でサポートしてくれるので今後も安泰だ ・Goはホビー向け言語で不安定でビジネスには使えない ・Mavenは最強だ。他の言語にこんな便利なものはないだろう ・Goに乗り換えたときの経済的利益を具体的な金額で教えて下さい ・金額を出せないなら、移るメリットがないってことですよね? 想像だけどw
分散メッセージングなんかはJavaの独壇場だしなあ 分散システムは大規模運用で叩かれないと バグが全然減らないから実績が実力に直結する
>>403 オブジェクト指向にクラスも継承も必須なのか?という本質的な問いかけを投げかけた。
そもそも継承を重ねすぎてわけわかんないことになってるのがjavaだったわけで、
javaに問題点を感じなければgoみたいな言語仕様は生まれなかった。
/\___/\ / / ヽ ::: \ | (●), 、(●)、 | / ̄ ̄ ̄ ̄ ̄ ̄ ̄ | ,,ノ(、_, )ヽ、,, | < まーたはじまった | ,;‐=‐ヽ .:::::| \_______ \ `ニニ´ .:::/ /`ー‐--‐‐―´´\
自分はクラス設計もデザインパターンも全くわからないプログラマなので クラスがないGoは天からの贈り物
goは実験的な言語であって、明確に何かをリプレースしようと開発したわけじゃない 過去最もリプレースが進んだ言語といえばcobol→javaだと思うが、 それはcobolとは比べ物にならないほどjavaが便利に洗練されていたから 俺はgoにそれほどのポテンシャルを感じない
データとはバイナリじゃなくてアクセス可能な情報構造だって考え方がクラスだから 言語仕様関係なく分かんないのは不味い
>>413 だったらstructで十分じゃん。って、考え。
型に対してメソッド追加できるし
javaもgoもどっちも書く俺はどっちの連中に分類されるんだろうか、、
>>412 goは現場から考え出された言語だよ。
実験的とか口から出任せすぎる。
生まれた経緯はgo blogに書かれてるから読んでみ。
基本的にはgoogle社内のc++プロジェクトの一部を置き換え目的で生まれた。
Go 2ブロックをおりる
https://www.infoq.com/jp/news/2018/09/go-2-draft-designs Go 2の記事は貴重だけど全体的に訳が微妙
特に Gets off the Blocks → ブロックを降りる はひどい
ここ機械翻訳つかってんのかわかんないけどかなり翻訳ガバい
get off the blockなんて言い方あるのか。勉強になったぞい
get off / the blocksで訳しちゃったんだな get / off the blocksが正解っぽい
handleブロックたくさん書きたいケースってあるのかね?適宜書いた方が見通しが良い???
書いた後で、エラー区別できるわけではなさそうだから適宜必要かという結論になった
エラーは判別できるでしょ 今までは深さでエラー処理を重複して書いてたけど連鎖的に呼び出されるから、その都度必要な処理書くだけで良くなる
var b *bytes.Buffer if a { b = function() } http.NewRequest(`POST`, rawurl, b) invalid memory address or nil pointer dereference なんでなん
>>434 bの参照先がつくられるかどうか確定してないじゃん
>>436 NewRequest の中で body.(io.ReadCloser) をやってるから if 文を実行せずに b を nil のまま渡したらダメということでしょうか?
むしろそこまで分かっててあと何がわからないのかわからない
if文が実行されなかったら nil を渡したい。それを簡素に書きたいそれが知りたい
よく見たらnilでもいいはずだけど型がおかしく見える
var r io.Reader if a { r = function() } http.NewRequest(`POST`, rawurl, r) こうすればいいのか。すみません
何でだろうね、全てをGoで書きたいのに 一応ツールキットの類は色々有るんだけど、GUI操作で部品作れるようなヌルポ系は無いな
試しにやってみたことあるけど、その分野はまだまだって感じ 自分でcontributeするくらいの気合が必要になると思う
Goに限らんけど、この手の言語はRestfulなAPIを提供するバックエンドだけにしてUI関係は他のフロントエンドを利用してブラウザ上で提供するのが良いのでは。
それはそうなんだが、せっかく単一バイナリで実行できるものが作れるんだから GUIも簡単に組み込めるようになれば、デスクトップアプリケーションの分野も席巻するかもしれん
GoでGUIってだめなの? UNIXなら他言語と大差なくないか?
UNIX限定のGUIアプリって時点で超ニッチだけど、それならいいんじゃない 普通にWinとかMacを想定するならオススメしない
いや、WinAPIだと他言語のほうが使いやすいねって言ってるだけで、Windowsで動かないもの作る話じゃないんだよね
出来るか出来ないかで言ったら出来るけど、 あえてgoを選んで茨の道を行く理由もない気が
goにChronium突っ込んで一緒にビルドする道がある
フォーマットと呼んでる この略称じゃなかったっけ?
もちろんformatのことだし、formatと読んでなんの問題もないけど、
英語で話していると
>>458 で読む人多いよ
主因はrob pikeがそう発音したからだと思う
Gophercon 2014のキーノート
VIDEO の15:30あたりから
Mat Ryerという人がGo Programming Blueprint, 1ed, 2edで
このネタを紹介してる
Goでenum→arrayがしたいのだけれど、そんな機能はないと……? これみんなどうしてるの?
MAXだかENDMKだかでcみたく配列作りたいんやろ? 気持ちは分かる
例えば入力値に対するバリデーションで、enum(という言い方が適正かどうかは別として)が取り得る値のリストが欲しいとかそのへんかな
structに突っ込んでreflectでゴニョゴニョすれば出来るかもしれん constではなくなるが
久しぶりにgo触ったので記憶が不確かなところありますが main.goのみが置かれたディレクトリでgo buildしたらgo.exeが生成されたのですが以前はmain.exeが生成されてたよう思うのですが仕様が変わったのでしょうか?(流石にgo.exe生成は有害すぎる気がするのですが)
>>475 です
自己解決しました。main.goのあるフォルダ名がgoになっていたせいでした。
お騒がせしました
文法難しすぎて挫折した ポインタもあるし やっぱりグーグルはダメだな
go触ってみたんだが、なにGOPATHって? 前世紀からの業を背負っているpythonでさえ最近はvenvとかが普通なのに。
結局それってプロジェクト毎にGOPATH設定する前提じゃない? まあ手間としてはpython venvのactivateと変わらんのだろうけど。
go1.11以降であればgo modでvendoringともGOPATHともおさらばよ。デフォは設定してないとダメだけど
おおこれはうれしい。 ただ、go mod vendorしたのにvendorだけじゃなくて$GOPATH/pkgにも展開されてしまうのは そういうもんなのかな。あえてvenrorを使う必要もなさそうだからいいけど。
goでwebサービス作ろうかと思ってるんだけどginとbeegoならどっちがおすすめかな? ネットの情報だとginの方が優勢っぽいんだけどこれはgoが規模大き目のweb開発に向かないわけではないよね?
goでの大規模開発は複数のマイクロサービスで成り立ってるのが主流だから、単体だと機能少なくていいんだよ
>>509 それは分かるんだけどフルスタックなFWでモノシリックなサービス作るのにjavaより劣る点があるのかな?開発者数以外で。
今は過渡期でマイクロサービスやってるような敏感企業が先行してgo導入してる(gin流行る)→数年後、技術者が増えてjavaのポジションにgoが座る(フルスタックFWも流行る)。
なんて事を妄想してるんだけど、実際にgo使ってる人からするとこの妄想は無理がある?
Googleが小中規模だと思うならどうぞ。 GoはGoogleの要望から生まれたも同じだから。
>>510 可能性としては大いにあるけど、確実なことは誰も分からんよ
少なくとも今よりは採用例が増えるし、中にはモノリシックなでかいシステムを組むところももちろん出てくるのは間違い無いと思う
モノシリック → 物知り モノリシック → モノリス
>>512 そーか。とりあえずginで遊んでみるわ
>>513 ありがと
goルーチンやチャンネルがそこまでスケールするものかね。 10000くらいがいいとこじゃないの?
vscodeのgoプラグインで、ファイル保存時にフォーマッタかけるのを止める設定ってどこだ? importだけ書いたところで思わず保存してしまって消えちゃうことが多くてもう嫌だ。
>>516 "[go]": {
"editor.formatOnSave": false
}
>>515 どんなシステム化によるけどサーバー1台で同時10000さばけたらなかなか優秀じゃね
他の言語に当たり前のようにある機能がGoにはないよな
// ̄~`i?ゝ ? ? ?`l?| ?/?/ ?,______ ,_____ ________ ?|?| ____ TM | | ? ?___ // ̄ヽヽ // ̄ヽヽ (( ̄))? ?|?| // ̄_>> \ヽ、 ?|l |?| ? ?|?| |?| ? ?|?| ``(?(. .|?| |?|?~~ ? ?`、二===-' ?`?==='?' `?==='?' ?// ̄ヽヽ |__ゝ?ヽ二='' ? ?ヽヽ___// 日本 _____ _____ ?______? _______ | ?ウェブ? | | イメージ | | グループ | | ディレクトリ |  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ?._________________ |GoLang導入事例 │・検索オプション └────────────────┘・表示設定 ? |?Google検索 | I'm?Feeling?Lucky | ・言語ツール ? ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ○ウェブ全体から検索?◎日本語のページを検索 広告掲載について?-?人材募集?-?Googleについて?-?Google?in?English  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ? ̄ ̄ ̄ ̄  ̄ ̄ ̄ ̄ ̄ ̄ ̄  ̄ ̄ ̄ ̄ ̄ ̄ ̄ c2003?Google?-?0,000,000,000ウェブページから検索 ↓ 検索結果なし
>>520 そりゃそういうコンセプトで作られたものだし
)ソ) ッλ ノ(.,ノ) (゙- ..::.::. . ( (ソ. .彡⌒ミ. )ソ) ).::'; (´・ω・`) ス ( ソ .::;';'(つ ⊂)::;';'`〜、. ( :;';' |__∧_| ::;';' ヽ) `'~`'''`'`'`~'~~`~~'`'`''''"`'`'`''`''''"`'``'~`''`'~`'''`'`'`~ さ あ 禿 げ 上 が っ て ま い り ま し た
gin(gorm)とbeego(beego/orm)を味見(CRUD API+ちょっとした検索)してみた。 beegoの方が「どういうAPIが定義されているか」が分りやすくていいような気がした。 他は違いが分からなかった。 なのでbeego使っていこうと思うんだけど、そのうち困ることって出て来るのかな? パフォーマンスとかtransactionとか思いもよらない何かとか。。
goってenumないの不便じゃない?慣れたらそうでもないんかな
グーグルの天才たちがenumは要らないと判断したんだから要らないってことだよ 何も迷うことはない
まさかと思いますが iota も知らずに言っているわけないですよね。 Java の enum class がないのは不便じゃないかというなら分かるけど、 enum がないのは不便と言われても const + iota + type でいいじゃんと思った。
例外は不便じゃないが、ジェネリクスは確かに欲しいっちゃ欲しいけど、無くてもなんとかしてた、かなぁ。 Go 2のジェネリクスは早く来て欲しい。
例外はデメリットも結構あるから、Goはこれでいいと思う。 どうしても例外使いたけりゃ他の言語を選べばいいだけだし
>>530 そう。javaのやつ。
あれからいじくり回した結果、自分でメソッド生やせば似たような事はできた。
そしてjavaのenumに求めていたような事はgoでは違う方法で実現すべきという気がしてきた。。
レガシージャバで嫌な思いしてきたからgo最高ですよ
そりゃ違う言語なら違うやり方を選ぶべきだよ。 と、かつてCOBOLの流儀で書かれたJavaに殺されかけたおじさんはそう思うよ。
リモートプロセスとchannel通信したいと思ったんだけど、netchanってもう非推奨なんだよね。 代わりになるものって無いのかな。
標準パッケージだとrpcしかないか。 channelから取得したデータをrpcで投げるブリッジを自分で用意すればなんとかなるかな。 それにしてもなんでnetchanやめたんだろうね。
log.Fatal()を呼び出したときdeferが実行されない罠なんなんですか
panic()使ってmain()のdefer内のrecover()で拾ってlog.Fatal()使えってこと?
>>543 log.Panic()使えばいいんじゃね?
それとも、同じ関数内のdeferは呼びたいけど上位のdeferは処理したくないってこと?
Fatalは致命的なのでリソース解放とか気にしている場合じゃないのです
致命的な状況でFatalの代わりにPanicを呼ぶのは妥当ではありません プログラムの実行の継続をしてはいけない状況でPanicはプログラムを終了できる保証はありません
目的で使い分けりゃいいだけの話。defer呼びたいっていうことならPanicでいいだろ。
放置してたチュートリアルを、最近また始めた。 前はエラーのinterfaceが理解しきれず詰まったんだけど、 今回やり直してやっと原因がわかった。 fmt.Errorfで返せばええやん interfaceの説明のためにエラーを返すためだけのタイプ作ってるってことが今はわかったけど、 前はその意図が全く理解できず放置になってしまった そういうとこあかんよねgo言語(´・ω・`)
または前の関数使い回さず、 interfaceに変えた上で実装なら筋が通ってる あんな使い方するシチュ無いよね?
あーごめんこれ
https://go-tour-jp.appspot.com/methods/20 ■正答とされているもの
func (e ErrNegativeSqrt) Error() string {
return "cannot Sqrt negative number: " + fmt.Sprint(float64(e))
}
func Sqrt(x float64) (float64, error) {
if x < 0 { return x, ErrNegativeSqrt(x) }
}
実際やるなら普通こうだろ!と思った答え
■その1 fmt.Errorfつかう
func Sqrt(x float64) (float64, error) {
if x < 0 { return x, fmt.Errorf("cannot Sqrt negative number: %f", x) }
}
■その2 interfaceで揃える
type FloatValue float64
func (x FloatValue) Error() string {
return "cannot Sqrt negative number: " + fmt.Sprint(float64(x))
}
func (x FloatValue) Sqrt() (float64, error) {
if x < 0 { float64(x), x }
}
func main() {
o := FloatValue(2)
fmt.Println(o.Sqrt())
}
typeにErrorを実装することでinterfaceの条件を満たせるんですよってのが演習の目的なんだと思うけど、実際こんな実装するの?って疑問に思った。行数限界
>>553 リンク先ちゃんと読んでなかった
いろんな回答例出てるのね
ただ出題の前提条件はやっぱおかしいというか、無理がある気はする
新しい型:
type ErrNegativeSqrt float64
を作成してください。
こんな事普通しないよね?
という話でした
明日にでも読んでみますわブログ
>>555 普通するかどうかは問題じゃない
言語の機能を一通り学ぶことがチュートリアルの目的なのだからね
>>556 ユースケースって大事だと思うけどなぁ
最初何やってるか、何やろうとしてるか理解できなかったし
あとここに書いたのは、 正答の例って使うシーン無いよね?ってのが本当にわからなかったからでもあります(´・ω・`)
> こんな事普通しないよね? golangではする
>>555 エラーの型を作るのは深いところからerrorが戻ってきたときに何のエラーか特定できるようにしてエラー次第で処理を分岐するためなのではないの?
>>560 戻ってきたときにはエラー型になってるから型判定は無理で、
メッセージで判定するならその階層のために型を作る必要が無いのではなかろうか
まだ上のリンク読んでないから、違ってたらすまん
エラーってインターフェースだから、タイプアサーションで型判別は出来るんでないかい?
>>562 ありがとうございますorz
なるほどswitch型アサーションしてエラー処理出来るのね。。
goに関係なくインターフェースって言葉自体を理解してなさそう
すまんがA Tour of Goの次はどこ行けばいいの? さしあたっての到達地点はgRPCでWebAPIを書くことなんだけど、おすすめがあったら教えて
これってなんで通らないんですか? https://go-tour-jp.appspot.com/moretypes/18 package main import "golang.org/x/tour/pic" func Pic(dx, dy int) [][]uint8 { image := make([][]uint8, dy) for y := 0; y < dy; y++ { image[y] = make([]uint8, dx) } for y := 0; y < dy; y++ { for x := 0; x < dx; x++ { image[y][x] = uint8((x + y) / 2) //14行目 } } return image } func main() { pic.Show(Pic(10, 10)) //21行目 pic.Show(Pic())なら通る } エラー内容 prog.go:21:14: cannot use Pic(10, 10) (type [][]uint8) as type func(int, int) [][]uint8 in argument to pic.Show 引数が間違ってるからでしょ、pic.Showは、f func(int, int) [][]uint8、これを受け取るのだから その書き方だと、[][]uint8しか受け取ってない、因みにpic.Show(Pic())も通らないはず pic.Show(Pic)なら通る
そうだったのか、そもそもを全く勘違いしてたよ Pic()の戻り値である[][]uint8を渡してるんじゃなくて、Pic関数を渡してるのか ありがとう
go
http://2chb.net/r/tech/1257920595/ 2009年に華々しく初登場。3日で消化
Go part2
http://2chb.net/r/tech/1258183436/ まだまだ衰えず10日で消化
Go part3
http://2chb.net/r/tech/1259072043 だいぶ落ち着いてきた3ヶ月で消化
Go part4
http://2chb.net/r/tech/1265620273 ほぼ1年で消化。すっかり普通のスレに。
Go part5
tech/1327216227/ 17res。オワコン
Go 総合スレ
tech/1342535690 再建。しなかった。4resでアイちゃんフィニッシュ
Go の宿題片付けます
http://2chb.net/r/tech/1257968644/ part1の頃立った残骸。
Go language part 1
2013年開始、4年で消化。
http://2chb.net/r/tech/1381374291/ Goのシンプルさを再認識した これ(・∀・)イイネ!!
Mapがない言語から来たんで、どう役に立つのかよう分からん よくある辞書型とはちがうんか?
namespace周りはもう少しなんとかなりそう。 検索するのが意外と不便。
>>571 https://github.com/gorilla/websocket/blob/master/examples/chat/hub.go > type Hub struct {
> // Registered clients.
> clients map[*Client]bool
最近見てへーと思ったwebsocketのサンプルチャット
typeのポインタをmapのkeyにしてる
1.12リリースあげ TLS1.3自前実装とは恐れ入る。
TLS1.3ってHTTP/3.0とセットじゃなかったっけ?
全く知らないんだけどちょっとググったんだけど HTTPS的なものなの?
http/3とセットなのはquic quicはtls 1.3を参考にしてるけど別物 httpsのs (secure) 部分の最新仕様がtls 1.3
go案件は増えてきてるのにここの書き込みが少ないのは5chの人気が衰退してるってことなん?
うん 新しいものに敏感な今の若い子は5chを見ない
2chの代わりってどこなんだろう Teraなんとかとqiitaなのかな
genericsが正式リリースされたら使ってやろうと様子見。
ジェネリクスが入ったら、インターフェイスで書くのはレガシーになるんだろうか
Goは難しすぎる Cに挫折して流れてきたけどCの方がまだわかりやすいと思える
良かった、やっぱり人居たじゃん。 という釣りだと思うけど
難しくはないけど直感的じゃないしコードの見た目が汚いとは思う
そういや、チュートリアルのクイズはなにを求めてるのかよく分からんかったな
>>590 ああそれだ
俺みたいにコードを論理ではなく見た目で直感的に解釈するタイプの人間には果てしなく合わない
やっぱこれを作ったグーグルの秀才たちの感性は俺とは違うんだなと思った
見知っている言語と似ているようで微妙に違う、不気味の谷を感じることはある。 丸括弧の使い方とかinterface{}とか。contractはさらにキモいな。
C作った人がCじゃないものを作ったわけで 他の言語はCの影響どっかしら受けてるだろうから 別物になるのは当然っちゃ当然なような
QiitaじゃGoとかScalaがもてはやされてるけど実務でガッツリ使ってる企業って1%もないよね?
Goはそこそこ使われてんじゃん ただGoでの求人はないだろうな
Scalaがもてはやされてたのは2017年頃までやろ 昨年は既に空気やで…
よくサーバサイドのエンジニアがJavaScriptの流行り廃り怖すぎwって言ってるけど最近はサーバ側の方が激しくない?
scala嫌いではないけど万人に好かれるような言語じゃないよな、理想に走りすぎてて使いにくいというか いまscalaかKotlinか選べるなら100人中98人はKotlinを選ぶだろう
誰でも頭が良くなる、プログラムが書けるようになる方法が発見される 83890
https://you-can-program.hatenablog.jp 情報工学を学んでいない者にも使える言語がこの先生きのこる GoやJavaScriptみたいな大雑把な言語設計でも直感的に書けるのは大事
何だかんだでJava、JavaScript、PHPが30,40年後も生きてると思う ぶっちゃけこの3つだけできてれば一生食ってはいけるんだろうな
20年前はcgiと言えばperlだったし 動的なWebコンテンツと言えばフラッシュだった PHPのCMSと言えばPHPNukeが当たり前だったし それ以前はそもそもCMSが無かった 先の事なんて判らんよ
今のWebの新規開発はrubyかpythonってイメージある
静的、動的、関数型を一つずつマスターしてれば時代の流れとともに簡単に乗り換えできるし 最初のうちはJava、PHP、Scalaとかでいいんじゃね
今だったらJava(Kotlin)、Python or Ruby、Go でいいんじゃね
とりあえず、ここGoのスレだからGoは入れようか 他は何でもいい
Kotlin, Go, Python, TypeScript
JavaScriptでちゃんと実務ができれば他の言語とか全部余裕だと思ってる ブラウザが変わると挙動が変わったりするのは本当にきつい 俺にはフロントは無理
Go,Gopher||JSSyscall/js,Otto
>>613 静的で動的で関数型なTypeScript最強ってか。
小中学校でプログラミング必修化だそうだ 俺ら失職じゃん 小さな頃から仕込まれた才能にはとても太刀打ちできん
職業プログラマで才能が〜とかなるシーンてほぼ無いような…
結局のところ授業は国数英社理が9割ぐらい占めてるし 音楽とか美術ぐらいの頻度でプログラミングを学んだところで実務レベルになるとは思えんわ
>>621 そもそも論理的思考は算数・数学で鍛えられるのに、今まで何やってたのかと。
>>621 家庭科で料理を教えるけど料理人は失職してないよ
料理は人間の食欲に直結する 人間は食べずに生きていく事は出来ない しかしプログラムは無くても生きていける いわんやプログラムを書く事をや
プログラムを自分で書かなくても生きていけるけどプログラムが消滅したらもはや生きて行くのは無理なのでは
俺も学生当時は数学なんて勉強しなくても生きていけるって言ってた
>>624 自分は数学が極めて苦手なんだよ
高校入学後の数学のテストで三回連続零点取って呼び出しを食らったほど
三角関数や微分積分はおろか分数の計算すら全くわからない
だから普通に数学のできるヤツがプログラマーに大量進出してくるとすぐに失職する
PHPのディスられっぷりがすごい
>>633 Perl が日本刀か、Ruby は何の工具よ?
>>634 サーベルソーとかレシプロソーって言われる電動ノコ
プログラミング言語はモダンで緩い職場につくための道具である
structの拡張記法でjsonをそのまま返せるし、web APIを書くための言語としては最高だと思うけど 世の中、そんなにAPIを書くような仕事があるのか? 食いっぱぐれ無いためにsalesforceかintra-martを触るわ あと、中枢都市はjava案件が多いけど地方は中小企業向けの業務アプリ開発ばかりで.netばかりだからな オフショアの二次請けなんかになってくるから、ハロワへ行くと手取り15万円とかザラ 誰がプログラマなんてなるんだよw
web APIは、golang + micro serviceに流れるだろうけど、業務システムはjavaから変わることねーわ 新しい言語を躍起になって覚えるぐらいなら、習得済みの言語でソフトウェアの1つでも書けよ
―┼‐ ノ / | --ヒ_/ / \ヽヽ ー―''7 `」 ┼, 二Z二 レ / /´レ' \ ―7 ̄} | ー-、 / (__ (|フ) (__ノ _ノ ∨` ノ / / _ノ \_ ─┼- / | ‐┼- | ー|― ─┼─ | \ レ /  ̄Tー / ノ -─ (二フヽ \/ _ノ (二フ\ ヽ_ノ / 、__ i';i /__Y ||真|| /⌒彡 _ ||露|| /⌒\ /冫、 ) ・・・・・・。 \ || || ̄ ̄ ̄ ̄ ̄ ̄ ̄\ `./⌒ i ` /ゝ _,,..,,,,_ ||\`~~´ (十万石) \( > ('\\ ./ ,' 3 `ヽーっ ・・・・・・。 ||\|| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|| ̄\`つ ⌒ _) l ⊃ ⌒_つ .|| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄|| `'ー---‐ ( 'A) ・・・。 〃∩ ∧_∧ <⌒/ヽ___ /(ヘ)ヘ ⊂⌒( ・ω・) ・・・。 <_/____/ zzzz・・・ `ヽ_っ⌒/⌒c
>>639 ハロワで30万以上の無いんですかって聴いたら
いまどきそんなのあるわけないでしょって諭された
日本おhる
プログラミングで食っていきたいなら東京近辺に住んでないと本当に人権が無いからな 東京以外だと手を動かさない営業モドキの業務系SEになるしか稼げる道がないのは可哀想だと思う 経験2年のフリーランスプログラマーに60万円とか東京以外じゃ絶対に払わないだろうし
業務系アプリは作ってほぼ終わりだからオフショアが成立するけど Web系アプリは運用がメインだからオフショアは無理だと思う というか未だにJavaとか.netとか言ってる化石がGoのスレにいるのはウケるな
業務系の雑魚がプログラミング語ってるの見ると本当に笑える
YouTube で有名な雑食系エンジニア、KENTA の動画を見れば? 基本的に、間に会社を通すと、3割抜かれるので、 1次受け、2次受けとドンドン抜かれていくので、直接受注が理想 身分による還元率は、 社員なら、3割。その代わり仕事が無くても、給料がもらえる。 派遣なら、7割。その代わり仕事が無いと、給料もない。 フリーエンジニアで、エージェントを使うと、9割 ただし、フリーエンジニアは個人事業主だから、 サラリーマン控除(給与所得控除)が無いから、50〜100万円ぐらい税金が増える! 厚生年金も無いから、年金額も少ない。 サラリーマンは、厚生年金の半額を会社が払うから、所得が少なくてもリッチ それに個人事業主には、組織という後ろ盾がなく弱いから、 だましたり金を払わない客が、積極的に寄ってくる この辺の仕事は、だましあい。 ヤクザと同じ。如何にアホをだまして稼ぐか
>>644 大学サークルみたいな集まりの売れない自社サービスなんて赤を垂れっぱなしだよ
宅配ドライバーの契約社員の方が給与マシってレベル
これで地方から人が居なくなるとか言うもんだから笑えてくる
>>650 最近垢抜けたよ、マジで。
Windows一族感を一歩脱出して、クロスプラットフォームも.Net coreで攻めてきてるし。
ベンチも悪くない。
最近Goと両刀使いしてる。
golangって、RESTful APIを書くぐらいでしょ? .netって、C/S系の仕事ばかりだと思うんだけど この2つの言語を扱うプロジェクトって、同時にやるようなものなのか プログラマってのは工場のラインや期間工と変わらないですよ。 刺し身の上にタンポポを乗せた方がマシだな
.netは昔VB.netしか書いたことないから詳しくないけど C#でゲームサーバ書いてk8sに乗っけた話を昨日見たよ k8sは便利だね GKEだと特に
プロジェクトのネジになりたくないなら、自分が立ち上げる側に回れば良い それが出来ないなら大人しくタンポポ乗せてれば良いのさ
Webページのフレームワークって、まだ特にどれが定番とかってないの?
Goなら定番までいってるものはないんじゃないかな いずれは出てくるだろうけど、そういうものを作りたかったらGoを使わなくてももっと成熟したものがいくらでもあるし
net/http と html/template ってのがまぁ定番じゃないの? もう少しリッチにするなら gorilla を組み合わせるとか。
あるにはあるけどRubyにおけるRailsみたいな定番はまだ定まってないわな
スレチなら申し訳ありませんが解説をお願いします
https://qiita.com/clamoto/items/7c977d9a741c677b8539 のサイトにGoProの位置情報ぶっこ抜きが乗ってるのですが2バイナリの抽出からよくわかりません
gitとか全くわからないものですがわかりやすく解説お願いします
何が分からないのか言ってくれないと教えようがないけど、 ffmpegというコマンドを使ってデータの形式を変換してるだけだね。 この時点ではGoに全く関係ないからffmpegが何をするものでどうやって使うのかを調べな
GoogleはGoを捨ててDartのみやってくだろう
web業界のサーバー側はgolangが主流になるわ。json返すの楽だし、micro serviceは増えるだろ モノリシックな糞の山が高く積み上げられているのを見たけど、外部サービス利用した方がマシな機能ばっか 動的言語の採用は減っているし、動的言語そのものの評判が悪くなってきている lispやBCPLから、cが出てきたんだから当然だろと c++やjava, PHPといった進化を経て、webのサーバーサイドって環境に最適化したのがgolangって言語だよ
先日行われたGoogleのプログラミングコンテストCode Jamで
提出に使えるGo言語のバージョンがsort.Sliceも使えない古いバージョンで
GoogleがGo言語にやる気が無いのが伺える
https://twitter.com/andrew_charlton/status/1114791830950961154 https://twitter.com/5chan_nel (5ch newer account)
>>661-663 ffmpeg で、動画を変換しているだけだろ
変換前・変換後の動画の規格を調べる
ただし、各メーカーの動画の規格を調べるのは、大変
各メーカーの独自規格なら、そのメーカーしかわからないし、
特許関係で、規格を公開していない場合もある
十分な報酬が無ければ、こんな機械の規格のような業務を引き受けてはならない!
言語の文法とは、全く関係ないし、調べることができないから
>>665 みたいに、新しい技術が出るとそれまでの技術が消滅すると思ってる奴はいつの時代もいるよな
実際は選択肢が増えるだけで、完全に消えることはほぼない
企業によって有料で提供されるものは企業が倒産で消えることもあるだろ
グーグルは儲からない・将来性のないプロジェクトはバンバン廃止するからなあ 怖くて業務には使えんわ
Python 2 みたいな技術的負債w github の新規プロジェクト数が多い理由は、同じものをPython 3 で書き直しているから 一方、Ruby の新規プロジェクト数が少ない理由は、数年前のコードがそのまま動くから Python, JavaScript, Kotlin は、Rubyに似せてくるが、Rubyは変わらない。 Rubyは、最初から書きやすい
gifは消える消える言われながらまだ息してるな 怖くて使えないけど
まあgoくらいのシンタックスならgoogleが捨ててもメンテされるだろ。単純だし。
というかGoは出所がGoogleってだけで完全にOSSとして開発されてるからな
メンテが放棄されたOSSがいかに多いか理解しているのか?
というかGoは出所がGoogleってだけで完全に揚げ底クソ言語
Google Code Jamでもバージョンが1.8とかだったし、中であまり使ってないのかなと思った
OSSになってたのか じゃあしばらく安泰かな けどLinuxやPythonのように内紛でメイン開発者が失脚した例があるからなあ
サーバーでgolangを使う気はするけれど、dartって息してるの?
>>680 Go言語は競プロには向いてないって言ったでしょ
>>682 Flutter
>>681 会社と同じで人間関係に寄る。
小規模のOSSは大学生が就職先にアピールする為で就職先したら止まるし、ユーザーが技術的な困難理解したりで人間関係上手く行く。
タダ働きのボランティアだって事をユーザーが忘れると主力が抜ける法則。
戻り値のerrorを処理せず捨ててるコードがある場合にコンパイル時に警告かエラーを出すことできます?
>>686 errcheckってlintツールがあるからCIのタスクで回すといい
&Hoge{}とnew(Hoge)の違いってなーに?
>>688 いっしょ
速度的な差はあったかよく覚えてない
スクリプト言語ならともかく、 コンパイル言語で単文で意味一緒なら変わらん気もするけど そうとも限らないの?
2019年高い給料につながるプログラミング言語は? - Stack Overflow
2019/04/15 17:03 後藤大地
https://news.mynavi.jp/article/20190415-807198/ Stack Overflowはこのほど「Stack Overflow Developer Survey 2019」において、高収入と
関係性の高いプログラミング言語ランキングを伝えた。ランキングによると、Clojureが最も
高く、これにF#、Go、Scalaが続いている。逆に、ランキングの中で最も給与が低いのは
Javaだという。
高い給与と関係性の高いプログラミング言語ランキング - 資料: Stack Overflow提供
ランキングの上位は、調査ではシェアが低いことが多いプログラミング言語が入っており、
逆にシェアが高いとされるプログラミング言語が下位にエントリーする傾向が見られる。
特定の要求があるにもかかわらず対応可能な開発者が少ない場合、開発者を引き寄せるために
給与が高くなっていったものと見られる。逆に、シェアが多いプログラミング言語は人材も
豊富であることから、給与の下落につながっていると考えられる。
Goができると給料がいいんじゃなくて給料がいい企業がGoを使ってる定期
>>688 初期化できるか出来ないかの違い
hoge := &Hoge{
foo: 10,
bar: "aho",
}
hoge := new(Hoge)
hoge.foo = 10
hoge.bar = "aho"
>>692 単に需要と供給の原則で決まってるだけだよな。
これからGoがめっちゃ流行って書ける人が増えたら平均値は確実に下がるし。
それで言うと確実に需要があるのに誰も新規に習得しなくなってるCOBOLマスターはかなり年収が高くなってると聞く。
Clojure 使ってるとこ CircleCI しか知らんな
>>692 6位 : Ruby
12位 : Python
19位 : JavaScript(JS)
YouTube で、漏れが見た、外人の動画では、
Ruby は、800万円で、Python, JS では、1,200万円まで上げられるって言ってた!
日本では、COBOL の求人も多い
JavaのfinalやC#のreadonlyのような仕組みになっていないのクソでは?
import "github.co.jp/hogehoge/foobar" こういうやつブランチとかタグとか指定してインポートできる?
ここにいる人達はGoでどんな仕事してるんでしょうか? 企業システムの構築SIer? 研究目的?
>>704 ありがと。そんなクリティカルなとこにこんな新しい言語適用するような会社があるのか。
自分は旧態依然の日本企業の仕事だけなんでjavaかメインフレームから離れられないんだよね。
クリティカルだけどGoで書いたコードが問題になった事はないよ トラブルがあっても連携する外部のサーバで起こった事しかない
>>705 メルペイとかものすごい勢いでgoエンジニア採用してるやん
goエンジニア募集してるけど素人に毛が生えた程度の人しか集まってないと予想
独学じゃなく体系的にgoを勉強する機会って無いよね? 一番すんなり入れるのはC?C+?の人なのかねやっぱ
goで問題が生じるとしたらgoroutineが回収不能になるとかそんなとこかね?
フリーの言語を使って障害出したら組織として問題になる懸念がある
>>706 は保身策を練ってあるのか?
社長が「大事なシステムをフリーソフトで開発したヤツは誰だー!」って
海原雄山モードになったらどうする?
DBならともかくweb系の言語で有料なのって.netくらいじゃないの IISよりapacheのが圧倒的多数派だと思うし
言語はやりたいことから覚えていってしまうから、自分も体系的に覚えた言語はないな。 本買って知らなかったこと勉強したりしたのも数少ない。 Goは言語の覚えることは少ないイメージ。環境周りは知っとくべきことが色々ありそう。
>>714 ,netは最初から無料ですよ
有料なのはVisual Studio
最近は.net coreってオープンソースのもあるし
web系の言語で有料なのってJavaくらいじゃないの
>>713 Goを全面的に採用するような組織は言語側にバグがあっても自分で直してプルリク出しちゃうだろ
逆に言えばそこまで出来ないなら大人しく金はらって有料の言語を使えという話
フリーソフトを使おうが使うまいが「大事なシステムでバグを出したヤツは誰だー!」ってなるだけ。
>>717 Goってプログラミングで騙して回避できないような言語バグって残ってるのか?
責任負えるの?って観点でjavaが選択されてたのか…
マイクロソフトはこっちが切羽詰まった状況の場合は 期限切って回答くれたりするからねえ グーグルにはそんなことは期待できない
>>713 Goに限らずOSSで作ったシステムで障害になった時に責任求められるような組織や契約で働いた事ないから考えたことない
日本マイクロソフトって、Office2016以降のVBAで日本語モジュール名使ったら動かなくなるバグを、 previewで指摘されていたにもかかわらず無視して、そのままリリースさせちゃったところか。 後日アナウンスされた対処法は前のバージョンに戻す方法だけだったな。security fixもあったのに。 OSS使う人は、責任云々じゃなくて、どうすれば直るかを考えるんじゃないかな
OSS選定みたいな技術選定でエンジニアが責任とらないなら誰が取るんだ?まさか、このOSSがバグったんで俺らは悪くないです、が通じるの?
うちの会社だとエンジニアという職種の人達は責任とらんだろうな。 それを承認した上の責任だとか、そんなこと言う。 最早、エンジニアではないのかもしれん。
javaも選定すること自体が冒険みたいな時代があったけど、もうすっかり安定の規定路線になったよね。 その次に来るのがこのGoかな?と思って見てる。 広く普及しそうと騒いでたのがjava以降いくつか出たけどjava程にはならなかった。 もっと別の場所から出て欲しいけどね。 言語の発祥地としてはGoogleは閉鎖的に過ぎるように思う。
責任云々の話はサービスの種類にもよるんだろうな 銀行とかじゃそういう話になっちゃうんだろう 俺はゲーム系で、多くてもサバクラでクライアント外注くらいの登場人物しかいないから 誰が悪いとかじゃなくまず直そうよって話に普通はなる その後で必要なら、技術選定方法の見直しはやるかもね 責任誰が取るんだ?とか「何言ってんの?」ってリアクションになりそう 工程の見直しですらない無駄な振り返りというか
てか有料だからって責任取るわけでもないしな。 どうせ問題解決させられるならソース見れる方がいいわ。
>>713 > 社長が「大事なシステムをフリーソフトで開発したヤツは誰だー!」って
この文章がかなり基地外じみてて笑える
企業システムの場合だと、その会社での開発規定みたいなものがあって、そこで言語やソフトウェアも標準というのが決められてる。 それ以外のものを使うなら、それが標準より優れているってのを書面で説明してしかるべく部署とかに承認されないといけない。
フリーソフトという言葉が笑えるwwww ゲームを何でもファミコンという世代なんだろう
>>728 責任はとらないけどメーカーの責任と言うことには出来る
ソフトウエアの事が何も分かってない経営層に対する言い訳にはなるかも
どの言語にもGoでいうchannel的なもの欲しくなる
>>732 その言い訳の連鎖の先が今のSIerの状態なわけだけどな。
あれは経営層、営業、プログラマ、誰も幸せになっとらんぞ。
>>735 責任取りたくない連鎖でもありますよ
非効率な前世代の開発手法がまかり通てます
責任なんてだれも取らないよ 再発防止策伝えて終わり
「有料の言語」ってなかなかのパワーワードだなw 仮に有料の何かを使ったとしても責任のなすりつけ先が他に出来るだけでバグ自体が消えるわけじゃないのに
>>730 そういう昭和で頭が止まってるような会社ははなからGoなんて興味すらないからこの話題には全く関係ない
ちなみに日本の老舗大手でもGoを使ってるところは既にある
awsとかgcpとかパブリッククラウド使ってたらSLA決まってるから許諾して使ってるだろうし落ちてもごめんなさいだけど、 オンプレでGo使ってるところは知らんな どうなの?
単に有料なだけのツールの大半は責任を擦り付けることもできなかったりするしな。
バグ出したやつは誰だーって言う前にテストエンジニアがデバッグしてんだろ? テストエンジニアが無能なだけじゃん
20年前ならいざ知らず、有料のものなら安心だと思ってる奴なんて実在するの というかもはやOSSを一切使わずにシステムを構築する方が逆に難しいと思うんだが
有料のはサポートを打ち切られたらそこで終わりってのが怖いな OSSなら頑張ればなんとか使い続けることができるだろうけど、それができん 俺が使ってるRuby Motionなんていつ終わるかわからんし、終わり間際にOSSにしてもくれないだろう
>>739 ITに限らず最大手の会社には一定数の天才がいるから実は割と新しいものに対しても柔軟なんだよな
やばいのは業界内の二位集団みたいな企業
バグが見つかった時にまず誰が責任とるんだって話になるトンチンカンな会社ならそうだろうね 新卒で入ったところはそんな感じだった
統制の一部として、保守サポートがあるものを使う、ということを是としてる企業はまだ多いからね。 保守サポートがあれば、何か問題あったらそこに責任を押し付けられるという謎理論。
世の中の家電はlinuxベースのものだらけだよな デジタルTVも多分100%そう androidもlinuxベース webサーバもかなりlinuxに乗ってるものが多い もちろんGPLライセンスなのでlinuxにバグがあっても無保証 そこに世界中の家電メーカーなどが乗っかってる
組み込みはいいんだよ、linuxでも。実績ができちゃってるから。最初に採用させた人は頑張ったろうけど。 次に組み込みでlinux、android以外ってのは国内企業は受け入れられないぞ。
そういう企業があることはわかるけど 「国内は」とかで語っちゃうのは違う気がする 世界が狭すぎというか
GW明けにvscode開いてみたらgoのlanguage serverが新しくなってたのでそっちにしてみたらストレスレスになった。インテリセンス周りとても快適で良い
>>748 その発想が謎すぎる。
有料サポートを選ぶのは「金で解決できるから」でしかないだろ。
例えばjavaでもgoでも、十分一般的な技術を選定した上でバグが見つかった場合、責任を取るって具体的に何をするんだろうなw 技術選定プロセスを見直すってもそこらへんの技術を品質とか信頼性の基準で弾くのは無理だろw
昔のジジイどもはそんな意識だったな windowsにバグがあって「その会社の奴を呼んで来い!休日返上ですぐに不具合を修正させろ!」と叫んでたそうな…
>>754 再発防止≠責任を取る
単にながーい始末書を書かされたり何かしら処分されたりするんでね?
そして貴重な失敗の知見を持った人材が辞めていく
そんなバカなことを、って言ってる人達はエンジニアとして幸せだと思う。 SIerはホントにこんな感じよ。
辞めりゃいいじゃん エンジニアなんてめっちゃ簡単に転職出来るんだから
んなこたない。 まともなとこに転職するのに俺は少なくとも4社は辞めたぞ。
そんなバカなことを、と言ってる人達は会社に幸せにしてもらってるわけじゃないからな ダメなら辞めるで通せるだけの努力をしてる
>>763 4社辞めても次が普通に見つかる時点でエンジニアは幸せよ
日本でビジネス系だと4社辞めてたら転職多すぎて書類選考時点で不利になる
goで書いてるというよりかはkubeやdockerのためにソース読むって感じか。
趣味で金を気にしないサバクラゲー作りたくて、鯖側をgoにしようとして勉強してる まずwebsocketの習作としてニコニコもどき作る予定
サバクラという言葉から溢れ出るおっさん感 いや俺も通じる世代だけどさ
もはやその構成がデフォルトだから特別な名称はないと思う 少なくともここ数年は聞いたことないし、若い子には通じないと思うw
俺たちの頃はコンピューターは一台でそこにカードリーダーがあって、まだノートPCは存在してなくて、あってもダム端で。。。
それ知ってたらもうおっさんじゃなくてお爺ちゃんだろ
サバクラって死語なの…?(´・ω・`) まあ今はなんでもブラウザ使うもんなぁ
>>776 天皇陛下世代をおじいちゃんだと
不敬罪で逮捕じゃ
>>778 そうだよね
なんかサバクラって違和感あるなと思ってた
クライアント−サーバーシステムだからクラサバだよね
でもWebアプリも最近はSPAになって「サーバーが」「クライアントが」って会話は増えたよね。 それにしてもみんなサバクラなのか。クラサバじゃなくて。
クラサバでもサバクラでもいいけどどちらにせよ最近はその言い方聞かなくなったな
さすがに紙テープとかパンチカードだと歴史上の遺物だが 俺が就職した頃はオフコンとかは普通にあったな パソコンの事を当時のオッサンはノンダム端末とか言ってた記憶がある クラサバの時代だとup4800とかかな? ダウンサイジングとかバズワードだったなぁ・・・
>>783 NetWareの時代には良く言ってたがWindows NTになってからは死語かも
>>785 オフコンはIBM Power Systemsで現役ですよ
完全にスレチなんだけどさ nosql話すスレって2chに無いのかな
>>788 Key-Value StoreやMongoDBのスレがDB板にあるけど過疎ってる
>>788 なぜが過疎ってるよな。
多分使ってる人が少なすぎるのが問題なのかなも。
全然違うスレで質問してたので移動してきました。 mattnのsqlite3ドライバとgormを使って struct Model { gorm.Model Name string } としたレコードを登録すると、 CreatedAtの自動挿入された日付が全部1899/12/31なんだけど 自動で付与させるための操作が何か必要なんでしょうか 何もしないでもいいものだと思っていたのですけど。
今現場の主力になってる世代は5ちゃんなんて見ないからな
>>795 今でもAS/400って呼ぶ人が多いけど、AS/400とRS/6000のハードが統合されてIBM Power Systems
OSは昔と殆ど変わってないです
system 360 がホントは system 365 の意味だったという話
昨日からGoを始めた いにしえのCの雰囲気があるねコレ
モダンなc なんだけど時代に逆行してる気がしないでもない
最初、type の後置と := を見て pascal みたいだな、って思った
あんまり不満はないがimport文の範囲指定はもっとどうにかならんかったのかと思う。 あの辺のネームスペースはもう少しなんとか出来るだろ。
モダンな言語で型が後置な理由
https://teratail.com/questions/188903 モダンな言語、それがGolang(´・ω・`)
関心の的というか集中すべきものは変数名であって型じゃないからな 自分でJavaやC#でコード書いてても先に変数名を書きたくなる
てかストラウストラップもc++で後置にしようとしてたんだぞ。
>>805 古いプログラミング言語にも後置のやついっぱいあるだろ
log.Fatalするくらいなら panic使ったほうが良くない?
GOで競技プログラミングしようとしたらどんなpackage構成が正解なんだろ。 今はスニペット関数が衝突しないように問題毎にフォルダ切ってるんだけど何か正解ないのかな。。
その手のバカはgoには向いてないよ。 c++,rust,haskellみたいな俺Tueeeeできる言語使ったらいいさ。
Goでやりたいならフォルダごとに分けるしかなさそうな気がしちゃうね
>>813 panicはdeferが実行される
致命的なエラーが原因によってdeferが実行されては困る場合log.Fatal
error戻り値は受け取り側が握りつぶして処理を継続できる panicは呼び出し側直後の処理の継続は阻止できるがdefer内でrecoverすれば握りつぶせるのでその外側では処理を継続できる log.Fatalやos.Exitは強制終了できるがdeferによるリソース開放やロック解除の処理も実行されず終了する こんなの使う価値ない
Goを使ったことないけど、gRPCとMySQLを使ってAPIを作りたい バリデーションやORMのおすすめってなに? フレームワーク使ったほうがいい?Ginが人気そうだったけど
Ginとかechoは使いたかったら使ってもいいと思う ORMはgormと折り合いつけてうまく付き合うくらいしかなさそう
ありがとう。gormとGinを組み合わせて作ったりするのね。
>>829 既存システムのAPIを作りたくて、Goが候補にあがってる。
すでにあるMySQLのDBもあるのでそれを使うため。
>>830 自分でSQLを書くような単機能のORマッパーもあるからそういうのは使ってるわ
RailsのActiveRecordみたいなのは使わないようにしてる
DB一種類しか対応しなくていいなら、それほど気にしなくてもいい
プログラミング言語別新規求人数
AI自走コンテストみたいなのもPythonとScalaだったな Goで書きたかったな〜
アカデミックな人たちってほんとScala好きよね プロダクトで使うとめんどくさいことこの上ないけど
副作用がない Java資産が使える コードを非常に短く書ける
JVMなら正直ScalaよりKotlinの方が実用的だと思う
間違いない scala組は早くkotlinに合流してほしい
そうやって文化の違う声の大きいやつを招き入れると、C++みたいになるんじゃないの?
c++みたいにしたい奴は結構いる。 俺は反対だが。
むしろ内部破壊工作をたくらむスパイじゃないかと思える
Scala民はなぜかKotlinを敵視してるから合流しないと思う
var list []string if list, err := getList();err != nil{ doSomething() } fmt,Println(list) みたいにerrはスコープ絞りたいけど、listは外でも使いたいときってどうしてる? list, err := getList() if err != nil{ doSomething() } ずっとこれで書いてるけど、errの汚染が気持ち悪くてしょうがない
var list []string { var err error if list, err = getList();err != nil{ doSomething() } } 理解できてなくて、返信遅くなったけどありがとう。 こういうこと?確かにいけるわ
>>857 それ読んだ感じ、Go2ドラフトの3つのうち2つは、近いうちに実装されるみたいね。 ジェネリクスはまだ揉めているようだ。 Go 1.13 → errorに他のエラーをラッピング可能になる Go 1.14 → ビルトインtry導入 ドラフトのエラーハンドリングはボツになって、代わりにtryになった。 といっても、他の言語のようなtry〜catch構文じゃなくて、 if err != nil { return err } のシンタックスシュガーっぽいが。 a, err := foo() if err != nil { return err } ↓ a := try(foo()) >>859 コピペ冗長なコードが減っていいですね。
1.14待ち遠しいね
糖衣構文と言うことは従来の書き方でも行けるんよね 天才達が考えた事なら間違いない
一見して制御構文に見えないけど制御構文なので不気味だなとは思う
z := try(foo()).bar(try(baz(try(x, err)))) うわあああ
tryリジェクトかよ エラー処理にどれだけ時間かける気だよいいかげんにせーよ
ほぼ宗教戦争だからな ただしばらくしたら結局普通に入ると思うわ 他言語からの流入者が増えるに連れてコミュニティ内のtry賛成派が増えると思うし
それ繰り返したらjavaになるだけだろ。バカなのかな。
なんでもそうだけど 初期よりの中期が一番完成度が高い
>>868 良い悪いじゃなくて確実にそうなる。
特にGoはコミュニティの意思が最優先だから、人が増えたら絶対に回避できない。
nilチェックでいいと思うけどね Cみたいなもんなんだし
pythonとgoのどちらかを学ぼうと思っているのですがどちらのほうが就職では役に立ちそうですか? ごく簡単なHPを作れるくらいのプログラミングの知識しかありません
>>876 比較的新しい言語のほうが寿命があるかなと
pythonは今大人気の言語のようだしgoもgoogleだから伸びていくように思います
>>877 特にこれといったものはないですがweb上で動かせるようなのがやってみたいですね
片方だけとかケチくさいな、両方やればいいのに Pythonから始める方が楽だと思うが
Web上で動かすって言ってもクライアントしたいのかサーバーしたいのかにもよる Goスレだから一応言うとGoは基本サーバーアプリケーション向け
勉強でwebsocketでチャットするサイト作ってて、 待ち受け用のただのhtml生成と、特定pathでwebsocketでjsonやりとりするようにしてるんだけど こういうhttpとwebsocketみたいな別機能?って、別バイナリに分けるべきなんだろうか それはそれでサーバ設定がめんどくさくなりそうなんだけど
>>878 いわゆるWEBサービスみたいなのを作りたいならgoはあまりおすすめしない
作れないことはないけど主流とは言い難いし、職に就きたいという理由ならそんな仕事を探すのはほぼ無理
たぶん君の希望に1番近いのはRails
>>886 rails?初めて聞いたわ
pysonとかyoutubeなんでしょ?
railsってそれらを押しのけるほどの力を持ってるの?
∩___∩ | | ノ\ ヽ | / ●゛ ● | | | ∪ ( _●_) ミ j 彡、 |∪| | J / ∩ノ ⊃ ヽ ( \ / _ノ | | .\ “ /__| | \ /___ /
初心者なんで有名ドコロしかしらない アプリっていうのはpythonとかgoじゃ作れない?
マジレスすると なんていうか、 バイクレース出るならハーレーっすかね?有名だし。 ってバイクの免許持ってない人が言ってる感じ? 多分プログラミング言語云々言う前に もっと根本的な事勉強した方が良いと思う。
javascriptでフロントエンド? goでサーバーサイド みたいな感じで2つ学べば大丈夫 みたいな認識で大丈夫でしょうか?
釣りとか気にしてるのって馬鹿らしいと思わない? マジレスしたら恥ずかしいと思ってる奴の方が 人間的に恥ずかしいと思うが。
>>893 とりあえず最初に勉強するのは一つの言語に絞った方がいいよ。
goは初学には向いてないと思う。
まじか もうプロゲートで最初の2つの講座終わったところなのに・・・
プロゲートって初めてみたけど、go講座は4コマで、 3コマ目に関数、4コマ目にポインタだから、 毒にも薬にもならないね このサービスが1年以上もつんだ
4コマ終わればテトリスくらいは作れるようになると思ったんだがそうじゃないんか? もう有料会員になっちまったよ
調べてみましたが web系だと HTML CSS Sass javascript go やっておけば大丈夫そうですね
サーバー側は、アマゾン、グーグル、Heroku など、すべてで採用されている、Ruby が標準です! Ruby をやったあとは、Ruby 実装系を、JavaScript で作り直した、Node.js をやる。 Node.js パッケージマネージャーの、npm, yarn は、Ruby のBundler のコピーです クライアント側は、HTML, CSS/SASS, JavaScript, jQuery, Vue.js など 最初に、Ruby, Node.js, VSCode のインストールすればよい これらを数年やったら、Kotlin, Go, Elixir を学ぶ
*by厨はpythonスレでよく見かけたがgoには来ないもんだと思ってた
>>900 手に職を意識してるんなら、goよりはnode.jsにしとけ(´・ω・`)
流石に今からやるならNode.jsよりはGoだと思うけど… ただフロントエンドでJSから逃げられない事を考えたらバックエンドもNode.jsを使えば多少楽になる
調べてみたらSassってRubyじゃないと使えないみたいですね
>>901 RubyはGoに相当するものだと思えばいいですか?
rails-Rubyはunity-C#みたいなもんですかね?
node.jsも新しい知識です
Sassはツールであって、単にrubyで動くだけよ。 俺は文法が気に食わんから、less使ってる。
>>904 なんでバックエンドでnodeを使うと「楽になる」んだ?頭沸いてんのか?
>>908 学ぶ言語の数を減らした、という意味で「楽になる」と言ったつもりだった
ちなみにどういう解釈のもとで「頭が湧いてる」と感じた?
エンジニア志望の学生100名が回答した、プログラミング言語トレンド発表
初めてプログラムやるやつが最初からGoなんてやらんだろ
最近この手の派遣転職サイトはろくなことしてないわ どことは言わんがエンジニアに金渡して記事書かせたり 自分たちの都合の良い言語を持ち上げまくるのはマジでやめて欲しい
PHPはもう過去の遺産をメンテする用途でしか使わない気がする Rubyもいずれそうなると思う Javaは案件から見た立ち位置的にはCOBOLだよね。一部で絶対死なない言語になりそう
PHPってインストール直後に 勝手にindex.phpが造られて 鯖環境晒されるやつだろ? セキュリティーホールではIISより最悪 IISとのコンボでもマジ最凶 SQLまで実行出来たωωω
>>924 XAMPPでもインストールしたのか?w
1.13 TLS 1.3 enabled by default Uniform and modernized number literal prefixes Support for error wrapping
コントラクトってHaskellでいうところの => の左側に書く奴?
でもgoのcontractのコード、キモいんだよなぁ。
丸括弧ばっかりでコード読みにくくなりそ あと、原文のボリュームがすごすぎる もう少しシンプルにならんもんか
他の言語のものとは違うとわかってて名前をかぶせてくるのはほんとやめてほしいわ
Haskellの型クラスみたいな感じね この手の言語でちゃんと使えるのは凄いかもしれん
WEBサーバー用に勉強したけど、デフォルトではORMもクッキーの暗号化もフォームの秘密鍵もないのかよ。 これでフレームワーク使わないのが主流って、セキュリティ穴だらけのサイトが乱立しそう。 セキュリティ対策はできてるつもりになってて、実は全然できてない奴が多いからなー
でもhttpサーバーなしでwebサイトを公開できるのは感動だったな ありゃ楽だわ
むしろデフォルトで「ORMもクッキーの暗号化もフォームの秘密鍵」もある言語ってなに? Java EE を「デフォルト」だと言い張れるなら、Java がそうかな? > でもhttpサーバーなしでwebサイトを公開できるのは感動だったな これも何を言ってるのかさっぱり分からない。Go のどこにそういう種類の感動があるのやら。 なんか根本的に勘違いしているというか、正しい技術的理解ができてないんでは…。 「できてるつもりになってて、実は全然できてない」のはまずいですよ!
実用性は無視してhttpサーバーなしでwebサイトを公開できるだろ…
Goは単純なマイクロサービスみたいのを簡単に提供できるのが魅力
> でもhttpサーバーなしでwebサイトを公開できるのは感動だったな 普通はそのまま本番公開なんてしないぞ 本番ではリバースプロキシのバックエンドとして使うんだよ
一応書くけどリバースプロキシ自体はhttpサーバじゃないよ webサーバがその機能を持ってることもあるけどね この場合だとリバースプロキシのバックエンドと書いてるそのものが一応webサーバかな じゃあ張り切ってリバースプロキシを使う理由をどうぞ!
「httpサーバーなしで」というと"net/http"も使わないように思うがどういうことなんだろう? 逆に、それを使う前提ならpythonやC#でも同じようにできるしな。
Laravel使ってるあたまペチパーが紛れ込んだみたいなレス
本番環境でのデプロイをやったことのない奴にはgoの楽さがわからないんだろうな
初学者だけど$GOPATH/src以下にgetしてきたソースも自分のソースも何もかも味噌も糞も一緒に入れなきゃなんないのが…そのなんだ その法則を乱そうと足掻いたけど泥沼。面倒すぎる! 諦めて素直にGOPATHにプロジェクト移すかなーと日和かけてる GOPATHってMavenリポジトリみたいなもんかと思ってた時期が懐かしい
外から来るものと、内から行くものを分離して管理したいと考えるのは、池沼と呼ばれるほどの馬鹿な考えなのか?
>>954 おっ、これか!かなり新しい機能なんだね
普段からシェルスクリプトとC書いてるから 毎回エラーチェックするのは特に違和感なかったな 他の言語の人からしたらtryやbeginで囲ませろってなるのはわかる
なんでもかんでもthrowしてくるJavaとかに嫌気をさしてたんで、Goは結構気に入ってるJava歴20年長な俺 catchの羅列はもうお腹いっぱい
>>954 新しい機能すぎて、まだVSCodeのプラグインが部分的にバグるという罠
デバッグつきでは動くのに、何故かデバッグなしで起動できん現象
パッケージのサイト名をexample.comから変えようと思ったんだけど、Gorename使ったことないんでよくわからない どこのwebサイト読むと分かりやすい? VSCodeでりふぁくた
vim-goはマージ版gocode使ってるそうでVimで補完プラグインを探してたところ govimがよさげだった
どんなんだっけかな?全く困らんから別に要らんけど Javaカスみたいなのはやめてほしいな〜
tryリジェクト以来、議論がトーンダウンしちゃったのかな 結局、if err != nil でいいじゃん的な
プログラミング初心者です。 N回同じ文字列を出力するにはどうすればいいのでしょうか?
fmt.Println(strings.Repeat("Hello", N))
go modules で GOPATH 以外にプロジェクト置いてるんだけど、godoc -http=6060とドキュメントを確認しようとしても出てこない と探すとissues#26827がクローズしてないからまだmodulesには対応してないのか メンドクセ
issues読んでみたら1.13試してみてという話があったけど、 1.13入れてみたらgodocのインストールがうまくいかねー
code.google.com/p/go.tools/cmd/godoc から入らなかったんで、 golang.com/x/tools/cmd/godoc から入れたけど、やっぱりmodulesなソースはパッケージの一覧に出ない いちいちgithubにプッシュしてgodoc.orgで見てる…
modulesは見限って$GOPATH/srcで開発するしかないのか?
うちとこJava/C#が主力な会社 面白そうだから布教してみようと思ったんだけど、結局C言語からの直系なだけで、Java以降とは似て非なるものだから布教は無理なんだと、よくわかった あいつら新人類は実体とポインタにまみれたC言語の素養がないから、うっかりと参照を代入する気楽さで構造体の実体をコピーして操作する感じのミス連発 C言語の経験なしにも関わらず、苦労せずにGo言語に慣れたって人いる? そして、今さらポインタと実体を残したgoogleの意図も良くわからない。参照でよくね?
ただの慣れじゃねC#の構造体も値型だし 値型の方が有利な場合がある 例えば構造体のでかい配列を作る場合は値型の方が一気にメモリ確保するから速いはず
>>978 回り見てるとスクリプト言語出身の人はGo移行についてこれてない
Cでそれなりの規模のアプリ書いたことがある人がジワジワと良さを認識してる(すぐに良さがわからないのは共通してる)
C++出身の人はRustを気に入ってるが
ポインタと実体という概念がどうもしっくりと来ないみたい Java以降だとプリミティブ以外は全部インスタンスの参照で統一されていてシンプルになってるから そこいらのハードルが新規参入の障壁になってる可能性は高いんじゃないかなとか感じてる しかし惜しいと思うのは、実体とポインタが混在しえるコンセプト Cからの派生だからといって実体としてのインスタンス化って、本当に必要だったのかな? &とか*なんて廃止して、全てはポインタの言い換えである参照を扱うというJavaとかのアイデアは多重間接参照(ポインタへのポインタ)が扱いづらくなる一方で概念的な単純さをもたらしてくれる ぶっちゃけポインタへのポインタなんて、普通はそんなに使うこと無いから 参照を採用していたら、レシーバーはポインタで記述とか、実体でのセレクタでポインタレシーバーも呼び出せるとかイミフな仕様もスッキリとしたんじゃないかと 多分、ポインタを残したことには深慮遠望があるんだろうけど、使っていてイライラしてくる
具体的には構造体のスライスを使うために構造体ポインタのスライスを書くのがイライラ でもポインタにしないとrangeでコピーされちゃうから これって実はエレガントな書き方があったりする?
まあ確かにその辺は混乱する ローカル変数の実体のポインタをリターンするとか C脳ならありえない
Goは全然気持ち良いけどDartの酷さがやばい あれはスクリプト言語出の人らだと大丈夫なんか?
>>979 構造体のデカイ配列ったって、マーシャリングして外部DLLに渡すとか極特殊な用途でしか使わなくない?
Goは確かに気持ち良いね、テストからカバレッジ、マップにスライス、ゴルーチンとチャネル (でも気持ちよさの基準がCなのは否めない) interfaceとか目から鱗だった。元ネタはなんだろ?
前は動いてたのに run も build も package main: no Go files in hogehoge とか can't load package: package main: no Go files in hogehoge とか 出るようになって ハマった ソースファイル名を _fugaufa.go みたいに _ で始まってたらあかんの? 時間還せ
>>986 >気持ち良い
ガベコレとゴルーチン以外で何があるんです?
>>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
>>989 言われてみれば、varって昔のBASICのlet並みに要らない子だね
変数名 型 だけでも、構文として破綻しているようには見えないもんな。C言語もそうだし 当然にvar{}も要らんし あれ、func も不要じゃね? なにか必要である理由ってあったかな?
構文解析が楽とかだった気が 最初の方のトークンでどの構文(変数定義とか関数定義とか)なのかが分かったほうが 後の方のトークンでやっと分かるより楽
んー、:=で型推測をぶちこんでくるアグレッシブさなのに?1000ならIsNil()追加
-curl lud20241214174555caこのスレへの固定リンク: http://5chb.net/r/tech/1510395926/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「Go language part 2 YouTube動画>2本 ->画像>7枚 」 を見た人も見ています:・Go language part 5 ・Go language part 3 ・【EBiDAN】SUPER★DRAGON Part1 ・Vue vs React vs Angular その2 ・Vue vs React vs Angular Part.4 ・Vue vs React vs Angular Part.2 ・beatmaniaIIDX 26 Rootage 情報スレ Part16 ・Vue vs React vs Angular vs Svelte Part.9 ・【ワッチョイ有】Vue vs React vs Angular Part.5.5 ・【新生FF14】Mandragora鯖スレ Part72【マンドラ】 ・Vue vs React vs Angular vs Svelte Part.11 (376) ・Io Language ・http://anago.2ch.net/heaven4vip/ ・【姉Ageha】美咲あいり【Cool Beauty】 ・http://anago.2ch.net/slotk/ ・【バーチャル詐欺師】Manager2525監視スレ13 ・Docker/HyperVとVirtualBox/Vagrantが共存可能に ・GEZAN Part.2 ・angela Part37 ・NetBeans Part7 ・ARToolKitでARを作ろう ・Strange Brigade Part 1 ・Foxage2ch (FoxAge5ch)part3 ・homage オマージュ質問スレ Part1 ・Android開発質問スレ Part2 ・Angel Beats! Part37 ©bbspink.com ・【フーリガン】Angelic Upstarts【大合唱】 ・【age of z】攻略や質問など Part11 ・夏休みだから実験中です $Mango->{part->[43] ・【あんじゅれ】Ange☆Reve part4【アンジュレーヴ】 ・STRANGER OF PARADISE FINAL FANTASY ORIGIN part2【FFオリジン】 ・【LAA】Los Angeles Angels【Rally Monkey】 Part.2 ・【Archange】STU48瀧野由美子200系【二百度参り】 ・ARToolKitマルチマーカを使うプログラムが難しい件 ・WPF(.NET, WinUI) GUIプログラミング Part30 ・【Archange】STU48瀧野由美子202系【まだまだ自】 ・秋になっても実験中です $Mango->{part}->[46] ・【mobage】戦国武将姫 MURAMASA 楽市・ギルドpart28 ・【Archange】STU48瀧野由美子203系【TAKINO美術館】 ・DDO Dungeons&Dragons Online Unlimited Part23 ・WPF(.NET4.x, .NET Core) GUIプログラミング Part25 ・【LAA】Los Angeles Angels part107【ワッチョイ無】 ・【LAA】Los Angeles Angels part48 【ワッチョイ有】 ・【A.LANGE】A.ランゲ&ゾーネ part10 [無断転載禁止] ・【LAA】Los Angeles Angels Part65 【ワッチョイ有り】 ・【LAA】Los Angeles Angels part75 【ワッチョイ無】 ・【LAA】Los Angeles Angels part105【ワッチョイ無】 ・【LAA】Los Angeles Angels part158【ワッチョイ無】 ・【LAA】Los Angeles Angels part71 【ワッチョイ無】 ・【LAA】Los Angeles Angels part46 【ワッチョイ有】 ・夏休みだから実験中です $Mango->{part->[44] [無断転載禁止] ・【ポーカー】m HOLD'EM (エムホールデム) Part28【テキサスホールデム】 ・Android Studio Part4 (689) ・Regular Expression(正規表現) Part17 (255) ・WPF(.NET, WinUI) GUIプログラミング Part33 (439) ・Chage Vol.9 ・Chage Vol.18 ・Chage Vol.12 ・manage:経営学[レス削除] ・【姉貴と】Solange☆ソランジュ【比べんな】 ・manage:経営学[スレッド削除] ・manage:経営学[レス削除]
13:56:19 up 4 days, 14:59, 2 users, load average: 50.20, 55.20, 53.83
in 0.61792302131653 sec
@0.61792302131653@0b7 on 011803