C# will infer lambda argument types from context, yes. So the code given:

  return Iterables.filter(employees, {Employee e -> e.isPartTime()});

Would be in C# (Since you'd also omit the { } and use "=>" not "->") something like this:

  return Iterables.filter(employees, e => e.isPartTime());

And it is a better C# idiom to make "filter" an extension method on IEumerable<T>.

  return employees.filter(e => e.isPartTime());

In fact, the existing extension method "Where()" is what you want.

  return employees.Where(e => e.isPartTime());

C# has had this for about 2 years now. And it is good. So, I'm looking at your code, and back to mine. Mine is shorter but still very readable (to me anyway). And it stays readable when you chain methods, e.g.

  return employees.Where(e => e.isPartTime()).ToArray();

I'll stay with mine right now.

There was also a comment to the above saying that instead of writing:

  List<Ticket<ThingYouLove>> tickets = new ArrayList<Ticket<ThingYouLove>>();

You could write:

  List<Ticket<ThingYouLove>> tickets = new ArrayList<>();"

Nice, but I prefer C# there as well where you use the var keyword, like this:

  var tickets = new ArrayList<Ticket<ThingYouLove>>();

   Nice, but I prefer C# there as well where you use the var keyword, like this:

     var tickets = new ArrayList<Ticket<ThingYouLove>>();

Actually, JDK7 is better in this case because it helps developer to "program to an interface".

What do you mean, that you can do something like this?

  List<Foo<Bar>> list = new ArrayList<>();

Programming to an interface is relevant between method calls, not inside the scope of a single method, which is typically where you use the var keyword in C#. This is programming to an interface, in C#, using the var keyword:

  public List<Foo<Bar>> MyMethod(...) {
      List<Foo<Bar>> result = new ArrayList<Foo<Bar>>();
      ...
      return result;
  }

  var list = MyMethod(...); //list will be of type List<Foo<Bar>>

In Java, the above would then look like this:

  public List<Foo<Bar>> MyMethod(...) {
      List<Foo<Bar>> result = new ArrayList<>();
      ...
      return result;
  }

  List<Foo<Bar>> list = MyMethod(...);

You don't save more characters in either case, neither is promoting programming to an interface more than the other, but I still think the var keyword is the better construct, since it removes type declaration consistently. It basically means that the compiler should infer the type of the variable immediately, without me having to spell it out. The Java construct on the other hand means something like: "In the constructor to a generic class, infer the generic parameters from the type of the variable the result is assigned to", which is a weaker construct, a less expressive one, a less flexible one.

Both are still syntactic sugar implemented as compiler tricks, but the C# one simply does more.

Could you expand on what "program to an interface" means to you in this context, I'm not getting it. Assume that I know what it means in the usual context, of depending on the services of an interface type not a concrete type.

With the var keyword the variable will be the exact same type as what you initialize it to, not an interface.

  List<Foo> list = new ArrayList<Foo>();

...is programming towards an interface, whereas

  var list = new ArrayList<Foo>();

...isn't, because the type of list will be ArrayList. I think his point was that with the new Java stuff you could instead do

  List<Foo> list = new ArrayList<>();

...which would then be explicitly programming towards an interface, while still not having to type so bleeding much.

Programming to an interface just doesn't seem so useful within the scope of a method.

It's interesting that the latest Java does not include the var keyword, as JavaFX (which is modeled after JavaScript) uses the var keyword and does type inference on regular Java types.

You have to use => instead of ->. This got me many times too ;)

Good point - this is the first time it's got me, but then I don't look at much java.

Minor nitpick: The lambda operator in C# is "=>"

Whoops, I have fixed that cut-and-paste error. I hadn't noticed that the java code had another gratuitous difference.