@dcoder 认真设计 schema 和 index 是最基本的要求，这和“正确地”使用工具并不冲突。当然这里我对“正确”的定义可能有些狭隘。

@iseki #2 最神奇的是，他直接要求删掉外键的理由是，外键耽误他无视逻辑关系的 delete 删数据了……

@dcoder 是啊，是这样啊，每个人选择不同，导致了不同的结果。

@Mac 是不是有点太过于因噎废食了…

@dcoder 哈哈这里确实见仁见智了，有人宁可自己写一大坨，跑的慢死还一堆问题，就不肯看看一句稍微“高级”那么一点的 SQL ～

@dcoder 其实真不一定符合公司和程序员利益，大多时候一句 sql 出来的东西，写一坨代码，快慢不论，能不能写对都是值得考虑的～毕竟数据库积累了这么多年不是白积累的

@dcoder 私以为这种场合没有继续强行使用支持 SQL 的关系型数据库的必要

个人支持在大部分场景下使用数据库提供的“物理外键”，和 tl 争吵的结果是，他表示可以接受脏数据，但不能接受维护时（导入导出）的麻烦～～个人保留意见

@windseekerjack 所以我还是没看懂你这一大堆和我帖子标题有啥关系

换个角度理解，文档的含义是创建 String 对象的副本，至于对象里面的那个 array 属于不公开的实现细节，文档并没有保证会创建那个 array 的副本。而你用反射进行修改很显然是不正常的行为，那么出现问题就是很正常的咯~~~

@sagaxu 哈哈哈，我到觉得既然是查找，那没有就是正常的，返回空就 OK 了。不过如果那个函数叫“修改用户信息”，这时候报用户找不到异常就是很合理的了~~~

@windseekerjack 这个帖子讨论的是部分 go 用户的行为，不是 go 语言本身的特点，讨论这些东西的帖子够多了。对本帖内容不感兴趣可以叉掉~

@documentzhangx66 可能确实我资历浅了，见的比较少，我虽然天天吹 Kotlin 吹 PG ，但是我个人还是把他们当工具看的，别人要是喷我也不会在意。但是你要是喷 miku 那搞不好就要互相喷一喷了~~~

说实话啊，go 用了大半年了，go 的设计有些东西是真不想提，没完没了的吐槽挺没劲的，看到这种帖子也就直接划过去了，可就是不明白为什么总有一群 go 用户如同宗教一般狂热，你只要指出 go 哪里看不顺眼，他就要开始喷你

标题起的不好确实我的锅，一下子打击了一大片，不太客观。
可问题确实存在，可能是我经验比较少，混论坛的时间也比较短，没见过其他语言的使用者有这种现象，大多数都是如 #72 楼所述的一样，要么大家一起喷（开玩笑）要么就有理有据的讨论问题，就 go 的帖子动不动说人引战。有人提 if err 看着不爽就不行了，就是引战了；有人提没泛型异常就你不懂大道至简，引战了。你要一和他讨论这种现象，他就和你说你咋不去看看调度器垃圾回收什么的，天天纠结语法如何如何···
可能是我资历比较浅，真没看有其他什么语言天天为这种事矫情的。

@SuperMild 很难说 Go 这种实用主义是错的，就个人喜好上确实不太喜欢。不知道这样的实用主义会不会给后面带来麻烦呢

@sagaxu 其实一直很好奇如何把异常当作常规控制流使用，比如递归时用一个 throw 结束递归？

@weimo383 你觉得 deno 怎么样（引战～试一下

@wangxn 愤怒不至于，如果他真戳到了我看 Kotlin 一样不顺眼的地方，搞不好我和他一起喷哈哈哈…
不过那一小撮 Go 粉丝的行为是真让我感到血压升高…

@SuperMild 不是，只是感觉 go 里总是有很多奇怪的魔法，比如那个 make

@liuxu 我对 go 的这种并发模型并没有太大意见，甚至权衡利弊觉得这块 go 设计的不错，虽然丧失了一点灵活性。