I rec'd an email about my recent thing to do with the "shared nothing" vs. "shared memory" models, JRuby, et al. being crammed into the JVM, CLR, Parrot, and so on.
The point of the email is well taken. Essentially JRuby is a good thing because the JVM is widely adopted and accepted in enterprises. This is the vehicle that will allow JRuby to be widely adopted. I agree with that approach, and do think JRuby, Jython, IronPython, and related languages are all very good things to have.
I'd rather have a widely adopted shared-nothing environment. That is the model of the future. The shared-memory model *is* the current model but there is plenty of evidence we've been done with it for some time. Another five years or so will be necessary for this to really sink in.
But we have JRuby now. Yeah, I'll program in JRuby today. At the same time I will push for something better, and expect to get it about 2010 or so.
Let's be clear that the JVM has been lurching toward a shared-nothing model already for well over five years.
The servlet model, the EJB model, the Jini model... these are all in various ways attempting to provide semi-shared-nothing models so we can each contribute our own isolated parts to the whole. Unfortunately they're each anachronistic, one-off, partial solutions. JSR 121 is attempting to make this even more general for all kinds of pojo scenarios.
Given the isolation model that just comes for free with Erlang, the vast majority of the complexity and variation of these lurches toward isolation for Java would just go away. (Erlang itself has a *little* cruft but that's nitpicking.)
I've been through the garbage collection wars, the dynamic typing wars. I think we'll get better isolation more easily but so far it remains a subtle point in the community at large.
Iceman: "You like to work alone. I've heard that about you."
Update: A Fellow traveller writes...
Yes, you can layer a shared nothing architecture on top of a language that does not hand-hold you towards a shared nothing design, but the scope for error is huge. Remember the days of malloc anyone? Same idea.I don't think it is quite that drastic. Yes, I lean toward semi-functional languages like Scheme and Erlang, mostly Scheme because you can more easily write all kinds of languages in Scheme. Gambit Scheme is a good candidate platform for building mult-language shared-nothing runtimes.
But even "heavily-imperative" languages like Smalltalk, Ruby, and Python can take much better advantage of a shared-nothing runtime model. These implementations just need to be able to run more than one environment within an OS process. Kind of like doing a "fork" that forks an isolated process within the current OS process. Now you have two or more Smalltalks, Rubies, Pythons, Javas, etc. running in that one OS process, isolated one from another.
When these are truly isolated and efficient then nothing should prevent an OS process from mixing these languages "sub-processes" within the same OS process. These are not new ideas, but have never really been fully explored. Most of the bits and pieces are in place. It's just around the corner.
2 comments:
I think this pragmatic approach might be an important part of Sugar -- we set up the archetype of a Python process (including importing core modules) when the machine is started up, and fork off from that to start new processes. Processes aren't as light as Erlang, but it does make processes somewhat light (and that's very important in the environment Sugar is intended for). Then we use DBus to do IPC from there.
It's nothing all that new, but it will be interesting to see how far we can take it.
Michael Sparks wrote However our target is something understandable by the average user (rather than force people to change language if they don't want to) ...
"Finally, we have seen that programmers – even those with no previous exposure to functional languages – learn Erlang quickly, and become productive within a matter of weeks."
Four-fold Increase in Productivity and Quality p24
Post a Comment