Java之外，選擇Scala還是Groovy？

Scala"微軟雅黑","sans-serif"'>和Groovy都是基於JVM的語言，相比Java都有更加簡明的文法和豐富的表達能力。對於那些既想不脫離開JVM又想避免Java繁瑣的語句的開發人員來說，Scala和Groovy都是不錯的選擇。可是選擇哪一個才能在未來發展過程中取得先機呢？哪一個是未來發展的方向呢？這些都是困擾開發人員的難題。

 

去年早些時候，一篇名為“Scala，Groovy的殺手? ”的部落格對Scala和Groovy進行了對比：

 

Scala"微軟雅黑","sans-serif"'>和Groovy之間的核心區別在於前者是靜態類型的。有些人可能爭辯說這使得達到指令碼化目標變得更加複雜了，而指令碼化正是Groovy的動機。然而，Scala有完整的體系特徵，這使Groovy看上去更像個玩具。比如，Scala有“sequence comprehensions”。該要素導致對演算法的表述非常緊湊和強大。

 

Scala"微軟雅黑","sans-serif"'>還有更多被證明是非常有用的特性，如嵌套類，currying和代數類型模式比對。它還支援類似於JDK1.5所增加的泛型和註解。這些還都只是冰山一角。

之後，Derek
Young撰文“Scala對比Groovy：靜態類型是效能的關鍵”。在文中他舉了一個實際的例子，試圖說明針對同樣的演算法，Scala的效能遠高於Groovy。

 

然而，Scala並不是盡善盡美的，它也有一些明顯的缺陷。Rick Hightower在最近發表的一篇部落格中，尖銳地批評了Scala的文法問題：

 

Scala"微軟雅黑","sans-serif"'>並不是更好的選擇。在閱讀了Scala的文檔之後，我的想法是：雖然這種語言的特性聽起來挺好，但是文法卻讓我想放棄。為什麼事情非要為了不同而不同？Scala讓Groovy看起來比以前更加美味可口。

 

憎恨是個很強烈的詞。我恨Scala的文法。請不要再推進這種文法了。……Scala有好的思想嗎？有。借用過來就行了……

 

總而言之，Scala看起來像下一個被過度宣傳的語言。只需要把其精華引入到Groovy中，然後扔掉那些糟糕的文法。我最喜歡的Scala特性是推理類型和強型別。C#3.0也有這些。（我不用C#，不見得我不喜歡它的一些特性。）

Rick Hightower"微軟雅黑","sans-serif"'>還建議Sun應該在Groovy上進行投資，而不是對JRuby作無謂的投資。

 

Groovy"微軟雅黑","sans-serif"'>更像Java，更容易上手，文法也讓開發人員不反感。為什麼Sun在JRuby上投那麼多錢呢？

 

投資應該給Groovy。這樣瞭解Java的開發人員可以更快地學習Groovy，而且如果有工具支援他們，那麼就更可能這樣做。

為了說明Sun投資在Ruby上的不明智，Rick Hightower還引用了一幅統計圖表來說明企業採用Ruby的趨勢還是比較低的：

 

 

 

另外，無論是Ruby、Scala還是Groovy都有對應的Web架構，且對應的架構都是用各自對應的語言編寫的。這些架構分別是Rails、Lift和Grails。儘管Lift和Grails中的許多東西都從Rails借鑒來的，但是Grails對其他已有Java技術架構進行了很好的繼承，這無疑會保護使用者或廠商在這方面的已有投資。Grails架構參考文檔中這樣描述：

 

Grails"微軟雅黑","sans-serif"'>構建在這些概念之上，並且顯著地減少了在Java平台上構建Web應用的複雜程度。不同的是，這些是建立在已確立的如Spring和Hibernate這樣的Java技術之上的。

目前，Scala和Groovy兩種語言都在快速發展的過程中。就目前的情況來看，Groovy的優勢在於易用性以及與Java無縫銜接，Scala的優勢在於效能和一些進階特性，如果在發展過程中兩者能互相借鑒對方的優點來充實自身，對開發人員來講無疑是福音。正如第一篇所引用的部落格作者最後提到的那樣：

 

大家並不想看到一場殊死鬥爭，而是想看到更注重實效思想的Groovy團隊能與更具有學術思想的Scala團隊一起合作，製作出一門既強大又易用的語言。

你會將賭注押在誰身上呢？