We already have a VM…
By Ryan Tomayko under Then they laugh at you... on 17. July 2005There is an emerging notion that there are really three cleanly separated platforms that will be contending for the enterprise over the next few years: Java, .NET, and LAMP/friends. Current mainstream thinking suggests that LAMP isn’t really a contender but that dynamic languages at least have a chance of riding in on top of the JVM or CLR.
But I’d like to consider some of Sam’s findings in working with Parrot in the context of dynamic languages on the JVM or CLR. Specifically, that using a common VM for multiple languages is hard; and keep in mind that Sam is hacking on a VM that is designed for dynamic languages, whereas the mainstream VMs are not.
As I was saying, initial thinking suggested that one of Jython, JRuby, IronPython, etc. would be the horse that dynamic languages would ride into the enterprise but I’ve grown away from this notion for a few reasons:
Rails is gaining acceptance with hardcore Java heads under the C Ruby implementation, not the Java Ruby implementation.
The LAMP stack is gaining acceptance at a rapid pace and in my experience, adding Java/.NET to a LAMP setup results in an impedance mismatch both in tool simplicity and quality of license / community.
The misconception that dynamic languages are useful only for “scripting” type tasks (e.g. gluing static language code together in controlled environments) is fading fast. It’s hard to find someone who will argue that Python or Ruby are incapable of being used as the primary language on large projects where these people were everywhere as early as a year ago.
Dynamic Language to Shitty Language bridge libraries give you the best of both worlds: a portable and efficient implementation of the language interpreter plus the mass of libraries that were developed under legacy runtimes (yes, I’m trolling now) like the JVM and CLR.
I’d much prefer to be working on the C implementations of these languages as opposed to the mainstream VM based ones. The JVM/CLR based implementations have problems: C extension libraries (are they even possible?), a lag in features from their mainline counterparts, less community involvement, and running atop mainstream VMs typically requires more resources than running atop the C interpreters.
Further, Java and .NET have licensing issues that create obstacles to adoption. The inability of Linux/BSD distributions to include the vendor implementations is a problem that neither vendor seems to be willing to budge on. The Mono and GCJ/GNU Classpath projects are moving in the right direction, no doubt, but it bothers me that in the end our best case is a situation where we’re running great languages on top of VMs designed for poor languages and have no participation from their original creators. That doesn’t really give me the warm and fuzzy about the future of dynamic languages…
Note that Parrot is a very different situation from the mainstream VMs. It’s being designed for dynamic languages, is licensed for the community, and probably won’t have the same issues with wrapping C extension libraries.
Getting to the point, I’d like to challenge the assumption that running dynamic languages on mainstream VMs is optimal / desirable in the long term. The existing interpreters have thriving communities, years of proven use, and a slew of C/C++ extension wrappers to even more proven libraries. They are already cross-platform and there’s bridge code for accessing the vast set of functionality that has been implemented in Java or C#.
The real question for me becomes, when will LAMP/friends gain legitimacy as an “enterprise class” platform and how quickly will that force the industry to re-evaluate optimal deployment models?
Danno:
Do Linux and Apache not scale well? All I know about those two pieces says “SCALING AWAAAAAY!!!!”
I suppose arguments could be made against MySQL, but there’s always, PostGre or one of the other DBs, right?
As for the P’s (Incidentally, with Ruby gaining ground, maybe P should change to Programmer’s Perfect Paradise instead of Perl/PHP/Python), I was lead to believe that scaling the code there is as simple as just about anywhere else and, of course, I’m pretty sure that none of the Dynamic Languages bar you from dropping into C when you need to bang something out that has to get done REALLY, REALLY, REALLY fast.
Is it just FUD that has caused fear of LAMP? I don’t know, I’ve never watched the Enterprise space closely.
comment at 17. July 2005
Assaph Mehr:
I would just like to add that the primary reasons why common runtime fails are social: take all these languages that have dedicated maintainers and followers. A significant portion of these followers prefer one over the other due to matters of taste. All these maintainers and followers have invested time and effort into creating libraries and evolving their own language. Now tell them that they all have to compromise on their favourite to allow constraints from that ‘other’ language.
Not gonna happen. I am not even sure it’s a good idea. Part of what makes these languages great, is the itch their creators have and their ability to scratch it. Creators experiment. Having a single, committee-controlled runtime will reduce their ability to experiment.
On the bright side, if you’re corporately-constrained to use one platform of the other, you can sneak in languages inspired by dynamic languages but designed for the platform of choice, like Boo or Groovy.
comment at 18. July 2005
Harry Fuecks:
For web applications, a question that springs to mind state is handled server-side, when riding on .NET or Java? Think David took the smart option by not being smart: http://www.loudthinking.com/arc/000479.html
comment at 19. July 2005
Ryan Tomayko:
Hi Harry. I’m not sure I understand the question exactly but I feel quite strongly that the shared nothing + caching proxy + memcached (when you absolutely need it) is a great way to ensure a LAMP/friends solution will scale to a competitive level. I’ve said as much before and taken quite a bit of heat for it.
comment at 19. July 2005
Bill Higgins:
I’m not sure about the “AMP” acceptance in the enterprise, but it’s common knowledge that the “L” is making some serious in-roads.
Some examples:
There’s actually quite a few case studies on IBM.com about enterprises partnering with IBM and using Linux to solve really hard technical problems, but since it’s not pure LAMP and because it’s a marketing web site, I won’t link to it here (though anyone who’s interested can email me for a link).
comment at 20. July 2005
Harry Fuecks:
What I was trying to ask was what’s the impact of running, say, IronPython under IIS and the .NET runtime, effectively meaning it’s running in an application server and that, potentially state can be stored in memory vs. something more C / Unixy where there’s some central process forking children to handle requests after which they die, leaving no traces? Perhaps it’s just a question of implementation detail and a question of choice of APIs / strategy for developers. Need to find out more from people who have tried it.
On that subject, another project to watch, also as a test for uptake: http://www.php-compiler.net/ - basically PHP for .NET. They seem to have done a very convincing job and they do seem to have simulated PHP’s maximum execution time limit.
comment at 20. July 2005
Ryan Tomayko:
Bill, I think I know you well enough to trust your intentions. Feel free to post links to your marketing material if you feel its valuable to the community - I’m not anti-commercial, I’m anti-bullshit/anti-fluff.
And thanks for stopping by.
comment at 21. July 2005
Chris Wine:
I also would like to see Bill’s link. I have written a long and wordy document about this topic, and in the interest of brevity (and some may say kindness), I will provide you with just a few bits.
I posted the rest of this monster to the main site. See The Dark Horse. — Ryan
comment at 21. July 2005
Ryan Tomayko:
Hi Chris. I’d like to post this as an entry so it gets more visibility. I’m just going to assume that’s okay with you but let
me know if you have a problem with that.
Do you have the longer version up on the web somewhere? I’d like to link to it.
comment at 21. July 2005
Kragen Sitaker:
Perry Lorier has some other arguments against VM envy:
http://coders.meta.net.nz/wordpress/archives/2004/09/20/vms-and-the-opensource-community/
Summary: “Why are the open source community wasting time on VMs when we can use the strength of our source to provide a superior solution?”
Hope to meet you at OSCON next week, Ryan — although now that you’ve been anointed the Server-Side Zeldman, you may be busy!
comment at 30. July 2005
Laurent Szyster:
“The real question for me becomes, when will LAMP/friends gain legitimacy as an “enterprise class” platform and how quickly will that force the industry to re-evaluate optimal deployment models?”
Legitimacy is not what will make Ruby or Python C VM get into that league of “entreprise class” development platform.
They allready are!
They have been playing in that league for a while now, disguised as Jython, bundled as a DLL, hidden inside large data processing centers, etc.
Trying to pose as J2EE, NET or another megaframework won’t help the LAMP/friends stack.
Zope, Ruby on Rail and others failed at that game. Because LAMP/friends don’t need to present a unified “do-all be-all” face to their “entreprise” adopters.
Corporate business, large public agencies and the public adopted the LAMP stack for its diversity … of defacto standard C implementations.
Twenty-four years ago, I was fourteen year old computer freak and at that time C was described as the portable “write once, run everywhere” language of the day, something to use instead of CPU specific assembler.
This has not changed.
Java failed to replace C as the defactor system programming language because it is not a language but a proprietary API (that began as a shameless copy of NextStep’s, may I remind you). Java was an attempt of Sun to suplant the Win32 API from within the browser, later recasted as a replacement of C++ for server and workstation application development.
You were not trolling when you described them as “legacy”. But they will stay around for a long time, pretending to be alive, like the ghost of COBOL, a cold body of millions of lines that nobody want to read again.
LAMP/friends allready made J2EE and NET obsolete.
Yet vendors will sell their scam as long as their customer “don’t get it”.
The shift will come slowly with the multiplication of niche competitors for J2EE and NET, built on the same stack as LAMP but dedicated to a specific field. Smaller frameworks, faster implementation with API more narrowly focused on what actually matters, what sells hardware and software: their applications.
comment at 27. September 2005
Ryan Tomayko:
Hi Laurent. You said:
That wasn’t what I was suggesting at all. Here’s my sentence as you quoted it:
I’m not suggesting (at all) that LAMP/friends need to change to look more like J2EE/.Net, I’m suggesting that the perception of “enterprise class” needs to change. I’m wondering when that will happen. I’ve been watching very closely as the perception has shifted over the past 12 months or so and the trend is only accelerating.
Basically, I’m waiting for the industry to understand the situation as you’ve described it. I’m in no way suggesting that LAMP needs to incorporate the brokeness of existing enterprise platforms. That would be complete folly.
comment at 27. September 2005