#rust

Rust で長く開発してきた人が、Zig を実際に触って何を感じたのかを書いた記事だ。単なる印象論ではなく、JSONPath という実用的なライブラリを Rust 版から Zig 版へ移植しながら、IDE 支援、ファイル構成、テスト、関数型っぽい書き方、メモリ管理の手触りを比べている。面白いのは、Zig を持ち上げる記事ではなく、Rust に慣れた目で「どこが気持ちよく、どこが面倒か」をかなり率直に書いている点だと思う。言語の思想の違いが、日々の作業の小さな癖にどう出るのかが見えてくる。 書き手は冒頭で、自分はこの7年間 Rust 開発者としてやってきたと述べる。主に OSS を扱い、Rust の関数型寄りの書き方、たとえば整った関数や表現力のある型に親しんできた。一方で Zig も以前から気になっていた。C の後継候補として、より低レベルで軽く、しかも実用言語として存在感を増しているからだという。昔 C を触っていたこともあり、Rust と比べたらどう感じるかは前から興味があったらしい。 ただし、この記事は Zig の上級者が書いたものではない。最初に触ったプロジェクトがこの移植作業

Cloudflareがまた、大規模インフラでは「小さな無駄」がどれほど高くつくかを示す話を出してきた。今回はPingoraを使う社内の負荷分散サービスで、あるアルゴリズムのメモリ使用量を見直し、全世界で100TBを超えるRAMを取り戻したという。派手な新機能の話ではないが、こういう改善こそクラウド事業者の現場では効く。しかも今回は、Rustと少しの数学が主役だ。 元記事が扱っているのは、Cloudflareの内部負荷分散サービス「Pingora Backend Router」、略してPBRだ。PBRは、キャッシュ可能なリクエストをどのサーバーに送るかを決める役割を持っていて、その判断には consistent hashing を使っている。consistent hashing は、サーバーの増減があっても割り当てが大きく崩れにくい方法で、分散システムではよく使われる。Cloudflareではこの仕組みを open-source の `pingora-ketama` ライブラリで実装していた。 話の発端は、Cloudflare内部のIvanが出したチケットだった。内容は「Pingora

What jumped out at me is not “wow, agents can rewrite large codebases.” It’s that the interesting bit is all the scaffolding around the agents. If you read the piece closely, the headline claim is less “let Claude do a giant rewrite” and more “different teams built very different control systems around the same basic capability.” That feels right to me. A rewrite is never just a rewrite. It’s a confidence problem. GitHub and Anthropic both used their own agents on major Rust migrations, but the

TokioはRustの非同期処理を支える定番ランタイムですが、速く動かすための「万能の正解」はありません。今回の元記事は、その前提をかなり率直に書いた実践メモです。遅い原因をTokioそのものに決めつける前に、何を測り、どこを疑い、どこで割り切るべきかを整理しています。読みどころは、抽象論ではなく「現場で本当に効く判断」が並んでいるところでしょう。 元記事は、RustConfのUnconfで交わした議論と、自身の経験をもとにした「fast Tokio applications」の原則をまとめたものだ。著者は、Tokioアプリの性能問題にはハードルの低い決まりごとがほとんどなく、「it depends」が多すぎると認める。そのうえで、まず確認すべきなのは本当に問題があるのか、という点だと強調する。多くの実アプリでは、`.await` に戻るまでの「poll」がAlice Ryhlの勧める 10〜100マイクロ秒よりずっと長いが、それが必ずしもユーザー体験やKPIの悪化に直結するとは限らない。見つけた赤信号を片っ端から直すのではなく、改善したい実際の指標から逆算せよ、という姿勢だ。 性能を

