主题：【原创】介绍一下Go语言（1）之前的话 -- zllwy

一般而言，我们说到Simplicity，很少指标准库的丰富强大。

自问还没有能力很好的定义对于一个编程语言来说，simplicity是啥，但是我觉得有些例子，

比如ruby的meta programming，比如python的 generator，再比如C#的delegate。

python -m SimpleHTTPServer 8000

这可也是用自己的标准库,而且干的事情比你的还实用些呢,呵呵

什么是语言的简单性，是个很有意思的讨论。

我倾向于认为simplicity是指语言设计上的简单性。但语言的易用性是另外一个概念。Design simplicity并不意味着使用上的容易。Go的特点是设计上很简单，比如Go只有25个关键字，比大多数语言都要少（当然不是simplicity绝对的比较），还有Go的compilation不需要symbol table等等，再加上互相独立的一组强大的语言功能特性，使得语言使用比较简单。其实python也有这个特点。设计简单，但功能又很强大，让人不用学太多的复杂语法就能上手。

你说的几个例子我感觉是语言的功能强大，使得程序员可以简单地实现一些程序结构，这个更多的是易用性。实际语言本身，我觉得ruby和C#的设计其实不算simple。

至于库，其实越来越成为一个语言不可分离的一部分了。不过我那个例子的关键并不在于库。即使Java之类的语言有同样的库支持，写出来的代码也要冗余不少。看来大家不满的是觉得这个例子不够充分说明Go 的简单易用，虽然我个人觉得还是很能说明的。这个就是个人观点的差异了。

我承认python也很简单（虽然其实你要实现我例子中的代码的话，python的code其实也不比Go少。哈哈）。不过这个跟我说Go写代码很简单不矛盾吧？其实公平比较应该是static language和static language比。Go就是个better C，或者C + python。Go的source code感觉冗余比较少。就像Java的public static void main()，实在是太罗嗦了。:-)

"正是因为Haskell作为functional language本身的约束（没有side-effect）导致的结果"

That's exactly what I meant by saying "inherent succinctness". This is precisely what matters for simplicity: the nature of a language's power by design. Now you've got it, yet you dismissed it as a trivium, what a pity.

PS: Simplicity of a language is not measured by how many keywords it has or does it use symbol-table during the compilation process, these are true trivia. Otherwise, one would argue LISP is the simplest language there ever is.

Well, much confused by your introduction, I went ahead reading the tutorial and specification of the Go language, and wrote a couple of small programs myself, I can see the power of this new language clearly resides in the go-routine concept, which makes the concurrency much easier to handle than most of other languages.

If I would evangelize the simplicity of this language, I would've chosen the example of goroutines, which is a heck lot better demonstration.

那代码写的。。。overload的确是双刃剑啊，用得合适需要智慧

That's exactly what I meant by saying "inherent succinctness". This is precisely what matters for simplicity: the nature of a language's power by design. Now you've got it, yet you dismissed it as a trivium, what a pity.

No side-effect到底是好还是不好仁者见仁。从某种程度上来说也是导致haskell流行不起来的原因。即使是functional language本身，也不完全抛弃side effect。目前的趋势是在procedural language里面加入functional的元素。我可没有dismiss这个design，只是觉得对大多数程序员来说，这是更是一种约束。而通过增加限制条件来simplify在我看来并不是真正的simplicity。

PS: Simplicity of a language is not measured by how many keywords it has or does it use symbol-table during the compilation process, these are true trivia. Otherwise, one would argue LISP is the simplest language there ever is.

当然不是，只是从一个侧面来衡量。No symbol table也不是true trivia，而是为了简化compiler，提高编译速度考虑的。

Well, much confused by your introduction, I went ahead reading the tutorial and specification of the Go language, and wrote a couple of small programs myself, I can see the power of this new language clearly resides in the go-routine concept, which makes the concurrency much easier to handle than most of other languages.

If I would evangelize the simplicity of this language, I would've chosen the example of goroutines, which is a heck lot better demonstration.

goroutine正是我选择go的最主要原因。我在第1部分写得很详细了。另外我在第4部分里面重点写了goroutine。web server只是一个简单的小例子。如果你觉得不好，为什么不再补充一篇呢？

也许我是写得不怎么样。不过能引起你的兴趣，我的目的也达到了。就算抛砖引玉吧。

4:21 PM

我觉得简单性应该是指使用的简单性，任何一种工业上可用的编程语言，其设计上必需是复杂的，必需提供一大坨业界需要的功能。

使用上的简单性，就是说这种语言能把很多概念抽象出来（比如算法，比如数据结构，比如编程思想），用一种简单的近似于透明的方式，暴露给代码民工们。最简单的例子就是GC了。 这种使用上的简单性，在设计实现上往往是非常复杂的。但是，码农们不需要自己需实现jvm啊，理解GC的概念以后，用起来爽就可以了。

