huizhou92's Blog

Why Your AI Agent Keeps Forgetting: A Practical Memory Architecture for Individual Users

Mon, 02 Mar 2026 23:03:33 +0800

The Problem: Why Does Your Agent Get Dumber Over Time?

Picture this: you’ve been working with an AI agent for weeks, patiently teaching it your project structure, personal preferences, and workflows. Within a single conversation, it remembers your instructions just fine — but the next day, when you start a new session, it’s like meeting a stranger. Worse still, it starts confidently fabricating events that never happened, asks you the same questions again, and forgets critical decisions made just hours ago.

If this sounds familiar, don’t blame the agent’s intelligence — the problem is a fundamental flaw in memory system design.

Most people assume AI “has memory” because it can recall earlier parts of a conversation. What’s actually happening is far simpler: the agent is using its Context Window — a temporary workspace, not permanent storage. When the conversation gets too long and triggers compaction, or when you start a new session, that workspace gets wiped clean.

OpenClaw tries to fix this by persisting long-term memory to local Markdown files (MEMORY.md, daily logs, etc.). In theory, memories can span months or even years. Files live on disk, are human-readable, editable, and git-versionable — sounds perfect, right?

Yet countless users report that their agents become progressively “demented” over time.

The root causes boil down to three layers:

Compaction-induced “summary amnesia”: When the Context Window approaches its ceiling (say, Claude Opus 4.6’s 200K token boundary), OpenClaw automatically triggers compaction — it asks the model to “summarize” earlier conversation into shorter chunks, then discards the originals. Critical details get lost in translation.
Retrieval failure — “remembered but can’t recall”: Important information does get written to disk (MEMORY.md, daily/YYYY-MM-DD.md), but retrieval depends on memory_search / memory_get tools. Missed recalls happen because the underlying embedding model isn’t strong enough, pure semantic search misses keyword matches, and MEMORY.md bloats into an unwieldy mess over time.
No forgetting + no conflict resolution: OpenClaw almost never forgets — files only grow, never shrink. Outdated preferences, abandoned project decisions, early incorrect instructions — they all pile up. When new information arrives, the system doesn’t “update”; it only appends. Contradictions accumulate, noise dilutes signal during retrieval. Eventually the agent gets confused and starts fabricating stories to reconcile conflicting “facts.”

Six Structural Flaws in Current Memory Systems

OpenClaw’s default memory scheme — Markdown files + vector search — has obvious strengths: human-readable, git-versionable, zero external dependencies. But in practice, I’ve found six structural weaknesses, and none of them are trivial:

1. Flat and undifferentiated: A casual chat from a year ago carries the same weight as yesterday’s architecture decision. Search results drown in noise.

2. No forgetting mechanism: Append-only, never delete. The memory system eventually drowns itself — stale information masquerades as “facts” and pollutes current decisions.

3. No automatic consolidation: Important insights must be manually distilled and written in. The agent never proactively “digests” what happened today.

4. No temporal reasoning: The agent knows “something happened” but not whether it was 3 days or 3 months ago — it simply can’t judge whether information is stale.

5. No memory promotion: Critical decisions buried in logs stay buried forever. No mechanism promotes them to the long-term knowledge base.

6. No knowledge graph: Unable to express relational knowledge like “A knows B” or “Project X depends on tool Y.” Every memory is an isolated, flat entry.

What Does Academia Say? (February 2026 Research Review)

In February 2026, agent memory suddenly became a hot academic battleground — 10+ papers published in a single month. One survey paper with 59 co-authors proposed a three-dimensional taxonomy for memory systems.

Let me highlight the key ones:

A-MEM (NeurIPS 2025): Borrows from the Zettelkasten note-taking method — new memories auto-generate keywords and associative links, building an interconnected knowledge network. A fascinating approach.
xMemory (ICML 2026): Decouples memory into semantic components, organizes them hierarchically, and supports top-down retrieval, dramatically reducing retrieval noise.
BudgetMem: Three-layer budget structure + RL router that prioritizes retrieval resources for the most important memories.
InfMem: PreThink-Retrieve-Write protocol — the agent “thinks about what to look for” before retrieval, boosting accuracy by 10–12%.

But what’s even more worth noting are two industry warnings:

⚠️ Serial Collapse (Dark Side of the Moon paper): Agents may gradually degenerate into not using memory at all — even when the memory system is running perfectly. Memory existing ≠ Agent using it.

⚠️ Memory Misevolution (TAME paper): Accumulation of “toxic shortcuts” during normal iteration — memory strategies that appear efficient but violate constraints.

These two warnings are extremely common in practice. You’ve probably noticed it yourself: sometimes the agent has memory files right there but simply never queries them.

The Solution: Three-Layer Memory Architecture

Synthesizing all the research above plus my own hands-on experience, here’s a deterministic, zero-cost architecture for individual users.

First, let me show you my own memory system directory structure:

root@ubuntu-4gb-openclaw:~/.openclaw/workspace/memory# tree
.
├── daily
│   └── 2026-03-01.md
├── episodic
├── hotspots_2026-02-18.md
├── hot-topics-2026-02-17.md
├── hot-trends-2026-02-18.md
├── INDEX.md
├── keywords_20260217_1600.json
├── lessons
│   ├── api-guide.md
│   ├── mistakes.md
│   └── system-deployment.md
├── NOW.md
├── people
│   └── 老板.md
├── rules
│   └── storage-routing.md
├── scripts
│   ├── archive-stale.sh
│   └── daily_digest.py
└── semantic
    ├── golang-patterns.md
    ├── writing-frameworks.md
    └── writing-style-guide-huizhou92.md

Let’s walk through each layer.

Short-term layer: NOW.md (the most overlooked design)

NOW.md is the highest information-density file in the entire architecture.

The core idea is straightforward: after every restart, the agent’s first action should be reading NOW.md — not searching through a massive memory library. It’s the essence extractor, the “where did I leave off” quick-recovery tool, the life raft after compaction.

# NOW.md — Workspace
Updated: YYYY-MM-DD HH:MM
## Today's Focus
- ✅ Completed items
## In Progress
- 🔄 Unfinished tasks (including blockers)
## Current Priorities
| Priority | Task | Status |
|----------|------|--------|
| P0 | Most important thing | In progress |

Key rule: NOW.md is the only file allowed to be overwritten. All other memory files are append-only.

Medium-term layer: Daily logs

Filename: memory/YYYY-MM-DD.md
Write mode: Append-only, never overwrite
Format suggestion: ### HH:MM — Event title + content description
Principle: Better too much than too little. Logs are raw material; distillation happens through nightly automation.

Long-term layer: Structured subdirectories

Knowledge files use a standardized YAML frontmatter:

title: "File Title"
date: 2026-02-28
category: lessons
priority: 🔴          # 🔴 Core | 🟡 Important | 🟢 Reference
status: active        # active | stale | superseded | conflict
last_verified: 2026-02-28
tags: [relevant tags]

Entries with last_verified older than 30 days are auto-flagged as ⚠️ stale, prompting manual review.

INDEX.md: Knowledge base health dashboard

| File | Priority | Status | Last Verified | Description |
|------|----------|--------|---------------|-------------|
| tools | 🔴 | ✅ active | 2026-02-28 | Verified tool list |
| api-guide | 🟡 | ⚠️ stale | 2026-01-10 | Possibly outdated, needs review |
| old-workflow | ⚪ | ~~superseded~~ | 2025-12-01 | Replaced by new approach |

On startup, the agent glances at INDEX.md and knows the health status of the entire knowledge base in seconds.

Lightweight Knowledge Graph: SQLite Triple Table

This is the most complex of the six flaws, and the fundamental limitation that pure Markdown cannot break through.

Why Do We Need a Knowledge Graph?

Markdown files can only store flat facts:

Brian prefers concise communication. Project X uses PostgreSQL. Tool Y requires an API Key.

But real-world knowledge has relationships:

Brian → responsible for → Project X → depends on → Tool Y → requires → API Key (stored in secrets/)

When the agent is asked “What API Key does Brian’s project need?”, pure vector search simply cannot complete this three-hop inference.

The solution: a SQLite triple table. No external dependencies, no deployment overhead — perfectly sufficient for personal knowledge relationship management:

CREATE TABLE triples (
    subject TEXT,    -- Entity (e.g., "Brian")
    predicate TEXT,  -- Relationship (e.g., "responsible for")
    object TEXT,     -- Object (e.g., "Project Alpha")
    added_date TEXT,
    confidence REAL DEFAULT 1.0
);

Use Python or Node for reads, writes, and queries. The entire database is a single .db file sitting alongside your Markdown memory — portable and trivially easy to back up.

When to Write to the Knowledge Graph

Not all information deserves graphing. My recommendation is to limit it to these scenarios:

System dependencies: Project A depends on tool B, which requires configuration C
Resource locations: Where credentials / files / APIs are stored
Historical associations: Decision X was made because of event Y

Daily facts (preferences, operation logs) are fine in Markdown — don’t over-graph.

Forgetting Mechanism: Active Forgetting Matters More Than Passive Retention

This might sound counterintuitive, but forgetting is one of the most critical capabilities of a memory system.

Each memory entry is tagged with priority and expiration:

