[pansa2]

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]

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.

[sacado2]

Small native binaries don't have to warm up when you start / restart a server.

[pjmlp]

Sure they do, they have to warm up the cache and OS data structures, whence why Windows has a pre-fetch service.

[grumpydba]

> 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]

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.

[pansa2]

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]

Because plenty of managed languages do support AOT compilation to native code, including Java.

[pjmlp]

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.

[noelwelsh]

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.