Go エコシステム 2026 完全ガイド - Go 1.24/1.25、Echo · Gin · Fiber · Chi · sqlc · pgx · ent · Cobra · Bubble Tea · Buf · Connect-RPC · PGO 徹底解説

はじめに — 2026年5月、Go は韓国・日本のバックエンド標準になった

2020 年までの韓国・日本のバックエンドは、Spring Boot(Java/Kotlin)と Node.js、そして一部の Python(FastAPI/Django)が分け合う市場だった。2026 年 5 月現在、その地形は明らかに変わった。Toss は決済・認証のコアサービスのほとんどを Go に移行し、Naver はゲートウェイ・検索インフラのホットパスを Go に移した。日本ではメルカリが 100 以上のマイクロサービスを Go で運用し、ZOZO とサイバーエージェント CAGroup は新規サービスのデフォルト言語として Go を選んでいる。

Go がこの位置に来た理由は単純だ。マイクロサービスのバイナリ 1 本が数十 MB で済み、コールドスタートが実質ゼロ、p99 レイテンシが安定し、標準ライブラリだけで 90 % の仕事が片付く。さらに 2026 年では、Go 1.24・1.25 の新機能が生産性をもう一段押し上げた。この記事は単なる「Go 入門」ではなく、今、韓国・日本のプロダクションで何がどの位置に置かれているかを正直にまとめる。

Go 1.24 と 1.25 — 2026 年の標準になった新機能

Go 1.24(2025 年 2 月)と 1.25(2025 年 8 月)は言語自体の大きな転換点だ。主要な変更をまとめる。

• iter.Seq[T] と iter.Seq2[K, V]: 標準のイテレータ型。for-range が関数を受け取れる。
• range-over-func: for x := range myFunc { ... } 形式でユーザー定義のイテレーションが可能。
• Swiss テーブルマップ: ランタイムのマップ実装を Abseil の Swiss テーブルに置き換え。平均でメモリ -20 %、ルックアップ +30 %。
• GOEXPERIMENT=newinliner: 新しいインライナーが 1.25 でデフォルト有効に。関数呼び出しオーバーヘッドが平均 5–8 % 減少。
• PGO の一般化: Profile-Guided Optimization がビルドパイプラインの第一級市民に。go build -pgo=auto。
• Weak pointers: weak.Pointer[T] でキャッシュやメモ化を GC フレンドリーに作れる。
• encoding/json/v2(実験): 1.25 で GOEXPERIMENT フラグ越しに登場。v1 比 30–50 % 高速で、オプションモデルがすっきりしている。
• log/slog の標準化: 1.21 で導入された構造化ロギングパッケージが、事実上すべてのライブラリのデフォルトに。

体感の大きな変化は range-over-func だ。次のように、ライブラリ側がイテレータを返せる。

package paginate

import "iter"

func All[T any](pages [][]T) iter.Seq[T] {
	return func(yield func(T) bool) {
		for _, page := range pages {
			for _, item := range page {
				if !yield(item) {
					return
				}
			}
		}
	}
}

// 呼び出し側
// for item := range paginate.All(pages) { ... }

これまでチャネルやコールバックでさばいていた流れが、標準化されたイテレータで素直に表現できる。

ジェネリクスの成熟 — 2026 年の実用パターン

Go 1.18 で導入されたジェネリクスは、2026 年になってようやくライブラリ生態系に定着した。代表例が samber/lo(関数型ヘルパー)と samber/do(DI コンテナ)だ。標準ライブラリでも slices、maps、cmp パッケージのジェネリックヘルパーが浸透した。

package main

import (
	"cmp"
	"fmt"
	"slices"

	"github.com/samber/lo"
)

type User struct {
	ID    int
	Name  string
	Score int
}

func main() {
	users := []User{
		{1, "Alice", 80},
		{2, "Bob", 95},
		{3, "Carol", 70},
	}

	// slices.SortFunc はジェネリックな比較関数を受け取る
	slices.SortFunc(users, func(a, b User) int {
		return cmp.Compare(b.Score, a.Score)
	})

	// lo.Map はジェネリック変換
	names := lo.Map(users, func(u User, _ int) string { return u.Name })
	fmt.Println(names)
}

ここで大事なのは「ジェネリクスは何でも解決する」のではなく、型安全さが効くところ(コレクション変換、DI、オプションパターン、Result 型)だけに使う、という点だ。むやみなジェネリクスはコンパイル時間を増やし、可読性を損なう。

Web フレームワーク五強 — Echo・Gin・Fiber・Chi・Kratos