`1`	`- [🟢LOW][CONTEXT] added:2026-02-01 expires:2026-03-01 · Context for a temporary task`

The retention policy is simple:

1
2
3

- 🔴 HIGH — Core knowledge, never expires, never archives
- 🟡 MED — Important knowledge, long-term retention, manually evaluate for staleness
- 🟢 LOW — Reference information, proactively add `expires:` field for system auto-cleanup

.archive/ cold storage design: Name the directory with a dot prefix. OpenClaw’s QMD vector engine automatically skips dot-prefixed directories, giving you zero-configuration hot/cold index separation. Archived files aren’t deleted — they remain directly accessible via the filesystem.

A simple weekly cron script handles cleanup: scan for expired expires: fields, move those entries into .archive/, and update INDEX.md accordingly.

Automatic Consolidation: Teaching Your Memory System to Digest

Good storage structure alone isn’t enough — if memories can’t auto-consolidate, it’s just a manually maintained folder.

Temporal annotation is key. Every memory entry must include time-relationship markers, solving the “no temporal reasoning” problem mentioned earlier:

“First appeared: …”
“Following previous X, today completed Y”
“N days since first discussion, status: completed”

Nightly consolidation (via cron): Set up a nightly cron job that calls your existing LLM API to:

Read today’s daily log (memory/YYYY-MM-DD.md)
Extract key decisions, lessons learned, and status changes
Promote important entries to long-term knowledge files (with proper YAML frontmatter)
Update NOW.md with tomorrow’s priorities
Update INDEX.md health dashboard

One easy pitfall here: always read the target file before writing, check whether similar content already exists, and avoid duplicate entries and memory conflicts (a.k.a. the HaluMem problem).

The Setup Checklist

Here’s everything you need to implement this architecture:

Three-layer file structure: NOW.md + memory/YYYY-MM-DD.md + structured subdirectories (lessons/, tools/, etc.)
INDEX.md: Knowledge base health dashboard, read on startup
Nightly cron job: Calls your existing LLM API for auto-consolidation
expires field + weekly cleanup script: Active forgetting mechanism
Built-in vector search: No extra deployment (OpenClaw ships with it)
SQLite triple table (optional): Only add if you genuinely need multi-hop relational reasoning

No extra resources needed — everything runs on what you already have.

Three Common Misconceptions

In practice, I’ve seen plenty of people stumble into these traps. Here are the three most common:

Misconception #1: More memory is always better. Quite the opposite — stale, low-quality memories are more dangerous than no memory at all. They masquerade as “facts” and skew the agent’s judgment. Forgetting mechanisms are just as important as writing mechanisms.

Misconception #2: Write-only, never read. Writing information into memory doesn’t mean the agent will use it. Serial Collapse — where agents gradually stop querying memory — is a real phenomenon. Regularly verifying that the agent actually uses its memory is as critical as building the memory system itself.

Misconception #3: Everything belongs in the knowledge graph. The value of a knowledge graph lies in relational reasoning, not storage. Daily preferences and operation logs are perfectly fine in Markdown — only knowledge that genuinely requires multi-hop reasoning deserves to be graphed.

Summary

A good memory system isn’t the one that stores the most — it’s the one that delivers the right information, in the right form, at the right moment.

Start with the three-layer architecture (NOW.md + daily logs + structured long-term files), add nightly auto-consolidation and a simple forgetting mechanism — for any individual user, this is more than enough, and it costs nothing beyond your existing LLM API. Add a SQLite triple table only when you genuinely need multi-hop relational reasoning.

Don’t overcomplicate it. The architecture above addresses all six fundamental flaws — and you can set it up in an afternoon.

You can also just copy this article to OpenClaw and let it set everything up for you.

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

五年了， JSON/V2 还是没有转正

Fri, 27 Feb 2026 21:50:53 +0800

五年了， JSON/V2 还是没有转正

2026 年 2 月 10 日，Go 1.26 重磅发布。Green Tea 垃圾回收器正式成为默认选项。go fix 工具经历了全面的现代化改造。cgo 调用开销降低了 30%。64 位平台迎来了堆地址随机化（Heap Address Randomization）安全增强。无论从哪个角度看，这都是一个里程碑式的版本。

然而，许多开发者翘首以盼的功能——encoding/json/v2——却明显缺席于稳定 API 之中。它依然躲在 GOEXPERIMENT=jsonv2 的实验性标志背后，尚未就绪。

我从Golang 1.25 就开始期待JSON/v2 了。五年的开发，居然还没完成？但如果你深入研究核心追踪议题 #76406 和相关提案 #71497，画面就变得清晰了：这种延迟不是工程效率的问题。它源于对 API 完美主义的执着追求、一场艰苦卓绝的向后兼容性攻坚战，以及一个几乎让整个项目脱轨的内存回退问题。

我们逐一拆解。

宏观视角：为什么 JSON V2 如此重要

当前的 encoding/json（我们姑且称之为 v1）已经忠实服务 Go 开发者超过十年。但它的设计缺陷一直在累积，就像一个从不重构的创业公司的技术债务。以下是主要问题清单：

它会默默接受无效的 UTF-8 JSON 字符串
它允许重复键名而毫无怨言
自定义 Marshaler 实现无法访问配置选项
没有办法拒绝有效 JSON 文档之后的多余数据
所谓的"流式"API 基本上是个幌子——底层实际上会缓冲所有内容

这些绝非小问题。在生产环境中，它们是安全攻击向量和静默数据损坏的风险源。符合 RFC 8259 标准？差得远呢。

由 Joe Tsai 和 Daniel Martí 领导的 JSON v2，是自泛型（Generics）落地以来最具雄心的标准库重写。它旨在修复上述所有问题——同时带来巨大的性能提升。

全新架构：语法层与语义层的分离

v2 最精妙的设计决策之一，是将 JSON 处理严格拆分为两层：

encoding/json/jsontext —— 语法层（Syntactic Layer）。负责纯粹的 JSON 标记化（Tokenizing）、解析和编码。无反射，不涉及 Go 类型。你可以把它理解为一个高性能 JSON 扫描器。
encoding/json/v2 —— 语义层（Semantic Layer）。基于 jsontext 构建，实现 Go 类型与 JSON 数据之间的映射。

这种分离的威力在于：如果你只需要验证或转换原始 JSON 而不涉及 Go 结构体，可以直接使用 jsontext——零反射开销、真正的流式处理、最小化内存分配。

以下是两个版本的对比：

维度	encoding/json (v1)	encoding/json/v2 (实验性)
架构	语法与语义耦合，重度依赖反射	清晰分离：`jsontext`（语法） + `v2`（语义）
流式处理	伪流式；底层往往需要全量缓冲	真正的流式编码与解码
默认安全性	接受无效 UTF-8，允许重复键名	拒绝无效 UTF-8，拒绝重复键名（符合 RFC 8259）
性能	基准	Unmarshal 最高提升 10 倍；Marshal 提升 1.6–3.6 倍
unsafe 使用	无	无——在不使用 `unsafe` 的前提下达到第三方库级别的性能

最后一行值得着重强调。像 Sonic（字节跳动）这样的库通过大量使用 unsafe 来实现极致速度。而 JSON v2 在不牺牲内存安全的前提下达到了同等性能水平。这就是标准库的承诺：你不需要用正确性换取速度。

为什么没有随 1.26 发布：四大阻碍

既然 v2 这么好，为什么不在 Go 1.26 中发布？追踪议题 #76406 揭示了四个截然不同的战场。

1. “永久 API” 约束

在 Go 的标准库哲学中，一旦 API 脱离实验阶段进入 encoding/json 路径，它就必须受到 Go 1 兼容性承诺的保护。永远如此，不可撤回。

Joe Tsai 对此态度明确：性能问题可以后续通过优化来解决，但 API 设计缺陷一旦固化，就会成为未来几十年的技术债务。

目前的审计重点集中在 jsontext 的公共接口。作为基础层，它的设计需要在高性能与易用性之间取得平衡——尤其是在 Token 处理以及与 io.Reader/io.Writer 的最佳交互模式上。

此外还有关于 time.Duration 的激烈争论。v1 将持续时间序列化为纳秒整数——虽然广泛使用，但跨语言互操作性极差。v2 倾向于采用 Go 风格的字符串如 "1h2m3s"，但这引发了关于标准化程度的热烈讨论。双方各执己见，API 签名悬而未决。

2. “完美兼容 json/v1

以下是 Go 团队的雄心壮志：一旦 v2 落地，他们希望只维护一套代码库。现有的 encoding/json 将变成 v2 引擎的一个薄包装层（Shim）。

问题在于：v2 引擎必须完美复刻 v1 的所有行为——包括 bug、未文档化的怪癖，以及成千上万生产应用无意中依赖的边缘情况。

例如，v1 在处理非寻址值（Non-addressable Values）的指针接收者 Marshaler 时存在特定的不一致性。许多现有应用在不知情的情况下已经依赖了这种行为。

在一个架构完全不同的引擎中复刻这些细微的、难以文档化的行为偏差，是一项极其艰巨的工程挑战。团队目前正在通过大规模测试逐步"烧除”（Burning Down）发现的每一个微小行为差异。进展稳步推进，但长尾效应依然明显。

