

Go for the JVM, written in Scala - DanielRibeiro
http://code.google.com/p/jgo/

======
mechanical_fish
And once again my brain fails to correctly parse the word _Go_ until it has
read the headline three times.

It must be some kind of world record: I have gotten exactly _two characters_
into this language and already I'm demoralized by its user experience. ;)

------
enneff
I'm interested to see they approach they'll take with Go's interfaces. When Go
was first being developed we considered targeting the JVM directly, but there
seemed to be no efficient way of implementing Go-style interfaces, or
"structural typing" (I think Scala uses runtime reflection to achieve this,
which is slow).

Here's an interesting article on shoe-horning structural typing into the JVM:
[http://www.draconianoverlord.com/2010/01/17/caller-side-
stru...](http://www.draconianoverlord.com/2010/01/17/caller-side-structural-
typing.html)

~~~
beza1e1
How is structural typing implemented efficiently?

~~~
enneff
[http://research.swtch.com/2009/12/go-data-structures-
interfa...](http://research.swtch.com/2009/12/go-data-structures-
interfaces.html)

~~~
beza1e1
Thanks for the link. Computing vtables during run time would have been my idea
as well. Sorting the vtable is a nice trick to reduce the complexity.

------
kennystone
Why someone would pick Go on the JVM over clojure/scala/jruby/java which are
already mature and offer a nice, diverse set features of their own already
(persistent data structures, actors, scripting, etc)?

~~~
omaranto
A Go programmer forced to use the JVM might.

------
seunosewa
Good luck! Can anyone explain how this might be useful, though?

~~~
chuhnk
To exploit the advantages of the JVM. Can you imagine letting the jvm handle
GC and JIT for you?

~~~
justincormack
Compiled Go is roughly the same performance as Java, so no I cant see a big
win here. Sure there is some work needed on Go optimisation and GC.

~~~
uriel
Also, there still plenty of low hanging fruit to optimize in Go, both in the
compilers and GC, so surpassing Java wont be hard.

And Go's memory usage is already magnitude orders better than Java.

~~~
lukesandberg
I think its somewhat naive to think that it won't be hard to surpass the JVM.
The JVM is a highly tuned piece of software especially when it comes to GC i
think it will probably take Go a while to surpass the JVM with respect to
that, similarly for compilation though it is a little apples to oranges due to
the JIT.

~~~
burgerbrain
A staticly typed language compiled to native code surpassing the JVM? That's
not naive, that is commonplace...

GC is the only sticky factor here.

~~~
lemming
No, it's not commonplace.

[http://shootout.alioth.debian.org/u32/which-programming-
lang...](http://shootout.alioth.debian.org/u32/which-programming-languages-
are-fastest.php)

Only 4 languages are faster than Java 6, two of which almost no-one uses. Java
generally loses on memory use, but not on performance these days.

~~~
burgerbrain
First off, I have personally seen, as justincormack describes, compiled Go as
it currently exists being roughly comparable to Java, as it currently exists.
I haven't burned much time looking around, but I was unable to find what
version of Go they were using, or even what compiler for it (there are two
major ones, with dramatic performance differences). Furthermore, it is a fact
that Go at it's current maturity does little real optimization. Regardless of
how "commonplace" languages beating Java may or may not be, Go should stand a
very solid chance of doing it, provided it continues to see love.

anyway,

Java also loses handily on startup times, and only wins in runtime speeds
against statically typed languages compiling to native code that lack the same
tier of backing. Notice that one of the languages that beats Java is C++,
possibly the single ugliest language in actual use. Practically a worse case
scenario for a language developer but I don't think there has ever been a
point in history which it doesn't cream Java. Hobbyist languages, which I
would classify most of the languages on that list as (well, the ones that are
even commonly compiled to native code in the first place...) will rarely
compete with mature enterprise backed languages, but when you weight by
funding, compiled languages clean house. Continued development of systems such
as LLVM which blur the distinction between the two will only serve to improve
the situation.

aside: I find their Fortran statistic suspect as well. In my professional
experience a well designed Fortran program will kick C's ass nearly every
time. At least in scientific computing applications anyway.