2026 年 5 月時点で、Go の Web フレームワーク市場は 5 つの道具に分かれている。

• Gin: 最古参の事実上の標準。自由度が高くミドルウェアエコシステムが大きい。
• Echo: Gin とほぼ同等。API がやや整っていて組み込みミドルウェアが強い。
• Fiber: fasthttp ベース。Express(JS)スタイルの API。単純ルーティングのベンチで優位。
• Chi: 標準 net/http 互換。ミニマルでライブラリ的。Toss がコアサービスで採用。
• Kratos: Bilibili が作ったフルスタックマイクロサービスフレームワーク。gRPC + Wire DI 内蔵。

Echo の典型的なハンドラは次の通り。

package main

import (
	"log/slog"
	"net/http"
	"os"

	"github.com/labstack/echo/v4"
	"github.com/labstack/echo/v4/middleware"
)

type CreateUserReq struct {
	Email string `json:"email" validate:"required,email"`
	Name  string `json:"name" validate:"required,min=2"`
}

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
	e := echo.New()
	e.Use(middleware.Recover())
	e.Use(middleware.RequestID())
	e.Use(middleware.Logger())

	e.POST("/users", func(c echo.Context) error {
		var req CreateUserReq
		if err := c.Bind(&req); err != nil {
			return c.JSON(http.StatusBadRequest, map[string]string{"error": err.Error()})
		}
		logger.Info("user.created", "email", req.Email)
		return c.JSON(http.StatusCreated, map[string]any{"email": req.Email})
	})

	e.Logger.Fatal(e.Start(":8080"))
}

Gin との違いはほぼスタイルレベルだ。どちらも httprouter 系のルーター、ミドルウェアチェーン、似た JSON バインディングを持つ。新規プロジェクトではどちらを選んでも大差なく、チームが慣れている方を使うのが正解だ。

Chi と標準 net/http — "フレームワークなし" の潮流

2024 年に Go 1.22 で http.ServeMux が強化(メソッドパターン、ワイルドカード)されて以降、「フレームワークなしで標準ライブラリだけ使う」流れが再び強まった。Chi はその代表格。標準 net/http インタフェースをそのまま守りつつ、ルーティング、ミドルウェア、サブルーター、URL パラメータを提供する。

package main

import (
	"encoding/json"
	"net/http"

	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"
)

func main() {
	r := chi.NewRouter()
	r.Use(middleware.RequestID)
	r.Use(middleware.RealIP)
	r.Use(middleware.Recoverer)

	r.Route("/v1", func(r chi.Router) {
		r.Get("/users/{id}", func(w http.ResponseWriter, r *http.Request) {
			id := chi.URLParam(r, "id")
			_ = json.NewEncoder(w).Encode(map[string]string{"id": id})
		})
	})

	http.ListenAndServe(":8080", r)
}

Toss はコア決済バックエンドで Echo と Chi を混ぜて使っていると伝えられている。新規サービスには Chi、既存サービスには Echo をそのまま残す。

Fiber — 速度優先、標準互換は半分

Fiber は fasthttp の上に乗っているため、単純なルーティング・JSON 応答のベンチで Echo/Gin より 20–40 % 速い。ただし標準 net/http とインタフェースが異なるため、標準のミドルウェアエコシステムと直接互換ではない。トレードオフは明確だ。

sqlc — コンパイル時に型安全な SQL

ORM ではなく「SQL をそのまま書いて、コード生成で型安全な関数を受け取る」アプローチが、2026 年のデフォルトになった。代表が sqlc だ。.sql ファイルにクエリを書き、sqlc CLI が Go 関数と構造体を生成する。

-- queries.sql
-- name: GetUser :one
SELECT id, email, name, created_at FROM users WHERE id = $1;

-- name: ListUsers :many
SELECT id, email, name FROM users ORDER BY created_at DESC LIMIT $1 OFFSET $2;

-- name: CreateUser :one
INSERT INTO users (email, name) VALUES ($1, $2) RETURNING id, email, name, created_at;

これを sqlc generate に通すと、次のような Go コードが生成される(要約)。

type User struct {
	ID        int64
	Email     string
	Name      string
	CreatedAt time.Time
}

func (q *Queries) GetUser(ctx context.Context, id int64) (User, error)
func (q *Queries) ListUsers(ctx context.Context, limit, offset int32) ([]User, error)
func (q *Queries) CreateUser(ctx context.Context, email, name string) (User, error)

