List of Generics [text.Baldanders.info]

Go 1.27 のリリース

2026-08-30T05:40:23+00:00

先日 Go 1.27 がリリースされた。

個人的には encoding/json/v2 が（実験的実装じゃなくて）正式にリリースされたことが注目点かな。今はじっくり検証する暇がないので，とりあえずブックマークのみ載せておく。

go fix コマンドについては手持ちのパッケージで一度試したほうがいいかもなぁ。

参考図書

プログラミング言語Go - 丸善出版理工・医学・人文社会科学の専門書出版社: 明解で効率的なプログラムを描くための書。柴田　芳樹訳; Release 2016-06-15; 評価

[Comment] 著者のひとりは，あの “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

Go言語 100Tips ありがちなミスを把握し、実装を最適化する impress top gearシリーズ: Teiva Harsanyi (著), 柴田芳樹 (著); インプレス 2023-08-18 (Release 2023-08-18); Kindle版; B0CFL1DK8Q (ASIN); 評価

[Comment] 版元で PDF 版を購入可能。事実上の Effective Go とも言える充実の内容。オリジナルは敢えてタイトルに “tips” という単語を入れるのを避けたのに邦題が「100 Tips」とかなっていて，原作者がお怒りとの噂（あくまで噂）

reviewed by Spiegel on 2023-08-18 (powered by PA-APIv5)

Go言語で学ぶ並行プログラミング　他言語にも適用できる原則とベストプラクティス impress top gearシリーズ: James Cutajar (著), 柴田芳樹 (著); インプレス 2024-12-04 (Release 2024-12-04); Kindle版; B0DNYMMBBQ (ASIN); 評価

[Comment] 読書会のために購入。インプレス社の本は Kindle 版より版元で PDF 版を買うのがオススメ。「並行処理」について原理的な解説から丁寧に書かれている。 Go で解説されているが Go 以外の言語でも応用できる。

reviewed by Spiegel on 2025-01-25 (powered by PA-APIv5)

Go 1.18 と Generics と Linter

2022-03-19T06:16:40+00:00

予測して然るべきであったが Go 1.18 に組み込まれた Generics と既存の linter の間でトラブルが続出しているらしい。

私も大変お世話になっている Go の代表的な総合 linter である golangci-lint は v1.45 で暫定的な対応を行ったようだ。

So I added a new configuration option inside the run section.
We will not have to remove this option in the future because we will be able to use it for some linters that have a Go version option.

An example:
run:
    go: 1.18
By default, the supported Go version will be go1.17 because it allows us to run all our tests without a huge rewrite.

If you set the version to go1.18, the following linters will be inactive:

bodyclose

contextcheck

gosimple

nilerr

noctx

rowserrcheck

sqlclosecheck

staticcheck

stylecheck

tparallel

unparam

unused

wastedassign

via Support of go1.18 · Issue #2649 · golangci/golangci-lint

この説明にあるように .golangci.yaml ファイルに

run:
    go: 1.18

の記述を入れることで Go 1.18 に対応していない linter を無効にしてくれるようだ。あとは各 lint パッケージが 1.18 に対応してくれることを気長に待つしかないか。

なお Generics の機能を使わないのなら今回の件は気にしなくてよい（笑）

あと golangci-lint-action もいつの間にか v3 に上がってるな。見落としてたかなぁ。この辺はおいおい検証しよう。

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

[Comment] 著者のひとりは（あの「バイブル」とも呼ばれる）通称 “K&R” の K のほうである。この本は Go 言語の教科書と言ってもいいだろう。と思ったら絶版状態らしい（2025-01 現在）。復刊を望む！

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

次期 Go 言語で導入される総称型について予習する（その3）

2020-09-26T14:21:12+00:00

【2021-02-21 追記】 型パラメータの提案（「総称型」というのは厳密には正しくないらしい）は2021年2月に承認され，製造フェーズに入ったようだ。

前回紹介した “Type Parameters - Draft Design” が 2020-09-21 にアップデートされたらしい（最終更新：2020-11-25）。どうやらこれが最終案になりそうだ。

早ければ2021年8月にリリース予定の Go 1.17 でお披露目というスケジュールは変わらない模様。また総称型（generics）に対応した Playground も最終案の仕様で稼働中である。

https://go2goplay.golang.org/

前回からの変更点

前回は，たとえば

