huizhou92's Blog

GPT-5 Upgrade Guide: Which ChatGPT Plan Should You Choose?

Mon, 09 Mar 2026 13:47:01 +0800

The Problem with GPT-5

OpenAI dropped GPT-5 in August 2025. Eight months later, we’re at version 5.4. The model family has exploded from a simple two-tier system to a four-tier pricing structure with more variants than most people can keep track of.

If you’re not following AI news daily, figuring out which model to use — let alone which subscription tier — is genuinely confusing.

This guide won’t bombard you with benchmark scores. Instead, I’ll tell you exactly what to do based on your actual work scenarios and budget.

TL;DR

Auto mode handles 80% of use cases — you don’t need to manually select models
Plus is the sweet spot for most professionals; Go works for lighter users
Coding and long-document analysis got significantly better, but casual writing and conversational tone actually degraded
Agent Mode can handle research and organization tasks, but precision operations aren’t quite there yet
If responses feel boring, it’s not you — use prompt techniques to fix it

Understanding GPT-5 Models: What Each Version Actually Does

Let’s be honest: OpenAI has the most confusing model naming scheme in the industry. GPT-5.2 Instant, GPT-5.3 Instant, GPT-5.4 Thinking, GPT-5.2-Codex — the names alone are enough to give anyone a headache.

Forget the technical jargon. You only need to know three models:

Model	Plain English	Best For
GPT-5.3 Instant	Fast, everyday assistant	Email replies, translation, summaries, general Q&A
GPT-5.4 Thinking	Deep-thinking analyst	Long document analysis, complex reasoning, financial report interpretation
GPT-5.2-Codex	Code specialist	Programming, debugging, code review

How Auto mode works: When you use ChatGPT, the system automatically selects a model based on your question’s complexity. Simple questions go to 5.3 Instant (fast response), complex ones automatically switch to 5.4 Thinking (slower but deeper reasoning).

From my experience, Auto mode makes reasonably good decisions most of the time. But if you’re processing long documents (financial reports, contracts) or need deep reasoning, manually switch to 5.4 Thinking to ensure the system doesn’t sacrifice quality for speed.

Free, Go, Plus, or Pro? A Scenario-Based Decision Guide

Skip the comparison tables. Ask yourself one question: How many times per day do you use ChatGPT?

Fewer than 5 times daily, simple questions only → Free. You get 10 GPT-5.3 messages per 5 hours, 16K context window. Fine for short texts, email replies, and translations.

5-20 times daily, occasional file uploads → Go ($8/month). GPT-5.3 quota jumps to 160 messages per 3 hours, 32K context window, handles longer documents.

15+ times daily, frequent long documents or Agent Mode → Plus ($20/month). Same 160 messages per 3 hours for GPT-5.3, but the key difference is 5.4 Thinking quota increases dramatically to 3,000 messages per week, plus fuller Agent Mode access.

AI-dependent work, 100+ times daily → Pro ($200/month). No usage caps, full feature access.

💡 The hidden difference most people miss: Free tier’s context window is only 16K tokens. Go and Plus get 32K, and manually selecting 5.4 Thinking gives you 256K. This means the free tier literally “can’t see” documents longer than a few pages, severely degrading response quality. This matters more than message limits for daily use.

Five Real-World Scenarios: What Actually Got Better?

Email, Summaries, and Translation

Quality is stable, speed is faster. GPT-5.3 Instant performs similarly to GPT-4o on these tasks but responds noticeably quicker. The only caveat: tone leans formal. If you preferred GPT-4o’s more casual style, add tone instructions to your prompts.

Report Analysis, Financial Documents, and Long Texts

This is where GPT-5 improved most dramatically. In my testing, 5.4 Thinking can process entire financial reports and catch hidden inconsistencies, with significantly reduced hallucination rates. If your work involves document analysis, this feature alone justifies upgrading to Plus.

Presentations and Data Organization

Agent Mode can handle multi-step tasks like “research these products and organize findings into slides.” But it still needs explicit instructions — don’t expect it to interpret vague requirements. Treat it as a “research assistant that can browse the web.”

Programming and Debugging

Developers will feel this upgrade the most. GPT-5 series shows major improvements on code-related tasks, generating more complete code and pinpointing bugs more accurately. For developers, 5.4 Thinking or Codex are currently the strongest options.

