golang年度使用总结,简洁不简单

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_26981997/article/details/52079972

时间过得好快,比较正式的使用go语言,已经接近300天了。这期间,go从1.5发展到了1.7,自己因为兴趣+责任,来到了新的团队,再次从事曾经非常熟悉的开发工作,充实!

竟然在玩scala之后,用了go语言

最初了解go语言,还是13年原单位一个项目。在不涉及到数据库操作的情况下,技术团队用.net竟然无法支持500/s的tcp峰值请求。本欲捡起Java,结果无意中知道了go。发现,用go的select非常非常简单。但因为其编程思想和传统OO差别很大,极不习惯,就没有跟进。
再次接触就是2015年,这期间正痴迷Scala,加入了一些scala的群。喜欢scala比较简单:
1. 语言精炼,代码优雅
scala的模式识别、类型推断实在是太舒服了,利用lambda(这个java8也有,但scala更纯粹)、集合库,几行代码就可做不少事。而且,好多设计模式的东西,在语法上就可以处理。比如Null Object可以用Option直接替代。代码越少,问题越少,是吧!
2. 入门陡峭,喜欢高智商
好多人都感觉这语言入门比较难,主要在FP思维模式与传统过程式思维不同。
3. 分布式actor模式,简化了多服务器的同步
从设计上,actor模型确实非常不错,加上akka框架,在多服务器之间可以简化服务发现、消息分配的基础框架工作。这对于业务开发确实提供了很大的提升。因为自己在这块没经验,不好评价其具体性能。
这期间,最让人蛋疼的就是SBT。本来SBT是个好东西,但下载太太太慢了。这本来与工具无关,但在天朝,必须折腾,你懂的!
然而,说再多的好处都没用。回来创业的朋友(我现在所处团队)做游戏,招聘有经验的scala程序员没成功,再考虑客户端基本都是c、c++经验,技术路线尽量贴合,就再次回到了go。都说go简单,是吧!?事实如此?

对go语言的对比评价

客观的说,目前半年,服务端开发还算顺利。偶有闲暇,还是会看看scala,也很喜欢与go做对比。
作为一门语言,当团队选择的时候,考虑的一般是工具与资源,语法难度,效益待遇。

工具与资源

谁都知道go是google搞着玩的,scala则是Lightbend(原来叫做typesafe)的安家之本。想都不用想,两者出生基本不是一个层次。客观而言,工具与资源与语言的发起单位的商业化程度有关。
- 开发工具
开发工具方面,除了LiteIDE,其余都是以插件方式在Idea、Eclipse、Sublime等上运行。个人主要用于Idea,因为重构非常方便,go的插件更新也很快,基本上晚上提交feature之后,睡一觉,就已经处理了。但距离Scala,工具支持程度相差一个层次。比如修改了接口,插件是不会重构“实现类”的接口方法。一方面,scala插件是官方的;此外,go的接口模型与java系的不同,没有显式定义,语义推导要难的多。
- 第三方资源
资源方面,最著名的docker以外,etcd、consul、groupcache、nsq都非常不错。个人目前用了consul,另外的简单研究过代码,但距离使用还有段时间。相对于scala的spark、akka、play、Spray这几种,go的框架gin、beego、xorm等等,其实都不错,但侧重于局部功能,不及scala的全面,还没发现分布式数据处理框架。

语言语法

  1. 语法二义性少,上手容易。
    go的网络底层封装好,无明显bug(当然http2.0还待完善)。除了defer与go、chan之外,代码无特色。缺少三元操作符、泛型、枚举,代码多了会感觉很啰嗦。也许正因为如此,任何人都能够迅速上手。
  2. 对设计模式的依赖依然很强。后期提升比scala难。
    相对于scala在语法阶段就封装了大量模式,go的代码要原始一些,要写出漂亮的程序,就得费点功夫。要做出好的服务端,原来的设计模式、架构模式,以及其他类似C语言、linux的使用积累也很重要。相对于scala,后期的成长曲线要陡峭一些。成为宗师,没有捷径。

    • 比如:判断集合不同项
      找出两个集合的不同,scala只需要几行,而go语言,试试20行能否搞定。
    • 比如:设置执行的结束时间点或者强制退出
      scala基本是在语法或者actor模型中会有大量讲解,而go则是利用csp来做,涉及到复杂业务要考虑封装。事实上,官方源码中的context包已经提供了一种模式,非常巧妙。可惜,介绍的比较少,需要自己去探寻,学习成本不比scala低。依然要高智商!
  3. 代码阅读难度
    因为golang的代码格式是强制性的,基本上阅读起来比好多语言容易。但涉及到运用了channel的模块,因为非常灵活,有的coder写出来的代码,不问一问,真的不懂。^ _ ^这个涉及到代码构架风格,又没有在原来偏OO的《设计模式》中有过论述,我想以后应该会有一些好的经验方法。