type ordered interface {
	type int, int8, int16, int32, int64,
		uint, uint8, uint16, uint32, uint64, uintptr,
		float32, float64,
		string
}

func Max(type T ordered)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

のような記述だったが，今回は型パラメータ（type parameter）の記述がちょっと変わったようで

type ordered interface {
	type int, int8, int16, int32, int64,
		uint, uint8, uint16, uint32, uint64, uintptr,
		float32, float64,
		string
}

func Max[T ordered](x, y T) T {
	if x < y {
		return y
	}
	return x
}

と角括弧 [...] で囲まれている。どうしても山括弧 <...> はイヤみたい（笑）

type キーワードは無用となった。

組込み済みの制約

組込み済みの interface 型として error が定義されているように，組込み済みの制約（constraint）として any と comparable が追加されるようだ。

any はあらゆる型を包摂する。むしろ「制約がない」ことを示す制約というべきか。強いて書くなら

type any interface{}

といったところだろうか。たとえば

// Print prints the elements of any slice.
// Print has a type parameter T and has a single (non-type)
// parameter s which is a slice of that type parameter.
func Print[T any](s []T) {
    for _, v := range s {
		fmt.Println(v)
	}
}

via Type Parameters - Draft Design

みたいな感じに使える。どうやら型パラメータの指定で制約を省略することはできないようなので，制約がない場合は any を付けることになりそうだ。

comparable は演算子 == および !== が使える型を示す制約だ。これを使って

package main

import "fmt"

func Contains[T comparable](col []T, item T) bool {
	for _, e := range col {
		if e == item {
			return true
		}
	}
	return false
}

func main() {
	fmt.Println(Contains([]string{"coffee", "tea"}, "coffee")) //true
	fmt.Println(Contains([]int{1, 2, 3}, 11))                  //false
	fmt.Println(Contains([]int{1, 2, 3}, 1))                   //true
}

via Go Generics draft design Final

のように書ける。

any も comparable も制約としてのみ使用可能で，通常の inteface 型としては使えないようだ。

なお， Go の総称型について詳しくは以下の「本」がオススメである。色々な事例が載っているのでかなり参考になる。

Go 言語にやってくる Generics は我々に何をもたらすのか | Zenn

この本を買うために Zenn のアカウントを取ってもいいかも（クレカが通ればだけど）。

Go は Nearly Java になるか

上述の「本」に

その慎重な Go が今、Generics を取り入れ、Better C から Nearly Java へと変わろうとしています。Java がそうであった様に、Go は Generics の導入により多くのアルゴリズムが汎用的に実装され便利になっていくでしょう

Go 言語にやってくる Generics は我々に何をもたらすのかより

とある。標準の sort パッケージのように型ごとに似たようなコードをゴリゴリ書くのではなく，汎化されたアルゴリズムに集約されていく期待感はあるが，それが Nearly Java になるかについては懐疑的である。

Go 言語の特徴のひとつは「汎化」の実装として Java や Rust のような公称型の部分型付け（nominal subtyping）ではなく構造型の部分型付け（structural subtyping）を採用していることにある。当然ながらこれは総称型を使ったアルゴリズムの実装にも大きな影響を与える筈である。

私は Go が総称型を得ることで更に独自に発展することを期待している。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

次期 Go 言語で導入される総称型について予習する（その2）

2020-06-17T07:33:04+00:00

以前書いた記事に関して，仕様が変わったらしい。

そこで，これまでのおさらいと変更点について簡単に紹介する。

「総称型」のおさらい

次期 Go 言語で導入される「総称型（generics）」について，これまで提案されていた仕様は以下の通り。

contract ordered(t T) {
    t < t
}

func Max(type T ordered)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

Max() 関数の (type T ordered) の部分が「型パラメータ（type parameter）」で，これによって型 T が総称型であることを示す。また ordered は「型コントラクト（type contract）」と呼ばれ，総称型に対する制約（constraint）として機能している。

制約の定義

新しい提案では，型コントラクトを捨て，制約の定義を以下のように変更する。

type ordered interface {
	type int, int8, int16, int32, int64,
		uint, uint8, uint16, uint32, uint64, uintptr,
		float32, float64,
		string
}

func Max(type T ordered)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

以前の型コントラクトとの違いは 既存のキーワードがそのまま使える ことである。文法も interface 型の宣言とほぼ同じだが type int, int8, ... といった感じに型の列挙ができる点がこれまでと異なる。

これにより，制約 ordered を満たす型であれば

