Ruby Clouds: Engine Yard Vs. Heroku 41
snydeq writes "InfoWorld's Andrew Glover provides an in-depth comparison of Engine Yard and Heroku, two cloud-based, platform-as-a-service offerings for Ruby development. 'To put it simply, Heroku will appeal more to developers and Engine Yard will appeal to operations folks. Consequently, when evaluating the two platforms, one's choice usually comes down to what's more important: Heroku's rapid deployment via a hands-off infrastructure, or Engine Yard's total control over all aspects of application deployment, provisioning, and monitoring.'"
Great for little apps (Score:3, Informative)
Re:Ruby?! (Score:5, Insightful)
Re: (Score:1, Funny)
It's not Python for one.
Re: (Score:1)
No need to feed the obvious trolls. Anyone who uses Ruby knows what sort of tasks it's good for and what sort it isn't.
Re:Ruby?! (Score:4, Interesting)
Not to mention Ruby 1.9 is statistically the same speed as Python 3 (if not just very slightly faster).
I like both so I really don't care who wins this fanboy war.
My personal preference is Ruby since I have to work with Perl most of the day and Ruby is what OO Perl should be. Also I like RubyGems for library management, not having to worry about indentation, and there are some syntactic sugar in Ruby that gives it an edge (for me at least).
I like Python while using iPython to do some quick and dirty data checks with numpy and matplotlib.
Re: (Score:2)
Not to mention Ruby 1.9 is statistically the same speed as Python 3 (if not just very slightly faster).
It is? Shootout [debian.org] makes it marginally faster in 2 tests, marginally slower in 5 tests, and 2-3x slower in two tests. Still close enough that speed shouldn't be a deciding factor though; if number crunching is so important that a 10% difference is important you'd be using C anyway :-P
Re: (Score:1)
if number crunching is so important that a 10% difference is important you'd be using Fortran anyway :-P
FTFY
Re: (Score:2)
Re: (Score:2)
If you look a little closer in the shootout results that you linked, you will see the overall difference is a wash (basically the same speed) hence the term "statistically the same speed".
Actually we use intel Fortran. It's slower than C (4 times slower in the benchmark), much faster
Re: (Score:3)
look at the cost (Score:1)
Ruby is a TURD (Score:1)
Ruby is a giant stinking turd written by a bunch of clowns with little grasp of how computers work.
Don't think so? Read this:
Ruby bug 5244 [ruby-lang.org]
Yeah, Ruby completely misuses setjmp()/longjmp() throughout its code. Yet get this:
Ruby's callcc copies stack to heap, then calls setjmp(). Stack frames are restored from the copy before longjmp(). -- Shugo Maeda
You moron - read the fucking man pages for setjmp()/longjmp(). Since when is copying a stack off somewhere a sufficient condition in allowing one to arbitrarily restrictions placed on a system call?
And we're supposed to think such crap ideas don't permeate Ruby through and through?
Re: (Score:1)
I don't know about all that. Coming from the C++/Java land, Ruby was a breath of fresh air. It seemed to me better at allowing me to express what I wanted to do in a more natural way. I've since looked at Python, and have had to do quite a bit in PHP (ugh), and neither struck me the same way. JavaScript's semantics are nice, but the syntax is unfortunately from C. So as a scripting language, Ruby is very nice. And it's a lot less ugly than Perl.
Now unless these trolls are coming from Lisp or Smalltalk, they
Re: (Score:3)
Probably.
I'm not sure how to feel about all of this. Not the comments from the Anon, but the Ruby situation. Some of the hate is about the language and I'll admit it, I'm not a fan of Ruby. OK, RoR, I see some of the benefits, Ruby on its own, well, just not a fan. I'll just leave it at that before I display any more stupidity and ignorance, just to say that the Anon above is right with the comment about folks not knowing much outside of the C universe. I certainly don't.
The rest of the hate comes from some
Re: (Score:2)
Try out openshift (Score:5, Informative)
While I am a fan of both of these services, I really enjoy using openshift more. OpenShift is completely free and supports ruby, python, perl, java, and PHP.
For those who don't know, OpenShift is Red Hat's free platform as a service all running on top of RHEL.
--
Re: (Score:2)
Free as in costing no money whatsoever? Does it scale at all? Sounds like a big money pit.
Re: (Score:1)
Re: (Score:2)
Do it's a platform without the infrastructure to run it on. Interesting idea, but not really what people generally mean with PaaS.
I must be missing something (Score:1)
There are a jillion places where I can run PHP + MySQL. Every web hosting company on the planet probably.
Ruby on Rails? Probably less than 1 in 4 support it, and many of those that do don't do a good job.
Why? Why is RoR so specialized?
Re: (Score:2)
Re:I must be missing something (Score:4, Interesting)
This. It's not specific to Ruby frameworks though. You're pretty much in the same situation if you want to use anything other than PHP+MySQL. Generic hosts nowadays are pretty much meant for non-programmers to run their own PhpBB, Wordpress, Drupal and various legacy websites, not recently developed web applications unless the developers are still stuck in 2004 and choose PHP+MySQL as their language and database even when they have the chance to start from scratch.
Personally I just get a XEN/KVM server somewhere and install what I need myself, be it Ruby+Rails, Node.js+Railway or Scala+Play and Redis, RIAK, MongoDB and/or PostgreSQL.
Manga (Score:4, Funny)
I admit I am not a big follower of Japanese manga, that's why I probably never heard of Ruby Clouds: Engine Yard vs. Heroku, but is it any good?
Re: (Score:2)
Personally I prefer plain rspec with capybara and steak over cucumber, though. And I don't use shoes.
Why doesn't someone... (Score:3)
Design a platform composed from the ground up as a collection of clean, interlocking modular blocks, Those blocks are designed to allow the developer to choose from a wide range of functionality and would be designed to make platform extensibility a natural process. As the library of functionality grew, 99% of the time you could just pull a few blocks out, connect them and you'd be off to the races. If you needed anything new or particularly esoteric, you could just create a new block, and when done add it to the library so others could enjoy the fruits of your labor in the future (as you enjoyed theirs now.)
I'm tired of looking at 20 different systems with 20 different sets of advantages and disadvantages. Make the app platform core module uber-tight and way fast (maybe something LISPish.) Create a simple abstraction module that provided a smooth and consistent interface so library modules could easily be written in or ported to any popular language. Of course there would be the classes of modules to support various file types and interactions, network protocols and interaction, maybe natural language or device dependent smart formatting, you could start with all kinds of goodies in the cupboard. Build the thing from the ground up to sit on a hardware abstraction layer that allows the application to leverage any and all hardware and network resources available to it. This would allow you to tune the beasty to its selected environment without the need of screwing with the platform engines configuration.
Is it just me, or isn't there now sufficient experience and information available both from the "using end" and the "designing end" to build a platform that is both flexible enough to assimilate new technology, fully utilize existing technology and provide basic services that most of us seem to be asking for on fairly regular basis. I'm not interested in religious wars. I just want to be able to slap something together without getting a doctorate in the silly thing or go through a 2 year learning curve because the tech keeps changing under my feet.
Then again maybe I'm just pissing and moaning to myself and a holy grail is just a silly myth. I'd be interested to see how others feel?