The C++ interop tools out there are nothing short of outstanding and a lot of (compiler research academia and community) effort went into it.

What Java and GC brought was raised levels of abstractions and hand-holding and with it a huge framework of bloat. Elrang would go no different if we took that route, but as you say it is oriented towards network I/O not complex simulations so ok I can agree it that sense it would be appropriate for a limited domain.

It is simply a fact that EJB (I worked on it 10 years back and see it used to date sure), J2EE and various bloatware has lost an enormous audience because of its complexity while gaining nothing on its productivity hype. Another proof of that is uptake of Ruby.

So I can agree ‘for servers and telephone switches’ it often is more sense to use it. Unfortunatelly, many people need a bit more than that.

“itself can be a rather hard to predict OS-specific behavior, even in a C program”.

I cannot agree here, because it is very stable and predictable for a large number of Linux, QNX and even NT deployments.

Embedded and device field demonstrate what you say is not the case very well.

” think this adherence you have to compiler-only is not even existent in the rigorous sense”.

I am surprised you say this considering your blog title, specifically the word ‘meta’.

In rigorous sense it is very real and leading the entire show with generics and MPL for quite some time (around 5 years). It would be foolish to assume it is going to change any time soon. Just look at what impact it had on CLR and how it now outperforms Java (with help of MS’s own OS mechanisms or not) by a light year and these are few simple examples.

” I can make a Python binary, I just load up my code into a big data block and run the interpreter, all in one binary.”

That is fine but you are missing my point that fighting the ‘compiler adherence’ is assuming a programmer is more smarter. And he/she usually isn’t. And no longer can they even approach the machine code generation even with a bargpole, hand-writing or generating x86 is as slow and inefficient and unpredictable as interpreted and GC-like hackery.

As for Java ” overwhelming “, everyone I see and speak too perceives it as Underwhelming in many instances (in terms of cost, productivity and much more) if you compare it to alternatives.

Also I do not think you should believe benchmarks (especially one as weak as you presented) and look at a bigger picture, practical bits, you know, like what Google infrastructure is written in, like what all those runtimes are written in, like what boots your box and rooter and more etc.

Of course that you can glue Python, hack even JavaScript or whatever you like. But the metal is always going to support garbage collection induced damage if any performance is a concern.

I hope this is a bit easier to understand.

Let’s not forget that the number of bugs was of similar density, but the C++ implementation was longer, more complicated, and yet slower because it wasn’t complicated enough to deal with Erlang’s well-oiled machinery in handling (in a nutshell) network I/O. We’re not dealing with complex simulations or computations here, but rather switching stuff around, something Erlang was more or less designed to do. Memory residence is probably large there because Erlang overcommits memory (much like many garbage-collecting runtimes do) and never shrinks. (Which itself can be a rather hard to predict OS-specific behavior, even in a C program)

I think this adherence you have to compiler-only is not even existent in the rigorous sense. I can make a Python binary, I just load up my code into a big data block and run the interpreter, all in one binary. It’s all code and data segment, right? Everything is. Java is a newcomer? Java2 is ten years old, and its overwhelming adoption on the server side has more or less eliminated an entire class security bugs as well as greatly increased reliability. (Garbage collection, array bounds checking).

Even more convincingly, I can take an entire SBCL core image including my code and dump it to a binary. There is no obvious hard line between something that is “not compiler-only” and “compiler-only,” only compilers that generate different code. This isn’t even “cheating” in the sense that I’m just interpreting a big data block; it compiles it into honest to goodness x86 byte code with stack pointer manipulations and everything. Just try calling the disassemble function on a symbol.

You really should be making an argument like “I’m against arrays bound checking, garbage collection because they’re too slow,” or whatever it is you really mean. Otherwise…I found a lot of your comment very hard to understand.

I remain unconvinced. If nothing, purely from adoption perspective in at least half a dozen domains I am interested in. That and seeing that similar error rate and productivity is there while certainly bringing different type of risk.

That the ‘Erlang DM’ is twice as fast as C++ ‘DM’ means nothing in my view, ie. nothing can beat native code and C++ compilers (humans constantly try to outsmart it and consistently fail). Sure it is more work, but libraries are out there, it is not 90s in C++ world any more.

170% greater memory residency is a huge turn-off, enough to invalidate many modern caches.

And naturally, this is just ‘bare’ C++ xx we are talking about, and there are far too many tools and commercial implementations demonstrating its adoption, power and longevity to simply ignore or dump it for another Haskell, Lisp or Smalltalk, Java or CLR or ML or any other newcomer.

Your research project pointer is great example.

Not that I am against proven ideas and I see that Erlang has done some great works out there, or that I am sticking to my zealot guns, but compiler, and compiler only is what makes all great work possible.

I believe all you are observing is that C++ is incorrectly assumed to run in a classical huge stack, process or thread oriented model whilst that is far, far from reality. Even FGPA people are showing it is just a misconception, and on scientific front there is nothing out there apart from Fortan that matches it in performance and library support.

And I strongly believe it is all just a start as people move from legacy of C.

Cheers

sixyears.wordpress.com

My verdict on this: as we have seen on the paper I cited one can get this event-like performance from just standard old threads and the authors conclude that we basically need better threading implementations, so certainly it is not out of the question for Scala or even regular old Java. I somehow doubt that this is the reality of the implementation today (and if it does support stuff like this there is little doubt in my mind that performance would suffer greatly), but maybe I should run an experiment. That’s probably involved enough to justify another full post in the immediate to intermediate future. A lot of my doubts come from the fact that some of this stuff is pretty low-level and that Scala would have a hard time maintaining competitive performance while actively making use of some features the JVM may not provide. But I am no JVM expert, so it’s fuzzy…the best way to find out, I think, is try.

http://www.artima.com/scalazine/articles/steps.html

One reason you might want to use Scala is that it allows you to increase your productivity compared to Java while leveraging JVM execution speed, your existing investments in Java code, knowledge, and the vast array of APIs available for the JVM. It has the conciseness of a dynamic language like Ruby or Python, but it is statically typed, like Java. Another reason is that Scala comes with an Erlang-like Actors library that greatly simplifies concurrent programming, but runs on the JVM.

Any thoughts? Can Scala really match Erlang for concurrent programming?

FYI: I don’t know why, but you got caught in the spam filter. Luckily I noticed and fished you out.

I think Erlang is one of the more interesting languages I’ve seen, so I’m very happy about blogs that remind us that there is more than Java, Ruby ….