主题：【原创】介绍一下Go语言（1）之前的话 -- zllwy
int *c[10] -> var c [10]*int
int (*c)[10] -> var c *[10]int
It will be a mess if there are "const".
无论是operator还是method overloading
记得当年自学C++的时候，看到operator overloading，惊为天人。但是到了看别人程序的时候，才明白如果一个短短的表达式里面有几个operator是overloaded，然后每个操作符都要小心翼翼的去查证是否是overloaded，那叫一个痛苦。
所以后来看到java没弄这个劳什子，还是很开心的。
method overloading相对好一点，但是如果一个程序员被逼迫到需要用同一个函数名去处理不同的事情，那么要么是这位词语比较贫乏，要么是被requirements给逼的。
我也很讨厌operator overloading，尤其从读代码的角度来说。科学计算领域似乎确实有这个需要。想象一下a+b都要写成add(a, b)也是挺痛苦的。不过一般语言里面有限的几个operator也不够用的。可能应该允许定义自己的operator。这就是另外一个话题了。
还是很强大的，有了prototype，后面跟几个参数都是确定的。
expression我看主要还是兼容以前的写法，表达能力其实只是对二元操作符最合适，遇到一元的就只好上括号，或者骑到别的操作数肩膀上来避免歧义了。遇到Σ这样键盘上找都找不到的操作符，函数才是最终的办法。
我倾向于统一用函数调用，只在不产生歧义的地方使用expression
基于VM的东西，优化的空间有可能更大
没有vm的语言，比如C之流，全靠编译那个时候的一下子优化，一锤子买卖。有了VM，可以做jit，速度更快也不是不可能。
动态优化不一定要一个完整的跟jvm一样的虚拟机。
如果单纯的按照字面意思做jit，把vm的指令改写成native code，那样其实不快多少的。更快的是做动态profiling，然后找hotspot优化。jvm在1.1就有jit了，但是到了1.2才做出hotspot jit来，那个才是性能可以和C这种有一拼的时候。
像C这种，如果编译的时候加了标记hotspot的代码，另外和动态优化库链接，那么还是可能做到动态优化的，而且不需要完整的VM
此外我感觉动态链接库的优化很难啊， 因为同一个so或者dll可能会被同时load到不同场景的应用里面去。
不过那个时候不是针对C的，是在汇编级别的二进制翻译+优化。很大的一个跨国的项目，不过后来目标机器没火，就算了。
具体实现就是在翻译以后的机器码里面加轻量级的计数指令，用来发现hotspots，发现以后进行优化，基本上是干basic block合并，预取这些常规优化，还有针对目标机汇编特性的优化。
效果还是不错的，benchmark这些作弊很容易的事情就不提了，几个比较常见的应用跑起来都很自如。考虑到这个是跨硬件平台的转化+优化，能做到和原来硬件平台跑的一样好（正确+性能），已经很不容易了。
不知道为什么那么多人讨厌缩进，我一点儿感觉都没有啊
难道写C/JAVA的时候人们都不缩进吗？
A simple web server:
package main
import (
"fmt"
"http"
)
func handler(c *http.Conn, r *http.Request) {
fmt.Fprintf(c, "Hello, %s.", r.URL.Path[1:])
}
func main() {
http.ListenAndServe(":8080",
http.HandlerFunc(handler))
}
Frankly, I don't see much "simplicity" in this snippet of code. Any decently flexible descendant language of ALGOL60 can wrap up and give apparent simplicity like this.
The real "simplicity" only becomes evident when it can handle otherwise complicated programming tasks with clearly and cleverly crafted model.
Don't get me wrong, I am not saying Go is not a decent language, just this example you gave is not convincing at all.
不过我在这里想说明的是，只用语言本身和语言提供的库，来实现这么一个web server，Go的代码量可能是在最少的那端。而且并不像你说的是syntax sugar，这里面没有任何花里胡哨的东西，完全是任何看得懂C的人，不需要学习Go都能看懂的程序。
我更想说的是，程序语言就是应该这么简单。其他很多语言要写更多代码，就是因为搞复杂了。写一个简单的web server，实际上就只需要这么些代码。
对了，这个例子不是我提的，是Go team在一个talk的slides里面的一页。我想还是说明很多问题的。
The short length of the code that implements a dummy webserver does not proof anything. With enough wrapping code underneath, one can write a C++ library that eventually allows a beginner to implement a dummy webserver with same LOC, or maybe shorter. Node.js can do the same short implementation for a simple web server.
The point is that the shortness of implementing things like this does not illustrate the inherent succinctness of the Go language. There should be better examples in aspects such as the easy control / expression of concurrency, etc.
For instance, in Haskell, a good example is that you can implement complex constructs such as transactional memory in insanely small LOC while that is not possible in any ALGOL60 family languages. That's the true demonstration of the power / simplicity of a language.
All in all, Go is a promising language, but not that outstandingly impressive. Or, maybe not yet.
我们在争论不同的东西。我只想说：
“Go很简单，只用自己的库就可以写很短的一个web server程序。”
你非要说
“Go不是最出色的，其他的程序语言包装一下也可以这么短。”
完全是南辕北辙。网络上的争论，往往就是陷于这样的意气之争。哈哈。
还有啊，你说程序长短不说明问题，我完全不同意。你去试试用Java/C/C++/python/javascript写同样的程序，只准用自己的标准库。
再说一下Haskell，之所以STM在Haskell上容易实现，正是因为Haskell作为functional language本身的约束（没有side-effect）导致的结果。在传统有side-effect的语言里面，实现STM是一件很难的事情，到现在Microsoft和Intel也都只有research project（比如STM.NET），而没有产品，虽然都已经说了好多年了。关键是STM的性能问题，以后可能要靠硬件解决。