Both Spring and Guice's ecosystem didn't immediately exist after launch. The success of both is due in large part to the fact that their ecosystems were created. Every framework/community has to start from 0 or close to 0. Therefore, Silk will require early adopters to jump on board and start building. However, even before that, just like with Guice, people might use it for large applications and do most of the work themselves. They will do this if they feel it offers a substantial benefit over others.
I don't know quite yet if Silk offers these benefits. However, I will state (bluntly) that they way the announcement of Silk was handled makes me leery. As for Dagger, it looks very cool. I like the use of javax.inject and I also like the compile-time errors (and some other bits as well). I do wonder if you have actually tested and proven that compile-time code generation is actually faster. The reason I say that is that last year (if anyone recalls) when I was doing my major performance testing, I found that it was actually the opposite. My tests were inside Prime-MVC for the parameter binding system (setting user.name parameter into a object). I was using fastclass rather than compile-time generation, but I found that it was slower than reflection after warm up. I was running iterations of about 10,000,000 I think. I recall reading somewhere that after a certain number of invocations, the JVM would optimize reflection to generated code. If you have tested it and found that it was faster, I will definitely need to check out how you did it and perhaps grab some of the code for Prime. -- Brian On Apr 7, 2013, at 10:14 AM, "[email protected]" <[email protected]> wrote: > I don't fully agree on the criteria of this comparison. Jan, you and I > disagree on which DI features are useful and which ones are harmful! > > Having worked a some large Guice applications (dozens of modules) I think > Guice's biggest flaw is that it is very dynamic. Although this is essential > for building powerful frameworks, it also makes larger codebases more > difficult to navigate & understand. > > Silk is more dynamic than Guice. Features like loose multibinds, > mostPreciseOf() and TARGET_INSTANCE scare me just a little. The lack of > annotations means it's not obvious from the application code which classes > participate in dependency injection. I'd have to actually use Silk to learn > if this is a problem in practice. > > I've also been working on a Guice-like dependency injector called Dagger. Its > like a mini Guice, that intentionally omits dynamic bindings. I've filled out > how Dagger stands for the Guice-vs-the-World comparison here: > https://docs.google.com/spreadsheet/ccc?key=0AqH4uBT50p0tdEhLOEU1WHB4RUZjR2RURVF6MThkZnc#gid=0 > The Dagger column confirms that it does less than the other dependency > injectors. For me this is a feature, but it does limit the appeal of Dagger > for larger projects. > > And for larger projects is where the entire comparison itself starts to fall > down. > > When a developer chooses between Guice and Spring and the others, they're > less interested in features and more interested in the ecosystem. Spring has > a huge ecosystem and will integrate with everything. But I think Guice's > ecosystem is better still. It has first-party integration with JPA and > servlets. There's third-party integration for lots more, and it's possible > (if difficult) to write rich integrations for other infrastructure. > > Until Silk has an ecosystem like this around it, it's appeal for most > applications will be limited. > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/google-guice?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