其实我们说的不矛盾。我说的设计是语言本身的设计，你说的设计是实现上的设计。以Go为例来说，它的语言设计很简单，其中一个目的也是为了编译的速度。但它的实现其实比较复杂，比如goroutine和channel的实现，gc的实现等等。

你写的这些关于Go的帖子我很感兴趣，都认真看了，我还跑网上找了一些教程等看，还顺便看了看Lua的资料。就象吹西门的雪兄说的，Go的让我最感兴趣的地方是goroutine（另一个是duck typing和对继承的处理）。引起我的兴趣，这个目的你的确是达到了，但是你的第4部分里写的，让我这个对这方面不熟悉的人，感到心痒痒，但是又有没有搔到痒的感觉，不太好受。主要就是术语比较多，但是缺少解释，也许有基础的朋友看了没问题，但是对我来说却是有点懵。所以希望能进一步讲讲这方面的内容。

有两个问题想请教一下：为什么goroutine能比线程轻得多？通过channel来通信为什么比通过内存分享来通信要可靠？

对后一个问题我的理解是，通过内存分享来通信，得时时刻刻注意着race condition的问题，因为这有可能在程序的任何一点发生，编译器的优化使得理解和控制race condition更为困难。但事实上同一个程序中那些并行的部分并不需要这样时时刻刻保持通信的状态，它们之间是合作的，只需要在大家都知道的特定的点为特定的目的而通信，所以channel就大大简化了这种状况。还有比如java中，即便两个methods都是synchronized，如果顺次呼叫这两个methods，有可能还是得在放在一个synchronized的块里，也就是说java的synchronized机制是局部（不知应该用什么词）的。而channel的通信却天生是全局的，一个message只可能给收听这个channel的若干goroutines中的一个，于是在一个goroutine里面完全不用考虑其他并行的goroutine的影响。但我不知道是不是还有其他的用channel通信的优点。

最近在考虑一个包含数据库的系统框架，所以非常关注系统内部应用层的编程语言。希望一定是一个脚本语言，以得到好的开发效率，以及在今后的应用中 real time deploy。因为系统时常有大量运算(文本及数值负载都很重）所以计算速度也很重要。又考虑系统的构成有很多部件，开发资源，维护资源（人力，财力）有限，希望尽量采用开源软件.python本是一个不错的选择，可是在速度上有短板，特别是GIL限制了多线程，现在看不出来在重新写过cPython的垃圾处理机制前有什魔希望解决，最近Google限制内部使用python的谣言让我但心JIT项目不会太顺利。

Lua在速度(JIT)，内存效率，多线程上有巨大的优势。可是有如下缺点

1) 社区没有python发达，库资源的丰富程度及文档支持远没有python丰富。

2）语言没有Python丰富，对我来说特别是缺乏OOP的原生支持和缺乏装饰模式的原生支持最恼火。（我们希望用装饰模式实现对原语言特色进行非侵入扩展，本来改Lua及LuaJIT的内核也可以加入额外的语言特色，但这样就可能在用其他Lua库时有风险，并且不能自动支持Lua升级）

希望得到熟悉Lua的河友指教。特别在如下方面：

1) Lua在构建大型系统时有何缺点。

2）介绍一下成功的Lua开源库，如:数值运算，网络支持，web应用，图形界面，2D-3D绘图,分布远程运算，日期时间时区。

3）LuaJIT在运行实际大型系统时的效率如何

4）Lua的程序量比相应的python差多少，比C好多少（代码的表达效率：如python可以用C 1/6.5的代码量实现同样功能）。

如果能像zllwy河友一样，系统介绍一下就更好了。

谢谢

先解释一下为什么goroutine比thread要轻。goroutine是用户空间的，所以切换goroutine要比thread的花费要小。thread的初始堆栈比较大（几个MB），而goroutine初始堆栈比较小（20KB），而且是动态缩放的。所以可以同时创建比thread可以大得多的数量的goroutine。

我觉得你对channel的理解是对的。本质上通过share memory来通信使得程序引入了非确定性。两个并行的程序如何访问一块共享的内存，其执行过程是不确定的。但如果通过channel，那就很明确什么时候要通信。至于性能，不是最主要的。因为channel很可能就是利用mutex来实现的。channel是比buffer/mutex更高一层的抽象。主要的目的还是使程序逻辑本身更加清晰，减少发生错误的可能性，尽量把非确定性缩小到可控的范围（比如channel底层的实现）。有时候为了性能需要，mutex也还是可能需要用到。比如在go的mailing list讨论过goroutine的barrier的问题。如果同时生成一组goroutines，需要等他们都运行结束然后取所有的结果。这个barrier的实现可以用channel，但效率比较低。Go还没有一个好的抽象来解决这个问题。最高效的方案还是用mutex来实现。

是说HP的Dynamo吗？

类似的，但不局限于在同样的指令集上模拟自己的还有IBM的DAISY。其实最著名的是Crusoe，曾经很火的Transmeta公司现在已经无影无踪了。

x86->Itanium

是个习惯问题，如果先接触C/Java，用括号习惯了，一下子换成缩进有些不适应。