Go for the JVM, written in Scala | Hacker News Reader

Go for the JVM, written in Scala

code.google.com

71 pointsDanielRibeiro57 comments

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

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

How is structural typing implemented efficiently?

http://research.swtch.com/2009/12/go-data-structures-interfa...

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.

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)?

A Go programmer forced to use the JVM might.

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

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

Standard Go doesn't need JIT, it is all compiled to native code already.

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.

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.

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.

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.

No, it's not commonplace.

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.

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.

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

>>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=...

I don't have the time to, nor do I care to, evaluate the legitimacy of their benchmarking suite.

But, are you honestly suggesting that Java hasn't had dramatically more corporate funding than Go? Don't be absurd.

Here's what you claimed - "but when you weight by funding, compiled languages clean house".

But you don't seem to have any information at all on $$$ amounts spent on the development of compiled languages (C, C++, Fortran, ...) compared to others (Java).

Obviously you don't know what would result "when you weight by funding".

If you want to ask the GCC folk for an estimate of how much of their development has been done while on the payroll of other companies, feel free to do so. I expect you will find that it is somewhere within a few orders of magnitude as what was spent on Java by Sun in the past 2 decades.

In short, my suggestion is that shittons of money has been spent on Java while relatively little money has been spent on Go. Yet somehow they are currently pretty evenhanded. You haven't been able to provide any sources that suggest other than this rather sensible claim.

Funny how that works.

> my suggestion is that ...

Here's what you claimed - "but when you weight by funding, compiled languages clean house".

Do you wish to abandon that claim?

Not in the slightest. Do you wish to address it?

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.

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

Pthreads is not part of any of the C standards. Your credibility is sorely hurting.

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.

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.

I don't care about micro benchmarks, I care about real programs. When is the last time any real user said "Yeah I think I'm gonna go home tonight and fire up the N-body problem on the PS3". Write a video game in java and then tell me that it's on par with statically typed languages compiled to native code in terms of performance.

Also, this language shootout doesn't use optimized compilers for a bunch of languages like C#/F#. Also for C/C++, ICC is much faster than gcc. I would hazard a guess that there are many more than 4 language implementations that are much faster than java for real programs that allocate memory.

The fact that Go is on par with java after a couple years is impressive. It took java ~20 years to get to that point.

>>any real user<<

Scientists solving n-body problems are real users too.

>>doesn't use optimized compilers for ... C#/F#<<

What "optimized compiler" do you suggest for linux C#/F# ?

Meanwhile http://shootout.alioth.debian.org/demo/compare.php?lang=csc&...

>>many more than 4 language implementation<<

lemming wrote "Only 4 languages are faster", not only 4 language implementations are faster.

For C#/F# I'd suggest using the Microsoft compilers/JIT as that's a more realistic usage of C#/F#. I realize that the MSFT implementation doesn't work on Linux.

Languages aren't faster or slower, only implementations are. Look at the performance of the CINT implementation of C.

It's conceivable that on some future computing platform Ruby would be faster than C. (Eg. On a Symbolics LISP machine LISP is probably faster than C)

How is suggesting a C# implementation that you know will not work realistic?

Programmers run their programs with implementations not with languages - so what makes you think programmers are confused about that? When they say C they probably just mean the usual well known C compilers.

Today, we can only use the programming language implementations that are available today.

Benchmarking C# on any platform other than Windows with Microsoft's stack, then pretending you are being honest.... that's just nuts.

>>then pretending you are being honest<<

... that's just ad hominem.

And your comment notably fails to address my concern.

Name calling doesn't rise to the level of expressing a concern.

I am expressing concern that you don't seem to see any issue in the slightest with benchmarking an effectively Microsoft language with Microsofts stack. Good job acting indignant to avoid addressing this.

Allow me to additionally point out that this account you are posting with seems to be used solely for the purpose of trolling discussions about programming languages. Someone who only shows up for programming language discussions surely cannot be any stranger to a very mild "insult" or two.

When Go is involved, it is better to compare the 64bit compilers which are the ones used by almost everyone:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

Go is already faster than Java in half of the benchmarks, and uses dramatically less memory.

Of the benchmarks where Java wins, at least one (regexp-dna) is not related to the language at all and only to the regexp implementation, the one used there is a toy, Russ Cox already has written a much better high-performance regexp implementation based on re2 for Go which should replace the existing one very soon.

Why did't you suggest the quad-core x64 measurements?

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

> I think its somewhat naive to think that it won't be hard to surpass the JVM.

Go already surpasses the JVM in many areas, for example it has magnitude orders lower memory usage, and even in performance it already beats it in quite a few benchmarks, see:

http://shootout.alioth.debian.org/u64/benchmark.php?test=all...

And this is without the simple optimizations that are coming soon to Go, and even after that Go still will be able to improve performance greatly without too much effort.

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.

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.

Also, Google happens to have a pretty important Java platform of its own on which it might like Go to run.

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?)

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

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/2... and video here: http://jeremymanson.blogspot.com/2011/04/cliff-click-in-jvm-...

I'm not sure I understand what does compiling a javam have to do with replacing a vm with a compiler? The jvm has really good garbage control and a good jit compiler. LLVM has some of the stuff needed for writing a jit compiler for a vm. I'm not sure whether a compiler for a garbage collected language will be faster then a jit compiler.

Why isn't it written in Go and bootstrapped?

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)

Yea, self-hosting is neat, but also makes bootstrapping much more complicated, specially when the language is still changing.

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

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.

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!

This is another area where Go prefers pragmatism over everything else.

Interoperability with all the rich Java frameworks seems a win.

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

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

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.

Reply on news.ycombinator.com