3. 内存回退问题：Issue #75026

这是最令人警醒的阻碍。在 Go 1.25 和 1.26 的实验周期中，Issue #75026 报告了在特定 Map 序列化场景下灾难性的内存分配回退。

场景（Map 编码）	内存分配 (B/op) — v1 原生	内存分配 (B/op) — v2 实验	增幅
KeyCount: 10, ValLength: 1000	832	33,139	+3,883%

没有看错。一个常见的 Map 编码模式，内存分配量增加了 39 倍。

性能分析显示，92.98% 的内存分配集中在 bytes.growSlice 中，这表明新架构在处理复杂对象树或特定 Map 结构时存在严重的缓冲区管理缺陷。虽然总的分配次数（Allocs/op）实际上有所下降，但单次分配的体积暴增，给 GC 带来了巨大压力。

如果这种回退作为 v1 用户的默认行为发布，后果将是灾难性的。修复这些极端场景下的分配逻辑是目前最高优先级的工作。

4. 生态成熟度与联合类型之争

JSON v2 项目已经开发了五年。虽然已在许多生产环境中得到验证，但在成为默认标准之前，仍需经历更广泛的生态系统压力测试。Project 50 的追踪显示，44 个子任务中仍有约 18 个处于开放状态或需要进一步审计。

此外，关于 v2 是否应该支持 JSON 反序列化中的联合类型（Union Types / Sum Types），也引发了设计上的分歧。部分开发者认为这是现代 JSON 处理的标配功能。Go 团队的立场？等待语言层面的总和类型提案（如 #57644）成熟后再做集成，而不是在 JSON 包中塞入一个临时的、不兼容的实现。

这就是典型的 Go 式实用主义：不在库层面解决语言层面的问题。

值得等待的核心特性

尽管发布延迟，v2 的实验性版本已经展示了多项将从根本上改变 Go JSON 处理模式的特性。

`omitzero` —— 终于有了合理的省略逻辑

v1 的 omitempty 让开发者困惑了多年。time.Time{} 算空吗？false 算空吗？答案是不一致的，而且常常出人意料。

v2 引入了 omitzero，它严格按照 Go 的零值语义进行判断，并支持自定义 IsZero() bool 接口：

type Event struct {
    Name      string    `json:"name"`
    StartTime time.Time `json:"start_time,omitzero"`
    EndTime   time.Time `json:"end_time,omitzero"`
}

这对于 PATCH 风格的 API 尤其有用——你只需序列化那些被明确修改过的字段，而不会因为字段恰好持有类型的默认零值而意外忽略它们。

`inline` 和 `unknown` —— 灵活的数据建模

两个新的结构体标签解决了长期存在的痛点：

inline：将嵌套结构体或 Map 的内容"平铺"到父 JSON 对象中——无需匿名嵌入。对于包含动态键值对的 API 来说，这是一个巨大的改进。
unknown：指定一个字段（通常是 map[string]jsontext.Value）来捕获结构体中未定义的所有 JSON 成员。彻底告别"二次反序列化"的开销。

type Config struct {
    Version  int                          `json:"version"`
    Name     string                       `json:"name"`
    Extra    map[string]jsontext.Value    `json:",unknown"`
}

`format` —— 内置编码定制

format 选项支持按字段定制编码方式：

为 []byte 字段定制 Base64 或 Hex 编码
为 time.Time 使用自定义布局字符串
不再需要为常见格式化需求编写自定义 Marshaler/Unmarshaler 实现

性能：Benchmark 数据说话

基于 jsonbench 评估套件，以下是 v2 与竞品的对比：

库	Marshal 速度	Unmarshal 速度	内存安全性
JSON v1	基准	基准	高（无 unsafe）
JSON v2	提升 1.6–3.6 倍	提升 2.7–10.2 倍	高（无 unsafe）
Sonic（字节跳动）	与 v2 相当	极快（部分使用 unsafe）	中（大量使用 unsafe）
JSON-Iterator	慢于 v2	慢于 v2	中

关键洞察：v2 通过迭代式线性解析实现性能飞跃，而非 v1 的逐字节虚函数扫描模式。而且它没有使用一个 unsafe.Pointer。这不仅仅是快——这是负责任地快。

前路：v2 何时落地？

基于当前的任务处理速度和 #76406 上的开发者活跃度，以下是务实的时间线： 2026 年上半年：

修复 Issue #75026 —— 解决 Map 编码的内存回退问题。这是脱离实验阶段的唯一最关键前提。
API 定稿 —— 完成 jsontext 中所有公共函数的审计，特别是 Encoder/Decoder 在流式场景中的状态机健壮性。
v1 兼容层完善 —— 确保所有已知的 v1 行为（包括那些"有 bug 的"行为）在 v2 引擎中都有对应的配置选项支持。

Go 1.27（预计 2026 年 8 月）：

这被广泛认为是 JSON v2 移除实验性标签、进入稳定标准库的最早也是最可能的窗口。1.27 开发周期中代码树（Tree）的重新开放将是需要密切关注的关键信号。

Go 团队还计划在 v2 正式发布时同步推出现代化迁移工具。重新设计的 go fix 将支持从 v1 到 v2 默认配置的一键迁移——不只是简单的字符串替换，而是感知类型信息的智能转换。例如，它能检测到手动实现的 Base64 转换逻辑，并建议替换为 v2 的 format:base64 结构体标签。

总结

JSON v2 的延迟不是失败——而是纪律。 Go 团队拒绝发布一个存在设计缺陷的 API，因为在 Go 1 兼容性保证下，这些缺陷将永久存在。
架构设计是扎实的。 通过 jsontext 和 v2 实现的语法/语义分离是一种精妙且面向未来的设计。
性能已经得到验证。 Unmarshal 最高提升 10 倍，Marshal 提升 3.6 倍——全程不使用 unsafe。
内存回退（#75026）是关键阻碍。 Map 编码中 39 倍的分配增长必须在 v2 成为默认之前解决。
Go 1.27（2026 年 8 月）是目标。 社区应据此做好规划。

对开发者的实用建议：

内部工具：放心在非核心系统中尝试 GOEXPERIMENT=jsonv2。仅 omitzero 和 unknown 特性就能显著简化你的代码。提交 Bug 报告——团队需要它们。
性能敏感型应用：如果 JSON 反序列化是你的 CPU 瓶颈，v2 的实验版本可能已经优于 v1——而且比第三方 unsafe 库更安全。
公共组件库：目前继续使用 encoding/json（v1）。v2 的 API 仍有可能发生破坏性变更，你的用户不会欣赏这种不稳定性。

JSON v2 将是 Go 语言自泛型以来最重要的库级演进。它不仅让速度更快——更补全了 Go 在现代数据交换标准合规性上长达十年的缺口。随着阻碍一个接一个地被清除，一个更安全、更快速、更灵活的 JSON 处理时代即将随 Go 1.27 到来。

等待即将结束。而且，值得。

参考资料：

Go Issue #76406 — JSON v2 追踪议题
Go Proposal #71497 — encoding/json/v2 提案
Go Issue #75026 — jsonv2 实验中的内存分配回退
Go Issue #57644 — 总和类型语言提案
Go 1.26 Release Notes

10 Quiet Side Projects Making Real Money in 2025

Thu, 25 Dec 2025 09:53:08 +0800

While everyone on Twitter is chasing the next AI wrapper or prompt marketplace, a post on Hacker News asked a much more grounded question:

If you’re making more than $500/month from a side project in 2025, what are you building?

The answers were refreshing.

No hype.
No “AI will change everything” slogans.
Just small, specific problems solved well—often in niches most of us never think about.

I picked 10 of the most interesting projects from that thread.
If you’re feeling burned out by endless AI discourse, this might help reset your brain.

1. A Printable “Escape Room” You Can Play at Home

Instead of building a physical escape room, this project sells downloadable PDF escape games.

Users buy a script, print it, cut it out, and use a companion app to play puzzles at home—perfect for parties or family gatherings.

MRR: ~$1,000
Website: https://www.escape-team.com/
Why it works:
Digital distribution + physical interaction = low cost, high perceived value.

2. Managing Xbox Consoles in Children’s Hospitals

A children’s hospital wanted an Xbox in every room—but managing dozens of consoles manually was a nightmare.
This project built a centralized admin system to configure, update, and manage all consoles remotely.

MRR: ~$6,000
Website: https://coplay.io/

Why it works:
A painfully specific enterprise problem, with a buyer who really needs a solution.

3. One-Off Online Fax (Yes, Fax)

Sometimes you just need to send one fax. Not a subscription. Not an account.

This service does exactly that: upload → pay → send.

MRR: ~$500
Website: https://justfaxonline.com/en/

Why it works:
It monetizes inconvenience. And faxing is still inconvenient.

4. Duplicate Photo Finder for macOS

A macOS app that detects duplicate and visually similar images—handy for photographers with massive local libraries.

Paid users: 100+
Website: https://maheepk.net/projects/dedupx/

Why it works:
Local storage is exploding. Cleanup tools age very well.

5. GPS-Based Check-In for Teams and Classes

Teachers, coaches, or team leads set a location and time. Participants must physically be there to check in—verified by GPS.

