Wednesday, August 09, 2006

Secret Weapons for Startups

In Paul Graham's famous essay, Beating the Averages, he explains how his decision to use Lisp as the backend language for Viaweb helped Viaweb gain a critical competitive advantage, making it the first successful commerial web application. (This happened ages ago: in 1996!) According to Paul, Lisp's conciseness and expressiveness produced a rapid development cycle that helped Viaweb's platform outpace its competition in stability and features. This rewarded Viaweb's founders very generously, as they eventually sold Viaweb to Yahoo for $49 mil(!).

Here's a passage from Paul's essay describing the competitive advantage Lisp gave Viaweb:

What were the results of this experiment [using Lisp]? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn't have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.

It must have seemed to our competitors that we had some kind of secret weapon -- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.

One can learn a valuable lesson from Viaweb's story: the programming language(s) a startup chooses can have a decisive effect on its business success. Picking a language that fosters developer productivity is critical, because if your competitors use a more productive language, they would eventually have an advantage in the marketplace. In Viaweb, as well as Orbitz's case, Lisp has proven to be the winning language choice. Lisp's combination of power and obscurity has led Paul Graham to think of Lisp as a startup's secret weapon, so Viaweb has never advertised its use of Lisp, fearing Viaweb's competitors would adopt Lisp as well.

Viaweb has actually had another secret weapon that the essay doesn't discuss: great hackers. Viaweb's use of Lisp may have given it a productivity advantage, but even more important than the use of language is the skill of a company's hackers. I'm believe that in most cases, a team of good hackers can beat a team of average hackers even if the good team uses a less productive language.

The same holds even if the good team is smaller than the average team. In fact, the bigger the team, the more management and communications overhead tend to slow down development. Even worse, large teams sometimes become stratified bureaucracies in which hackers are regarded as mere implementors of a the suits' "vision." Depending on the industry, this can be a recipe for mediocrity if not outright failure. For an illustration, look at the rate at which Google, which has an agile, decentralized structure, churns out quality products and compare it to Microsoft's Vista nightmare.

I'd bet Paul and Robert Morris would have made Viaweb a success even if they had written it in a less productive language (maybe even C, which I sadly have to use at my day job) because they are top-notch hackers and because they ran a lean-and-mean, independent operation that gave free reign to their creativity and problem-solving finesse.

All else being equal, though, picking a great programming language can make a big difference for a startup. So, ignoring hackers' skills, what is a (web) startup's ultimate secret weapon? Well, I can't say I know for certain, but I do have some ideas :) Paul Graham thinks it's Lisp, and although I appreciate Lisp's clean syntax, dynamic typing, and great metaprogramming features, I can't say I like the way Lisp code looks (admittedly, the last time I touched Lisp was in college, so I may be oblivious to its wonders). I actually think that a startup's secret weapon arsenal boils down to the following:

  • If it's building an "ordinary" CRUD-based webapp and it has good or average hackers, it should go with Ruby on Rails or Python/Django. (haXe will be another appealing option in a few months.)

  • If it's building a CRUD-based app or a cutting-edge app that uses advanced Comet techniques like Meebo, and it has very good hackers who aren't scared of functional languages, it should go with Erlang.

(Update 8/17/06: Regarding haXe, I think haXe is an awesome language, especially for both Javascript and Flash development. The reason I said "in a few months" is because haXe/Neko, the server component of haXe, is not as feature rich as Rails -- yet. However, Nicolas Cannasse, haXe's creator, is moving it forward in a blazing speed. Keep that one on your radar, because with haXe you can actually write all aspects of a webapp in one great open source language. How's that for a secret weapon? :) )

Why would a startup need better hackers if it's using Erlang? After all, Erlang is actually a very simple language -- simpler than Ruby. There are two reasons:

  • Erlang is a dynamically-typed functional language, which apparently doesn't fit well into developer brains that are conditioned into thinking in Java. Sadly, this is the general case these days.

  • Erlang doesn't have as many web development libraries as Rails or Django, so the hackers would need the courage to roll up their sleeves and write their own framework-level code. (Yaws, "The" Erlang webserver, does have some good web development APIs, but not as many as Rails.)