型安全・SQL そのまま・ランタイムリフレクションゼロ。韓国・日本の新規プロジェクトの 80 % が sqlc を採用している。

pgx — PostgreSQL 専用ドライバの定番

PostgreSQL を使うなら、database/sql の汎用ドライバではなく jackc/pgx を使うのがデフォルトになった。理由は PostgreSQL のワイヤープロトコルを直接扱うため、性能と機能(LISTEN/NOTIFY、COPY、配列型、タイムゾーン処理)が両方とも優れているからだ。

package main

import (
	"context"
	"log/slog"
	"os"

	"github.com/jackc/pgx/v5/pgxpool"
)

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
	cfg, err := pgxpool.ParseConfig(os.Getenv("DATABASE_URL"))
	if err != nil {
		logger.Error("config.parse", "err", err)
		os.Exit(1)
	}
	cfg.MaxConns = 20
	pool, err := pgxpool.NewWithConfig(context.Background(), cfg)
	if err != nil {
		logger.Error("pool.create", "err", err)
		os.Exit(1)
	}
	defer pool.Close()

	var version string
	if err := pool.QueryRow(context.Background(), "SELECT version()").Scan(&version); err != nil {
		logger.Error("query", "err", err)
		os.Exit(1)
	}
	logger.Info("connected", "version", version)
}

sqlc は pgx をデフォルトバックエンドとしてサポートしているので、「sqlc + pgx」が 2026 年の PostgreSQL 標準だ。

ent — Meta が作ったグラフフレンドリーな ORM

Facebook(Meta)が作った ent は、「スキーマを Go コードで定義してグラフモデルで扱う」ORM だ。スキーマファイルからマイグレーションとクライアント API を一緒に生成する。

// schema/user.go
package schema

import (
	"entgo.io/ent"
	"entgo.io/ent/schema/edge"
	"entgo.io/ent/schema/field"
)

type User struct{ ent.Schema }

func (User) Fields() []ent.Field {
	return []ent.Field{
		field.String("email").Unique(),
		field.String("name"),
	}
}

func (User) Edges() []ent.Edge {
	return []ent.Edge{
		edge.To("posts", Post.Type),
	}
}

エンティティ間の関係(edge)を一級市民として扱う点が GORM・bun との違いだ。メルカリも一部サービスで ent を標準採用している。

ORM 比較 — sqlc・ent・gorm・bun・sqlboiler

各ツールの位置づけを表にまとめる。

新規プロジェクトには sqlc または ent、Rails/Django から移行するチームには gorm が向く。

gRPC、Connect-RPC、Twirp — RPC プロトコル三国志

マイクロサービス間通信は gRPC が事実上の標準だが、2024 年以降は Buf が作った Connect-RPC が急速にシェアを伸ばしている。3 つの違いを整理する。

Connect-RPC の決定的な利点は、同じ proto で gRPC サーバと HTTP/1.1 JSON API を同時に公開できる点だ。ブラウザからそのまま呼べ、サーバコードは 1 回だけ書く。

Buf CLI — Protobuf ワークフローの標準

Buf は protoc よりはるかに整備された Protobuf ツールチェーンだ。buf.gen.yaml でコード生成、buf lint でスタイル検査、buf breaking で互換性検査を行う。

version: v2
managed:
  enabled: true
plugins:
  - remote: buf.build/protocolbuffers/go
    out: gen
    opt: paths=source_relative
  - remote: buf.build/connectrpc/go
    out: gen
    opt: paths=source_relative

このファイル 1 つで、protoc オプション地獄から抜けられる。CI では buf lint と buf breaking --against '.git#branch=main' を回し、API 変更の後方互換性を自動検証する。

log/slog の標準化 — 構造化ログの終着点

2021 年までの Go ロギングは、log・logrus・zerolog・zap がシェアを争う戦場だった。2023 年に標準ライブラリ入りした log/slog が、2026 年には事実上すべてのライブラリのデフォルトになった。

package main

import (
	"context"
	"log/slog"
	"os"
)

func main() {
	logger := slog.New(slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
		Level: slog.LevelInfo,
	}))
	slog.SetDefault(logger)

	ctx := context.Background()
	slog.InfoContext(ctx, "service.start",
		"version", "1.2.3",
		"port", 8080,
	)
}

ハンドラインタフェースが標準化されたため、slog-go-zap・slog-zerolog・slog-otel といったアダプタを経由して既存ロギングバックエンドをそのまま使える。zap を使っていたチームも、段階的に slog インタフェースへコードを寄せている。

