[azth]

That statement is misleading. You can also compile Java natively. Secondly, there is most definitely a runtime "between the metal and the language" in golang, the GC being the most obvious.

This proves my thoughts that these claims are not valid.

[nemothekid]

>You can also compile Java natively.

This is also misleading. You are implying that GraalVM isn't relatively new and that Java native compilation isn't rare. I've yet to see anyone deploy service or CLI tools that are natively compiled in Java. That statement is about as true as saying you can compile Python natively. Just because its possible doesn't mean the language is actually suited for it.

[azth]

I never said it was rare or not. It is possible if you truly need fast startup times. The fact of the matter, the JVM is good enough for the vast majority of the use cases, and is faster than golang so no need to even go there.

[anthk]

>, and is faster than golang

Nice joke. Go software runs much snappier and faster than any Java GUI or CLI tool.

[azth]

Not a joke. Large real world programs are proof (otherwise, my employer will not be spending millions of dollars on reinventing performance and other toolings already present in the JVM). What golang gui programs are you comparing against?

Java CLI tools compiled with GraalVM start up just as fast.

[pjmlp]

You weren't looking into the right plaaces, ExcelsiorJET, PTC, Aicas, Websphere Real Time, Android since version 5 (althought the story here is complicated).

[Cupprum]

>That statement is about as true as saying you can compile Python natively.

Python is actually compiled. When you run a file, it firstly compiles the cod into a bytecode, which is saved in ‘.pyc’ files. These are afterwards interpreted by the interpreter.

[anthk]

So does TCL, and yet Go outperforms TCL/TK, even 8.6.

[anthk]

Call me when I can compile some static binary for Windows from OpenBSD such as GOOS=Windows GOARCH=arch32 go build foo.go.