Ikai Lan says

I say things!

Twitter, Ruby on Rails, Scala and people who don’t RTFA

with 34 comments

The Register recently published an article titled, “Twitter jilts Ruby for Scala“, prompting a wave of Tweets (Twitter messages for the jargon challenged) about Ruby on Rails and scaling. More specifically, its lack of ability to do do. The source of this article was a talk given by the API lead at Twitter, Alex Payne, at the Web 2.0 Expo in San Francisco, where he discussed porting parts of Twitter from Ruby to Scala. Naturally, the armchair commentators added their two cents about the message, taking it to mean that Scala is *the* one true language for internet companies, and that Ruby on Rails should not be used because it cannot scale.

I tweeted about my annoyance with retweeters that don’t understand what they are retweeting, and Alex responded: “It’s really frustrating for me. I don’t think the people who were there for my talk got that impression. The press skewed it.”

Alex wasn’t saying that Rails can’t scale. Alex was saying that he really likes Scala, and parts of Twitter that were written in Ruby were rewritten in Scala because some tasks are simply not appropriate for Ruby. I know of Kestrel, their messaging queue, but likely there are other middleware layers that sit between their APIs/web interfaces and their data sources that are being ported.

Now, Scala is an amazing language. It compiles to JVM bytecode, and thus, most procedures will run near or at the speed of Java. Functions can be treated as first class objects and passed around like variables. Its system of type inference means less ceremony for simply declaring variables. Traits function remarkably like mixins in dynamic languages, allowing very rich composite classes that, in many cases, need to add very little boilerplate for the composition, unlike Java interfaces. And pattern matching with wildcards? I can’t even think of an analogy for how powerful of a tool this is. Is it the best compiled language? Some think so, and I can certainly see where they are coming from. I’m learning Scala as we speak. The basics were pretty easy to pick up, but I’m still struggling to be good with it. Scala best practices such as programming in an immutable style are far easier to preach than to actual do.

But Scala is not Ruby, and will never be Ruby. Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages. It can do this because any class or object can be extended, any method overridden, any constant undefined and redefined, and so on, and so forth. You can take an Integer and declare more methods on it. Duck typing means that you don’t have to set up boilerplate interfaces and abstract classes to create objects that can replace other objects with similar interfaces. A web development platform as powerful and syntactically concise as Rails could only have been done in Ruby. Imagine this: a developer looks at a model file representing a database table, and immediately understands the business rules regarding validity as well as the callbacks that will take place when the object is created, updated or destroyed. Or this: it is possible to create a plugin that extends collections objects to allow very complex pagination, and a client developer only has to include a file or remove the include statement. This plugin recognizes if the collection in question maps to a database, and if so, applies LIMIT and OFFSET statements to SQL queries as to not eagerly load too many objects at once. This plugin exists.

This power does not come without a price. Ruby is slow. Ruby is generally recognized as being twice as slow as Python, and at least an order of magnitude slower than C++ or Java. Charles Nutter, one of the creators of the JRuby VM for the Ruby language, recently posted an article about optimizations that could be made to the VM, and he improves Ruby performance by as much as twenty times by removing much of Ruby’s power and breaking compatibility. If anything, it shows us skeptics that there is no such thing as a free lunch.

So if Ruby is slow, and Rails uses Ruby, does that mean Rails cannot scale? Let me make this clear right now: Though Ruby is slow, this does not mean that Rails does not scale. Scalability is a very difficult concept, often oversimplified to be synonymous with efficiency. Efficiency is a facet of scalability, yes, but it is not its only dimension. Reliability and uptime are very important dimensions of a scalable system. So is horizontal scalability: the ability to serve an increase in usage with a corresponding increase in computational nodes. Though it may seem like a given that throwing hardware at a problem will increase capacity, this simply isn’t so. Anybody that has worked on a large data driven application will tell you that a centralized, authoritative source such as a database cluster is a bottleneck, and simply throwing hardware at the problem results in diminishing marginal returns. Then there is quality of service. A truly scalable architecture will have minimal service degradation as users and usage exponentially increase.

