> why can't a group of programmers just copy the design of Rails to Java? [...] as of now, there is still no decent web framework for Java that is as easy to use as Ruby on Rails. Why is that? [...] Well, simply, because they can't.
> pretty much all of the Ruby language features come into play in some way. Rail's ActiveRecords [...] Ruby's runtime evaluation features. [...] you subclass ApplicationController [...] importing various mixins [...] attaching a call back [...] Ruby is dynamically-typed and garbage-collected. These features are simply not available in all other languages. Java's meta-programming features, for example, are just not powerful enough to implement a system like ActiveRecords. Rails is only possible because of Ruby.
Groovy and Grails tried to duplicate Ruby and Rails, even having soundalike names. Unfortunately, after its founder was managed out, Groovy (nowadays called Apache Groovy) lost its way and tried to diversify down many roads (e.g. generics, command syntax for Gradle, static type compilation, targeting Android) instead of sticking to its knitting and becoming the best possible JVM dynamic language for software like Grails, even eventually became good at none of its goals. So although it's a no-brainer that Grails would become as popular for the JVM as Ruby became for native apps (heck, Grails even bundles Spring), because of the incompetent project management of Groovy (which doesn't even have a roadmap now), Grails adoption faltered.
Use the right tool for the right job. This includes picking the correct language and the correct patterns for that langauge. Of course Ruby's patterns that take advantage of metaprogramming don't work in Java. But Java has a very mature Web library, Spring. It uses heavily uses dependency injection. I find DI to be a nightmare in dynamic languages like Ruby or JS but works great in Java.
We need good languages and good libraries. Just as we need good math and good physics in mechanical engineering. They exist at different layers and are not exclusive.
I'm curious, what's the problem with DI in dynamic languages? I don't really get what you're missing other than type safety, which is inherent to everything you do in dynamic languages.
> pretty much all of the Ruby language features come into play in some way. Rail's ActiveRecords [...] Ruby's runtime evaluation features. [...] you subclass ApplicationController [...] importing various mixins [...] attaching a call back [...] Ruby is dynamically-typed and garbage-collected. These features are simply not available in all other languages. Java's meta-programming features, for example, are just not powerful enough to implement a system like ActiveRecords. Rails is only possible because of Ruby.
Groovy and Grails tried to duplicate Ruby and Rails, even having soundalike names. Unfortunately, after its founder was managed out, Groovy (nowadays called Apache Groovy) lost its way and tried to diversify down many roads (e.g. generics, command syntax for Gradle, static type compilation, targeting Android) instead of sticking to its knitting and becoming the best possible JVM dynamic language for software like Grails, even eventually became good at none of its goals. So although it's a no-brainer that Grails would become as popular for the JVM as Ruby became for native apps (heck, Grails even bundles Spring), because of the incompetent project management of Groovy (which doesn't even have a roadmap now), Grails adoption faltered.