西西河

主题:【原创】介绍一下Go语言(1)之前的话 -- zllwy

共:💬92 🌺231
分页树展主题 · 全看首页 上页
/ 7
下页 末页
                        • 家园 你后面说的优化c的方法,是设想还是有了实现?

                          此外我感觉动态链接库的优化很难啊, 因为同一个so或者dll可能会被同时load到不同场景的应用里面去。

                          • 家园 10年以前有过实现

                            不过那个时候不是针对C的,是在汇编级别的二进制翻译+优化。很大的一个跨国的项目,不过后来目标机器没火,就算了。

                            具体实现就是在翻译以后的机器码里面加轻量级的计数指令,用来发现hotspots,发现以后进行优化,基本上是干basic block合并,预取这些常规优化,还有针对目标机汇编特性的优化。

                            效果还是不错的,benchmark这些作弊很容易的事情就不提了,几个比较常见的应用跑起来都很自如。考虑到这个是跨硬件平台的转化+优化,能做到和原来硬件平台跑的一样好(正确+性能),已经很不容易了。

                            • 家园 Dynamo

                              是说HP的Dynamo吗?

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

    • 家园 【原创】介绍一下Go语言(3)Type system

      Go的一大特点是它的type system。在写这篇之前我发现自己其实对很多概念也一知半解,这里就先把type system的一些概念梳理一下。如果有谬误,希望给我指出。

      Go有很多方面和python很像。而python又是一个比较有代表性的语言,我这里就主要用Go和python做比较。

      首先是static type和dynamic type。static type简单说就是type checking是在compile time做的,而dynamic type是在runtime做的。Go是statically typed而python是dynamically typed。说一下我对这两者的评价。我是基本倾向于用static type语言的,特别是大型项目。支持dynamic type的人的最主要理由就是实际当中type error是很少的(我的体会是其实很常见,而且很难调试),所以到runtime去检查没什么,但开发要快很多。其实我不是很赞同。因为我觉得特别对于大型系统来说,coding其实不占主要时间,design和debugging更花时间。而且static type语言一般效率要高一些。综合来看,dynamic语言除了用来写script,tool比较好以外,真正重要的项目还是应该用static语言。

      然后是weakly typed和strongly typed。strongly typed是指任何使用value的时候都要检查它的type,对不上的话就不行。当然这个可以在runtime做(对dynamic type语言)或者在compile time做(对static type语言)。Go和python都是strongly typed。Javascript就不是。这里对python可能有些容易混淆的地方。python可以写:

      onevar = 1

      onevar = "1"

      这个不说明python是weakly typed。因为赋值给变量其实只是一个绑定,关键还是看在用它的值的时候是不是检查type。

      还有一个概念是type safety。你不能说一个语言是type safe还是不safe,你只能说多大程度上是safe的。比如C是某种程度上的safe,还是有很多漏洞。C++强一些。Java,C#更强。所以static type system不一定就意味着很强的type safety。

      再来讲polymophism,多态。C++用type hierarchy来实现多态。C++的type system比较复杂,有单继承还有多重继承。Java就简化了一下。Java的Interface提供了一定的灵活性。你不必一定要继承某个类,实现一个interface就可以实现多态了。实际上有人建议尽量使用interface而少用inheritance。这个后面再说。但interface的问题是如果有些第三方的代码你不能改,你就很难把它融入到你的type system里面来。这就出现了duck typing和structural typing。duck typing和structural typing很类似。都是说只要你实现了某些性质,你就可以被称为某个类。有人称为signature based polymorphism。duck typing的代表就是python,很有名的一句话就是:

      "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck."

      所以duck typing是看一个value是否存在某组属性来进行type checking的。structural typing也很类似,如果一个类实现了一组确定的接口,它就可以被当作那套接口定义的type。区别在于,duck typing是在runtime检查,而strcutural typing在compile time检查。Go是structurally typed。

      再来说一下inheritance和composition。如果你要subclass一个基类,你可以选择用"as-a"还是"has-a"。"as-a"就是继承,说明新的类是基类的一种。"has-a"就是组合,说明新的类拥有基类的能力。目前的主流看法是尽量用"has-a",也就是composition。这里就不展开了。Go提供了一些方便使得composition可以基本取代inheritance。这样Go的type system就非常简单了。

      现在可以来说Go的type system了。首先Go里面只有struct,没有class。但你可以在任何type上定义函数,设置在primitive type上定义。比如:

      type INT int

      func (a INT) printa() {

      fmt.Println(a)

      }

      这里你不能直接在int上定义函数,要先定义自己的type,然后在上面定义函数。然后:

      var a INT = 1

      a.printa()

      你实际上就是在整数类型上定义了一个新的操作。结合struct,你可以给任何一个struct定义函数。基本上,你可以把被定义的struct看做是那个函数的一个参数。这样我们就有类似class的功能了。

      如果你又定义了一个指针:

      var ap *INT = &a

      ap就也有了a的函数。你可以写

      ap.printa()

      更进一步,你可以组合struct来实现subclassing。比如

      type T1 struct {

      a int

      }

      type T2 struct {

      T1 // anonymous field

      b, c int

      }

      现在T2有了T1所有的东西,你可以直接写:

      var t T2

      t.a

      t.b

      t.c

      T2还可以直接调用T1的函数。

      再来看Go是怎么定义两个类型的可赋值性的(assignability)。如果你要把一个值赋给一个lhs,Go值看两边的类型是否完全等价。比如:

      type T1 struct {

      a, b int

      }

      type T2 struct {

      a, b int

      }

      在C/C++里面,这是两个类,是不能赋值的。但Go把他们当作是一样的。

      最后,终于说到interface了。如果你有这么一个interface:

      type Api interface {

      Foo(a int) int

      Bar(b float) float

      }

      这样只要任何一个type实现了这两个函数,就可以被当作Api来用。这样就实现了polymorphism,而且比用type hierarchy的要灵活。你可以比较容易地对你的代码进行改进,而不需要担心要对已有代码做大手术。

      元宝推荐:铁手,
      • 家园 关于这个type,我还是有些疑问

        有多少是从运行的性能考虑,有多少是从编程便利的角度考虑?或者说,哪个会更重要一些?

        我一直不太明白,那些解释型的,为什么就不能搞成编译性的呢?比如象 php 这样的,要编译成 opcode,然后再去执行,难道就不能直接编译成象exe那样的么,最起码,也可以提供这么个选项啊。为什么就没有。如果是为了多个平台通用,既然能搞出在不同平台上的解释器,没有道理搞不出不同平台上的编译器啊。

        • 家园 试着回答一下

          我想关于type system的设计,主要是从为程序员提供比较好的工具考虑的,目的是能精练,准确地表达程序的逻辑,同时保证程序的安全性,可读性等其他方面的要求。性能考虑也有。比如Go非常强调语法的简单性,使得编译器设计比较简单,编译速度也比较快。

          至于解释型和编译型的区别,其实界限也不是那么明确的。比如Java,gcc就提供了编译器gcj。虚拟机起到了把语言本身和平台隔离的作用,这样虚拟机和编译器的实现都相对比较简单一点。另外,很多解释型语言的一些特征,在虚拟机上实现容易一些。其实对这样的语言进行编译也不见得就有什么优势。虚拟机目前的技术已经能够实现比较好的性能,更何况虚拟机天生就有很多静态编译做不到的能力。比如动态优化等等。

      • 家园 Python很适合初学者

        对初学者来说,什么抽象概念都没有的情况下,那一套类型系统太复杂了,大大增加了入门的负担。

        而象Python或Matlab那样容忍人可以乱写代码,这对初学者来说很体贴。

        另外,初学者的代码都很简单,所以调试中的问题不大。

        这里的初学者指非计算机人员,但要写少量代码的普通人。

        至于专业人员,不论工作中用什么语言,都至少要把c/unix这套学通,才能生存下去。

    • 家园 听到netty这个词好亲切啊,呵呵。

      当年可是认真研究过netty源码的,不过现在netty早就升级改名叫mina了。

      zllwy对erlang有没有兴趣,我现在比较关注erlang,尽量回避java/c,呵呵!

      • 家园 erlang,听说过,当时是找jabber server

        以前有段时间想给西西河弄一个 jabber server,基于XMPP的开源标准,类似MSN这样的即时聊天功能。(现在的google talk似乎也是基于xmpp)。找着找着,就碰到一个用 erlang 写的服务端。刚才查了一下,还在 http://www.ejabberd.im/。

        看上去挺有趣的。不过最后还是没弄。

        • 家园 确实有趣,不弄也不是遗憾

          jabber这玩意儿我也动过心思,当时公司大老板猪油蒙了心,让我们IT部门选型弄个内部的IM,还不能要钱,于是就被jabber迷住了,服务器端试了好多种,客户端几乎试遍了,服务器端不说了,还都算不错,客户端就没办法说了,多人会议、文件传送、中文支持这三样能完美无缺支持的都没有,jabber,这名字起的,还真是一首晦涩的长诗。。。

          • 家园 原来试验的时候,我记得中文是可以支持的

            多人会议,记不得了,好像也是可以支持的,文件传送,这个可能没有试过。印象中好像是linux下比较常用的一个软件,也可以连msn,yahoo im的,忘了叫什么名字了。

      • 家园 有兴趣,有空你说说吧

        netty和mina不是同一个project,netty是redhat/jboss的,mina是apache的。不过干的倒是同样的事情。

        • 家园 04年我就开始用netty了

          后来有一段时间netty不怎么更新了,主要作者一个韩国人推出了一个类似的开源项目mina,我就改行用mina了。一度以为netty被废弃了。刚才查了一下,netty还继续存在,所以我说netty改名叫mina是错的,呵呵。多谢指正。

          外链出处

          我是09年进入erlang领域的,erlang可说的太多了,一下不知道说啥,以后找机会慢慢说,呵呵。

分页树展主题 · 全看首页 上页
/ 7
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河