The 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.

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

Let 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.

IT says everyone uses version X.

This 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.

Most of the companies I worked for, only IT has a say what devs have on their machines and servers. You need tickets for everything.

First off, make the assumption that you're not just running Linux. Half your deploys are to Windows. If you don't do Windows then you'll certainly have fewer problems.

Second, Docker may be the solution. In concept it's great. But Docker isn't yet a first class citizen in Windows. For the time being it becomes yet one more run-time piece that has to be configured.

Clearly my map of the world not your map of the world (à la Korzybski). I find the various extraneous run time pieces constantly tedious and annoying. You don't. Can't say why you don't, but I'm to the point where I despise them. I don't want another call where I have to tell a customer they have to update this piece or download that piece or move this there in order to get the latest version of an application to work.

Docker and other containers are a response to runtimes failing to, ahem, contain themselves. It is true that you don't need a second solution if you already have one, but some people may not like the container solution.

I don't know about your situation, but at our end, to start JBoss after a new deployment, it takes about 75 to 90 seconds. While for production it may be okay-ish, it absolutely drives the developers and testers nuts.

I think D fills that bill, and it has at least a tiny bit of Facebook backing.

In fact, IMHO it is a much better language than go, the only lacking stuff are millions of libraries.

You can compile to native code with Java as well. The OpenJDK isn't the only one, e.g. Excelsior JET.

If you prefer freebies Java 10 might have an AOT compiler as well.

Talking 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.

That 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.

> I have to export GOMAXPROCS=`nproc` in a wrapper script...

    if os.Getenv("GOMAXPROCS") == "" {
        runtime.GOMAXPROCS(runtime.NumCPU())
    }

Is the above not sufficient?