At least get rid of the splash video that appears the 1st time you go to the homepage. This isn't 2002.

I'd be much more likely to fire poisonous employees who immediately threaten others for preference differences

Bah, why did JetBrains have to rebrand? :<

I do like the new design.

The main logo design is actually pretty clever.

It doesn't mesh well with other object-oriented concepts.

static

methods can't be an implementation of an interface's or class's method. They can't be overridden either. They're nice and convenient until they aren't.

Doesn’t this argument fall apart in FP languages?

There are tons of good reasons to have static methods without the overhead of allocating objects. Imagine the Math class having to allocate an object just to figure out the min or max of two numbers.

It always depends on the use case imho.

Or maybe Injekt ?

I'm not saying there's no instance in which a method that isn't bound to an object makes sense. If that were the case, the Kotlin team wouldn't have chosen to keep the idea around in the form of companion objects. But it's easy to get carried away and stuck with an inflexible situation if you make everything static

In my opinion there is nothing wrong with static methods, however static member variables on the other hand will stab you in the back eventually.

What about using higher-order-functions as a replacement for DI ?

@rocketraman Dagger 2 is fine but I prefer to save it for Android apps. For back end apps, I like Guice’s assisted injection a lot (easier to use than Dagger’s explicit injection and AutoValue)

@jan.rabe static methods have their use as helper functions but not as mechanisms to deliver singletons or dependencies

@janvladimirmostert Using higher order functions just pushes back the problem: how do you pass these functions around?

@cedric what is your general opinion of guice vs dagger 2? we have been considering switching from dagger to guice for android... but not sure if it plays well with the rest of the ecosystem (retrofit, etc)

No, don’t use Guice on Android. Too much reflection not designed for it.

It’s a bit painful to explicitly request injections with Dagger but it’s a price I’m happy to pay on Android since it gives me 100% static certainty.

On the back end, the reflection cost is negligible and the advanced functionalities that Guice gives you outweigh the reflection downside in my opinion

I'm still not personally a fan of Guice even on backend. Too much happens at runtime. Dagger takes a much less magical approach that makes it simpler and easier to understand your object graphs

Dagger VS Guice: https://docs.google.com/spreadsheets/d/1Llu7pYX6Fa97PldhZe26UNyalb6QYrnohVPozFJzXSA/edit#gid=0

Nice doc!

Agreed @kevinmost , I like the explicitness of Dagger and fast startup times, even on the backend. Guice is great too, but overkill for most requirements. @cedric I use Dagger2 without AutoValue.

@janvladimirmostert Is that comparison with Dagger 1 or Dagger 2?

@rocketraman I’ve also been using Dagger2 without AutoValue, occasionally passing dependencies explicitly

Yep, I find it best for module level injections and overall module organization. Within a module, I use explicit injections if that doesn't cause a testability problem, otherwise I inject those too.

@rocketraman That doc was mentioned in 2013, so it's probably Dagger1 and an older version of Guice. See here: https://groups.google.com/forum/#!topic/denominator-dev/Nqt_tavJHqk How different is Dagger 1 from Dagger 2? Seems like a decent replacement for Spring IOC if we need DI in larger projects.

This is a pretty good summary of Dagger2 vs Dagger1: https://blog.gouline.net/dagger-2-even-sharper-less-square-b52101863542#.9gf1nxorm

Dagger 1 uses reflection, in Dagger 2 everything is bound at compile time. They are pretty different, not sure why they decided to call it “Dagger 2” instead of something else.