4 ms·

That seems reasonable to me - Java's had decades of optimisation, but Go's a fairly new language and runtime. I've just started playing around with Go, I'm qui

That seems reasonable to me - Java's had decades of optimisation, but Go's a fairly new language and runtime. I've just started playing around with Go, I'm quite liking it. It's a different approach to things, which is always fun.

leothekim 14y ago
Agree. I've been playing with Go a bit, and though I still lean towards python and scala, Go definitely shows promise. The interfaces model and channel synchronization primitives are compelling enough to keep me interested in its progress.
koenigdavidmj 14y ago
It seems like it might be a fun project to compile Go to Java bytecode. GCC might actually have all the relevant bits---it includes gcj, a Java compiler including bytecode generator, and a Go frontend. Knowing this, someone's already done it---anyone aware of such a thing?
- durin42 14y ago
  http://code.google.com/p/jgo/ http://code.google.com/p/jgo/ but I have no idea how complete it is, I only know it exists.
- strlen 14y ago
  The big pull of go for me is AOT compilation to native code (which translates to fast start time for command line utilities), close integration with the OS,support for value types, and stack allocation. These are not currently available on the JVM (although this may change as of JDK 8).
  - koenigdavidmj 14y ago
    I think Java supports escape analysis on loops and will actually allocate stuff on the stack if it's in a tight loop. Your other points are valid; this is more a curiosity than anything else.
  - pjmlp 14y ago
    Sure they are, there are more JVM out there than Oracle's you know? http://www.atego.com/products/aonix-perc/ http://www.atego.com/products/aonix-perc/ http://www.excelsior-usa.com/jet.html http://www.excelsior-usa.com/jet.html http://researcher.watson.ibm.com/researcher/view_project.php?id=174 http://researcher.watson.ibm.com/researcher/view_project.php...
    - strlen 14y ago
      I'm aware of real time JVMs, but they seem to target smaller scale mission critical applications (I'd imagine embedded or Scada?) None of these are free (or "open source" in the OpenJDK sense -- e.g., where most of the system with the exception of a few libraries is open), however, with the exception of the last -- where the first revision was available as part of Jikes RVM. The only commercial JVM that I do believe has some production server-side deployments -- Oracle's JRocket -- still doesn't support value types and has (in many cases) actually performed worse than HotSpot with large heaps. So to put it bluntly none of these fit "I'm willing to deploy this to thousands of nodes in production" criteria. To me HotSpot (due to its stability, performance, and support for concurrent GC) VM is more of a reason _to_ use Java/JVM languages -- otherwise I'd much rather use C#, F#, D, Go, or OCaml. Finally, I should it's quite possible to do manual memory allocation, bypass bounds checking, and to control memory layout using direct byte buffers and Unsafe in HotSpot/OpenJDK. Problem is (and I've mentioned it) is that it incurs serialization costs from copying objects to these byte arrays. Of course may this may be acceptable for many kinds of application, especially if only a _small_ part actually needs this (which I'd imagine describes many -- if not most -- kinds of applications).
      - pjmlp 14y ago
        I usually work with Fortune 500 companies, so there the price of these JVMs is a water drop in the type of budgets we work with. But for the scenarios you described, I agree with you.
        strlen 14y ago
        Cost is an issue if you're deploying on large scale. The fact the source is not available is an even bigger issue. OTOH if using a proprietary solution ($$ and closed source) was fine, I'd personally go with C# or F#. If you're fine using a closed-source runtime, why not just use a better language (not to mention Microsoft's products are free for startups via BizSpark)?
- seunosewa 14y ago
  This could be cool, but it'll be tough to simulate Go features like lightweight threads and cache-efficient object layout in RAM.
ww520 14y ago
Java came out at in 96. GO has been out for couple years ago. The difference makes it far from decades.
- sitharus 14y ago
  Decade and a bit then?
- RobAtticus 14y ago
  So Java has had 1.6 decades of optimization. He didn't compare the difference, just what Java has.

leothekim 14y ago

Agree. I've been playing with Go a bit, and though I still lean towards python and scala, Go definitely shows promise. The interfaces model and channel synchronization primitives are compelling enough to keep me interested in its progress.

koenigdavidmj 14y ago

It seems like it might be a fun project to compile Go to Java bytecode. GCC might actually have all the relevant bits---it includes gcj, a Java compiler including bytecode generator, and a Go frontend. Knowing this, someone's already done it---anyone aware of such a thing?

durin42 14y ago
http://code.google.com/p/jgo/ http://code.google.com/p/jgo/ but I have no idea how complete it is, I only know it exists.
strlen 14y ago
The big pull of go for me is AOT compilation to native code (which translates to fast start time for command line utilities), close integration with the OS,support for value types, and stack allocation. These are not currently available on the JVM (although this may change as of JDK 8).
- koenigdavidmj 14y ago
  I think Java supports escape analysis on loops and will actually allocate stuff on the stack if it's in a tight loop. Your other points are valid; this is more a curiosity than anything else.
- pjmlp 14y ago
  Sure they are, there are more JVM out there than Oracle's you know? http://www.atego.com/products/aonix-perc/ http://www.atego.com/products/aonix-perc/ http://www.excelsior-usa.com/jet.html http://www.excelsior-usa.com/jet.html http://researcher.watson.ibm.com/researcher/view_project.php?id=174 http://researcher.watson.ibm.com/researcher/view_project.php...
  - strlen 14y ago
    I'm aware of real time JVMs, but they seem to target smaller scale mission critical applications (I'd imagine embedded or Scada?) None of these are free (or "open source" in the OpenJDK sense -- e.g., where most of the system with the exception of a few libraries is open), however, with the exception of the last -- where the first revision was available as part of Jikes RVM. The only commercial JVM that I do believe has some production server-side deployments -- Oracle's JRocket -- still doesn't support value types and has (in many cases) actually performed worse than HotSpot with large heaps. So to put it bluntly none of these fit "I'm willing to deploy this to thousands of nodes in production" criteria. To me HotSpot (due to its stability, performance, and support for concurrent GC) VM is more of a reason _to_ use Java/JVM languages -- otherwise I'd much rather use C#, F#, D, Go, or OCaml. Finally, I should it's quite possible to do manual memory allocation, bypass bounds checking, and to control memory layout using direct byte buffers and Unsafe in HotSpot/OpenJDK. Problem is (and I've mentioned it) is that it incurs serialization costs from copying objects to these byte arrays. Of course may this may be acceptable for many kinds of application, especially if only a _small_ part actually needs this (which I'd imagine describes many -- if not most -- kinds of applications).
    - pjmlp 14y ago
      I usually work with Fortune 500 companies, so there the price of these JVMs is a water drop in the type of budgets we work with. But for the scenarios you described, I agree with you.
      - strlen 14y ago
        Cost is an issue if you're deploying on large scale. The fact the source is not available is an even bigger issue. OTOH if using a proprietary solution ($$ and closed source) was fine, I'd personally go with C# or F#. If you're fine using a closed-source runtime, why not just use a better language (not to mention Microsoft's products are free for startups via BizSpark)?
seunosewa 14y ago
This could be cool, but it'll be tough to simulate Go features like lightweight threads and cache-efficient object layout in RAM.

ww520 14y ago

Java came out at in 96. GO has been out for couple years ago. The difference makes it far from decades.

sitharus 14y ago
Decade and a bit then?
RobAtticus 14y ago
So Java has had 1.6 decades of optimization. He didn't compare the difference, just what Java has.