3 ms·

He is partly right, but if you think about what you are doing it shouldn't be such a big issue to scale reasonably well later on. Rails is properly more difficu

by tomjen 18y ago

He is partly right, but if you think about what you are doing it shouldn't be such a big issue to scale reasonably well later on. Rails is properly more difficult to get to scale since that was never a concern of DDH when he made it, something like Erlang scales because it was made to do that.

zepolen 18y ago
From personal experience, I would say he is entirely right. The first iteration of an app will be used by very few people, and most probably require a lot of changes in scope as users tend to have a way of 'abusing' (in a good way) a system in ways you could never conceive. Optimising for something that won't be used can be a terrible waste of time. For example, I recall a niche site that dealt with antiques - People could list their antiques for sale in a nice searchable 'craigslist' style site. They also included a separate url that showed only the antiques for sale by a single user, it was more of an afterthought than a core feature. The 'abuse' came when users, especially antique shops, starting using these as their actual sites. In a time when getting a presence on the internet was an arduous deal (hire a developer, hosting, domain name etc.) It turned out that the real interest of the site wasn't searchable antiques, but rather as a very simple method of creating an antiques focused minisite. Unfortunatey I don't recall the url.
derefr 18y ago
I would say that with the kind of "applications" you have people writing today, it's actually more effort to build scaling in at the start, than to throw away and rewrite the whole thing for a more scalable platform once you need to--there's just not that much code involved that's very hard to translate. To put it another way: live with the prototype for as long as possible.
dasil003 18y ago
I'm sorry, but this is complete nonsense. Rails is a framework for building web applications. Erlang is a programming language optimized for distributed computing. Rails doesn't have any inherent scalability problems. It uses a share-nothing architecture which will scale just fine. It's true that Ruby (the language that Rails is written in) is slow and presents some additional challenges to scaling (green threads, memory leakiness), but ultimately the burden of scaling rests on the architecture. If Ruby were 100 times faster it would be a very fast language indeed, but that still wouldn't make scaling easy. 100x is nothing when you're trying to go from 10 req/s to 1,000,000 req/s. As to your second part about scaling not being a big issue if you think about it up front, that is also a load of crap. Yes, don't do stupid things, but once all the obvious optimizations are gone you will usually be surprised by where the bottlenecks are. Most applications won't ever get to that size that scalability becomes seriously difficult, but then they certainly won't have a problem with Rails either.

by tomjen 18y ago

zepolen 18y ago

From personal experience, I would say he is entirely right. The first iteration of an app will be used by very few people, and most probably require a lot of changes in scope as users tend to have a way of 'abusing' (in a good way) a system in ways you could never conceive. Optimising for something that won't be used can be a terrible waste of time. For example, I recall a niche site that dealt with antiques - People could list their antiques for sale in a nice searchable 'craigslist' style site. They also included a separate url that showed only the antiques for sale by a single user, it was more of an afterthought than a core feature. The 'abuse' came when users, especially antique shops, starting using these as their actual sites. In a time when getting a presence on the internet was an arduous deal (hire a developer, hosting, domain name etc.) It turned out that the real interest of the site wasn't searchable antiques, but rather as a very simple method of creating an antiques focused minisite. Unfortunatey I don't recall the url.

derefr 18y ago

I would say that with the kind of "applications" you have people writing today, it's actually more effort to build scaling in at the start, than to throw away and rewrite the whole thing for a more scalable platform once you need to--there's just not that much code involved that's very hard to translate. To put it another way: live with the prototype for as long as possible.

dasil003 18y ago

I'm sorry, but this is complete nonsense. Rails is a framework for building web applications. Erlang is a programming language optimized for distributed computing. Rails doesn't have any inherent scalability problems. It uses a share-nothing architecture which will scale just fine. It's true that Ruby (the language that Rails is written in) is slow and presents some additional challenges to scaling (green threads, memory leakiness), but ultimately the burden of scaling rests on the architecture. If Ruby were 100 times faster it would be a very fast language indeed, but that still wouldn't make scaling easy. 100x is nothing when you're trying to go from 10 req/s to 1,000,000 req/s. As to your second part about scaling not being a big issue if you think about it up front, that is also a load of crap. Yes, don't do stupid things, but once all the obvious optimizations are gone you will usually be surprised by where the bottlenecks are. Most applications won't ever get to that size that scalability becomes seriously difficult, but then they certainly won't have a problem with Rails either.