In time, Erlang will have better web development tools. When it happens, I predict that Erlang will become the ultimate startup secret weapon. Why? Because Erlang is a better language than Ruby/Python, especially for building concurrent, distributed applications with scalable, highly-available backends, where Erlang is years ahead of any other language. Even if, hypothetically, the initial development would be somewhat slower with Erlang, Erlang is best positioned to prevent a startup's developers from turning into full-time sysadmins/optimizers once the app becomes popular. This is important because they can spend their time developing new features that give the startup a competitive advantage.

Erlang will get there sooner than you may realize. Stay tuned.


Roberto said...

Great post. After a couple of weeks with Erlang (thanks to you, before, all I knew whas that Erlang was a kind of measurement unit for telephony traffic) I feel now comfortable with functional programming and it really let's you do things which would't be possible otherwise, you will see soon ...

Rickard said...

I think your blog is about to get very popular. Keep up the entries. One question: is there a SICP for Erlang or a kick ass Erlang tutorial to get newbies started? What's a good path to become enlightened with Erlang without your head exploding? I think lots of people will start asking this question.

Frank said...

Erlang's features don't really help web programmers. Okay, they help you in building a web server, or a database server, or anything that needs lots of processes, but that's not what web programmers do. They write simple, lienar code that interact with a web server, database, and templates. Web programmers would never touch Erlang's concurrency primitives.

Therefore, there is no reason for Erlang to gain hold in the web programming market: It's just another programming language with nothing unique from a web developers viewpoint.

This doesn't mean that Erlang can't become popular. It just won't happen in the web programming world.

Yariv said...

Richard, you can read my previous posting titled "The Hitchhiker's Guide to Erlang" for some pointers on where to start.

Frank -- you're missing out on one important point: Yaws, The Erlang webserver, already uses Erlang's concurrency primitives, which gives web developers a free ride as far as lightweight concurrency is concerned.

Another point to keep in mind is that Erlang has many other great features from the functional programming world, such as list comprehensions, higher-order functions, single-assignment, hot code swapping (this is unique to Erlang), etc. etc. You can read my previous postings about Erlang but keep in mind that they just scratch the surface.

Frank said...

No, I'm not missing Yaws. I'm saying that from the web programmers point of view, Yaws, or Apache, or aolserver, or Lighttpd, or thttpd, or whatever the web server is simply doesn't matter. What matters is if they can write their code easier.

Does Erlang offer anything that allows them to write their code easier? Beyond what any other functional language provides, the answer is no. It's a big no if we take into consideration that Erlang doesn't have any of the libraries Perl, PHP, Python, or Ruby has -- but, in time, those would surface, so we'll ignore that.

Even hot-swapping of code is useless to a web programmer since web programmers use scripts, which can be hot-swapped regardless of language.

Don't get me wrong, I love Erlang. Been playing around with it for years and wish I could use it on a 'real' project. But for web programming, Erlang is not the right tool for the job (not that I know what is the right tool).

Frank said...

Grr. Off-topic: I'm annoyed this commenting system removes paragraphs.

Yariv said...

Yes, I know. The comments are annoying. Blame Ruby on Rails :) About Erlang, I have found that Erlang makes me very productive -- more so than Ruby and other languages. I think when Erlang has more web development libraries, it will be a highly productive web language. Also, it's not about Erlang being "the" right tool or not. Erlang is just another alternative for web developers, some of whom would prefer it to other languages because it offers capabilities that other languages don't. But ultimately, it's also a matter of taste and comfort. I'm not suggesting that Erlang is for everyone.

Jason said...

Hi Yariv, Frank,

I would hope that the programming language itself becomes a lesser consideration than the deployment platform.
Last year I wrote a very simple proof of concept code translator that allowed me to convert a small PHP script to lua. The subset of PHP functions used were replaced with inline lua equivalents and the entire exercise took just one afternoon.

