go语言接小程序 go语言编程实战

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

写小程序，什么语言跨平台兼容和性能较好？golang

我最早使用go语言接小程序的语言是Java和Python，并且一直都对Python充满好感，我喜欢这种很朴实和高效率go语言接小程序的感觉，但我却最后没有采用Python，原因其实也很简单，我就是不喜欢缩进语法，就跟很多人换工作仅仅是为了屏幕更大一点一样，另外就是有了同样很棒的可选方案，这就是Ruby，所以我最终采用了Ruby作为主力编程语言，同样也为不能使用Python而有一点小遗憾，毕竟Python的健壮性比Ruby好很多，只不过Ruby也一直在进步，所以这一点无伤大雅

我们都知道，无论是Python还是Ruby，甚至Java，都是在解决业务层的问题，属于应用型语言，以解决业务逻辑为主，但还有一个领域是系统领域，偏网络层和底层操作，在这一块我一直在寻找一种优雅的方案， C++被我首先给淘汰掉了， C的开发效率太低， Java倒是比较合适，就是太臃肿，而且缺少系统编程的基因，毕竟它是企业级开发出身的

最后我选择了Erlang，因为它在网络层方面表现优秀，同时容错性和健壮性都很不错，它的虚拟机是唯一可以跟JVM媲美的，而且还有OTP的超重量级武器，几乎可以是通杀网络层应用，但根据我的总结它有一个硬伤和一个软肋，这一点后面展开，可以说选择Erlang是我目前所知道的方案里面是最优的

直到有一天我了解了Golang，我知道Golang其实也蛮早的，大概08年的时候就知道Google在搞一门奇怪的语言，之后的几年，一直有不少以老莫为代表的人在嘀咕Golang，其实我一直没太关注，我从ROR中吸取的经验是，成熟度对于商用很重要，后来基于Golang开发的产品越来越多，让我不得不去研究一下，这我才知道，这就是我梦想中的Python，效率和性能达到了最佳的平衡，对Go了解越多，就越不愿意用Erlang写代码，主要原因：

1、Erlang的硬伤在于代码的可读性、表现力，让我来举个小例子，比如你为你的系统软件构建一个RESTFUL的接口，我们大致了解一下代码风格，先不说Erlang，无论是你c/c++/python/ruby/java 出身，对Go是不是有种很久违的感觉, 为什么说是硬伤？因为对一门语言来说，语法是不大可能会大幅度变更的，而且不会出现大的变化，我不知道有没有人读过《松本行弘的编程世界》，里面阐述的道理很明白，真正好的编程方式是人去主宰计算机而不是计算机主宰人，我感觉Erlang就有点主宰我的编程思维的感觉(我的视力本身就不好，它还在不断的扼杀我的眼睛！)，编程首先是门逻辑学，其次是工程学，最后才是数学，又让我想起吴军的《数学之美》所说的，人工智能上个世纪一直在走弯路，期望机器的高度图灵完备，而忽视人类本身已有的文明，统计归纳的应用

2、Erlang的软肋在于高质量的库少，尽管有不少杀手级应用，同样Go在这方面也是软肋，这一点对于一个不到五年的语言有情可原，但对于一个20多年的语言是不是有点说不过去，比如你用json解析库，很多人都是从mochiweb这个基本不更新的库中去抽取，而我认为对于类似json这种东西可以考虑融入到语言标准库中，因为未来的商业软件的api化趋势越来越明显，说的难听点，一个倚老卖老一个与时俱进，反正我对Golang的库一点也不担心，目前的成绩易经非常棒了，远远优于Ruby/Python的前五年，可参见已有的高质量的库列表

3、Erlang不合群，这主要体现在跟其他语言的交互性上，当然这也有深层次的原因， Erlang本身有自己的哲学，如出错恢复机制，你融入一个其他语言的东西进去，这帐就不好算，就好比你硬要让一个喝咖啡的跟一个吃大蒜的坐在一起，总之你写一个Erlang的port远远比Go复杂，甚至比Python/Java还要复杂，这就造成了Erlang在底层编程上效果不是很好，没法利用linux已有的很多优秀成果，我一直认为Erlang的什么的mysql/pg/oracle驱动都没有必要存在， Erlang一定是一个self-container应用，你只要用到了其他东西，根据木桶理论，你就不敢号称9个9，以系统的眼光看问题，我觉得一个系统的鲁棒性不能依赖于某一组件，这也是为什么爱立信本身的Erlang应用并不广泛

