Hacker News Reader

> Even with something not-so-high-level-but-sorta-high-level like Java or C#, you still have an abstraction level (JVM/CLR) that must first boot, then interpret, then execute.

There's no reason those shouldn't be resident daemons. Heck, if they were, why should the OS be anything other than a hypervisor for managing those, plus some abstractions like a "container" interface that each runtime execution driver implements? We could have had something like Microsoft Research's SingularityOS a decade ago if we had approached the problem from the other direction—pushing the runtime lower in the stack, instead of trying to write a kernel that does everything. Imagine your laptop booting into Xen, and then loading a Smalltalk image that contains the desktop, while in parallel booting up some background daemons into virtually-isolated Erlang nodes.

> Sure I may use a great many separate apps, all working together in orchestration (my database, authentication server, some 3rd party libs, etc), however for some apps, a great deal of the codebase will end up being a monolithic piece, and that is just fine so long as it's maintainable and extensible.

The author's complaint was less about factoring of components and more about the way we (still) do IPC. As in, why are we directly-and-unsafely sharing allocated memory handles between families of processes (i.e. using threads) instead of just having processes push information to one-another's inboxes over sockets? Anything that's currently threaded could be done with message-passing instead. And like the article said, it'd be only a 2-4x difference in overhead, minuscule compared to the speedups over the past decades.

> There's no reason those shouldn't be resident daemons

Well, you can blame OS vendors for that. But would it be practical even if implemented? For a system that will never execute Java code, why would a JVM daemon be running in the background? Even if it were a daemon, it would still require spool-up time to interpret the first byte-code down to machine code before the built-in jvm optimizing compiler could kick in and compile down to native machine code.

> hypervisor for managing those

We do have similar things now-days, but it's worth considering that your OS does a lot more than just simply execute other code. But again, there's a practicality issue trade-off. Containers aren't exactly easy, and it's unlikely that even today's implementations will be the last attempts that get it 100% right. (BTW, Xen requires a Kernel, and for the sake of argument, your laptop does not require anything but the kernel to boot (actually less, you can boot raw binary machine instructions), the rest is convenience for the user).

> why are we using processes that share mapped memory allocations (i.e. threads) instead of just having processes push information to one-another's inboxes over sockets

Sockets still have overhead. IPC can be achieved in a number of ways, some better than others, and some better in certain circumstances. Why bother opening a socket when my program consists of only a small handful of child processes all running on the same host and only require very small amounts of communication (such as a keypoller subprocess)? Message queues are fine for sending basic messages around, but even a message queue is unnecessary if I can pass the info into the child process as I spawn it. Why over-complicate things if not necessary?

> a 2-4x difference in overhead, minuscule compared to the speedups over the past decades.

That is, of course, relative. I think some large projects would argue a 2-4x improvement in compile-time, for example, is a dramatic time savings. If we snubbed every 2-4x performance improvement, we'd still have performance on the scale of 1984.

> Even if it were a daemon, it would still require spool-up time to interpret the first byte-code down to machine code before the built-in jvm optimizing compiler could kick in and compile down to native machine code.

The first time you loaded that bytecode, sure. Every time after, it should be hashing the byte code it's being told to load, and then taking that hash as a key into a disk cache of already-profiled-and-JITed object code. In fact, the application can ship with those cache files (like a pNaCl binary shipping with its native counterpart), or the developers could dump (signed copies of) those cache files into a DHT which the runtime would look in as an extended cache.

Either way, the API is still "load this byte code", but the bytecode is effectively just a really long key that looks up the real code that should be loaded. It's just that in the absolutely-cold path, the JIT (effectively the load-time compiler) can kick in and actually parse the bytecode into the required native code.

The OS/400 mainframes use a JIT in their kernel.

All userspace code, including C, compile to bytecode known as TIMI.

Depends what version you are running and the applications running ontop. The AS/400 box at my company runs a load of RPG language code, which is interpreted at runtime.

It's very likely that your CPU interprets the machine code at runtime. What's your point?

