When I first started trying to understand the memory allocator of Go, it was maddening. Everything seemed like a mystical black box. As almost every technical wizardry is hidden beneath abstractions, you need to peel off those layers one by one to understand it. In this blog post, we will exactly do that. Do you want to learn everything about Go memory allocator? You’re reading the right article.
Go で DDD をやっていくため、 struct に getter setter を生やせる go-genaccessor を作りました。 hori-ryota/go-genaccessor 対象ディレクトリ内のファイルを走査して accessor を生成する getter setter の struct tag を検知して自動生成 タグのパラメータに指定することで alias 対応 デフォルトがカレントディレクトリなので //go:generate go-genaccessor を対象ディレクトリに記述すれば go generate で起動する 動作サンプル こんな感じで定義します。 package example import ( "encoding" ) //go:generate go-genaccessor type Person struct { id string `get
はじめに Goの新しいerrors パッケージ xerrors(Go 1.13からは標準のerrorsパッケージに入る予定) - Qiita 上記の @sonatard さんの記事にある通り、 Go 1.13 から golang.org/x/xerrors が標準の error パッケージとして入るそうです。 標準でエラーを追いやすい形の仕組みができるのは嬉しいですね。 この記事では xerrors と使用する上で発生しそうな問題と、 問題を防ぐために静的解析してチェックする lint を作成しましたので紹介します。 pkg/errors との違いと感じている問題 スタックフレームを明示的に積んでいく必要がある 今までは github.com/pkg/errors を使用してエラー伝搬してスタックトレースを表示させるのが主流だったかと思います。 pkg/errors では errors.N
先日 xerrors パッケージがリリースされました。 このパッケージは、Proposal: Go 2 Error Inspection で提案されているものをGo1向けに外部ライブラリとして試験的に実装したものです。 Goの標準ライブラリではありませんが、Go公式がメンテナンスをしています。 このパッケージができた背景は、今まで多くのGoエンジニアは下位層のエラーの情報を伝播させるために pkg/errors パッケージ などの外部ライブラリを利用していました。この手法が開発者の間で普及したため標準ライブラリで正式に検討を始めることとなりました。 2019/9/4更新 Go 1.13では %w でのラップや Is メソッド、 As メソッドは正式に導入されました。 しかし%+w や %+v によるスタックトレースの表示の採用は見送られました。 スタックトレースの表示が必要な場合はxerr
未リリース版のGo仕様や実際の動きを確認する。 今回は2019/02/14現在未リリースのGo1.12の仕様を確認した。 TL;DR 未リリース版の仕様やリリースノートを確認したいときはtip.golang.orgを見る https://tip.golang.org/doc/go1.12 未リリース版の挙動を確認したいときはDockerイメージを使うかコードをビルドする https://hub.docker.com/_/golang 未リリースのGoの仕様の調べ方 Goの仕様は基本的にgolang.orgで公開されている。当然ここに記載されている仕様はリリース済みの最新版の仕様だ。 2019/02/14現在まだリリースされていないGo1.12の仕様を調査したいときはtip.golang.orgにアクセスする。 tipのほうならgolang.orgに無い未リリースバージョンの(現時点で予定さ
TL;DR Go Modules(vgo)はGo1.11から導入され始めたGoの新しいバージョン管理 Go1.12ではまだ有効にはなっていない(Go1.13からはデフォルトで有効になる) Go Modulesの概要とTipsなどを簡単にまとめた Go1.12のModules関連の変更をDockerを動かして確認してみた GOPATHi外でgo.modがなくてもgo run可能 replaceディレクティブで依存パッケージをローカルのコードを使って解決 etc… 確認に利用したDockerfileやスクリプトは以下のリポジトリにある。 https://github.com/budougumi0617/gomodules-explore vgo発表前のGoのバージョン管理は以下のような手法が取られていた。 go getでgo1タグ・ブランチもしくは最新のmasterブランチを取得する go g
こちらの記事はGo言語初心者向けのサイト「50 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs」の中から初級編だけを日本語に翻訳したものとなります。特にGoを始めたばかりの方にはとても役立つ情報かと思いますので是非ご覧ください。また、多少日本語がおかしい部分あるかもしれませんがご了承ください。もし分かりづらい部分は直接本家サイトを参照頂ければ幸いです。 概要Goはシンプルで楽しい言語ですが、他の言語と同様に、いくつかの問題点があります。それらの多くの問題点は、Goのせいではありません。あなたが他の言語から来ているならば、これらの間違いのいくつかは自然な罠です。 公式情報、wiki、メーリングリストでの議論、Rob Pikeによる素晴らしい投稿やプレゼンテーション、そしてソースコードを読むことで言語を
Sometimes we find ourselves dealing with a linter error that states something like: warning: struct of size 40 could be 32 (maligned) So we search at Google, Stack Overflow, GitHub, official docs and other communities out there that may help us with this problem. However, the lack of information just leave us more confused and empty handed. There’s clearly something wrong with our code, so what ex
Some time ago my friends and I came up with an idea of merging our IRC bots and rewriting them in Go. In order to avoid rewriting most of the already existing functionality we attempted to find existing libraries supporting the web APIs used in the bot. One of the libraries needed in our project was a Reddit API library. This article was inspired by the first three libraries that I found and which
Writing Go programs that talk to services over HTTP is easy and fun. I’ve written numerous API client packages and I find it an enjoyable task. However, I have run into a pitfall that is easy to fall into and can crash your program very quickly: the default HTTP client. TL;DR: Go’s http package doesn’t specify request timeouts by default, allowing services to hijack your goroutines. Always specify
The Go Garbage Collector (GC) works exceptionally well when the amount of memory allocated is relatively small, but with larger heap sizes the GC can end up using considerable amounts of CPU. In extreme cases it can fail to keep up. What’s the problem? The GC’s job is to work out which pieces of memory are available to be freed, and it does this by scanning through memory looking for pointers to m
依存がなく、テスト可能であり、クリーン。 Uncle Bobのクリーンアーキテクチャの概念を読んだので、これを私はGoで実装してみたいと思います。このアーキテクチャは、自分たちの会社である Kurio – App Berita Indonesia で使っていたものに似ていますが、少し違っています。大きな違いはなく、概念は一緒なのですが、フォルダ構造が違っています。 サンプルのプロジェクトとして、記事をCRUDで管理するリポジトリを https://github.com/bxcodec/go-clean-arch にpushしてあります。 * 免責条項 ここで使われているどのライブラリあるいはフレームワークも、利用を特別推奨しているものではありませんので、ご自身あるいはサードパーティによる同じ機能のものと入れ替えることが可能です。 基本的な考え方 ご存知のように、クリーンアーキテクチャで設計
Go (その3) Advent Calendar 2016 11日目の記事です。 Go言語の生みの親、Rob Pikeが2015年のGopherfestのセッションで 言っていた、Go Proverbsを自分の勉強がてら和訳してちょっと解説してみる。 後半に行くに連れて集中力が切れたり、いろいろ調査不足のところや、認識違いの部分もあると思うので、 そういう部分のところがあったら是非指摘してください。自分でも気づいたら修正していきます。 ちなみにタイトルの「Go Proverbs」は、動画の冒頭で囲碁の話をしているとおり「碁の格言」の直訳で、 「Goの格言」にかかっていておしゃれ。 メモリを共有して通信したり、通信してメモリを共有してはならない 原文は"Don't communicate by sharing memory, share memory by communicating." こ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く