Creative Writing and Brainstorming

Honestly, this is where GPT-5 regressed. Many users report shorter, more formulaic responses lacking the creativity and personality of the GPT-4o era. GPT-5.3 has been adjusted to reduce “preachy” tone, but the overall style remains cooler.

If you primarily use ChatGPT for creative work, manually select GPT-5.3 Instant and explicitly specify tone in your prompts: “respond in a casual conversational style” or “like chatting with a friend.” This noticeably improves output quality.

Agent Mode: A Realistic Assessment

Agent Mode represents GPT-5’s biggest functional leap, letting ChatGPT operate browsers and complete multi-step tasks. Sounds impressive, but how does it actually perform?

What it does well:

Web research: “Compare these three products’ specs and pricing.”
Data organization: “Summarize this PDF’s key points into a table.”
Booking and queries: “Check flights from Taipei to Tokyo next week.”

What it struggles with:

Precise UI operations (button position judgment sometimes fails)
Login-required operations (security restrictions)
Multi-step complex workflows (tend to go off-track mid-process)

Practical advice: Treat Agent Mode as a “research assistant that can browse the web” for collecting and organizing information. But for final decisions and precise operations, you’re still more reliable.

Caveats and Gotchas

The Tone Shift Is Real

This isn’t your imagination. When GPT-5 launched, users complained responses felt like “a lobotomized overworked secretary” — lacking personality and warmth. GPT-5.3 has been tuned to reduce preachiness, but it’s still cooler than GPT-4o overall.

The fix: Add tone instructions at the start of your prompts, like “respond in a relaxed but professional tone” or “like an experienced colleague chatting at the water cooler.” In my testing, this significantly improves output style.

Model Deprecation Timeline

GPT-5.2 Instant retires on June 3, 2026. GPT-5.2 Thinking follows on June 5. Before retirement, they’ll move to Legacy Models for paid users. Your conversation history and custom GPTs remain unaffected, but you won’t be able to specify these models after retirement.

The Auto Mode Black Box

You can’t tell which model Auto mode selected. For important work tasks (contract analysis, formal report writing), manually specify 5.4 Thinking to ensure you’re using the right tool for the job.

Privacy Reminder

Agent Mode operates browsers and accesses websites on your behalf. Review authorization scopes before use, and avoid letting it handle tasks involving sensitive information.

Summary

GPT-5 delivers genuine improvements in professional tasks, especially for long document analysis and coding. But casual conversation and creative writing actually got worse. Rather than blindly upgrading, first clarify your primary use cases.

My recommendation: Start with the free tier to experience GPT-5.3 Instant. Track your usage for a week or two. If you find yourself hitting the “10 messages per 5 hours” limit daily or need to process long documents, upgrade to Go or Plus. Pro is only worth it if you literally make money with AI.

FAQ

Will my conversation history and custom GPTs disappear when GPT-5.2 retires?

No. Conversation history and custom GPTs are preserved. You just won’t be able to specify GPT-5.2 models after retirement. GPT-5.2 Instant retires June 3, 2026; GPT-5.2 Thinking on June 5. Before retirement, they’ll move to Legacy Models for paid users.

Can I manually select models, or am I stuck with Auto mode?

You can manually select. Use the model dropdown above the chat interface to switch between models. Auto mode automatically assigns models based on question complexity, which works fine for most daily use. Manually switch to 5.4 Thinking for long documents, coding, or deep reasoning.

What’s the ChatGPT Go plan? How does it differ from Plus?

Go is a mid-tier option added in early 2026, cheaper than Plus. Both offer the same GPT-5.3 message quota (160 per 3 hours). The main differences: Plus provides significantly more 5.4 Thinking quota (3,000 per week) and fuller access to Agent Mode. If you primarily use GPT-5.3 for daily tasks, Go is sufficient.

If you found this guide helpful, feel free to follow me for more practical AI insights. Questions or different experiences? Drop them in the comments — I’d love to hear how GPT-5 is working (or not working) for you.

Tags: GPT-5, ChatGPT, AI Tools, Productivity, OpenAI, Technology Guide

go-lambdas-medium

Sat, 07 Mar 2026 10:07:14 +0800

Go Is Finally Getting Lambdas — 8 Years in the Making

How a Single Proposal with 900+ Comments is Quietly Reshaping Go’s Syntax