EDIT: "machine" -> "machine code". Doh.

There's no reason those shouldn't be resident daemons.

In fact, they already can be. For the JVM, there's nailgun[1], for example.

[1] http://martiansoftware.com/nailgun/

> why should the OS be anything other than a hypervisor for managing those, plus some abstractions like a "container" interface that each runtime execution driver implements? We could have had something like Microsoft Research's SingularityOS a decade ago if we had approached the problem from the other direction—pushing the runtime lower in the stack, instead of trying to write a kernel that does everything. Imagine your laptop booting into Xen, and then loading a Smalltalk image that contains the desktop, while in parallel booting up some background daemons into virtually-isolated Erlang nodes.

With Microsoft partnering with Docker, I can see exactly that happening in a few years.

> Well, most higher level languages are getting interpreted, which require some cpu time to startup. Even with something not-so-high-level-but-sorta-high-level like Java or C#, you still have an abstraction level (JVM/CLR) that must first boot, then interpret, then execute.

Anyone with a degree in CS knows this is not true.

Additionally there are quite a few native code compilers for Java and C#.

>> C still doesn't have a module system

> Any why should it? It's a low-level language usually (but not always) reserved for low-level (ie. system) programming. This is not the typical language of choice to write your pluggable enterprise app in.

I don't know? Maybe because every other system programming language since the late 70's had a module system?

> Anyone with a degree in CS knows this is not true.

Not sure what you are trying to imply here? Perhaps it's to say that all code can be compiled down to machine instructions? -- Well, that would negate a lot of benefits of using some of the higher level languages and/or their portability of architecture claims. So yes, my statement stands true unless you do compile down to machine code for your target platform.

> Additionally there are quite a few native code compilers for Java and C#.

I'm not very familiar with C#, but it's worth noting that Java does indeed get compiled down to native machine instructions during runtime (mostly noticeable on long-running applications and especially in "hot zones" of code). It's been claimed that the optimizing compiler embedded in the JVM is one of the best around, and usually will result in code running at the same performance level as C on the same platform (again for long running code allowed).

> I don't know? Maybe because every other system programming language since the late 70's had a module system?

There aren't exactly many languages that are considered to be "System Programming Languages". For most of the *nix's (all?), it's C (which as noted does not have a native module system). For Windows, it's mostly C++, which also has no native module system. One should ask what benefits a module system would bring to a mostly bare-bones language like C that could not be achieved in the 40+ years it's been around?

Ada, Eiffel, D, Go, Rust, OCaml, Common Lisp, Haskell, Scheme Dylan, among many others, provide native ahead of time compilers in their default toolchains.

All look pretty high level to me.

C# can be compiled ahead of time with ngen since .NET 1.0.

Singularity compiles Sing# (an extension of C#) to static binaries

Windows Phone applications get compiled to native code on the store. The mobile phones only see native code.

.NET Native will bring the same functionality to desktop applications.

Mono compiles C# to native code in iOS and offers the same functionality on other systems.

The now defunt CosmoOS used C#, compiled to native code, as their systems programming language.

There isn't no such thing as "The JVM". It is a specification with a reference implementation, that any JVM vendor can be certified against.

Just like any other language vendor can be certified against the respective ECMA or ISO standard for their respective languages.

Aonix PERC, JamaicaVM, J9, SubstrateVM, JikesRVM, ART are all examples of Java environments that offer the option to compile straight to native code.

> Ada, Eiffel, D, Go, Rust, OCaml, Common Lisp, Haskell, Scheme Dylan, among many others, provide native ahead of time compilers in their default toolchains.

I think you and Alupis have different definitions of the term "system programming language". In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.

I think a good indication for a system programming language is the ability to write its runtime system in itself. Any language with non-optional GC collection fails this test, because you couldn't write the GC in that language.

> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.

No, because I have listed Ada in my list.

> Any language with non-optional GC collection fails this test, because you couldn't write the GC in that language.

