When people talk about a lack of concurrency, what are they referring to? * Rails not handling concurrency? * The lack of use of multiple CPUs by some implementations of Ruby? * The lack of native support for Actors?
Andrew On Mon, Apr 11, 2011 at 1:37 PM, Tom Adams <tomjad...@gmail.com> wrote: > I think the comment Ryan made above is on the money. Having been > through the evangelical nonsense that was around when Rails first hit > the big time, I think it's quite refreshing to see things being used > for what they're good at. > > Rails is fine for a bunch of things for a ton of reasons, you just > can't solve everything with it. To put some meat on the bones of my > point, here's some reasons we still use Rails: > > - It's fine for the scale we need on the web & API portions of our codebase. > - The deployment tools are mature. > - Hosting is easier & simpler than other tech (cf. EngineYard & Heroku). > - The stack is (more) consistent (than other tech). > - Rails people are still easyish to get, though this is becoming less > so/impossible in Brisbane. > - It's quicker to execute features for most things we build. > - Most of the things we need are built in, or have gems available. > > And here's some things that make it a not so good choice: > > - You're not building a website/API/something webbyish. > - Largish project teams (of course you can make it work if you try hard > enough). > - Highly concurrent systems. > - Systems that require high throughput. > - Anywhere you require a static type system (which I'd argue is most > things, though it's balanced with the pros above). > > > To go a little further, if we find Rails isn't giving us what we need, > we use something else. > > Tom > > > > On Mon, Apr 11, 2011 at 11:17 AM, Andrew Boag <andrewb...@gmail.com> wrote: >> This is a really interesting thread. >> >> One point worth making is that the really useful information comes >> from AFTER twitter has migrated from rails to their new solution (and >> had it in place for several onths). Twitter, no doubt, has sensible >> reasoning behind why they are changing their infrastructure, but it's >> only when they actually fully migrate their production system that the >> real-world discoveries (and problems) from a new technology become >> clearer. >> >> Would be great to keep the momentum on this topic of discussion going >> after the deployment cycle has completed. >> >> -- >> Andrew Boag >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to rails-oceania@googlegroups.com. >> To unsubscribe from this group, send email to >> rails-oceania+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. >> >> > > > > -- > tom adams > e:tomjadams<at>gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to rails-oceania@googlegroups.com. > To unsubscribe from this group, send email to > rails-oceania+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
