もう2年近く前の記事だが，「Go 言語と Unicode 正規化」の脚注でこっそり「単に全角・半角変換ができればいいのなら golang.org/x/text/width パッケージをお勧めする」と書いていたのだが，今回はその話。 golang.org/x/text/width パッケージ golang.org/x/text/width パッケージ1 では半角/全角変換用に以下の width.Transformer が用意されている。 var ( // Fold is a transform that maps all runes to their canonical width. // // Note that the NFKC and NFKD transforms in golang.org/x/text/unicode/norm // provide a more generic

今回も小ネタで。 go mod graph コマンドを使うと以下のようにモジュール間の依存関係を表示してくれるのだが $ go mod graph github.com/spiegel-im-spiegel/gpgpdump github.com/BurntSushi/toml@v0.3.1 github.com/spiegel-im-spiegel/gpgpdump github.com/inconshreveable/mousetrap@v1.0.0 github.com/spiegel-im-spiegel/gpgpdump github.com/pkg/errors@v0.8.1 github.com/spiegel-im-spiegel/gpgpdump github.com/spf13/cobra@v0.0.3 github.com/spiegel-im-spiegel/gpg

Ubuntu に graphviz をインストールしたので「何か動作確認できるものはないかなぁ」と思い Go モジュールの依存関係を可視化するツールを作ってみた。 spiegel-im-spiegel/ggm: Graph of Go Modules main.go いっこだけの簡単なお仕事（笑） ダウンロードとインストールは以下の通りでよい（モジュール・モードがオンの場合）。

8月に正式リリースされる Go 1.13 の主な機能 Go 1.13 のベータ版が登場したようだ。 リリースノートも併せて公開されている。 Go 1.13 Beta 1 is released - Google Group Go 1.13 Release Notes - The Go Programming Language Go 1.13 では数値のリテラル表現（2進数表現や浮動小数点数の16進数表現）など色々と重要な機能追加があるが，主なものは以下の通り。 errors パッケージへの機能追加 以前に紹介した golang.org/x/xerrors の機能が正式に errors パッケージに組み込まれるようだ。 階層化 Error パッケージ “xerrors” を試してみる golang.org/x/xerrors の機能をほぼ踏襲しているみたいなので，既に golang.org/

（この記事は Qiita とのマルチポストです。 まぁ，向こうは草稿版だけど） 久しぶりに glide を使おうと最新版（0.13.0）を見に行ったら “Consider switching to dep” とか書いてあるじゃない。 Glide is used by a great number of projects and will continue to get support for some time. But, the near future is likely in dep. dep can handle importing Glide config files. Please consider trying dep on your project or converting to dep. まじすか。 つまり「依存関係（Vendoring）管理ツールとしては dep を推奨

（初出： はじめての Go 言語 (on Windows) その4 - Qiita） 文字列を示す string は不変（immutable）なオブジェクトだが，中身は byte 配列である。 したがって以下のように package main import "fmt" func main() { nihongo := "日本語" size := len(nihongo) fmt.Printf("nihongo = %d bytes :", size) for i := 0; i < size; i++ { fmt.Printf(" %02x", nihongo[i]) } fmt.Println() }

C++ や Java のような言語圏から来た（私のような）人間にとって Go 言語の「オブジェクト指向」はかなり異質なのだが，慣れてみると逆にとても合理的に見えてくる。 なんで C++ や Java はこのようなアプローチをとらなかったのか不思議なほどである。 この最たるものがエラー・ハンドリングだ。 Go 言語には「例外」がない 「例外（exception）」は本来の処理の流れをぶった切って「大域脱出」するための仕組みである。 でも考えてみれば例外というのはかなり微妙な言語仕様だ。 例外が抱える問題というのは本質的に goto 文の問題と同じ1。 オブジェクトの状態ごと脱出するため，（脱出前ではなく）脱出後にオブジェクトの後始末を記述せざるを得ないし，記述するためには脱出前の状態（の可能性）を「知識」として知っていなければならない2。 もし後始末をきちんとしないと，それがバグやリークやそ