func main() {
	fmt.Println(Max(Max(1, 2), 3))               //Output: 3
    fmt.Printf("%#U\n", Max(Max('あ', 'い'), 0)) //Output: U+3044 'い'
}

などと記述できる。

なお，これまでの interface 型も制約として使える。たとえば，こんな感じ。

func SayError(type E error)(e E) string {
	return e.Error()
}

func main() {
	fmt.Println(SayError(io.EOF)) //Output: EOF
}

更に interface 型を入れ子にすることで複雑な制約条件を構成することもできる。

注入するか単態化するか

ところで先程の

func SayError(type E error)(e E) string {
	return e.Error()
}

は，わざわざ総称型を使わなくとも今までの書き方で

func SayError(e error) string {
	return e.Error()
}

としても見た目の結果は同じになる。

しかし，今までの書き方が実行時に動的ディスパッチを行う「依存の注入（depencency injection）」であるのに対し，総称型を使った記述はコンパイル時に型ごとに別々の関数として展開される。これを「単態化（monomorphization）」と呼ぶ。

依存の注入と単態化ではリソース管理の戦略がまるで異なる。

たとえば上述の SayError() 関数を総称型で記述するのは，どう考えても効率が悪い。 error に包摂される型は必要に応じていくらでも定義可能であり，それらの型ごとに単態化されるなどぞんぞがさばる。

逆に Max() 関数なんかは，基本型の振る舞いを interface で括るのが難しいこともあり，コストの高い float64 型の math.Max() くらいしか標準では実装されてなかったりする。こういったものを総称型で記述できるようになれば（OAOO 原則の観点から考えても）コード管理しやすくなるだろう。

「Go プログラマは息をするように依存を注入する」。他のプログラミング言語が総称型で書いているかなりの部分を依存の注入で簡単に纏めてしまえるのが Go 言語の強みであるが，使える道具は多いに越したことはない。

Go 2 Playground

次期 Go 言語用に新しい Playground が公開されている。

https://go2goplay.golang.org/

総称型についてもここで色々と試せるようなので，遊びに行ってみてはいかがだろうか。

早ければ Go 1.17 でお披露目？

だいぶ仕様が固まってきた総称型であるが，早ければ2021年8月にリリース予定の Go 1.17 でお披露目されるかもしれないとのこと。

たのしみ！

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

次期 Go 言語で導入される（かもしれない）総称型について予習する

2018-11-10T21:10:48+00:00

2018年8月に次期 Go 言語で追加される（かもしれない）仕様についてアナウンスがあった。

Go 2 Drafts Announcement - YouTubeより

“Go 2” といってもメジャー・バージョンが変わるのではなく現行バージョンに対する追加仕様らしい。したがって後方互換性は確保されているようだ。

紹介されているドラフト案は大きく2つある。

総称型（generics）
- Generics — Problem Overview
- Contracts — Draft Design
エラー・ハンドリングに関するもの

このうち今回は総称型について予習してみる。

なお “Go 2” の提案はまだドラフト段階なので大幅に変更になったり場合によっては立ち消えになる可能性もある。なので，この記事では深いところまで踏み込まずフワっとした説明になるけど，あしからずご了承の程を。

総称型のメリット

ソフトウェア・エンジニアには自明だと思うが，まずは復習から。

具体例として2つの値のうち大きい方を返す関数を考えてみる。

package main

import "fmt"

func max(x, y int) int {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1
    y := 2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1, 2) = 2
}

この関数 max() は int 型で記述しているが byte 型や float32/float64 型でも関数の中身は全く同じコードになる。

package main

import "fmt"

func max(x, y float64) float64 {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1.1
    y := 1.2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1.1, 1.2) = 1.2
}

ならば，最初から汎化した型で単一のコード記述すれば型ごとに複数のコードを量産しなくてもいんじゃね？という発想になる¹。これが総称型の原点である。

たとえば Java で総称型を使うと以下のような記述になる²。

public static <T> T max(T x, T y) {
    ...
}

<T> の部分が総称型の定義にあたる。ちなみに総称型の名前（この場合は T）はスコープ内で被らなければ任意に指定できる。

現行版 Go 言語において総称型の不在で割りを食っている典型例のひとつが sort パッケージで，基本型の slice のソートだけで以下の型が用意されている³。

sort.Float64Slice
sort.IntSlice
sort.StringSlice

