我的 Elixir 2016

作者 tony612 所属板块 新闻项目
转自自己博客: http://tony612.com/my-elixir-2016 (转载请标明出处) 回顾自己 2016 年的技术方面,Elixir 应该最值得一说了。这一年,写了一些、参与了一些、看到了一些、想了一些,正好在这个时间点记录下来,算是对此的总结,也或许能从我的视角看到 Elixir 的一些发展。 ## 开源项目 翻看今年的 [GitHub](https://github.com/tony612),虽然也就 400 多个提交,不算多,但却是一直坚持在业余时间写代码的结果,主要就是 Elixir。除了代码量的收获,所有 Elixir 相关项目总共到达 200 多个 star,也算是对自己的一种鼓励。 ### ExChat 上半年还在继续开发 [ExChat](https://github.com/tony612/exchat) 项目,基本的群聊和私聊功能已经实现,但因为不擅长前端等各种原因,后来进展一直很慢,现在已经停止开发了。之后打算还是稍微维护一下,比如保持 Phoenix 版本更新,以及可以运行的状态,但目前没有增加新功能的计划了。除非有前端/客户端的同学感兴趣,让我只负责后端,倒是可以考虑重拾起来。 [7 月份公司办了 Hack Week 活动](http://tony612.com/after-liulishuo-hack-week),现在看来算是一个转折点,ExChat 从那之后就没再动过。当时我们用 Elixir 做后端,还拿了二等奖。 ### grpc-elixir 从那之后,我开始想,要用 Elixir 做点什么。继续做 ExChat 还是再拿 Phoenix 做个什么应用? 结果是可能对 Phoenix 越来越了解,但一方面,我并不希望 Phoenix 变成 Elixir 的 Rails,另一方面,做这种项目,业务逻辑会占很多时间,以我当前的精力恐怕是很难在业余时间维护好的。那就造轮子吧,什么轮子呢?写个数据库啥的,以我的水平暂时怕是写不出来的,就整个简单的吧。碰巧 Hack Week 的项目需要用 [gRPC](http://www.grpc.io/),当时因为没有 Elixir 的库,只能勉强用 Ruby 搭了个 proxy,把一个 gRPC 服务转成了 HTTP。于是就想着要做个 gRPC 的 Elixir 实现,毕竟随着微服务越来越流行,加上 Google 的推广,gRPC 应该会被越来越多的使用,如果 Elixir 没有这样的轮子的话,岂不是很被动。 于是我剩下几个月就一直在折腾 [grpc-elixir](https://github.com/tony612/grpc-elixir),直到现在。一开始思路不太对,导致走了很多弯路,从九月份开始终于算是找到了方向。之后虽然有时会在一些问题上卡个几天,但整体还算比较顺利,到现在已经实现了 client 和 server 的基本功能(四种方式的调用),有了能跟 grpc-go 互相调用的 examples,Authentication 也快搞定了。接下来除了一些细节的处理,把 Benchmarking 做完,就比较可用了。 写 grpc-elixir 的过程还是有不少收获的。最大的感受是,Elixir 虽然年轻,但工具链简直完胜 Erlang,想想 Erlang 发展这么多年,OTP 做的是好,但工具链实在不怎么样,火不起来不是没有道理啊。而且我能感受到,Elixir 的生态已经在慢慢地超过 Erlang 的了,首先 Erlang 的库 Elixir 都能很方便地使用,另外我注意到一些高质量的库已经先考虑 Elixir 而不是 Erlang 了。其实我在刚开始写 grpc-elixir 的时候就想过要不要也支持 Erlang,毕竟有些逻辑应该是可以公用的,但考虑到效率问题,还是决定先用 Elixir 写了。 说到效率,这应该算是另一个收获。Elixir 在 [productivity 这一设计目标](http://elixir-lang.org/blog/2013/08/08/elixir-design-goals/) 上确实做的不错,没有太多冗余代码,就能很容易地实现需求,而且写出的代码很简洁、直观,利用 pattern match 对于二进制数据处理也非常方便。[宏](http://elixir-lang.org/getting-started/meta/macros.html)也是一个很好的工具,既能使得 API 很友好, 又能减少很多工作,对于 gRPC 这个需要有“生成代码”功能的项目来说实在很合适。当然,宏确实不是很好写,所以最好想清楚是不是一定需要使用宏,就算用也要尽量少用,毕竟像 Ecto 这种大面积使用宏的项目是 José 自己在写啊,真心学不来。 ### The Zen of Elixir 上个月整理了 [The Zen of Elixir](https://github.com/tony612/the-zen-of-elixir),用来收集一些“必看”的、“最好”的 Elixir 资料。因为一直觉得 Elixir 入门不算难,但要想学好还是需要多花点功夫的,而且并不是把语法、概念、文档记熟就够了,有些思想靠自己可能还是比较难体会到的。这些思想甚至不仅仅限于 Erlang/Elixir 方面,比如 José 自己就写过几篇很好的文章,我在很多时候即使不写 Elixir 都会想到,也经常会在 [Elixir slack](https://elixir-slackin.herokuapp.com/) 上看到被不同的人贴出来。而这些好的资料可能会被淹没在一大堆文章、视频中,所以才创建了这个项目,希望能够让其他人更容易发现,也方便自己时不时能回顾一下。 ## 社区 ### Elixir Shanghai 很多技术人其实并不怎么喜欢参与社区,特别是线下的活动,我也并不热衷于参加各种活动,还是喜欢自己多研究技术、写写代码。只是有时觉得定期的交流还是很有必要的,每个人可以学到更多,对整个社区都会有帮助,社区氛围好了也会促进语言的发展,然后又对每个人产生帮助,这是一个正向的循环。年初就看到北京那边在办 Elixir 的 meetup,让我羡慕了好久,到了年中的时候就在想为什么不在上海这边也组织 meetup 呢,反正这事情谁做都是要做啊。于是就创建了 [Elixir Shanghai meetup](https://www.meetup.com/Elixir-Shanghai/),然后找公司借了场地,想办法联系各种小伙伴,找演讲者,终于办了第一次 meetup。到现在一共办了 4 次,并且形成了每两个月最后一个周六的周期,每次平均会有10个人左右。因为社区还比较小,不管是演讲者还是找参加者,其实都不是那么容易,但只要有人肯来分享相关的内容,有感兴趣的人肯来参加,就已经是不错的开始了。 搞线下活动最有意思的就是认识各种各样的人了,既有之前比较熟的 Ruby 社区的,也有完全不认识,只是因为喜欢 Elixir 而凑在一起的,之前可能是 Erlang、Python、Go、Java 等后端背景,甚至是前端、客户端的同学。也让我感到办这些活动是很有意义的,至少我自己觉得每次大家聚在一起,听演讲者讲各种有意思的主题以及其他同学精彩的讨论,都会受益匪浅,然后鼓励我保持不断地学习,再争取分享给大家。 当然也学到了很多,除了直接从其他人那里学到的,因为怕主题不够,我经常只能自己充数,迫使自己一直要有新的东西拿出来分享,就怕每次讲的太水被大家嫌弃了。 ### Elixir China 之前一直觉得,Ruby China 的成功不可复制,[Elixir China](http://elixir-cn.com/) 应该很难像做得像 Ruby China 一样好,特别是现在社区比较小,语言流行度也不够,大家还不如潜心干点正事的好。近几个月突然态度开放了很多,有些东西,有比没有的好,即使做不成 Ruby China 那样的,但只要能沉淀一些内容,对其他 Elixir 学习者、开发者都是好事。虽然一个人的力量微不足道,产出的内容有限,但能贡献一点是一点咯,总会有人看到,会对别人有帮助的。所以最近还是经常有逛一下论坛,看看其他人的帖子,给个评论,有时会发发帖子。之前想发个分享,直接就发了,现在经常会选择先发到 Elixir China,再发到社交网络。 除了这些,最近还经常给 Elixir China 的代码提 issue 或者 PR,自己有空就 fix 一些 bug 或者加一些功能,既有了写代码的机会,又能给社区做点贡献。虽然我不觉得现在功能的完善是 Elixir China 当前最需要的(内容应该更重要),但还是能够改善用户体验,让大家更乐意去用。比如我在用的时候就发现不能直接上传图片、分享到微信的 title 不是帖子标题等可以改进的地方,都会有想要完善的冲动,于是就尝试去修复了。 话说回来,为什么会产生这些心理变化,我想应该是在运营 Elixir Shanghai 的原因,深知社区的运营靠一个人是搞不定的,还是需要大家的参与,而这里的“运营”基本等同于“参与”,任何人发一些不错的帖子或者是添几行简单的代码都是在“运营”这个社区,都是对社区很有帮助的。 ## 生态 我们常说,一个语言本身好不好可能并不会成为我们是否使用它的决定性因素,很多时候还要看它的生态。那 Elixir 现在的生态发展的如何呢?我不敢说看到了全部,但还是看到了很多有意思的事情。 应该大部分的 Elixir 开发者都会订阅(几乎算官方的) [Elixir Radar](http://plataformatec.com.br/elixir-radar/),它从 2015 年二月份到现在,几乎每周一期,已经有 79 期了,一开始只是些文章,然后又加进去了免费的招聘信息、各地的 Meetup 和 conf 信息。开始时招聘一般只有三四个,现在已经有几十个,实在太多放不下,他们干脆做了个[招聘版块](http://plataformatec.com.br/elixir-radar/jobs)。每次有 meetup 活动的时候,我都会联系他们,把 meetup 信息放上去,最近的一次居然没有了,后来收到他们的一封邮件说,Meetup 列表实在太长了,让大家还是直接去 [Elixir Meetup](https://www.meetup.com/topics/elixir/) 看吧,真是哭笑不得,让人感叹 Elixir 社区发展速度之快。 之前 Elixir 有两个 mailing list,一个是 [elixir-lang-core](https://groups.google.com/forum/#!forum/elixir-lang-core) 用于讨论 Elixir 核心的一些开发,一个是 [elixir-lang-talk](https://groups.google.com/forum/#!forum/elixir-lang-talk) 用于讨论问题和其他讨论。而现在 elixir-lang-talk 的 mailing list 已经放到 [elixirforum.com](https://elixirforum.com/) 的 [Elixir Chat](https://elixirforum.com/c/elixir-chat) 分类了,还是挺惊讶于 Elixir 团队这个决定的,毕竟印象中,很多语言核心团队的开发者都很喜欢用 mailing list,但其实比较一下就能发现之前 mailing list 每个帖子只有几十个浏览量,现在基本都是几百甚至上千,说明大家还是很喜欢和能够接受这种形式,毕竟体验更好嘛。另外,Elixir 团队成员也经常在这个论坛中发帖或者回复,[Elixir News](https://elixirforum.com/c/elixir-news) 更是已经成为了官方发布一些新消息的地方。 Elixir 语言本身则从 1.2 到了 1.4-rc,有关注过最近几次 Elixir Conf 上 José 的演讲的同学可能注意到,Elixir 除了语言层面的改动以及关注开发者的体验,现在核心团队非常关注如何更好地用 Elixir 来解决实际的问题,比如 [GenStaging](https://github.com/elixir-lang/gen_stage) 关注的是[如何更好的处理数据](https://www.youtube.com/watch?v=srtMWzyqdp8&list=PLE7tQUdRKcyYoiEKWny0Jj72iu564bVFD&index=15), [Registry](https://github.com/elixir-lang/elixir/blob/v1.4/CHANGELOG.md#registry) 则是从 Phoenix 代码中提取出来,让大家方便地使用。 其他的还有很多变化,比如 Elixir API 文档现在跟其他所有的 hex package 文档都[放在一起了](https://hexdocs.pm/elixir/),[使用 Elixir 的大大小小的公司](https://github.com/doomspork/elixir-companies)也在变多,出现了[各种各样的 conf](https://elixirforum.com/t/elixir-events-in-2017/2998),[awesome-elixir](https://github.com/h4cc/awesome-elixir) 的列表变得越来越长,ThoughtWorks 的[技术雷达](https://www.thoughtworks.com/radar/languages-and-frameworks)将 Elixir 和 Phoenix 都列为 TRIAL。 而在中国,参加 Meetup 的人慢慢变多,而且每次都有新的面孔。在线上,不管是 [Slack](https://elixir-slackin.herokuapp.com/) 的 #china channel,还是 QQ 或微信群,大家经常会有一些讨论。而且身边就有一些同学已经在生产中使用,以及写一些开源项目,造各种轮子了。 ## Elixir 2017 2017 年这些又会有什么变化呢?不知道,但应该会变得更好。 有些人说将来 Elixir 会变得很流行,有些人会问将来到底什么时候会来。我当然也希望 Elixir 会真的变得很流行,而且越快越好,但不管那一天是哪一天,甚至会不会到来,我还是会继续保持关注和学习,毕竟这是门值得学习的语言,毕竟我可以愉快地以高的效率写下高效率运行的代码。
5 回复
  • gonglexin 发表
    学习了,厉害。
  • chenge 发表
    确实Elixir的代码看着比较愉快,模式匹配可读性好于if的写法。 最近在exercism做题,希望能越来越熟练。 希望能参加你们下次的上海活动。
  • dantangfan 发表
    也是今年开始写 Elixir,之前多写 Python,并没有 Ruby、Erlang 的经验。但是 Elixir 出奇的简单,很快就上手了。跟 Python 想写点元编程要死要活比起来,Elixir 实现一个 Mongodb 的 ORM 却十分轻松。 在我们的项目中,大量的使用了宏。头脑清晰的时候写宏并没有多大困难(毕竟这是 Elixir 最大的亮点之一),但是调试起来确实有点麻烦。 比如前端加载逻辑业务,然后后端翻译成 Elixir 代码,实现简单的图形化编程比: %{ attr: level, filter: %{gt: 10}, action: doSomething,# 这里可以是一个操作或者下一个节点 } 会被翻译成 if level > 10, do: doSomething 当然,实际复杂度远远不止如此,而且性能也有保证,极大的方便了运营。 Elixir 虽然看起来简单,入手之后实际上还是得填 Erlang 的坑。我就是由于对 Erlang 不够熟悉,在优化代码的时候入过 GenServer 消息堆积的坑,这坑太隐蔽,请求量达不到一定的数量级的时候完全不会出问题。 遗憾的是自己水平有限,没有在开源社区做过什么贡献,关注也不多。 社区方面,远在广州就只能持观望态度了~ (编辑器不好用啊)
  • tony612 发表
    [@dantangfan](/users/495) 👍🏼 能在项目中使用 Elixir 就很不错了啊 你用的什么编辑器啊? 我用 Atom,感觉还不错吧,自动补充、语法检查什么的都有,起码够用了 有空可以给 Elixir China 贡献点代码啥的,应该不难,加油!
  • zzz6519003 发表
    Awesome