Don’t call it a comeback: Java is still champ • Hacker News Board

Re: Don’t call it a comeback: Java is still champ

#511

Post by mwcampbell » Wed, Aug 10, 2022, 2:59 PM UTC

pron wrote: post #64

jeroenhd wrote: post #29

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

> but I think it'll slowly move the way of COBOL and FORTRAN That could be true of any language that's achieved great popularity, but in 2022 Java is the language that dominates server-side development (by plurality, not majority), it is a technological leader in areas of compilation, garbage collection, and low-overhead in-production profiling, no other single language looks posed to seriously challenges Java's domi…

> no other single language looks posed to seriously challenges Java's dominant position on the server (as PHP seemed for a while)

What do you think about JavaScript in this context? JavaScript seems at least as popular among today's full-stack web developers as PHP was 15-20 years ago. V8 might not be as optimal a runtime environment for servers as HotSpot, but that won't necessarily diminish the language's popularity.

Re: Don’t call it a comeback: Java is still champ

#512

Post by kaba0 » Wed, Aug 10, 2022, 3:40 PM UTC

cutler wrote: post #508

mesarvagya wrote: post #466

Earlier quoted context omitted.

Code like this is expected in Spring https://hastebin.com/jevibugiqu.less . Literally all the classes I see are filled with annotations. Can we even write code in pure java without a single annotation ? Theres a lot of magic going on with annotation. It works great while it is running. God forbid there is some issue and we have to figure it out where all the magic is happening.

It was the @Query annotation which finally killed Spring for me. So I have to stuff all my SQL into an annotation now if I want raw JDBC? Madness. **ck that.

Why would you have to do that? You can just inject an entitymanager to wherever you want to use it natively and do whatever you want.

Re: Don’t call it a comeback: Java is still champ

#513

Post by kaba0 » Wed, Aug 10, 2022, 3:53 PM UTC

blub wrote: post #478

bullen wrote: post #27

The only problem Java has is experienced C programmers don't build servers from scratch with it yet. Once they take that responsibility, the debate will be over because: "While I'm on the topic of concurrency I should mention my far too brief chat with Doug Lea. He commented that multi-threaded Java these days far outperforms C, due to the memory management and a garbage collector. If I recall correctly he said "only…

Reading your message brought flashbacks of 2006, when C and C++ programmers were politely but passionately explaining to Java programmers why the Java ecosystem was a hopeless pile of bloat. I would have thought that in 2022 the failure of Java to conquer any kind of market on the most popular platforms and 2nd most popular or any kind of popular plus the rise of languages like Swift, Go or Rust would have made that…

I don’t know, other than not having the same hype as “back then”, Java does better than ever. It may not have stuck its original target, but it is bigger than anything has ever been on the server side, with all Fortune 500 companies having heavy investment in the platform.

Re: Don’t call it a comeback: Java is still champ

#514

Post by pkolaczk » Wed, Aug 10, 2022, 3:53 PM UTC

kaba0 wrote: post #499

pkolaczk wrote: post #471

Earlier quoted context omitted.

That's a common wisdom, but there is little if any evidence to support it. True GC costs are simply more hidden and harder to measure. A malloc/free pair might be slightly slower than Java's new (not by much really - go measure), but invoking `new` is not the only cost of GC. https://arxiv.org/abs/2112.07880 Also modern low pause GCs have way higher CPU overhead than the old STW ones. Try to set a low pause GC pause…

Your point on low-latency GCs is indeed fair (read barriers vs write barriers), and I should have probably specified ref counting where the overhead is much more apparent (and is a fairer comparison). But regarding malloc-only, fragmentation also comes into picture which does have a non-negligable effect. And while Java does like to “heap”-allocate, it happens foremost on thread-local buffers and are used pretty much…

> And while Java does like to “heap”-allocate, it happens foremost on thread-local buffers and are used pretty much as an arena allocator. Even without escape analysis, these are very cheap all around.

If that was true, it would be fairly easy for Java to come close to C++, C, Rust, Pascal in the "binary trees" microbenchmark in The Computer Language Benchmarks Game. This microbenchmark is the one that stresses dynamic heap allocation, and is traditionally favoring bump-allocation, so compacting GCs should have an easy win, shouldn't they?

The problem is: the best Java implementation loses this benchmark by far on the CPU part (~2.5x worse) and terribly on the memory part (~20x worse) when using the default stop-the-world GC.

I attempted to run this benchmark using ZGC with OpenJDK 17, and here are the run times depending on the heap size:

    250 MB: OOM
    300 MB: 27.3 s
    500 MB: 12.4 s
    750 MB: 8.4 s
    1G: 7.8 s
    2G: 5.1 s
    16G: 5.6 s

For comparison, the best Rust program on the same computer runs in 0.8 seconds and takes about 150-280 MB of RAM (max RSS, varies from run to run).

