#programming

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（実行しながら高速化する仕組み）を使うのが大きな特徴です。 ここが面白いところで、普通のスクリプト言語は「

AIがプログラマーの仕事をどう変えるのか。この記事は、その話を「フロントエンドがすでに経験したこと」とそっくりだと見ています。 かなり刺激的な主張ですが、正直かなり面白いです。なぜなら、これは単なる「AIすごい／危ない」論ではなく、便利さと引き換えに何が失われるのかを、歴史を使って考えているからです。 AIによるコーディングは、フロントエンドがフレームワークで経験した deskilling（技能の空洞化） に似ている フロントエンドはかつて、HTML/CSS、ブラウザ差、アクセシビリティ、性能などを深く理解する仕事だった でもJavaScript frameworkの普及で、ブラウザを「ただの実行先」とみなし、一般的な開発者でも扱いやすくなった AIも同じように、コードを書く作業を高い抽象度に持ち上げているが、結果が不安定で、抽象化がかなり“漏れる” Stack OverflowやGoogle検索の変化も、「知っている人を少し速くし、知らない人でもそれなりに動くものを作れるようにした」という点で似ている ただし、品質よりも成果が重視されやすい現実

AI支援の開発では、「コードが動くか」だけでなく「リポジトリ全体が信頼できるか」が重要になる 著者は、AIの出力とリポジトリの実態のあいだに生まれるズレを問題視している そのズレは、未完了なのに完了したように見える、古い情報が残る、仮置きのコードが本物みたいに残る、などで起きる 著者が作っている Scarab Diagnostic Suite は、AIそのものではなく、AIを使う開発環境を監督・診断するCLIツール これからは「AIが仕事をできるか」だけでなく、「リポジトリが何を本当に証明できるか」が大事になる、というのが記事の主張 AIを使った開発って、見た目はかなり順調に見えることがあります。 コードはそれっぽくできるし、テストもある。場合によっては、AIエージェントがかなり役に立っているように見える。 でも著者は、そこに落とし穴があると言います。 「AIの出力は良さそうなのに、リポジトリの信頼性は下がっていく」 という失敗モードがある、という話です。 これ、かなり面白い視点だと思いました。 普通は「AIのコードがダメだった」「プロンプトが悪かった」で話が終わりがち

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

vibe coding は、LLMに「こういうものを作って」と頼み、出てきたコードをほぼ読まずに進める開発スタイル もともとは Andrej Karpathy が 2025年2月に名付けた言葉 コードを「忘れる」ことが前提なので、プログラミング経験がなくても使えるのが強み ただし、保守性・正しさ・セキュリティに大きな弱点がある Martin Fowler は、捨てられる前提のソフトウェアには向くが、重要なシステムには向かないと警告している 似た言葉の Agentic Programming とは、実は別物として分けて考えるべきだと主張している Martin Fowler の記事で扱われている vibe coding は、ざっくり言うと、 > LLMに「こんなの作って」とお願いし、動かして、直してと頼み続ける。でも、LLMが生成したコードはほとんど見ない。 という開発スタイルです。 ここで面白いのは、単に「AIにコードを書かせる」話ではないことです。 ポイントは **“forget that the code even exists

Nicholas Carlini氏が、84,688個のregular expressionsで動くチェスエンジンを作った ただし本物の強いAIではなく、2-ply minimax（自分→相手の2手先まで見る簡易探索）で動く“変な実験” 仕組みの核心は、正規表現を命令として使う擬似CPUを作り、その上でチェスの手を選ばせていること 状態は1本の文字列で管理し、stackとvariablesを正規表現の置換で操作する 面白さは「正規表現は検索ツール」という常識を、計算機の材料にひっくり返しているところにある 正規表現でチェスを指す。 この一文だけでもう十分に変です。しかも、ただのネタではなく、実際に有効な手を返すチェスエンジンとして動くのがこの話のすごいところ。作者のNicholas Carlini氏は、84,688個のregular expressionsを順番に実行することで、盤面に対して1手を決める仕組みを作りました。 もちろん、強いわけではありません。記事のタイトルにもある通り、2-ply minimaxです。

C/C++では、undefined behavior（未定義動作）が思った以上に多い それは「コンパイラの嫌がらせ」ではなく、言語仕様上、何が起きても文句を言えない状態のこと 未定義動作は、最適化の有無に関係なく危険になりうる アラインメント不一致、型変換、可変長引数、null pointer、ゼロ除算など、一見普通に見えるコードにも落とし穴がある 著者の主張はかなり強めだが、「Cは細部まで気をつけてもなお危ない」という警鐘としては非常に示唆的 今回紹介する記事は、タイトルからしてかなり挑発的です。 「Everything in C is undefined behavior」――直訳すれば「Cのすべては未定義動作だ」。もちろん厳密には言いすぎですが、著者はあえて極端な表現で、C/C++の怖さを読者に叩きつけています。 率直に言うと、これはかなり面白い記事です。 なぜなら、単に「Cは危ないよね」で終わらず、“どこがどう危ないのか” を、具体例を積み上げながら見せてくるからです。しかもその例が、いかにもありがちなものばかり。読んでい

CUDAを学びたいと思ったとき、まず困るのが「で、どの本を読めばいいの？」問題です。 このGitHubリポジトリ awesome-cuda-books は、その悩みにかなり真っ向から答えてくれる「CUDA本のおすすめ一覧」です。 GPUプログラミングは、普通のC++やPythonとは少し勝手が違います。 CPUが「順番にコツコツ処理する」のが得意なのに対して、GPUは「同時にたくさん処理する」のが得意。 この違いをうまく使えると、画像処理、科学計算、機械学習の一部などで大きな高速化が狙えます。 ただし、学び方を間違えると「用語が多すぎて何が何だか…」となりがち。そこを本リストが助けてくれます。 CUDA学習向けの本を、初心者〜上級者まで段階別に整理している C++中心の本だけでなく、Python向けのCUDA本も載っている 「理論」だけでなく、実践・最適化・デバッグ寄りの本もある 2022〜2026年の比較的新しい本も拾っていて、古い情報だけに偏っていない ただし、CUDAは変化が速いので、本だけで完結しないのが重要 公式のCUDA C++ Programming Gu

Erlang/OTP 29.0 が公開されました。 ひとことで言うと、「新機能もあるけど、今回は安全性と堅牢性をかなり真面目に底上げした版」という印象です。Erlangは昔から、止まらない通信システムや分散システムで強い言語として知られていますが、今回のアップデートはその“実戦向け”な性格がさらに濃くなっています。 `-unsafe` 属性が追加され、危険な関数を明示しやすくなった コンパイラが「危ない呼び出し」に警告を出すようになった SSH daemon が shell / exec をデフォルト無効化し、より安全な初期設定に SFTP subsystem もデフォルト無効化 SSL/SSH のデフォルトで、量子耐性を意識した hybrid key exchange が採用された `io_ansi` で ANSI カラーや装飾を出しやすくなった `ct_doctest` でドキュメント中のコード例をテストできる native records、`is_integer/3`、multi-valued comprehensions など言語機能も拡張 Windows の 32-b