Skip to content

Comment on Apache Kafka 0.8.0 releasedparent

Comments

Java is pretty high performance, usually on par with C++, and usually faster than e.g. Go.

Writing Java code so that there are no perceivable GC pauses is an art, but it is not impossible to achieve.

JVM might require more RAM upfront, but a well-written program is usually reasonably memory-efficient, too, so the consumed memory grows reasonably slowly with the problem size.

Writing things in pure C is often just too time-consuming.

> Java is pretty high performance, usually on par with C++

I'm not convinced. Java I/O is far form perfect, and Kafka is probably very heavy on I/O side.

> and usually faster than e.g. Go.

That's strange, since Go to some degree was intended as replacement for Java without having Java's downsides. Why would Go be less performant?

I'd be interested if someone would write such framework in Rust though. C++ is of course a default expectation, but usage of Java somehow surprises me in this case.

Java I/O is far form perfect

The API certainly isn't perfect, but what do you find lacking about the performance of Java I/O?

http://docs.oracle.com/javase/7/docs/api/java/nio/channels/p...

Kahka is written in Scala, not Java. The only Java in the project is for a JavaAPI and hadoop connectors.

Comparing languages in absolute performance terms is bad idea, it's an extreme simplification of what really goes into creating performant applications.

> Kahka is written in Scala, not Java.

Thanks for the correction.

Why are you so deadset on assuming that Java is slow? That's an incredibly misinformed and narrow view of what's possible on the JVM.

I didn't say it's just "slow". I said it's an expected performance hit in comparison with languages like C++. In some cases that hit is tolerable, in others not.

Right, but even what you said isn't really within shouting distance of reality.

Certainly, many naive people would expect such a performance hit; personally, I'd strongly expect that the actual performance is predicated on the architecture and the expertise of the teams involved and that any differences between the languages become either apples to oranges or noise.

I'd expect an actual performance comparison to be sure, rather than relying on expertise of the teams for assuming it. As much as any claim that difference between languages becomes irrelevant with advancement of the hardware, it still can be relevant in different cases.

Definitely, definitely not true. Go is extremely fast, it has its strengths in some areas and trade offs in other areas. If you want a good comparison to Apache Kafka, you should look at Apcera's NATS server, a publish-subscribe and distributed queueing messaging system written in Go by Derek Collison: https://github.com/apcera/gnatsd

You should never discredit a language, especially with blanket terms such as "its faster than Go". In what respects and in what areas? Here's a blog post which performs benchmarks on Go and Scala: http://eng.42go.com/scala-vs-go-tcp-benchmark/

They found Go to perform better than scala, however it had a high footprint. Every language has its tradeoffs, Java and Go are no exception.

Your link says the opposite of what you posted. From the article: "To our surprise, Scala did quite a bit better than Go, with an average round trip time of ~1.6 microseconds (0.0016 milliseconds) vs. Go’s ~11 microseconds (0.011 milliseconds).", and "Notable in the opposite direction was that the Go server had a memory footprint of only about 10 MB vs. Scala’s nearly 200 MB."

I have no idea where people got the idea that Go was faster than Java, or that Java/JVM is slow in 2013. Not trying to discredit Go (its my language of choice), but to say it surpassed Java while only being around for almost 5 years is disingenuous.

nemothekid,

You're absolutely right, my apologizes, its been a while since i read that article. Thank you for the correction! Much appreciated.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.