背负了太多Java平台兼容的包袱，为了大量利用Java平台的强大功能，在设计方面处处考虑两者的共通性。如语法方面：为了兼容JavaBean规范，通过@BeanProperty注解来实现getter和setter，显得古怪，也现实上增加了语法层面的复杂度 - 优点是缺点，缺点是优点......
以上这点，我估计Groovy、Clojure，也有类似的情况吧？ 基于Java平台，在享受Java强大支撑的同时，必然也要受限于Java平台，这点我不是很喜欢，如果说做Java EE开发，旧有的知识已经很熟练的情况下，学习Scala的意义必然大大降低了，那么，剩下来吸引我的语法糖，其独特之处到底在哪儿？实际上，函数式的影子，在Ruby上已经展现地很好了......
而于性能，估计要不同场景不同分析，在需要充分考虑性能的场景下（不是每时每刻都需要着重考虑性能的，只有在少数情况下，性能问题才会浮现），Scala具备一定场景应用优势，就是其招牌式的并发能力，进一步讲，我认为是方便并发编程的能力，因为它在这方面封装地很好，便于使用，但千万别搞错了，绝不是并发能力，因为，Scala跳不出Java平台的掌控。
另一方面，说是Scala进军了.Net平台？但我查了下，好像许久未更新了？退一步而言，就算是在.Net平台落地生根、开花结果，也只是把上面一句话变变而已：“基于.Net平台，在享受.Net强大支撑的同时，必然也要受限于.Net平台”。
据此，我已深信不疑，Scala绝对取代不了Java。通过这种植入式（如JSR-223规范）的实现，永远都不可能取代Java，再好（至少从目前来看）也是绿叶配红花。即使是在语言层面，除非官方原生直接支持或吸取借鉴，否则也不可能取代。但我们应该看到，光从语法角度看（因为我是语法糖控），Scala很“现代”，Java已“老旧”，Java的后续版本，是不是也会借鉴一些“时髦点的东西”呢？我觉得这是肯定的。
很遗憾，不管你喜不喜欢Java，它还是会摆在哪儿。但Scala给了你多一种选择，你可以选择它，一行搞掂getter/setter，或者像这样：
"Hello".foldLeft(List[BigInt]())((b,a) => a :: b).reverse.reduce(_ * _)
而不用写罗罗嗦嗦的Java语句。但自己心里一定要明白，你喜欢的东西并不能取代Java，你也不应该否认Java，虽然你可以骂Java、讨厌Java。
如果你第一次接触函数式语法，恰好又是通过Scala，你会喜欢上Scala；同样道理，如果你是通过Ruby第一次接触函数式语法，估计你深深喜欢上的就是Ruby了。无论如何，你接触第二门类似语法语言的时候，你的热情必然不太可能燃烧起来 - 所以，如果你想扩展视野，你选一门差不多的语言来学就好了。
回到Java上来说，立志于Java平台开发的，还是应该首先掌握Java语言本身，走稳了，再学飞。
基于兴趣来看待Scala比较现实些 - 有兴趣就学，没兴趣就算了。我需要Scala吗？
