These are pluggable, orthogonal (intersection?) types, that can even be introduced or inferred for code that has already been compiled without them. I'm not a type systems expert by any means, but I haven't seen anything like it in any other language, certainly not a mainstream one.

There are currently Java 8 type systems for nullability, immutability and more.

[1]: http://types.cs.washington.edu/checker-framework/

    sorted(Comparator<? super T> comparator)

Say you have class Country { int population; int name; }. You want the names of the top 3 countries by population:

    countries.orderByDesc(x -> x.population).limit(3).map(x -> x.name)

    countries.sorted((x, y) -> Integer.compare(y.population, x.population).limit(3).map(x -> x.name)

    countries.sorted(by(x -> x.population)).limit(3).map(x -> x.name)

    <S, T> Comparator<T> by(Projection<S, T> projection);

    interface Projection<S, T> {
       Comparable<S> project(T value);
    }

It's still ugly, and would prevent e.g. a radix sort being used when projecting an integer as the sort key, or American flag sort for strings.

so one can write: ``` contries.sorted(comparingInt(Country::getPopulation)). ... ```

I've read this kind of thing everywhere, but is there any language/runtime/compiler that DOES DO this, or is it mostly a case of "an adequately advanced compiler" syndrome?

Especially for examples as the simple accumulation (addition) above, it seems especially difficult for the runtime to judge how to break down, what the parallelization overhead would be etc.

Also, this talk that I found on HN some time ago explains some of the gory details behind the idea: http://vimeo.com/6624203

Yes, that's an example of what I was talking about, and I know you can also do it with Apple's Grand Central Dispatch API.

But is Clojure's stuff implicit or do you explicitly ask for the parallel thing to happen?

What I'm asking is essentially: sure, a reduce/map/filter/etc can potentially run in parallel. But does that ever happen automatically when using common API's for map/reduce/etc, or do you have to explicitly tell it to do so?

And if it happens automatically, how does the scheduller knows it's a good idea to run stuff in parallel? For some tasks the overhead might even make the time needed worse.

     int sum = widgets.stream()
                      .filter(b -> b.getColor() == RED)
                      .mapToInt(b -> b.getWeight())
                      .sum();

    List<Widget> filtered = filter(widgets, new Filter<Widget>() {
        @Override public boolean keep(Widget w) {
            return w.getColor() == RED;
        }
    });

    List<Integer> weights = mapToInt(filtered, new Mapper<Widget, Integer>() {
        @Override public Integer map(Widget w) {
            return w.getWeight();
        }
    });

    int sum = sum(weights);

http://blog.hartveld.com/2013/03/jdk-8-33-stream-api.html

I've been around too long to trust the computer to figure out how best to do something. If I'm wrong then Java 8 leads the way to the end of programmers, similar to how robotics mostly ended how cars were manufactured.

  int sum = 0;
  for (w : widgets) {
    if (w.getColor() == RED)
      sum += w.getWeight();
  }

So they can't just take collections here and pretend they're streams (but you can obtain streams from collections).

But nice to see that the days of writing explicit loops just to filter a collection in Java are over. That being said, I still like Python's or C#'s syntactic enhancements to write generators/IEnumerables. The Spliterator in Java doesn't sound as easy to use and seems more aimed at low-level library code instead of user code. In the latter case you'd probably just get the stream from a collection again instead of creating it yourself. (You can apparently base it on a normal iterator, though, but the docs warn about it having bad performance in parallel scenarios.)

Geez, the C++ hate is unbelievable. I use it every day, and it's a great language. No way is it "virtually unusable". Some of the criticisms are justified, but the way people carry on about it is just absolutely beyond overblown.

More about the goodies in Java 8: http://www.techempower.com/blog/2013/03/26/everything-about-...

The one thing that I really hope for a future release of Java is a better literal syntax for dealing with maps and JSON.

Such jingoism adds nothing to the discourse. Someone can as easily find something in Java 1.5 that C# still doesn't have. So what does that prove? Nothing.

Like what?

mainly wildcards, you can design an interface which is covariant and contravariant, and real interference when calling a generic method.

What am I missing?

(Although: A workaround for java's bizarre stance that no function can exist without an object doesn't really strike me as a "feature". [Granted: this criticism is equally true of C#])

You can't make this stuff up.

EDIT: what I'm trying to say is: why his remark is inflammatory and unnecessary, it's also wrong. This API is perhaps the single worse example of why java makes API's look worse than C#, and there is nothing to be done about it until the JVM stops erasing types.

Scala never really run on the CLR, it's a vaporware, sorry a work in progress.

No, I really don't think so.

The above should no longer be an issue when/if we remove the primitive types in Java 10(?) as we can safely use Stream<Integer> and Predicate<Integer> (or Stream<int>).

(In C# System.Int32 is a value type, and an "int" is equivalent). A List<Int32> is equivalent to a List<int> and is backed by an array of ints.)

The reasons, IMO, are twofolds: 1) The huge install base in enterprise: changing language feature is a big deal, and like it or not, enterprises are conservative in this aspect. One only needs to look at all the garbages included with Windows in the name of backward compatibility. 2) Design by committee: Many vendors have stake in Java eco systems, all with their own agendas. To get them to agree on something take time.

In some ways, Java is victim of its own success. On the other hand, JVM is a very solid platform. Those impatient can go with Scala or Clojure. I could be snarky like you were and said Scala was light year ahead of C# in terms of feature evolving, but of course I know C# is a fantastic language which serves its users very well.

if I got in my delorean, hit 88 miles per hour, went to Sun Microsystems in the early 90's and convinced Guy Steele that yes, we should include Guy's currently 15 year old research of lexically scoped, first class functions into this new language which is designed to drag C++ programmers halfway to lisp, then java would have not been widely adopted, and this run on sentence would never have been written.

(And still: C++ managed to get lambdas before java did. How messed up is that? Extending Java is about 10x easier than trying to add something to the crufty minefield that is the C++ spec, and they still beat them to the punch.)

What I find really interesting about your comment is that I always thought C# was the closest equivalent to Java there was, and that I'd be happy using it if I was developing in the Microsoft eco-system (I gave up on QuickBasic/VisualBasic). It would make more sense if you were sniping at a language you felt was inferior if that language was also signicantly different than Java.

P.S. I didn't downvote you either

(Don't worry about, you know, backing up your point or anything silly like that. That might require that you know what you're talking about.)

I'll bite. C# is syntacticly and idiomatically more similar to Java than any other language. I'm sure how I can prove this, beyond saying "look at them!" – is there a counter example I'm missing?

I must admit that except for this two missing features, I'm quite happy with the java 8 release in term of features.

A bit hacky, but it works.

Yes.

Thank you for the quick advice, I'll be sure to ignore it. Because I don't care.

When describing the design of language, again, the very first thing Gosling says is, "Java is a blue collar language. It's not PhD thesis material but a language for a job. Java feels very familiar to many different programmers because I had a very strong tendency to prefer things that had been used a lot over things that just sounded like a good idea."

So: no research, no PhD, only proven stuff and nothing new. Regardless of your opinion of Scala (I don't like it), I think it's not controversial to say that Scala is on the exact opposite side of the spectrum.

[1]: http://dfjug.org/thefeelofjava.pdf

It is moving towards scala, just at an incredibly slow rate.

Scala is first and foremost a research language. It has some very good features and some terrible features. Also it is completely unopinionated. But that's how it's supposed to be: as a research language, its main goal is to figure out what works and what doesn't, so that mainstream languages years from now will know what works and what doesn't.

For example, which of the official new features in Scala 2.11.0 is research-y, would you say? We worked on faster incremental compilation, started modularizing the standard library, improved our infrastructure for better integration builds with SBT & Scala IDE. We did add experimental support for SAM types -- is it "research" to prepare for Java 8 interop? The main experimental features are of course reflection and macros, developed at EPFL. I'd say we've been pretty clear about labeling these experimental bits "experimental".

Despite reading your many "scala" rants on HN, I still don't know which features you think are 'terrible', just that you think there are some that confuse you and/or are allow you to something multiple ways (abstract classes vs. interfaces with concrete implementations say what???).

Care to actually articulate the 'terrible' features this time?

I don't want to be dragged into the Scala discussion again (after all, these are just opinions; I realize some people really like Scala, but for some reason, Scala people just find it hard to accept the very real fact that some people don't like it, and it's not because they haven't tried it or don't understand it).

Just recently I was hit by a runtime exception from a library which apparently decided that using undocumented unchecked exceptions was a good idea. The vast majority of open source libraries are not or poor documented, even ones which are used heavily (as in my case). In these, checked exceptions are a godsend as they MUST appear in the method signature.

For many programmers, exceptions just get in their way and they handle them poorly which is imho one reason for the bad reputation of checked exceptions.