Hacker News Reader

Comment by deitcher | Hacker News Reader

It is pretty impressive as a project, but I am not sure I get the point. JVM already exists, so we can run Java programs. Go exists so we can compile Go programs. What do I get from running a Java program in a Go-built JVM over a C-built JVM?

View on HN

I've noticed from HN headlines that there's an odd focus on what programming language something is written in. Often they'll take the form of "A <thing that is already common> written in <recently popular language>", rather than a real USP. It's especially odd from a community that places so much emphasis on the importance of a good pitch.

> a community that places so much emphasis on the importance of a good pitch

A subset do, for sure. But some of us are just playing around.

I absolutely understand where you are coming from, but then again we are enthusiasts. It has some kind of relevance to us on the basis of being a novelty. Compare, "car engine runs on plant sap".

Think of it in terms of a typical 13 year old boy acting out, e.g. by climbing real high in a tree or doing tricks on his bike, to impress friends/girls. That's all this shit is, except it is targeted to a slightly different audience who will go out of their way to deny it. Not saying that applies to this particular project, just to your comment more generally.

Sometimes it is done just to learn, but it seems a bit silly to do it in public as it were.

I think it is closer to a 13 year old doing something that they have spent years practicing, such as a piano recital.

Sure, sometimes it is, undeniably. But given how immature in general this industry is--and that means both in terms of the span of its existence and in terms of the age of practitioners--it sure is suspicious how often X-that-has-been-around-forever-implented-in-Y comes up.

I mean how likely is it that "Hashtable/JS interpreter/JVM implemented in C" is going to be a big hit on HN? Not often. But since Go, JavaScript, and other insert new hotness language here are popular things somehow it's more interesting to retread old ideas with them. That's not the sign of a young master demonstrating his skill, it is the sign of an immature field that hasn't figured out how to distinguish what is new and important from what isn't.

It's unfortunate in particular for the people who do do these projects for fun or learning. These people have their work hijacked for a showoff culture's mutual backpatting.

A similar thing happens with browser technology. "Look at this amazing WebGL demo!" The thing is, the only interesting thing is that OpenGL can be accessed from JavaScript in the browser. After that, it's just lots of people rehashing demos that were done years ago, but people continue to be impressed because it's in a browser.

So we're all wasting our time. Some people find more interesting ways to do it than others.

It's important for libraries. If you're writing in Go, a Java library doesn't help you much. Think of it as an easy way to qualify leads.

For apps, it matters less but you still have to think about how easy it is to modify. That's why we care about open source, right?

This is the wrong way around for that. It won't give you Java/Go interop.

> It's especially odd from a community that places so much emphasis on the importance of a good pitch.

A good pitch? Why does that even matter? 97% of these projects are for fun/as a learning exercise. If someone is interested those things, then they can check it out. If they aren't, then I guess the author misses out on a few GitHub stars. shrug

There aren't always great reasons behind great hacks.

We can appreciate them for the ideas they present, the interesting implementation of features, and the what-if's that can come from expanding the hack further.

> JVM already exists

Actually there is no single "the JVM," even today. Various JVMs exist, commercial and free, that have their individual strengths.

Sometimes we build things just for the experience, just to learn as we build.

Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.

The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM.

Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds.

EDIT: to address all the comments.

I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable.

I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight.

    $ otool -L Main 
    Main:
        /usr/lib/libSystem.B.dylib
        /usr/lib/libiconv.2.dylib
        /usr/lib/libsqlite3.dylib
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
        /usr/lib/libstdc++.6.dylib


     $ du -sch Main 
         11M	Main

All C implementations of languages that exist on the JVM start fast. All JVM implementations are slow. How is this not a JVM problem?

Have you ever used Aonix, Websphere Real Time, JamaicaJVM, RoboVM, ExcelsiorJET, JikesRVM, OS/400 JVM, CodenameONE JVM,...?

If not, then don't say "All JVM implementations are slow".

I meant "all JVM implementations of languages that also exist in C". Sorry I was unclear.

Ah ok.

A pipeline of Java hello worlds then might take half a second just to spawn the multiple JVMs. It is also important to note that the work a JVM does scales in the number of classes you load: running "saxonb-xslt" with no arguments (so as to get the usage block) takes 215ms "hot" (1485ms "cold") on my relatively beefy server. In comparison, running "xsltproc" with no arguments takes 7ms "hot" (113ms "cold", though my cold numbers for this may be artificially low as maybe the JVM warmed up some C library xsltproc also happens to be using; the number doesn't feel wrong, though, given the hot times, which are perfectly reproducible, btw, as nothing else is happening on this computer). If I actually tried to use Saxon (so it had to load and link even more classes related to the transformations) the slowness would just become more and more painful.

Those numbers seem totally plausible. I am not advocating for `ls` to implemented on the JVM. But for most usages, there is not a huge problem implementing CLI programs on the JVM, but some things like loading a huge AoP framework is out of the question.

Right. The "JVM's slow startup" (or, rather, HotSpot's slow startup) is a result of two things: the tendency of JVM code to use a lot of dependencies and, more importantly, the time it takes the HotSpot to warm up enough until it does all the optimizing compilation to native code.

So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed.

HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed.

Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".

If the JVM is slow at loading dependencies, that fact is very relevant when talking about the startup time.

> startup time of Clojure has nothing to do with the JVM

Startup time has everything to do with the VM. Check out this post, comparing perf and startup time for Clojure on the CLR vs JVM:

http://stackoverflow.com/questions/10827093/clojure-performa...

We are working on the lightweightness. We currently throw away a bit of startup performance due to the way we load classes at runtime. That being said, 23ms is quite reasonable i guess.

I don't think the size is horrible, though for mobile, smaller executables do reduce breakage. I haven't tried converting a large app, but I assume even a big jar is a small incremental increase in exe size.

23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.

There have been many different VMs implemented on top of JavaScript VM, and it is to be able to run codes written in different languages on JavaScript VM without porting effort. It is useful since there are systems only running JavaScript programs, such as web browsers. I guess the purpose of this project may be justified similarly as Go started off from frustration with JavaScript and Go enthusiasts are dreaming that it would replace JavaScript (or get a spot in every browser) in the future.

Minor note: go is now self-hosted which means it is no longer wrapped in c.

Reply on news.ycombinator.com