後方互換性を確保するため，これらの型がなくなることはないだろうけど，総称型が実現すれば内部実装の refactoring が進むかも知れない。

このように総称型はコンテナ（container; オブジェクトの集合を表現するデータ構造）操作で特に威力を発揮する。また，現行版 Go 言語では総称型を用いずとも interface 型と reflect パッケージを使ってかなりの部分を代替できるが，コード量のコスト高を別にしても，記述の正しさは実行時での評価ではなくコンパイル時に評価して欲しいところである。

そういうわけで，今までずうっと後回しにされてきたが，総称型を導入できるのであれば是非とも期待したいものである。

型パラメータ（Type Parameter）と型引数（Type Argument）

次期 Go 言語で総称型を導入するために型パラメータおよび型引数の構文を追加するようだ。

例えば先程の max() 関数であれば以下のように記述できる。

package main

import "fmt"

func max(type T)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

func main() {
    x := 1
    y := 2
    fmt.Printf("max(%v, %v) = %v\n", x, y, max(x, y))
    //Output
    //max(1, 2) = 2
}

(type T) の部分が型パラメータで，これによって総称型を定義している。既存の語彙だけで構成しているのがポイント（< や > は演算子だし [...] は配列/slice や map の構文で使われるので避けたのだろう）。

関数を呼び出す側は型推論によって引数の型が一意に決定するので特別な記述は必要ない。相変わらず refatoring に優しい言語だよな（笑）

明示的に型を指定するなら

max(int)(x, y)

などと記述する。 (int) の部分が型引数にあたる。

型宣言とインスタンス生成でも同様に

type List(type T) []T

var listInt = List(int){0, 1, 2, 3, 4 ,5}

などと記述できる。

型コントラクト（Type Contract）

先程の max() 関数だが

func max(type T)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

型 T のインスタンス同士で比較演算（具体的には x < y）が可能である必要がある。たとえば complex64/complex128 は基本型だが < 演算子による比較ができない。

Java の場合は継承を構成して

public static <T extends Comparable<? super T>> T max(T x, T y) {
    ...
}

などと記述することで総称型に対する制約（type constraint）を表現できる⁴。

しかし Go 言語ではいわゆる「継承」の仕組みを持ってないため別のアプローチをとる必要がある。それが型コントラクトである。型コントラクトでは contract キーワードおよびそれを使った構文を追加する。具体的には以下のようなコードになる。

contract comparable(t T) {
    t < t
}

func max(type T comparable)(x, y T) T {
    if x < y {
        return y
    }
    return x
}

なお comparable の型引数を明示する場合は

func max(type T comparable(T))(x, y T) T { ... }

と書く。

型コントラクトの記述はバイナリ・コードにコンパイルされない。上の例では型 T に対して比較演算子 < が使えることを要求しているとコンパイラに知らせるものである。これなら T を complex128 に展開しようとしてもコンパイル時に「契約違反」になるわけだ。

型コントラクトは型コントラクトに埋め込むことができる。例えばこんな感じ。

contract equalable(t T) {
    t == t
}
contract comparable(t T) {
    equalable(T)
    t < t
}

これで comparable は == 演算子と < 演算子が使えることを要求していることになる。

継承を利用した制約と異なり，型コントラクトの自由度は高く応用範囲も広い。たとえばポインタ型を要求するなら

contract pointer(t T) {
    *t
}

などと書くこともできるらしい。他にも io.Reader と汎化・特化の関係があることを要求するなら

contract readable(r T) {
    io.Reader(r)
}

などと書けばいいようだ。

もし今回のドラフト案の通りに総称型が実現するなら型コントラクトの整備が喫緊の作業となるだろう。

ブックマーク

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

このように同じコードを重複させないように記述するコーディング指針を「OAOO (Once And Only Once) 原則」と呼ぶ。そういえばよくある勘違いで「DRY (Don’t Repeat Yourself) 原則」と解説している記事が見受けられるが， DRY 原則は同じ意味を持つ情報やデータを複数に散らばせないというシステム設計や開発環境の指針を指すものである。 ↩︎
久しぶりに Java コード書いたら型を前置することに違和感がハンパない。型の前置なんて非合理的だよなあ（もちろん偏見w） ↩︎
Slice のソートについてはバージョン 1.8 から任意の型に対応する sort.Slice() 関数が用意された。内部で reflect パッケージを使っているが，かなり巧妙に組まれているため，パフォーマンス低下は殆どないらしい。ただし slice 以外のインスタンスを指定すると（コンパイル時ではなく）実行時に panic を吐く。詳しくは「ソートを使う」を参照のこと。 ↩︎
C++ や C# でも where 句を用いて総称型に対する制約を表現できるが，基本は継承を利用したものである。 ↩︎

