@mengzhuo

“为什么说不对 err 进行处理是偷懒的行为，那是因为一旦有了 catch ，程序员一般就全扔里面了，而且有时，一些“罕见”的错误需要停止程序运行，但是 catch 住了，你觉得还会有处理么？
再说，编译器在 catch 对每一种错误都进行判断和处理，那我为啥不直接返回值里一个个来呢？”

1. 全部 catch 不处理，偷懒的是程序员。
2. 返回 err 一个一个来？ 还是我说的，在 do_transaction 这样的函数里面的问题，如果我里面返回了不定多个 err ，你怎样一个一个来？ 这时候偷懒的是编译器，语言。

@julor

区区在下最近恰好在 linux 上用 mono 写 C#，商用的， JIT 也可以 AOT 也可以，所有的 C# 特性已经 mscorelib 都支持。 所以，对于跨平台这一点的疑问，自己可以去看 mono 官网。

@mengzhuo

你了解到的 async + Task 是什么？为什么不是并发模型？ async + task 这些甚至是语言自带的。

async 关键字让异步方法可以被编译器改写，避免了回调嵌套，这点跟 go 用 goroutine 带来的优势是一样的，无论从性能还是从代码可读性的角度来说都是一样的，甚至异步模型能够使用比 coroutine 栈更精确的内存使用量； Task 自带线程池跑异步任务，用的是系统级的线程调度，一样也是在任何需要的地方（甚至不局限于 IO ）自动让出 CPU 使用权，这跟 goroutine 也是一样的；

而 go 必须要使用 channel 或者其他同步原语才能明确交出控制权，遇到 CPU 密集的计算你甚至没办法手工分派到低优先级队列，这跟 C# 全方位的控制真是差远了，至少用 C# 你还可以指定线程池策略。在这一点上 go 还真是没办法自称系统编程语言，隐藏了太多重要的底层细节不让程序员使用。

加锁问题？这个跟语言没有任何关系， go 不需要加锁的地方 C# 一样也不需要，这是业务决定的。甚至用 C# 你还可以在编译器层面保证所有其他项目参与者，使用设计良好的 actor 模型，完全无锁。这是 golang 这种弱爆了的编译器没法要求其他参与者做到的。

2. 单文件可以追溯所有的问题 ？ 你肯定没遇到过静态链接的坑吧，请问 golang 用了什么不一样的原理使得它跟以前的链接模式有所区别？甚至比以前要退步了，因为只能在有源码的情况下链接。

你要问 C#， Dll Hell 早就是历史了，因为你可以自己对第三方库的版本做 code sign ，不一致的第三方库版本，哪怕你 *没*有*源*码* 你都可以在静态链接或者动态链接的阶段发现出来。

不要以为有个什么包管理工具就可以趟过坑了，这种根本就是语言设计层面的问题。看看现在 go 又有多少个第三方包管理程序就知道， go 根本就没解决过这种问题。

3. 大量使用 interface 不是一个个人问题，而是社区问题，只要你语言里面有这样的东西，就会倾向于被各种低级程序员滥用。不过也确实， golang 也就只能吸引这部分人了吧。

4. 编译成原生代码根本就不是什么屌渣天的事情。 Tracing JIT 甚至可以为长期运行的程序优化生成比从 C++ 编译出来更快的原生代码，信不信由你。

5. 你知道 PEP8 就好，再也不要迷信什么大括号啊，缩进啊，都要搞成语言标准的东西了，用 clang-format 这种基于语法分析的工具来优化代码格式，而不是靠什么语法层面约束来制造麻烦。

@chai2010

正如 @mengzhuo 说的，任何语言都“不能阻止组内的程序员继续写自己风格的东西。 ” 你今天重新发明一个 类似与 exception 之类的东西，明天又有别人发明一个，然后使用 不同 的重新发明过的 exception 写成不一样的 第三方库，然后你就指望一个程序里面可以好好地 handle 这些不一样的 exception 吧。

这就是弱鸡语言的全部故事。

补充我刚刚说的那个 do_transaction 的问题。

exception 的概念优秀之处在于，抛出异常保留现场（包括整个调用栈），这其实是一个非常有用的工具。如果没有 exception ，那么就要程序员自己写代码，想办法来保留可能有用的数据。

