[tluyben2]

Twitter was down all the time for hours after the launch. I don’t think I have an issue coding something that goes down when it overloads with functionality twitter had when it launched in a weekend. Most work for that kind of project goes into interpreting the specs/your business colleagues and fixing the mishaps; here you don’t have that.

[acdha]

Don’t forget that you’re talking 2006, so you need to be doing a lot more infrastructure work: no containers, shared hosting environments are less stable but bare metal costs a fair amount to get started, you’re using something like cfengine instead of Chef/Ansible if you aren’t setting everything up by hand, you have 10% of the RAM and no SSDs, CDNs are an expensive premium service, etc. Then think about what that means browser-wise: you can do a bit on the client side but server side rendering is a necessity and you’re still going to be burning time on browser compatibility to an extent which can be hard to remember now. HTML5 hasn’t happened yet so you’re building more stuff yourself, too.

I’m not saying there’s nothing they could have done better, just that there’s an awful lot they couldn’t have avoided at least without building a very different app.

[tluyben2]

Yes, I agree with that. Containers though, as far as some of the advantages; we have been using chroots for deployment since the early 2000s which is not the same but deployment/compatibility wise it was pretty good. It allows you to have the same small Linux image and deployment everywhere as well and you could move most zipped images from machine to machine with vastly different kernels. I still use chroots now on my Pandora handheld which has an ancient kernel but I run modern software on it in a chroot. No overhead too.

I think what they could have done better is rails; it was not good enough then. Php would’ve been far less hassle. But he, they made it!

[acdha]

I used chroots, too, and it was useful but much harder to maintain than a container. Automation wasn't impossible, of course, but that was also complicated by concerns about bloating each chroot with copies of all of the system libraries & config files.

I used PHP in that era. It could be faster but then you're in the classic developer productivity tradeoff between, say, hand-coded SQL calls versus using an ORM, etc. The PHP frameworks which were comparable productivity-wise to Rails were also a lot closer to Rails performance-wise since they also had heavy abstractions, and they tended to have even more creative ways to create security holes. (I am feeling very old remembering arguing against enabling register_globals circa 1998)

[tluyben2]

Hahah yeah ; I did a lot of hosting then and everyone insisted on register_globals. I still run stuff for clients that depends on it to this day.

And maybe the rails perf was comparable to the larger pho frameworks in some cases, but php was really much easier to scale in our experience. We hosted millions of sites and the python/ruby ones were generally dramas when they got serious (for that time) traffic.

[acdha]

You could still write bad code, of course, but deploying mod_php sure was easy. People could still write bad code (thinking here of someone who processed a database join in a foreach loop rather than learning how to use a WHERE constraint) but I do miss that level of install simplicity, at least until I remember what it was like dealing with incompatible versions or reconciling configuration in multiple places.