OpenTelemetry Go — 分散トレーシングのデフォルト

分散トレーシングは OpenTelemetry Go SDK が事実上の標準だ。HTTP/gRPC ミドルウェア、DB クライアントの計装、slog ハンドラ連携までフルスタックで揃っている。Toss・メルカリともに OTLP コレクタへ送って Tempo または Honeycomb に格納する構成が一般的だ。

中心となるパターンは(1)context.Context でトレーススパンを伝播、(2)otel.Tracer("name").Start(ctx, "op") でスパン生成、(3)otelhttp.NewHandler で HTTP の自動計装、(4)slog 出力に trace_id/span_id を自動付与、の 4 つだ。

context 伝播とエラーラップ — Go らしいコードの核

Go 1.20 で errors.Join が追加され、エラー処理モデルがようやく完成した。2026 年のイディオムは次の 4 つに集約される。

1. すべての外部呼び出しは ctx context.Context を最初の引数に受ける。
2. エラーは fmt.Errorf("...: %w", err) でラップする。
3. 分岐判定は errors.Is、型判定は errors.As を使う。
4. 複数エラーを一括でまとめるには errors.Join を使う。

これらに反するコードは errcheck・revive・errorlint などの linter で即座に検出される。

Cobra と fang — CLI の事実上の標準

Go の CLI ツールの 80 % は spf13/cobra で作られている。kubectl、helm、hugo、docker CLI が軒並み cobra ベースだ。2025 年登場の charmbracelet/fang は、cobra の上に「綺麗なヘルプと色」を載せるレイヤーだ。

package main

import (
	"fmt"

	"github.com/spf13/cobra"
)

func main() {
	var name string
	root := &cobra.Command{
		Use:   "hello",
		Short: "Say hello",
		Run: func(cmd *cobra.Command, args []string) {
			fmt.Printf("Hello, %s!\n", name)
		},
	}
	root.Flags().StringVarP(&name, "name", "n", "world", "name to greet")
	root.Execute()
}

代替には urfave/cli(軽量)、alecthomas/kong(構造体タグベース)がある。本当に軽く始めたい新規プロジェクトには kong が魅力的だ。

Charm エコシステム — Bubble Tea・Lipgloss・Glow・Soft Serve

charmbracelet が作った TUI ツール群は、2026 年のターミナル UX の標準になった。Bubble Tea は Elm アーキテクチャ(Model–Update–View)を Go で実装した TUI フレームワークだ。

package main

import (
	"fmt"
	"os"

	tea "github.com/charmbracelet/bubbletea"
)

type model struct{ count int }

func (m model) Init() tea.Cmd { return nil }

func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
	switch msg := msg.(type) {
	case tea.KeyMsg:
		switch msg.String() {
		case "q", "ctrl+c":
			return m, tea.Quit
		case "+":
			m.count++
		case "-":
			m.count--
		}
	}
	return m, nil
}

func (m model) View() string { return fmt.Sprintf("count: %d (+/- to change, q to quit)\n", m.count) }

func main() {
	if _, err := tea.NewProgram(model{}).Run(); err != nil {
		fmt.Println(err)
		os.Exit(1)
	}
}

同じファミリの Lipgloss は色やボックスのスタイリング、Glow は Markdown レンダリング、Soft Serve はセルフホスト Git サーバ。社内ツールを作るときの第一候補だ。

DI コンテナ — wire・fx・do・do-rc

大規模な Go アプリケーションでは DI コンテナがほぼ必須になる。4 つの位置づけを整理する。

Kratos・Buffalo は wire をデフォルトで推奨し、Toss は fx を標準化、メルカリもマイクロサービスの骨格に fx を採用している。

DB マイグレーション — atlas・golang-migrate・goose・dbmate

スキーママイグレーションは 4 つから選べばよい。

• golang-migrate: 最古参の標準。ファイルベース(up.sql、down.sql)。
• goose: Go コードによるマイグレーションもサポート。軽量。
• dbmate: 言語中立。CLI 単体で動く。
• atlas: HCL/SQL の宣言的モデル。スキーマを宣言的に定義するとマイグレーション差分を自動計算。ent と親和性が高い。

新規プロジェクトには atlas、既存資産があるチームには golang-migrate を維持するパターンが多い。

HTTP クライアント — resty・req・go-retryablehttp

標準 net/http だけでもクライアントは十分動くが、リトライ・タイムアウト・認証・トレーシングが絡む外部 API 呼び出しには、ヘルパーライブラリが便利だ。