golang 这种直接把错误当作一个返回值传出去，在我看来才是完全不负责任的表现——就是想把错误应付过去就算了……都返回结果了，哪里还有什么现场可言？

尤其是在返回不定多个 err 这样的场景下（例如 do_transaction 的例子）， golang 是静态编译的没有办法直接在语言层面返回不定多个 err ；那么就只能： 1. 把 err 都放到一个值返回出去做检查，请问这样跟 catch 掩盖错误有什么区别吗？然后，如果你不想程序轻易当掉的话，你还要手工去分析 err 的各种可能性，否则漏了一个的话，你就会惊喜的看到上线后不定期 crash …… 而支持 exception 概念的基本上语言层面直接把 error 分发到对应的分支了，实在不想让程序 crash ，你总是有办法的。 2. 就是在写的时候手工做一些 book keeping 来纪录执行到哪里出问题…… 那为什么不直接用语言提供的措施？这跟 exception 有什么区别吗？

可能有些人觉得 exception 都是 IO 才会产生，现场不重要。那么，用 golang 就意味着只能外面拼接一个 DSL 或者其他语言才能做事务了——这么说来，它其实也就是一个用来拼凑业务逻辑的东西，根本不是什么系统编程语言。

所以 golang 就是一个 自相矛盾 自欺欺人的编程语言。

@mengzhuo 这么说？你认为 golang 不用 try catch 用 err 是比较严谨的行为？

我能理解有些人的想法，认为 try catch 会制造机会让程序员写出什么 error 都不管也不抛的代码出来；而返回一个 err 加上编译器强制检查是否使用过 err 可以解决这类问题……

恕我直言，这样思考问题还是不够抽象，太幼稚……

首先，不合格的程序员无论怎么低等级，战胜编译器还是易如反掌的……

譬如，一个函数 do_transaction 里面要串行执行多个（但数量并不是固定的，譬如在循环里面调用）有可能返回 err 的方法，现在，编写一个方法调用 do_transaction ，如果有错误，对已经执行过修改进行回滚，但是，其中某些 err 是可以忽略的，请问这个方法要如何才能知道在哪一步产生了错误？

你瞧不起 try catch , 认为这是偷懒？偷懒的是人，通过把语言功能弱化来迁就人，我也是醉了……

如果你说这不是 golang 解决的问题——基本的事务都解决不了，那么请问他何以自称服务端开发语言？

再来说说你所谓的有点：
1. channel 刷多核，消息跨核传送——我觉得，只有那些只用过 python nodejs 的人才会把这个当卖点吧？ C# async + task + 自带的线程池，一样轻松愉快刷多核

2. 单文件解决所有问题？—— 没有动态库当成优点，应该是 golang 脑残粉才做得出来吧？ hotfix 怎么办？ 增量式部署更加是奢望了

3. 工具链完备，各种分析很容易做？ 呵呵，以 golang 那么点历史，大概还没有项目经历过重构吧？以它那么低的语言表达能力，重构一定很爽。有 interface {} 这种东西，静态分析基本上都可以废掉了。

4. 性能还不差 —— http://kokizzu.blogspot.com/2015/02/framework-benchmark-10-preview.html 这个 benchmark 好像不太同意你的说法哦

5. 原生支持生产代码、风格统一、标准得很漂亮 —— 建议你了解一下 clang-format ， golang 这种自己帮你加分号的丑陋东西就不要拿出来 BB 了……

@mengzhuo go 语言是门严谨的系统编程语言？
请问你对于“严谨”的定义是什么，对“系统编程语言”的定义是什么？

PS ：你可以不理会我，因为我是 golang 黑。

https://zh.wikipedia.org/wiki/TF-IDF

以下摘自 维基百科：

TF-IDF 的主要思想是：如果某个词或短语在一篇文章中出现的频率 TF 高，并且在其他文章中很少出现，则认为此词或者短语具有很好的类别区分能力，适合用来分类。 TF-IDF 实际上是： TF * IDF ， TF 词频（ Term Frequency ）， IDF 逆向文件频率（ Inverse Document Frequency ）。 TF 表示词条在文档 d 中出现的频率。 IDF 的主要思想是：如果包含词条 t 的文档越少，也就是 n 越小， IDF 越大，则说明词条 t 具有很好的类别区分能力。

