- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】介绍一下Go语言（1）之前的话 -- zllwy
我知道会有很多争议的。就当一家之言来看吧。欢迎讨论。
先说说我入门的经历。最早知道Go是还在Android的时候，坐我对面的一位资深老程序员（以前是xbox team做graphics的）跟我介绍了Google内部在开发的新语言。新的语言这年头也层出不穷，我也没注意。后来到了现在的公司，开始做web service，主要用Java。特别讨厌netty的异步编程方式（netty本身还是好同志，对了，如果你没听说过，netty是一个基于Java nio的一个网络编程库），所以就开始想到coroutine，因为coroutine是非常轻的，可以大量创建，这样可以同时保证并行性和代码的顺序性。不过coroutine在C里面比较容易实现，利用gcc的特殊feature可以实现，有专门的库可以用。在Java里面，没有直接的实现。只好退一步，考虑continuation，利用continuation可以实现coroutine。continuation其实是个非常强大的概念。函数调用返回其实是continuation的一种特殊形式（参考google吧）。Java里面说了好久要支持continuation，因为它是实现generator的必需。曾经进了Java 7的draft，但后来被JCP砍了。有一些专门的库，比如RIFE和apache commons的Javaflow，实现了continuation，不过因为没有JVM支持，效率比较低。后来发现了Cambridge（UK那个）一个印度人的博士论文，他写了一个系统叫Kilim，在Google还有个tech talk。Kilim在Java上实现了一套最基本的Actor/Message的实现。他的办法是用一个"Pausable" exception来标志有可能主动pause的函数，然后在编译后经过一道特殊的Java class的binary rewriting，在所有的pausable的函数前后插入维持continuation状态的代码。这样就可以实现类似coroutine那样的合作式并发，或者称为轻量级的thread，和windows上的fiber比较像。实际上Kilim也把它的并发单元叫做fiber。Kilim还实现了基本的消息传递的机制。Kilim是看来最完整最高效的在Java里面actor的实现。不过Kilim的问题是它要多一道工序，改写class file。另外所有的I/O代码其实也要重写来支持fiber。这些好在也不是太大的问题，实际上有人已经开始用kilim了。
随着我对Actor模型的兴趣，go再一次重新进入我的视野（scala什么的就不提了）。这次，我发现Go正式我期盼已久的语言。
先说我一下我心目中理想编程语言的标准：
1 不限制我在一个框架里面的。
2 语言足够简单，不需要我花大量精力去学的。
3 提供足够的orthogonal的features来方便我编程的。
其实python符合我的标准，可惜还差那么一点。另外，对于大型项目，动态语言本身这一点我就不选它了。还有我其实很讨厌python的缩进格式，真想把这个搞进python的人狠狠打一顿。本来很喜欢的一个语言，就这点特别让人恼火。不知道还有没有人跟我有相同感觉的。
好了，Go完全符合我的标准：
1 静态语言
2 语法非常简单。language spec一天可以看完，当然要熟练编程还是需要点时间的，如果你对python熟，基本不是问题。Go的compiler似乎是不用symbol table的。足够简单。而且Go的语法基本接近于C（感觉就是程序员的母语一样，哈哈）。
3 没有OOP的那套复杂的东西，只有interface，相当于static duck typing，非常灵活。
4 提供一组orthogonal的language features，精巧好用简洁。
5 日益完善的library支持。
6 Actor并发模型，写网络程序非常容易。
7 很重要的一点：garbage collected。
后面一个个来说。先说一下Go的背景。Go的原创人员都是鼎鼎大名的人物：Bell lab的Rob Pike，Ken Thompson等。Ken Thompson大家应该都知道了吧：Unix，C...就凭这个我也信任他们。呵呵。
还有我其实很讨厌python的缩进格式，真想把这个搞进python的人狠狠打一顿。本来很喜欢的一个语言，就这点特别让人恼火。不知道还有没有人跟我有相同感觉的。
go的性能表现如何?虽然现在的计算机越来越快了...
缩进,我倒是觉得还好,这个算是强迫你提高可读性.不过,有时候搞乱了,然后就很痛苦了.设置好的编辑器往往帮助你维持恰当的缩进.不过有时候跨平台换个编辑器,就容易出问题
我一直有个疑问,java的性能应该是很不错的,可以用来写各种存储管理系统.可java的gui程序怎么就那么烂呢? 我觉得python的gui程序都比java好很多!
好多人吹的，特别是google捧的那个有力，本来是想看看能不能用python写网站程序，结果一看到用缩进来代替结束的大括号，感觉特别不习惯。不习惯还好，就是特别不放心。万一不小心把缩进搞错了，那还不乱套。短点的程序还好，长一点怎么办。总不能为了代码段的短小精悍搞出无数的小函数吧。
对了，建议给标题加上【原创】，然后在数字后面加个短小提示，点名本节讲什么内容。
Go的性能理论上是接近C的。因为Go是直接compile的。但实际上的性能受到很多方面的影响：
1 compiler的实现。目前Go有两种compiler，Xg/Xl系列（X是数字代表architecture，目前支持x64,x32和arm，分别是6,8,5，g代表compiler，l代表linker，这套都是从plan 9来的），还有就是gccgo（gcc的frontend）。Xg/Xl系列编译非常非常快，这也是Go的一大特点，但优化相对就不够一点。gccgo编译慢，优化好，和C可以直接连，但还有一些feature没有实现（最终会一样）。Go team也考虑过LLVM，不过目前LLVM还是太庞大了。
2 库函数的实现。很多benchmark要进行公平比较的话，需要特殊优化的库函数实现。
3 GC。Go是garbage collected的语言。好处自不用说，但性能就很受GC的影响。目前的GC还是要stop the world，还不是很理想，新的GC正在实现中。
有的网站给出了对各种语言的benchmarking，结果对Go不是太好。不过其实很多是因为Go的库函数实现不够优化。比如有些benchmark中，C和python用的库都是有assembly优化的，但Go没有。
总体来说，Go的性能应该比C/C++差一点，毕竟是GC的。但应该不会比Java差。Go已经在Google内部用于某些production system了。实际表现如何，我还要在实际的project中看。有机会会来报告。
另外，python缩进问题，最大的问题是很多editor对于tab/space有不同解释。所以很多人一起工作的话，没有一个coding standard，就会一团糟。而这个问题完全是没有必要存在的。
Java的GUI难道大家不都用Eclipse的库了吗？自己的那套应该没人用了吧。Java目前更多是一种server language，desktop已经不是很时髦了。
感觉和Groovy 与Java 的关系类似。感觉就是不同级别的应用需要不同特性的语言，于是衍生出很多很有特色的语言。
Groovy, Scala, Clojure, Jython, Rhino
python没有编译
但是对缩进的检查还是很仔细，如果有不正确的缩进会提醒你
当然逻辑上的错误缩进，就得自己弄，这其实跟大括号一样啊，大括号你也得括对了
并且好多工具帮你处理缩进
很多IDE在你打上半个括号的时候自己就给你加上下半个了。所以你很清楚什么时候scope结束了。缩进就不一样了，完全要自己控制。最大的问题其实是难读，不小心把缩进搞乱了，就回不去了，要是space,tab混在一起，更是没办法看了。总之是增加没有必要的麻烦。上一个这样做的语言是fortran了吧。
因为协程本质上就是自己的代码彼此协作以更适合程序逻辑的方式做任务调度，避免阻塞，而OS和硬件实现的强制线程轮换虽然肯定不会更适应程序逻辑 但效率极高，编程难度也要小很多很多。
当然只是个人感觉，我尝试过。代码规模一上去，我很怀疑其复杂度会达到难以控制的地步。
当年可是认真研究过netty源码的，不过现在netty早就升级改名叫mina了。
zllwy对erlang有没有兴趣，我现在比较关注erlang，尽量回避java/c，呵呵！
我在emacs里，无论写什么，一般都设成只认space，反正按tab在emacs默认就是补全或者是indent。现在几乎所有IDE的python mode（如果支持的话）里，是没办法直接输入tab的。说起来的话，python里用vim的比较多。
我觉得写python最重要的是代码块绝对不能写太长，超过一定长度就要把代码拆开。太长的当然也可以看，不过需要一个好的编辑器。比如说像emacs那样有outline mode的。另外缩进一般要控制好，一般的代码一两层就差不多了，四层千万到顶，以后要是加上try的话，直接变五层了。
python可以说是典型的对编辑器（环境）有强烈信赖的语言，用windows默认的记事本，哪怕是看python代码，那也是杯具。
windows下面，其实用notepad++或者editplus这样的就差不多了。
python的这些特点导致了整个社区对代码规范的极端重视，具体的体现就是这个：Style Guide for Python Code。这应该也是很多公司推python的原因。你要是不按规范写，自己都甭想好过。不过话说回来，python的自带的库里，好多代码也不是完全按PEP8来的。
话说回来，遵守不遵守PEP8开头就说了，按你的兴致来，自己觉得合适就行
FORTRAN还是看你用的编译器和FORTRAN标准，有些编译器和标准一般不是很区分空格和TAB，甚至是语法。我自己写FORTRAN的时候，不管是不是F90，一律用gfortran编译，才懒得理这个函数到底应该算f77还是f90呢。