Live data from Hacker News

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

github.com

171–180 of 557 posts

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

#171
post #19
post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

I don’t know, probably some truck would be a better analog. It ain’t sexy, but it was made to be a blue collar language, and it is the one that ships cargo nigh everywhere.

You're not alone as someone else made a similar observation in a previous thread[1]:

> To me Java is like a garbage truck. You get to work, start it up, do a nearly invisible but absolutely essential duty, then, at the end of the day, you turn it off and go home. No one dreams about garbage trucks or puts one in a car show but they’re there and ready to go right back to work when you are.

[1] https://news.ycombinator.com/item?id=26834177

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

#172
post #97

Earlier quoted context omitted.

With Loom incoming, Go's only unfair advantage (shared with Erlang) may be gone soon. I guess we'll have the answer in a few years. Will the next WhatsApp be written in Java?

It will take more than green threads to be equivalent to Erlang. Erlang's concurrency model depends upon a completely non-shared memory model, which Java will never have. Edit: and programming it in Java will always be more laborious than in Erlang. Sure, you could put Erlang on the JVM (as the Loom folks want to do) but then is Java really the winner here, or did Oracle just make an alternative BEAM?

Surely having a shared memory model increases the design space? Or is this about memory management performance?

A benchmark should settle things in that case. Maybe it will be a draw! Erlang's almost-no-op deallocation vs Java's world-class JIT. Some applications are bound to be better suited to one specific side. I guess we'll see; but it cannot be denied that with Loom Java started to compete on a non-void part of Erlang's land.

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

#173
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…

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

All that said, Erlang is a very sharp knife, built for one specific purpose. This is just not true:

"a much better concurrency model"

If your program is CPU-bound, where real threads are king, then Erlang is a pretty poor solution. Because you cannot have real threads in Erlang, even if you wanted to. Number crunching or string processing are not its forte.

Also, most enterprise software does not really benefit from green threads anyway, because the scale they are running on easily handles blocking JDBC and http request calls. Not all companies are google or want to run a telephone switch that handles >million concurrent calls...

And finally, if you go Erlang, you get actors, whether you like them or not. You cannot have CSPs, for example, which in many ways are superior to actors. You don't get to choose your concurrency model, it is chosen for you. If your use-case suits this model, great. If not... not so much.

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

#174
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…

Comparing Java with C is about as strawman-ny as it gets, you're literally picking on one of the oldest and dumbest languages in production usage. "The PDP-7 assembler that thinks itself a programming language", in the hilarious words of one wise guy.

The problem Java experiences (not 'experienced') is that it isn't the 1990s anymore. People aren't easily hyped, not smart people at least. Programming language research, already way ahead of Java in 1995, moved far ahead some more. The internet and open source and free online education and social media means smart language designer(s) can now begin a baby project and put it on github and wait their luck for a corporation or organization that will support it, and they can wait a decade+ on hobby mode till the luck comes. Java's competition isn't C, I highly doubt it ever was, it's dozens of far superior programming languages that were born after 1995, and some of those that were born before but weren't very populer because internet and open source barely existed in the 1990s and they weren't made by a corporation.

Even if you keep overfitting the requirements function time and time again to gradually approach java (by adding "vast libraries" and "performance" to it, although neither of those things are specific to Java), you will eventually reach a very narrow niche with Java and Kotlin squarely in the middle, I know which one I'm going to choose if I'm willing to maintain my sanity and not drown in 'paper-work programming' that is the developing experience with Java. It's as easy as opening a source file in an IDE and naming it with a '.kt' extension rather than '.java', I'm in love with it.

Companies use Java extensively ? So it's a COBOL then: Old, everywhere, infrastructure-critical, but an utter failure as a programming language in every way that is not "runs my old program I'm too afraid to re-write". This is forgivable in the case of COBOL because it's a literal proto-language, one of the earliest of the species. It's not forgivable in the case of a language designed when Smalltalk and ML and Haskell were around.

The history of Java is the story of a corporation stumbling upon the idea of a VM (1960s stuff) and deciding that it's so good that they need something like this under their name right now, and not giving the slightest shit about the design of the language that sits on top of said VM. And they were right, the idea of a VM is really so fucking good that Java's aweful design was tolerated, until somebody relized running on the JVM no more means writing Java than running on x86 means writing x86 assembly, and wrote the first non-Java JVM language. And because VMs are so fucking beautiful, you get all Java code for free.

