Link Details

Please, i hav got bored of J this and J that. Just create a new platform independent language that compiles to native binary. You program binary will be platform neutral, only the core libraries will be platform specific. Your binary will just make calls to those libraries.

No need of JVM , get over it and move ahead.

Ah, Like C and C++ you mean? ;-)

Not really, if we take the "You program binary will be platform neutral" part...

you got me there

its "your program binaries ....."

Do you mean something like... the JVM?
Why do you thing there are so much Jxxx languages? Because the JVM is precisely what you ask for: a platform independent bytecode interpreter that compiles (via Jit) to native binary. The bytecode is platform neutral and only the deep core libraries (system access) are platform specific.
Languages based on the JVM just leverage the Java platform: rich library ecosystem, optimized and real-world tested VM with good Jit support.

The go programming language has already proved that there is no need of a VM, so now lets move ahead and make go like language that also is platform independent without a VM.

All you need to do is use the core libraries instead of native binary code and the libraries will be in native mode. The beauty will be that the core will be as small as possible to encapsulate the processor architecture.

The Go programming language is compiled (and officially not supported on Windows, so much for portability, even if that's temporary...).
Its logic is "write once, compile everywhere", like C and C++ (theoretically), while VM based languages' logic is "write once, run everywhere".
Both paradigms have advantages, for one you distribute only one file and run it on any platform (theoretically, again), for the other you have either to get the compiler to get it running (an option not popular on Windows world...) or to distribute lot of binaries. The latter having in general an advantage in speed.

I finally read (well, scanned) the article, and actually they say (much better) what I wrote above: while the Java name, used both for language and platform, is confusing, it is foolish to drop it because of that.
Using the JVM allows to leverage lot of good stuff, even at the cost of some inconveniences.
After all, Ruby (and lot of dynamic languages, from Lua to Perl) has already its own VM, GC, etc. But it takes efforts to get it at the level of the Java one... The "Just create" is easier to write than to do...

Why not remove the jruby name from blog post and move the discussion to another level when the question is languages and architetural decisions?

Well, since the entire point of the post is explaining to people (including regular Ruby folk) why their team has ported Ruby to the JVM, the title seems quite appropriate.