MicrosoftがRustを「Tier-1 language」として扱っている、とRust Foundationの寄稿記事が改めて説明しました。単に「Rustを使っています」という話ではなく、社内開発の中でC++やC#、TypeScriptと並ぶ重要言語として位置づけ、Windows向けの開発基盤に深く組み込んでいるという宣言です。Rustは安全性の高い言語として語られがちですが、この記事が面白いのは、その評価が理想論ではなく、Microsoftの実務やビルド基盤の話にまで降りている点にあります。しかも焦点は言語そのものより、RustをWindowsの既存エコシステムにどう接続するかにあります。 記事はまず、RustがMicrosoftにとって戦略上重要な技術であると位置づけます。Azure CTOのMark Russinovichが以前に示したネイティブコードの将来戦略や、MicrosoftがRust Projectを支えるために長年にわたって資金を投じてきた流れを踏まえたうえで、Rustは今や社内開発で最もよく支援される言語群の一つになったと述べています。ここでいう「Tier-1

React のビルド周りで、かなり実務的な変化が起きています。Master.dev の記事は、React Compiler の Rust 版を使うように切り替えたら、コンパイル部分が一気に速くなり、しかも今まで引っかかっていた制限も少しずつ解消されてきた、と伝えています。単なるベンチマークの自慢ではなく、CI の待ち時間や設定の複雑さに直結する話なので、フロントエンドを日々触る人にはかなり刺さる内容です。特に React Router や Vite を使っているチームは、実際の移行手順まで含めて気になるはずです。 記事を書いた開発者は、Outlyne というウェブサイトビルダーの 1,036 ファイルからなる React Router のコードベースを、oxc チームが 2026 年 8 月 4 日に公式対応を出した Rust 版 React Compiler に切り替えたと説明しています。そこで得られたのは、コンパイラ部分だけで約 17.6 倍の高速化でした。Babel ベースのコンパイラでは 14.3 秒かかっていたものが、Rust 版では 0.81 秒になったそうです。 ただし、

Spotifyを使うためのアプリはもう十分あるように見えますが、実際には「重い」「ブラウザの延長に見える」「キーボード操作がしづらい」といった不満が残りがちです。Fastpotifyは、そうした不満に真正面から応える形で出てきたデスクトップ向けクライアントです。Linux、macOS、Windowsに対応し、Rustで書かれたネイティブアプリとして、軽さと操作性を売りにしています。単なる再生ソフトではなく、Spotify Connectやライブラリ閲覧、Winamp風のミニプレーヤーまで含めているのが面白いところです。 Fastpotifyの説明はかなりはっきりしています。これは「Spotify, native and fast」を掲げる、軽量なSpotifyクライアントです。対応OSはLinux、macOS、Windowsで、ローカル再生、ライブラリへのアクセス、Spotify Connectの操作を一つのウィンドウで扱えるとしています。 まず強く押し出しているのが軽さです。ブラウザエンジンを使わないネイティブバイナリで、起動は1秒未満、メモリ使用量は通常100〜250MB程度だと書

Rustで使える埋め込み型のkey-value storeとして、TurboKVというライブラリがGitHubで公開されています。単に「速いDBです」で終わる話ではなく、非同期API、batchの原子性、range scan、耐久性の切り替え、圧縮、バックグラウンドcompactionまで含めて、かなり実戦的な機能をひと通り揃えているのが目を引きます。Rustで小さく始めたいが、あとから保存方式や一貫性で困りたくない、という人には気になる存在です。今回はそのREADMEを軸に、何を目指したDBなのかと、そこから見える設計の匂いを追います。 TurboKVは「A fast, simple, and embedded key-value store for Rust」と名乗る、非同期の埋め込み型データベースです。READMEでは、atomic batches、ordered range scans、configurable durability、compression、background compaction を備えると説明されています。つまり、単純な `get` / `put` だけの

