はじめに Goはできるだけ冗長な機能セットを増やさずに応用の効くシンプルで強力な機能セットに絞り込んだ設計であることを目指した言語処理系です。なのでリッチな機能を持つ言語処理系経験者からするとたくさんの「なぜ？」を感じると思います。 しかし、Goの開発者たちは他の言語処理系にある機能だからGoにも採用しようとは一切考えません。あくまで大きなゲイン（デメリットをメリットが大きく上回る）を示されるまでは採用しません。特に言語仕様についてはより変更を嫌う傾向があります。「Go1の約束」というものがあり、Go1.0向けに書かれたコードはGo1.xでも動くもしくは機械的にコードにパッチを当てることで移行可能にするということをずっと守っています（約９年？）。 最近になりGo2プロポーザルがたくさん書かれ、それらの提案のうち言語仕様に関するものは最終的に２〜３個に絞り込まれ順次採用されていくという計画で
GitHub にコードを上げてます。 2021-11-17 時点で Go の Generics の機能を使ったキャッシュライブラリはおそらくないでしょう。Generics を使った例の一つとして参考にしてください。 Star をくれると大喜びします。 本記事ではこのキャッシュライブラリを作ってみて Generics に対して気が付いた点と発見した tips や微妙だった点を紹介していきます。 もし Go の Generics って何ができるんだっけ？となっている方は是非こちらの記事にも目を通してみてください。 any でゼロ値を返す これは @syumai さんから教えてもらった tips です。 次のような any と error を返すコードをよく書くことになるでしょう。関数内で error が発生した時に今までゼロ値と error を返すコードを記述していたはずですが、ちょっと頭を捻
Goの利点を使って実装するコツやノウハウを書くことがコミュニティにとってプラスになると思っているのでそれに専念したいという考えはありますが、Goの苦手な領域にGoを採用してしまってヘイトを溜め込んでしまう事例を見かけたりします。 こういう悲劇の起こる可能性を少しでも減らせたらという思いで、Goの現状の苦手な領域について解説しようと思います。Goを学び始めにこれらの領域に手を出すのは避けましょう。 Cgo is not Go GoはCGO連携でC/C++資産を利用することができますが、メモリアロケータの異なる処理系を繋ぐ関係上、お互いに呼び合う際のパラメータや戻り値はほとんどのケースでコピーが必要になります（Cの型でメモリ確保しCの型のまま受け渡しする場合はOK）。なので高頻度に呼び合うような用途には不向きであるというのはSWIGなどのような複数の処理系を連携させる仕組みと同様です。 また、
TL;DR Go(のランタイム)は以下のタイミングで自動的にGCを実行する 前回のGC後に占有していたメモリと同量を新たに確保したとき 前回のGCから2分後 cgroupなどでメモリ制限しているときは、メモリ使用量が制限の50%以上になったらruntime.GC()を呼び手動でGCすべきである 前置き: GoとOOMのこれまで 以下はGo 1.16での調査結果です。Goのバージョンが異なった場合は事情が異なる可能性があります。 Goでプログラムを書く際に、使用メモリ量を気にしなければならないシーンはGCのおかげでそう多くはありません。実際それは間違いではないのですが、運用まで視野に入れるとそうは言ってられないことがあるのもまた現実です。昨今はコンテナの利用が当たり前になったことに伴い、OOMによりプロセスが強制的に終了させられることもあり、それを避けるために一定量以下のメモリで動くことが重
日々コードを書く中で起こり得るインセキュアなコード米内貴志氏：米内です。今日は「Goをセキュアに書き進めるための『ガードレール』を整備しよう」という題で、組織としてGoを使うときにセキュリティを底上げするための仕組み作りについて話をしようと思います。よろしくお願いします。 まず簡単に自己紹介をさせてください。私は米内貴志と申します。株式会社Flatt Securityでセキュリティプロダクトの開発、今は特にeラーニング事業の開発をしています。社内でもけっこうGoを使っています。 もともとWebブラウザーとセキュリティが好きで、最近『Webブラウザセキュリティ』という本をラムダノートさんから出版しました。気になる方はぜひ読んでみてください。 ここから本題に入っていきます。Goに限らず日々コードを書いていく中で、セキュリティ的に良くないコードを書いてしまうことはけっこうあると思うんですね。知っ
Goのエラーハンドリングが採ったスタイル 多値返し 直積（関数の返値とエラーを両方返す） try-finallyをdeferという機構でカバー panicはプロセスを落とすためのもの Goはこの戦略でエラーハンドリングを行うとしましたので、「多値はなぜタプルじゃないんだ？」、「直和（返値orエラー）で十分じゃ？」「panic-recoverでtry-catchできそう？」などいう様な他の処理系の風習を持ち込むことは意味がありません。そしてそれらの提案の多くはすでに検討されリジェクトされてきた経緯があります。 「try組み込み関数」プロポーザルなんかも検討されマージ直前くらいまで進んだこともありますが、「Goのエラーハンドリング」にとって一長一短がありました。その欠点課題は解決できずに最終的にリジェクトされました。 「多値返し」は実にCPUフレンドリーな機構で、C言語の関数呼び出し規約にちょ
The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license. 種々の linter が様々なプロダクトの品質を高めてきた、というのは疑う余地のない事実です。実装の初歩的な問題をエディタ内や CI/CD パイプライン中で機械的に検出できる環境を作れば、開発者はコーディングやコードレビューの邪魔になる些末な問題を早期に頭から追い出し、本質的な問題に集中できます。 また、そのような環境づくり（e.g. linter のルールセットの定義、組織独自のルールの作成、…）は、まさに開発組織のベースラインを定義する作業として捉えることができます。一度誰かが定義
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
こんにちは。Goのテスト、書いていますか？ 私はめちゃめちゃ書いています。 VSCodeに拡張機能(vscode-go)を入れることで、テストコードを自動生成することができることを最近知ったのですが、これがとても便利です。 使い方は以下の記事でまとめられています。 kdnakt.hatenablog.com これはめちゃめちゃ便利なのですが、デフォルトだと少し物足ないところがあったので、カスタムテンプレートを作成しました。 GitHub - Magaming/gotests-templates vscode-goは内部でgotestsを使っているので、それ用のテンプレートを用意している形です。 具体的には次のようなことをしています。 go-cmpを使う 標準だと reflect.DeepEqualで比較しているが、これだとtime.Time型を含んだ構造体の比較とかで死ぬ go-cmpは、
Go 言語は struct のレシーバがポインタの場合は実体であってもポインタの場合であっても呼び出せるので、もし struct が参照カウントに従い動作する様な場合は実体でコピーされてしまっては困る場合があります。例えば以下の様なインタフェースを考えます。 package main import ( "fmt" "sync/atomic" "time" ) type foo struct { n int64 q chan struct{} } func (f *foo) Add() { if atomic.AddInt64(&f.n, 1) == 1 { f.q = make(chan struct{}) } } func (f *foo) Done() { if atomic.AddInt64(&f.n, -1) == 0 { f.q <- struct{}{} } } func (f
Go初心者がやってしまいがちなやらない方がいいことを書き出してみました。 情報検索や環境構築 golang.jpを見に行ってしまう Golang（ごーらんぐ）と呼んでしまう(by hogedigo) depが最新推奨のパッケージマネージャだと勘違いする(Go標準の「go mod」を使おう) 「GO？？？」環境変数を理解せずに設定しまくる（わからない場合は一切設定しないのが正しい） しょっぱなからgvm,gobrew,goenvなどのマルチバージョンのマネージャを入れようとしてエディタ連携環境構築に失敗する （複数バージョンのGoの運用は既に標準のGoだけでできるようになっている） エディタにgoimportsやgolintを設定し忘れる OSのパッケージマネージャまかせで古いGoやgccgoをインストールしてしまう エラーハンドリング周り err変数名のバリエーションを増やしすぎる（ほとん
はじめに 下記の記事でxoを導入してどうやって管理運用しているかについて書いたが、すべてうまくいっているわけではない。 すんなりハマらず、色々と困った点はあった。 このすんなりハマらなかった点やそれに対してどうやって対応しているか等を書いておく。他の人も参考になったら嬉しく思います。 tsuyoshi-nakamura.hatenablog.com 前提的な所 既存に関係なく、まったくの新規の開発ではなく、DB(mysql)は既存で運用されているtableを参照するという制約があった。 まぁこれが原因でうまくハマらない点が出てきたのだが、マイクロサービスへ移行する過渡期などは致し方ない所があると個人的には思います。 困った点 困った点1 : indexの貼り方がちょっと変な場合 歴史的な背景はおいておくとして下記のようなindexが貼られてた場合です +----------+-------
はじめに Goの正規表現は遅いと言われていることが以前から疑問だったので調査してみました。 こちらの記事やこちらの記事を拝見する限り ① 現実的なユースケース(例えばURLのパースなど)ではGo言語の正規表現は使うべきではなく、stringsパッケージの標準の関数を利用した方がパフォーマンスとしては良い。 ② Go言語で正規表現を利用するために必要な"正規表現オブジェクト"を並行にアクセスするにはパフォーマンスが問題になるので注意が必要。 とあります。その理由は、それぞれ以下に集約できるようです。 ① Go言語標準の正規表現ライブラリは、正規表現と検査文字列の長さに対して常に$O(n^2)$のオーダーで計算量が増加する安定したアルゴリズムを採用している。 ② "正規表現オブジェクト"を用いたマッチング処理には排他制御が行われている。 調べてみる Go言語のpkg/regexpの公式ドキュメ
はじめに 今年の 8 月にリリースが予定されている Go 1.13 では、Go 1.11 で導入された Go modules に加え、Go module proxy といった新しいエコシステムが登場します。 そこで、そもそも Go modules は何を行っているのかや、何ができるのか、どういった要素で構成されているのかを紹介します。 また、古い Go バージョンから Go 1.13 へアップデートする場合や、 dep や Glide といったベンダリングツールから Go modules へ移行する際の懸念点も併せて紹介します。 先日発表した "Go Modules and Proxy Walkthrough" はこのポストがベースになっています。 TL;DR な人はスライドを見るのがおすすめです。 speakerdeck.com Go Modules Go modules という仕組みは
他の言語になれた人が、初めてGoを書いた時にわかりにくいな、と思った部分はどのようなところがあるのか、難しいポイントはどこか、という情報を自分の経験や、会社の内外の人に聞いたりしてまとめてみました。まだまだたくさんあるのですが、多すぎるのでまずはこんなところで。コンテナで開発することがこれからますます増えていくと思われますし、その時にコンテナとの相性が抜群なGoをこれから使い始める人もどんどん増えていくと思います。 Goは特に言語のコアをシンプルに、何かを実現するときはそのシンプルな機能を組み合わせて実現しよう、というコンセプトです。つまり、他の言語で実現したいこと・できていることに比べて、Goは組み合わせ（イディオム）でカバーする領域が広くなります。そのあたりのとっかかりになる情報を提供することが、これからGoを触る人にとってつまずきを減らすことになると思います。 Go Conferen
// ReadTimeout is the maximum duration for reading the entire // request, including the body. // // Because ReadTimeout does not let Handlers make per-request // decisions on each request body's acceptable deadline or // upload rate, most users will prefer to use // ReadHeaderTimeout. It is valid to use them both. ReadTimeout time.Duration // ReadHeaderTimeout is the amount of time allowed to read
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
