包含golangdsl的詞條

本文目錄一覽：

• 1、編程語言的載體是什麼
• 2、為什麼Ruby程序員應該了解和掌握Docker
• 3、寫小程序，什麼語言跨平台兼容和性能較好？golang
• 4、創業項目該如何選擇技術?

編程語言的載體是什麼

一台計算機只有硬件（稱為裸機）是不能工作的，必須配備各種功能的軟件，才能發揮其運算、測控等的功能，而軟件是人使用編程語言編寫出來的，是人賦予機器智能的載體。

編程語言是人與計算機之間交流的語言，其種類非常多，總的來說可以分為機器語言、彙編語言、高級語言三大類。

4.1.1機器語言

計算機所使用的是由”0″和”1″組成的二進制數，二進制是計算機的語言的基礎。計算機發明之初，人們只能降貴紆尊，用計算機的語言去命令計算機干這干那，一句話，就是寫出一串串由”0″和”1″組成的指令序列交由計算機執行，這種計算機能夠認識的語言，就是機器語言。使用機器語言是十分痛苦的，特別是在程序有錯需要修改時，更是如此。

對於機器語言，一條機器語言成為一條指令。指令是不可分割的最小功能單元。而且，由於每種計算機的指令系統往往各不相同，所以，在一類計算機上執行的程序，要想在另一類計算機上執行，必須另編程序，造成了重複工作。但由於使用的是針對特定型號計算機的語言，故而運算效率是所有語言中最高的。機器語言，是第一代計算機語言。

為什麼Ruby程序員應該了解和掌握Docker

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創業團隊，去用現成的基礎設施其實更方便。

寫小程序，什麼語言跨平台兼容和性能較好？golang

我最早使用的語言是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的開發速度。他們不想在找一個新的有趣的語言，他們需要一個堅定的妥協。 技術驅動理念 技術的選擇會受到理念的影響。你需要清楚而謹慎地權衡你選用的技術是否與企業的價值觀一致。做出正確的決定有助於你從技術細節的糾纏中擺脫出來，擁有更多投入商務運作的時間。