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