MRR: ~€500
Website: https://www.youhere.org/index.php/start/

Why it works:
It replaces paper sign-ins with proof, not trust.

6. Practicing Cold Calls by Actually Making Calls

Most sales practice tools simulate calls on screen.

This one actually dials your phone and connects you to an AI, forcing you to practice under real conditions.

MRR: ~$500
Website: https://coldcallgym.com/

Why it works:
Fear reduction through exposure—not theory.

7. Paying Your Kids to Save on Taxes

Parents log their kids’ work (filing, photos, admin tasks), treat it as a legitimate business expense, and route income into tax-advantaged accounts like a Roth IRA.

MRR: ~$500
Website: https://trypixie.com/#how-it-works
Why it works:
It turns tax optimization into a family financial strategy.

8. Turn Photos Into Printable Coloring Pages

Upload a photo of your pet, child, or vacation—get a clean black-and-white coloring page ready to print.

Website: https://dreamandcolor.com/
Why it works:
Personalization beats stock content every time.

9. Tracking Hard Drive Prices on eBay

This project scrapes eBay listings for disks and memory cards, parsing titles with 200+ regex rules, then monetizes via affiliate links.

MRR: $400–$600
Websites:
https://unli.xyz/digitalfilmstock/
https://unli.xyz/diskprices/

Why it works:
Data cleaning is painful. If you do it once, others will pay.

10. A Daily Logic Puzzle (No Ads)

Each day has a new puzzle: easy on Monday, brutal on Sunday. Revenue comes from selling puzzle packs, not ads.

Website: https://cluesbysam.com/
Why it works:
Habit + ownership beats ad-driven distraction.

The Real Pattern Here

None of these projects are “sexy”.
But they all share something powerful:

A very specific audience
A clear, painful problem
Simple pricing
No dependence on hype cycles

In a world obsessed with AI, these projects quietly remind us:

Making money is often about reducing friction, not inventing the future.

If you want to build something sustainable, maybe don’t ask
“What’s the next big thing?”
Ask instead:

“What’s an annoying problem people already tolerate?”

Source discussion:
https://news.ycombinator.com/item?id=46307973

Why the Flask Creator Ditched Python for Go in His AI Startup

Fri, 24 Oct 2025 00:00:00 +0000

Introduction: A Python Icon’s “Betrayal”

Armin Ronacher, creator of Flask—one of Python’s most beloved web frameworks—is a household name in the Python community. For years, he’s been a standout contributor to Python’s ecosystem, with his career deeply intertwined with the language. Yet when launching his AI startup, he made a surprising decision: the company’s core backend services wouldn’t use Python, the reigning champion of AI, but Go instead.

This choice raises a fundamental question: Why would a top-tier Python expert “betray” his preferred language in an AI project where Python should dominate? This isn’t just a technical decision—it’s the result of an internal struggle between two identities: the “Swiss watchmaker” who pursues code perfection and the pragmatic founder focused on shipping products. This article explores how Armin Ronacher balances these personas and how AI-era tech companies should rethink their technology stack decisions.

1. Reconsidering Python: AI’s King with Hidden Concerns

Python’s dominance in today’s tech landscape seems unshakeable, especially in AI. However, every technology choice involves tradeoffs, and even Python isn’t the best answer in every scenario.

Python’s Absolute Strengths

First, we must acknowledge that no company can completely avoid Python. Armin Ronacher explicitly states that whether you like it or not, Python will be part of your stack. Its position in these domains is irreplaceable:

Machine Learning (ML): Core for AI inference and data processing tasks.
Data Processing: Unmatched data science ecosystem.
Infrastructure Management: For example, Armin uses Pulumi with Python to build his company’s infrastructure.

As the “glue” in the ecosystem and the data science engine, Python’s value is undeniable. Even for network-intensive tasks like AI inference, performance bottlenecks typically lie in networking rather than the language itself, making Python an excellent choice.

The Tradeoff for Core Services

Despite Python’s ubiquity, Armin believes it shouldn’t be used to build his new company’s primary services. This consideration isn’t rooted in performance bias but stems from deeper insights into language complexity and ecosystem strengths.

Growing Complexity: Armin observes that Python itself is becoming increasingly complex. In contrast, Go has maintained relative simplicity since inception. This matters because for an engineering team that needs rapid iteration and collaboration, Go might be “an easier language to write.”
Ecosystem Specialization: Technology choices aren’t just about what a language can do, but what its ecosystem is good at. Armin explicitly states he’s abandoning Python not for performance reasons, but because of “what the ecosystem is good at.” While Python is fully capable of handling email parsing (one of Armin’s company’s core businesses), this isn’t where its ecosystem naturally excels. Compared to Go, it’s not the “chosen one” for building this type of scaled core service.

These nuanced considerations led Armin to look toward another language, naturally bringing us to the discussion of Go.

2. Embracing Go: The Pragmatist’s Victory

If choosing technology is an art, then for startups, the core of this art is pragmatism. Armin Ronacher’s choice of Go perfectly embodies this philosophy. Go isn’t the most “sexy” or feature-rich language, but in specific scenarios, it’s the most pragmatic, most suitable tool.

Here are Go’s core advantages that made it stand out:

Built for Web Services: Go is clearly positioned as “an excellent language for building web services” with intense focus (“really kind of only web services”), plus some CLI tool building capability. This focus makes it exceptionally performant in its target domain.
Extreme Pragmatism: This is Armin’s primary reason for choosing Go. He emphasizes Go’s “very pragmatic language features,” a crucial quality for startups that need to focus on products, ship quickly, and reduce unnecessary technical friction.
Ecosystem Stability: For long-term projects, technology longevity is a key consideration. Armin believes Go can be “expected to stick around.” Even if Google stopped maintaining it someday, the massive community and industry users have enough strength and willingness to sustain its vitality, providing solid guarantees for projects.
The Pragmatic Landing Point After Avoiding Python Scaling Concerns and Rust Development Friction: After weighing options, Go became an ideal pragmatic choice. It avoids both Python’s ecosystem fit issues when building certain types of core services and Rust’s steep learning curve and high development “friction,” making it the best choice for a “founder.”

To understand this decision more clearly, we need a horizontal comparison of these languages to see their roles in different scenarios.

3. Horizontal Comparison: Go vs. Rust vs. Python Use Cases

Armin Ronacher houses “two programmers” within himself: one is the “Swiss watchmaker” pursuing code perfection, usually thriving in the open-source world; the other is the company founder focused on product delivery, making all decisions with pragmatism first. From the latter’s perspective, he made a clear distinction between Go, Rust, and Python’s applicable scenarios.

Python: The Ubiquitous “Glue” and Data Science Engine

Role: Python is the universal “glue” in the ecosystem and the undisputed default choice for data processing and machine learning.
Advantages: Most powerful library ecosystem, supports rapid prototyping and iteration. In network-intensive tasks like AI inference, the language’s performance bottleneck isn’t prominent.
Tradeoffs: The language’s inherent complexity is increasing, and for certain types of core services, it may not be the most natural, direct choice.

Rust: The “Swiss Watch” for “Rust-Shaped Problems”

Role: Rust is the expert-level language for solving specific “Rust-shaped problems,” such as handling binary data, building databases, load balancers, or high-performance Python extension modules.
Advantages: Memory safety, predictable performance without garbage collection (GC), excellent as Python extensions.
Tradeoffs (for Startups): Extremely high development “friction.” This includes “incredibly slow” compilation speeds and the steep learning curve of ownership and borrow checking. This makes it highly unsuitable for environments requiring rapid iteration and flexible adjustments.

Go: The Pragmatic, Focused Web Service Builder

Role: Go is the pragmatic choice for building web services and CLI tools, a focused service-building specialist.
Advantages: Simple language, easy for teams to learn and master, stable ecosystem, excellent performance in high-concurrency service scenarios.
Tradeoffs: Its applicable domain is relatively focused, lacking Python’s “jack-of-all-trades” versatility.

Notably, Armin also explicitly ruled out using TypeScript/JavaScript for core backend services. Despite its increasingly mature language environment, he’s reserved about the npm ecosystem, stating bluntly: “I feel like in the JavaScript ecosystem, I can barely build efficiently without introducing 500+ dependencies, which makes me uncomfortable.”

Traditional language selection considerations are now very clear. However, AI’s rise introduces a new, potentially disruptive decision dimension.

4. The New Deciding Factor: AI Agent Code Generation Quality

The rise of AI programming assistants is fundamentally changing software development paradigms, and the underlying logic of technology selection is shifting accordingly. Armin Ronacher, as an entrepreneur heavily relying on AI-assisted coding (which he calls his “army of interns”), discovered a striking fact: AI Agent code generation quality has become an unavoidable consideration.

He reached a clear conclusion from practice:

“I did actual testing… I found that AI Agents perform much better on Go than on Python.”

Why? The reason lies in the language’s design philosophy. Armin explains: “Because the abstractions are very thin, it (AI) can understand the code better.” Go’s simplicity and directness make its structure easier for large language models to understand and generate, resulting in more reliable, more correct code.

This discovery is significant for a team heavily dependent on AI. When your “army of interns” is more efficient and makes fewer errors with a particular language, choosing that language isn’t just a technical preference—it directly impacts the entire team’s productivity.

