追求客戶端和伺服器編程語言的一致有多大的意義？
比如伺服器端 Javascript ，或者讓 Cocoa 支持 Ruby 都在試圖統一開發語言。
但是語法的一致性真的那麼重要？
那為何目前實際上最成功的應用，恰恰都是多種語言混合起來開發的？
『伺服器端 Javascript ，或者讓 Cocoa 支持 Ruby 都在試圖統一開發語言』這是從何說起……MacRuby 是要和什麼『統一』啊？
來說伺服器端 JavaScript 的事吧。賣點主要有三個：
一是部分代碼可以在伺服器端和客戶端共享。瀏覽器只有 JavaScript。通常的例子無非是為了用戶體驗，將部分表單驗證代碼寫成 JavaScript，用戶輸入後如果有錯誤即時提示。表單傳輸至伺服器後，同樣的驗證過程要在伺服器端再次進行，因為你不能相信用戶輸入（誰不做誰傻逼）。如果伺服器端邏輯不是 JavaScript 寫的，意味著同樣的驗證代碼要在 JavaScript 和伺服器端用的語言同時實現兩次。這會導致不一致和維護問題。在移動互聯興起後，另外的一個應用場合是可以在伺服器端和客戶端均衡計算任務。比如如果客戶端是比較強大的桌面瀏覽器，那麼很多計算任務可以在客戶端完成。但如果客戶端是弱小的移動瀏覽器，同樣的任務也許要考慮轉移到伺服器端進行，以降低客戶端移動設備的電力消耗和提高完成速度。
二是以 Node.js 為代表的伺服器端 JavaScript 是完全非同步的（asynchronous）。大部分網路服務的前端部分（插話：似乎很多人對前端、後端的理解有誤。其實前端和後端都是講的伺服器端的事，而不是通常誤解的前端是客戶端、後端是伺服器端）並非 CPU-bound，而是 I/O-bound。傳統的 thread-per-connection 或 process-per-connection 無法有效處理大量客戶端的並發、低速連接。現在流行的方式通常是基於 epoll/kqueue 的非同步 I/O（但實際上要達到最佳性能還是要權衡非同步 I/O 和同步 I/O 的不同性能、代價）。但在大多數語言裡面，非同步 I/O 的支持或不存在、或不完善，而且通常語法並不適合編寫基於非同步 I/O 的程序。Node.js 看中了 JavaScript 從一開始就完全非同步 I/O、並且匿名函數的語法很適合編寫基於回調（callback）的非同步程序（至於說嵌套了比如 13 層回調的非同步 JavaScript 程序如何維護、調試、除蟲，那是另外一碼事了……）。並且在 Web Worker 普及之前，由於通常 JavaScript 單線程的限制，要做並發也只能走 event-based + 非同步 I/O 這條路。
三是帶 JIT 的 V8 JavaScript 引擎效率很不錯。現在主流的動態語言裡面，執行效率排序大概是 JavaScript &> Python &> Ruby （假設用常見的實現：V8、CPython、MRI）。
以上三點，除了一能涉及到語法一致性的好處，二和三都和語法關係不大，而且顯然一（這部分代碼量相對較少）不如二、三重要。
順便羅嗦幾句……
&< 牢騷 &>
完全非同步這個願景聽起來很美好，但現實是那麼多功能要全部重寫。現存的 JavaScript 庫數量還比較少，如果遇到某些功能沒有就要自己實現，對很多人來說這或許不值得。基於回調的編程方式造成的控制流倒置（inversion of control）會導致代碼難於理解和組織（Python 的 Twisted 庫就是典型）。相比之下，Python 的 generator 和 Lua 的 coroutine 都是更加優雅的實現非同步 I/O 的方式，控制流可以保持原樣，從而使得代碼易於理解和維護。所以實際上存在的問題僅僅是：沒有現存的大量基於非同步 I/O 的庫。Node.js 試圖完全重寫所有涉及 I/O 的部分（HTTP、資料庫訪問等），而這個嘗試在其他語言的社區里似乎並沒有得到重視。這個問題不解決，伺服器端 JavaScript 也就只能停留在愛好者玩票的階段。這也是有大量包的語言（如 Java, Python, Ruby）在伺服器端更流行的原因之一。
V8 的效率已然很高，對很多應用來說都綽綽有餘了（相對慢的 Ruby 都可以支持），但這並不等於說它就夠了。比如 Twitter 的後台最後還是改用跑在 JVM 上和 Java 效率差不多的 Scala （最近大愛它，個人覺得比 Python 和 Ruby 都要優雅），因為到了那個規模，JVM 上靜態語言的效率還是很值得的。雖然 benchmark 通常的有偏差，但從 http://shootout.alioth.debian.org/u32/benchmark.php?test=alllang=v8lang2=scala 的結果看 V8 和 Scala/JVM 還是有一兩個數量級的效率差異。更不用說極端的例子甚至要拋棄 JVM 改用 C/C++ 實現最大效率了。（忘了是人人還是哪家，最後貌似把所有應用改用 C++ 重寫，省了不少伺服器資源據說）
&< /牢騷 &>
很多人都認為nodejs是給前端開發人員可以開發後端程序的契機，除此之外沒有任何東西。
但是個人認為，nodejs最大的亮點是，將事件模型和非同步模型遷移到了後端，程序員不需要關注多線程就可以完成任務。這是編程模型上的改變。
很多伺服器端程序在解決一些問題的時候，真的很麻煩，像php，完全同步的方式調用，在一些網路應用的時候，性能很成問題，nodejs卻能解決這個問題，而且程序員不用像java那樣通過多線程來解決問題。
語言一致性不是非常重要，就像樓主說的，大部分成功項目已經驗證語言不一致一樣可以出成功項目。對於技術從業者而言，是否能作出好產品，關鍵不是用什麼技術而是如何運用技術。
語言一致性是否值得追求，我覺得值得追求，這種追求是軟體工程方面的追求，沒有這樣的追求，軟體工程也不會進步，軟體工程的根本其實就是追求用更低的成本做更好的事情，諸如模塊化編程、面向對象編程、java語言等等這些技術的產生都是因為人對效率和成本的追求，語言一致性跟這些追求沒什麼區別。
項目中實際場景：策劃給了一個功能模塊的配置，這些配置不單純用於功能邏輯也用於表現邏輯，於是客戶端和服務端的開發人員，分別都在代碼里用各自的方式配置了一份數據，於是一份配置分散到了兩個地方，產品上線後策劃所功能要調整，於是就開始陸續出現前後端配置不一致產生的bug。
有一些配置是包含運算邏輯的，所以單純的用數據格式保存配置是不行的，如果「工程化」一些，這些數據最好是服務端保存，客戶端來取，但是這就犧牲效率了。
如果有一門前後端都通用的語言，就可以讓客戶端和服務端共用一部分代碼和邏輯，就可以保證最高的效率和最低的維護成本，不是挺好的嗎？
另外一個角度看，現在做項目大多數時候都是招人難，培養人難。項目里用的編程語言越多，結構越複雜，可維護性就越差，人員培養成本和招人成本就越高，項目風險就越大。相反，項目里用的語言越少，項目的可維護性就越高，人員培養成本就越低，相應的項目風險就越小。
如果有一門前後端都通用的語言，項目里的前後端開發人員可以隨時調配工作力量，不是挺好的嗎？
至於現在或將來是否可能存在前後端通用的語言，我覺得不可能存在廣義上的前後端通用語言，但存在適用於特定項目的前後端通用語言。因為編程語言選擇是取決於項目需求和參與者等諸多因素的。
比如有的web項目規模不大，就可以考慮用nodejs做服務端。但是規模大了，nodejs的非同步編程模型恐怕就不是很好的編程方式了。
前段時間看到有人把AS3搬到服務端，如果效率可以的話，我覺得這對web遊戲開發也是挺有價值的。但是否犧牲執行效率，換更低的人員成本和更高的開發效率，不可能有一個絕對的答案。需要一定程度的統一，但不是完全統一。編程語言是程序員互相交流的語言，是人人語言不是人機語言。所以需要的統一程度和自然語言一樣，語言交流既是語言符號的問題，也是文化認同的問題。理解一個團隊和一個公司的亞文化，對於理解這個團隊和這個公司的代碼是有幫助的。
以前學生物的時候知道生物多樣性是很重要的，可持續發展。
沒太多意義.
編程界一個極大的誤解就是,如果A工作是用B語言做的,那麼原來用B語言做C工作的人就能馬上來做A工作.
這顯然太高看了語言這個工具,就好比會認為你會英語,就能去劍橋學數學一樣的.
C/S兩端,除了語言之外,涉及到的知識面差別太大,S端需要考慮負載均衡,高可用高並發等,C端需要考慮圖形,渲染等等.
那些認為只要語言相同就能做的事情,多半是比較low的純擼業務的工作吧.
這個事情反過來又說明了,不要把自己的從業門檻建立在一門語言上,還是要多擴展其他相關知識.我認為是完全沒意義的。
實名反對所有說沒意義的或者意義不大的。
不要只從技術角度思考問題。
不要只從技術角度思考問題。
不要只從技術角度思考問題。
重要的事情說三遍。
大部分回答其實在說，應該根據合適的功能選擇合適的語言。這句話沒錯，但是它忽略了企業對於管理難度和成本的要求。在迭代式開發越來越成為主流的今天，未來工作量甚至工作內容都是不確定的，這個時候你讓作為管理者怎麼根據功能招合適技能的人呢？
方法一，根據崗位和工種招人。比如說，一個前端一個後端吧。結果發現，最近的功能都是在改進後台，前端插不上手。後端一邊加班一邊罵，拿一樣的工資，我忙的不行，前端卻在那裡天天看萌喵視頻。顯然沒有辦法讓每個人都處於合適的工作狀態。大公司池子大，同時進行的事情多，能夠讓各個崗位的比例大致符合工作量，但是到了小公司這種矛盾就很明顯。
方法二，招特牛的人，能用J2EE寫企業軟體，能用C++寫演算法，還能寫嵌入式搞搞智能硬體，時不時自己開個AI做點渲染，就算你出的起錢，這樣人有幾個，你的公司能吸引人家來嗎？
所以，追求客戶端和伺服器端編程語言的意義，更多是工程管理角度的需求。可以用同一種語言讓程序員全棧化和代碼復用化。
用同一種語言後，程序員不用在不同語法syntax中切換，數據傳遞的格式也更一致，工作效率會高很多，更容易實現全棧化。
程序員全棧化後，workload就很容易平攤。還是剛才一個前端一個後端的例子，再也不會出現有人忙的要死，有人閑的要命的情況。而且這裡還節省了另外一層的成本：任務分配。以前，需要把一個完整的功能拆成前端部分和後端部分。請問這個拆分和寫文檔總得有個兩頭都懂的的人去干吧，但有這拆分和寫文檔的時間為什麼不自己幹了呢？
代碼復用化，讓後端的代碼到前端重複使用的例子有browserify，讓前端代碼到後端重複使用的例子有cheerio... 好處就不用多說了。
最後回過頭來說， 強行用同一種語言會不會對性能有所損失？是，在某些情況下可能會有。然後這種損失有多大呢？至少可以從業界權衡利弊後的選擇來推測一二。node.js能開發大型網站嗎？ - Node.js
實際上，google用的是python，facebook用的是php(為了速度加上了編譯），這些現在都不是新技術公司的主流，然而並沒有妨礙他們的競爭力。追求編程意義上最好的語言，除了美學追求外，意義真有那麼大嗎？畢竟，所有的語言最後都編譯成一樣的機器語言。
上面不贊同的居多呀。我有不同的意見。 : )
沒有前提就會流於空泛，所以，設定一下前提先。
前提：就我自己而言，所謂的客戶端和服務端開發，在大多數情況下，都不需要自己從很底層去解決問題，更多是使用「架構的力量」。語言的作用只是去調用現有的各種軟體，也就是寫寫「膠水代碼」而已（所以，如果要前提是想寫 OS 的話，那就不用往下看了）。
在這個前提下來考量編程語言，最主要的關注就是它提供的抽象粒度是否適合它的應用場景（膠水）。javascript 在客戶端，已經很好地扮演了它的角色，這點無需多說。那麼，在服務端。它也同樣可以扮演好自己的角色，成為一個好用的後端語言。為什麼這麼說呢？
歸根結底，非同步（或者說延遲）其實是系統本身不容忽視的內在特性。這個特性是需要被編程語言表達出來的，試圖假裝延遲不存在的語言（或者 API），其實都不能真正做到象它的語法所暗示的——讓程序員從這個問題中得到解脫。況且，它對於延遲其實也是有著隱含處理策略的，這個策略通常就是等待（block）。好吧，我們必須承認，這並不是在解決問題，而是在逃避問題。
至少也要直面問題，對吧。實際上 javascript 一直都被用來處理延遲的問題。對於 browser 里的代碼來說，xhr 要到伺服器上去走一個來回，這是顯而易見的延遲，必須要用回調來做處理。對於 server 來說，問題還是一樣。到資料庫里查詢，同樣也要消耗時間（只是，這兩個時間的量級不同，但是，也不能裝作沒有吧），為什麼回調就不適合了呢。我們是不是可以這麼說——至少在處理與其他系統的交互時（也就是 io），在非同步這一點上，前端和後端其實是沒有區別的。
小結一下，能夠表達非同步的邏輯，這是 javascript 作為膠水語言的核心優勢。或許會有比 javascript 更好的膠水語言出現（沒準是 coffeescript ？），但它也一定要解決好非同步的問題。
所有的程序都是在解決計算與 io 的問題（交互就是 io）。而，這個部分跟其他語言區別不大（或者乾脆用更合適的語言來實現，提供介面供「膠水代碼」調用就好）。
再外圍的，就是 API 的豐富程度與包裝問題。這方面，主要靠社區。人氣旺的問題就會被解決得快一些。人氣不旺的問題，就會被解決得慢一些。大概總之都是會被解決的吧。其他的都是 bonus 。same language, same table. write once runs everywhere. 神馬的，都是廣告詞。
作為中間件（前後端）和客戶端都是c++手工磊出來的產品的現任開發者之一，對於這個問題的答案是：可以讓所有同學在同一張桌子上吃飯的時候有共同的話題。
編程世界多姿多彩，引發了那麼多偉大的程序員前赴後繼投身於這個事業，就是因為多樣性和可變性，不明白編程語言怎麼就需要統一了？
他的意義在於將腳本的靈活性增加給了服務端，而不是讓前端能寫後端。兩端的差異不僅僅是語言，這就如同廚子說相聲。
遇到不同的問題，正確的做法是使用不同的合適的工具，而不是把一種工具改造成兩個都合適的。前後端遇到的問題根本沒有任何重疊的地方，根本不存在使用同一語言的需求，這麼搞的都是精神病。
我也不排除某個牛逼能把某個語言改造的二者都適合的可能性，但這也不會令你會了這個語言寫前端就會後端，前端牛逼就後端牛逼，技術細節與業務都是慢慢積累的，語言只是工具。
**********************題答完了，說點別的********************************經常有C++粉說語言不只是工具。實際上他說這話的時候只是把C++當成一個項目的產品，比如GCC，用來寫GCC的C++還是工具。當然以他們的智商一般看不清這一點，只會自我陶醉。也可能是自我陶醉影響智商，所謂「不識廬山真面目，只緣身在此山中」。
意義有限。
後端不管寫什麼語言，會一點基本的前端總是要的，不過多數並不能工程化的搞複雜界面、交互。
前端多少也要性一點網路通信，不過能寫重負載分散式伺服器卻不多。
完全沒有意義，app用單線程模式，server主要在對付並發上，一致性基本上都在犧牲某一塊，比如你的產品，客戶端要求比較低，只是簡單的展示一些靜態數據，對於fps要求低，這個時候你可以用一些偏向伺服器端的語言，反過來，如果你的產品重心在客戶端上，伺服器端要求低，這個時候你可以用一些偏向客戶端的語言，但是如果你的產品對於客戶端和伺服器端要求都比較高，比如很多遊戲，那這個時候你最好就是兩邊獨立開來
大型項目發展到最後可能都要考慮可維護性和代碼的可讀性。否則真有些項目在10年後，等到寫這個項目的人都不知道跑哪去，有些東西恐怕都動不得了。。。
能少找人 能少花錢
在工程上的意義基本為零
當 nodejs 開始火起來的那幾年，前端工程師感覺自己的春天馬上就要來了，人人都開始搞起 express ，妄想馬上就能在公司里挺直腰板做人了，升職加薪從此搭上語言的便車，走上人生高峰。
可過了幾年，事實的情況呢？
前端還是前端，後端還是後端，即使是在使用 nodejs 作為後端語言開發的公司。
其實可以從另一個角度去思考，為什麼會有這麼多的語言？單一語言確實沒法很好的解決全部問題
早就不是單語言單平台解決通用問題的局面了，不然為什麼還要有那麼多多語言支持的框架呢
推薦閱讀：
TAG:JavaScript | 編程語言 | Ruby | Node.js |