Cloudflare が、自社の DNS サービス群を支える内部基盤「Big Pineapple」で、キャッシュの持ち方を見直し、大きなメモリ削減を実現したと明かした。対象は 1.1.1.1 をはじめ、Gateway DNS、DNS Firewall、AS112 など、同社のDNS関連サービスを裏で支える仕組みだ。単なる省メモリの話ではなく、同時に処理速度も上がった点が面白い。サーバーを増やす話ではなく、既存の設計を細かく磨くだけでここまで変わる、というところにこの話の価値がある。 Cloudflare によると、Big Pineapple は任意の時点で 2500億件を超える DNS キャッシュエントリを保持している。DNS キャッシュは、過去に調べた名前解決の結果を覚えておき、次回以降の応答を速くする仕組みだ。Big Pineapple では、キャッシュが空の状態から始まり、DNS クエリが来るたびに項目が増えていく。上限に達したら、古いものや人気のないものから追い出していく。 ここで重要なのは、1件あたりの無駄が全体では巨大なコストになることだ。Cloudflare は「1エント

最初に思ったのは、「速さ」より先に「本当に置き換えていいのはどこまでなんだろう」という不安のほうだった。この記事、Claude Code が何万行ものコード移行をかなり短期間で進めた話として読めるのだけれど、読後感は単純な武勇伝ではなかった。むしろ、AI がコードを“書ける”ことより、既存コードを“壊さずに移す”ために何を見ているのかのほうがずっと面白い。 特に引っかかったのは、テストや judge（判定用の仕組み）をかなり厚く置いている点だ。AI に「移行して」とだけ頼んで終わりではなく、どのテストを呼ぶか、どう同値変換するか、意図的な破壊をどう見分けるかまでルール化している。ここを読むと、AI の価値は“賢さ”そのものというより、作業の周りにある面倒な確認をどこまで機械に持たせられるかにあるのだと思う。逆に言えば、ここを雑にすると、どれだけ派手なデモでも現場では怖くて使えない。 もう一つ印象に残ったのは、移行先の言語が Zig や Rust みたいな「堅い」ものだったことだ。こういう移行は、ただの書き換えではなく、実質的には設計の再点検になる。だからこそ、AI が便利だとしても、人

Claude Code v2.1.181以降は、JavaScriptランタイムのBunを「Rustで書き直した版」で動かしている。 きっかけはBun作者Jarred Sumnerの投稿で、起動がLinuxで10%速くなったが、見た目の変化はほとんどないという話だった。 Simon Willisonは実際に自分の環境を調べ、Claude Codeの中にBunのバージョン文字列やRustのソースファイル名が埋め込まれているのを確認した。 つまり、かなり多くの端末で、Rust版Bunが静かに本番投入されているらしい。 “Boring is good” という一言が、この話のいちばん面白いところだと思う。派手な新機能より、地味でも速くて安定しているほうが現場では強い。 この話、派手さはないのに妙におもしろいです。 Claude CodeはAnthropicの開発補助ツールで、要するに「AIにコード作業を手伝わせるための道具」です。その内部で動く仕組みのひとつに Bun という runtime が使われています。runtime というのは、JavaScriptやTypeScriptを動かすための

For Claude Code users, this is one of those infrastructure changes that barely shows up in the product experience but matters a lot underneath. Simon Willison dug into the binary and found evidence that Claude Code is now using the Rust port of Bun, which fits Jarred Sumner’s claim that the newer Claude Code release line adopted it and got a small startup win. Jarred Sumner said that Claude Code v2.1.181 and later use the Rust port of Bun. The claimed benefit was modest: startup got about 10% fa

Rotoは、Rustアプリに組み込むためのembedded scripting languageで、static typedかつJIT-compiledなのが特徴 公開から1年で、6つの新バージョンが出て、機能もかなり増えた `while` / `for`、`enum`、`List`、`const`、`+=` など、実用寄りの機能がどんどん追加された Rustとの連携方法が改善され、`library!` マクロで登録がかなり書きやすくなった ロゴ、講演、マニュアル改善、外部採用など、プロジェクトとしての存在感も一気に増した 今後は `hashmaps`、ユーザー定義 state、generic functions、formatter、LSP などが課題 Rotoは、Rustアプリの中で動かすためのスクリプト言語です。 ただの「スクリプト」ではなく、型が静的に決まる（実行前に型がチェックされやすい）うえに、JIT-compilation（実行しながら高速化する仕組み）を使うのが大きな特徴です。 ここが面白いところで、普通のスクリプト言語は「

