Live data from Hacker News

Why Java is still relevant

medium.com

71–80 of 82 posts

Re: Why Java is still relevant

#71

Earlier quoted context omitted.

Is there actually a way to properly debug LINQ expressions? I haven't figured out how to get Visual Studio to step through lambdas or break halfway through the chain (eg break after the filter call has completed and before reduce runs in the above example). But I'm not sure if I'm missing some blindingly obvious.

I don't know, but it just hasn't been a problem. If something's that wrong with the expression chain I can just break it up temporarily.

Thing is though, now you've changed the recipe from what you intend to run in PROD. You linearized it to gain a debugging advantage that you lose when you re-lambdaize it.

Re: Why Java is still relevant

#72
post #68

Earlier quoted context omitted.

How can you not debug "junk" like that?

I can see my view is already unpopular but you asked a fair question. It's several key pieces of logic jammed together on one line. That's not the part that bugs me though, it's wondering how this is going to play out. I can imagine multiple threads servicing the Lambda stuff and it reminds me of trying to debug Camel code hopping around debug screens trying to stay up with all the async stuff going on just to find a…

I guess I can understand if java doesn't allow for debugging code similar to this. Being fond of lisp/scheme languages such as racket though, I find this very clear and is of course easy to debug in those languages.

Re: Why Java is still relevant

#73

Earlier quoted context omitted.

That was my reaction as well. We are using Go in production here and I'm very much a Go fan, but I'd be surprised if Go caught up to Java in so little time.

I was referring to this benchmark: http://www.techempower.com/benchmarks/

That benchmark makes it clear Go has not caught up to Java in performance.

Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).

Re: Why Java is still relevant

#74
post #41

I like java as a language. It's consistent, has less warts than many languages and the jvm is pretty darn awesome. What I don't like is the java ecosystem. Guice? I've nothing but bad experiences with it. Just about every framework out there that I've used in java has gotten in my way more frequently than it's been helpful. Java Api's (excluding much of the stdlib) almost all seem to be made to annoy me. Java's great…

I work on a large application that uses Guice, and it doesn't seem so bad, so YMMV.

Mind you, this may just be because there are other things in the application that are so much worse.

Re: Why Java is still relevant

#75

Earlier quoted context omitted.

I was referring to this benchmark: http://www.techempower.com/benchmarks/

That benchmark makes it clear Go has not caught up to Java in performance. Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).

I counted go lead on 3 of the tests, but I agree with your point, will fix the article accordingly, thanks!

Re: Why Java is still relevant

#76

Earlier quoted context omitted.

Great feedback, I will certainly look up these books, thanks!

btw, Elements of Style is a very short book (~26 pages) and early editions are available online: https://courses.washington.edu/b572/public/StrunkWhite.pdf

It's also not very good:

http://chronicle.com/article/50-Years-of-Stupid-Grammar/2549...

Re: Why Java is still relevant

#77
post #68

Earlier quoted context omitted.

How can you not debug "junk" like that?

I can see my view is already unpopular but you asked a fair question. It's several key pieces of logic jammed together on one line. That's not the part that bugs me though, it's wondering how this is going to play out. I can imagine multiple threads servicing the Lambda stuff and it reminds me of trying to debug Camel code hopping around debug screens trying to stay up with all the async stuff going on just to find a…

That code is exactly equivalent to:

int sum = 0; for (Integer x: Arrays.asList(1, 2, 3, 4, 5, 6, 7)) { int x2 = x * x; if (x2 % 2 == 0) sum += x2; }

No threads, no weirdness. It's just a different syntax for a loop, really.

Re: Why Java is still relevant

#78

Earlier quoted context omitted.

I write code like that with LINQ and such in .NET all the time and have no problem debugging it.

Is there actually a way to properly debug LINQ expressions? I haven't figured out how to get Visual Studio to step through lambdas or break halfway through the chain (eg break after the filter call has completed and before reduce runs in the above example). But I'm not sure if I'm missing some blindingly obvious.

this probably isn't the place to start a chain on how to do this, but if you wrap the statement in the lambda in a {} block and explicitly return the expected value, you can insert line breaks and set breakpoints.

i'm not familiar enough with the vocabulary to explain it perfectly, but i do it all the time.

example: list.Find(o=> { if (o.prop == "foo") { return true;} // visual studio will allow a breakpoint here else { return false;} });

Re: Why Java is still relevant

#79

Earlier quoted context omitted.

That benchmark makes it clear Go has not caught up to Java in performance. Out of the 10 tests that have both Java and Go results, Java is faster than Go in 9 tests while Go is faster than Java in 1 test (by 0.2%, so not significant).

I counted go lead on 3 of the tests, but I agree with your point, will fix the article accordingly, thanks!

Only 1 of those 3 tests (the very 1st one) also contains Java results. The other 2 are Windows tests that don't contain any Java results.

Hence I said that out of the 10 tests that contain both Go and Java results Go only beats Java (by a statistically insignificant 0.2%) in 1 test while Java beats Go in the other 9 tests.

Re: Why Java is still relevant

#80

Also a lot of the de-facto Big Data/NoSQL/Distributed Computing stack is Java(/Scala). Hadoop, HBase, Cassandra, Neo4j, Storm, its actually pretty interesting to note that most of the popular nosql solutions are in Java. On top of that its the number 3 language on Github. I'm not a huge fan of Java but I'd be pretty surprised if someone was saying Java wasn't relevant. Don't quote me on this, but its also the fastest…

Java and Mono have been shown to be roughly comparable overall in speed, each a bit worse or better than the other in some ways, I've read.

Shown where? Mono's JIT is nowhere near as good as OpenJDK/Hotspot.
Post reply on HN