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

时间过得好快，比较正式的使用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、集合库，我也非常非常喜欢。但愿，别让偶做梦太久！

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