>doesn't copy everything Java does VM + GC

Come on, write those 2 words on any half-decent academic research repository and you will get hits from the fucking 1960s. Java is younger than Lisp, Smalltalk, Self, Haskell, Python and the same age as Ruby. All of those languages do VMs and GCs. Java's hotspot is taken from Self, that's documented stuff. And "Copying" isn't copying if it's a better implementation of the interface, JSON didn't "copy" XML, they reimplemented its interface better.

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

#175
post #45

Earlier quoted context omitted.

Personal rant: I've never understood the hate towards XML. It's a practical and flexible markup language that does not depend on whitespace or quoting every bloody thing. Plus, every markup language invented since has had to re-invent XML things that, surprise surprise were actually needed. Paths, schemas, comments, etc. I get frustrated with JSON because of things I could do in XML that I can't do in JSON without br…

I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.

A schema can be written in 15-30 mins to make XML as opinionated as you want it to be.

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

#176
post #5

Java's adequate. It's like a Toyota Corolla (insert your boring car of choice here if you don't feel this one works for the analogy). Not the prettiest, not the fastest, not the most efficient. But it gets you from point A to point B with little fuss or muss. I totally get why companies adopt and standardize on it. Do I use it for personal projects? Nope. Because it's not fun to "drive". For that, I pick the equivale…

Whoever invented the car analogy should pay for what they did.

I remember an intermediate OO class in Java 20 years ago... the existence of the El Camino was proof of the terribleness of both multiple inheritance and car analogies.

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

#177
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…

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

One of the weird things about Java is that there's a big low-latency/high-performance Java community around that stems from Island (now owned by NASDAQ) using Java as the platform/language for their matching engine. Then, talent flow from that team resulted in lots of proprietary trading shops using Java to low-latency trading/order execution.

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

#178
post #127
post #54

Earlier quoted context omitted.

Indeed. Shutoff Garbage collection completely and it can work. (And make sure your Java code creates no garbage - which is a new type of programming in and of itself)

Maybe I’m taking your comment wrong, why is this a bad thing? What other GC’d language just lets you turn it off?

I don't think their comment is intended to be negative really -- looks more like appreciative of the option, while cognizant of the fact that using it introduces a new challenge.

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

#179
post #62

The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle. This one, existing technology would make Java DX on par with the dynamic languages

> The biggest thing Java is missing is full hot swap The biggest thing missing in Java is an answer for the billion-dollar mistake. Real world Java is plagued by NPEs because a lot of Java is written by low caliber programmers. Java + functional error handling would be a monumental improvement.

It doesn't fully solve the problem, but @lombok.NonNull helps a lot. It makes it clear which properties shouldn't be null, and catches NPEs closer to the source. Incidentally, lombok in general does wonders for boilerplate reduction.

https://projectlombok.org/

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

#180
post #151

Earlier quoted context omitted.

Java is pretty fast. Second most popular language in HFT. Can get it to a few tens of micros. Not as fast as C++ at sub 5 micros. So good enough for many latency sensitive apps.

> Not as fast as C++ at sub 5 micros. Try sub 5 nanos. I was curious awhile ago at how fast C++ hash set lookup was compared to C#, and it consistently performed a lookup at 1 nanosecond. I tested with up to 6GB of data and then stopped because it was taking longer to generate random data then it was to run the benchmark 10,000 times. C++ benchmarks here[0]. It's a bit more complicated then just a pure lookup since I…

> and it consistently performed a lookup at 1 nanosecond.

TBH I'm skeptical that you are measuring what you think you are measuring. There are a lot of micro-benchmarking pitfalls, like dead code elimination, loop-invariant code motion, unrolling, and other issues. Unless you actually looked at the machine code coming out of the compiler, you're measuring something you don't understand. E.g. 1 nanosecond is roughly 3-6 instructions. That 100% means the hash lookup has been inlined into the benchmarking loop.

Are your hashtables mostly empty? Really small? Lots of easy hits (or easy misses)? Because the slow cases (actually looking up) are going to be hairier and may not be inlined.

Did you benchmark against Java's HashMap? Because it is also very, very, very fast for simple cases.

Post reply on HN