Twitter Reportedly May Abandon Ruby On Rails
Raster Burn writes "According to TechCrunch, Twitter has plans to abandon Ruby on Rails after two years of scalability issues. Candidates to replace Rails are said to be PHP, Java, and Ruby without the Rails framework." The post links a brief comment (at 139 characters, probably a tweet) from Twitter founder Ev Williams saying it ain't so. The comments following the post embody the controversy over whether or not RoR sucks.
What is Twitter and why is it significant that they are abandoning it as opposed to anyone else?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
...and maybe it won't? Maybe the moon is made of cheese, but maybe it isn't! who's to say?! This isn't news, it's a conversation starter for people who enjoy arguing.
How complex can Twitter be on the inside? In the 1.5 years they've been publicly grousing about Rails they could have redone it ten times over.
I think there is a world market for maybe five personal web logs.
A hilarious read:
http://www.zedshaw.com/rants/rails_is_a_ghetto.html
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
I have an argument with a coworker frequently about architectural orthogonality vs performance. I fall on the "architecture should be clean and easy to understand and maintain" side of the argument and he falls on the "speed, memory, and response time at all cost" side.
What is more important? Is developer time and productivity over the software lifetime more valuable than CPU cycles? If the price of that productivity imposes a maximum limit on performance, how much optimization should be undertaken?
It's a hard question to answer. On the one hand employees are expensive and hardware is cheap. On the other hand, you can't simply forego developing for performance just because of some religious belief that architecture should be clean.
This is what Twitter is for.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
...and maybe it won't? Maybe the moon is made of cheese, but maybe it isn't! who's to say?! This isn't news, it's a conversation starter for people who enjoy arguing.Isn't that what we do here?
With douchebags like "Zed" (of "Zed is So Fucking Awesome" fame) working on RoR (you might remember his "rant" which was featured here on slashdot a few months ago - he basically threatened to beat everyone else in the world up because he's such a bad ass), why would we expect RoR to be anything other than a steaming pile of shit?
one debate that is yet to be resolved, if ever.
The whole cause is not real and debunked. But the crowd is spoiling for a fight.
Given that the linked "comment" is a status message on Twitter, it's most definitely a tweet. No "probably"Âabout it. Half an ounce of logical thinking would have told kdawson that.
And for all those Ruby people in denial to the fact that people have been saying this for years, here is your proof yet again. Of course I will be marked down as being a troll for pointing this out by the RUBY comunity but it is time that they acknowledge the inherent achilles heel of the language.
This is my sig. There are many like it but this one is mine.
You're right. Ruby is ugly if you try to write Ruby like you'd write PHP, or Python, or whatever language you think is beautiful. And although Ruby lets you code in that style, to really realize what Ruby has to offer you have to understand that Ruby is quite different than most other languages and use that to your advantage.
Rails was the cat's pajamas two years ago. The future. The in-thing. Revolutionary. Exciting. Radical. Amazing!
Then like so many similar times before, reality set in. It turned out to be buggy, unstable, less performant, and heavily dependant upon an evangelical base.
Ruby the language is interesting. Not my personal cuppa, but I have nothing against it. Rails, however... After having analyzed it and developed a prototype application for my company, I came to realize that there are other frameworks out there that are more worthwhile, epecially in an enterprise environment. The problems I've seen Twitter experience only solidify this.
If you are doing green-field development Rails should probably not be your first choice. Yes, Rails is interesting. No, it is not the end-all-be-all, and it certainly has some rather major warts.
There is no link to any original statement at all only a link to the response. If it was a twitter was the original statement: "ROR: Fail". :P
Well, there's spam egg sausage and spam, that's not got much spam in it.
What will it take to get twitter to abandon Slashdot?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
In related news, twitter (104583) reportedly may abandon his use of sock puppets due to numerous outages.
Reviewing just the first hour of video games.
And the scalability issue is not the x86 Slowaris systems they're running it on? Scalability of a platform is rarely just a RoR issue...
Your karma-blow would be more useful if you'd say what you think is better...
"Not an actor, but he plays one on TV."
JRuby.
Website Hosting
...there's not one size fits for all. Rails maybe perfect for some kinds of apps, but it can't be the silver bullet for all. And it's the same for J2EE, PHP, etc...
What about this: http://twitter.com/ev/statuses/801530348 ?
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
No, Rails is ugly.
Ruby is not just beautiful, but great.
Rails is just making bad publicity for Ruby.
factor 966971: 966971
http://twitter.com/ev/statuses/801530348
Is it just me, but how in the world did Twitter get $5.4M of funding? It's a pretty simple system and I just don't get it - granted I'm sure it's not cheap to run a system so many use but it can't be that bad...
Do the funders think that people are going to be okay with little ads being on each tweet people send out eventually or did they just want a cool new web 2.0 toy themselves?
Ruby, the Cobol of the new millennium.
The problem is Ruby. It is a very slow language (http://www.blognone.com/node/4385). My tests confirm it is 20 times slower than python in simple loops. Java is a dinosaur and PHP is not easy to maintain. I would go with Django or web2py. If they use web2py (http://mdp.cti.depaul.edu), I will help them. web2py scales very well because allows you to bytecode compile the models, the controllers and the views (so there is no parsing when serving a page) and cache every function in ram.
All of these slashdot conversations about rails have no technical details in them, describing which parts of rails are failing, which parts are preventing concurrency. The programmers on here can be just as stupid, unscientific, and reactionary as anyone else. As an example, you!
The funny thing is, for social networking sites, this is almost expected and par for the course. MySpace, and more famously Friendster had HUGE problems with availability due to their unexpected success. It's taken years for them to stop being buggy. Writing applications to handle this kind of load ain't easy.
Also, the one case of twitter's downtime being rails' fault, that I'm aware of, was due to Rails' lack of multiple db connections, which was fixed within days. And that wasn't really a bug, but a feature that was missing because no one using rails was dealing with twitter's requirements at that point.
I sure hope there isn't a train coming.
I don't really get Twitter as a social thing, but it's damn useful for interfacing with Remember the Milk through SMS when I'm away from my computer. That's the only reason I have a Twitter account.
Rails remains the best way to develop solid and maintainable web apps. But it will not compete with C for speed. Once you understand your business process, and have developed a mature algorithm to make the business work, there is nothing wrong with writing the core infrastructure in C. There are lots of C libraries that do the core part of Twitter. But the company would have been idiotic to start with them, and would be foolish to move new development off Rails.
So, er... TechCrunch says "multiple sources claim that Twitter is abandoning RoR."
The guy who founded Twitter says, "no, not really."
And TechCrunch says, "but we have MULTIPLE SOURCES."
Guess what? I have MULTIPLE SOURCES that say the Earth is flat!
Must be a slow news day.
stop replying on crackpot frameworks. a framework system that crashes at all is useless.
Twitter is probably more of an erlang kind of thing as it is a giant switch for messages . Does not mean that ruby sucks or that erlang is the best for all projects.
I think the OP's point is that worded like this, the article is rumor-mongering, not news. Many /. discussions may devolve into pointless arguments but they are not solely, intentionally that.
FreeBSD for the impatient.
I'm just starting to muck about with Rails, and am interested in where, exactly, it fails miserably. Not trolling, just curious.
Thanks.
ceci n'est pas un sig.
I don't think the problem is Ruby. Whilst I'm not associated with Twitter, I have seen some of their presentations on subject of performance, and the major bottleneck seemed to be the database, and ActiveRecord's unoptimized querying of it.
MatzRuby 1.8 is somewhat slow, but it does proportionality very little work compared to the MySQL and Memcached back end. Quite frankly, I've never seen a performance profile of a Rails site where Ruby was the problem; it's almost always the database, or too many AR queries.
Comment removed based on user account deletion
If this is true, apparently Evan Williams (Twitter's founder) hasn't heard about it.
And this is why there is a big push back to Perl for new development. It's fast, proven, plenty of tricks for speed, and a very fast database framework. Even with DBIx::Class on top of it, it's insanely fast.
If you haven't looked at Perl in a while, now's the time. Between Moose and Catalyst, developing in Perl is fun again.
- oZ
// i am here.
I once needed to make a web application to generate reports from an existing MySQL database, and I abandoned Ruby on Rails (for PHP) after just one and a half days of scalability issues. I only wish I'd done it sooner.
"When information is power, privacy is freedom" - Jah-Wren Ryel
What don't you understand?
* It's "a major site." ("Major" here means important, big).
* With many ("tens of thousands of") users. (This means it will have lots of traffic.)
* It's ("felt by many to be") the flagship RoR application. (It should be clear from the title, let alone the summary that RoR = Ruby on Rails.)
* It has suffered from numerous outages, some of these lasting days at a time. (So they clearly are having reliability issues. Since the article concerns them possibly abandoning "RoR", it doesn't take much to use some logic and work out that they may be pointing the finger at "RoR").
Granted, the summary might have mentioned what "Twitter" is, but the majority of Slashdot users will likely either know already, or will use something called "Google", which operates over something called the "Web", and can answer these sorts of queries.
I know that it gets really hard to keep up with the ever changing names, but just remember 9 times out of 10 it is just the same stuff we have seen the trendies do a million times. Now as to whether the stuff is any good or not I have no idea as I have things to do. Now get off my lawn!
ACs don't waste your time replying, your posts are never seen by me.
The RoR is a movement that depends on it's public perception. If Twitter abandons the RoR framework, then RoR could lose (if it hasn't already) a lot of steam, and appeal to the general public.
The RoR community does not want this to happen.
You're both wrong. The choices made in design and implementation need to reflect the requirements for the project. Therefore, there is not "one size fits all" shoe. You can't take a great design and force it into a real-time system. You can't take a real-time system and force it to work for a subset of problems tomorrow. There are trade-offs and the requirements will dictate the decisions you make in design and implementation.
Do you really think Twitter's bottleneck is anything other than IO? How does C improve network latency?
how to invest, a novice's guide
Ask yourself who you are working for. Most likely, you are essentially working for the people who end up using your application. If they don't like it, you have failed. Thus, the first priority should be to satisfy users.
If the application runs too slow and your users abandon you, the prettiest back-end architecture won't help you one bit.
In my opinion, maintainability should never come at the expense of the end user.
YHBT. YHL. HAND.
Let's stop feeding the troll. I have the feeling he is the guy that tells everybody that he doesn't watch TV (insert obligatory Onion link here...)
No sig
Hahaha nice troll... "good old VB6"
For the last time, PIN Number and ATM Machine are redundancies!
Pardon the off topic rant (please feel free to mod appropriately), but I have to agree that RoR DOES SUCK. (At least I didn't set up my own blog just to rant about it.) The RUBY language is the best thing since sliced bread, but Rails isn't. And I'm not talking about the installation and management issues like everyone else. I mean from a developer's perspective, RoR is horrible. Here's why:
.NET and it's various components, but I don't want to work on Windows, I don't want to work with IIS, I don't want to write VB or C#, and .NET really does a bad job of layouts and makes a lot of other stuff more complicated. And it's ORM simply can't touch ActiveRecord. Rails does only a tiny amount of what it could and should.
1) Automated copy-n-paste is still copy-n-paste
Maybe it's changed since the last time I used it, but creating a rails application COPIES a bunch of files from the distribution into the app directory it creates. How do you upgrade? Painfully, that's how. I have numerous small applications that break when I upgrade rails and it's dependencies because the copied files don't work with the newer version. My applications should be 100% code I write directly. Everything else should be kept separate and accessed via includes so emerge/apt/yum/gem dependencies can keep the rails code compatible with itself and I never have to "fix" code I didn't write.
2) RoR gives you the 1% that's used 10% of the time, not the 10% that's used 90% of the time.
So you set up a RAILS app, create your database table, and run 'generate' to get your pseudo-MVC (seen #4 below). You've got everything you need to edit a single table via the web, but that's not even close to an application. It probably saved me about 1/2 of setting things up by hand. That's simply not good enough. It should be able to create an app that supports validation (both JS and server-side for obvious stuff like numeric and lengths), sorting, filtering, searching, relationships, and css skins. It could do this just from the information available in the database metadata, which would get you 90% done. And a huge number of simple apps could be completed simply by writing a custom CSS skin and adding some graphics.
3) No UI components, which are the hardest part of web development.
Most of what rails does buy you is the back-end stuff. It's an easy way to get stared with ActiveRecord, which does the heavy SQL lifting. AR, the one shining gem of RoR, is a great object-relational model and I believe it is responsible for 99% of RoR's popularity. But SQL isn't that complicated in the first place. The real tough part of web development is getting rich, graphical, reusable UI components that work across web browsers. Prototype/Scriptaculous are a wonderful starting place, but I need code that I can feed an AR class (and possibly a list of columns and/or related tables+columns) that will generate cross-browser compatible HTML view of the table complete with searching, sorting, filtering, and paging. There could be functions/objects that render it as a table, a list, a tree, etc. You're probably thinking I should just use
4) It's NOT MVC
The Model-View-Controller design pattern is about limiting the amount of communication necessary by having one instance of some code (the controller) that all access to data (the model) from other code (the views) goes through. Views subscribe to a model, get their data and then do their thing without worrying about other views. If some other view changes the model, the controller notifies all other subscribed views of the change. Rails MVC is something totally different that doesn't solve the same problem. Rails does provide data validation via AR, which is part of true MVC, but it still misses the point of MVC, which is a coherent and always up to date set of views into the model. In fact, an MVC is impossible to implement over the web because communication is one way: the browser must initiate all communication with the web server. (For those that don't "get" this,
I know it isn't considered trendy,although "Good Old VB6" is still in the top 5 of programming languages(number 3 to be precise) and as long as you aren't trying to build some gigantic multi-use program it really works great. Of course I've been using BASIC since the days of the VIC 20(recording my programs to a cassette,boy THAT was fun) so for me it just works.YMMV of course and I've known guys that can do the same in Java,C++,etc. IMHO if it does the job you need it to and the customers are happy I say go for it.
ACs don't waste your time replying, your posts are never seen by me.
Twitter abandons the internet.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The fact that it is interpreted? The extremely conservative GC strategy that is being used? Green vs. native threads? All these are being addressed in the 1.9 development release as well as alternative implementations (see http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html). If you're referring to the fact that Rails is not written or intended to be thread safe, take it up with DHH (and he will appropriately tell you 'then don't use it' or as I would, 'go shove it'). If you're just frothing at the mouth to hear yourself type then a.) you came to the right place, and b.) you either hacked that post out in a hurry, or you don't know jack about Ruby as a language and should refrain from faking an valid opinion until you learn something about it.
quality of service instead of amateurish, stubborn preoccupation with the hyped-up framework of the month. congratulations to twitter for growing up.
-- nous
I'm really enjoying the productivity, tremendous time-to-market and business value that I can provide to my customers using Ruby and Ruby on Rails.
Part of my success is due to the fact that people still code using PHP, Java and all the rest. Those projects turn mostly late, without all/most of the agreed features and need to go through multiple revisions and debugging rounds just to hit 1.0 and go live.
So please, keep using your old stuff and stick to your old ways. You are doing me a huge favor by helping me to clearly differentiate in a very positive way from you and your solutions. And rewriting your apps properly in 30 days is profitable business.
Thank you.
Rails was the cat's pajamas two years ago. The future. The in-thing. Revolutionary. Exciting. Radical. Amazing!
... Ok, Glassfish maybe (*cringes at recalling the website*). But that's Java. They got the big gigs anyway - they don't need marketing.
... Except for maybe some post-grad, still-wet-behind-the-ears tweens who are just out of college and weren't there for the first bubble.
Wrong.
Actually it wasn't. Never was, never will be, and, dare I say, never was meant to be. Ruby on Rails is, believe it or not, relatively standard fare when it comes to frameworks. And no, they did *not* invent Active Record. And, as far as I can tell, aside from the usual marketing 'ours is the best' even the Rails people never insisted that RoR is the start and end all of all webkits.
In fact, IIRC, the RoR crew speak fairly respectfull of other frameworks aswell - like the django project. AFAIK the teams even are drinking buddies - or some equivalent of that. No, Rails never was the "Revolutionary. Exciting. Radical. Amazing!". Not with experienced web developers anyway. It was the Java communities darling because they like Ruby and RoR came at a time Ruby was getting some attention and PHP and others were caving in on Java *and* thus the Java crew needed something to join the fray without loosing face. Enter Ruby/RoR. That aside, there are far more innovative and mature projects out there that can serve as the bar for all things serverside than RoR - and most people doing web stuff know that.
There is one thing however that Rails did better than anybody else and with which Rails actually has changed the face of the Open Source Web forever: Marketing. Before Rails OSS projects would present themselves on the crappiest of sites you could find on the web and displayed no intention whatsoever of moving towards end-users and end-developers in order to win them over for a solution. Rails changed that by 180 degrees within months. They practically invented screencasts and the now obnoxious '15 minute weblog' video presentation which basically has replaced "Hello World" in the webkit community. And boosted the revenue of Macromates, the makers of TextMate - nothing much more that a grafically pimped Emacs for OS X - by doing so. It is because of said marketing spree that Rails has gained such a widespread following within the Java community. Which goes to show that these people fall for good marketing - no matter what the truth or reality behind it. And given that Java devs - after a decade of non-web but Enterprise progamming - have a standing as opinion leaders with management, it is only natural that RoR took off. It's since Rails there is no new project in the world that can dare to enter the community with a crappy presentation.
Prado, Zope, Mojavi, Ars Digita and other solutions are ancient by RoR standards, and some are way ahead technology wise. And most of the professionals I talk to are aware of that.
RoR is a neat framework and scores 30+ hits on a booksearch on Amazon. Which bodes well for RoR. But no one with real world web experience I know of was all that mesmerized by RoR as you claim.
We suffer more in our imagination than in reality. - Seneca
Hey guys, I'm working on a website and we are trying to decide on a Django or Rails implementation. This article kind of scares me because we are thinking big.
Personally, I wouldn't mind if Django is a little bit harder to develop in if it is significantly faster than rails and has more options (also I like python). On the other hand Rails has profiling and the ActiveRecord thing going on.
I've done research but I'm still kind of deadlocked.Do any of you have any advice? It would be very much appreciated in making a decision.
They must have read this webpage:
http://doesrailsscale.com/
Religion is poison to rationality, and we lose sight of that at our own peril. -- Lurker2288
Speak for yourself. Many of we Rails developers would be a lot happier to see Twitter go, because that's the one app everybody points to when they need an example of a Rails app that has problems scaling.
RoR is my bread and butter, but I'm not one of these typical RoR fanboys who preach like Rails is the second coming of Christ, and will cure cancer while simultaneously letting you build the next Slashdot in five minutes.
You want the truth? RoR isn't suited to every task, and Twitter is a perfect example of that! We're talking tiny text messages posted to an account. Then you have the concept of followers. That's pretty much it. It's a bonehead simple service that's built around extremely high volume and relatively low complexity. This thing should have a C/C++/Java backend and a thin and light frontend, where Rails would likely have no difficulty filling the job. Neither would Django, or Cake, or the languages themselves (Ruby, Python, PHP, etc).
If Twitter ditches Rails it won't say a single thing about Rails' ability to scale beyond that it didn't work for them. What it does say is that choosing the wrong tool from the get-go is an ideal way to doom your app to having such issues.
I don't know how many times I have to say it, but Rails is still a baby in the grand scheme of things, and so is Ruby. There was a time when people used to joke about writing high-performance applications in Java, but those days are over. Why? Lots and lots of brilliant people came together to figure out how to make Java fast, and they've done a really great job. Anyone who thinks that Ruby's issues with speed and Rails' exacerbations of them is going to be a constant has made an error in judgment. Then again, you can't really blame them.
Said it before.. will say it again: people hate Rails because there are too many fscking Rails fanboys out there. Bad programmers who like Rails because it makes them look like stars. It makes those of us who take a practical and pragmatic approach have a rough time on sites like this. Anyone who's ever attended a RailsConf knows that there's a lot of enthusiasm, but the people who make it out to the conferences and pay their dues are - in general - very level-headed about what Rails can and can't do, and are actively working on solving those problems Rails has. Phusion Passenger (mod_rails) was born out of necessity, and I can speak from first-hand experience that it does exactly what it says.
Everybody take a step back and relax. You didn't hear this kind of bitching when YellowPages ditched their system to rebuild in Rails, and in case anyone hasn't noticed, they're looking to hire even more Rails developers. Oh, and they're doing a great job scaling. If Twitter ditching Rails is evidence of Rails' failure, what does YellowPages' success with it tell us? Or, for that matter, any of the other large and successful Rails apps?
FWIW, Twitter isn't *the* Rails app to most bonafide Rails developers. Basecamp is.
VB6's web support was a complete abortion. I know what you're saying, but its kinda silly to pump tech in a completely different domain.
Better example in this case might be modperl or coldfusion. old and crappy but it works.
aprilfools
Seriously, they aren't. Check the facts.
You missed the point. This is a stealth ad for twitter and RoR.
Both of which are probably important, albeit not to me.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I can't comment on RoR, but your generalization about scripting languages represents a standard misconception. A native code platform isn't automatically more efficient than one that's based on an interpreter or a virtual machine. If you need to do something that hogs the CPU for extended periods (such as scientific number crunching) then yeah, you want to use C+ or Fortran or something else that compiles to native code. (Though some VM designers claim they can beat native code with on-the-fly optimization.) But for a typical web application, the CPU time used by scripts that generate the pages is not a big bottleneck. Here's an example you may be familiar with.
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Any language with fork() can scale. Claiming that Ruby can't is ridiculous.
Whether Rails can scale or not is another matter, but the bottleneck in Twitter was not Ruby, but the MySQL database.
This should, I hope, be common sense. It doesn't matter how slow your web server is, because you can always add more web servers. The point of failure is always going to be the database, because distributing writes is really tricky.
Now, I do realise that the internet is full of people who don't consider ignorance of a subject as a handycap to talking about it. However, can we not mod up people who make claims without the remotest bit of logic or evidence to back them up?
Comment removed based on user account deletion
All the time you wasted posting those two comments you could have just typed in twitter in google and found your answer.
I wonder if they've considered Groovy on Grails instead of Java or PHP? Groovy has all the dynamic language features that make Ruby and JavaScript popular with developers, but is essentially 100% backward compatible with Java (since it's running on top of the Java VM and is implemented in Java). Groovy also leverages Java and any other language that can be hosted on the Java VM because it interoperates with all of that stuff, and itself runs on the same VM. You also get legitimate closures and simplified syntax for many things. It can even give you Java 5 semantics (generics, enumerations, etc.) under JDK 1.4.
Grails is very similar to Rails, but is not a straight port -- more "inspired by," as it's described by its proponents. Grails also doesn't have the problem that Rails has in terms of scalability and performance, since it's built on Groovy/Java (which have a real threading model). No screwing around with creating a zillion Mongrel instances to scale your site, etc. And if you don't care to use the built-in web server that comes with Grails, you can have the Grails framework generate a WAR file which you can deploy in any container like Tomcat or Jboss.
At a recent 3-day Grails training session taught by Scott Davis, I was surprised to hear that some major corporations have jumped on the Groovy/Grails bandwagon, including Mutual of Omaha. For a conservative company to make that kind of leap says something. (Furthermore, they used to be a COBOL shop -- the rationale appears to be that it's easier to get COBOL programmers to make the leap to Groovy first, then switch slowly to Java, as opposed to migrating directly to Java.)
After that 3-day training, I was pretty impressed. The biggest win for Grails seems to be rapid development and deployment, but all the other stuff you get for free in the package makes it something you'd like to stick with. I'd say the thing that most impressed me with Grails was GORM, which makes Hibernate even easier to work with. GORM spoils me, since it obviates the need to write SQL most of the time.
Comment removed based on user account deletion
Basically, RoR wishes that it was Zope. It's not. People here haven't even touched on the biggest clusterfuck in terms of wasted development time - deployment.
And as for the earlier poster complaining about VB6 web support and me "pumping it", I thought I had been clear when I said whatever works for you and keeps your clients happy is what you should use. And with all the web exploits we are constantly hearing about I'm personally VERY glad that VB6 isn't really "webcentric". IMHO the world would be a lot better place if everyone didn't try to stick everything on the web. While there is a place for the web in business applications this push I've been seeing to have everything web based is just a bad idea. Too many black hats,too many programmers that don't understand all the different attack vectors available on the web, and too big a risk for little to no gain for a lot of businesses.
If your business gets tangible benefits from moving an app to web based and you have good security conscious programmers who can do it,great. But I guess I'm old fashioned like the VB6 I use. If it ain't broke,don't fix it and certainly don't chunk it just cause "web 2.0" sounds good to marketing. But as I said earlier that's my 02c and if your customer is happy with whatever language you use that is all that should matter.
ACs don't waste your time replying, your posts are never seen by me.
TechCrunch is speculating and clearly getting it wrong. Arrington's article comes out on the same day as an as an eWeek interview where Twitter's Britt Selvitelle talks about how they scaled up with Rails and offers some advice on the topic.
As to abandoning Rails:
Selvitelle told eWEEK that reports of Twitter abandoning Rails are "Not true in any sense. We use Ruby as our primary language. We have plenty of back-end architecture in other languages. Especially prototypes. We still use Rails and have no plans to discontinue this in the future."
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
As C/C++ apps get more complex, I've found that many in effect start reimplementing garbage collectors, only in really buggy, inefficient ways.
In simple apps, you can exactly police your memory patterns, and everything is created and freed in carefully defined locations. The only real complication here is that you usually (for efficiency) want an allocation strategy other than literally getting memory from the OS and returning it every time you do something minor, which fortunately C++ allocators can let you do.
But things get complicated pretty quickly, when objects can be accessed from lots of places, and there's no obvious "ok now we're done, free it" point. The usual first step is to manage this with reference counting. Encapsulations like autopointers can help make this easier to use. This is in effect a really crappy garbage collector---not very fast, and prone to memory leaks.
So what do you do next? Usually the first step is noticing that you have a bunch of memory leaks due to your reference counting leaving mutually-referential garbage. So you write a some code to look for objects with non-zero reference counts that aren't referenced by any 'real' live objects (Firefox just recently did this part). Now you have a slightly better ad-hoc garbage collector: reference counting plus cycle collection.
In many cases, by the end you would've been better off in all respects, including efficiency, if you just used an off-the-shelf garbage collector.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Comment removed based on user account deletion
Twitter wrote their own message queue based on the memcache protocol named Starling. It is actually quite awesome, and I've been using it at work lately.
Having done both, I will vote that Ruby is much easier to extend with C than Lua.
It was also next to impossible to extend Lua in an Object Oriented way, aside from one effort that was impossibly messy and in the programmers way.
In fact, if the project/library/whatever that you want to make into an extention uses C++, you will need to create a wrapper function for every single C++ class's methods (or make them all static, boo) , because the signature for a Lua exported function must be a regular C function signature.
Not to mention that you have to get intimate with Lua's stack as you pop each of the functions arguments, etc. etc.
Ruby, writen in pure C, is possibly the most clean, and easy to extend scripting language I've seen yet. In fact when writing the extention itself, the C code almost exactly mirrors Ruby to the extent that you are basically writing Ruby code in C.
Since Lua has essentially no libraries compared to the major scripting languages, and writing exentions is painful, I don't see it hosting the next big web anything framework any time soon.
The used to run on OpenSolaris when they were with Joyent. They tried to blame their outages on Joyent and changed hosting. That their still having problems can't be blamed on either Linux or Solaris in my opinion.
Open Source Java DAO Generator
Maybe they should switch to django, python-based framework. Google sure believes it can scale well. (hint: app engine) :-)
Twitter is basically a database application, where a lot of the stress comes in getting things into and out of the database at high speed.
How can you expect high performance from a framework that basically hides the sweat from good db programming? Any framework, not just Rails will fail. When you get a load higher than, say 600 reqs per second, you have to come down to understanding how to scale db performance -- take the framework away and start doing serious work.
right now, I'm currently having a laff at this time.
-
.
.
- aqk
F U
Basecamp eh? Finally I have a reason to dislike Rails!
There are exactly 42,935,718 letter sized sheets in a square mile.
Statically-linked compiled CGI scripts are usually a lot faster than anything that's interpreted.
I have yet to see a well structured VB6 app. The power of VB6 came from the third party controls market and they are slowly losing support/documentation.
I also use rails with lighttpd for slightly more crowded apps, I would have rewritten twitter in php, anyway.
So while I have no doubt in an experienced set of hands RoR could probably do what I use VB6 for, in my line of work it would be total overkill,add unneeded overhead and security risks that a nice VB6 client/server app on an internal network simply doesn't have. Not to mention it would add time that my clients wouldn't appreciate and I doubt I'd be able to make up in billing just to run RoR whereas with VB6 I have saved several years worth of code snippets that allow me to very quickly whip off a simple client server app using either VB6 and Access or MySQl,depending on how big i think the database might grow to. But as I said in an earlier post,if RoR gets the job done and makes the clients happy,I'm glad it works for you. I just hated the way some folks would look down on VB6 like it was just a waste of time when it the right situation it is just as valid a solution IMO as anything else. Maybe more so if you have situations like I get where time is a factor. But that is my 02c,YMMV.
ACs don't waste your time replying, your posts are never seen by me.
Ok, now I understand more of what you mean. I will wholeheartedly agree that VB is great for mockups, and strangely it's a great testbed for WinAPI calls.
But still, what happens when the day comes that MS pulls support for VB6? Or is there simply too much inertia in the language to prevent them from killing it?
For the last time, PIN Number and ATM Machine are redundancies!
But,let us say for the sake of arguement that someone REALLY stupid in MSFT decided "VB6 MUST DIE!" and Windows 7 wouldn't run it. I seriously doubt that given the simplicity of the underlying code that it would be very hard for someone who is a better programmer than I to come up with a little VM that allows for the simple VB client/server model to operate. Hell,didn't VB6 still have support for DOS,since it was originally released in '98? If so I bet it wouldn't be hard to tweak FreeDOS to be a host for a single VB6 frontend to connect to whatever backend you have the database sitting on. And with the size of today's HDDs you could easily push out the VM to the desktop of everyone who needed it. Then the user could simply double click on the VM and have it launch the app running in a FreeDOS environment.
But I'm probably over complicating it here. As my VB6 teacher Mr. Mikesell once said "Don't go tearing the server apart before you've even checked the Ethernet cable.". I'm sure someone has already come up with a way to run VB6 in a virtual machine. I just don't have the time ATM to go searching Freshmeat and Sourceforge to check. But as long as there are VB6 apps out there running little jobs that makes a business run a little easier(which is what I always thought VB6 excelled at) I'm sure there will be guys figuring out how to get it to run on newer software/hardware. But that is my 02c,YMMV.
ACs don't waste your time replying, your posts are never seen by me.
Why do your friends need to know you are going away during the weekend?
Answer: they don't.
In 99% of what passes for communication nowadays, the need for saying or informing other people about something it completely and utterly artificial.
IANAL but write like a drunk one.
Do they have those technologies in the planet you just recently arrived from?
IANAL but write like a drunk one.
Scaling means that you don't hit performance issues for a particular resource or that you hit them in a lineal fashion.
An application that does not scale will stall at some point for some resource (CPU, disk, network, whatever) and just throwing more resource at the problem will not sort it.
Throwing machines at a problem is a typical case of an application that is not scaling at all, you would expect that an application that is going to scale requests CPU in a linear fashion until a second machine is needed, tha usage scales linearly in both until a third machine is needed and so on.
If you have a process that all of the sudden needs 2 or 3 more machines most likely you should rethink your whole design...
IANAL but write like a drunk one.