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

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

github.com

Post reply on HN
Print view View original

401–410 of 557 posts

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

#401

Post by kaba0 »

the_only_law wrote: post #364
babypuncher wrote: post #183

Earlier quoted context omitted.

Benchmarks generally show C# outperforming Java, but not to a degree that most people would worry about. Performance-sensitive applications are still going to go for something native. One of C#'s biggest assets is Anders Hejlsberg of Turbo Pascal fame. He's been in charge of C# since its inception. He's done a very good job of keeping the language clean and concise, and generally ahead of Java when it comes to adopti…

> Performance-sensitive applications are still going to go for something native. What’s up with Java in HFT stuff then? I’ve never understood this: from what I understand in order for it to work, you have to intentionally avoid doing many allocations, and that seems like you’ll be throwing massive amounts of the ecosystem (Javas biggest strength) away.

They should not allocate on the hot path/after the initial set up, which is much more manageable. Old objects are not a problem for generational GCs.

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

#402

Post by titzer »

debug-desperado wrote: post #395
titzer wrote: post #379

Earlier quoted context omitted.

Sure. Reified generics, along the lines of C#[1], rather than Java, is the only sane design. Erasure of generics works fine in languages that have the "parametricity" property, where you cannot observe any characteristics of a polymorphic value. That doesn't hold as soon as you have casting. Java generics have a couple of unfixable problems. For one, you can have List and List both be passed to a place where Object i…

"Static generic types are lies" yes, and it doesn't matter that much. You got the safety at compile time and if you didn't do an unsafe cast then you preserved it. The issue with primitive types and boxing is certainly noted. Hopefully Valhalla will address it and more. The problem with reified generics is that the same variance model must be adopted by all guest languages on the runtime. Hence you basically don't se…

> The problem with reified generics is that the same variance model must be adopted by all guest languages on the runtime.

I think this is a fair observation, but it really boils down to "a dynamically typed compilation target is an easier target", which isn't all that surprising.

> such as Scala to port to the CLR

I am not as familiar with Scala's saga here, but I've heard multiple conflicting reports from Scala insiders, so I think this is a more complicated issue than just the generics model of the CLR.

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

#403

Post by titzer »

kaba0 wrote: post #400
titzer wrote: post #379

Earlier quoted context omitted.

Sure. Reified generics, along the lines of C#[1], rather than Java, is the only sane design. Erasure of generics works fine in languages that have the "parametricity" property, where you cannot observe any characteristics of a polymorphic value. That doesn't hold as soon as you have casting. Java generics have a couple of unfixable problems. For one, you can have List and List both be passed to a place where Object i…

Your first point is kind of making a big deal out of something that isn’t that big of a deal. The trivial solution is to just.. use the language’s static typing and don’t pass typed objects as Object. With a generic function nigh everything can be done type-safely (remember, if you don’t use class casts, your generic code will be completely type safe). Sure, there are some edge cases, but they are so edge-cases of an…

I mean, I agree. The static warnings will generally steer you away from the bad cases. From a source-language standpoint, if you don't consider the second-order effects of this design choice, it accomplished a fair fraction of the original goals. But more complex patterns I've seen people try to pass around java.lang.Class objects as a reification. That doesn't really work, because it's skin deep.

With significant experience with reified generics, there's just a lot of patterns that you can't do in Java. I wrote a whole PLDI paper about it back in 2013. Reified generics mean you can do stuff like ad-hoc polymorphism without direct language support. Ironically enough, the little trick of hiding type arguments with subtyping but getting them back with casts is a powerful dynamic tool.

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

#404

Post by kaba0 »

kelnos wrote: post #332
kentonv wrote: post #274

Earlier quoted context omitted.

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

> I once worked on a Java-based server at Google that had to answer requests with millisecond latency. That's... not really normal, though, and sounds like the exception that proves the rule. For the vast majority of applications, Java will perform better, be easier to develop, and be safer to run, than an equivalent server written in C or C++. At my previous job we used to run realtime audio through a Java server (R…

Finalizers are deprecated (though are still used of course in existing programs), so just a heads up: Cleaner API is the replacement

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

#405

Post by kaba0 »

pkolaczk wrote: post #231
the8472 wrote: post #207

Earlier quoted context omitted.

> - no global gc pauses, low-latency ZGC has sub-millisecond pauses https://malloc.se/blog/zgc-jdk16 And afaik azul's C4 collector has no global pauses, only per-thread pauses (which are also short)

Low pauses, low memory overhead, low CPU overhead. In Java world, pick one. In C/C++/Rust/Zig you can have all three at once.

Malloc and friends have much more CPU overhead than a modern GC, so if you do choose all of these, brace yourself to a really micromanaged programming.

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

#406

Post by delta_p_delta_x »

adgjlsfhk1 wrote: post #296
lenkite wrote: post #175

Earlier quoted context omitted.

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

and then you'll read an xml file that doesn't meet your schema and your code will crash

That's the point of the schema—use it to generate compliant serialisation/deserialisation code, and use that code to generate/read your schema-compliant XML.

No issues anywhere. There's only one point of failure here: bugs in the code generator.

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

#407

Post by kaba0 »

vbezhenar wrote: post #311
plandis wrote: post #118

Earlier quoted context omitted.

This is kind of hard to do in practice unless you’re really watching where you’re allocating memory. It’s very easy in Java to end up accidentally throwing a bunch of allocated memory on the heap without realizing it. Fwiw, the JVM now has a noop garbage collector so this is easy enough to benchmark.

Can you provide an examples of accidentally allocating memory? The only example I'm aware of is autoboxing which is huge misfeature IMO.

Any method call could allocate objects in their call trees, and it may not even behave consistently with new versions.

But it is easy to monitor with Java’s killer observability.

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

#408

Post by lenocinor »

vbezhenar wrote: post #311
plandis wrote: post #118

Earlier quoted context omitted.

This is kind of hard to do in practice unless you’re really watching where you’re allocating memory. It’s very easy in Java to end up accidentally throwing a bunch of allocated memory on the heap without realizing it. Fwiw, the JVM now has a noop garbage collector so this is easy enough to benchmark.

Can you provide an examples of accidentally allocating memory? The only example I'm aware of is autoboxing which is huge misfeature IMO.

Concatenating lots of Strings instead of using a StringBuffer will do the trick. Sure, people who are familiar with Java know not to do that. But I’ve seen plenty of production code that concatenates.

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

#409

Post by kaba0 »

pkolaczk wrote: post #318
mcculley wrote: post #277

Earlier quoted context omitted.

This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep goi…

I haven't said that the JVM would be corrupt by NPE. But C program state would also not be, and you could do the same handling as in Java. But if your code invoked an NPE or bounds check, then it means either the algorithm is incorrect or the data it processes are already corrupt by incorrect processing earlier. Continuing in such situation increases the risk, because you don't have any guarantees which parts of the…

Well, then consider deterministic failing a plus, as your C program may just continue along silently, with corrupted application state, and you might never learn of the problem (you are not likely to meet truly nullptr null pointers, they are just likely uninitialized, where all bets are off whether they are valid addresses)

Being able to handle it correctly is just an additional benefit.

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

#410

Post by hackerlight »

_gabe_ wrote: post #151
hackerlight wrote: post #71

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…

I'm talking about an end to end HFT system in C++.
Post reply on HN