Conclusion: No Best Language, Only the Right Choice

Armin Ronacher’s abandonment of Python for Go isn’t a rejection of Python, but rather a highly pragmatic tradeoff made in a new technical paradigm, based on a specific startup context (AI company, rapid iteration, small team collaboration).

His decision logic can be summarized as follows:

Pragmatism Above All: For startups, product success matters far more than “meticulously crafted” code. Choosing tools with less friction and more focus on solving core problems is wise.
The Art of Tradeoffs: Among language simplicity (easy for teams to master), ecosystem maturity, performance, and development efficiency, Go provides an excellent balance point.
Embracing New Paradigms: Incorporating AI code generation quality into core technology selection considerations reflects adaptation to changing times. A language’s friendliness to AI is becoming a new, critical productivity metric.

Ultimately, Armin’s story brings a profound insight to all technical decision-makers: we must continuously reevaluate our toolbox and courageously make the most suitable, most pragmatic choices based on current project needs and emerging technology waves.

Article Summary

Flask creator Armin Ronacher chose Go over Python for core services in his new AI startup. This decision doesn’t negate Python but stems from a startup’s extreme pursuit of pragmatism, simplicity, and team efficiency. He views Go as the pragmatic choice after avoiding Rust’s development friction and Python’s ecosystem specialization limitations. More critically, he discovered that AI Agents generate far better Go code than Python—a decisive new factor in the AI-assisted programming era.

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

Playing Snake in Your Browser's Address Bar: When the Internet Was Still Fun

Thu, 02 Oct 2025 17:21:30 +0800

Open Chrome, type https://demian.ferrei.ro/snake# into the address bar, and you’ll suddenly see a string of strange characters.
Yes, you read that right. Keep your eyes on the address bar and control the direction with the arrow keys or WASD.

You’ll see a little snake made of odd-looking symbols (░░░░░░░⠠⠤⠄⡀░░) crawling around inside the address bar, eating food, and growing longer. The entire game plays out inside that thin text field you usually only use to type URLs.

That’s right — this is a fully functional Snake game running entirely inside the browser’s URL bar.

Last week, this decade-old project suddenly blew up on Hacker News, racking up 840 upvotes and hundreds of comments. The first reaction from many people was: “This is insane. How did you even come up with this?”

But the story behind this game is even crazier — and it reveals something important about what the modern internet has lost.

A Random Curiosity Sparks a Technical Adventure

The creator, Francisco Uzo, recalls the project’s origins: “I just wanted to understand how the Braille system worked.”

That’s the essence of hacker culture — not solving a problem, but chasing pure curiosity.

As he dug into Braille, he noticed something fascinating: each Braille symbol is a 2x4 dot matrix, eight positions in total, each either “raised” or “flat.” That gives 2^8 = 256 possible combinations. And Unicode happens to support all 256 Braille characters.

One night around 3 a.m., it hit him: “Wait, this is basically an 8-bit pixel character set!”

That spark — when two unrelated ideas suddenly connect — is exactly the kind of joy hackers live for.

And then came the classic hacker instinct: don’t ask whether it’s useful — just build it.

The implementation was full of clever hacks:

Mapping the game world onto Braille character grids, each character acting as a 2x4 pixel block
Using solid dots (⣿) for the snake’s body and blank Braille (⠀) for empty space
Leveraging JavaScript’s history.replaceState() API to update the URL in real time without polluting the history
Refreshing the entire frame each tick so the game animates smoothly inside the address bar

Francisco’s openness was just as “hacker-ish”: “The source code isn’t minified or obfuscated. Just hit Ctrl+U and you’ll see everything.”

The whole thing was only a few hundred lines of JavaScript — concise, readable, and elegant. In the hacker mindset, code isn’t just for execution — it should also be legible, learnable, and inspiring.

Wait… Why Does My Game Look Broken?

If you try the game today, you might just see a mess of %20, backslashes, and gibberish. The snake barely moves — or sometimes the game doesn’t run at all.

It’s not your fault. It’s not even the code’s fault. The browser has changed.

Francisco admitted, “This project was written for browsers ten years ago. Since then, browsers have made certain ‘security improvements’ that severely limit what’s possible in the URL bar.”

The most critical change? Modern browsers now forcefully escape all spaces in URLs.

In the game’s design, the blank Braille character (⠀) represented empty space. However, browsers now escape those characters as %20 or something else, which ruins the visual output.

Francisco even built a fallback system that measured text widths via Canvas and replaced escaped characters on the fly — but it only worked partially.

He appealed to browser bug trackers. Developers sympathized but ultimately concluded: “As always, security outweighs fun.”

As a result, users’ experiences varied wildly:

Some people on Chrome scored over 2,000 points.
Others saw a screen full of garbage in Firefox.
On iOS Safari, the game sometimes didn’t even render
Some users found their browsing history polluted with every single game frame.

The same code, drastically different behavior across browsers. That’s just the reality of modern web development.

The Golden Age of “Weird Browser Games”

Snake in the address bar wasn’t the only project of its kind. The Hacker News discussion turned into a nostalgia trip, with people recalling a whole wave of unconventional browser experiments.

2048 In the URL

Someone linked to https://aquova.net/games/2048/ — a port of the once-famous puzzle game, implemented entirely inside the address bar using the same Braille and URL-refresh trick.

Snake In the Browser Tab Title

Francisco mentioned that someone on Reddit made a version that runs inside the tab’s title instead. It was basically a compromise — no longer in the address bar, but safe from URL escaping.

TinyJS Snake

In 2023, another developer built a similar Snake clone using a different technique. At the time, browser restrictions weren’t as strict.

3D Worlds in the URL

Another project took things further: an interactive 3D environment rendered through unconventional browser features.
One commenter joked: “It’s not Doom, but you can walk around in 3D.”

What do all these have in common? They were built for fun, out of curiosity, with no concern for practicality.

No commercial value. No business use case. Not even “best practices.”
But they embodied the spirit of the early web: a playground where people could experiment, push boundaries, and have fun.

Why Are Projects Like This So Hard Now?

It’s not just the space escaping problem. Over the past decade, browsers have introduced countless so-called security improvements:

History API Limits

Francisco originally used history.replaceState() to update the URL without spamming history entries. Modern browsers now throttle calls to this API, forcing fallback to location.hash — which clutters your browsing history with every frame of gameplay.

URL Length Restrictions

Different browsers cap URL length anywhere from 2,000 to tens of thousands of characters. Encoding game state into URLs quickly hits those ceilings.

Character Set Restrictions

More and more Unicode characters are marked as “unsafe” for URLs. Browsers escape or block them, killing Unicode art projects outright.

Mobile Compatibility

Many mobile browsers hide the URL bar entirely while scrolling — making address-bar games literally unplayable.

Francisco summed it up: “Every browser change since then has made projects like this harder. I got some sympathy in bug trackers, but security always wins.”

When Security Kills the Fun

Here’s the fundamental tension:

Nobody disputes the importance of browser security.
URL injection attacks, XSS vulnerabilities, phishing — these are real threats affecting billions of users. Browser developers have a duty to protect people.

But every “security improvement” quietly closes off a door to creativity.

Francisco’s code worked flawlessly a decade ago. Today, it’s broken not because it was bad, but because the browser “evolved.” That evolution made the web safer — but also more controlled, more uniform, and frankly… more boring.

It’s Not Just About Games

One Hacker News commenter sneered: “Why don’t people build something useful instead of abusing the internet?”

The community overwhelmingly pushed back:

“The learning value from projects like this is massive.”
“Creative play matters for skill development too.”
“This is exactly why I come to HN — 100% hacker spirit.”
“ChatGPT couldn’t have come up with this. I love the creativity.”

The best response was simple:
“To most people, this is nothing. To me, it’s insane. How did you even think of this?”

That’s the point. The value of projects like this isn’t in utility, but in pure human creativity — driven by curiosity, joy, and the urge to ask “why not?”

And every time we “tighten security,” we don’t just close loopholes. We also close off avenues for wonder.

Trade-offs Are Necessary, But We Should Acknowledge the Cost

This isn’t about blaming browser developers. They face incredibly difficult trade-offs:

Allow flexible URL encoding vs. prevent injection attacks
Support high-frequency API calls vs. avoid performance issues
Display arbitrary Unicode characters vs. prevent phishing scams

There’s no perfect answer. Every decision has its cost.

But we should at least be aware of and discuss these costs. When we say “security first,” we should ask: “What are we losing because of this?” When we say “user experience optimization,” we should ask: “Whose experience are we optimizing for?”

Francisco’s response from browser bug trackers was typical: “I understand your frustration, but security must come first.” This answer is technically unassailable, but it also represents a broader trend: on the modern internet, control and security are systematically overwhelming creativity and fun.

In the Age of AI, Human Creativity Matters More

When asked about AI, Francisco said something striking:

“This game has been online for ten years. It’s probably in AI training data. A robot might be able to replicate it, but it could never enjoy it. (At least not yet.)”

That gets to the heart of our cultural anxiety today. In an era where ChatGPT can generate code in seconds and Copilot can autocomplete whole functions — what projects are still worth building by hand?

The answer might just lie in this Snake game.

