锐客网

  1. 首页 > 睿知 > it技术 > >

go语言理论补充 go语言知识点( 五 )

IT技术语言


比如C/C++的增量编译/预编译头文件/并发编译都是为了提高编译速度.
Rust1.1 也号称 比 1.0 的编译时间减少了32% (注意: 不是运行速度).
当然, Go刚面世的时候, 编译速度是其中的一个设计目标.
不过我想楼主, 可能想说的是因为编译器自己添加分号而导致的编译错误的问题.
我觉得Go中 { 不能另起一行是语言特性, 如果修复这个就是引入了新的错误.
其他的我真想不起来还有哪些 调编译速度，不惜放弃本应提供的功能 (不要提泛型, 那是因为还没有好的设计).
1.4 错误处理机制太原始
在Go语言中处理错误的基本模式是：函数通常返回多个值 ， 其中最后一个值是error类型，用于表示错误类型极其描述；调用者每次调用完一个函数，都需要检查这个error并进行相应的错误处理：if err != nil { /*这种代码写多了不想吐么*/ } 。此模式跟C语言那种很原始的错误处理相比如出一辙 ， 并无实质性改进 。实际应用中很容易形成多层嵌套的if else语句，可以想一想这个编码场景：先判断文件是否存在，如果存在则打开文件 ， 如果打开成功则读取文件，如果读取成功再写入一段数据，最后关闭文件 ， 别忘了还要处理每一步骤中出现错误的情况，这代码写出来得有多变态、多丑陋？实践中普遍的做法是，判断操作出错后提前return，以避免多层花括号嵌套，但这么做的后果是，许多错误处理代码被放在前面突出的位置，常规的处理逻辑反而被掩埋到后面去了，代码可读性极差 。而且，error对象的标准接口只能返回一个错误文本，有时候调用者为了区分不同的错误类型，甚至需要解析该文本 。除此之外，你只能手工强制转换error类型到特定子类型（静态类型的优势没了） 。至于panic - recover机制，致命的缺陷是不能跨越库的边界使用，注定是一个半成品，最多只能在自己的pkg里面玩一玩 。Java的异常处理虽然也有自身的问题（比如Checked Exceptions） ， 但总体上还是比Go的错误处理高明很多 。
话说, 软件开发都发展了半个世纪, 还是无实质性改进. 不要以为弄一个异常的语法糖就是革命了.
我只能说错误和异常是2个不同的东西, 将所有错误当作异常那是SB行为.
正因为有异常这个所谓的银弹, 导致很多等着别人帮忙擦屁股的行为(注意 shit 函数抛出的绝对不会是一种类型的 shit, 而被其间接调用的各种 xxx_shit 也可能抛出各种类型的异常, 这就导致 catch 失控了):
int main() {
try {
shit();
} catch( /* 到底有几千种 shit ? */) {
...
}
}
Go的建议是 panic - recover 不跨越边界, 也就是要求正常的错误要由pkg的处理掉.
这是负责任的行为.
再说Go是面向并发的编程语言, 在海量的 goroutine 中使用 try/catch 是不是有一种不伦不类的感觉呢?
1.5 垃圾回收器（GC）不完善、有重大缺陷
在Go 1.0前夕，其垃圾回收器在32位环境下有内存泄漏，一直拖着不肯改进 ， 这且不说 。Go语言垃圾回收器真正致命的缺陷是，会导致整个进程不可预知的间歇性停顿 。像某些大型后台服务程序，如游戏服务器、APP容器等，由于占用内存巨大，其内存对象数量极多，GC完成一次回收周期，可能需要数秒甚至更长时间，这段时间内，整个服务进程是阻塞的、停顿的，在外界看来就是服务中断、无响应，再牛逼的并发机制到了这里统统失效 。垃圾回收器定期启动，每次启动就导致短暂的服务中断 ， 这样下去，还有人敢用吗？这可是后台服务器进程，是Go语言的重点应用领域 。以上现象可不是我假设出来的 ， 而是事实存在的现实问题，受其严重困扰的也不是一家两家了（2013年底ECUG Con 2013，京东的刘奇提到了Go语言的GC、defer、标准库实现是性能杀手 ， 最大的痛苦是GC；美团的沈锋也提到Go语言的GC导致后台服务间隔性停顿是最大的问题 。更早的网络游戏仙侠道开发团队也曾受Go垃圾回收的沉重打击） 。在实践中，你必须努力减少进程中的对象数量 ， 以便把GC导致的间歇性停顿控制在可接受范围内 。除此之外你别无选择（难道你还想自己更换GC算法、甚至砍掉GC？那还是Go语言吗？） 。跳出圈外，我近期一直在思考，一定需要垃圾回收器吗？没有垃圾回收器就一定是历史的倒退吗？（可能会新写一篇博客文章专题探讨 。）

推荐阅读


上一篇：辽宁智慧人口gis系统规划方案，辽宁人口信息网网址

下一篇：虎牙直播怎么解决血腥暴力，虎牙直播的时候总是有杂音该怎么办