go杂记

  终于有空看看go的tutorial.
  
  粗鲁看下,开始并没觉得有什么新意.
  很中规中矩的语法.

  当然,少不了带有python的一点风格.
  或者也不能完全说是python的风格,而是类动态语言的风格:
  运行时类型绑定.
  
  在基本数据类型方面,算是正式把c/c++里的一些潜规则内置为语言基本属性了.
  比如uint,int32等.
  既然需要明确数据类型大小,那就直接上升为语言特性好了.

  注意到它们之间是不能直接转换的.
  这个也许是出于安全考虑?
  尤其是32和64以及有符号和无符号之间,隐式转换应该确定为一个怎样的效果呢?
  不能确定,于是就限制为只能显式手工转换了.

  在众多常见的数据类型里,还有一个是string.
  这个应该算是必不可少的一个类型吧.
  跟其他语言稍微有点不同的是,string是不可写的.
  也就是说,对于实际上string底层所指向的内存区域是不可写的.
  至少在语法上是如此.
  
  按照文档上的说法,其实就是const的语义.

  值得注意一下的是map这个类型.
  在所知的大多数语言里都提供有map功能,但是作为一个内置数据类型,go应该算是比较特殊的一个.
  但是想想.go的创造者和推动者是google,想想google搜索下面的mapreduce就明白了.
  很好奇go底层会如何实现这个map,让他便捷快速轻量而又泛型.

  不过泛型map应该归功于语言本身的动态属性吧.
  很好奇一个据说有gc功能的编译型语言,在没有虚拟机的基础上,是如何做到gc的?
  是在每个runtime上构建一个轻量gc么?

  同时存在的还有称为channel的东西.
  一个类似线程安全的队列或者pool.
  有着erlang的风格.
  尤其是配合go特色的函数定义--多返回值. 
  某种程度上,一眼看上去跟erlang是何其相似.
  不同的是erlang是functional programming language,没有所谓的变量.一切都是可推导计算的.

  有一点比较有意思的是go对于interface的定义.

  通常的oo编程,都会有比较严格的类层次关系.
  也就是说子类和父类之间会有比较明显的is关系.
  从语言角度上,通常这种is约束或多或少地会在语法上有所约束.
  比如java里的extends,implements.

  如果设计之初没有考虑到这种类层次关系,而后期需要让其重构符合的话,势必会对源代码产生影响.
  即使当初比较有远见地采用了统一接口.
  但是,不能保证接口的继承关系能覆盖特定特征的集合.

  而go的作法很巧妙,也很天才.
  既然这种is的关系是抽象出来的,那么,并不需要过多地把它变成语言上面的一种强约束.
  因为毕竟,这种抽象依据角度和站立的层面不同.

  于是,go选择了很松散的is关系定义:
  type Sample interface
  {
       sampleFunction( parameter Type1 , ... )(return_item Return_Type1 ...);
  }

  只需要对以及由的类进行统一抽象,那么即便是在后期,也可以做出不同的is关系.
  更多的时候,这是一种组合式的is构建方式.

  对于一些敏捷开发方式来说,这个对于迭代式建模开发其实是一件利器.
  虽然,某种程度上说,需要这种方式的设计,本身也并不能算是一种非常良好的架构.

  但是,却能产生一个良好的架构.
  毕竟,从开始,需要限制的条件就不多了,于是后期系统少了更多的限制,也就多了更多的自由.
  这就是所谓架构的伸缩性.
  过多的假设是制约的是未来发展的弹性空间.

  且不说这个interface的风格,至少个人是比较喜欢的. 
  至少觉得描述能力比较强.
  尤其是做一些REST风格的,或者需要自我描述性比较强的场合.

  一个或许能动态解析,甚至动态层次化的结构的特性,多少算带给人新的思路.

  如同当初erlang带来的绕道的思路一样.
  
  不过,话说回来.
  go也许很适合google,但是google能不能把它发展起来,还持观望态度.
  虽然据一些测试,go对于高并发时候的性能还是很稳定的.
  但不出色.

  而且如interface的概念能让人眼前一亮,但似乎并不能找到很好的工程化的模式.
  也许,这需要时间吧.

  毕竟,在go之前,google也尝试了一个类java的noop.
  后来似乎没什么动静了. 
  也许是感觉跟jdk7的某些特性冲突了吧.