• go-resty/resty: 最も人気のフル機能クライアント。チェーン API。
• imroc/req: resty に近い。デバッグログが充実。
• hashicorp/go-retryablehttp: 標準 HTTP クライアントへの自動リトライデコレータ。

低レイヤな制御が必要なら標準 net/http + go-retryablehttp の組み合わせ、素早く作りたいなら resty が正解だ。

テスト — testify・gomega・gomock・mockery

Go のテストは標準 testing パッケージがデフォルトだが、アサーションとモッキングはほぼライブラリ任せになる。

• stretchr/testify: assert、require、mock のセット。事実上の標準。
• onsi/gomega: BDD スタイル。Ginkgo と組み合わせて使う。
• go.uber.org/mock(旧 golang/mock): インタフェース起点のモック生成。mockery で自動生成。
• vektra/mockery: モックコードの自動生成器。CI に組み込む。

ゴールデンファイルテスト(golden file test)は gotestyourself/gotest.tools か、自作の小さなヘルパーで実装するのが定番。出力変更の追跡に効く。

ベンチマークと PGO — go test -bench と benchstat

性能計測は go test -bench、結果比較は benchstat が標準だ。

# 1 回目の計測
go test -bench=. -count=10 -benchmem ./pkg/parser > old.txt
# コード変更後の 2 回目の計測
go test -bench=. -count=10 -benchmem ./pkg/parser > new.txt
# 統計的に比較
benchstat old.txt new.txt

benchstat は平均だけでなく t 検定による有意差まで報告するため、「自分の変更が本当に速くなったのか」を客観的に判断できる。

PGO(Profile-Guided Optimization) — 平均 5–15 % の無料改善

Go 1.21 で GA した PGO は、2026 年には主要サービスの標準ビルド工程になった。プロダクションのトラフィックから pprof CPU プロファイルを取り、それをビルドに食わせると、コンパイラがホットパスを積極的にインライン化・整列する。

# プロダクションで 30 秒分のプロファイルを収集
curl -o cpu.pprof "http://prod.internal:6060/debug/pprof/profile?seconds=30"
mv cpu.pprof default.pgo

# 同じディレクトリに default.pgo があれば自動で PGO 適用
go build -pgo=auto ./...

Toss が公開した内部ベンチでは、決済ルータで平均 8–12 % のスループット改善と、p99 レイテンシ 6 % 減を報告している。メルカリでも一部サービスで 7 % 程度の改善が確認されている。「ただで手に入る性能」というわけだ。

ゴルーチンパターン — プール・sync.Pool・sync.OnceFunc

大量の並行処理を扱う標準パターンは次の 3 つだ。

1. ワーカープール: panjf2000/ants ライブラリ、または自作のチャネルベース実装。
2. sync.Pool: 短命のオブジェクト(バッファ、パーサ状態)を再利用して GC 圧を下げる。
3. sync.OnceFunc・OnceValue・OnceValues(1.21+): 遅延初期化のイディオム。

IO バウンドな負荷ならゴルーチンを無制限に立てても問題ない。プールは CPU バウンド、または外部リソース(DB コネクション、HTTP クライアント)に上限があるときに限って必要だ。

Wails — Go で作るデスクトップアプリ

Wails は Go バックエンド + WebView フロントエンドでデスクトップアプリを作る。Electron の Go 版と捉えてよいが、バンドルがずっと小さく(平均 10–20 MB)メモリも少ない。v3 が 2025 年に GA。社内ツールや開発者向けデスクトップアプリ(GUI Git クライアント、k8s ダッシュボード、ログビューア)でよく使われる。

Hugo — Go 製、最速の静的サイトジェネレータ

Hugo は Go エコシステムの誇りだ。1 万ページ規模のサイトでも数秒でビルドする。2026 年は LCP/Core Web Vitals 改善の一環として再び注目されている。韓国・日本の技術ブログの相当数が Hugo + GitHub Pages または Vercel 静的ホスティングで運用されている。

韓国の事例 — Toss・Naver・Coupang・カカオ

• Toss: 決済・認証・送金のコアサービスの多くが Go。標準スタックは Echo + Chi + sqlc + pgx + fx + Connect-RPC。Go 1.24 PGO を正式採用。
• Naver: ゲートウェイ・検索インフラの一部が Go。fasthttp ベースのゲートウェイ事例が公開されている。
• Coupang: 一部のマイクロサービス、特に非同期ワーカー系を Go に移行。
• カカオ: カカオエンタープライズが社内ツールの多くを Go で作っている。Cobra + Bubble Tea ベースの CLI が標準。

