Hacker News Reader

Comment by userbinator | Hacker News Reader

That reminds me of all the "Java is not slow" articles that came out back when Java was more popular.

If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles.

Because people equate startup time with speed? Seriously, Java was never slow compared to the things that I actually saw people comparing it to. I've seen people pick Javascript over Java, because of performance and it just made no sense. Notably that incident was over 10 years ago, when JS was actually pretty slow relative to today.

I can't think of a time when Python, PHP, Perl, or Ruby were faster than Java and yet I saw people acting as if they were.

I don't know whether modern Java is slow or fast compared to other languages since it tends to be fast enough for many applications these days. Yet Java earned a reputation for being slow in the early days, may that be due to the startup time of the JVM when Java applets were embedded into web pages or the lacklustre performance of overly ambitious applications built upon a (then) immature platform. Even though those issues were dealt with in one form or another (e.g. applets dying off as well as the development and improvement of the JIT compiler), the reputation has been hard to shake. I suspect that much of that is due to a "fool me once, shame on me; fool me twice, shame on you" type of attitude. In other words, people haven't bothered to see if it has improved since early Java did not live up to the early hype.

Probably because C doesn't have a garbage collector or interpreter. And despite all the evidence suggesting that bytecode interpreters on top of JIT compilers with generational GC is plenty fast enough for a huge number of applications, with additional benefits like memory safety and lower development time, devs are still convinced that big == bad and slow.

Maybe. Probably not as bad and slow as you think it is. .NET and Java really don't have the performance overhead that everyone thinks they do, but a corollary of that is C and C++ aren't as fast as you think they are. All that GC tuning you see on JVMs is the same work you do converting to data oriented code in your favorite systems language, you're just fighting the memory wall. While GC's can do it smarter than a human can, they just can't do it for free.

> If it really wasn't slow, why would they have to defend it? We don't see "C is not slow" articles.

Because there’s a justifiable concern from some about a bytecode system being slower than raw machine code. After all, bytecode requires, at a minimum, interpretation to run. And with JIT systems, there’s still a cost associated with it.

You don’t see “C is not slow” because no one is arguing that it is.[a] There’s nothing faster than machine code[b].

[a]: Maybe back in the day when assembly was still king? If the internet was as prevalent 20 years ago as it is now, I’m sure you’d’ve seen articles arguing “C is not slow” compared to assembly.

[b]: Ignoring optimizations. Machine code is as close to the processor you can get.

You would see USENET posts back in the 90s about C/C++ vs ASM basically arguing that C/C++ was better than ASM because hand tuning ASM wasn't worth the man-months of effort required to extract the small amount of additional performance. It's basically the same argument, writing in a higher level language provides more benefit than the performance losses that aren't really that big to begin with.

Your argument is basically myths and misconceptions don't exist, which seems pretty weak.

One reason is that Java GUI applications were noticeable and annoyingly slow to run, compared to native Windows applications.

Reply on news.ycombinator.com