--

“腾讯”和“百度”肯定比起什么“公司”，“有限” 这类词语出现得少……然后，就是这样了。

如果你是想说用某种库或者 GC 以外的办法，使得问题变得看起来比较简化，那么你需要的是 actor 模型 / 协程。

主要的差距在于眼界和自我完善的能力上。

科班出身的，一般程度的由于时间积累，知道各种理论可以达到什么样的效果怎样的上限，可以解决怎样的问题，这些其实是身边的同学 /导师带来的。 非科班出身，光靠自己很难弥补这种差距，除非有一个适合的环境。

另外一方面就是，遇到专业范围内不熟悉的领域，如何切入和查找相关资料方面，科班出身也会比较有优势，因为接触到的术语比较多，用好的术语和关键字来查找资料和建立自己的知识体系会容易很多。

其他的，技巧啊技术什么的，都是看个人。

V 也是这样成功黑进元首的全国性的强制性的广播系统，向全部人发表他的宣言的

@jsyangwenjie

1. “手写递归下降或者语法分析有什么意义呢” 这是你自己说的，我只负责告诉你有什么意义。

2. 在 54 楼我问你，给出错误信息是前端还是后端， 55 楼你反问我关于 IR 的东西。你这是喝多了吧？

3. 处理 "/api/v1/item/<id:string>" 这样的与 URL 相关的 DSL ， 并且绑定到对应的处理器，叫做 url routing 。

如果你把 LL parsing LR parsing 这部分当作前端，那我可以告诉你， ANTLR 的作者 Terrence Parr 就是研究前端的，教授，他的研究成果就是通用的 LL(*) Parser Generator 。

LL(*) 的意思是，向前看任意多个 Token ，如果你不明白这是什么意思，那你还是看看龙书再出来教育他人吧。

@jsyangwenjie

1. 不是所有编译过程都需要中间代码，譬如你写一个 web url routing 就没有什么鬼中间代码。但是你依然可以在一遍 pass 的过程中就找出所有注册路由过程中可能发生的错误或者歧义。又譬如 v8 jit 一样也没有什么鬼中间代码，从体验上来说它就是一遍 parsing ，要么出错要么生成 binary 。

2. “手写递归下降或者语法分析有什么意义呢” 我问的问题是关于你的这个观点的，手写递归下降是很多商业编译器的做法，这些编译器不是用任何什么 lexer generator parser generator 整出来的。你跟我扯什么前端后端，现在又扯什么 IR ，让我觉得你好像没有实在地使用过编译器的技术……

事实就是，一个十几人的编译器 team （再大一点的我就真没见过了），确实很少时候需要把精力放在 parsing 的阶段（可能这是你说的所谓前端？），主要精力都是放在生成优化，可能就是你说的 IR 阶段……

手写递归下降有什么意义？除非在 LR 分析技术有什么重大突破吧，不然 LL(*) , 例如 ANTLR 这样的工具所使用的 parsing 技术才是主流，因为这样的 parser 好写，用户友好度高。

@jsyangwenjie 偷换概念？我问你一个问题，你认为递归下降分析出错误，然后实现给出错误信息的工作，这部分属于前端还是后端？

@jsyangwenjie 尽管 LR Parser Generator 已经不是什么高深的技术，手写递归下降目前依然是多数商业编译器的主要实现方式，因为这样的错误提示比较容易做得友好，投人力就可以搞好了——然而前提是，做这些的人必须要理解 LL ，不然根本无法工作。

觉得编译原理没有实际用处？

来，我们来实现一个 Web url 路由，支持动态绑定资源处理方法，譬如模仿一下 flask restful ？

什么？你不知道什么叫做 web url 路由？

那跟你说这些有什么用……

非要细究的话，可能的考虑就是 在
dataSource registerReusableViewsWithCollectionView: 之前可能会被另外一个线程改变 self.collectionView

然而 C/C++ 已经掌控世界 30 年

什么是 quick document ? 你是说 "///" 吗？

其实就是 AppArmor 或者 Docker 做的事情。理论上当然是可以，但是……这么做的话几乎跟重新发明一个 OS 的效果是一样的，很多不流氓的 app 也运行不了