AI can parse Braille characters, understand Unicode, and spit out JavaScript. But AI can’t feel:

The 3 a.m. epiphany that “Braille could be pixels”
the giddy surprise of watching a snake slither inside a URL bar for the first time
The stubborn joy of debugging escape sequences for hours
The quiet pride of seeing strangers enjoy your work a decade later

These are uniquely human creative experiences.
In a world where AI can replicate almost all code, that human spark is more precious than ever.

Francisco’s project wasn’t created to solve a problem — it was created for exploration and fun. That motivation, that process, that pure creative joy — that’s something AI can never truly possess.

We Need More Projects Like This

Snake in the URL bar went viral, not because it’s useful or profitable, but because it reminded us of something essential:

The internet shouldn’t just be efficient, safe, and standardized. It should also be surprising, playful, and experimental.

When Francisco asked himself, “How does Braille work?” ten years ago, he wasn’t solving a business problem or optimizing UX. He was just curious. That curiosity created something that made thousands of strangers smile.

In today’s increasingly homogeneous, “safe,” and algorithmically optimized internet, we need more of this. Not because it’s useful, but because it reminds us:

Technology isn’t only about efficiency and safety — it should also be about wonder and joy.

So, how many points can you score? Does your browser even support it?

Or maybe the real question is: what’s the last “useless but fun” project you built?

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

Playing Snake in Your Browser’s Address Bar: When the Internet Was Still Fun

Thu, 02 Oct 2025 17:21:30 +0800

That’s right — this is a fully functional Snake game running entirely inside the browser’s URL bar.

But the story behind this game is even crazier — and it reveals something important about what the modern internet has lost.

A Random Curiosity Sparks a Technical Adventure

The creator, Francisco Uzo, recalls the project’s origins: “I just wanted to understand how the Braille system worked.”

That’s the essence of hacker culture — not solving a problem, but chasing pure curiosity.

One night around 3 a.m., it hit him: “Wait, this is basically an 8-bit pixel character set!”

That spark — when two unrelated ideas suddenly connect — is exactly the kind of joy hackers live for.

And then came the classic hacker instinct: don’t ask whether it’s useful — just build it.

The implementation was full of clever hacks:

Mapping the game world onto Braille character grids, each character acting as a 2x4 pixel block
Using solid dots (⣿) for the snake’s body and blank Braille (⠀) for empty space
Leveraging JavaScript’s history.replaceState() API to update the URL in real time without polluting the history
Refreshing the entire frame each tick so the game animates smoothly inside the address bar

Francisco’s openness was just as “hacker-ish”: “The source code isn’t minified or obfuscated. Just hit Ctrl+U and you’ll see everything.”

Wait… Why Does My Game Look Broken?

If you try the game today, you might just see a mess of %20, backslashes, and gibberish. The snake barely moves — or sometimes the game doesn’t run at all.

It’s not your fault. It’s not even the code’s fault. The browser has changed.

The most critical change? Modern browsers now forcefully escape all spaces in URLs.

In the game’s design, the blank Braille character (⠀) represented empty space. However, browsers now escape those characters as %20 or something else, which ruins the visual output.

Francisco even built a fallback system that measured text widths via Canvas and replaced escaped characters on the fly — but it only worked partially.

He appealed to browser bug trackers. Developers sympathized but ultimately concluded: “As always, security outweighs fun.”

As a result, users’ experiences varied wildly:

Some people on Chrome scored over 2,000 points.
Others saw a screen full of garbage in Firefox.
On iOS Safari, the game sometimes didn’t even render
Some users found their browsing history polluted with every single game frame.

The same code, drastically different behavior across browsers. That’s just the reality of modern web development.

The Golden Age of “Weird Browser Games”

Snake in the address bar wasn’t the only project of its kind. The Hacker News discussion turned into a nostalgia trip, with people recalling a whole wave of unconventional browser experiments.

2048 In the URL

Someone linked to https://aquova.net/games/2048/ — a port of the once-famous puzzle game, implemented entirely inside the address bar using the same Braille and URL-refresh trick.

Snake In the Browser Tab Title

Francisco mentioned that someone on Reddit made a version that runs inside the tab’s title instead. It was basically a compromise — no longer in the address bar, but safe from URL escaping.

TinyJS Snake

In 2023, another developer built a similar Snake clone using a different technique. At the time, browser restrictions weren’t as strict.

3D Worlds in the URL

Another project took things further: an interactive 3D environment rendered through unconventional browser features.
One commenter joked: “It’s not Doom, but you can walk around in 3D.”

What do all these have in common? They were built for fun, out of curiosity, with no concern for practicality.

No commercial value. No business use case. Not even “best practices.”
But they embodied the spirit of the early web: a playground where people could experiment, push boundaries, and have fun.

Why Are Projects Like This So Hard Now?

It’s not just the space escaping problem. Over the past decade, browsers have introduced countless so-called security improvements:

History API Limits

URL Length Restrictions

Different browsers cap URL length anywhere from 2,000 to tens of thousands of characters. Encoding game state into URLs quickly hits those ceilings.

Character Set Restrictions

More and more Unicode characters are marked as “unsafe” for URLs. Browsers escape or block them, killing Unicode art projects outright.

Mobile Compatibility

Many mobile browsers hide the URL bar entirely while scrolling — making address-bar games literally unplayable.

Francisco summed it up: “Every browser change since then has made projects like this harder. I got some sympathy in bug trackers, but security always wins.”

When Security Kills the Fun

Here’s the fundamental tension:

But every “security improvement” quietly closes off a door to creativity.

It’s Not Just About Games

One Hacker News commenter sneered: “Why don’t people build something useful instead of abusing the internet?”

The community overwhelmingly pushed back:

“The learning value from projects like this is massive.”
“Creative play matters for skill development too.”
“This is exactly why I come to HN — 100% hacker spirit.”
“ChatGPT couldn’t have come up with this. I love the creativity.”

The best response was simple:
“To most people, this is nothing. To me, it’s insane. How did you even think of this?”

That’s the point. The value of projects like this isn’t in utility, but in pure human creativity — driven by curiosity, joy, and the urge to ask “why not?”

And every time we “tighten security,” we don’t just close loopholes. We also close off avenues for wonder.

In the Age of AI, Human Creativity Matters More

When asked about AI, Francisco said something striking:

“This game has been online for ten years. It’s probably in AI training data. A robot might be able to replicate it, but it could never enjoy it. (At least not yet.)”

The answer might just lie in this Snake game.

AI can parse Braille characters, understand Unicode, and spit out JavaScript. But AI can’t feel:

The 3 a.m. epiphany that “Braille could be pixels”
the giddy surprise of watching a snake slither inside a URL bar for the first time
The stubborn joy of debugging escape sequences for hours
The quiet pride of seeing strangers enjoy your work a decade later

These are uniquely human creative experiences.
In a world where AI can replicate almost all code, that human spark is more precious than ever.

We Need More Projects Like This

Snake in the URL bar went viral, not because it’s useful or profitable, but because it reminded us of something essential:

The internet shouldn’t just be efficient, safe, and standardized. It should also be surprising, playful, and experimental.

In today’s increasingly homogeneous, “safe,” and algorithmically optimized internet, we need more of this. Not because it’s useful, but because it reminds us:

Technology isn’t only about efficiency and safety — it should also be about wonder and joy.

So, how many points can you score? Does your browser even support it?

Or maybe the real question is: what’s the last “useless but fun” project you built?

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

Official discussions readdress error handling: Why has the new syntax been delayed?

Wed, 04 Jun 2025 20:34:41 +0800

Go Officials Revisit Error Handling — Why the New Syntax Is Still Stuck

Recently, the official Go blog published a post titled On | No syntactic support for error handling. Contrary to the community’s anticipation for a breakthrough in syntax, the article took a step back—revisiting Go’s long and rocky history of failed attempts to simplify error handling.

So, why did the Go team choose to publish this now?

Why Does the Go Team Keep Revisiting Error Handling?

Since its inception, Go has been celebrated for its simplicity and clarity. But one area has always stood out as a sore spot: error handling is verbose and repetitive.

Here’s the familiar Go pattern we’ve all seen:

func printSum(a, b string) error {
    x, err := strconv.Atoi(a)
    if err != nil {
        return err
    }
    y, err := strconv.Atoi(b)
    if err != nil {
        return err
    }
    fmt.Println("result:", x + y)
    return nil
}

The repeated if err != nil blocks often feel mechanical and boilerplate. Over the years, the Go team has made multiple attempts to design a cleaner syntax—but each one has failed to gain enough traction for implementation.

Failed Attempts That Once Held Promise

Here are a few notable proposals that stirred hope but never made it into the language:

