tinyurl.com/6g93om -> www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/
Twitter is planning to abandon Ruby on Rails as their web framework and start from scratch with PHP or Java (another solution is to stick with the Ruby language and move away from the Rails framework).
CrunchBase, our tech company database, is also built on Rails. Switching off Rails may not solve all of Twitter's problems. They have nearly two years of infrastructure built up and would face many more growing pains if they switched frameworks or rolled their own.
here, all I can say is that multiple sources claim that Twitter is telling people they are planning on moving away from Ruby on Rails. This is not the first time a company has denied something that has turned out to be 100% true.
Because of the similarity of Ruby on Rails and Cake PHP in the ORM layer and etc its more likely to be a move to PHP using the Cake MVC web framework. The other choice is not Enterprise Java but say Plain Old Java Objects using the Groovy Graiils framework that works with Java.
May 1st, 2008 at 1:54 pm PDT Sometimes huge growing pains force change sooner than planned. I'm just now getting into Twitter and although not an addict, yet, really enjoy the connecting that goes with the site.
May 1st, 2008 at 1:54 pm PDT I thought database abstraction and transparency, almost as if you could avoid thinking about databases in traditional terms, was a big new bonus in Rails, why would you need to optimize the database?
May 1st, 2008 at 1:55 pm PDT Oh no, this is going to cause absolute mayhem. This is more potent than a DHH post on GENERATING PROFITS or four day works weeks. I'm betting they won't side with a PHP or Java framework, but that's not going to stop the upcoming rage virus epidemic.
May 1st, 2008 at 1:57 pm PDT They should just go with IIS7 and sql server 2008. I know it is the "in thing" to not pay for your webserver os and db engine, but why not build on something that is used in the enterprise? net, and there are hundreds of thousands of people learning C# in college right now.
May 1st, 2008 at 1:57 pm PDT They should go with C This is a messaging protocol, not a Web app people. Would AOL Instant messenger implement their app in Rails? This really says very little about the Rails framework, if you ask me.
com runs his whole entire operation on 2 front-end servers and one DB server, and he's doing what like 30,000,000 page views an hour or a day or something ridiculous like that. Compiled code beats scripting in speeds any day of the week. Net MVC framework, that way they can write ruby and still get performance.
May 1st, 2008 at 1:59 pm PDT Maybe it's time for Twitter to leverage Amazon's E2C which has no uptime agreement. At least Twitter would have someone new to blame for endless, unscheduled outages.
May 1st, 2008 at 2:00 pm PDT Twitter is easy to implement using an ActiveMQ (Java) cluster for the subscriptions, PHP for the front end/API, and another Java farm for message delivery. They are probably going down because they are pushing around too much data on the backend. Subscriptions should just be pushing around the index for messages.
May 1st, 2008 at 2:01 pm PDT Depends on their strategy here, but there are quite a few other ways they can go. The RR monolithic strategy can be tough to cope with when you need to do things like asynchronous operations. Other platforms are just better equipped to do those sorts of things, without your environment ending up as a hodge-podge of technologies. I'm *sure* they're having conversations about the front-end vs.
May 1st, 2008 at 2:01 pm PDT I see lots of people suggesting a PHP solution, but I think that's a limiting path for 2 reasons. First, Twitter is increasingly global, and (I believe) PHP still lacks Unicode support. Second, for a site that gets as much traffic as Twitter, they'd benefit immensely from a language that handles multi-threading well.
May 1st, 2008 at 2:04 pm PDT earle: PHP is a template language meaning that it's a language that works within a template system (in this case, HTML) That makes building smaller templates very easy and fast. That's one of the reasons that you really want to divvy up business logic from display logic. Django is a template system within a language, which may seem like a minor quibble, but it requires data preconditioning in order to use it, meaning that templating is something that has to be kept different and requires a different syntax. It really depends on how they've structured things for their site. Both choices are valid, but it's a bad idea to dismiss either of them out of hand.
May 1st, 2008 at 2:04 pm PDT @Matt Baron: agreed this is a messaging app. Sticking a db into the flow and distribution of messages is a non-starter for anything with real aspirations to scale. it's the flow of msgs and what you do with them that matters.
May 1st, 2008 at 2:06 pm PDT @26 Your technology doesn't support compilation so your defense in using it to scale is use an adon? I / me / developers everywhere shouldn't have to fight with a technology that doesn't scale and bolt something else on to solve a problem. I should be able to focus on my code, write it, and move on, not worrying about having to one day at some point install some other third party tool to make it go faster.
May 1st, 2008 at 2:10 pm PDT @26 - that thought scared me - are they really *moving* around multiple copies of tweets? I've seen people seemingly in awe of being able to "deliver" that many tweets to people (the twitter spewage charts a few days ago). There should only be one copy of a tweet in a database table, not dupes. Also, not really sure why they're having the scaling problems. I'm not a huge RoR fan, but I don't really care to bash on it that much. I've been around to see crap code on every major platform out there - I know people who can make *any* system *not* scale. However, if they're trying to keep everything within the confines of the RoR framework, that may be the problem. Frameworks are great, but there are times when you need to bypass the confines of the system, usually for performance reasons. The trick is knowing when and how to do it, documenting it, training people on why you deviated, etc. I suspect if they just rebuild with the same architecture and mindset, just a new language, they'll have the same problems. Likewise, if they rebuilt from the ground up in RoR (or just Ruby) they would likely be able to make it scale much better with all the lessons learned. Of course, given that many of the original brains are now gone, perhaps that wouldn't be as useful, because those experiences are now gone too...
May 1st, 2008 at 2:11 pm PDT Just because a site has scalability issues, it does mean Rails is the culprit. Most of the time when Sites are not scaling it is database which is the culprit, mainly for not being totally optimized. Twitter is growing faster than they expected and can't really blame someone here because the service is free and beggar's(users) can't choose.
May 1st, 2008 at 2:12 pm PDT PHP only limits people of lack of creativity. They will probably find the correct language for the application, but I would not say that PHP is not the right language for this.
May 1st, 2008 at 2:13 pm PDT They are obviously going migrate to Termite/Gambit and replace Starling with ejabberd, I mean, what else could possible handle the load? Come on people, as if the web front end has anything to do with twitter's particular technology challenges.
May 1st, 2008 at 2:13 pm PDT A default install of PHP isn't the best thing in the world, but once you tweak some settings and add a few extensions like eAccelerator, it's real fast. Clicky's tracking server handles almost 20 million hits per day to PHP, and it's far from top of the line. I realize Twitter would have quite a bit more traffic than that, but the point is that 20M/day is still a LOT of traffic, and PHP does it without a sweat.
May 1st, 2008 at 2:14 pm PDT @30 - Eric: Multithreading and application scaling - at the server farm level - have pretty much nothing to do with each other. One might almost argue *against* that approach, as the 'shared nothing' approach of PHP has been proved as scalable as any other approach out t...
|
http://csua.com/feed/