Hacker News Reader

Comment by adrianN | Hacker News Reader

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

View on HN

> if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast

Context is pretty important to the original comment:

> python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

they're not looking for a fast language in isolation, they're looking for a fast language in the broader context of their existing technological stacks. Java doesn't help that much when you're looking into ways to speed up your Ruby application, at least not easily.

Furthermore, Java has the issues that it's only fast when memory is plentiful and it has a long startup/running time, it's "eventually fast" if you will.

Java's FFI story is not as good as rust's though. So if you're interacting with the OS / native libs a lot then it might not be a good choice.

Although there's JNR and JNA and it might become a standard feature at some point in the future[0]. But for a good FFI experience you also need arrays-of-structs, which means you need value types in java. So it's a long journey to get there.

[0] http://openjdk.java.net/jeps/191

>It's plenty fast

Unless you need guarantees that can't be offered by garbage collection.

Java is pretty popular for HFT applications. I think most programs are less latency sensitive than that. But of course, Java is not for you if you have hard real time constraints.

There's a commercial pauseless GC offering for java. It's pretty much aimed at HFT applications.

https://www.azul.com/resources/success-stories/

In some cases those HFT installations are tuned not to run full Java GC within 8 hours during the trading day. Then they are rebooted.

That sounds interesting - have you got any more details on exactly how they set this up?

You can also use the Java Unsafe class to squeeze performance (every last bit) by recycling objects. I'm sad to say that I've had to do that at least once to make some vector math work.

Edit: Check out https://dzone.com/articles/understanding-sunmiscunsafe

A person on a conference has not mentioned details. The reason for Java is productivity and access to a bigger pool of developers.

> I think most programs are less latency sensitive than that.

Hardly, compared to anything that takes user input and aims at 60/120 FPS (where you inevitably end up bypassing GC if you can't force it to run when you want to).

https://www.quora.com/Is-Java-overtaking-C++-in-the-HFT-worl...

> One thing about HFT is that the speed of the language oddly doesn't matter much. You are talking about latencies of 20 milliseconds, and any language can do 20 milliseconds since CPU times are measured in nano-seconds rather than milisecond.

and

> If you are playing in the sub 10 microsecond range doing everything in C++ helps a lot. [..] A lot of high frequency strategies run in the 20-30 microsecond time frame. I think this is where a lot of diversity in terms of setup occurs.

and

> To lower execution costs, we need a low latency system that has good determinism in response times. You cant pause for hash table rebucketing or garbage collectors or the OS taking away your time slice or moving you to a diferent processor or whatever. There are guys who try this in Java, and spend most of their time trying to make Java work deterministically. Good luck

and

> If you are in ultra HFT then C++ is the only answer (besides custom hardware - FPGA & ASIC). You just can't afford garbage collector.

Java has not so great reputation about safety.

Java's bad safety reputation comes mostly from the Java plugin, where many inventive ways to bypass its sandbox have been discovered. When used as a normal programming language, without depending on it for sandboxing (that is, when all code running in the JVM is trusted), its safety is quite good.

(Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes to start up, while keeping the Netscape browser UI locked up.)

... and just to add to that, if you look at the other popular sandboxed client-side runtimes, i.e., Adobe Flash and various JavaScript-enabled browsers (all of them implemented in C++), you will find a similar number of critical vulnerabilities.

I see a lot of NPE in IntelliJ IDEA, especially EAPs. It's not browser's plugin.

NPEs are not a security issue in the same sense as a buffer overflow or null pointer dereference.

That's interesting because it is based on the same principles of not letting developers do harmful thing as a way to guarantee security.

Rust uses RAII for memory-safety, not just language constructions to raise some limitations.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

No sum types (the Java alternative to Rust enums is the horribly verbose visitor pattern, so a lot of the time people don't bother). null. A verbose and unabstractable "checked exception" system (that the standard library uses poorly in places) that leaves many users resorting to unchecked exceptions (panics) instead. Uninitialized field problems because methods are virtual even when called from superclass constructors. Excessive overhead to custom types that leads to using weakly typed Strings etc. rather than domain types. Poor abstraction facilities that lead to a culture of "magic" annotations and runtime reflection (or worse, proxies and bytecode manipulation) e.g. @Transactional, @Inject.

Java is safer than C, but it's a long way behind a modern functional language like Rust.

Well, I don't know about java's reputation, but there's this:

http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...

http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.

As a safe language from race conditions or memory leaks?

The Java VM is written in C though.

There are many java vms

The most popular(hotspot/openjdk) is written in c++/assembly

GC is not about safety at all, sorry. I'm not going to start flamewar, but just to answer your question: https://www.google.com/#newwindow=1&q=null+pointer+exception

You can't say NPEs are an example that Java is unsafe. The propegation is Nulls isn't Java's fault and Java's evolving currently to make use of Optionals as we speak to attempt to avoid this.

I can say it.

Reply on news.ycombinator.com