看了一个 go 语言，感觉语法略为不习惯。

go 的语法太古怪，比 Python 还古怪。

1 ，几乎各门主流语言都有大量脑残粉，这个不能成为黑的理由，太牵强
2 ，泛型估计从开始到现在一直没找到满意的解决方案，只不过现在呼声太高，把缺陷放大了，实际上写业务代码的对泛型的需求并不是特别强烈，写库的才有需求
3 ，包管理真纠结
4 ，批判代码风格问题的人，一般都是太自我中心的人

golang 的 error 要看你用什么角度去看, 如果你是用 c /lua 这样的, 那么 golang 的 error 只有改进

但是一定要同 python/c#/java 的 try/exception 机制去比, 就陷入脑残粉的怪圈了

github 有很多对错误改进的库,比方说 github.com/juju/errors, 其中就反映了 error 的不足

比方说 errors.Trace 方法, 会在原来的 err 对象上再增加代码行, 比方说 errors.Annotate 会在原来的 err 上增加描述, 比方说我现在看到到一个 orm 库 gorm, 它在找不到记录时返回的异常都是 record not found, 如果代码中有多行返回这个异常, 不在原来的错误添加描述而是直接返回其异常是没有办法定位的


这里还要吐槽一下 golang 的错误堆栈, 同 python 完全没法比, 用过的人自有体会

上面有兄弟说到 try/catch, 服务器端开发其实不 catch 异常的, 都是直接抛出, 最多捕获一般也是在发送给客户端时捕获一下,然后打印异常到日志, 也就是说有些不正常的情况是依赖系统或库抛出的异常的, 比方说查询时 sql 用了一个字段名打错了,python/java 之类的不会在这行中取捕获这种异常, 但 golang 就一定要, 否则出错在就在下面的行, 让你莫名其妙

最后别信 golang 的开发效率, 同 python 比是完全不可能的, 拿关键的 orm 而言, 没有一个库的设计能同 sqlalchemy 这种设计高度相提并论的, 在开发数据库应用时,会很痛苦.

@noli err 要携带上下文信息很好实现，我自己就包了一个（不过今天只能看到独角兽了）：
https://github.com/chai2010/errors


panic 也可以当作一种异常，只是被故意设计的很难用。
这是为了防止 panic 被滥用。

我就一个问题为什么发在 python 版...

另外, golang 的古怪的地方是

虽然 golang 有闭包, 但官方其实不建议闭包当做类似 python 的 lambda 用的, 像, 类似

filter(ATypecol, func (item AType ) bool { return true})

这样的用法是不建议的, 而是推荐你用循环

类似于 do in transaction, 按 java 系的写法就是

session: = db.Begin()

err := func (session *gorm.DB) error {

return nil

}

if err != nil{
session.Rollback()
return err
}
session.Commit()

但一般也不建议这样用, 而是老老实实的每次 crud 时

if err != nil{
session.Rollback()
return err
}

一个复杂的事物中, session.Rollback(); 会重复 n 次, 处女座绝对不能忍

err := func (session *gorm.DB) error {

return nil

} (session)

打错了

scala 大法好

@Shieffan +1 严重同意……

@jjx 看场景吧，标准库也有类似的用法：
https://godoc.org/strings#TrimFunc

@jjx +1

@banxi1988 sigh

为了楼主自己的感受挑起语言之争真不值得；那些就写了几个 demo ，看了点语法介绍连 effective go 都没看完的人有啥好和争论的；每个语言都有缺点，在特定方向上瑕不掩瑜就好了。

Haskell 教徒笑而不语

@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 吧。

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

@mengzhuo

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

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

真是奇怪了。。。怎么又来语言大战？哪有语言是完美的？

@kelvinji2009 主要是某些用低等语言的人总是秀优越感，让人心烦。

像用 C++ 这样的就没有机会秀优越感了，一个个都老实得不得了。

然后，阻止那些用“战术上勤奋的语言”作恶毁掉程序员人才库，是我等学院派和语言卫道士的终生追求。

再者，技术崇拜和技术歧视，是一样脑残。我就喜欢打那些捧 google 臭脚人的脸，把所有微软技术视作邪恶来源的，也是逗逼。

最后，憋一个作品之后再出来爽，这样实在太漫长了，还是放个嘴炮又快又舒服。

@noli

本来写了很多技术讨论的东西，但是人身攻击已经开始了，我也就不回了
EOF

@xunuoi 哈哈 +1