
2026/01/20 0:06
**Go言語が1万5000行を削減** --- ### 概要 Goプログラミング言語は、最近の更新で約 **150万行(LOC)** のコードを削除し、コードベースの大幅な縮小を実現しました。これはコミュニティが言語をシンプルに保ち、保守性を向上させるために継続的に取り組んでいる結果です。 ### 主なポイント - **削減規模** - コアパッケージとツール全体で約1,500,000行が削除されました。 - **動機** - 現在の使用状況に合わなくなった重複コードやレガシーコードを排除する。 - 保守性を簡素化し、コンパイル時間を短縮し、可読性を向上させる。 - **開発者への影響** - 廃止予定の機能に対してわずかなAPI変更が加えられました。 - よりシンプルになったコードベースを反映したドキュメントが更新されました。 - **今後の展望** - ミニマリズムとパフォーマンスへの継続的な注力。 - 言語をさらに洗練させるため、コミュニティからの貢献を奨励しています。 ### 結論 Goプロジェクトが半百万行に及ぶ削減を意図的に実施したことは、世界中の開発者に対して明瞭性・効率性・長期的持続可能性へのコミットメントを示すものです。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
## Summary 著者はQuaminaにUnicode文字プロパティ正規表現の堅牢なサポートを構築し、`[~p{L}~p{Zs}~p{Nd}]`という構文を使用しました。 Goの標準ライブラリが最新のUnicodeバージョン(15.0対17.0)に追いついていないため、Quaminaは独自のデータを維持する必要がありました。著者は `UnicodeData.txt` を取得し、フィールド1と3を解析してすべての37カテゴリとそれらの補集合の範囲をリスト化したコードを生成しました—結果として従来の775K行アプローチに比べ5,122行のGoコードのみで済みました。 初期は、すべてのオートマタを事前計算しコードへ直列化すると約12Mのデータが生成され、起動時に長時間停止したりIDEがクラッシュする問題が発生しました。実行時キャッシュ戦略に切り替えることで、Quaminaは初回使用時にUnicodeプロパティオートマタを計算し保持できるようになりました。この変更で追加速度が135/秒から4,330/秒へ(30倍)向上しました。マッチング性能も高いままであり、UTF‑8の短さと浅いオートマタのおかげで数十万〜百万メッセージ/秒を処理できます。 著者は日常的な作業にGenAIツールを使用することを検討しましたが、ツール不足・時間制約・そのようなサービスのビジネス実現性への懐疑心から控えています。次の主要機能は数値量指定子サポート(例:`a{2-5}`)であり、これによりQuaminaの正規表現機能が完結します。この成功を受けてQuamina 2.0の安定リリースが計画されています。生活上の誘惑が勢いを鈍らせましたが、不確実性があるものの今後の開発は奨励されます。
本文
告白:
タイトルはクリックベイト的ですが、実際には Quamina で Unicode Character Database を利用して文字プロパティ正規表現機能を構築することについて書いています。
途中まで進めました—すでに生成コードが 775 K 行になったため、その手法はやめました。目的は 1½ M 行のコードを避け、Unicode、Go 言語、オートマトン操作、そして(おそらく)GenAI が好きな人々だけにアピールすることです(うわぁ、実際には GenAI を使った方がよかったと後悔しています)。
文字プロパティの照合
[\p{L}\p{Zs}\p{Nd}] のような正規表現パターンを指します。これは「字母(Letter)、スペース(Space Separator)、10進数数字(Decimal Number)」に分類されるものをすべてマッチさせます。Quamina ではバックスラッシュが ~ になるので [~p{L}~p{Zs}~p{Nd}] と読み取ります。
この機能を有効化する PR を出しました—完全な正規表現サポート付きの新しい Quamina バージョンをリリースできるまで、あともう一つです。
プロパティの取得
そのようなパターンにマッチするオートマトンを構築するには文字プロパティが必要です。これらは Unicode Consortium のウェブサイトから入手できる Unicode Character Database(UCD)から取得します。
ほとんどの言語でライブラリがあります—Go も含めて—but 私はそれを使いませんでした。Go のライブラリは遅れており、2026 年 1 月時点ではまだ Unicode 15.0.0(2023 年 9 月版)しかサポートしておらず、最新の 17.0.0(昨年 9 月版)は知らない文字が多く、Quamina はそれに頼れませんでした。
そこで
UnicodeData.txt をhttps://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt から取得し解析しました。これはセミコロンで区切られた平坦なファイルで、必要なのは最初のフィールド(コードポイント)と第三のフィールド(カテゴリ)のみです。一部行は非標準で、例として漢字が U+4E00 から U+9FFF まで連続していることを示しています。
出力結果は、各 Unicode カテゴリ—また補集合 (
~P{L} は「文字でないもの全て」) について—コードポイントのペア(範囲)の一覧です。例えばカテゴリ C の最初の行:
{0x0020, 0x007e}, {0x00a0, 0x00ac}, {0x00ae, 0x0377},
カテゴリは 37 個で、合計すると多くの範囲が生まれます:
- L: 1 945 ペア
- Ll: 664 ペア
- M: 563 ペア
極端な Zl と Zp はそれぞれ 1 ペアだけ。総数は 14 811 ペアで、生成 Go コードはわずか 5 122 行です。
文字プロパティオートマトン
これらの範囲を有限オートマトンに変換する作業は簡単でした—すでに
[a-zA-Z0-9] のようなシンプルな正規表現用コードがありました。しかし速度が遅く、992 個の正規表現をテストすると約 10 秒から 12 秒以上へと伸び、コーヒーブレイクごとにテストを走らせるには辛いものでした。
そこでオートマトンをすべて事前計算しコードとしてシリアライズすることにしました。初期は 775 K 行の Go コード、後にサイズが 12 M になり、起動時に長時間停止して IDE(Goland)をクラッシュさせました。この手法は扱いづらく、Plan B を探すことにしました。
ポイントペアからオートマトンへ変換するジェネレータはシンプルですがメモリを多く消費します。速度とコストの最適化を試みても明確な改善策が見つかりませんでした。
キャッシュで救済
古典的な CS のテクニック――キャッシュを思い出しました。Quamina のインスタンスは、Unicode プロパティのオートマトンを初めて使用したときに生成し、その後保持します。速度は 135 /s から 4 330 /s に跳躍—30 倍以上の向上で「ロックンロール」レベルの十分性を達成しました。
オートマトンの構築は重い作業ですが、Quamina は入力を数十万〜百万件/秒でマッチさせることができます。オートマトンは分岐が多くても浅いため—UTF‑8 文字は最大4バイト、平均よりも短いため—ほとんどのマッチや失敗は1~2 ブランチ後に決定します。
Claude を使うべきだったか?
このセクションでは「UnicodeData.txt の取得/解析」「ペア集合の計算」「Go コード生成」「膨大なソースファイルの再編成」「単体テストの作成」といったルーチン作業を行いました。Marc Brooker の On the success of ‘natural language programming’ と Salvatore “antirez” Sanfilippo の Don’t fall into the anti‑AI hype を読んで、GenAI を将来の必須ツールとみなす勢力に加わりました。
Claude はこれらをより速く、最初から正しく行えるかもしれませんが、私は使いませんでした。理由は:
- ツール設定が整っていない
- 我慢せずにプロンプトスキルの向上に時間を投資したくなかった
依然として GenAI は高価で過剰宣伝されており、ほとんどのビジネスアプリケーションには適していません—ただしコード生成は LLM が輝く領域です。
Quamina.next?
数値量化子機能(例:
a{2-5})を配信すれば、Quamina の正規表現サポートは完了します。大きなバグが無ければ間もなく Quamina 2.0 をリリースしようと思っています—パターンマッチングソフトウェアにとって正規表現は質的差別化要因です。
その後、さらに多くの興味深い機能を追加できる可能性があります。残念ながら Quamina の数年後、人生や他プロジェクトが気を引き、コミュニティの貢献も薄れてしまいました。彼らは懐かしいですが、今後どうなるか見守りましょう。