To ground this last comment, every Java execution is a recompile in the sense that the JVM holds all the magic and applys it to a Java “binary” before and/or during execution.
The “write once run anywhere slogan” is at best a statement of “you code once and we’ll localize and concreteize for you at runtime.” This is little different in basic meaning than saying “run this source code zip of go code through the ‘go run’ VM and your code will run anywhere.” No, that’s not the Go intent, but it is correct as a thought experiment to show why Go-style internal implementation changes to support later GC changes are possible for interpreter languages, VM languages, and the “compiled” languages. They are all compiled languages, either statement by statement, in advance of distribution, at runtime all at once, or lazily on demand. The difference is packaging and marketing. On Sun, Oct 28, 2018 at 7:31 AM Robert Engels <reng...@ix.netcom.com> wrote: > To clarify, think of the performance improvements in the GC in Go from 1.1 > to 1.11. Amazing. But you only get these via recompiling which is a > barrier. Many java installations frequently get performance improvements > with no code changes or recompilation. This is why I’ve been investigating > packaging Go binaries with dynamic linkage to the runtime and stdlib. > > Sent from my iPhone > > > On Oct 28, 2018, at 9:23 AM, Robert Engels <reng...@ix.netcom.com> > wrote: > > > > Cool. Not sure why the JVM is not applicable to the discussion as it > normally ensures binary compatibility as languages evolve. > > > > Sent from my iPhone > > > >>> On Oct 28, 2018, at 9:16 AM, Gerald Henriksen <ghenr...@gmail.com> > wrote: > >>> > >>> On Sat, 27 Oct 2018 14:33:32 -0500, you wrote: > >>> > >>> What exactly are you referring to? I wasn’t aware of Android no longer > being Java. > >> > >> At Google I/O 2017 the Android team announced that Kotlin would be > >> supported as a first class language along with Java, including full > >> support in Android Studio. > >> > >> While Android will likely never get rid of its Java base, developers > >> have been switching to Kotlin due to the advantages it offers over > >> Java. Kotlin offers cleaner, easier to understand code without all > >> the verbosity that Java forces. > >> > >>> But also when I say java am referring to the JVM technology as well, > so add in all of the JVM languages and it’s even more lopsided. > >> > >> The JVM is not relevant to a discussion about languages. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