It started in August 2017. A developer opened issue #21498 on the Go repository with a modest title: "proposal: spec: short function literals." Nobody could have predicted that eight years later, the discussion would stretch to 915 comments, involve Go’s core team, and still be searching for a final answer.

But as of early 2026, we’re closer than ever.

What’s the Problem?

Go’s function literals are verbose. When you pass a callback to a function, you write this:

1
2
3

sort.Slice(people, func(i, j int) bool {
    return people[i].Age < people[j].Age
})

In languages with lambda syntax, the same intent takes far less ceremony:

1
2

// What Go developers dream of
sort.Slice(people, (i, j) => people[i].Age < people[j].Age)

The types of i and j are already known from sort.Slice’s signature. The compiler can infer them. Yet Go forces you to spell them out every single time.

This isn’t just an aesthetic complaint. In modern Go code with generics, higher-order functions, and functional patterns — callbacks appear everywhere. The verbosity adds up.

Eight Years of Debate

The proposal has gone through three distinct phases.

Phase 1 (2017–2020): “Do we even need this?”

The early reaction was skeptical. Dave Cheney captured the sentiment bluntly: “Please no, clear is better than clever.” The Go philosophy has always favored explicitness. If the compiler can infer the types, should it?

Robert Griesemer (one of Go’s original designers) was sympathetic but unconvinced by the early syntax proposals. Ian Lance Taylor suggested restricting it to expression bodies only — no block, no explicit return — which made the tradeoff clearer.

Phase 2 (2020–2023): Syntax proliferation

Once generics arrived in Go 1.18, the callback problem became undeniable. Functional utilities like slices.SortFunc, maps.Keys, and iterator adapters made verbose function literals a daily friction point.

Dozens of syntax variants were proposed:

// Variant A: arrow syntax
(x, y) => x < y

// Variant B: backslash (inspired by Haskell)
\(x, y) x < y

// Variant C: fn keyword
fn(x, y) { return x < y }

// Variant D: dot notation
.(x, y) { return x < y }

Each had vocal supporters and equally vocal critics. The thread became, as one commenter put it, “an infinite loop with a new syntax proposed every 50 comments.”

Phase 3 (2024–present): Convergence

In June 2024, a smaller working group reached a narrow consensus. The key insight from Griesemer crystallized the requirements:

The primary benefit is leaving type annotations away in the signature

Parameters should be enclosed in some form of bracketing

Moving parameters inside the block is a non-starter

The current frontrunner syntax:

// fn keyword with type inference
sort.Slice(people, fn(i, j) bool { return people[i].Age < people[j].Age })

// Or with expression body
sort.Slice(people, fn(i, j) => people[i].Age < people[j].Age)

The \() variant — inspired by Haskell’s lambda — also has strong support for its brevity, though readability concerns persist.

Why This Is Hard

Go’s simplicity is not accidental. Every feature addition carries a cost: cognitive load for new developers, edge cases in the spec, tooling complexity, and the risk of inconsistency with existing idioms.

The short function literal proposal exposes a genuine tension. The Go team must answer: at what point does brevity become obscurity?

Consider this real-world scenario with iterators (new in Go 1.23):

// Current Go
for k, v := range slices.Sorted(func(yield func(string, int) bool) {
    for k, v := range m {
        yield(k, v)
    }
}) {
    fmt.Println(k, v)
}

// With short function literals
for k, v := range slices.Sorted(fn(yield) {
    for k, v := range m { yield(k, v) }
}) {
    fmt.Println(k, v)
}

The second version is shorter. But is it clearer? That depends entirely on whether Go developers internalize the new syntax — which takes years at the ecosystem level.

What Happens Next

The proposal is not yet accepted. As of early 2026, the Go team is still evaluating the exact syntax. The most likely outcome is a conservative version: type inference for parameters, optional expression body, familiar bracketing.

What’s clear is that the “no” camp has lost the argument. The combination of generics, iterators, and functional patterns has made verbose function literals a genuine ergonomic problem. The question is now how to solve it, not whether to.

If Go 1.27 ships with short function literals, it will be one of the most significant syntax additions since generics. Eight years of debate, distilled into a few characters.

Summary

