一台计算机只有硬件（称为裸机）是不能工作的，必须配备各种功能的软件，才能发挥其运算、测控等的功能，而软件是人使用编程语言编写出来的，是人赋予机器智能的载体。
编程语言是人与计算机之间交流的语言，其种类非常多，总的来说可以分为机器语言、汇编语言、高级语言三大类。
4.1.1机器语言
计算机所使用的是由"0"和"1"组成的二进制数，二进制是计算机的语言的基础。计算机发明之初，人们只能降贵纡尊，用计算机的语言去命令计算机干这干那，一句话，就是写出一串串由"0"和"1"组成的指令序列交由计算机执行，这种计算机能够认识的语言，就是机器语言。使用机器语言是十分痛苦的，特别是在程序有错需要修改时，更是如此。
对于机器语言，一条机器语言成为一条指令。指令是不可分割的最小功能单元。而且，由于每种计算机的指令系统往往各不相同，所以，在一类计算机上执行的程序，要想在另一类计算机上执行，必须另编程序，造成了重复工作。但由于使用的是针对特定型号计算机的语言，故而运算效率是所有语言中最高的。机器语言，是第一代计算机语言。
Docker技术在Ruby社区是有影响力的，我所知道的一些创业团队很早就在运用它来解决环境管理、持续集成以及部署的问题了。但是，也有一些同学尚未注意到这个技术，或者了解过后认为它不是很重要，所以我想讨论一下Docker对Ruby系技术的帮助。
有的人可能对Docker技术不太了解，不妨参考论坛里的这篇文章（ ）以及肖德时写的系列文章（ ）。 Docker 与 Vagrant
我一直很喜欢Vagrant这个工具，两三年前就用它来进行自己项目的环境维护，那时候主要是做测试，由于Vagrant将操作系统环境进行了标准化，我很容易就能让自己的应用系统以及相关的测试结果保持稳定。
Vagrant还有一个好处，Ruby社区比较偏爱Mac，但是线上的系统基本都是Linux，所以开发环境所做的测试是有疑问的，特别是遇到一些有so依赖的gem，这时一个和线上完全一样的环境就特别重要。
其实上面的表述不太准确，Vagrant也有各种provider，我所说的场景，基本上都是virtualbox的provider，所以这些地方正确的说法是 vagrant/virtualbox。
和Docker相比，vagrant/virtualbox组合的成本还是很高的，无论是setup一个环境还是reset一个环境，都需要一段时间的等待，Vagrant只是把virtualbox的操作DSL了而已，底层的做法没有变化。而Docker由于本质上就是一个进程，因此天生就是轻量级的。对于运行时间在分钟级别的自动化测试工作，Docker显然有很大的优势。
当然，也有人会认为Docker不能模拟完整的操作系统，不过这恐怕是一个优点而不是缺点。我在以前的文章中已经说过了，这里概述一下主要观点——
Docker简化了操作系统这个基础设施，让应用精简为其最核心的形态——携带有限资源的进程，在此基础上更有利于架构上的最佳实践。
而对Ruby工程师而言，这个“最佳实践”中肯定少不了的一条就是——微服务。
微服务
Ruby工程师中有很多就是Rails工程师，而Rails实际上更倾向于单体架构，因此后来社区的工程师们才需要在实际工作中总结1 to 30这样的实践。
其实微服务本身不是个教条，即使没有人教，我们也常常自发的去进行服务化改造，但是这个工作并不容易，主要是会受到一些问题的掣肘，比如运维复杂度和系统测试成本会大幅度上升等等。
处理这些困难，首先当然是看是否必要，一些简单场景我们也可以用单体架构直接搞定，但是我们很容易会注意到，这两年大家越来越多的提到了微服务或者服务化，这背后其实是有趋势的——各种业务形态都在朝着互联网级的用户规模推进，同时大家都在努力从每一个用户的各种维度上挖掘价值（这导致了大数据的需求），这些场景变得越来越常见，单体架构是难以支持的。
既然微服务或者服务化不可避免，那么就要有相应的对策，虽然Ruby社区也有很多人在不同问题点上针对微服务进行改进（比如完善异步化框架，以及对服务协议的探索等），但是在基础设施层面，Docker是最重要的武器，没有之一！
对Ruby工程师来说，Docker能做两件事：约束边界和建立通用基础服务。
约束服务边界
Ruby项目Docker化，并不是简单换个虚拟机那么简单，我们会面对拆分的压力，相信很多人尝试用Dockerfile来描述自己的项目的时候都会觉得束手束脚，但这些地方其实是促使我们想清楚——这个应用到底要做什么？它和外界是什么关系？对于外界的变化它如何响应？失败后怎样恢复？
这类的问题对系统架构非常重要。比如应用到底要做什么，这是让工程师去思考系统的目标，无论是提供web服务，管理调度后台任务，还是提供实时分析，它们都应该有一个尽可能单一的目标，在这个基础之上，我们建立的服务才有可能是易测试、易扩展和易维护的。
其它问题也类似，这些地方以前如果没有留意，很可能不是没问题，而是没意识到，使用Docker有助于我们意识到这些问题。
另外补充一点，由于Ruby项目不能完全脱离动态库依赖（java大都可以），本身的打包机制又没有自包含结构（gem+bundle不包括动态库，相比之下，Golang是静态联编的），在分布式环境中的交付和软件包分发其实是有着先天不足的，Docker的Image恰好补上了这一块，简直是睡觉时候有人送枕头了。 建立通用基础服务
当我们将应用系统分裂为各种服务并明确其边界以后，就出现了“分久必合”的问题，这很自然，服务化改造并不是各行其是，应用之间还是要协作，而对应用的运维——服务发现、水平扩展、容错等等——都需要基础设施的支持。
以前，对于这种运维基础设施，各公司甚至同一个公司的各个团队的做法都千差万别，但是借助Docker以及周边的生态圈，我们可以很容易的得到通用的服务发现框架，享受自动的部署和弹性扩展。
更好的消息是，这些基础服务是通用的——不但不关心是rails还是sinatra，甚至根本不关心是不是Ruby。
这也很好理解，Docker是对进程这个操作系统工作单元进行了简化约束，而进程的概念本来就是与语言和框架无关的。
这使得Ruby工程师以及Ruby项目可以更为自由的选择合适的技术去扩展公司的产品线。
延伸技术框架
Ruby 刚出来的时候，有很多来自 Java 社区的工程师加入其中（我也算是其中之一吧），很多人最大的感受是——视野被打开了。曾经象口号一样的“all in java”变成了落后的标志，大家意识到，一把钥匙开一把锁，用最合适的技术针对性的解决问题才是聪明的做法，单纯排斥某种技术或者语言框架并不明智。
这个道理在Ruby/RoR应用开发中也不例外，但是不少人在使用了几年Ruby以后都会遇到一个问题——“Ruby确实很适合开发Web，但是现在有些问题需要使用XX技术，而我们的系统严重依赖Ruby环境，这该怎么办呢？”
我认为问题就出在“系统严重依赖Ruby环境”上，研发的基础设施，比如配管、自动化测试、打包、部署，不应该仅满足一种技术或是语言，它一开始就要考虑到通用性，否则我们就只能“手里拿着锤子，看谁都像钉子”。
Docker本身和语言无关，它唯一的约束大概就是要运行在Linux上，这个对互联网服务端系统来说也算是标准了，问题不大。所以，我们应该以Docker为核心打造研发的基础设施，这将是未来的一笔重要投资。
当然，为未来画饼是危险的，不过还好，Docker领域的创业很活跃，有很多团队和公司已经做了相当多的基础工作，对于Ruby工程师和Ruby创业团队，去用现成的基础设施其实更方便。
我最早使用的语言是Java和Python， 并且一直都对Python充满好感， 我喜欢这种很朴实和高效率的感觉， 但我却最后没有采用Python，原因其实也很简单， 我就是不喜欢缩进语法， 就跟很多人换工作仅仅是为了屏幕更大一点一样， 另外就是有了同样很棒的可选方案， 这就是Ruby， 所以我最终采用了Ruby作为主力编程语言， 同样也为不能使用Python而有一点小遗憾，毕竟Python的健壮性比Ruby好很多，只不过Ruby也一直在进步， 所以这一点无伤大雅
我们都知道，无论是Python还是Ruby，甚至Java， 都是在解决业务层的问题， 属于应用型语言， 以解决业务逻辑为主， 但还有一个领域是系统领域，偏网络层和底层操作，在这一块我一直在寻找一种优雅的方案， C++被我首先给淘汰掉了， C的开发效率太低， Java倒是比较合适， 就是太臃肿，而且缺少系统编程的基因，毕竟它是企业级开发出身的
最后我选择了Erlang， 因为它在网络层方面表现优秀， 同时容错性和健壮性都很不错， 它的虚拟机是唯一可以跟JVM媲美的， 而且还有OTP的超重量级武器， 几乎可以是通杀网络层应用， 但根据我的总结它有一个硬伤和一个软肋，这一点后面展开，可以说选择Erlang是我目前所知道的方案里面是最优的
直到有一天我了解了Golang， 我知道Golang其实也蛮早的， 大概08年的时候就知道Google在搞一门奇怪的语言， 之后的几年，一直有不少以老莫为代表的人在嘀咕Golang， 其实我一直没太关注，我从ROR中吸取的经验是，成熟度对于商用很重要， 后来基于Golang开发的产品越来越多，让我不得不去研究一下， 这我才知道， 这就是我梦想中的Python， 效率和性能达到了最佳的平衡，对Go了解越多， 就越不愿意用Erlang写代码，主要原因：
1、Erlang的硬伤在于代码的可读性、表现力， 让我来举个小例子， 比如你为你的系统软件构建一个RESTFUL的接口，我们大致了解一下代码风格，先不说Erlang， 无论是你c/c++/python/ruby/java 出身， 对Go是不是有种很久违的感觉, 为什么说是硬伤？ 因为对一门语言来说，语法是不大可能会大幅度变更的， 而且不会出现大的变化， 我不知道有没有人读过《松本行弘的编程世界》，里面阐述的道理很明白， 真正好的编程方式是人去主宰计算机而不是计算机主宰人， 我感觉Erlang就有点主宰我的编程思维的感觉(我的视力本身就不好，它还在不断的扼杀我的眼睛！)， 编程首先是门逻辑学，其次是工程学，最后才是数学， 又让我想起吴军的《数学之美》所说的， 人工智能上个世纪一直在走弯路， 期望机器的高度图灵完备， 而忽视人类本身已有的文明，统计归纳的应用
2、Erlang的软肋在于高质量的库少，尽管有不少杀手级应用， 同样Go在这方面也是软肋， 这一点对于一个不到五年的语言有情可原， 但对于一个20多年的语言是不是有点说不过去， 比如你用json解析库，很多人都是从mochiweb这个基本不更新的库中去抽取， 而我认为对于类似json这种东西可以考虑融入到语言标准库中， 因为未来的商业软件的api化趋势越来越明显，说的难听点 ， 一个倚老卖老一个与时俱进，反正我对Golang的库一点也不担心， 目前的成绩易经非常棒了， 远远优于Ruby/Python的前五年， 可参见已有的高质量的库列表
3、Erlang不合群， 这主要体现在跟其他语言的交互性上， 当然这也有深层次的原因， Erlang本身有自己的哲学， 如出错恢复机制， 你融入一个其他语言的东西进去， 这帐就不好算，就好比你硬要让一个喝咖啡的跟一个吃大蒜的坐在一起， 总之你写一个Erlang的port远远比Go复杂， 甚至比Python/Java还要复杂， 这就造成了Erlang在底层编程上效果不是很好， 没法利用linux已有的很多优秀成果，我一直认为Erlang的什么的mysql/pg/oracle驱动都没有必要存在， Erlang一定是一个self-container应用， 你只要用到了其他东西， 根据木桶理论， 你就不敢号称9个9，以系统的眼光看问题， 我觉得一个系统的鲁棒性不能依赖于某一组件， 这也是为什么爱立信本身的Erlang应用并不广泛
4、说说数据类型吧， 我不止听到1个人说Erlang对字符串的处理不有好， 它把string当做list来处理，其实本质上是该这么，但，还是那句话， 违背了面向人的哲学， 应该做一些DSL， 比如Golang里面的 := 就是一个糖衣， 等价于 var xx yyy = zzzz， 大大方便的程序员少敲不少字符, Golang里面对字符转可以说基本和python差不多， slice map函数很强大， 支持lambda条件，虽然Erlang的基本类型很少， 但有很多构造， 所谓构造等价于Golang里面复杂的struct， 也奇怪了，我就是感觉Erlang构造伤眼睛好吗？可能是各种括号的比对的原因吧， 而且我认为这是不必要的， 显然Erlang缺少DSL的基因， 当然跟Erlang出身的年代有关， 我不夸张的说， 自打用Erlang以后我的视力又下降了100度左右， 我不是很喜欢lisp所说的符号也是一种语法， 可能这又跟函数式编程有关吧：形式推导远大于逻辑演绎
5、其实我最不关注的是性能问题， 因为随着摩尔定律， 单位计算单元的性价比会无限高，但Golang既然提出它的性能逼近C， 那我还是提一下吧， 当然， Erlang也还可以， 虽然比Java慢， 但跟Python一个档次吧
6、再谈谈报错机制， 因为Erlang的的报错信息太让人纠结了， 起初以为我不会看出错信息， 后来也使用了Sasl， 还是不够直观，甚至有时要用工具分析crash文件来定位问题，还是跟Erlang的哲学有关， 在Erlang中一切都是并行的， 所以它根本不care是物理哪一行出错， 只跟Actor绑定， 然后告诉你Actor的ID和出错代号， 你自己凭经验去分析吧，这样做的好处是可以很方便定位出并行中出现的问题，但凡事都是相对的， 在这一点上有点纠枉过正，根据我的经验， 绝大部分时候我只希望先给我明确的指出哪一行出错了好吗？ 甚至把顺序的backtrace用完整的英文句子打印出来好吗？至于并行中的错误及时在命令式多线程语言中是不常见的，虽然并不是没有， 但遇到错误我再费劲去调试好了， 但并不是所有的逻辑都用并行的思维去定位问题， 我甚至认为， 对于一个系统不完全是并行也不完全是串行，跟好比我们衡量世界不能单纯的唯物也不能完全的唯心一样， 这一点Golang就做了很好的折中， 不需要并行的时候你老老实实的写串行代码， 需要并行的时候也有较复杂的机制来应对， 合乎情理
7、再说说招人吧， 以前招过好几个C出来的人，说实话水平很好， 可以一周就完成一个小组件， libevent用的熟的很，后来我逼人家用Erlang，结果把人家逼走了，至今我还很后悔， 自己的一厢情愿强加在别人身上真是太不合适了，但我招纯Erlang出来的人，可以说比招objc的人还难， 没有人，空谈技术的优雅性首先就是不靠谱的，再看看邮件列表， Golang的活跃度明显比Erlang高很多， 基本逼近Ruby，更重要的是， 我根本不担心Golang的人才，因为只要熟悉Python/C/Ruby/或者C++， 基本可以实现半天入门， 之后就可以噼里啪啦边搜资料边干活了，虽然有足够的深度，但门槛极其平缓，工程人员也可以复用很多已有的知识。 Erlang在这一点其实跟第一点硬伤有关，大部分人学一周都摸不着头脑，不是每个人的抽象思维和世界观都是一样的好吗， 所以函数式编程尽管不比命令式语言起步晚，但始终学的人很少，这就是历史， 对于大部分人， 更希望解决问题，创造价值， 而不是数学来推导去
8、最后我建议， 如果你是玩c/c++的， 现在开始学Golang，是最好的时机， 跟一门靠谱的语言一起成长， 这种感觉非常棒， 你用Erlang折腾1个应用， 用Go恐怕都完成了10个开源项目， 当然，也要结合自己的口味， Golang就是Sublime Text， Erlang就是Emacs
相信自己的判断，相信自己的逻辑， 赢就是赢，输就是输
转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦
这些年，许多人问过我下面相同的问题： 我开始了一个新项目，你认为我该使用什么技术呢？ 通常，这些人属于下面两类中的一类： 已经做出决定的技术人员 需要鼓励支持的非技术人员 在一天结束的时候，我怀疑这些人是否真正关心我的答案。或许他们只是想知道我们是否面对相同的问题或只是需要鼓励支持。 坦白的说，作为一名工程师，我信奉这个说法：伟大的想法可由几乎任何技术构建。它们都有自己的优点和缺点。无论你选择什么技术，你都要为它带来的风险买单。但真的，你项目的成功与否更多的取决于愿景、领导团队、执行和市场，而并非技术的选择。 现在，我是一个负责人，我每天做技术上的决断。当我选择了一个特定技术时，我要能够证明这个决定，向我自己、我的合合伙人/员工和潜在的投资者。我根据项目及公司愿景做技术选择。 项目要成功你必须有一个坚定的愿景。如果你能将你的愿景转化成一组衡量你每个决定的值，你的前进道路会更清晰，也更容易找到合适的加入你的人。 除了愿景，许多初创公司专注于文化。人们都说文化是由创始人、最初的几个员工及产品本身确立的，然而，技术抉择对公司文化有直接影响这个说法却没怎么被提到。 你的项目初创可能基于J2EE、Oracle、Perl、PHP、Rails、Node.js或.NET，随之而来你的团队工程师将有不同的期望，不同的价值观，和不同的关注点。这些技术没有本质上是坏的。伟大的事情都有各自不凡的所在。它们伴随而来的是一种文化。 几年前，我遇到一位负责人选择使用Node.js来搭建自己的应用。出于好奇，我问他为什么选择Node。他的回答很简单：基础的工程师对Node.js很兴奋，所以我可以更容易招募到愿意免费贡献的人，因为他们希望积累相关经验。 这个决定显式地定义了工程师文化和团队成员——那些能够在这个项目中工作或感兴趣这个项目上工作的人。 问一个不一样的问题 那么我们不应该问什么技术是我们需要使用的， 我们应该问我们自己： 这个技术符合我们公司的核心价值观吗？ 这显然是个更为之困然的问题，因为你需要切切实实地了解你公司的核心价值观。这将是创建一个成功项目的关键。 你不能盲目地套用技术就像你不用套用别人的商业计划那样。这是公司身份的一部分，你的核心价值观，你的目标，你的团队，你的期望都是跟别人不一样的。 关于“这技术在某某公司用得适合啊”这样的论据是很少有效的。例如Facebook使用PHP，它“在Facebook公司用得很适合”，但是这意味着我们选都应该使用PHP吗？ 技术文化联盟 要具体描述这些技术社区的特性是很困难的,但我会个你分享我在不同选择上的观点与看法。请自由在评论里分享自己的看法，也可以包括关于其他技术社区的。 古典学校： 这里有些是“经典“的语言：他们已经被使用很长的一段时间，并且被证明他们的价值。他们的使用范围已经很广泛，但却引不起别人更大的激情。 注意：我在这没有提及Perl，因为我并不知道有哪个创业项目是以Perl作为核心技术来创建的（6？）。 PHP 理念: 功能都实现出来，这非常重要 就像互联网的基础一般 只要有一个方法去实现它，那么就不会被破坏 只要它运行起来并且速度很快，那么其他东西都是没有意义的 不要太理论化了，我们的语言是非常通熟易懂的，任何人一眨眼的功夫就能上手了。你可以用Java做同样的事情看看！ 面向对象是种落后的想法 常见的使用例子: (在2013年中期) 你的第一个web app Wordpress/Drupal的扩展 个人观点: PHP拥有它光荣的日子。它真的让web开发更加简单，容易上手. 但是, 大概因为大量新的程序员开始使用PHP并且它拥有个不是那么地坚持自己观点的社区，所以只有少数人能写出漂亮的PHP代码。 良好的拥有规范的代码例子是很难找到的，并且我甚至不敢肯定PHP拥有自身的规范。这导致了PHP社区以糟糕的代码质量，缺乏测试，安全问题如同梦魇和像在2000年代初期般的落后品味而著名。 拥有良好规范约定，开发流程和指南的强大的PHP团队，是可以完成伟大的事情的，但这样团队很稀少。 Java 理念: 可移植性 像C/C++般的能力和表现，但却能够自动管理内存 更多地关注面向对象 IDE是必须有得 我们要消耗所有的内存，因为它们是一文不值的 线程处理是个好方法！ 不要提起Java applets 看看我可爱的JVM！ 开源（但拥有者为Oracle） 缓慢但更为安全的开发流程 个人观点： Java是非常有趣的。在几年前很多开发者已经厌倦了Java，他们找到了其他新大陆。他们开始转向一些脚本语言，像PHP，Pyhton，Ruby或者一些更加难懂小众的语言像Erlang。 尽管如此，Google通过Android展示了Java并不像我们脑海里的那么糟糕（只要你并不是使用J2EE或者Swing）。现在有一种”赶时髦“的趋势视乎暗示着Java再次变得酷起来了。这些大多建立在两件事情上: JVM 让人难以置信高质量的代码库 即便如此，对于我们来说，花一整天来编写Java程序看起来并不是一件吸引人的事。如果你打算依靠Java的堆栈，那么有一系列的其他JVM语言供你选择，他们成熟而且兼容Java扩展的库（例如：Scala, Groovy, JRuby, Clojure），你总是可以混搭使用它们。 自从大量毕业生学习Java后，聘请Java程序员并非一件难事，但是要找那些前期创业公司，高水准的工程师并且对写Java程序感兴趣是一件极具挑战性的事情。 另外注意：如果你的目标是Android，那么不用想得太复杂，即使你认为其他JVM语言更好，你也要坚持使用官方的堆栈。 我们仍然有许多的原因在你的创业项目里使用Java技术，但你可能会想同时使用一些的”更快，更灵活“的解决方案（Ruby, Python, Node…）。对于公司跟工程师来说，一个多语言环境带来了大量的价值，这就是为什么Java社区看起来节奏很慢，但却肯定是活跃的。 Java绝大部分是吸引了那些受到了传统的训练的工程师，他们向往舒适，有重复性，总所周知的编程模式。他们习惯关于使用这种语言，这种工具，这种自然的节奏。或许他们并不是最具有求知欲的开发者，但是他们却是很可靠的（当然，你要挑选了正确的人）。 C#/.NET 理念: 是更加好的Java 最初是为了桌面与嵌入式软件设计的 我们比开发Java的小伙伴们拥有更好的IDE 虽然是企业级般的重量了，但是我们提供了大部分Rails很酷的特性 我们有矛盾的开源版本 缓慢但更为安全的开发流程 个人观点: 当我回顾C#在发布C#5的时候，我不得不惊叹，我真的对该语言新的特性留下了深刻的印象。单从纯粹的语言设计角度来看，C#是有一丁点的领先于Java。在Visual Studio里写Javascript时的欣悦感让我感到很惊喜（自从我用VS主要为了C++后，我真的再也没有期待过什么了）。 另一件让我印象很深的是：C#可利用的文档的质量非常显著！但是C#并不是开源的，和Visual Studio + MSDN 非常昂贵，并且整个环境都因为licenses跟内存损耗而变得很糟糕，这些事实多少让这个好印象打折扣了。 微软正在慢慢地往开源发展，所以有了更多像Azure的开源方案。但是作为一个社区，.NET仍然是微软开发的中心。作为创业者，你应该考虑下你对开源与拥有企业支持的文化之间对比的看法。 C#大部分吸引了Java群体中的变向者：这些工程师们寻求稳定性和有保障的合同远胜于追求开源。还有他们可以容忍IIS！ 明确的可替代品 在过去的这些年，有两个动态语言对于新的创业项目来说变得十分受宠：Python and Ruby。这两个语言实际上有非常多相似的地方。现在Python因为后台apps而著名（因为NLP, biotech, APIs, SOA的因素 ）而另一方方面，Ruby因为面向用户的apps而著名。尽管这两个语言都受到了一样的限制（主要是性能跟并发性），但是他们的核心价值和社区有着不一样的专注点。 Python 理念: 只有一种显而易见的做事方法 代码要漂亮简洁和明确 文档是关键 有较强的语言设计引导 个人观点: 作为一个更喜欢ruby的人来说，我常常嫉妒python项目文档的质量。同时python设计的初衷——给你一个正确的编程方式却又让我又爱又恨。通常这一初衷对于团队来说很好，但某些时候可能令人抓狂。 在某些领域python有很多优秀的库，并且这些库和你想解决的问题有关，这种情况下python可能是最好的选择。python开发者知道怎样去讨论交流他们的代码。他们用文档记录所做的事情并且用面向过程来描述他们务实的方法。 但是python在互联网流行前就已经存在，如果你关注的是并发和高吞吐量，那么这个并发性很差的动态解释语言可能不是一个很好的选择。 python主要吸引的是那些想要一个现代但通过充分验证的语言的更加务实和经验丰富的全栈开发者。 Ruby/Ruby on Rails 理念: 为人而不是机器而设计的Designed for humans, not machines 极端的灵活性：如果陷入困境的话，是你的原因，那是你 一切力求简单、优雅并充满乐趣 DSL至上，尽DSL 测试非常重要 事情变化很快，保持学习 激情活力的社区 个人意见: 就我而言，Ruby是我几年来的首选语言。你会发现令人难以置信的、大量的Ruby开源代码。Rails实在是一个了不起的Web框架，如果你知道如何使用工具的话它让使大多数的Web项目容易实现。 但灵活性和过快的开发周期也有缺点。随时准备在你的代码上投入大量时间以保持其更新以及分离废弃老的库。如果不能依靠缓存，一个成功应用的吞吐量往往被缺乏良好的并发支持限制。 Ruby开发者主要是用Rails开发，所以与框架特性相比基本不会去深入核心语言本身的特性。他们往往是充满好奇心且机会主义的（以一个很好的方式），有些实用主义，关心代码质量/结构和测试覆盖率。Rails开发者早期采用它的典型原因是由于该框架本身默认使用的一些新技术（coffeescript、turbolinks、CSS预处理器……）。 Ruby和Rails主要吸引了那些想把事情做得快而优雅的开发者。相比于底层计算细节，这些开发者往往是以产品导向的，他们更关心的目的和客户价值的实现。 新成员 这是些让人们兴奋的语言/技术。他们代表了运行在“云端”的编程语言的设计新浪潮。 Node.js (Javascript) Node.js不是一门编程语言，但它是使JS在服务器端运行最流行的方法。和我对Ruby的大部分评论是关于Rails一样，相比JS我更关注Node。 理念: 为实时驱动的应用程序而设计，高吞吐量、低延迟 DIY 小的内核，剩余的内容由社区维护 低耦合 借鉴Ruby/Python 个人意见: 我觉得Node.js很有趣。在技术上Node没有太多新内容。Python有Tornado/Twisted，Ruby有EventMachine，C有 libevent。 事件驱动的框架已经使用了一段时间，但Node具有两大优势：*大多数JS库是非阻塞*大多数Web开发者不管怎样都要写一些JS。 在前端和后端使用相同编程语言的想法吸引了不少人，但值得与否还有待验证。 Node提供了巨大的吞吐量（只要你坚持IO操作），它很容易上手，而且写起来很有趣。 由于其本身具有事件驱动性，调试及测试面临挑战，回调处理是可维护性的地狱。我希望Node能够提供一种官方的今后或承诺的解决方案。略显凌乱的文档使在现有项目里跳转时有些困难。 Node的开发者大都是它的早期的接受者，他们更喜欢自定义而不是按惯例创建结构/模式，这样使他们觉得更舒服。它吸引开发者使用已知的语言（JS）去处理高层的并发。Node作为一个框架处理的水平比经典的MVC更底层一些。Node开发者们也真的喜欢这个在服务器和客户端使用相同语言的想法。 Clojure 理念: 实用且符合现代人使用的Lisp 一切皆是数据 并发性，并发性，并发性 让那该死的可变状态见鬼吧 能够很好地与Java协作 稍微靠近科研路线，但并不影响他的实用性 个人观点: 我最喜欢Clojure的一点是它的lisp精神。一旦你攻克了它的圆括号和操作符/参数顺序，那么Clojure将很可能让你重新思考你构建代码的方式。对于处理数据跟强迫你保持代码简短这两方面来说，它真的很棒并且高效。 让我头疼的是我并非拥有足够的聪明去更多地编写Clojure。当我尝试去追踪那些数据时，我的大脑会出现栈溢出。对于该语言来说异常通常是没意义的，假如你尝试解决别人代码的bug，这将会是机具挑战的事情因为Clojure本身是复杂的语言，并且可以用宏来拓展。最后，Clojure社区并不是真的面向web开发，Clojure完成的大多数作品都是以数据作为中心的。 Clojure主要吸引了那些处于边缘，对编程语言有求知欲，面相数据的程序员。如果你寻找有编程语言怪癖的数据处理专家，那么Clojure将会是吸引他们的好方法。 Scala 哲学: 同时具有面向对象与函数编程世界的最佳优点 让编译器为你做一些工作 并发事务 比Java少一些规范，但是目标在于相同或更好的性能 与Java生态系统和谐共存 个人意见: 当目标是JVM时，Scala目前是我所选择的语言。它的学习曲线陡峭。 知道何时使用 FP 与 OOP是非常复杂的，而且在应对该语言语法本身时也是如此。 那就是说，获得使用FP的好处，同时又在需要的时候仍然保持OOP，是非常有用的。一旦你“掌握”了该语言的风格，写Scala实际上是令人愉快的，而且它的社区也非常友好。 Play框架确实很好，它提供了一个很好的替代Rails的选择，特别是对API开发来说。Twitter的工程师团队为此提供了许多资源与开源代码。 目前使用Scala是一个非常安全的选择。Java开发者会有舒适感并会尝试这种更加“现代的”语言。动态语言开发者不会感觉太陌生，并且获得了Java生态环境，性能提升，并发性和永恒性。如果编译时间不会使你感到沮丧的话，现有工具以及惯例使得在一个成长的团队中使用Scala非常不错。 不过就像Ruby，Scala社区的文档不是很丰富。我真的希望 API文档 可以重新编写得更直观，总的说来就是更有用。但是公平的说，已经有许多非常好的资源了，比如Martin Odersky (Scala的创造者)提供的Twitter的 Scala学校和Coursera的Scala 课堂之 FP 。 Scala主要是吸引了好奇的Java开发者，他们想要一些更现代的东西，就像Ruby/Python开发者想要他们语言的一个更具伸缩性的版本。对于吸引那些想拓展它们现存开发环境的伟大的开发者，以及那些可以充分利用该语言二元性的开发者来说，Scala是一个好方法。 Go 更强大的C 你可以自己管理内存，前提是你不能粗心大意 直观的代码更好 丰富的代码库 效率很快..对于任何一个部分来说（从编译到执行） 存在并行编程模式，并且简单使用 文档很关键 个人观点: 我真的很喜欢Go（亦称Golang）。在我使用它几年之后，我选择使用它来开发我自己新项目的API。Go或许对于一些人来说有些无聊，但它的简洁与效率是真材实料的。 Go强迫你更多地去思考你的代码的结构，你的数据/代码行为，因为你不能总是坚持面向对象的编程模式。我发现我的代码总算变得容易调试，结构更简洁，但有时会重复性比较大（例如：错误处理）。 没有比Go更加方便地开发并发业务的语言了。一旦需要编译，你的代码编译加上运行的时间会比Rails服务器启动的时间还快。Go支持一些鸭子类型（duck typing,动态类型的一种风格），这造就了从Ruby（举个例子）转换过来显得颇为简单。对比起一些脚本语言，它所编写产品的性能实在让人觉得惊叹，并且它占用的内存很小。 Go被设计为一个人或是一个大团队都可以为同一代码库工作的语言，而且它的身旁有很多很棒的工具值得你使用。 然而，它不是完美的语言。有时第三方依赖库很让人头疼。当你在高水平编程中运用了Go会让你觉得它的水平太低了。有些语言设计时的决策有时会引起困惑(例子：交互式接口和结构化设计)。 初创公司里，Go看起来在性能和并发事务方面变得越来越流行。我见过很多初创公司用Go替代了Node，而且另一些公司添加了Go应用作为扩展程序。 Go社区里看起来混合了一些老的C/C++学校黑客和一些喜欢低水平语言的年轻人。Go语言和社区的领导者固执的相信让人们理解他们的想法是很容易的。同时他们也允许你能快速的评估你接受他们哲学后是有多么的舒适，而且可以发现是否能达到你的预期效果。 Go主要吸引着面向性能和结构体系的开发者。他们想要轻易的实现并发，要达到C的执行速度，也要达到Python/Ruby的开发速度。他们不想在找一个新的有趣的语言，他们需要一个坚定的妥协。 技术驱动理念 技术的选择会受到理念的影响。你需要清楚而谨慎地权衡你选用的技术是否与企业的价值观一致。做出正确的决定有助于你从技术细节的纠缠中摆脱出来，拥有更多投入商务运作的时间。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有 