I am very interested in experimenting with code translation targetting neko and erlang. Franks 'simple linear template language' is something that we can create very easily using tools like NekoML.

Yariv said...

Jason, I think that in Erlang's case, the runtime and the language play together very closely to support Erlang's scalability, lightweight concurrency, and message passing semantics. I think it would be very difficult if not impossible to map a language like PHP or haXe unto the Erlang VM, but one should never say 'never' :)

Frank said...

It seems my point is still being missed. It isn't whether Erlang can be used for web development -- it can. But, doing so doesn't allow you to take advantage of any of Erlang's semi-unique features, such as concurrency and its bit-syntax. In other words, you don't gain over PHP/Python/Perl/Ruby/Java/whatever-is-hip by using Erlang in the web development realm.

Yariv said...

Frank, it depends on what you mean by "take advantage". Yaws, for instance, devotes one lightweight Erlang process per each incoming connection. What does this mean? It means that just by using Yaws, and without ever explicitly using Erlang's spawning and message passing, you are already benefitting from Erlang's concurrency by easily being able to support tens of thousands of simultaneous connections on one box. Google "yaws apache" and you'll see what I mean. In addition, as many functional programmers would say, Erlang's combination of dynamic typing and pure functional programming semantics *do* promote greater productivity than PHP/Python/whatever. So even without all the nifty concurrency and scalability stuff, many people would still prefer Erlang to the "standard" array of web languages.

Frank said...

You're still ignoring the point: There's no reason for a web developer to learn Erlang over, say, Ruby, as all of Erlang's advanced features are useless to him. It doesn't matter whether Yaws uses the concurrency primitives: The prorgammer doesn't. Therefore, why should he learn Erlang? Whereas learning Ruby would give him access to all the nifty features of Ruby on Rails.

"Many people would still prefer Erlang to the standard array of web languages" -- If that were true, it would be popular in the web-dev world.

Yariv said...

I said "many people," not "most people." Many Erlang hackers would prefer Erlang to Rails, but that doesn't mean that Erlang is popular among the web developer community at large.

How did Ruby on Rails come about? AFAIK, that 37 Signals hacker -- I forget his name -- created Rails because he liked the Ruby language and he thought it made him more productive than, say, PHP or Java. So, there are basically 2 types of hackers -- those that use frameworks and those that create them. For a developer who only uses frameworks, yes, it makes more sense to go with Rails because it has a richer set of APIs than Yaws. However, for a developer who can also create of frameworks, Erlang would be appealing because it's is a far more powerful language than Ruby.

Just like the creator of Rails, many web developers wouldn't be intimidated by Erlang's fewer web development APIs. And when those APIs are created by framework hackers, even "regular" web developers may be attracted to Erlang.

Yariv said..., I don't think it's accurate to say that web developers -- even Ruby ones -- don't need good concurrency capabilities from the language. Check out BackgrounDrb, which isn't nearly as beautiful and scalable as Erlang-style concurrency.

roberthahn said...

I think I can see wherer Frank was going with his questions, and, like him, I'm having trouble with your responses, Yariv. However, I know nothing about Erlang. So how about I try asking the question a different way?

When I build web based applications, I'm cognizant of the environment I'm working in -- it's a stateless, request/response system. For *most* kinds of apps, this is absolutely perfect. I send all my state data in each request (whether it's a simple GET for a resource, or a POST with lots of field data), the server processes it, and that's it. As far as the web server's concerned, it has no memory of a string of similar or identical resources - each time is like a first time.

So, to my thinking, yeah, with a popular app you'll likely see thousands of concurrent hits per second, but each hit is completely independent of any others, but any well tuned server will be able to handle that just fine.

Ok, so YAWS is this web server. I know nothing about it, so i'll assume it's going to be pretty much like Apache or lighttpd - it'll serve web pages, and enable me to run scripts; it'll probably help with load balancing, or proxying, or caching. I can get that. It is, after all, Yet Another Web Server.

