3 ms·

Targeting the JVM seems like a trending practice nowadays. But I can't really see why it's so great. You'll need to install the JVM to your platform before you

by Depado 11y ago

Targeting the JVM seems like a trending practice nowadays. But I can't really see why it's so great. You'll need to install the JVM to your platform before you can execute anything. You'll also need to install it on your server to serve a web application. I don't know how that works but it sure adds some complexity to the deployment.

mike_hearn 11y ago
If by "install" you mean "unzip", sure. People like JVMs because they provide a lot of services that are really useful, such as: • State of the art garbage collectors, which you can tune for throughput or low pause times (there's a fundamental tradeoff here, there's no one-size-fits-all GC algorithm) • Visual debugging that always works, including remotely • Stack traces that always works • Advanced profiler and monitoring tools • Very robust and portable build systems • Extremely fast compiles (this is touted as an advantage of Go, but I never find myself waiting for a compiler when working with Java or Kotlin). • Giant standard library and even larger ecosystem of well designed and documented libraries to do many different tasks • Language interop - you can normally use libraries written in one JVM language from others. This obviously helps with the former point. • In some cases (e.g. actor frameworks and big web servers) code hotswapping and dynamic loading. The Go runtime lacks a good chunk of these useful features: the last time I worked with a Go shop they told me debugging hardly worked, because error handling was "propagate an error code" they never had stack traces in their logs for failures, profiling was primitive or not available at all depending on platform, the standard library was small (compared to the JDK), and language interop was "it can call C". Also the GC sucked, though I heard they have a better one now. But it's still a one-size-fits-all approach, which has well known problems.
- Zikes 11y ago
  It seems to me that the majority of those features are a result of Java being 20 years old. It's entirely possible Go could achieve or surpass those features by its 20th birthday.

by Depado 11y ago

mike_hearn 11y ago

If by "install" you mean "unzip", sure. People like JVMs because they provide a lot of services that are really useful, such as: • State of the art garbage collectors, which you can tune for throughput or low pause times (there's a fundamental tradeoff here, there's no one-size-fits-all GC algorithm) • Visual debugging that always works, including remotely • Stack traces that always works • Advanced profiler and monitoring tools • Very robust and portable build systems • Extremely fast compiles (this is touted as an advantage of Go, but I never find myself waiting for a compiler when working with Java or Kotlin). • Giant standard library and even larger ecosystem of well designed and documented libraries to do many different tasks • Language interop - you can normally use libraries written in one JVM language from others. This obviously helps with the former point. • In some cases (e.g. actor frameworks and big web servers) code hotswapping and dynamic loading. The Go runtime lacks a good chunk of these useful features: the last time I worked with a Go shop they told me debugging hardly worked, because error handling was "propagate an error code" they never had stack traces in their logs for failures, profiling was primitive or not available at all depending on platform, the standard library was small (compared to the JDK), and language interop was "it can call C". Also the GC sucked, though I heard they have a better one now. But it's still a one-size-fits-all approach, which has well known problems.

Zikes 11y ago
It seems to me that the majority of those features are a result of Java being 20 years old. It's entirely possible Go could achieve or surpass those features by its 20th birthday.