前途,钱途

好多人学习一门语言,不是因为兴趣,而是待遇。这是现实,不得回避。我自己认为,绝大部分不可能精通两门,尤其思维模型都不同的开发语言。所以,面临选择很正常。
个人认为,待遇与语言无关,而与行业、具体单位效益、运气相关。前段时间面了一位硕士研究生,网络传输设备嵌入式开发15年,待遇只有6500,不如我们现在团队从事服务端开发不到1年的专科毕业生。同行业不同单位的就不说了,传统领域中,央企、事业单位,与私营企业的对比,那是黑白一样的分明。

Scala还是go

无论什么开发语言,除了语法和部分框架,大部分模式、架构、以及专业背景知识是相同的。语言不同,更多体现在于结合了工具、生态链之后,各有擅长的一面。很多时候,语言选择,在于业务需要和团队基础。
1. 业务方面
同属于服务端的程序,scala侧重于数据分析预处理,集合库太方便了。其他的业务处理,包括行业应用,go并不会其实没什么区别。如果是游戏开发、物联网,go还更适合一些。想想看,256M的运行内存,就可以很轻易的做到5K以上的长连接+内存业务处理,是否很振奋!
2. 团队方面,
如果团队允许1年左右的时间折腾,java资源很熟悉,有大量的服务器资源,选择Scala不错。原谅我,我始终认为scala的actor模型非常占用资源。本质上,scala只是从语法上封装了Reactor(Proactor)架构+Bridge(或反射)来实现消息分发与响应(akka还封装了服务发现,与consul一样用的gossip协议)。只是我们显示的看到这个框架而已。不过,面试scala程序员的时候,筛选成本低很多,这其实是个优势。
如果三个月就得出个大并发的服务端,团队成员C(C++)比较多或者成员层次不齐,老板在乎服务器费用。go的选择不错。这玩意就好比国外的高考,宽进严出。没有优秀的代码,总比没有代码好吧?!难题在于,golang的业务实现太灵活,如果有人说搞过一年go,价码不好判别。

对我而言,两门语言都非常喜欢。scala的语法封装了大量的设计模式,这大大减轻了开发成本,侧重于“用”。而go语言则胜在语法简单却又不失亮点:静态部署、多返回值、函数+闭包、简单的并发+消息通道,更侧重于“创造”。也正因为go语言核心语法的东西不多,到了中后期,做出好的程序框架要比scala烧脑。要真的能把csp玩转,还需在《设计模式》之外需要积累很多经验,需要继续努力!

对go的期许,别只是Better C

要把一门语言玩得转不容易,个人也看好go语言的发展,但目前的它相对于迅速发展的swift、rust,就好比简陋的毛胚房。据说golang1.7支持pkg包直接编译,这独立开发商提供了可能。个人希望要是能尽快提供以下几点就好了:

  1. 统一的包管理
    缺乏明确显示的版本,依赖的完整性无法校验,一直是团队面临的工程问题。迫切需要类似于marven、sbt这样的存在。godep、govendor、glide、gvt……太多太多,八仙过海。一个,统一,即可。
  2. 泛型、枚举支持
    都说java的泛型其实内部也是动态转换,但编译期发现问题不是要更好一些吗?论坛提到了golang 2支持,不知道什么时候。
    至于枚举,尽管可以通过类型定义做简单验证,但依然开放式,限制太少。go不是强调一致吗?
  3. 更多的数据结构基本库
    目前,container容器内仅有双向链表、环形链表、堆。红黑树或AVL树,队列,明确的栈……,没有。依赖于第三方,或者照着教材写一个,始终麻烦。
  4. 三元操作符
    这个本来只是个细节,但渴望这个语法糖。否则看到if就意味着3-5行。(或许会扯到隐式转换问题,这个我就不管了。)
  5. 其他
    如果可能,lambda、FP、集合库,我也非常非常喜欢。但愿,别让偶做梦太久!

杂七杂八写了不少,临时想的,没太梳理,就这样吧。

阅读更多

没有更多推荐了,返回首页