#go

最初に思ったのは、「これは設計の話というより、かなり強い信念の話だな」ということだった。Go で MCP server を作るだけでも十分手間がありそうなのに、そこへ zero-dependency と 22 security layers を同時に載せる。普通ならどこかで妥協しそうなところを、あえて妥協点として明示しているのが面白い。 特に引っかかったのは、ML inference まで “依存なし” の枠内に押し込めているところだ。Python ならともかく、Go で ONNX Runtime を使うなら普通は何かしらライブラリに寄るはずだし、そこを vendored binary と CGO でねじ伏せている。80MB 重くなるのを「その代償は払う」と書いているのも印象的だった。軽さを捨ててでも、air-gapped deployment と supply chain risk の低減を取りにいく。ここは実務っぽい潔さがあると思う。 一方で、22 層のうちどこまでが本当に効いているのかは、記事だけでは少し見えにくい。Regex scan、RBAC、response scan、au

Goの並行処理は、書けるようになるまでが長く、いったん慣れても「この場面では channel でよかったか、mutex か、select か」と迷いがちです。今回の「Go concurrency distilled」は、その迷いをほどくための短い再整理版として公開されました。しかも単なる解説ではなく、コードをその場で動かしながら試せる作りです。Goで仕事をしている人にとっては、基礎の学習書というより、手元の知識を整えるための速い復習帳に近い内容です。 元記事は、Anton Zhiyanov氏が公開した「Go concurrency distilled」というミニブックの紹介です。扱うのはGoの並行処理で、goroutines、channels、select、pipelines、time、context、wait groups、data races、race conditions、mutexes、semaphores、signaling、run once、object pool、atomics、testing、scheduling、diagnostics、final thoughts と

Goのブログが、SIMDを扱う実験的なAPIを大きく前に出してきました。SIMDは、CPUが複数の値をまとめて処理するための仕組みで、計算の重い処理をかなり速くできる一方、これまではGoから使うにはアセンブリを書くしかありませんでした。今回の発表で目を引くのは、単に高速化の道具を増やしただけではなく、CPUやOSの違いをできるだけ隠して「同じコードを別の環境で動かす」方向に踏み込んでいる点です。Go 1.26と1.27で何が変わったのかを追うと、Goが低レイヤー性能と移植性をどう両立しようとしているかが見えてきます。 元記事は、GoにおけるSIMDの扱いが大きく変わった、と説明しています。SIMDは Single Instruction Multiple Data の略で、1つの命令で複数のデータをまとめて処理するCPU機能です。たとえば float64 を8組まとめて足すような処理ができ、暗号、データ処理、AIのような計算集約的な処理を速くできます。GoのGreen Teaガベージコレクタも、メモリ上の生存オブジェクトを探す場面でSIMDを使っていると書かれています。 ただ、これまで

LLM（大規模言語モデル）は、バラバラで変化の激しい技術より、ルールが安定した技術のほうをうまく扱える JavaScriptやPythonは便利だけど、エコシステムが断片化しやすく、エージェントには迷路になりがち Goは、文法・標準ライブラリ・ツールチェーン・並行処理・メモリ管理の面で、LLMにとってかなり相性がいい 「Goが最高」というより、“制約が強くて選択肢が少ない言語”が、AIには有利という主張 人間にとっての「柔軟性」は、LLMにとっては「迷子の原因」になりうる、という視点が鋭い Jacob Young氏の記事「Use boring languages with LLMs」は、かなり挑発的ですが、筋の通った主張です。要するに、 > LLMやcoding agentを使うなら、派手で自由度の高い言語より、地味でルールが揃った言語を使ったほうがいい という話です。 ここでいう「boring languages」は、「退屈な言語」ではなく、“仕様や流儀が安定していて、毎回ちがうやり方を要求しない言語” くらいの意味だと思うとわかりやす

Corrode Rust Consulting の記事「Migrating from Go to Rust」は、Go から Rust へ移るときの論点をかなり正直に整理したガイドです。 面白いのは、「RustはGoより速いの？」みたいな単純な話ではないと最初に釘を刺しているところだと思います。 著者の主張をざっくり言うと、Go も Rust もサーバー開発には強い。 ただし Rust は、コンパイラがもっと多くのミスを事前に防いでくれる。その代わり、学習コストや書き方の制約は増える。 つまり、移行の価値は「性能アップ」よりも 正しさ・安全性・開発体験の改善 にある、という話です。 --- Go と Rust はどちらも静的型付き・コンパイル型の言語で、バックエンド開発に強い ただし Rust は、nil、エラー処理、データ競合、リソース管理を type system に寄せている Go は「やさしく始めやすい」、Rust は「間違いにくい」 Go から Rust への移行理由は、速度不足よりも「細かい不満の積み重ね」であることが多い Rust の borrow