2018: check and handle
Introduced new keywords to reduce error handling verbosity, but were eventually rejected due to concerns about added complexity.
2019: try
Proposed a built-in try() function to handle errors more concisely. The community pushed back, citing it as “too implicit” and against Go’s design philosophy.
2024: The ? Operator Inspired by Rust
Ian Lance Taylor suggested borrowing Rust’s ? operator to reduce boilerplate (proposal #71203). Once again, the community responded with strong opposition.

I also wrote a blog post about it.

Each failed proposal reveals more than just technical challenges. They reflect a deep-rooted cultural norm in the Go community:
“Clarity is better than cleverness.”

What’s The Real Message Behind This Blog Post?

If you read between the lines, you’ll see this blog isn’t just a retrospective—it’s a strategic response to the growing noise in the community:

“Do we need new syntax for error handling?”

The post sends a subtle but critical signal:

The question isn’t just about syntax. It’s about the philosophy of the language itself.

Go’s team isn’t aiming to push a new solution just yet. Instead, they want to steer the community back to first principles—asking:

What kind of language do we truly want Go to be?

“Explicit Is Better Than Implicit” — A Principle Go Won’t Let Go

Go’s strength lies in its unambiguous, explicit nature. Every new syntax proposal must pass a rigorous checklist:

Does it preserve clarity?
Does the benefit justify the added complexity?
What unintended side effects might it introduce?

These principles make every proposal an uphill battle—and explain why so many attempts have been shut down before reaching their intended conclusion.

So, Where Does This Leave Us?

Another key takeaway from the blog post is this:

The Go team has come to terms with the reality that a new error-handling syntax isn’t coming anytime soon.

That doesn’t mean it’s impossible—just that the right solution hasn’t been found. The Go team is signaling: the door remains open, but more experimentation, real-world feedback, and reflection are needed.

In the meantime, Go developers will need to live with the existing pattern. But that also means Go will continue to be what it’s always been: explicit, transparent, and devoid of magic.

This blog post might look like a historical reflection, even an admission of past failures—but it’s really a catalyst. A challenge to the community:

What do we truly want Go to become?
How much clarity are we willing to trade for convenience?

You may disagree with the current state of affairs. But it’s hard to deny that this kind of introspection is essential for the health of any programming language.

Yes, the following proposal might fail again.
Or the community may one day strike the perfect balance.

What’s certain is this:

The Go community is still thinking, still debating—and still evolving.

Original blog post →

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

Go Action Managing Go Application Lifecycles in Kubernetes

Mon, 02 Jun 2025 17:45:34 +0800

This article explores best practices for developing Go applications in Kubernetes, focusing on the different stages of a Pod’s lifecycle and the role of Kubernetes termination signals. Properly managing these phases ensures smooth application shutdowns, preventing data loss or disruptions to user experience. By mastering lifecycle management, teams can efficiently handle updates and workload adjustments.

The Three Phases of an Application’s Lifecycle

Application Startup
Application Runtime
Application Shutdown

Each phase requires careful attention to ensure everything proceeds as expected. While most teams focus solely on runtime, managing all three phases in Kubernetes is equally critical.

1. Application Startup

In Kubernetes, a Pod is considered ready when all its containers are prepared to accept requests. This readiness is determined using readiness probes and readiness gates.

The Role of Readiness Probes

A readiness probe signals whether a service is ready to handle traffic. It periodically checks the application’s state to confirm availability. Here’s an example of a readiness probe definition:

readinessProbe:
  httpGet:
    scheme: HTTP
    path: /ready
    port: service
  timeoutSeconds: 2
  periodSeconds: 60

Key Parameters:
• timeoutSeconds: Maximum time allowed for the probe to respond.
• periodSeconds: Frequency at which the probe is executed.

2. Application Runtime

During runtime, liveness and readiness probes monitor the service’s health. The liveness probe, in particular, detects deadlocks and determines whether a container should be restarted.

Example Liveness Probe

livenessProbe:
  httpGet:
    scheme: HTTP
    path: /health
    port: service
  timeoutSeconds: 1
  periodSeconds: 30
  initialDelaySeconds: 60

Important Considerations:
• Ensure probes respond quickly to avoid unnecessary restarts due to temporary load spikes.
• Avoid coupling probes with external service dependencies—a single failure shouldn’t trigger cascading restarts.

3. Application Shutdown

The shutdown phase involves gracefully terminating a Pod. Kubernetes manages this by sending SIGTERM followed by SIGKILL if necessary.

Graceful Shutdown in Go

Here’s an example of handling graceful shutdowns in a Go application:

func main() {
    // Step 1: Startup
    startService := time.Now()
    ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM)
    defer stop()

    logger := zerolog.New(os.Stdout).With().Str("service", ServiceName).Timestamp().Logger()
    
    config, err := NewConfig()
    if err != nil {
        logger.Fatal().Err(err).Msg("Unable to setup config")
    }

    mux := http.NewServeMux()
    mux.HandleFunc("/health", healthHandler(logger))
    mux.HandleFunc("/ready", readyHandler(logger))
    mux.HandleFunc("/task", taskHandler(logger))

    server := &http.Server{
        Addr:         ":" + config.ServicePort,
        Handler:      recovery(http.TimeoutHandler(mux, config.HandlerTimeout, fmt.Sprintf("server timed out, request exceeded %s\n", config.HandlerTimeout)), logger),
        ErrorLog:     log.New(logger, "", log.LstdFlags),
        ReadTimeout:  config.ReadTimeout,
        WriteTimeout: config.WriteTimeout,
    }

    waitGroup := &sync.WaitGroup{}
    
    // Run HTTP server
    waitGroup.Add(1)
    go func() {
        defer waitGroup.Done()
        errListen := server.ListenAndServe()
        if err != nil && !errors.Is(errListen, http.ErrServerClosed) {
            logger.Fatal().Err(errListen).Msg("server.ListenAndServe error")
        }
    }()

    go func() {
        <-ctx.Done()
        logger.Info().Msg("HTTP server cancelled")
        timeoutCtx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
        defer cancel()
        errShutdown := server.Shutdown(timeoutCtx)
        if errShutdown != nil {
            logger.Error().Err(errShutdown).Msg("server.Shutdown error")
        }
    }()

    waitGroup.Add(1)
    go performTask(ctx, waitGroup, logger)

    logger.Info().Dur("duration", time.Since(startService)).Msg("Service started successfully")
    runningService := time.Now()

    // Step 2: Runtime
    <-ctx.Done()
    stop()

    // Step 3: Shutdown
    logger.Info().Dur("duration", time.Since(runningService)).Msg("Gracefully shutting down service...")
    startGracefullyShuttingDown := time.Now()
    waitGroup.Wait()
    logger.Info().Dur("duration", time.Since(startGracefullyShuttingDown)).Msg("Shutdown service complete")
}

Key Takeaways

• Design for failure—applications must withstand underlying software or hardware failures.
• Graceful degradation and eventual consistency improve reliability and availability.
• Proper use of probes and shutdown mechanisms ensures stable and efficient management of Go applications in Kubernetes.

Developers can build resilient systems that handle disruptions seamlessly by implementing these best practices. 🚀

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

Why Did Go's Map Get Slower? Let's See How Go 1.25 Plans to Fix It

Tue, 20 May 2025 22:22:53 +0800

This article explains why your program might have gotten slower using maps in Go 1.24, and how the Go team plans to fix this issue.

The feature in Go 1.24 that excited me most was SwissMap. Previously, some unofficial implementations showed up to 50% performance improvements in certain scenarios. The official implementation also provided noticeable gains. You can find more details in my earlier articles:

SwissTable: A High-Performance Hash Table Implementation

Swiss Map in Go 1.24: Compatibility, Extendible Hashing, and Legacy Issues

However, you might have noticed that SwissMap in Go 1.24 doesn’t perform as expected and might even slow down your programs, especially with large maps. This isn’t your imagination—it’s a real issue.

https://x.com/valyala/status/1879988053076504761

The issue has been documented in Issue #70835, and the developers are actively working to address it.

What’s the Problem?

Go’s maps in the latest version use a Swiss Table structure, which is very fast for small maps and highly concurrent scenarios. However, performance degrades significantly when maps become large and data isn’t cached by the CPU (so-called “cold” data).

Why does this happen?

Because SwissMap has a relatively complex internal structure, it organizes data in multiple layers:

A header structure for the map.
A directory pointing to a list of table pointers.
Each table contains control information, keys, and values.

When you look up a key, you might encounter 4 to 6 memory jumps, each potentially resulting in a cache miss. This causes the CPU to frequently fetch data from slower main memory, significantly reducing speed.

Large projects like Prometheus noticed this issue clearly after upgrading to Go 1.24, where CPU usage increased dramatically. Upon investigation, it turned out to be due to slower map lookups.

How Was It Discovered?

Test cases didn’t detect this issue but instead surfaced in real-world scenarios:

Using huge maps (several megabytes in size).
Frequent reads from the map.
Data was not cached in the CPU’s fast cache.

Michael Pratt from the Go team conducted extensive testing to identify the cause of map access slowdown and detailed his findings in Issue #70835.

How Will It Be Fixed?

To make maps faster, the Go team plans several key changes:

Simplify directory structure: Replace pointer lists with direct structure storage, reducing one memory jump.
Compact control information: Organize control data more densely to enable more effortless CPU loading.
Separate keys and values: Change layout to “key-key-key + value-value-value” for optimized memory access.
Align control bytes: Align control information to CPU cache lines to minimize cache misses.

These changes are quite challenging since they impact Go’s runtime core:

Garbage collection must continue to work correctly.
Map resizing logic needs updating.
Performance for small maps must remain unaffected.

Where Can You Follow the Discussion?

