4 ms·
From Java to Go, and never back, for Go programs use much less memory, warn-up much faster, need much less code lines to implement and compile much faster. Besi
by tapirl 8y ago
From Java to Go, and never back, for Go programs use much less memory, warn-up much faster, need much less code lines to implement and compile much faster. Beside happier developer experience, my App Engine apps also save much money by using Go.
- amzans 8y agoWhat do you mean by "warn-up much faster"? Go doesn't have a JIT compiler so not sure what you need to warm up?
- tapirl 8y agoThe time from a program starts to the program fully responses/works, a.k.a., the loading/prapare phase time.
- tomohawk 8y agoAgree - developed in Java for many years, and would never consider going back. Also agree on the resource use of Go vs Java. Having watched other Java devs make the switch, the big thing seems to be to stop over thinking things.
- abvdasker 8y agoProbably the number one thing I have always hated about Java is its build tools. Maven has never really made any sense to me and I simply don't want to have to deal with XML in 2018. Gradle requires me to use a totally different programming language just to write configuration. Ant is somehow more confusing than Maven but less standardized (and is almost useless without Ivy). It's been a few years since I wrote any Java so maybe there is something newer and better, but I just can't bring myself to go back to the misery of reading through that shit just to get a project to compile. With Go it feels like all you need is a dependency manager and maybe a Makefile for more complex builds.
- tapirl 8y agovgo is great, which will be released along with Go 1.11 soon. Go tools are not intended to be a full build system, so for more complex builds, Makefiles are still needed.
- vorg 8y ago> Gradle requires me to use a totally different programming language just to write configuration There's an alternative to using Apache Groovy for writing Gradle config scripts: https://blog.gradle.org/kotlin-meets-gradle https://blog.gradle.org/kotlin-meets-gradle . If you also use Kotlin instead of Java for your software on the JVM then you can stick to one language for everything.