I use the word “architecture” because a truly scalable system that meets the requirements set by its intended consumer is rarely, if ever, about a single component. Even if we were just talking about speed and none of the other dimensions of scalability, there’s a great article by Joe Stump where he calls out language critics about this exact subject. C++ can probably assemble HTML at least a hundred times faster than Ruby, but this has minimal impact on what a user sees because disk reads are slow, talking to a data source is slow, and sending data over the internet is *really* slow. On top of all that, Steve Souders, creator of YSlow, a popular tool for benchmarking perceived speed of web sites, argues that for most sites, 90% of the wait time a user has to put up with is a result of loading assets, JavaScript and stylesheets. Rails and proper database constraints can ensure data integrity (reliability). Rails is by default stateless and sessions can be centralized (fault tolerance and horizontal scalability), check. Rails can scale, and does scale. Twitter is not replacing their web tier because it is fast enough, and they have focused on optimizing their middle tier, which sits between their web layer and their data layer. There’s no point in replacing this layer. Its performance and reliability are completely bound by the data and middleware layers.

This is where Scala enters the picture: middleware. Likely this refers to a non-RDBMS datasource serving denormalized social graph, a dispatching component for pushing messages through SMS and email, a queue and queue workers. There are a few requirements here: concurrency and computational speed, both of which are areas where Ruby falls flat because MRI Ruby, the stock VM, uses green threads which block on I/O and do not make use of multicore processors. In addition, Ruby’s memory requirements are aggressive. Scala, on the other hand, is fast and can is as concurrent as the JVM will allow, which is pretty damned concurrent.

So what Twitter did was optimize the bottleneck and leave their investment in the front-end intact. This shouldn’t surprise anybody. Facebook started out on PHP, but now their backend is an amalgam of C/C++, Erlang and other languages. Google runs Java and C++ for their backend, but I’m told several web tier services are written in Python. And so forth. This doesn’t mean don’t use Python, and don’t use PHP. It just means to be ready to optimize and possibly to replace those components when the time is right, which, for many startups, is a LOOOOOOONG way off.

In fact, I still push Ruby on Rails as the development platform of choice for web startups launching a 1.0. Why? There are many reasons. Here are a few:

  • You will hit the ground running fast, and you will have something working within a single development cycle. If your application has any kind of boilerplate, like user management, pagination, multiformat output, simple AJAX or CRUD functionality, Rails just saved you from having to write most of it.
  • Onboarding developers is fast. I’ve been on projects where new developers have been able to be productive the first or second day of looking at a project’s structure and tests
  • Rails emphasizes the importance of test driving development, and any good Rails developer will feel wrong writing code without corresponding tests – when I started Scala, I settled on the NetBeans IDE because it seemed like the easiest to get going with JUnit
  • Solving scalability problems too early is a bad idea. Nobody starts out with a sharded database. Instead of building features or attracting customers to a usable product, you spend your time building an incredibly complex system that will scale but at severe opportunity cost if it hits the market late. You want scalability problems, because it means you are growing too fast. In the words of The Wire’s Marlo Stanfield, “that sound like one of them good problems.”

– Ikai

Written by Ikai Lan

April 2, 2009 at 9:58 pm

Posted in Ruby on Rails, Scalability

Tagged with , ,

34 Responses