Issue #21498 has been open since 2017, with 900+ comments — Go’s longest-running syntax debate
The core problem: Go requires explicit types in function literals even when they can be inferred
After years of proposals, the community is converging on fn(params) or \(params) syntax
The Go team’s constraint: brevity must not come at the cost of readability and learnability
A formal proposal is likely in 2026 — watch the issue

If this post helped you understand Go’s evolution, consider following for more deep dives into Go internals and language design.

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 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

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.

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.

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.

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.

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.

The Importance of Website Icons (Favicon)

Tue, 18 Feb 2025 11:30:38 +0800

Recently, Tao Shu’s Blog published an article about reciprocal links, and I took the initiative to request a link exchange. Tao Shu promptly responded and kindly reminded me that adding a favicon (icon) to my blog would help RSS subscribers quickly identify it. At that moment, I wondered, “What is a favicon?” (The struggles of a backend developer!)

Later, I consulted DeepSeek:
In web design, icons are small yet significant elements. They assist users in quickly identifying a website and enhancing the overall user experience.

Common Usage Scenarios:

Browser Tab: Displayed next to the webpage title.
Bookmark Bar: Shown when users save a webpage.
Home Screen Icon: Displayed when a webpage is added to the home screen on mobile devices.
PWA (Progressive Web App): Used as the application icon.
For example:

Icon displayed in the browser tab.

The icon displayed in the bookmark bar.

The icon can be displayed even on Android devices, as the Chrome browser’s feature to add a webpage to the home screen allows this.

How to Set Up

The simplest way to set an icon is to add a line in the <head> section of the webpage.

`1`	`<link rel="icon" type="image/png" href="/favicon.png">`

If you are using Hugo or other tools, there may be specific settings for the favicon.
Some large websites, such as google.com and apple.com, may have more considerations, and their setups may differ.

Important Considerations

The icon size is also essential to optimize the user experience and achieve the best display effect across various scenarios.

Common Sizes:

16x16: Browser tab icon.
32x32: Bookmark bar icon.
64x64: High-resolution screen icon.
180x180: iOS device home screen icon.
192x192 and 512x512: PWA icons.
This is why we often see multiple icons set on some websites, such as the Hugo website.

Modern browsers support selecting different icon sizes based on various scenarios and screen PPI, striving to achieve the best display effect in all situations.

Choosing Icon Formats

Icons can be created in different image formats, specified by the type attribute. Standard icon formats include:

ICO: Traditional format, good compatibility, supports multiple sizes.
PNG: Modern format, supports transparent backgrounds, and is suitable for high-resolution screens.
SVG: Vector format, infinitely scalable without losing quality, suitable for responsive design.

Multi-Resolution Icons

If maintaining multiple icon files seems cumbersome, you can use a multi-resolution icon (Multi-Resolution ICO or Multi-Size ICO), a single file containing various sizes and color depths. This allows multiple bitmaps (BMP or PNG format) to be stored in one file.
An ICO file includes:

File Header: Defines the ICO file type and the number of images it contains.
Image Directory: Describes the size, color depth, offset, and other information for each image.
Image Data: Contains the actual pixel data for the images.
When a browser needs an icon, it selects the most appropriate size from the ICO file. The downside is that an ICO file containing multiple sizes may be larger than a file with a single size.

This article does not delve deeper into topics such as the manifest.json unique to Android Chrome or the apple-mobile-web-app-capable for Apple devices. Interested readers are encouraged to explore further.

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

GPT-5 Upgrade Guide: Which ChatGPT Plan Should You Choose?

The Problem with GPT-5

TL;DR

Understanding GPT-5 Models: What Each Version Actually Does

Free, Go, Plus, or Pro? A Scenario-Based Decision Guide

Five Real-World Scenarios: What Actually Got Better?

Email, Summaries, and Translation

Report Analysis, Financial Documents, and Long Texts

Presentations and Data Organization

Programming and Debugging

Creative Writing and Brainstorming

Agent Mode: A Realistic Assessment

Caveats and Gotchas

The Tone Shift Is Real

Model Deprecation Timeline

The Auto Mode Black Box

Privacy Reminder

Summary

FAQ

go-lambdas-medium

Go Is Finally Getting Lambdas — 8 Years in the Making

How a Single Proposal with 900+ Comments is Quietly Reshaping Go’s Syntax

What’s the Problem?

Eight Years of Debate

Why This Is Hard

What Happens Next

Summary

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

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

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

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

`format` —— 内置编码定制