News for hackers. Stuff that matters.
Re:A year with Go by falcolas on Friday June 05, 2015 @09:06PM (#9669149)
> You deploy. You're done.

Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then...

Yeah.

Re:A year with Go by mavelikara on Friday June 05, 2015 @10:14PM (#9669327)
The ability to tune GC and availability of monitoring solutions are things I consider as big pluses for deploying on the JVM.

I would love to have a GC which tunes itself to accommodate the workload. On the JVM, G1 is a step in the right direction. How does Go's GC work in this regard - does it auto-tune itself?

Also, how are Go programs monitored in production? Are there tools like AppDynamics, NewRelic, JConsole or similar APM/telemetry solutions available to monitor Go applications?

Re:A year with Go by Skinney on Friday June 05, 2015 @09:48PM (#9669247)
Setting memory parameters and tweaking them would be similar to deciding what compilation flags to use when compiling your program. I also much prefer profiling over JMX than re-compiling the application with the profile flag activated and re-deploying.
Re:A year with Go by Alphasite_ on Friday June 05, 2015 @09:26PM (#9669193)
Yeah. But you don't have to, you're literally complaint that the user has options. It's not like Go doesn't have a GC either.
Re:A year with Go by threeseed on Saturday June 06, 2015 @12:04AM (#9669605)
And the biggest joke is that when you tweak the default settings you often end up making it worse.

The JVM has generally excellent performance with the defaults.

Re:A year with Go by nosequel on Friday June 05, 2015 @11:21PM (#9669499)
Exactly, and Go's GC is years behind the JVM.