Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java is fast, code might not be

jvogel.me

Post reply on HN
Print view View original

221–230 of 259 posts

Re: Java is fast, code might not be

#221

Post by KronisLV »

this_user wrote: post #41
jandrewrogers wrote: post #28

You can write many of the bad examples in the article in any language. It is just far more common to see them in Java code than some other languages. Java is only fast-ish even on its best day. The more typical performance is much worse because the culture around the language usually doesn't consider performance or efficiency to be a priority. Historically it was even a bit hostile to it.

Performance is really not Java's issue. Even bad Java code is still substantially faster than the bulk of modern software that is based on technologies like Python or JavaScript/Node.js.

This might also be why I heard colleagues saying “Nono, listen, these ‘N+1 problems’ and our nested service calls aren’t an issue because it works well enough” until it eventually didn’t. I’d rather not have bad code in any language.

Modern Java runtimes are pretty good, though.

Re: Java is fast, code might not be

#222

Post by Shorel »

cogman10 wrote: post #107
Shorel wrote: post #104

Earlier quoted context omitted.

Because every single database vendor will try to lock down their users to their DBMS. Oracle is a prime example of this. Stored procedures are the place to put all business logic according to Oracle documentation. This caused backslash from escaping developers who then declared business logic should never be inside the database. To avoid vendor lock-in. There's no ideal solution, just tradeoffs.

> Because every single database vendor will try to lock down their users to their DBMS. I mean, that already happens. It's quite rare to see someone migrate from one database to another. Even if they stuck to pure SQL for everything, it's still a pretty daunting process as Postgres SQL and MSSQL won't be the same thing.

I migrated a database with some stored procedures from MSSQL Server to Oracle. Then lots of logic was added as stored procedures to the database. Then I migrated the same system to MySQL. Including the SP. Doesn't happen often, but it does happen.

Re: Java is fast, code might not be

#223

Post by gf000 »

array_key_first wrote: post #206
jandrewrogers wrote: post #28

You can write many of the bad examples in the article in any language. It is just far more common to see them in Java code than some other languages. Java is only fast-ish even on its best day. The more typical performance is much worse because the culture around the language usually doesn't consider performance or efficiency to be a priority. Historically it was even a bit hostile to it.

No - this is not entirely true. Many of Java's fundamental design decisions lead to unexpected slowness that just does not happen in other languages. For example, appending to a string in a loop. That only happens because of how Java handles strings. In C++, that's very fast. As fast as it can get, really. Since it all goes into the same buffer that gets mutated and expands at a good growth rate. Basically, equivalen…

> For example, appending to a string in a loop. That only happens because of how Java handles strings. In C++, that's very fast. As fast as it can get, really. Since it all goes into the same buffer that gets mutated and expands at a good growth rate

Well everything comes at a price. Just imagine how many billions of very hard to debug bugs did Java save the world from by going immutable on Strings, at the expense of some slow down when used without a though, and pretty much every java book starts with how to avoid it since decades?

Re: Java is fast, code might not be

#224

Post by gf000 »

spwa4 wrote: post #96

Java IS fast. The time between deciding to use Java and Oracle's lawyers breaking down your door is measured in just weeks these days.

Jokes are only funny when they have an ounce of truth to them.

Oracle was the one who open-sourced the whole of the JDK, and is the main contributor to OpenJDK by far, which is completely open-source with the same license as the Linux kernel. It's fine to criticize them on e.g. Oracle db licenses and stuff like that, but they have been excellent stewards of Java and all the bad language around this java lawyering stuff is just FUD.

Re: Java is fast, code might not be

#226

Post by gf000 »

ActorNightly wrote: post #113
jayd16 wrote: post #22

Earlier quoted context omitted.

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

Lets look at Java in modern day. * Most mature Java project has moved to Kotlin. * The standard build system uses gradle, which is either groovy or kotlin, which gets compiled to java which then compiles java. * Log4shell, amongst other vulnerabilities. * Super slow to adopt features like async execution * Standard repo usage is terrible. There is no point in using Java anymore. I don't agree that Rust is a replaceme…

> Most mature Java project has moved to Kotlin.

Demonstrably false, not even close

Re Gradle using groovy/kotlin: so what? Gradle is not a standard any more than Maven, and java is not primary used as a scripting language, so it makes sense that it has a different language for its config files? What's the deal here?

Show me a language without vulnerabilities.

It has virtual threads for quite some times and it is a much much better choice for most use cases than async.

Re: Java is fast, code might not be

#227

Post by spopejoy »

dionian wrote: post #32
jayd16 wrote: post #22

Earlier quoted context omitted.

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.

LOL I wish. LLMs massacre gradle code all the time. Once you're past boilerplate generation and doing anything remotely unusual they can't stop hallucinating broken shit that they insist works.

Re: Java is fast, code might not be

#228

Post by asternout »

bob1029 wrote: post #55
kyrra wrote: post #10

First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.

AOT is nice for startup time, but there are tradeoffs in the other direction for long tail performance issues in production. There are JITs that use dynamic profile guided optimization which can adjust the emitted binary at runtime to adapt to the real world workload. You do not need to have a profile ahead of time like with ordinary PGO. Java doesn't have this yet (afaik), but .NET does and it's a huge deal for thin…

Java definitely does have that, although maybe not in the most commonly used JDK distributions. E.g. companies needing ultra-low latency even before the first request, would use Azul JDKs like Prime (paid), pre-train the profile in non-production environments, and then use it in production on new version deployment.

Re: Java is fast, code might not be

#229

Post by pron »

Mawr wrote: post #201
pron wrote: post #151

Earlier quoted context omitted.

Well, JS is fast and Go is faster, but Java is C++-fast.

What a ridiculous claim. You're either deluded or outright lying.

No, just a 20+ year C++ and Java developer, while you clearly haven't used modern Java. Now, I admit that because I have a lot of experience in low-level programming, I am often able to beat Java's performance in C++, but not without a lot of effort. I can do better in Zig when arenas fit, but I wouldn't use it (or C++ for that matter) for a huge program that needs to be maintained by a large team over many years.

Re: Java is fast, code might not be

#230

Post by vbezhenar »

carlmr wrote: post #90
vbezhenar wrote: post #76

Earlier quoted context omitted.

Why should compiler optimize obviously dumb code? If developer wants to create billions of heap objects, compiler should respect him. Optimizing dumb code is what made C++ unbearable. When you write one code and compilers generates completely different code.

The problem is rather that Java doesn't have generics and structs, so you're kind of forced to box things or can't use collections.

No, in the example they provided, programmer wrote obviously stupid code. It has nothing to do with necessity:

    Long sum = 0L;
    for (Long value : values) {
        sum += value;
    }
I also want to highlight that there are plenty of collections utilizing primitive types. They're not generic but they do the job, so if you have a bottleneck, you can solve it.

That said, TBH I think that adding autoboxing to the language was an error. It makes bad code look too innocent. Without autoboxing, this code would look like a mess and probably would have been caught earlier.

Post reply on HN