4 ms·
> Go competes for mindshare [with those who] have lost patience with the high deployment costs of JVM based languages This is repeated so often, but I genuinel
by alexatkeplar 11y ago
> Go competes for mindshare [with those who] have lost patience with the high deployment costs of JVM based languages
This is repeated so often, but I genuinely don't understand the underlying point. At Snowplow we have to deploy Scala, Java, JRuby and Go, amongst other things.
Scala/Java: build a fatjar containing all dependencies using sbt-assembly, upload to Bintray and then deploy onto servers which have a recent JVM.
JRuby: build a fatjar containing all dependencies using warble, upload to Bintray and then deploy onto servers which have a recent JVM.
Go: build a binary containing all dependencies with godep for each relevant server architecture, upload to Bintray and then deploy onto servers.
Yes, Go doesn't need a JVM installed, but on the flipside I have to build a version for each relevant server architecture. And then there's the software where I have to export GOMAXPROCS=`nproc` in a wrapper script...
- threeseed 11y agoTalking about deployment is ridiculous to me with languages that in most cases are going to be long running server side applications. How often are you going to install JVM/Ruby/Python ? Once. How often are you going to deploy ? Thousands. So the important part is how well the overall process works e.g dependency management, build scripts, automation, tooling etc.
- kasey_junk 11y agoThat makes an assumption about deployment. It assumes that you only provision a server once and you deploy many times. There are operational models where the provisioning of the server themselves is the deployment step.
- commentzorro 11y agoThe JVM, CLR, Frameworks, Runtimes, app servers, configurations, etc. _ARE_ the problem. We're tired of all that crap all the time. Compile to an executable and xcopy the executable to an arbitrary server. Ideally, nothing to configure outside of the application itself. Go fits that bill nicely, but it's an annoyingly austere language. With all the languages in this last wave, I just don't know why nobody hit on a full featured Go level language yet. No memory management, not deployment dependencies, full of nice sugary high level abstractions, and cross platform Windows/Linux. Something solid and ready for production use, not an alpha or beta.
- alexatkeplar 11y ago> Compile [assemble] an executable and xcopy the executable to an arbitrary server [with a JVM]. Ideally, nothing to configure outside of the application itself. That is exactly what we do with Java, Scala, JRuby. Installing a JVM is 5 lines of bash; 1 line of Dockerfile. I don't understand the point you're making.
- kasey_junk 11y agoLet me start by saying I think the argument for binaries vs fat jars is overblown. That said there is more complexity with the jvm. Do you have the right jvm installed? Where was it installed? Are there multiple versions of the jvm installed? Do you care? Can you mess with it? Have you accepted the license for the jvm? Should I use docker to manage all this complexity? Is the docker agent working? etc. In environments where you are deploying to a single architecture that is more complex than "copy binary". In environments with LOTS of servers the (admittedly limited) complexity difference can add up.
- pjmlp 11y agoIT says everyone uses version X.
- kasey_junk 11y agoThis group IT, do they set up the servers? Do they make sure policy is enforced? Do they deploy your software? If so, they are doing the work and we should be asking them & not you whether they prefer JVM based solutions or single binary ones.
- pjmlp 11y agoMost of the companies I worked for, only IT has a say what devs have on their machines and servers. You need tickets for everything.
- commentzorro 11y ago
- NateDad 11y ago> I have to export GOMAXPROCS=`nproc` in a wrapper script... if os.Getenv("GOMAXPROCS") == "" { runtime.GOMAXPROCS(runtime.NumCPU()) } Is the above not sufficient?