Better improve your CS skills. Ever heard of Cedar, Modula-3, Oberon, Active Oberon?

EDIT: Just for the kicks, here is Oberon's GC implementation, in Oberon!

http://www.inf.ethz.ch/personal/wirth/ProjectOberon/Sources/...

>> In general, the ability to be compiled to native code is necessary but not sufficient for typical system programming language tasks, like hardware drivers, OS kernels, and language runtimes.

> No, because I have listed Ada in my list.

I have no idea how that would refute my statement.

> Better improve your CS skills.

Don't be so condescending.

> Oberon GC in Oberon

I stand corrected: You're right, the GC runtime for a language with non-optional GC can be written in the language itself. I guess a better, more precise indicator are the following two requirements:

1) Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers.

I don't see how one could implement the GC runtime without these features. (Note that native support for heap-allocation means that GC is optional anyway). What do you think?

> I have no idea how that would refute my statement

Ada is used for building systems running on bare metal.

> Native support for calling OS services, for example through system calls (specifically, reservation of memory space). 2) Pointers, pointer arithmetic, and reading/writing memory through pointers.

Oberon variants and Modula-3 support GC pointers and have been used to write full OSs.

Pointer arithmetic is possible in code regions marked as unsafe.

The Oberon based ones were used for several years at Swiss Federal Institute of Technology.

Spin (Modula-3) didn't had such luck, as DEC and Olivetti got closed down.

Just read the code provided in the link for Oberon's example.

The problem is that many think GC == Java, while during the years Java was getting loose into the world, there where languages like Cedar, Oberon and Modula-3 that while having a GC do offer the fine grain control one needs for system programming.

> Note that native support for heap-allocation means that GC is optional anyway

Not really. In safe systems programming language the GC is always there and you need to mark the code as unsafe when allocating from foreign heap. Meaning you are responsible for not tainting the whole code base.

For example, in the Oberon OS only the Kernel and driver modules do manual allocation.

Actually, Java 9 is getting the missing features from safe systems programming languages (some of them will only come in Java 10).

There are operating systems implemented in many of the languages pjmlp listed.

> Not sure what you are trying to imply here?

He's saying that being interpreted and being high level are orthogonal.

> Well, that would negate a lot of benefits of using some of the higher level languages and/or their portability of architecture claims.

Portability and high level-ness are also orthogonal.

> Something is wrong if most programs don't run instantaneously

Agreed. BBC BASIC V on my Archimedes had zero startup penalties, unlike modern JIT languages.

> Highly optimizing compilers aren't worth the risk

Agreed. The problem here is unforseen overflow resulting from machine representation of ints.

> Design applications as small executables that communicate

Agreed. Both UNIX and Erlang have demonstrated the efficacy of this approach.

> Don't write temporary files to disk, ever

Agreed. WANG wordprocessors routinely outperformed MS Word 6.0 due to their RAMDISCs.

> Everything is so complex that you need to isolate yourself from as many libraries and APIs as possible

Agreed. BBC BASIC V did everything I needed without need of external graphics libraries.

> C still doesn't have a module system

Agreed. Indeed, do we actually even need the complexity of C++ to remedy C's deficiencies?

> Well, most higher level languages are getting interpreted, which require some cpu time to startup. Even with something not-so-high-level-but-sorta-high-level like Java or C#, you still have an abstraction level (JVM/CLR) that must first boot, then interpret, then execute.

Startup times of typical VMs on modern hardware are mostly insignificant compared to initializations of various libraries and frameworks inside the actual application (and in many GUI applications there is outright call to sleep() in initialization code).

On the other hand this seems somewhat inconsistent with the fourth point. For example GIMP plugins are external processes and most of the (long) startup time of GIMP is spent exec'ing random small binaries that output few bytes of data and then exit.

A reason not to have small communicating binaries is that communication adds overhead for serialization and deserialization.

Performance overhead and programming/complexity overhead, because you basically have to treat incoming data as external input which has to be thoroughly validated (more thoroughly than data structures coming from within the same program).