What I, and maybe Frank, don't really understand is this: in an environment of stateless requests, what does Erlang buy you exactly? YAWS doesn't appear to do anything that any other web server can't do, from what I see. If concurrency is important, well, i'll just configure Apache to prefork a few more listeners, see? (assuming i use Apache of course)

What I would look for in building web apps would probably include: an easy way of dispatching requests to chunks of code; an easy way to pull data from a source (be it an RDB or a file or a BDB)); an easy way to process that data (regex's, or SOAP packet generators, or anything that depends on either the language itself or a healthy library) and an easy way to print that data back to the client. For some of my more complicated apps, some method or process to preserve state may be needed (ie: i'm talking sessioning here), but it's simplly not going to be needed most of the time.

Are you saying that Erlang can give me all those things significantly easier than Ruby or Python? From what I've read, Erlang seems to be great for building *stateful* apps, but what I'm not seeing is how it can be so much better at building *stateless* apps, and by far most of the apps being built today are (I sincerely hope) stateless.

I suspect the answer is complicated, but I hope you'll be able to write a post or two comparing/contrasting traditional cgi development to the Erlang way of doing things. I think that would answer a lot of questions.

Yariv said...

Hi Robert, that's a great question. I'll let the full answer brew in my head before I write a full post about this, but I'll give you a short response for now: webapps are changing. XMLHttpRequest has opened new possibilities for web developers. As Meebo has show, with XMLHttpRequest, your app doesn't have to be stateless anymore. I think Meebo is just the first (AFAIK) in a long line of webapps that will bring dynamic, stateful interactivity to webapps. What backend tools are by far the best options for building such webapps? Erlang + Yaws.

However, forgetting Comet for a second, Erlang + Yaws still gives you a lot because Erlang is a very good language. It's dynamic, functional, fun and highly productive. It's much better than Ruby. I've been coding in Erlang for a while, and the thought of using any other language (except for Lisp maybe) makes me cringe.

For data storage and retrieval,, Erlang is ideal. You can store any Erlang term in Mnesia, which is ACID transactional (if you want it to be).

I'll think of a more complete answer and will probably blog about it in a few days.

Thanks for the feedback,

Yariv said...

I should probably mention this again: even for stateless apps, Erlang is a *really* good language. Its functional, dynamic, yet compiled nature is much stronger than Ruby and Python, which have scripting/OOP roots. Erlang is just a joy to work with. I used to do Java development in Eclipse and C++ development in XCode, and now all I want is my Erlang shell and Emacs. Ericsson's greatest PR bluder is failing to explain to programmers that Erlang coding is a lot of fun. :)

Yariv said...

Check out my latest posting for a more complete answer.

anon said...

Hot code swapping is not limited to Erlang: Smalltalk has been able to do it since the 70s or early 80s.

namehere said...

Don't compare google and MS's products. In quick order, MS came up with a perfectly good copy of google maps ( How long would it make google to remake XP? I mean, even with their crack calendar team on the job, I'm guessing it would be a while.

Shanti said...

Yariv - we're having some trouble converting a Ruby script into a BackgroundDrb worker.

I know this isn't really the place to mention it but apparently it's overruning the database with repeated requests.

Learning Lisp (or Erlang) has been on my todo list for a while. Thanks for the reminder!

Byron said...

namehere, Google wouldn't remake XP with all its backward compatibility cruft, but would using a highly modified Linux kernel to build world's largest, most powerful parallel supercomputer suffice?

Yariv said...

Namehere -- I admittedly don't have insider-level perspective on the issue, but from the articles I read, it sounds like the Vista development structure is much more bureaucratic than Google. I'm not talking about all Microsoft products -- just Vista. I think Microsoft is doing some great work and that Microsoft's web initiatives are promising, albeit somewhat belated. I'm not writing Microsoft off -- I'm just saying that Google's structure seems much more agile.

Yariv said...

Anon -- yes I know that Erlang isn't the only language that has hot code swapping, and although I haven't used Smalltalk, I heard people rave about it. I just think that Smalltalk and Erlang target totally different applications. Erlang is specifically suited for applications that require massive concurrency and scalability, which Smalltalk doesn't AFAIK.