代码之家  ›  专栏  ›  技术社区  ›  Jim Ferrans

groovy语言的稳定性如何?

  •  23
  • Jim Ferrans  · 技术社区  · 15 年前

    我们正在用Java编写一个大型的生产系统,我在考虑是否可以在JVM的动态语言之一中编写一些组件。Groovy似乎是Java互操作性观点的最佳选择。但是,groovy实现是否足够可靠,可以在生产中使用(我假设如此),并且groovy语言规范本身是否足够稳定,这样我们就不必在一两年内大幅修改生产代码了?你的经历是什么?

    总结(5/30/09):好的评论,我的感觉是你应该谨慎地采用groovy来进行关键任务的生产使用,对于像组合测试用例这样的辅助用途来说这是可以的,并且有一个中间地带,它可能是可以的,但首先要做你的家庭作业。性能是一个问题,需要与开发人员生产力的提高相平衡。基于groovy的使用,bill和ichorus有同样有用的答案,所以这是一个掷硬币游戏。

    更新(2009年12月3日):最近我认真地看了一眼 Scala ,另一种JVM语言。它是由Javac编译器的原作者Martin Odersky和Java泛型的合作设计者设计和实现的。scala是一个强类型,但是使用类型推断来除去许多样板文件。它是面向对象和函数式编程的完美结合。詹姆斯·高斯林 likes it . james strachan,groovy的作者, likes it too . 奥德斯基写javac的经历意味着scala的原始 performance is not far from Java 是的,令人印象深刻。

    更新(4/26/11):看看 Groovy++ 是一个静态类型的groovy扩展, performance 相当于Java。看起来很有趣。

    6 回复  |  直到 11 年前
        1
  •  20
  •   cdeszaq Sudhir N    11 年前

    编辑 :四年后的今天,groovy变得更加坚实了。

    我可以全心全意推荐它用于生产级项目。


    我使用groovy来支持生产应用程序已经有一段时间了,为此,它已经足够稳定了。至于在真正的生产代码中使用groovy,我不认为我会这样做。groovy做了太多令人惊讶的事情。在这方面,在过去一年左右的时间里,情况已经好多了,但每隔一段时间,我就会遇到一个由于生成的代码而难以跟踪的错误(我的问题似乎围绕范围界定)。

    我已经摆脱了groovy(虽然我们使用的简单而坚实的东西仍然存在),并且使用了python(jython实现),在我看来,这更容易预测。而且,在可读性方面,python优于groovy。

    您可以在groovy中编写一些非常有趣的代码,包括闭包、运算符重载等等。

    这些语言用于辅助代码的方便和快速使用……如果需要的话,这些代码可以即时关闭。这些都没有在生产中。我不认为我会投入生产,除非它是一个权宜之计,让一些关键的东西迅速走出大门,或作为概念或原型的证明。

    在把它放到实际生产中的情况下,它必须是在最可怕的情况下,我会指派某人在下一个版本中用纯Java重写它。我有98%的人相信这两种方法在生产上都可以,但那2%太不必要了。

        2
  •  17
  •   billjamesdev    15 年前

    我们在Grails上运行了几个生产应用程序(使用groovy作为语言)。到目前为止,还没有出现任何问题。至于JVM兼容性,看看过去5年中JVM字节代码的变化有多小…增加了一条指令,没有一条被观测到。

    明年会推出新版本的groovy吗?对。你需要换衣服吗?不,尽管你可能想,1.6是一个巨大的速度提高。

    这给我们带来了groovy的主要缺点,速度问题。显然,Groovy比直Java慢。当前数字最多为10 时代 慢一点,对于某些动作。也就是说,你的CPU是应用程序的瓶颈吗?对我们来说,这主要是数据库访问和延迟。如果对你来说是一样的,那么CPU用200毫秒而不是35毫秒来处理页面请求又有什么关系呢?

    这是Groovy唯一的问题吗?不。动态语言有重构的困难,因为代码中的任何地方都不一定有完整的类规范。但是,较小的代码大小部分地平衡了这一点,从而更容易找到修改代码的位置。

    无论如何,groovy是一种非常适合生产使用的语言。如果你害怕可靠性,就把它和Java混合在一起用于你的“关键”代码。这是groovy最好的部分…它与Java类混合起来多么容易。

        3
  •  4
  •   Jim Ferrans    13 年前

    我目前正在探索使用groovy只编写单元测试。它的作用是

    1. 允许编写测试的潜在乏味部分用比Java稍微简单的语法来完成。
    2. 使groovy代码停止生产。
    3. 允许大部分代码库以非Java语言编写。

    当然,我们还没有开始,但这至少是我尝试将备用的JVM语言引入我们的新项目(可能还有现有项目)的方法。我和你有同样的顾虑,更关注性能而不是稳定性。

        4
  •  3
  •   ivan_ivanovich_ivanoff    15 年前

    脚本语言在句法特征方面发展得“太快”。

    如果您希望JVM的语言与 多年来,
    爪哇 是你唯一的选择;)

    顺便说一下,我不认为代码的可读性是 由脚本语言自动确保。

        5
  •  1
  •   mindthief    12 年前

    我们使用Grass/Groovy作为我以前公司的主要后端,从这个经验中,我会说,在大多数情况下,我会选择Groovy在Java中遇到,因为它无缝地与Java进行交互,否则会更加有趣和富有表现力。此外,我预计数据库几乎总是我的应用程序的瓶颈,而不是语言性能,而且据我所知,我们在groovy中没有遇到任何稳定性问题/错误。

    但在大多数情况下,它通常不是关于GroovyVSJava——它是关于Groovy/Java+可用库与其他语言(如Python/Jython/JavaScript / Ruby +可用库)的。还有很多其他的考虑,比如社区的强度、针对特定应用程序的相关技术的成熟度等。特别是对于Web开发,Grails是相当不错的,但是社区似乎缺乏。我的总体意见是我将继续使用python或node.js。如果我需要JVM,我将使用Jython兼容的python web开发环境。

        6
  •  1
  •   Community CDub    7 年前

    我和groovy玩了一个月左右。简单性很棒,动态语言功能也很酷。然而,速度绝对是个问题。而且,groovy控制台真的很糟糕。你不能做你能做的事情,例如在python中。每隔一段时间,我必须重新启动控制台、重新导入、东西等。在控制台模式下,它也会不断忘记我在变量中输入的值;不知何故,它们超出了范围。(是因为合资公司吗?我不知道。)我无法从我的头脑中想出一个例子,但是我在groovy控制台中得到的行为与我在grails控制台中得到的行为不同,并且与我在脚本中编写代码得到的行为不同。

    还有几个警告。注意Groovy几乎是,但不是100%兼容Java。例如,这不会编译:

    public class HelloWorld {
    
        public static void main(String args[]) {
            System.out.println( "Hello, world!\n");
        }
    }
    

    也可以看看 How to get classpath in Groovy?