Hacker News Reader

Comment by telephonetemp | Hacker News Reader

Between D, Nimrod and Julia it looks like there's a resurgence of fun in (JIT) compiled languages.

All available D compilers generate native code directly, there is no JIT involved.

Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments.

[1] Funny enough, the precursor of .NET was native and COM based, similar to what is now WinRT, more info here,

http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-co...

All available D compilers generate native code directly, there is no JIT involved.

I think that's why the GP has the JIT in parentheses (to account for Julia's implementation, which does use a JIT-compiler, as opposed to D and Nimrod)

Fair enough, it wasn't clear to me.

Sometimes I wonder how computing would look like if the default implementations of Java and C#[1] were available from the start as native compilers, instead of VM environments.

At least with Java that would defeat one of the main intents of its development. What would you think would be gained by having non-VM based implementations of these by default?

What would you think would be gained by having non-VM based implementations of these by default?

For the JVM, considerably lower startup/JIT warm-up times. You can really observe this nicely if you're using Zinc (the incremental Scala compiler), where you not only cut the startup overhead down to pretty much zero, but compilation really speeds up once the JIT has warmed up a bit. (Hence why Nailgun exists.)

I only have a passing familiarity with Scala so I had to look up Zinc, and my hobby languages are erlang/lisp and work is C# so Nailgun is also new to me.

Nailgun seems to be a way to keep the JVM running so you don't incur the startup overhead. Straightforward enough, and makes sense when your execution time is dominated by the JVM init.

Zinc seems to be a compiler based on Nailgun so that performance improves over time (particularly useful for long compiles or frequent compilation).

Neither of those though, move Java off a VM/JIT basis. However, as someone who hasn't seen them before, it was interesting reading and neat to see what's going on in the rest of the world.

Neither of those though, move Java off a VM/JIT basis.

That's the thing; the Nailgun workaround to an extent avoids the startup overhead, but can create other problems. E.g., when you're starting multiple builds on the same server (because the Nailgun server listens on a port, so you may have to sort out conflicts), if you have multiple users on the same machine (because anybody can connect to the socket, so you have a potential security problem), etc.

With a native option, this can be avoided (note that IBM offers an AOT compiler for Java).

Note: I'm not saying a native option doesn't make sense, my original question is what would be the benefit for Java/C# (though we've focused on Java) of native first.

Re: Nailgun - that seems like an implementation issue, but yes, if native compilation were present then Nailgun wouldn't exist (or need to) so the technical issues causing those problems wouldn't exist.

> At least with Java that would defeat one of the main intents of its development.

If you mean bytecode, well there isn't nothing speaking against it. After all it is just an implementation issue.

And bytecodes are not Java specific. Pascal, Ada, Modula-2 are languages with native compilers that also had originally bytecode compilers as well.

But most importantly, it would not confuse a whole generation of developers to mix strong typing with VM as form of implementation.

I'll admit, I was only in HS in the 90s, but by the time I got to college and was studying CS that confusion never occurred to me. Was there really a period when strong typing was specifically associated with VMs and vice versa?

You studied CS, and probably even had a nice CS degree.

Many people discussing about languages in HN and reddit, tend to first of all, mix languages with implementations. Language X is compiled, interpreted, ..., sometimes without knowing multiple implementations are available.

Then many never used strong typed languages with native compilers, like Pascal, Modula-2 and so on. Their experience tends to be limited to JVM/.NET languages.

Outside of this world, they kind of know C and C++ are not as strong typed as those languages, don't have a GC and have native code compilers available.

Hence, strong typed typed languages are managed and require a VM.

This is a pattern I observed in many young developers without CS background.

Start up time. You can't write cli programs if the JVM takes 100+ms to start up.

That's a fair issue, but also a particular use-case. Java seems to be suitable for long running apps where that 100+ms start up time is easily covered as an ammortized cost over the apps uptime. It still doesn't answer what benefit would Java have if it had been native compilation from the start versus VM (and later VM with JIT-compilation). It would not have been able to run on near the number of platforms that it initially supported if, instead of porting a VM, they'd had to support many OS/ISA pairs. The VM -> VM w/ JIT approach provided a deployment path based on incremental improvements. Initially support dozens of platforms with good enough performance, then over time improve performance on each platform. Versus initially support a handful of platforms with good performance and spend years getting the breadth of platform support.

So what?

This was the initial way Pascal and Modula-2 were developed. P-Code and M-Code were their bytecodes.

This didn't prevent most compiler vendors to introduce native compilers and use those bytecode implementations mainly for bootstraping purposes.

Writing compilers is not that dark magic thing many think about.

Well, except when targeting x86 processors, maybe. :)

How do webservers solve this problem and why can't CLI programsw do the same? Invoking a Java program could connect to a running jvmd daemon

They "solve" it by being long running applications. When GP says CLI they likely mean things like grep or cat or other command line tools, not just interfaces, that tend to run in a very short time. A Java implementation would see a lot of extra time spent on just the startup. Consider writing a bash script that calls out to grep for each of a bunch of different files (an example, better ways, but go with it). Say it ran grep 100 times, jgrep at 100ms startup time would take 10s longer just on the java startup time, ignoring any other performance differences.

A project which does exactly that: http://www.martiansoftware.com/nailgun/

The crucial combination appears to be static typing + automatic memory management + imperative programming. This is a niche that has not been served well by languages outside the JVM/.NET families; and the JVM has the problem of having pretty high per-process overheads while the problem with .NET languages has always been portability/deployment outside the Windows ecosystem.

Reply on news.ycombinator.com