Pompous Statement

On twitter I posted the following tweet:

Quote me on this “Erlang will replace Java in the next 2 years as the standard for Enterprise Applications.”

A fair number of people were either outraged or excited by this statement, but one thing is sure people wanted to know my justification for this statement. I feel that it was deserving of a full blog post rather than a random assembly of 140 character messages.

A little background first, I have built many applications in a wide range of disciplines from Security Policy Management products to project management web applications and have coded in nearly all the “standard” set of languages. Programmers and their language selection is little more than a tool for management types to tout, blame, or confuse based on the situation and as such my statement is indeed controversial, especially since most programmers rarely get to pick the tool for the task, let alone the right tool.

I have been on both successful and unsuccessful projects and one thing is true, developers have a short period of time to accomplish something great before managers apply their “business savvy” to the mix and it all goes sour. This is why Ruby is seeing such a limelight at this point, because you can quickly get something out before the “others” have a chance to fark it up (trying to be PG). So without question, the quickness to a win is the key to success within the development community especially when you have any layer of management. Java, .Net, and even Ruby take a long time to develop an Enterprise solution because they are not designed for the inherent concepts of distributed computing, messaging, and even data persistence. They all farm out some other solution for these problems. If you code in Rails or merb, how often to you fire off a background process to do something that “needs special care”? If you code Java or .Net how many times are you dealing with an ORM because you need an enterprise database (SQL Server, Oracle, DB2)? Most of the time in Enterprise development is spent tricking the language into being enterprisy and globbing on often times incompatible technologies (relational != object) just because “it has to be that way”. When you break down Enterprise development, the key factors to it are:

• High Availability
• High Performance
• High Scalability
• Robustness of operation
• Perform a business function

Humorous Note – Check the wikipedia definition through the link and notice the foreboding message about the cost of development and the recommendation not to do it — awesome.

Java and .Net have been quibbling over the enterprise development stack for years decades and they were highly reliant on two basic assumption – processors in computers would continually get faster and memory would be abundant. Since 2002, individual processors have not improved at any rate to speak of so applications have gotten slower, not faster. It is important to note that due to the way threading and concurrency are handled in both languages, the application will only utilize a single processor, so even if there are eight (8) cores on the server, the “enterprise” application will only be using one of them, not exactly high performance. The other assumption about memory has been stifled due to the addressing constraints of a 32bit processor stack and the slow adoption of 64bit operating platforms that could facilitate higher memory utilization. Furthermore since the processors now have multiple cores, the are each assigned portions of the local and RAM cache banks, splitting the available address space reserved for any individual processing unit and reduce the overall available memory space for applications. Put on top of this that every enterprise application not only requires memory for itself but for an application container (tomcat, JBOSS, IIS, mongrel) and memory quickly becomes a contrained resource, despite its “commodization”.

So what is a programmer to do? Well if you follow the trends, you are probably hearing good things about “cloud computing” and the glorious abstractions that it provides you in order to work across an array of cheap computers that most times you never even see using some form of virtualization. This doesn’t solve the problem it just pushes the maintenance task to someone else and to be honest its a band-aid on the real problems. Cloud computing will not work in the long term because the systems inherently carry the problems with them because they are not addressed, they are “virtualized”. Yes the cost of setting up and tearing down an infrastructure is reduced, but to what gain? Are we programming better systems because of it? Are we producing faster, more efficient results? The answer is a dismal no. You are just adding an increased level of complexity that you do not have to understand in order to use and you are setting yourself up for a storm.

Note: In case its not obvious I do not recommend cloud computing solutions for a variety of reasons, not the least of which is the problematic security issues that never get resolved within the “cloud” where your information is available for anyone — umm yea, can you say honeypot?

So back to me being a pompous statement maker. In the next two years, you are going to see those “managers” start asking why these solutions are working, looking for the next buzzword. I say fark them. Developers need to make this next big change, it needs to be for the right reasons. We need to move to something like Erlang which uses a database, in Erlang, and a message queue, in Erlang, and a webserver, in Erlang, so we aren’t constantly looking for people to hire with an alphabet soup of qualifications. Enterprise software does not have to be complex. I repeat, enterprise software does not have to be complex it just requires doing it right. Going full circle on how to sell this to your organization is simple – make big wins fast. Erlang, Haskell, Clojure, and Lisp all allow you to do that, it just takes you being at least semi-knowledge about it. You can build a fully-distributed, blazing fast, fault tolerant processing engine that can be hot-updated in the field in an evening, that sure as hell beats a blog in ten (10) minutes in my book. This shift will allow software developers to finally utilize and maybe catch up to the advancements that hardware developers have been making. It will allow us to leverage computers in a way that we could never have imagined before due to remedial constraints from failed assumptions. Look you don’t have to believe me, Kevin Smith posted in his blog that “Erlang reminds me of Ruby during its early days” and then goes on to reference several enormous projects using Erlang with great success. Erlang has arguably already penetrated the enterprise and those companies using it have resoundingly had success with the language.

As for my statement, time will tell, but I am going to my darndest to make it happen.

About these ads