Go language part 2
■ このスレッドは過去ログ倉庫に格納されています
>>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のキーノート https://www.youtube.com/watch?v=aRkx_rKgnxo の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 } ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる