4 ms·

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++.

pansa2 7y ago
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).
- petersellers 7y ago
  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.
  - grumpydba 7y ago
    > 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.
    - lostmsu 7y ago
      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.
  - sacado2 7y ago
    Small native binaries don't have to warm up when you start / restart a server.
    - pjmlp 7y ago
      Sure they do, they have to warm up the cache and OS data structures, whence why Windows has a pre-fetch service.
- pansa2 7y ago
  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.
  - pjmlp 7y ago
    Because plenty of managed languages do support AOT compilation to native code, including Java.
- noelwelsh 7y ago
  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.
- pjmlp 7y ago
  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.
abraxas 7y ago
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.
- LessDmesg 7y ago
  Java is also going to take a ton more memory.
  - pjmlp 7y ago
    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/ https://jdk.java.net/valhalla/

pansa2 7y ago

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).

petersellers 7y ago
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.
- grumpydba 7y ago
  > 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.
  - lostmsu 7y ago
    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.
- sacado2 7y ago
  Small native binaries don't have to warm up when you start / restart a server.
  - pjmlp 7y ago
    Sure they do, they have to warm up the cache and OS data structures, whence why Windows has a pre-fetch service.
pansa2 7y ago
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.
- pjmlp 7y ago
  Because plenty of managed languages do support AOT compilation to native code, including Java.
noelwelsh 7y ago
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.
pjmlp 7y ago
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.

abraxas 7y ago

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.

LessDmesg 7y ago
Java is also going to take a ton more memory.
- pjmlp 7y ago
  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/ https://jdk.java.net/valhalla/