Hacker News new | ask | show | jobs
by highfrequency 2315 days ago
Curious if there’s a reason Java/Kotlin wouldn’t have worked? There are a number of fast, statically typed languages with much less developer overhead than C++.
2 comments

Do any of them have comprehensive standard libraries, and compile to small native binaries? Those features, along with performance and support for parallelism, are why I chose Go (for command-line apps).
Small native binaries don't seem like much of an advantage when writing servers. For command-line apps sure, but it sounds like OP was addressing someone who was writing a server application.
Small native binaries don't have to warm up when you start / restart a server.
Sure they do, they have to warm up the cache and OS data structures, whence why Windows has a pre-fetch service.
> Small native binaries don't seem like much of an advantage when writing servers.

However when deploying server binaries it's a substancial advantage. End users like them. Ops like them.

End users happily chug along with 300MB Facebook Messenger on their phones.

On server I am deploying 250MB TensorFlow on a _free_ cloud tier.

Not sure what are you talking about.

I also bet Java or .NET would be speedier than Go after warmup.

The last time I gave these reasons for choosing Go, that post got downvoted as well. But, still no-one can suggest a more appropriate language to use.

I don’t even particularly like Go. It just seems to be the best solution for command-line apps in 2020.

Because plenty of managed languages do support AOT compilation to native code, including Java.
Yes, since around 2000's when willing to pay for third party SDKs.

Nowadays OpenJDK, OpenJ9 and GraalVM offer AOT for those that aren't willing to pay for such SDKs.

As for small, Go binaries aren't necessarily that small.

With GraalVM you can compile JVM languages to small executables with limited memory consumption. It's fairly new technology but people are using it in production.
Java can be as fast as Go if you are careful. Unfortunately idiomatic Java isn't terribly fast because of the pointer chasing behaviour in its collections. The only way to avoid the issue is to work primarily with arrays of basic numeric types. If you sort a large vector<Point3d> in C++ it will be an order of magnitude faster than sorting a similar looking ArrayList<Point3d> on Java because the C++ version stores and allocates these tiny objects in a contiguous memory block.
Java is also going to take a ton more memory.
Java doesn't need the trick to allocate useless GB to force the GC to behave, like Twich and others have reported about.

I also bet that Java value types will be available in the language earlier than any Go compiler with generics support.

https://jdk.java.net/valhalla/