InfoQ

新闻

Java之外,选择Scala还是Groovy?

作者 宋玮 发布于 2008年1月14日 上午4时25分

社区
Java
主题
动态语言,
语言
标签
Groovy,
JVM

Scala和Groovy都是基于JVM的语言,相比Java都有更加简明的语法和丰富的表达能力。对于那些既想不脱离开JVM又想避免Java繁琐的语句的开发人员来说,Scala和Groovy都是不错的选择。可是选择哪一个才能在未来发展过程中取得先机呢?哪一个是未来发展的方向呢?这些都是困扰开发者的难题。

去年早些时候,一篇名为“Scala,Groovy的杀手? ”的博客对Scala和Groovy进行了对比:

Scala和Groovy之间的核心区别在于前者是静态类型的。有些人可能争辩说这使得达到脚本化目标变得更加复杂了,而脚本化正是Groovy的动机。然而,Scala有完整的体系特征,这使Groovy看上去更像个玩具。比如,Scala有“sequence comprehensions”。该要素导致对算法的表述非常紧凑和强大。

Scala还有更多被证明是非常有用的特性,如嵌套类,currying和代数类型模式匹配。它还支持类似于JDK1.5所增加的泛型和注解。这些还都只是冰山一角。

之后,Derek Young撰文“Scala对比Groovy:静态类型是性能的关键”。在文中他举了一个实际的例子,试图说明针对同样的算法,Scala的性能远高于Groovy。

然而,Scala并不是尽善尽美的,它也有一些明显的缺陷。Rick Hightower在最近发表的一篇博客中,尖锐地批评了Scala的语法问题:

Scala并不是更好的选择。在阅读了Scala的文档之后,我的想法是:虽然这种语言的特性听起来挺好,但是语法却让我想放弃。为什么事情非要为了不同而不同?Scala让Groovy看起来比以前更加美味可口。

憎恨是个很强烈的词。我恨Scala的语法。请不要再推进这种语法了。……Scala有好的思想吗?有。借用过来就行了……

总而言之,Scala看起来像下一个被过度宣传的语言。只需要把其精华引入到Groovy中,然后扔掉那些糟糕的语法。我最喜欢的Scala特性是推理类型和强类型。C#3.0也有这些。(我不用C#,不见得我不喜欢它的一些特性。)

Rick Hightower还建议Sun应该在Groovy上进行投资,而不是对JRuby作无谓的投资。

Groovy更像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构建在这些概念之上,并且显著地减少了在Java平台上构建Web应用的复杂程度。不同的是,这些是建立在已确立的如Spring和Hibernate这样的Java技术之上的。

目前,Scala和Groovy两种语言都在快速发展的过程中。就目前的情况来看,Groovy的优势在于易用性以及与Java无缝衔接,Scala的优势在于性能和一些高级特性,如果在发展过程中两者能互相借鉴对方的优点来充实自身,对开发者来讲无疑是福音。正如第一篇所引用的博客作者最后提到的那样:

大家并不想看到一场殊死斗争,而是想看到更注重实效思想的Groovy团队能与更具有学术思想的Scala团队一起合作,制作出一门既强大又易用的语言。

你会将赌注押在谁身上呢?

无需押宝 发表人 Island Chen 发表于 2008年1月14日 上午8时2分
Agreed,如今许多软件致胜的关键(功夫)恰在程序语言之外。 发表人 Charlie Zhang 发表于 2008年1月15日 上午12时18分
Groovy Web 发表人 Joe Huang 发表于 2008年1月14日 下午9时55分
Re: Groovy Web 发表人 james qiu 发表于 2008年8月15日 上午6时46分
  1. 返回顶部

    无需押宝

    2008年1月14日 上午8时2分 发表人 Island Chen

    我已经在用Groovy了,目前用起来还是挺舒服的;暂时没有去试用Scala的动力。 说实话,语言很重要,但不是最重要的,而且语言之间的切换/共用并没有那么可怕。无需强求一种语言满足所有需求,熟悉超过一种编程语言应该是开发人员/爱好者的基本要求。

  2. 返回顶部

    Groovy Web

    2008年1月14日 下午9时55分 发表人 Joe Huang

    我认为不一定完全使用grails开发web应用,因为目前它对web服务器的兼容性还不算非常好,可以考虑使用groovy+java混合编程以减低web的复杂度

  3. Island Chen 于 2008-1-14 8:20 说: 说实话,语言很重要,但不是最重要的,而且语言之间的切换/共用并没有那么可怕。无需强求一种语言满足所有需求,熟悉超过一种编程语言应该是开发人员/爱好者的基本要求
    根据我的实践经验,很多情况下比编程语言更重要的,往往是编程语言之外的环境和资源(参照系统论的观点)。其实,软件研发的重心,早就发生转移了。 太极敏捷教练 张恂 www.zhangxun.com

  4. 返回顶部

    Re: Groovy Web

    2008年8月15日 上午6时46分 发表人 james qiu

    Groovy 的首次启动速度太慢;需要进一步改进; 在服务器端,第一次装置后,运行速度还可以接受; 希望它的启动速度能够快点,至少接近beanshell

深度内容

和Google互补的搜索引擎Wolfram|Alpha

Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。

SOA契约成熟度模型

本文说明了所推荐的契约版本管理设计策略是如何与SOA成熟度模型发生联系的。文章目的是为实现版本管理和可组合性提供一个路线图。

数据服务简介

Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。

分块云计算

在本文中,Jimmy Nilsson描述了一种他在过去数年间观察到的一种正在缓慢成长的架构风格,他把这种风格称为“分块云计算”。

豆瓣网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

融合思想:深入探索S#arp架构

Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。

王雷谈开源以及新兴市场计划

中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。

使用HTML5构建下一代的Web Form

HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。