Java is fast, code might not be • Hacker News Board

Re: Java is fast, code might not be

#231

Post by zelphirkalt » Sat, Mar 21, 2026, 4:06 PM UTC

rileymichael wrote: post #36

bombcar wrote: post #12

Earlier quoted context omitted.

Do none of the JVMs do that? GraalVM?

the best way is via CRaC ( https://docs.azul.com/crac/ ) but only a few vendors support it and there’s a bit of process to get it setup. in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node

But then we can complain about the long start time for each instance or JVM. It is choosing a different trade-off.

Re: Java is fast, code might not be

#232

Post by pseudocomposer » Sat, Mar 21, 2026, 4:21 PM UTC

liampulles wrote: post #21

Understanding algorithmic complexity (in particular, avoiding rework in loops), is useful in any language, and is sage advice. In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of inde…

I’d say both local data structures and algorithms atop them, and external services like DBs, etc., are both just “resources” in a more abstract sense. Optimizing performance is a matter of using the right resources for the right things. Algorithms help a lot when you’re building FE components (even if the server is rendering them, or “rendering” responses for the FE).

I’d also argue “micro-ORMs” like Diesel (which isn’t really much like ActiveRecord, Hibernate, etc., but more a very thin DSL/interface that maps SQL types to Rust types), combined with LLMs, are the ideal solution (assuming we still want humans to be able to easily understand and trust the code generated). And there’s a big argument to be made for schema migration management being done at the app level (with plain SQL for migrations).

All that said, at work, we use Rails. And ActiveRecord’s “includes/preload/eager_load” methods are fantastic solutions to 99% of cases of querying for things efficiently, and are far more clear than all the SQL you’d have to write to replicate them.

Re: Java is fast, code might not be

#233

Post by tombert » Sat, Mar 21, 2026, 5:01 PM UTC

drtse4 wrote: post #212

tombert wrote: post #178

I think that the `sychronized` keyword in Java was a mistake. I've seen classes that are meant to be used by multiple threads where literally every method has `synchronized` because "that was the only way they could get it to work". Of course, if literally every method is synchronized it literally can't actually be used by multiple threads, it just looks like it is. Generally speaking I work pretty hard to avoid any…

A huge mistake, I've seen a lot of code where clearly the author thought that just adding "synchronized" would have solved any concurrency issue. And no one even talks about how synchronized is implemented, basically a monitor on the object. The point of view is usually also wrong, they focus on the method call flow while they should think about protecting access to shared data.

Yeah. The more I learn about concurrency (which I think is a fair amount at this point), the more I respect Erlang. It was so ahead of its time with this stuff.

As I said, I feel like when I reach for a lock, about 95% of the time it’s because I don’t really understand the problem well enough.

Re: Java is fast, code might not be

#234

Post by piva00 » Sat, Mar 21, 2026, 5:05 PM UTC

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…

> Python, Node, and C/C++ extensions to those, you can do everything you need.

Or you can use Java and have libraries that cover almost anything provided in those languages, having access to a massive pool of labour when needed.

> * Log4shell, amongst other vulnerabilities.

As if no Python, JS, C/C++ libraries ever had vulnerabilities? That's a non-sequitur, every ecosystem has security issues, the most important aspect is how quickly they are fixed. Given Java's massive size, a lot of libraries see high usage, and are actively developed, so security patches are released quite quickly.

> * Standard repo usage is terrible.

What does this even mean? Standard library?

Java has its place, it's boring technology that gets things done, and let companies hire from a immense pool.

By the way, over 25 years of carreer I have professionally worked with Java, Scala, Kotlin, Clojure, Obj-C, Go, Python, Ruby, PHP, JS, even ASP 3.0, and some .NET (C# and F#). I'm not a Java purist but I call your arguments a bit bullshit, all of these languages have their places, strengths and weaknesses, the sooner you realise they are tools and if they are generally used perhaps there's something valuable about each of them, the sooner you stop wasting time trying to argue why "X sucks, use Y".

Use the best tool for the job, knowing more tools is never bad.

Re: Java is fast, code might not be

#235

Post by ghurtado » Sat, Mar 21, 2026, 5:24 PM UTC

kerblang wrote: post #182

ghurtado wrote: post #160

Earlier quoted context omitted.

> The languages used to describe and query them have to be different. Absolutely not. That which is asserted without evidence can be dismissed without evidence.

> Absolutely not. Can also be dismissed without evidence

Sounds like you're too thick to understand Hitchens quote.

Re: Java is fast, code might not be

#236

Post by ksec » Sat, Mar 21, 2026, 5:50 PM UTC

pjmlp wrote: post #43

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.

Excelsior JET, now gone, but only because GraalVM and OpenJ9 exist now. The folks on embedded get to play with PTC and Aicas. Android, even if not proper Java, has dex2oat.

There used to be GCJ as well. But that was at least 15 years ago.

Re: Java is fast, code might not be

#237

Post by rileymichael » Sat, Mar 21, 2026, 5:57 PM UTC

zelphirkalt wrote: post #231

rileymichael wrote: post #36

Earlier quoted context omitted.

the best way is via CRaC ( https://docs.azul.com/crac/ ) but only a few vendors support it and there’s a bit of process to get it setup. in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node

But then we can complain about the long start time for each instance or JVM. It is choosing a different trade-off.

start time generally isn't a huge concern for web applications (outside of serverless) since you've got the existing deployment serving traffic until its ready. if you're utilizing kubernetes, the time to create the new pods, do your typical blue-green promotion w/analysis tests etc. is already a decent chunk of time regardless of the underlying application. if you get through it in 90 seconds instead of 60, does that really matter?

Re: Java is fast, code might not be

#238

Post by array_key_first » Sat, Mar 21, 2026, 6:02 PM UTC

gf000 wrote: post #223

array_key_first wrote: post #206

Earlier quoted context omitted.

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…

Of course, I agree. My point is that it is a Java thing, not a computer thing. It was deliberated designed this way. Java has unique performance characteristics that don't apply to most other languages.

The same thing is true for C++. Value semantics have a cost. In C++, passing a string to a function is very expensive because it calls a copy constructor, so you have to remember to use a reference to avoid that. In Java, that's basically free because of reference semantics.

I also want to say that, while Java has immutable strings, that is a bit undone by the reference semantics of the language. C++ has mutable strings but value semantics, which means that passing a string to a function is safe. It won't be mutated, even though strings are mutable like most C++ containers. In Java, passing containers around is generally not safe, and you can't assume they won't be mutated.

Re: Java is fast, code might not be

#239

Post by cryptos » Sat, Mar 21, 2026, 6:40 PM UTC

computerdork wrote: post #188

EricRiese wrote: post #150

This is a Spring specific gripe and I know this blog post doesn't assume Spring, but I hate seeing `new ObjectMapper()`. Spring Boot auto configures an ObjectMapper for you and you probably want the customization it gives you, including `java.time` handling and classpath scanning. I've wrestled with so many bugs caused by not using the `ObjectMapper` bean.

Have always really liked Java, but yeah, Spring overall has been terrible for the language. Autowiring is against the principles of a typesafe programming language - Don't make me guess what what object is going to be attached to a reference. And if you do, at least figure out what linked object is at compile time, not at run time. Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be…

It is not like auto-wiring would turn Java magically into a dynamically typed language!

Re: Java is fast, code might not be

#240

Post by computerdork » Sat, Mar 21, 2026, 8:30 PM UTC

cryptos wrote: post #239

computerdork wrote: post #188

Earlier quoted context omitted.

Have always really liked Java, but yeah, Spring overall has been terrible for the language. Autowiring is against the principles of a typesafe programming language - Don't make me guess what what object is going to be attached to a reference. And if you do, at least figure out what linked object is at compile time, not at run time. Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be…

It is not like auto-wiring would turn Java magically into a dynamically typed language!

For me at least, being statically typed is overall a strength. Yeah, it's not that much work to include types when declaring vars, but the benefits are you don't have the problems with types in expressions that you do with dynamically typed languages (Javascript for example, which is one the reasons why Typescript was created).

... although, Java have does support some dynamic typing, as you now don't need to have the type when instantiating objects, using the "var" keyword and the compiler will infer the type from the object that is being set to it (although, this is just syntactic sugar).