きみは Generics がとくいなフレンズなんだね，または「制約は構造を生む」

2017-03-11T05:55:06+00:00

公理によって与えられる暗黙の制約。この制約が集合の要素同士をしっかり結びつける。単純にしばるのではない、相互に秩序ある関係を結ぶ。言い換えれば――公理によって与えられる制約が構造を生み出しているのだ

数学ガール／フェルマーの最終定理より

今回は戯れ言モードなので「プログラミング言語 Go」ではなくこちらで書いてみる。コードは1行も書かないのでご安心を（笑）

私は出自が組込みエンジニアで（今は何でも屋），アセンブラや C/C++ から始まり Java などの制御に向いていると言われる言語を遍歴している（PHP を機器制御に使うとかいうこともやったが）。 Go 言語もその流れから興味を持っているが，あいにく私が住んでいる地方都市で Go 言語の出番はまだない。

そういう経歴を持つ私から見て Go 言語が特異だと思ったのは以下の2点である。

例外処理がない
明示的なクラス定義構文がない

私だけでなく C++ や Java などから来た人は大抵これで面食らうらしい。

このうち1番目については「プログラミング言語 Go」で記事にしたので割愛する。

さて，2番目の「明示的なクラス定義構文がない」について。

そもそも「クラス」とはなにか。クラスとは以下の要素をひとまとめの「モノ（object）」として定義したものである。

名前（必ず1個）
属性（0個以上）
操作（0個以上）

Go 言語では明示的なクラス定義構文がない代わりに type と struct，およびメソッド・レシーバを組み合わせることでクラスの要素である名前，属性，操作を定義できる。

そしてクラス定義で重要なのは「クラス間の関係」を定義することである。クラス間の関係としては大雑把に以下の2つがある。

汎化・特化（継承等）
関連（集約，依存等）

このうち2番目の関連は定義しやすい。あるクラスの属性として別のクラスを定義するか，操作によって関連付けるかすればいいからだ。問題は1番目の汎化・特化をどうやって定義するかである。

Go 言語の場合は interface を使った「構造的部分型（structural subtyping）¹」を採用した。構造的部分型とはクラスの振る舞いに注目してクラス間の汎化・特化関係を帰納法的に定義することである。例を挙げると，それが「にゃーん」と鳴くのなら机器猫だろうが猫耳メイドだろうがサーバルキャットだろうが全部「猫」である，ということだ。

クラス間の関係を定義するのは意外に大変である。皆さんは「クラス設計」をどのように行っているだろうか。まずは具体的なクラスを列挙していき，それらの関係を考察していくのではないだろうか（「ユーザ」や「管理者」を定義するのに動物→人間→… と考えていく人はいないだろう）。考察する過程で（クラスとクラスを繋ぐ）不可視のクラスを発見したり複数のクラスがひとつの概念で括れることに気づいたりすることもある。つまり設計する過程では「具象→抽象」へと遡っていく。

一方，実装する際には， C++ や Java では最初にテンプレート・クラスやインタフェース・クラスを作ってからインプリメント・クラスに落とし込む。

たとえば，最初に「猫」という抽象クラスを作っておいて，それを継承する形で机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを実装していく。つまり「抽象→具象」へと作業していくわけだ。そしてその過程において Generics² は，ほとんど必須と言えるほど利用価値の高い機能と言える。

これが Go 言語による実装ではひっくり返る。たとえば，最初に机器猫や猫耳メイドやサーバルキャットといった具体的なクラスを作っていって「これってみんな『にゃーん』って鳴くじゃん」と気がつけば後付けで「猫」という抽象クラスを実装できるのである。

どういうことかというと， Go 言語においては設計と実装を同時進行で「具象→抽象」へと考察していくことができる，ということである。このような思考過程においては Generics の有無はさして重要ではなくなる。だって具象化されたオブジェクトから作り始めるのだから。