This issue is actively discussed and tracked. You can find more details in Issue #70835. The Go Release Dashboard has already marked this issue for resolution in Go 1.25. Additionally, Issue #71368 discusses another related memory layout issue.

Conclusion

The Go team consistently strives to enhance the language’s speed and reliability. SwissMap is a significant improvement, but it has also brought new challenges, such as the recent performance degradation for cold caches.

Issue #70835 demonstrates how Go continuously improves through community feedback. Thanks to open-source projects like Prometheus, their reports help make Go better.

If all goes well, Go 1.25 will restore the balance between speed and stability.

Let’s look forward to it together!

A Deep Dive into Go’s Garbage Collector: Bottlenecks, Benchmarks, and Green Tea GC Improvements

Mon, 05 May 2025 16:32:57 +0800

Although Go’s garbage collection (GC) mechanism has undergone multiple rounds of optimization in recent years, its performance bottlenecks — especially in high-concurrency and large-memory scenarios — remain a significant focus for developers. Recently, the official Go team stirred up a discussion on GitHub with their proposal for Green Tea GC (#73581): can it further address the time cost of Go’s GC? This article dives deep into Go’s GC’s design, shortcomings, and real-world performance — and looks at the technical breakthroughs behind Green Tea GC.

https://www.reddit.com/r/golang/comments/173n28q/the_myth_of_go_garbage_collection_hindering/

📦 Design and Implementation of Go GC

Since Go 1.5, Go has used a concurrent mark-sweep algorithm combined with the tri-color marking model and yuasa-style.

In simple terms, Go’s GC runs in the background, concurrently traversing the heap, marking reachable objects, and gradually cleaning up unreferenced memory blocks. Throughout this process, Go aims for low latency and minimal pause times:

✅ Concurrent marking and sweeping
✅ No object movement (i.e., no compaction)
✅ Batch sweeping by spans (memory blocks) to reduce the duration of each Stop-the-World (STW) phase

This design’s direct benefit is that applications can mostly run in parallel with GC, keeping maximum pause times typically below the millisecond level.

🚧 Known Issues with Go GC

While Go GC delivers excellent latency, it still has several hard-to-ignore issues when it comes to time consumption and scalability, particularly:

1️⃣ Inefficient memory access
During the mark phase, GC jumps across objects, causing frequent CPU cache misses and memory waits — about 35% of GC’s CPU cycles are spent “waiting on memory.” This problem is especially pronounced on NUMA architectures or multi-core, large-memory machines.

2️⃣ Lack of generational collection
Go GC has no generational mechanism; all objects are treated the same. This becomes cumbersome in high-allocation scenarios. Engineers at Pinterest have pointed out that GC’s CPU usage spikes when memory pressure rises, triggering latency surges.

3️⃣ High CPU usage from frequent GCs
Twitch’s engineering team reported that even with small to medium heaps (<450 MiB), under steady-state conditions, the system triggers 8–10 GCs per second, up to 400–600 per minute, consuming roughly 30% of CPU time. This directly squeezes out the execution time for application threads.

📊 Performance Testing: How GC Impacts Go Programs

Let’s look at some real-world benchmark changes:

Go 1.3/1.4 (before concurrent GC)
On large heaps (10GB+), GC pauses were measured in seconds.
Go 1.5 (with concurrent GC introduced)
Under the same conditions, GC pauses shrank to <1ms.
Go 1.6–1.8
With heaps up to 200GB, GC pauses stayed under 20ms, often around 1ms in normal operation.

These improvements are impressive, but note:
✅ Latency control is excellent
⚠️ Total time spent and CPU consumption remain significant, especially under heavy load or high allocation rates.

🌿 Green Tea GC: A New Optimization Approach

To address these issues, the Go team has proposed Green Tea GC. Its core innovation is:

Upgrading from per-object scanning to per-span (memory block) batch scanning.

Specifically:

For small objects (≤512B), marking moves from per-object granularity to span-level granularity.
Only the first marked object pushes the entire span into the scan queue within each span.
During the GC scan phase, entire spans are batch-processed, significantly improving memory access locality.

Additionally, Green Tea improves parallel queue management, using a work-stealing mechanism similar to Go’s scheduler, further boosting multi-core scalability.

⚡ Green Tea GC in Benchmark Tests

Initial benchmarks show that Green Tea GC delivers selective performance gains:

✅ Tile38 benchmark (high-fanout tree structures)

GC overhead reduced by ~35%
Throughput, latency, and memory usage all improved

⚠ bleve-index benchmark (low-fanout, highly mutating workloads)

Objects are scattered with poor memory locality.
Green Tea’s performance is similar to, or sometimes slightly worse than, standard GC.

Summary: Green Tea isn’t a “silver bullet,” but it shows clear advantages in workloads with good memory locality and heavy multi-core scaling — and lays the groundwork for future hardware optimizations like SIMD acceleration.

🏁 Summary

Comparison Item	Current Go GC	Green Tea GC
Marking granularity	Per object	Per span (batch)
Memory locality	Poor, random jumps	High, batches within the same span
Multi-core scalability	Limited	Improved, using work-stealing queues
Performance gains	Near low-latency limits	Up to 35% GC time reduction in some cases
Suitable application	General workloads	Memory-locality-rich, allocation-heavy workloads

For developers chasing extreme performance, Green Tea GC offers an exciting new direction. To try it out, you can enable the experimental flag in Go 1.25+.

📝 References

Long Time Link
If you find my blog helpful, please subscribe to me via RSS
Or follow me on X
If you have a Medium account, follow me there. My articles will be published there as soon as possible.

huizhou92's Blog

Why Your AI Agent Keeps Forgetting: A Practical Memory Architecture for Individual Users

The Problem: Why Does Your Agent Get Dumber Over Time?

Six Structural Flaws in Current Memory Systems

What Does Academia Say? (February 2026 Research Review)

The Solution: Three-Layer Memory Architecture

Lightweight Knowledge Graph: SQLite Triple Table

Why Do We Need a Knowledge Graph?

When to Write to the Knowledge Graph

Forgetting Mechanism: Active Forgetting Matters More Than Passive Retention

Automatic Consolidation: Teaching Your Memory System to Digest

The Setup Checklist

Three Common Misconceptions

Summary

五年了， JSON/V2 还是没有转正

五年了， JSON/V2 还是没有转正

宏观视角：为什么 JSON V2 如此重要

全新架构：语法层与语义层的分离

为什么没有随 1.26 发布：四大阻碍

1. “永久 API” 约束

2. “完美兼容 json/v1

3. 内存回退问题：Issue #75026

4. 生态成熟度与联合类型之争

值得等待的核心特性

omitzero —— 终于有了合理的省略逻辑

inline 和 unknown —— 灵活的数据建模

format —— 内置编码定制

性能：Benchmark 数据说话

前路：v2 何时落地？

总结

10 Quiet Side Projects Making Real Money in 2025

1. A Printable “Escape Room” You Can Play at Home

2. Managing Xbox Consoles in Children’s Hospitals

3. One-Off Online Fax (Yes, Fax)

4. Duplicate Photo Finder for macOS

5. GPS-Based Check-In for Teams and Classes

6. Practicing Cold Calls by Actually Making Calls

7. Paying Your Kids to Save on Taxes

8. Turn Photos Into Printable Coloring Pages

9. Tracking Hard Drive Prices on eBay

10. A Daily Logic Puzzle (No Ads)

The Real Pattern Here

Why the Flask Creator Ditched Python for Go in His AI Startup

Introduction: A Python Icon’s “Betrayal”

1. Reconsidering Python: AI’s King with Hidden Concerns

Python’s Absolute Strengths

The Tradeoff for Core Services

2. Embracing Go: The Pragmatist’s Victory

3. Horizontal Comparison: Go vs. Rust vs. Python Use Cases

Python: The Ubiquitous “Glue” and Data Science Engine

Rust: The “Swiss Watch” for “Rust-Shaped Problems”

Go: The Pragmatic, Focused Web Service Builder

4. The New Deciding Factor: AI Agent Code Generation Quality

Conclusion: No Best Language, Only the Right Choice

Article Summary

Playing Snake in Your Browser's Address Bar: When the Internet Was Still Fun

A Random Curiosity Sparks a Technical Adventure

Wait… Why Does My Game Look Broken?

The Golden Age of “Weird Browser Games”

2048 In the URL

Snake In the Browser Tab Title

TinyJS Snake

3D Worlds in the URL

Why Are Projects Like This So Hard Now?

History API Limits

URL Length Restrictions

Character Set Restrictions

Mobile Compatibility

When Security Kills the Fun

It’s Not Just About Games

Trade-offs Are Necessary, But We Should Acknowledge the Cost

In the Age of AI, Human Creativity Matters More

We Need More Projects Like This

Playing Snake in Your Browser’s Address Bar: When the Internet Was Still Fun

A Random Curiosity Sparks a Technical Adventure

Wait… Why Does My Game Look Broken?

The Golden Age of “Weird Browser Games”

2048 In the URL

Snake In the Browser Tab Title

TinyJS Snake

`omitzero` —— 终于有了合理的省略逻辑

`inline` 和 `unknown` —— 灵活的数据建模

`format` —— 内置编码定制