6 ms·

Go for the JVM, written in Scala

71 points by DanielRibeiro 15y ago

seunosewa 15y ago
Good luck! Can anyone explain how this might be useful, though?
- chuhnk 15y ago
  To exploit the advantages of the JVM. Can you imagine letting the jvm handle GC and JIT for you?
  - uriel 15y ago
    Standard Go doesn't need JIT, it is all compiled to native code already.
  - justincormack 15y ago
    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 15y ago
      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 15y ago
        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 15y ago
        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 15y ago
        No, it's not commonplace. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... 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 15y ago
        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.
- discreteevent 15y ago
  Libraries. Provided it will give you the the ability to call into other jvm libraries it gives you huge leverage. Just like scala, jruby etc.
- dkarl 15y ago
  Sharing code between back-end servers running on the Java web stack and resource-constrained devices in the field. Not only for the purpose of running the same code at the same time, but also so you can easily port functionality back and forth between central servers and field devices. It reduces the cost of fixing design mistakes or just evolving your architecture.
  - chc 15y ago
    Also, Google happens to have a pretty important Java platform of its own on which it might like Go to run.
- deleted 15y ago
  [deleted]
aurelianito 15y ago
Why isn't it written in Go and bootstrapped?
- Someone 15y ago
  1. AFAIK, Go itself isnt self-hosting, either. 2. If I were to aim for a self-hosted go on the JVM, this could easily be one of the steps. Compile a 'Go written in Go' with this, and you are done (well, you would probably want to tune the runtime afterwards to get decent performance, but those are 'merely' details)
  - uriel 15y ago
    Yea, self-hosting is neat, but also makes bootstrapping much more complicated, specially when the language is still changing.
    - wickedchicken 15y ago
      > specially when the language is still changing. I think this is the biggest reason. Go has been stabilizing over the past few months but it definitely still is in development. Gofix helps with this but only so far...
- gaius 15y ago
  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 15y ago
    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!
  - uriel 15y ago
    This is another area where Go prefers pragmatism over everything else.
Leimy 15y ago
Interoperability with all the rich Java frameworks seems a win.
kennystone 15y ago
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 15y ago
  A Go programmer forced to use the JVM might.
mechanical_fish 15y ago
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. ;)
markokocic 15y ago
Does it compile directly to bytecode or it needs some runtime library. Anyone tried it on Android?
- drivebyacct2 15y ago
  You know that not all VMs are the same right? The Dalvik VM is completely different than the JVM.
  - markokocic 15y ago
    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.
enneff 15y ago
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-structural-typing.html http://www.draconianoverlord.com/2010/01/17/caller-side-stru...
- beza1e1 15y ago
  How is structural typing implemented efficiently?
  - enneff 15y ago
    http://research.swtch.com/2009/12/go-data-structures-interfaces.html http://research.swtch.com/2009/12/go-data-structures-interfa...
    - beza1e1 15y ago
      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.
schiptsov 15y ago
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 15y ago
  A best of breed garbage collector is a strong argument for the JVM.
  - deleted 15y ago
    [deleted]
- teyc 15y ago
  If I remember Cliff Click's [Azul] lecture "A JVM does what?" correctly, each machine whether JVM or x86 defines what is managed by the machine and what isn't. Just as x86 represents a machine which defines op codes only and leaves memory and process management to the operating system, the outcome of JVM's choices about taking responsibility for garbage collection, security, machine code generation is an interesting machine which can provide performance gains through time, just like Moore's law. I don't work with the JVM at all, so all I know I learnt from Cliff's lecture. The slides are here http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2011_WhatDoesJVMDo.pdf http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2... and video here: http://jeremymanson.blogspot.com/2011/04/cliff-click-in-jvm-does-what.html http://jeremymanson.blogspot.com/2011/04/cliff-click-in-jvm-...
- 15y ago

71 points by DanielRibeiro 15y ago

seunosewa 15y ago

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

chuhnk 15y ago
To exploit the advantages of the JVM. Can you imagine letting the jvm handle GC and JIT for you?
- uriel 15y ago
  Standard Go doesn't need JIT, it is all compiled to native code already.
- justincormack 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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 15y ago
        No, it's not commonplace. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... 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 15y ago
        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.
discreteevent 15y ago
Libraries. Provided it will give you the the ability to call into other jvm libraries it gives you huge leverage. Just like scala, jruby etc.
dkarl 15y ago
Sharing code between back-end servers running on the Java web stack and resource-constrained devices in the field. Not only for the purpose of running the same code at the same time, but also so you can easily port functionality back and forth between central servers and field devices. It reduces the cost of fixing design mistakes or just evolving your architecture.
- chc 15y ago
  Also, Google happens to have a pretty important Java platform of its own on which it might like Go to run.
deleted 15y ago
[deleted]

aurelianito 15y ago

Why isn't it written in Go and bootstrapped?

Someone 15y ago
1. AFAIK, Go itself isnt self-hosting, either. 2. If I were to aim for a self-hosted go on the JVM, this could easily be one of the steps. Compile a 'Go written in Go' with this, and you are done (well, you would probably want to tune the runtime afterwards to get decent performance, but those are 'merely' details)
- uriel 15y ago
  Yea, self-hosting is neat, but also makes bootstrapping much more complicated, specially when the language is still changing.
  - wickedchicken 15y ago
    > specially when the language is still changing. I think this is the biggest reason. Go has been stabilizing over the past few months but it definitely still is in development. Gofix helps with this but only so far...
gaius 15y ago
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 15y ago
  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!
- uriel 15y ago
  This is another area where Go prefers pragmatism over everything else.

Leimy 15y ago

Interoperability with all the rich Java frameworks seems a win.

kennystone 15y ago

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 15y ago
A Go programmer forced to use the JVM might.

mechanical_fish 15y ago

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

markokocic 15y ago

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

drivebyacct2 15y ago
You know that not all VMs are the same right? The Dalvik VM is completely different than the JVM.
- markokocic 15y ago
  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.

enneff 15y ago

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-structural-typing.html http://www.draconianoverlord.com/2010/01/17/caller-side-stru...

beza1e1 15y ago
How is structural typing implemented efficiently?
- enneff 15y ago
  http://research.swtch.com/2009/12/go-data-structures-interfaces.html http://research.swtch.com/2009/12/go-data-structures-interfa...
  - beza1e1 15y ago
    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.

schiptsov 15y ago

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 15y ago
A best of breed garbage collector is a strong argument for the JVM.
- deleted 15y ago
  [deleted]
teyc 15y ago
If I remember Cliff Click's [Azul] lecture "A JVM does what?" correctly, each machine whether JVM or x86 defines what is managed by the machine and what isn't. Just as x86 represents a machine which defines op codes only and leaves memory and process management to the operating system, the outcome of JVM's choices about taking responsibility for garbage collection, security, machine code generation is an interesting machine which can provide performance gains through time, just like Moore's law. I don't work with the JVM at all, so all I know I learnt from Cliff's lecture. The slides are here http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2011_WhatDoesJVMDo.pdf http://www.azulsystems.com/blog/wp-content/uploads/2011/03/2... and video here: http://jeremymanson.blogspot.com/2011/04/cliff-click-in-jvm-does-what.html http://jeremymanson.blogspot.com/2011/04/cliff-click-in-jvm-...
15y ago