「抽象→具象」へと実装する人にとっては Generics のない Go 言語はとてもまだるこしく見えるかもしれない。「なんで Generics がねーんだよ。いちいち全部書かせる気か。このポンコツ言語が！」となること請け合いである。しかし一度構造的部分型に慣れた人にとっては抽象クラスから書かなければならない C++ や Java こそが面倒くさい。何故なら，脳内では「具象→抽象」で思考していくのに実際に書くときには「考え終わらないと書けない³」からである。 Go 言語なら「考えながら書ける」のに。

これはどちらが正しいかという問題ではない。

たとえばウォータフォール型⁴ の開発スタイルでは実装を開始するまでに設計が終わることが（建前上は）保証されているため「抽象→具象」へと書き進めることが容易な言語が向いている。一方，要件が絶えず変わったり実験的な製品の場合は設計が終わるまで待っていられないため Go 言語のような言語が向いてるかもしれない。まぁ設計と実装を同時にやろうとするとリファクタリングが頻繁に発生するのでコピペ・プログラマにはキツい作業になるかもしれないが。

個人的には「プログラマは要件定義の段階から参加してコードを書くべき」と思ってるので，これを容易にするであろう Go 言語には注目している。

2018-10-11 追記

“Go 2 Draft Designs” において将来バージョンにおける Generics 対応の言及がある。

Go 2 Drafts Announcement - YouTubeより

ブックマーク

Why Everyone Hates Go · npf.io
- [翻訳]なんでGoってみんなに嫌われてるの？ - Qiita
Why Go? | Dave Cheney
- [翻訳] Why Go? - Qiita
Go 言語における「オブジェクト」
JavaScriptで継承を使わないプログラミングスタイル - JavaScript勉強会 : オブジェクト指向設計について上手くまとめている
Go にジェネリクスがなくても構わない人たちに対する批判について - methaneのブログ

参考図書

プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES): Alan A.A. Donovan (著), Brian W. Kernighan (著), 柴田芳樹 (翻訳); 丸善出版 2016-06-20; 単行本（ソフトカバー）; 4621300253 (ASIN), 9784621300251 (EAN), 4621300253 (ISBN); 評価

reviewed by Spiegel on 2016-07-13 (powered by PA-APIv5)

数学ガール／フェルマーの最終定理: 結城浩 (著); SBクリエイティブ 2008-07-29 (Release 2014-03-12); Kindle版; B00I8AT1CM (ASIN); 評価

[Comment] 「フェルマーの最終定理」というサブタイトルをみたとき「なんちう大風呂敷を広げるねん」と思ったものだが，実際に読んでみるとぐいぐい引き込まれる。ひっさびさに頭を使ったような気がする。

reviewed by Spiegel on 2019-01-13 (powered by PA-APIv5)

URL を見るとわかる通り最初は duck typing と表記していたが正しくは「構造的部分型」と言うらしい。 duck typing は主に動的型付け言語における型推論方式（のひとつ）で，クラス間の関係を記述するものではないようだ。ちなみに構造的部分型に対する言葉として「公称型（nominal subtyping）」というのがあって， C++ や Java におけるテンプレート・クラスやインタフェース・クラスを使った汎化・特化関係を指す場合に使うそうだ。 ↩︎
知らない人のために Generics について簡単に説明しておくと，変数の型あるいはインスタンス（instance）に対するクラス（class）に関係なく単一の記述で変数ないしインスタンスを扱うことのできる仕組みである。汎化の一種と考えてもよい。いわゆる多態性（polymorphism）とは異なり，継承関係の異なるクラスでも一緒くたに扱うことが可能なかなり強力な仕組みである。 Generics は特にコンテナ（container; オブジェクトの集まりを表現するデータ構造，配列など）操作で威力を発揮する。 ↩︎
私はこれを「写経」と呼んでいる。はっきり言ってプログラミングでもっとも苦痛なのがコーディング＝写経だったりする。ちなみに一番好きなのはデバッグ。特に他人の書いたコードをデバッグするのは大好物。あれは極上の数理パズルである（締切さえなければね）。 ↩︎
「ウォータフォール型」とは滝の水が上から下へと落ちていくように要件定義→設計→製造と上流工程から下流工程へ順番にプロセスを進めていく開発スタイル。工程ごとにマイルストーンを設けてチェックを行い，各工程が完了しないと先に進めないようにする。まぁ実際にはスケジュールやらの関係でチェックを端折って先に進めてしまうことが多く，下流工程に入ってから致命的な欠陥に気づいて抜き差しならない状況に陥ることもしばしばある（笑） ↩︎