Toss の SLASH カンファレンスでの発表は、韓国語の Go 導入資料として最も精密な参考書だ。

日本の事例 — メルカリ・ZOZO・サイバーエージェント・サイボウズ

• メルカリ(Mercari): 100 以上のマイクロサービスが Go。gRPC + Connect-RPC、ent、fx ベース。
• ZOZO: 検索・推薦サービスのホットパスが Go。sqlc + pgx を標準化。
• サイバーエージェント CAGroup: 広告・ゲーム新規サービスのデフォルト言語が Go。AbemaTV の一部バックエンドも含む。
• サイボウズ: kintone バックエンドの新サービスを Go で作成。Connect-RPC を積極採用。

メルカリのエンジニアリングブログ(engineering.mercari.com)は、Go マイクロサービス運用の標準参考書として広く読まれている。

導入ロードマップ — 0 からプロダクションまで

新しいチームが Go を導入するときの 6 ステップロードマップを示す。

1. Week 1: Go 1.24 のインストール、gopls/golangci-lint のセットアップ、A Tour of Go と Effective Go を通読。
2. Week 2: 小さな CLI を 1 つ cobra で作る。slog ロギング、urfave か cobra のどちらかを選ぶ。
3. Week 3: Echo か Chi で小さな REST API を作る。sqlc + pgx を導入。
4. Week 4: testify でテストを書き、golangci-lint を CI に組み込む。
5. Month 2: Connect-RPC または gRPC でサービス間通信を始め、Buf を導入。
6. Month 3: OpenTelemetry を導入、PGO をビルドパイプラインに統合、benchstat で回帰監視。

最初から Kratos のようなフルスタックフレームワークに飛び込むのではなく、標準ライブラリ + 軽量ライブラリの組み合わせで始めることを勧める。

アンチパターン — よくある失敗

最後によく見るアンチパターンをまとめる。

1. 深い関数の中で context.Context を受け取らず、その場で context.Background() を作ってしまう → 必ず受け取って伝播させる。
2. 通常のエラー処理に panic を使う → 回復不能な状況だけに限定する。
3. ゴルーチンの寿命を誰が責任を持つか曖昧 → errgroup.Group でまとめる。
4. すべてのエラーを fmt.Errorf("err: %v", err) で作る → %w でラップする。
5. 標準ライブラリで十分なのに重いフレームワークを持ち込む。

この 5 つを避けるだけで、Go コードの品質は一気に上位に入る。

おわりに — 2026 年 5 月、「Go はバックエンドのデフォルト」

2026 年 5 月現在、Go は韓国・日本の新規バックエンドサービスのデフォルト言語だ。Spring/Kotlin は既存資産の維持に、Node.js はフロントエンド/BFF に、Python は ML/データに収まり、Go はその中間の「高スループット・高並行のマイクロサービス」領域をほぼ独占している。

エコシステム自体の安定度もかつてないほど高い。sqlc + pgx + Echo/Chi + slog + Cobra + Buf + Connect-RPC + OpenTelemetry + atlas — この組み合わせ 1 つで、ほぼすべてのバックエンドシナリオをカバーできる。新規サービスの技術選定を先送りする理由はもう残っていない。

References

• Go 公式サイト、go.dev
• Go 公式ブログ、go.dev/blog
• Effective Go、go.dev/doc/effective_go
• Echo フレームワーク、echo.labstack.com
• Gin フレームワーク、gin-gonic.com
• Fiber フレームワーク、gofiber.io
• Chi ルーター、go-chi.io
• Kratos、go-kratos.dev
• sqlc、sqlc.dev
• pgx、github.com/jackc/pgx
• ent、entgo.io
• GORM、gorm.io
• bun、bun.uptrace.dev
• Cobra、github.com/spf13/cobra
• Bubble Tea、github.com/charmbracelet/bubbletea
• Lipgloss、github.com/charmbracelet/lipgloss
• Buf、buf.build
• Connect-RPC、connectrpc.com
• Uber fx、github.com/uber-go/fx
• google/wire、github.com/google/wire
• atlas マイグレーション、atlasgo.io
• testify、github.com/stretchr/testify
• benchstat、pkg.go.dev/golang.org/x/perf/cmd/benchstat
• OpenTelemetry Go、opentelemetry.io/docs/languages/go
• Wails、wails.io
• Hugo、gohugo.io
• メルカリエンジニアリングブログ、engineering.mercari.com
• Toss SLASH カンファレンス、toss.tech/slash