Rosalind は、Rustで書かれた genomics engine で、低メモリかつ決定的（deterministic）な出力を目指している 主な用途は read alignment、variant calling、coordinate sort、somatic calling、truth-set evaluation 強みは、ファイル全体ではなく、局所的な coverage を見ながら streaming 処理する設計にある 「100MB RAM で whole-genome workloads」というのはかなり野心的で、特に低資源環境では魅力が大きい ただし現時点では single contig / single-threaded / uncompressed FASTQ・FASTA など、適用範囲に制約もある 研究・学習・組み込み用途にはかなり面白いが、万能な本番パイプラインというよりは「尖った実装」と見るのがよさそう GitHub に公開されている Rosalind は、ひとこ

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

AzureのReplication基盤であるRSLを、Rustで“現代版”として作り直した話 100K行超のRustコードを、AI coding agentsを使って短期間で実装 正しさの担保には「code contracts」がかなり効いた Spec-Driven Developmentは、重すぎる運用より“軽量版”がちょうどよい 性能改善では、23K ops/sec → 300K ops/secまで伸ばした 今後のAI開発には、テスト・契約・性能改善の自動化がもっと進んでほしい、という本音が語られている この記事は、Cheng Huang氏が「AI coding agentsを使って、実際の本番級分散システムをどこまで作れるのか」をかなり本気で試した記録です。 作ったのは、Rustベースのmulti-Paxos consensus engine。 Paxosは、複数のサーバーが“このデータの順番や内容で決めよう”と合意するための仕組みで、分散システムの心臓部みたいなものです。 要するに、データを複数台で安全に一致させるための超重要技術です。 しかもこのプロジェクト、

Bunの一部ではなく、Bun本体をRustに書き換えたというかなり大きな話 既存のテストは全プラットフォームで通過 いくつかのmemory leak（メモリリーク）とflaky test（たまに落ちる不安定なテスト）も改善 binary size が3MB〜8MB縮小 benchmarks は同等か、それ以上に高速 そして何より、compiler-assisted toolsでメモリバグを見つけやすくなったのが大きい ただし、まだ最適化とcleanupが残っていて、段階的に進める段階 Bun は、JavaScript や TypeScript を速く動かすための実行環境です。 ざっくり言うと「Node.js の代わりになる、軽くて速い新世代ランタイム」の一角ですね。 今回のPRは、その Bun を Rustで書き換えた というものです。 これ、ひと言で言うと「家の中身をほぼ丸ごと、別の素材で作り直した」くらいの大工事です。普通に考えてかなり無茶です。しかも、ただの実験ではなく、既存のテストを通し、サイズも小

`crates.io` は、Rust の「crate（パッケージやライブラリ）」を公開・共有するための中心的な registry です。 crate は、Rust で書かれた再利用可能なコードのかたまりだと考えるとわかりやすいです。 今回のページは `zerostack 1.0.0` の公開先として表示されており、Rust の配布エコシステムの一部になっています。 画面上の本文はかなりシンプルですが、実は「Rust の開発でどこから部品を取ってくるか」を支える重要な場所です。 個人的には、こういう“地味だけど土台になるサービス”こそ、開発体験を大きく左右すると思います。 今回の元記事は、Rust のパッケージ登録サイトである `crates.io` のページです。 Rust は、速度と安全性を両立しやすいプログラミング言語として知られていますが、実際の開発では「自分で全部書く」のではなく、便利な部品を組み合わせて作ることが多いです。 その部品が `crate` です。 `crate` は Rust の世界で使うパッケージやライブラリのこと。 たとえば、文字列の処理、HTTP通信、暗号化