作为一个一心想做个什么网站的屡败屡战屡战屡败游走于各语言框架之间脚踏N只船反复尝试但一直没找到满意的web框架和orm方案的杯具的我来说，继续用Java版的Play+Ebean，再考虑Japid当View，也许是目前最好的选择了。虽然还有着各种不满意，但放低标准端正心态，生活才可以更美的。
Scala在开发后台并发程序方面，可以说已相当成熟，有越来越多的公司招聘Scala程序员开发此类程序。相比Java，这的确是Scala的一个强项。Scala的一些弱点如编辑器支持不够好、编译时间过长等，对这类程序影响不大，绝对可以忽略。而语言层面的改进和对并发的优良支持，可以大幅提高其开发效率。
然而说到Web，Scala处境尴尬。持久层、View层、编译时间、热修改、编辑器支持，这些对于Web开发比较重要的因素，Scala反而不如Java。Scala界有一个官方推荐的Lift框架，得到很多资深人士的支持，个人以为这只是因为没有太多选择。Play现在押宝Scala，其2.0版本推出在即，拥有众多让人激动的特性，如热修改、新View层、新持久层等，如果这个持久层经受住了用户的检验，那么Play的前景将会相当光明。只有它可以担当起拯救Scala web的重任，当然还需要时间检验。所以目前还不是使用Scala开发网站的好时候。
Groovy是一个动态语言，强项在于脚本程序和Web。在Groovy界，只有一个web框架，即grails。Grails越来越小众，因为它过于模仿rails，扬短避长。会学groovy和grails的大多是Java程序员，其特点是喜欢静态类型、依赖编辑器，但groovy/grails在这两方面仿佛故意与人作对。groovy语言明明可以设计得稍静态一些，以提高性能和讨好编辑器；grails也明明可以设计得不那么像Rails，而突出其JVM平台的优势，这样才能利用JVM和Java的优势，做出更符合Java平台的框架。可惜，现在已经晚了。
Groovy++是对groovy的改良，提供了动态与静态类型相结合的方式，大幅提高性能，并带来一些不错的新特性。我认为这才是正确的道路。毕竟在写程序时，有时适合静态有时适合动态。如果Groovy从一开始就这么设计，现在肯定会发展得相当不错。然而让人遗憾的是，groovy的开发人员对此毫不支持，认为其多此一举，并表示不会将其并入Groovy。所以Groovy++的发展前景并不理想，毕竟人单力弱，还不被支持。
最后，我把希望寄托于至今还未发布的Kotlin身上。Kotlin和Groovy++比较相似，只是它完全不支持动态类型。它比Scala简单，与Java更亲近，也不像Groovy那样动态。它其实很像是几个版本之后的Java。之所以看好这个语言，是因为它将会有与Java同水平的编辑器支持，还有商业公司在后面推动，不像Groovy++那样只有几个人在努力。我觉得Jetbrains应该把Groovy++的开发人员招过来，一起开发Kotlin.
Java已经有太多的历史包袱，如同一只大象，再也无法轻盈。期待Kotlin不会让我失望。