4、说说数据类型吧，我不止听到1个人说Erlang对字符串的处理不有好，它把string当做list来处理，其实本质上是该这么，但，还是那句话，违背了面向人的哲学，应该做一些DSL，比如Golang里面的 := 就是一个糖衣，等价于 var xx yyy = zzzz，大大方便的程序员少敲不少字符, Golang里面对字符转可以说基本和python差不多， slice map函数很强大，支持lambda条件，虽然Erlang的基本类型很少，但有很多构造，所谓构造等价于Golang里面复杂的struct，也奇怪了，我就是感觉Erlang构造伤眼睛好吗？可能是各种括号的比对的原因吧，而且我认为这是不必要的，显然Erlang缺少DSL的基因，当然跟Erlang出身的年代有关，我不夸张的说，自打用Erlang以后我的视力又下降了100度左右，我不是很喜欢lisp所说的符号也是一种语法，可能这又跟函数式编程有关吧：形式推导远大于逻辑演绎

5、其实我最不关注的是性能问题，因为随着摩尔定律，单位计算单元的性价比会无限高，但Golang既然提出它的性能逼近C，那我还是提一下吧，当然， Erlang也还可以，虽然比Java慢，但跟Python一个档次吧

6、再谈谈报错机制，因为Erlang的的报错信息太让人纠结了，起初以为我不会看出错信息，后来也使用了Sasl，还是不够直观，甚至有时要用工具分析crash文件来定位问题，还是跟Erlang的哲学有关，在Erlang中一切都是并行的，所以它根本不care是物理哪一行出错，只跟Actor绑定，然后告诉你Actor的ID和出错代号，你自己凭经验去分析吧，这样做的好处是可以很方便定位出并行中出现的问题，但凡事都是相对的，在这一点上有点纠枉过正，根据我的经验，绝大部分时候我只希望先给我明确的指出哪一行出错了好吗？甚至把顺序的backtrace用完整的英文句子打印出来好吗？至于并行中的错误及时在命令式多线程语言中是不常见的，虽然并不是没有，但遇到错误我再费劲去调试好了，但并不是所有的逻辑都用并行的思维去定位问题，我甚至认为，对于一个系统不完全是并行也不完全是串行，跟好比我们衡量世界不能单纯的唯物也不能完全的唯心一样，这一点Golang就做了很好的折中，不需要并行的时候你老老实实的写串行代码，需要并行的时候也有较复杂的机制来应对，合乎情理

7、再说说招人吧，以前招过好几个C出来的人，说实话水平很好，可以一周就完成一个小组件， libevent用的熟的很，后来我逼人家用Erlang，结果把人家逼走了，至今我还很后悔，自己的一厢情愿强加在别人身上真是太不合适了，但我招纯Erlang出来的人，可以说比招objc的人还难，没有人，空谈技术的优雅性首先就是不靠谱的，再看看邮件列表， Golang的活跃度明显比Erlang高很多，基本逼近Ruby，更重要的是，我根本不担心Golang的人才，因为只要熟悉Python/C/Ruby/或者C++，基本可以实现半天入门，之后就可以噼里啪啦边搜资料边干活了，虽然有足够的深度，但门槛极其平缓，工程人员也可以复用很多已有的知识。 Erlang在这一点其实跟第一点硬伤有关，大部分人学一周都摸不着头脑，不是每个人的抽象思维和世界观都是一样的好吗，所以函数式编程尽管不比命令式语言起步晚，但始终学的人很少，这就是历史，对于大部分人，更希望解决问题，创造价值，而不是数学来推导去

8、最后我建议，如果你是玩c/c++的，现在开始学Golang，是最好的时机，跟一门靠谱的语言一起成长，这种感觉非常棒，你用Erlang折腾1个应用，用Go恐怕都完成了10个开源项目，当然，也要结合自己的口味， Golang就是Sublime Text， Erlang就是Emacs

相信自己的判断，相信自己的逻辑，赢就是赢，输就是输

转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