Subscribe to comments with RSS.

  1. Ruby’s DSL capabilities are nice. However, Scala provides equally strong DSL support, albeit without open classes. Instead, Scala implicits, parser combinators, and operator notation do the trick nicely. There is nothing like Ruby for getting a Ruby-flavored DSL up and running, but Scala will give you a wider range of DSL forms. Take a look at my BASIC DSL written in Scala… could that be done in Ruby? (not trying to be facetious; I really do not know)




    April 3, 2009 at 3:59 am

  2. You say.

    “Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages.”

    and later “This power does not come without a price. Ruby is slow. ”

    Really, one has very little to do with the other.

    The (multiple) lisps, forths (and these days, factor) and even haskell are all arguably more “powerful” than Ruby at creating domain specific dsls and plenty fast (as compared to ruby), with some of them generating very optimized machine code.

    The slowness of Ruby has more to do with its (ast walking) interpreter’s (as of Ruby 1.8) design and implementation than any “ability to create DSLs”. JRuby has the same(more or less) semantics and was faster than “native” Ruby the last time I checked.

    my 2 cents. fwiw.

    Ravi Mohan

    April 3, 2009 at 5:20 am

  3. Nice post. I was quite surprised with some of the press that came out after Alex’s talk. I suppose turning his presentation into a “Rails sucks, use Scala for everything” talk gets more eye balls for the sites posting such non-sense, but as you correctly point out that wasn’t at all the point of his talk. I wasn’t there to hear/see it but it’s clear to me that his point was that you should use the right tool for the job, and Scala is something you should check out because it very well might be the right tool for the job you have at hand.

    Anyway, nice post! :)
    ~ Steve


    April 3, 2009 at 5:22 am

  4. I agree wholeheartedly with you, but I have a small nitpick. Ruby *1.8* is VERY slow. On the other hand, the recently released Ruby 1.9 is actually faster than Python 3.0, Perl, and PHP (graph here: http://skitch.com/wycats/bkkwh/scotland09).

    So while this criticism is widely true now, as Rubyists move over to 1.9, there is one less reason to use something because it’s “faster.”

    Jeremy McAnally

    April 3, 2009 at 6:10 am

  5. Excellent post!
    I loved reading what I was thinking. :)


    April 3, 2009 at 6:55 am

  6. “Though Ruby is slow, this does not mean that Rails does not scale.”

    There are two aspects to scaling. Ability to scale, and cost to scale. I’m puzzled that the webosphere only talks about the first one (I know hardware is cheap yadda yadda yadda).

    But when you’re growing as fast as Twitter, it really makes a difference in money (and TCO).

    My 2c on the get tracktion fast: When you need to be fast to impress a VC, I would use Grails and after I’ve got the money change to Scala for the future.


    Stephan Schmidt

    April 3, 2009 at 7:06 am

  7. Long live perl!


    April 3, 2009 at 7:27 am

  8. Great post. I attended the talk as well and really enjoyed it. My team uses Ruby and Rails heavily. It is not that I am looking to replace anything, although I am open to any change, but the message for me from the presentation was Scala would be a a great tool to add to our toolkit.

    Scott B

    April 3, 2009 at 7:49 am

  9. But, didn’t Twitter manage to scale to where it has by effectively cutting out the Rails part with extensive query caching? It’s all very well saying that it’s not Rails that bottlenecks, but if Rails does things that cause more bottlenecks elsewhere than is absolutely necessary to get the job done, then it has a scalability problem.

    Long story short:
    – Rails = Fail-whale in heavy traffic.
    – Skipping most of Rails = No fail-whale in heavy traffic.

    That, in any sensible definition, is a scalability problem.


    April 3, 2009 at 7:58 am

  10. Thanks for the comments, everyone. I have a few responses to all of your comments:

    Jeremy, I’ve seen that graph too, but it’s not that useful without context. From what I remember, it was a single threaded process. What were the algorithms being run? What’s the memory footprint? Etc. I’m sure Yehuda didn’t just leave the graph as is, but I haven’t been able to find a corresponding document or presentation describing the benchmarking process.

    Stephan, I’ve also used Groovy on Grails. Extensive parts of LinkedIn are built using Grails. Our experience has been that Grails has better Java support than JRuby and that building in Grails is much easier and faster than building in Java. However, Groovy has the same speed problems as Ruby in that it is still an order of magnitude slower than Java. While you do get the benefit of easier Java integration if and when you need it (JRuby has come a LONG way, though … ), the Grails community is much smaller. It’s harder to hire someone that really knows Grails – the pattern we’ve seen is to hire someone who knows Java, and train them. If you have Java people and need to start a new project, however, it may be the way to go. On your point of cost of scaling – it depends on your project. A media heavy but computationally cheap project will pay the bulk of cost in bandwidth and not servers, for instance. The cost of development should not be ignored. The same project that can be written in 3 Rails man months could cost several times more if you can’t find people to work on it.

    Grunties, Rails is a big hammer. It is a comprehensive development environment that consists of many of the pieces needed to build a web application. In my very honest opinion, the fact that the standard is to use an RDBMS to persist object oriented data is inherently flawed in many use cases, and any framework that uses an ORM rather than a self rolled data access layer will bottleneck at the data source. It’s an oversimplification to say that this is all a result of Ruby on Rails. I read somewhere that much of Twitter’s data is denormalized, for instance. Does that mean all projects that expect to scale need to denormalize from the start? Hell no! Do cross table joins cause scalability problems? At some point, yes, when you need data federation, or if the number of joins is incredibly high. I wouldn’t make the statement that MySQL has a scalability problem. It is not a scalability problem until it IS a scalability problem. Rails lets you hit the ground running, and in my experience, it’s a long time before applications start to need to start swapping out components.

    Ikai Lan

    April 3, 2009 at 8:46 am

  11. @grunties – This is the exact kind of ignorant attitude that the article is trying to dispel. Rails does not scale or not scale. Architectures scale. If Twitter had had the same architecture written in Java they would have hit the same ceiling, which was based on the fact that they were using a relational database rather than message queues. The process of scaling is about removing bottlenecks and (eventually) making everything parallelizable.

    There is nothing inherent in Rails either to prevent or to provide scalability. It simply uses a share-nothing architecture where you can keep adding app servers without any problems. There is no technology that will automatically make you scale. To design a scalable architecture first requires a very precise definition of what you are doing–which early startups should not have until they actually start to see some traction–then it needs to be tested and refined under real world loads. No two scalable architectures look the same. There are principles but no cookbooks.

    The whole “Rails doesn’t scale” meme seems to be coming from people who don’t use Rails and are just looking for a justification not to leave their comfort zones in Java or PHP land. Any actual Rails developer will tell you that the pain points in Rails are really more with the sorry state of the Ruby virtual machines, memory leaks and threads. Those things may provide a reason not to write a high-performance component in Ruby, but that does not mean “Rails doesn’t scale” any more than using a relational database means “Java doesn’t scale” or that running a single-threaded process means “Assembly doesn’t scale”.

    Gabe da Silveira

    April 3, 2009 at 9:21 am

  12. Hello, thanks for you long reply,

    ” The same project that can be written in 3 Rails man months could cost several times more if you can’t find people to work on it.”

    Perhaps I’m expecting too much, but from a good developer I’m expecting that he can write Grails code in one week and be good enough in a month at most[1]. It’s really not rocket science. Might not be the best code but should be working – either if he’s coming from Java or Rails.


    [1] And get an expert consultant for the tough stuff like tuning the GC, JVM, caching etc.

    Stephan Schmidt

    April 3, 2009 at 11:30 am

  13. You write: “Alex was saying that he really likes Scala”

    I have a problem with Alex liking anything. He shrugs off responsibility for not testing his site before deploying it. Instead of BSing us, he should confess he didn’t do his homework on picking the right framework in the first place, or admit that he didn’t know that the hell he was doing before he deployed Twitter. Instead of using empirical evidence for picking the framework to do the job, he picks Rails, the hip framework at the time. Now he’s sweet on Scala (like he was once sweet on Rails).

    In any case, why give this Alex any credence?


    April 3, 2009 at 11:41 am

  14. “But Scala is not Ruby, and will never be Ruby. Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages.”

    This (and the rest of the article) is just ignorant cheerleading — a brazen attempt to justify Ruby’s lackings and thus resolve your cognitive dissonance.

    Craig C. Kip

    April 3, 2009 at 12:09 pm

  15. This is a very nice write up. Like you mentioned, most people have the wrong perception about what it means to scale or how.

    The true keys to scaling is being stateless and asynchronous when possible. Sounds simple enough right? That’s where things like transactions and if a request spans multiple pages.

    Another thing that I often find interesting is most people don’t believe you can be asynchronous, but guarantee the delivery of the message. That’s an easy to solve problem. What’s not an easy to solve problem is ordering in an asynchronous system that’s clustered.

    Read over the Kestrel source code. I’ve been reading over it and actually making code changes to it for fun to learn about it.

    Richard L. Burton III

    Richard L. Burton III

    April 3, 2009 at 12:48 pm

  16. To play devils advocate, al3x has made some snarky comments about ruby and the ruby community, so it’s not exactly a stretch to cast his talk as anti-ruby. That said, I don’t think it’s an interesting thing to talk about, and I have mad respect for al3x otherwise.

    “MRI Ruby, the stock VM, uses green threads which block on I/O and do not make use of multicore processors.”

    Ruby uses select under the hood, so while individual threads block, the interpreter as a whole does not block on any particular io. This was a reasonable 80/20 step vs full N:M threads in the interpreter in the pentium era, however now it’s a big limitation.

    “There are two aspects to scaling. Ability to scale, and cost to scale. I’m puzzled that the webosphere only talks about the first one (I know hardware is cheap yadda yadda yadda).” This is a good point, and one of the few realistic scaling criticisms of rails. Rails scales similar to PHP, it just uses a whole lot more ram to do so. I think the reason people discount the per server efficiency aspect is because basic servers cost ~$100 a month (3 year amortization) while developers cost 50-100x that. Even cutting development time by modest amounts lets you afford a ton of servers.

    That said, I also believe it’s also a false dilemma: the trend is towards developing frameworks that preserve productivity gains while not being quite so inefficient.

    Jason Watkins

    April 3, 2009 at 4:14 pm

  17. I asked this on reddit as well but, did they take a look at erlang for their queueing?

    John Bender

    April 3, 2009 at 4:51 pm

  18. > Instead of BSing us, he should confess he didn’t do his homework on picking the right framework in the first place, or admit that he didn’t know that the hell he was doing before he deployed Twitter.

    Jose: how could you possible expect someone to “know what they were doing before they deploy Twitter”? Nobody’s ever built anything quite like that before, so it’s ridiculous to expect that someone could come in with all the right answers.

    Hindsight is 20/20. Let’s see you try to create an entirely new genre of web application and make all the right choices up front.


    April 3, 2009 at 4:54 pm

  19. @ikai The benchmarks are the single-core results for the default combined score on the Alioth shootout. I use those results for a few reasons:

    * Multicore results aren’t fair, because some languages make full use of all cores in the tests, and some use a single core. Ruby architectures use multiple processes to utilize multiple cores, so doing a multiprocess (via fork?) setup for Ruby (taking memory usage into consideration) would be required for an apples-to-apples comparison.

    * Nobody claims that the Alioth shootout benches are biased towards Ruby. In fact, they have been frequently used to show Ruby (1.8) as extremely slow. As a result, significant improvements against Python, Perl, or PHP should be taken more seriously than an ad-hoc bench I put together myself.

    I personally highlight these benches to show that people should refresh their FUD talking points once in a while to see if they’re still true. “Ruby is ridiculously slow” is still trotted out in every discussion or Ruby vs. other languages, and I suspect it will be for some time to come. It was never a very good argument to begin with (the Shootout is not representative of framework performance in the real world at all), but even that argument is closing in on retirement age.

    Yehuda Katz

    April 3, 2009 at 9:25 pm

  20. @Phil

    My point is precisely that Twitter is an outlier. I don’t expect to write the next Twitter and Rails will serve most web applications well.

    But Alex now is starting another fad with Scala. That will be great until the unseen ragged edges of Scala emerge and then, by his track record, he’ll jettison it to plug another fad.

    He could have optimized using C, a common practice in Ruby. I don’t think anything would have been faster.


    April 4, 2009 at 3:09 pm

  21. my language is better than your language….it’s never ending .

    why don’t we have experts in Ruby/Jruby and Scala have a shoot out ? get each side to write the same app and compare them on every metrics aspect ? let them show us what their language can do and the loser will have to shut up once for all about the virtues of his language..

    I don’t think it would be that hard to get a sponsor to host the event. think about all the derived advertising that could offset the coss.


    April 5, 2009 at 9:12 am

  22. @ yayoo (above me)

    That will not solve anything, it will be simply: who was the better skilled/inspired programer (at the time). Other things that won’t solve anything would be writing the same code (obviously not every language works the same).

    > article: “Scala best practices such as programming in an immutable style are far easier to preach than to actual do.”

    Hehe… that’s what you should be doing in Java, at least if you take things like the String class as “good example”; and your application is heavily network based (since well, java has come a long way).


    April 5, 2009 at 3:29 pm

  23. great post! i agreed with you mostly.

    maybe except just one thing. scala with its implicit conventions, by-name parameters, higher-order functions is really great for creating dsl’s too.

    take a look at specs[1] and apache camel[2].

    1: http://code.google.com/p/specs/
    2: http://camel.apache.org/


    April 7, 2009 at 4:38 am

  24. @Yehuda Katz > The benchmarks are the single-core results for the default combined score on the Alioth shootout

    On the benchmarks game we can now see the range of measurements not just a single number.


    @Yehuda Katz > doing a multiprocess (via fork?)

    Just like some of the PHP programs now do?


    Isaac Gouy

    April 10, 2009 at 10:55 am

  25. check out macruby – it’s a ruby implemented created by apple on top of the os x objective-c runtime, garbage collector, etc, and based on the 1.9 version. might have interesting implications for long-lived processes?

    emil tin

    April 13, 2009 at 2:14 pm

  26. “Ruby is probably the most powerful programming language on the planet for creating DSLs, or domain specific languages.” Hah! When you learn more scala you’ll realize that Scala provides a much safer way to create DSLs using implicit, as opposed to Ruby’s open classes. Plus internal and external DSLs are easy in Scala.


    June 4, 2009 at 5:19 am

  27. Hi Ikai,

    After reading many articles on Twitter-Ruby-Scala issue, I summarize the comments as pro Ruby and con Ruby type.

    Pro Ruby
    Most commenters wrote that Ruby on Rails does scale well and Alex could have done a survey for an open source tool for doing multithreading type operations and integrate it with RoR/Ruby

    Con Ruby
    Alex as well as any one could have been carried away by RoR capabilities without assuming that Twitter needs more. When situation comes, any project leader would have done the same thing i.e., write essential parts in another language rather than scratch head on the dull capacities of Ruby



    July 29, 2009 at 3:27 am

  28. This was a really insightful article. A lot of points noted. Thanks a lot.

    Y. Kamesh Rao

    December 31, 2009 at 10:38 pm

  29. There is obviously a lot to know about this. I think you made some good points in Features also.

    twitter trends api

    February 5, 2010 at 12:33 pm

  30. Hey Ruby folks. You should learn a little about the strengths of the other languages. Both Scala and Erlang have light threading and messaging architecture enabling above 10.000 concurrent connections. I think Erlang is stongest there. The functional paradigm enables high concurrency. Scala has the actor/model built in and was designed by the person that developed the first java compiler. It was made to scale.

    Ruby can scale well, maybe… but was it created with massive concurrency in mind? Don´t think so.

    How can you compete against the JVM with a dynamic language?

    Still one can debate all night long if one really needs this performance if one can just add one more box, but then you are missing out on the point.

    Arne Bjarne

    March 11, 2010 at 2:13 pm

  31. It’s been a little while, so commenting might even be out of place, but talk of much ado ;-).

    Alex had an unusual problem to solve, and picked a good tool for the job – a statically typed compiled language that’s almost as succinct as Ruby, and significantly more expressive.

    Ruby and Rails are both great – they lowered the gauntlet on just how little effort things should require to develop. A significant number of projects saw light of day with less pain, and lived happily ever after.

    On the technical merits, however, there’s no contest between a dynamically typed language and a statically typed one – they are in fundamentally different performance classes.

    Rails is becoming less of an issue as well. Lift (liftweb.net) is already at 2.0. It’s just as tight-lipped as Rails, and easily outdoes it in security, Comet support, maintainability, and indeed suitability for web development altogether – web isn’t really an MVC environment, after all.

    Anyway, to cut a longish rant short, it pays to dig below top soil. If you wish to have an opinion on comparative suitability of Ruby/Rails and Scala/Lift, get good at both, then compare. If Scala’s type system wrecks your brain initially (like it wrecked Steve Yegge’s, poor guy), consider it a mental fitness routine. :-)

    Alex Zuzin

    August 22, 2010 at 8:08 pm

  32. Hi there. I came across your blog because i’m currently having to build a web app for somebody I know, so i’m googling random terms and got here. I’m a kernel programmer who does math, and rarely have anything to do with the web, so please don’t shoot me down if I’m mistunderstanding this..

    The only comment I wish to make is about your DSL comment,
    – “ruby is the most powerful with the best DSL support.”
    well, i’m afraid that’s not true, Lisp is the most powerful and has been for 50 years.

    My point isn’t to argue or anything, I would just like to know why people on the web don’t use it? It’s been available as a complete packaged solution for 10+ years now, the web could be self-automated with built in evolution by now.

    Would feel honoured if you replied.

    (btw i realise this post is old, but i did search the site for the word lisp, and there was no counts)
    Many thanks, Jim.

    James Fletcher

    June 30, 2011 at 4:45 pm

  33. Sigh. I wrote this like 3 years ago. I think my opinion has changed.

    I think the thing about Lisp is the lack of a killer app. Ruby is popular because of Ruby on Rails, and so is Python. Clojure is kind of a neat tool but I have trouble getting a decent environment working. If your environment needs a Clojure expert to help you set up … it’ll probably fail. I think there are a lot of reasons why things do or do not take off, and a bigger part than is often given credit for is marketing.

    Ikai Lan

    July 16, 2011 at 4:31 pm

  34. No, your basic DSL could not be implemented as is in Ruby unless you went “out of the language” and used a parser/lexer like Treetop — but then who cares, because any programming language can be used to make that kind of DSL. No, your Baysick is a really powerful demonstration of Scala that I’m going to have to check out! Nice job!

    Larry Kyrala (@coldnebo)

    November 8, 2012 at 6:43 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s