And the C version #5 that uses malloc (no arenas) is still about the same speed as Java at 2G: 5.4 seconds.

Re: Don’t call it a comeback: Java is still champ

#515

Post by kaba0 » Wed, Aug 10, 2022, 3:54 PM UTC

javcasas wrote: post #440

gavinray wrote: post #348

Earlier quoted context omitted.

How is this not pattern matching? In Scala, I would write: enum Expr: case INT(value: Int) case ADD(left: Expr, right: Expr) case MULT(left, Expr, right: Expr) def eval(e: Expr): Int = e match case INT(value) => value case ADD(l, r) => eval(l) + eval(r) case MULT(l, r) => eval(l) + eval(r) This "match" syntax is the example given in the Scala docs for Pattern Matching: https://docs.scala-lang.org/tour/pattern-matchin…

Can you pattern match deeply? Can you make a case for ADD where the first param is a MULT with the second param of the MULT being INT(5)?

It is underway (destructors are not yet finalized).

Re: Don’t call it a comeback: Java is still champ

#516

Post by kaba0 » Wed, Aug 10, 2022, 3:55 PM UTC

dunefox wrote: post #489

gavinray wrote: post #348

Earlier quoted context omitted.

How is this not pattern matching? In Scala, I would write: enum Expr: case INT(value: Int) case ADD(left: Expr, right: Expr) case MULT(left, Expr, right: Expr) def eval(e: Expr): Int = e match case INT(value) => value case ADD(l, r) => eval(l) + eval(r) case MULT(l, r) => eval(l) + eval(r) This "match" syntax is the example given in the Scala docs for Pattern Matching: https://docs.scala-lang.org/tour/pattern-matchin…

Does it support matching patterns in data structures? f [ [1, _]. [3, _] ] = ... f [ [], [10, 20] ] = ...

Given that java doesn’t have too much syntax sugar for data structures, I doubt this will come, but other kinds of destructors will be possible.

Re: Don’t call it a comeback: Java is still champ

#517

Post by pkolaczk » Wed, Aug 10, 2022, 4:17 PM UTC

kaba0 wrote: post #477

pkolaczk wrote: post #470

Earlier quoted context omitted.

Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. There are dozens of other languages which are memory safe and some of them offer stronger guarantees than Java. Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the…

But even race conditions are well-defined in Java: you can’t get so called out-of-thin-air values. Some updates may not be visible from another thread, and of course dead/live locks are on the table (but they are everywhere, even the actor model doesn’t solve those).

> you can’t get so called out-of-thin-air values

You can't get out-of-thin-air primitive values (no word tearing).

But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do:

    a = 0;
    b = 0;
    a = 1;
    b = 1;

and another thread that does:

   print(b)
   print(a)

may observe 4 different combinations of values, surprisingly including also this one: { a = 0, b = 1 }

Why a corruption at a structure level should be considered less serious than tearing at a word level?

Re: Don’t call it a comeback: Java is still champ

#518

Post by vasili111 » Wed, Aug 10, 2022, 4:35 PM UTC

mark_l_watson wrote: post #324

Sun Microsystems had a link to my blog on the Java home page for about a year. I had attended the first Java World Tour, blogged about it, and for 15 years I was the first “hit” searching for “Java consultant”. Thank you Java. All that said, I don’t use Java much anymore, preferring to use Clojure when I need the rich JVM ecosystem. I do follow new Java language features and usually try them.

What you think about Scala? How you tried it?

Re: Don’t call it a comeback: Java is still champ

#519

Post by vasili111 » Wed, Aug 10, 2022, 4:36 PM UTC

dopamean wrote: post #67

I spent almost all of my career writing Ruby before I ended up at a company that required me to write mostly Kotlin (a bit of scala here and there too). After a few years of Kotlin I don't want to use anything else. There's a bit more ceremony to getting things set up but the experience of writing Kotlin with Intellij IDEA has been so wonderful I'm happy to keep doing it.

What you can say about Scala?

Re: Don’t call it a comeback: Java is still champ

#520

Post by nick__m » Wed, Aug 10, 2022, 5:09 PM UTC

cutler wrote: post #508

mesarvagya wrote: post #466

Earlier quoted context omitted.

Code like this is expected in Spring https://hastebin.com/jevibugiqu.less . Literally all the classes I see are filled with annotations. Can we even write code in pure java without a single annotation ? Theres a lot of magic going on with annotation. It works great while it is running. God forbid there is some issue and we have to figure it out where all the magic is happening.

It was the @Query annotation which finally killed Spring for me. So I have to stuff all my SQL into an annotation now if I want raw JDBC? Madness. **ck that.

Nothing in Spring-boot force Hibernate upon you. I stated that I used to use mybatis, a resultset mapper... it's a lot closer to JDBC and if you really need raw JDBC, have a datasource injected where it's needed.