~~~
igouy
_> >I don't think there has ever been a point in history which it [C++]
doesn't cream Java<<_

Still waiting for that faster C++ fannkuch-redux program (and still waiting
for a C fannkuch-redux program that uses multi core).

[http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa...](http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all)

 _> >when you weight by funding<<_

Please show total $$$ amounts spent on the development of each programming
language over the last several decades - so we can weight by funding.

(Should funding for Plan 9 compilers be accounted as funding for Go? Should
funding for GCC compilers be accounted as funding for GCCGO?)

 _> >I find their Fortran statistic suspect as well ... At least in scientific
computing...<<_

When you don't look, you won't find -

[http://shootout.alioth.debian.org/u64q/performance.php?test=...](http://shootout.alioth.debian.org/u64q/performance.php?test=nbody)

[http://shootout.alioth.debian.org/u64q/performance.php?test=...](http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm)

~~~
justincormack
The fannkuch benchmark is one where Go beats Java, and has a hugely better
memory usage. But these benchmarks are highly suspect (they dropped LauJIT
recentl despite it being the fastest dynamic language).

C does not have a standard threading library, which is why there is no
benchmark.

Plan 9 did not have a lot of funding. Java did.

~~~
igouy
_> >beats Java, and has a hugely better memory usage<<_

Do you understand that's the default JVM memory allocation?

 _> >But these benchmarks are highly suspect...<<_

But "highly suspect" is just name calling.

 _> >C does not have a standard threading library, which is why there is no
benchmark.<<_

No it is isn't, here's a C program that uses pthread for multi-core

[http://shootout.alioth.debian.org/u64q/program.php?test=mand...](http://shootout.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=gcc&id=6)

~~~
burgerbrain
Pthreads is not part of _any_ of the C standards. Your credibility is sorely
hurting.

~~~
igouy
Thank you for your Red Herring.

1) Where did anyone say pthreads was part of the C standards?

2) As I said, "C does not have a standard threading library" is not the reason
why there's no C fannkuch-redux program that uses multi core.

~~~
burgerbrain
C does not have a standard threading library. Pthreads is a threading library
for C that happens to be standardized.

The difference between these two statements, while perhaps subtle, is quite
massive.

------
schiptsov
I love all those 'JVM roks!' or 'JVM is mature and stable!' stories. But I
still unable to get it, why one user-level program (say, java.exe) must be
better than any another user-level .exe? With its primitive and rudimentary
integration with an OS (remember, it was designed to be isolated environment
that runs everywhere, which means exactly opposition to efficiency and
optimization). Wait! It can produce native code and able to run threads! Yeah,
but LLVM produces much better code and there is clang++ with which we can
build java.exe from its sources... ^_^ May be it rocks just because too much
money was invested in the ecosystem and now they do everything possible to
keep it breathing? ^_^ Remember? Your lovely Xeon CPU is a VM itself. Your
lovely Virtualization stack on top of your OS is what? Do we still need so
many layers of VMs? ^_^ btw, MS DOS is also quite mature, stable and
production ready environment. Especially with something like qemm.exe and
desqview.exe (do you remember them?)

~~~
antrix
A best of breed garbage collector is a strong argument for the JVM.

------
aurelianito
Why isn't it written in Go and bootstrapped?

~~~
gaius
Well, some language communities consider it to be a point of pride to be self-
hosting (e.g. Java) but for others (e.g. Python) it's not a big deal.

~~~
adw
I believe RPython to be a proper subset of Python, and PyPy is written in
RPython.

You need to bootstrap off CPython to compile the compiler, of course!

------
Leimy
Interoperability with all the rich Java frameworks seems a win.

------
markokocic
Does it compile directly to bytecode or it needs some runtime library. Anyone
tried it on Android?

~~~
drivebyacct2
You know that not all VMs are the same right? The Dalvik VM is completely
different than the JVM.

~~~
markokocic
Sure, but pretty much any JVM language that compiles to bytecode can be
translated to run on Dalvik VM using standard Android tools. What I'm asking
for is it the result usable.

