这篇文章以幽默讽刺的口吻讨论了编程语言的选择偏见。作者虚构了一种编程语言作为"稻草人"来调侃程序员们对不同语言的无谓争论,暗示这些争论往往源于主观偏好而非理性分析,最终可能只是自说自话的徒劳。

你的函数是什么颜色？

虚构语言的色彩规则

作者虚构了一种编程语言，其中每个函数都有颜色——红色或蓝色，并制定了以下规则：

1. 每个函数都有颜色：必须用blue_function或red_function声明
2. 调用方式与颜色相关：必须使用()blue或()red语法调用对应颜色的函数
3. 红色函数调用限制：红色函数只能被其他红色函数调用（但红色函数可以调用蓝色函数）
4. 红色函数调用代价高：调用红色函数需要繁琐的额外操作
5. 核心库包含红色函数：某些必要的基础功能只有红色版本

现实映射：异步编程困境

这个比喻实际描述的是异步编程的痛点：

• 红色函数代表异步函数（如Node.js中使用回调的函数）
• 蓝色函数代表同步函数

现实中的对应关系： 1. 同步函数直接返回值，异步函数通过回调"返回" 2. 同步调用直接获取结果，异步调用需要通过回调处理 3. 不能从同步函数中调用异步函数获取结果 4. 异步函数难以组合使用，无法与常规控制流结构配合 5. 核心API往往是异步的（如Node.js）

现有解决方案的局限

1. 回调：导致"回调地狱"，手动管理continuation-passing style
2. Promise：只是回调的包装，未解决根本问题
3. async/await：改善了编写体验，但依然存在同步/异步的割裂
4. 生成器：与async/await类似，通过编译器转换实现

理想解决方案：线程/协程

真正解决问题的语言特性： - Go的goroutine - Lua的协程
- Ruby的fiber - Java的线程

这些方案通过维护可切换的调用栈，消除了同步/异步的界限，使IO操作看起来是同步的，但实际上不会阻塞整个程序。

核心观点

当前多数语言的异步方案只是通过编译器技巧（如CPS变换）缓解问题，而非真正解决问题。理想的并发模型应该让开发者无需关心函数"颜色"，而这需要语言提供适当的线程/协程支持。

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持同步/显式标记的观点

1. 同步代码更可控

   • frankfrank13：坚持同步代码便于维护，"this entire chain of code is sync, if you want a DB call, do it somewhere else"
   • preommr：批评隐式异步（如Go）的风险，"Your entire codebase is now a surface area that is at risk of being blocked by waiting on a channel"

2. 显式标记（如async/await）有价值

   • qihqi："Colored functions are good... like Rust's unsafe markers"
   • wesselbindt："I like when I can see from the function signature that it might do IO... code is read more often than written"

反对函数着色问题的观点

1. 问题被夸大或已解决

   • slopinthebag："have not once ran into this supposed problem... The author is inventing a problem"
   • wasmperson："async/await syntax cleaned up that ecosystem... now function coloring isn’t really a problem"

2. 隐式异步的替代方案

   • nickcw：赞Go的隐式异步，"Go doesn’t have colored functions... a pleasure to code concurrent stuff"
   • satvikpendem：提倡代数效应，"algebraic effects in more languages... solves the function coloring problem"

中立/其他观点

1. 语言设计权衡

   • overgard："async/await is a huge improvement over callbacks... but threads are more elegant"
   • viktorcode：批评Go的隐式着色，"Go still has red and blue functions... now they’re implicit"

2. 语法改进建议

   • bre1010：提议反向标记，"why can’t my sync function await something asynchronous?"
   • fastforwardius：幽默建议，"Having functions literally color coded would be nice"

争议性引用

• rendaw："All functions are colored... It’s easy to call low-restriction functions from high-restriction ones"
• preommr（反驳作者）："Author makes up a lie... with a colorful non sequitur"

总结：评论围绕函数着色的必要性、显式与隐式异步的优劣展开，支持者强调可维护性，反对者认为问题被夸大或已有解决方案。部分用户提出代数效应等替代方案，另一些则指出语言设计中的固有权衡。