5 ms·

Do any of them have comprehensive standard libraries, and compile to small native binaries? Those features, along with performance and support for parallelism,

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

by pansa2 7y ago

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.