Slashdot Mirror
Ruby 1.9.1 Released
Janwedekind writes "Yuki Sonoda yesterday announced the release of Ruby 1.9.1 (Ruby Inside coverage with lots of links). The VM of Ruby 1.9, formerly known as YARV, was initiated by Koichi Sasada and has been in the making for quite some time. Ruby's creator Yukihiro Matsumoto has already presented many of the upcoming features in his keynote at RubyConf 2007. Most notably, Ruby 1.9 now supports native threads and an implementation of fibers. A lot of work also went into encoding awareness of strings. The 1.9.1 version is said to be twice as fast as the stable 1.8.7. It will take some time though until the majority of existing Ruby extensions get ported to 1.9."
So now it's only "really slow" as opposed to "really really slow"? Ruby needs to look at some of the lessons learned by the various Smalltalk and JavaScript speed-up projects from over the years if they want to actually get competitive on performance.
No wifi, garbage collection not as good as Lisp; Lame.
According to this video , there is lack of direction. This is by Dave Thomas , and important figure in the Ruby world.
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
I have only used Python and don't know anything about Ruby (I only heard that it has a very nice syntax), anyone would like to give me a good comparison between them?
Rubys speed and scalability hasn't compared in the past but each iteration I always try to re-evaluate and give it another shot. The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
My company tried to make the switch and could find enough developers, could find enough module support and just couldn't get the same functionality for RUBY as with languages that have larger communities. Plus under large loads, it buckled and we ended up having to rely upon the same PHP codebase to get the job done anyway.
But again, a new iteration may mean improvements and who knows, they may have made some positive changes this time. Naturally it won't have all the support of more mature languages but all I expect is for it to be able to scale as well and handle page loads as well before I'm switching languages.
This is my sig. There are many like it but this one is mine.
Choice of programming language actually matters, and dismissing languages you haven't used much is foolhardy. If this isn't obvious to you, this article may prove enlightening.
-- The act of censorship is always worse than whatever is being censored. Always.
Dave Thomas is not at all important in the Ruby world. He just wrote some terrible books about the language.
No, it really doesn't. What matter is availability of libraries, and your personal profficiency with the language. Given C and a regex library, I'll write better, cleaner, and faster doing string parsing than I would in perl. Why? Because I've used C and C++ every day for the past 8 years. Even though I use and know perl and regex is built into the language, I make more mistakes in it due to using it only a few times a year. And yes, I've actually tried this- I was 5x faster in C with the regex library. Do the test again with a perl maven, and I'm sure the opposite result would occur, even if you gave a problem that's more traditionally a C thing.
Now there are some languages that better suit individual people than other languages, due to the way they approach problems. Lisp is good for people who think very mathematically. C is good for those who think in a very step by step manner. OOP is good for people who think in terms of models and interactions. But you'll always be more efficient in a language you know well than one thats new to you.
Which isn't to say there's no reason to learn a new language- you may find one that fits you a bit better, especially if you learn a new paradigm like functional. But you'll never solve a problem quicker by using a language you aren't as familiar with, unless a library for a major piece of functionality exists in that language but not yours.
I still have more fans than freaks. WTF is wrong with you people?
That's an oversimplification of the issue. You don't simply use a new tool because it CAN do something, it is also a matter of whether it can do it BETTER that the current tool, whether you can find people who can use that tool, whether you can find information on how to use that tool with other systems and tools and whether that tools has a robust set of expansions/libraries/modules.
To date for alot of people and companies, RUBY was hype (and this has alot to do with the community that hyped it). Now that the hype is over, people are beginning to evaluate it for what it is. RUBY can provide an easy entry level, is a powerful language but has not to date shown it's ability to scale, continues to rely HEAVILY on languages that it's community says it is much better than in order to scale (ie PHP, Perl, Python), and the benchmarks I have seen are always slanted (ie trying to test pageload times for PHP vs RUBY without installing PHP as an Apache Module).
So the correct phrase should be... The right tool for the job (given current employment pool capable of supporting said tool and community support for said tool).
This is my sig. There are many like it but this one is mine.
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
If you see no advantages to using it over PHP, you obviously haven't looked very hard.
Off the top of my head: Ruby has better syntax, a better object model, runs faster (really), better standard libraries -- Rails aside, Ruby tends not to pollute the global namespace with bullshit like mysql_escape_magic_quotes_no_really_I_mean_it_this_time...
PHP's advantage? Lots of unimaginative programmers like you know it, and it's slightly better at mixing code and data, since it's really just a Turing-complete template language. But I like haml anyway, and regardless, the template is one tiny part of your app -- the actual application logic should be buried in the model somewhere.
So for the majority of the program, PHP has no advantage. For the tiny minority where it would, in a well-designed app, haml makes it look so ugly it's not even funny.
Don't thank God, thank a doctor!
You do realize neither Ruby nor Rails is an acronym, right? Ok.
The only argument for it in the past for web dev is RAILs and there are plenty of MVC frameworks for PHP now including PHPulse, Cake and Codeigniter.
And those don't compare well, even to Rails, certainly not to Merb.
And Merb is going to be merged into Rails.
under large loads, it buckled
Hardware is cheap. Couldn't you throw more at the problem?
Don't thank God, thank a doctor!
I have now seen the video you linked to, and I can't noticed where he said Ruby lack direction. He said in fact that Ruby is great as it is, what he want to see however, is that new ideas for Ruby experimented on as forks rather than tried within the mainline Ruby. I think the video was quite good and worth seeing even though it last 47 minutes!
The parent I believe is incorrect in using that video to claim there is a lack of direction.
On a side note, I will use PHP on my servers before touching Ruby since I see no advantages for using it over PHP.
Except for where speed is of the utmost importance (in which case you're limited to C/C++, and possibly just assembly language), anything you can do in one language, you can pretty much do in any language. The question is, how EASY is it to do it in a certain language.
There may be no web app you can create in Ruby that you can't also create in PHP, but that doesn't mean PHP is always equally suitable to the job at hand. You may find that Ruby allows you to complete certain projects much faster, saving you a LOT of money. And in those cases, that would be a big advantage for using it over PHP.
Dave Thomas is not at all important in the Ruby world. He just wrote some terrible books about the language.
Maybe not, but I hear he's pretty popular in the hamburger world.
(Somewhat related to that, my verification code was Subway.)
Hardware is only cheap if someone else is paying for it. Why spend money you don't have to? AMazon and other big companies have already come to that realization. When I worked there a year or so ago it was impossible to get new hardware- not because they were cheap, but to encourage you to use the hardware more efficiently. The end result- a lot more use of virtualization for small stuff, a lot more thought into efficiency of services, and millions saved. Smaller organizations won't save millions, but they'll save a significant chunk of cash. The "just throw money at it" attitude is gross negligence.
I still have more fans than freaks. WTF is wrong with you people?
That approach makes sense for small jobs, but for projects that take more than (say) two months, it makes more sense to choose a roughly suitable language, even if your proficiency is lower.
Also, for any code that isn't throwaway code, you have to assume that some unknown person will eventually inherit and maintain your code. Under that assumption, it's more important for the language to be appropriate for the task than for the language to be convenient for the initial programmer. You wouldn't want to inherit a bunch of string parsing code written in Fortran, would you? At least choose a roughly suitable language! Even the best imaginable regex library for C has to be relatively crappy (measured by the readability and correctness of code that uses it) just because of the limitations of the language.
Now, I personally detest Perl and am pretty good with C++, but if somebody proposed writing a string parsing program in C++, I would tell them to use whatever non-dead scripting language they know, even if it's Perl, and if they don't know one yet, for God's sake pick one and learn it -- even if it's Perl!
A lot of work also went into encoding awareness of strings
That's quite a fancy way to say "a lot of work went into making dealing with strings and encodings as messy as possible".
So far, Ruby 1.9/2.0 is the only high-level language I know of which allows strings within the same program to be in different encodings (attaching a reference to encoding to every string). For double fun, the encodings need not be compatible with each other (not even with Unicode). This might also make Ruby the first language in which string comparison and concatenation are not well-defined for two arbitrary strings (as you get an exception if encodings are incompatible). Just wonderful - imagine writing a well-behaved library which does any sort of string processing with input parameters with these constraints...
I am not familiar with Rubinius. But regarding all the others - Ruby on Java, on the CLR, etc., none of those are anywhere close to approaching the speed of recent JavaScript engines.
The typical situation is that something like JRuby or Jython are implementations of a dynamic language in Java/C#/etc. instead of in C/C++, but they have the same architecture as the C/C++ engines. This leads to about the same performance - the Java VM does excellent JITing, but as we know, it brings Java into about the same area as C/C++, not faster.
So, these implementations end up being about as fast as the original C/C++ ones (but they have various other advantages, which are their real value).
The latest-generation JavaScript engines - and we are talking about the last 6 months here! - are very different in their architecture. They use techniques like trace trees and hidden classes, along with native code generation using JITs specializing in JavaScript, to generate performance that can, in some cases, be closer to C/C++ than to Python/Ruby.
The PyPy project has been saying this all along, in fact - that to make dynamic languages fast, you can't just implement them in the JVM or such and expect 'magic' to happen with that VM's JIT. It doesn't work that way. Even if you JIT an architecture that does hash table lookups or type checking for each assignment, performance will be poor; the JIT can't fix your algorithm. Fixing the algorithm is exactly what latest-generation Javascript engines like V8 and TraceMonkey do.
Your maintenance point is good. For that reason alone I wouldn't use C for a web front end (back end service sure, not a front end), because the vast majority of people they'd hire to maintain it wouldn't be experts in it. And for any team project its not your best language that matters, but the best language of the team as a whole.
I disagree with your time argument though. If anything, the time just makes it more important to use what you're familiar with. If you're talking about something taking 1 hr vs half a day based on language choice, its a minor difference. If you're talking about a 3 month project, you're probably talking 2-3 months extra to use a less familiar language.
I still have more fans than freaks. WTF is wrong with you people?
Hardware is only cheap if someone else is paying for it.
No, hardware is cheap, relative to programmer time. Moore's Law only reinforces this. In fact, you're making my argument for me:
Why spend money you don't have to?
Let's suppose it takes me half the time to code it in Rails than it does to code it in PHP, but requires twice the power to run. And let's suppose I make minimum wage.
Before it even comes close to costing more to run the hardware than it does to run my salary, you're already running six or seven extra-large instances. Go look up the specs for an extra-large instance. And keep in mind, that's additional -- that assumes the optimized version requires six or seven of those, and my inefficient version requires six or seven more.
You can run the numbers yourself, but it ultimately tends to work out the same. And all of that assumes the Ruby version is slower -- and, following my link above, it really isn't.
Smaller organizations won't save millions, but they'll save a significant chunk of cash.
Smaller organizations, I would think the "just throw hardware at it" argument makes even more sense. The speed of a nonworking app is irrelevant. The speed of an app serving a dozen programmers and testers, before public release, is similarly irrelevant. By the time you're getting hundreds or thousands of requests per second, you're probably making enough money from ads alone to cover the costs -- but while you're still "only" getting dozens of requests per second, a single Rails server might work just fine.
Now, I agree, throwing hardware at it is not a good long-term solution. The good long-term solution is to optimize the better systems. However, investing in a demonstrably worse architecture to gain a little performance -- maybe -- in the short term, does not seem like a good move.
Don't thank God, thank a doctor!
Hardware costs in a hosted environment can be pretty outrageous.
But I really wanted to take issue with the insinuation by Foofoobar, which I have heard so many times, that Ruby is "not scalable". Even if he meant Rails, not just Ruby, he is just plain wrong. This scalability "issue" has never been a real issue at all... as long as you didn't mind getting your hands a little dirty in server configurations.
Look at some of the "top" 100 Ruby on Rails sites, and try to tell me again that Ruby "doesn't scale": http://rails100.pbwiki.com/
Lisp is good for people who think very mathematically.
Which aspects of mathematical thinking is it that is well aligned with Lisp?
What I think characterizes mathematical thinking (as opposed to programming thinking) is the declarative and/or pure nature of math: variables don't change, and there's no notion of time.
I think a pure functional language, such as Haskell (or at least pure code) would fit better with mathematical thinking, because it has the same unchanging nature that math has.
I'm guessing that a pure logic programming language would also make a good fit, but I haven't (really) done much logic programming.
But then again, map and filter are axioms in ZFC and they appear in roughly speaking all functional languages as well, so maybe there's something to it :)
How do you know the tons of manhours put into optimization work won't cost you more than the added hardware?
It's not just that, either. Ruby is more consistent. Object-orientation was a latecomer to PHP, and the language still shows it's non-object roots. Ruby is consistently, 100% object oriented, and it shows.
The old tales about being able to do things faster and with many fewer lines of code in Ruby are not just fluff. For example being able, in RoR, to take the submission from a 40-element form on a page, and put it in your database with just "my_object.create(params)" is pretty sligging frick, if you ask me. Of course that is only a very simple example, but still.
Being able to use reflection to get data about the objects you are handling is great. And the implementation is just plain smooth. Don't remember what you can do with the object at hand? puts my_object.methods.sort
Other languages have nice features, too, of course. But Ruby has some things that you don't want to do without, once you use them.
Python is skiing and ruby is snow boarding.
I guess that makes C drunk driving. Much faster and more crash-prone.
--*car_analogy_quota("jonaskoelker");
What kind of "direction" does a general-purpose, Turing-complete language need? What kind of "direction" did BASIC have? Or Pascal? Or C?
The evolution of Ruby has been extraordinarily fast, considering that the whole language is only around 12 years or so old, and only became somewhat popular 3 or 4 years ago!
Sure, certain additions to the language might be welcome. Compiler and speed improvements would be welcome. But I don't get this whole talk of "direction". WTF?!
Now, if that discussion is about Rails, then it makes more sense. But Rails has had plenty of direction. It has improved vastly, and is arguably the most flexible framework out there... soon to be even more so when it incorporates Merb.
Don't like Erb? Use Haml. Or some other markup... the most you need is a plugin. Gems and plugins are available for almost any conceivable want or business need.
Direction? Sheesh.
Why should they be comparable? They are fundamentally different things. A "Unicode String" is not the same as an "ASCII String" at all.
How should your string compare work? All similar characters in all popular encodings should map to each other? Hmmmm... that would be a pretty damned big code base to handle all those permutations. Maybe as big as the rest of Ruby.
via overflow.
--
Now, write that 100 times by sunrise or I'll cut your balls off.
And how do you know that adopting and developing more efficient solutions from the start won't save you money on new hardware along the life span of the current hardware?
I agree with your points. That said, the PCRE library seems quite sweet and I could probably live quite happily with it. Sure, Perl has advantages because regexps are built into the language and don't need quoting etc.
(-: And that from someone totally opposite of you; I wss never really happy with C++ but do Perl for fun. :-).
Karma: Excellent (My Karma? I wish...:-( )
Well, in Cake it's '$this->Model->create(); $this->Model->save($this->data);'. As examples go, that's not very convincing.
Never underestimate the bandwidth of a 747 filled with CD-ROMs.
"variables don't change"
Doesn't the name variable suggest, well, variability?
Are you thinking of constants, in a mathematical sense?
why aren't the pre parts in parent indented unless you click on the expand link?
Javascript, Smalltalk, or things like microsoft's CLR are not a good comparison for high-level languages' performance these days. That's because Vala manages to do everything that the CLR/JVM does, only with performance somewhere between C and C++.
I'll take Perl and Catalyst over Ruby and Rails any day of the week. Ruby borrowed heavily from Perl, and managed to snaffle the rest of it's features out of Python, all combined into a very un-directed little language.
There is no sig...
The idiom of "let's throw more hardware at the problem" is a way of saying "we don't know jack shit about how to build a scalable web application, so we'll hide the symptoms by throwing a bunch of additional hardware at it so it at least seems we can scale things".
Really, building a scalable web app is not hard, but if you're using Ruby on Rails, you're looking for a miracle since it's a known fact RoR doesn't scale very well. Other languages suffer from the same problem, except it seems those languages have more people using them that actually know what they're doing, instead of just following the RoR hype of it being the best thing since sliced bread, which it's not.
There is no sig...
How do you know its going to take tons of manhours to get efficiency gains? I'd imagine that if you hired jr. programmers to do the initial round of programming it would only take a few hours of an experienced sr. programmer to identify potential bottlenecks, and either come up with a solution or just fix the problem.
Besides, inefficient code will add up almost exponentially as your load increases. So you could throw hardware as a stopgap, but eventually (if you get large enough) you would have saved a lot more on physical resources if you had taken the time to analyze and solve the problem from the beginning.
When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
I hear that answer alot from the RUBY community. Why would I as a business be expected to switch to a language that requires twice as much hardware? What you MAY save with software dev speed, you now lose with day to day server maintenance.
The key to good engineering is to simplify because the more parts, the more chance of failure. So throwing more hardware at the issue when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
This is my sig. There are many like it but this one is mine.
So basically you're pissed that your hobby language (and make no mistake, that's all Ruby will ever be) will not be adopted because there are more "unimaginative programmers" who know it thus allowing business to move forward with doing actual in an attempt to make a profit.
The number of intelligent CS morons on here is astounding. You'll always a cog in the machine. You don't understand business, that much is obvious.
> Besides, inefficient code will add up almost exponentially as your load increases.
Eh?
We're not talking about poor algorithm selection. We're talking about using a slower language rather than a faster language. Unless you deliberately adopt a "slower languages deserve slower algorithms" mentality, you're talking about a linear increase in hardware.
In that case, doubling the hardware requirements in exchange for even a 25% cut in coding time is going to be a huge boon for your company. If writing in a cleaner, more elegant language makes the code base smaller and easier to read, those senior developers are going to have a much easier time finding the bugs and the bottlenecks. Plus, if you can write the thing that much faster, your developers are going to have a lot more fun.
Since we're talking specifically about Rails here, the first optimization pass is usually A) finding pages and partials that can be cached, and B) tweaking your ActiveRecord queries so that the database grabs all the records it needs on the first pass. Both are simple to do, and once you've accomplished them it's going to be quite a while before a normal site is going to run into scaling issues.
You want the truthiness? You can't handle the truthiness!
Ruby on Rails is not a language.
No, it's a framework based on Ruby, the language. Just as Catalyst is a framework based on Perl, the language.
Your point?
There is no sig...
Don't mean to be a hater, but IAlwaysLikeIt( when a dead language from the 1980s written by a long retired Japanese dude) isResurrected && pitched to a new Generation;
Reality Check: DHH knew that WebObjects (Apple's ObjectiveC turned Java for the web) was The Way, but Apple had let that framework languish since buying it along with NeXT. DHH did The Right Thing by building something new, but bet that it would be more successful if he brought Ruby back from the dead rather than try to pitch PERL to a generation of PHP jockies who had come to accept the echo of parrots mimicking guys not smart enough to grasp PERL so they simply mocked it as line noise. You're talking about academic purists and other real morons who typically embrace Python (the Visual Basic of Open Source) because let's face it, anything is better than PHP.
So PERL is back with its mean Catalyst Framework (almost up to v1.0 and it is awesome), Google seems to be latching onto Python with Django bindings for its Apps service and the cattle herders down in Israel are cooking something up for the PHP drones. Meanwhile, Ruby is fragmenting into a million incompatible releases and Rails is still just 37 Signals.
Question for you:
Which is greater:
I think you will find that the answer is "it depends". Specifically, it depends on how long it takes to learn the new language, how much more productive that makes you, and how many projects you do. Assuming that a new language makes you more productive, if you do enough projects with it, you save time compared to sticking to a language you already know.
The notion that the choice of programming language doesn't matter is simply ridiculous.
Please correct me if I got my facts wrong.
Not at all. You're assuming that it really will be faster to do a project in $newLanguage. I disagree- unless there's some library that doesn't exist in $oldLanguage, the productivity of languages at equal levels of experience are equal. I have never in my life seen a problem made simpler by changing languages rather than downloading a library. If you want to dispure my point you need to prove the assertion that it isn't so, not just throw some pseudomath in a post.
I still have more fans than freaks. WTF is wrong with you people?
We're not talking about poor algorithm selection. We're talking about using a slower language rather than a faster language.
You assume that the same algorithm used in two languages will have the same big-O characteristics for CPU and memory consumption. That is not true.
For instance, some languages can optimize tail recursion into a loop, and some cannot. For those that can, the memory consumption for a given algorithm may be constant. For those that cannot, the memory consumption may be O(n).
Social scientists are inspired by theories; scientists are humbled by facts.
It's roughly competitive with Python 3
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=yarv&lang2=python3
She loves me: 09F911029D74E35BD84156C5635688C0 She loves me not: 09F911029D74E35BD84156C5635688BF
No, hardware is cheap, relative to programmer time when the scale of the application (usage, complexity) is small, but the two scale very differently the operation gets larger. Programmer time scales linearly (if done right) as the application gets larger/better and hardware scales linearly (if done right) as the application usage gets larger. When both are increasing, as is the case in many real-world situations, you can blur the line between the two, but if usage grows much faster than the complexity of the application, you eventually have to address the problem with programmers rather than hardware, especially if your business model doesn't involve profits growing linearly with usage.
FWIW, at my company, we did an analysis last year as to how much we could save by moving from Java to Ruby for new features, since there have been people we respect that we've met at conferences who are/were Java proponents and have endorsed Ruby as something we should look into. The result was that based on the amount of traffic our app gets (lots...the Java version uses 15 beefy load-balanced app servers connecting to 4 replicated databases) and the size of our engineering team (5 full time), moving to Ruby would have increased our hardware cost 5 times what we pay programmers each year. Most apps that get as much traffic as we do employ 20 or more engineers, but our app is fairly simple and a lot of our work goes into tuning the application to perform better.
Now I'm not saying that our case is the norm...far from it. However if usage increases much faster than the amount of engineers that it takes to maintain/improve the application, the statement that "hardware is cheap" can definitely be false. Hardware is only cheap relative to programmer time in the right circumstances...the more hardware an engineers code runs on, the more value you get from their time. And anyone making these kinds of decisions should remember that.
I have never in my life seen a problem made simpler by changing languages rather than downloading a library.
Presumably you're not familiar with a great range of languages, then.
Say you want to make a bag in Java:
Whilst in Ruby:
And in Clojure:
But short examples like this can't really capture how much languages differ when used in large projects. Different languages open up entirely different ways to abstract a problem. In Ruby you can write methods that generate methods for other classes. In Clojure and other Lisps, there are macros which rewrite the syntax tree at runtime.
These sorts of features create abstractions that simply don't exist in other languages. There are whole classes of solutions that are simply impractical to use in some types of languages. I've written a few thousand lines of Clojure code, which is quite a lot for the language, and very little of what I've written could be easily translated back to Java.
in java i would just use the bag class from apache commons. bad example ;) I mean i got your point, ruby is good in implementing containing data structures because of the blocks, but do you really think a project gets developed faster because a language has blocks and closures? I've experienced quite the opposite...if you start using a language that is particularly good in one thing, every problem gets resolved by using this one thing. Especially in ruby, where you have to use blocks which are quite unreadable for everything or you're a noob (just google for a software problem and add "ruby way" to the query).
On second thought, let's not go to Camelot. It is a silly place.
OK, this is getting a bit off topic, but Yuki Sonoda is also a character in the Megatokyo web comic. In the comic, she's a 15 year old whose only geek credential is that she collects ancient video game platforms.
Quattuor res in hoc mundo sanctae sunt: libri, liberi, libertas et liberalitas.
I mean i got your point, ruby is good in implementing containing data structures because of the blocks, but do you really think a project gets developed faster because a language has blocks and closures?
Certainly. When I program in Ruby, I use blocks regularly. Assuming that I am not a closure fanatic, then presumably I have a reason for using them. If they didn't reduce development time, I'd do without.
Especially in ruby, where you have to use blocks which are quite unreadable for everything
Personally, I find blocks make code more readable:
Compared to:
Blocks are also more concise. It's my opinion that the more readable code you can fit in your editor window at any one time, the better idea you can get of the whole program. A function that is more than four lines of code is a big function in my book.
There's a guide around (http://frozenplague.net/2009/01/ruby-191-rubygems-rails/) about how to get some gems to work with Ruby 1.9.1. This involves a little bit of editing around, but generally they do work.
Did you read the article I linked to?
-- The act of censorship is always worse than whatever is being censored. Always.
You're emphasizing the wrong things.
For example: scaling isn't a language issue. A system can scale if it can keep working once it grows beyond what some constant set of hardware can support. Whether a system can do that is entirely a question of architecture; choice of framework will have some impact, but language won't at all. Micro-benchmarks of page generation times have nothing to do with scaling at all, except maybe at the absolute upper end. Even reasonably slow page generation times shouldn't be your bottleneck in a non-trivial system.
The important thing that you're missing is the force multiplier of using a more powerful language. The single largest expense in most software development projects is developers. Anything that lets less developers get more done sooner is hugely valuable - and skilled developers with a powerful language will, in practice, get more done faster than skilled developers with a less powerful language.
-- The act of censorship is always worse than whatever is being censored. Always.
Scaling isn't a language issue normally but in the case of Ruby, it seems to have an inherent flaw with it's threads which causes it to 'top out' in comparison to other languages; while PHP, Perl and Python continue to fulfill requests, Ruby 'tops out'. For example, as PHP determines a need for more processes, it scales up to handle more concurrent requests. Ruby can't and will top out and just queue them up. Getting more done with less is great no matter what the language and this can be done in all languages... it's called a framework, libraries, patterns and experience. But that has nothing to do with what we are talking about. We were talking about scaling not a languages usability.
This is my sig. There are many like it but this one is mine.
But you'll never solve a problem quicker by using a language you aren't as familiar with
I think the GP is trying to tell you that you need to get familiar with that other language. It takes more time, and for a good reason. You won't just be learning a new API, you'll be getting used to a new way of thinking. And programming is all about knowing the different ways of thinking.
http://zero-to-enterprise.blogspot.com/
That's just a deployment issue. It's definitely easier to get a single-server PHP deployment right - give or take secure permissions - but that doesn't mean that a properly set up RoR install can't take full advantage of a server's resources; mod_rails even does dynamic process allocation if that's what you really want (for Rails applications where "scaling" matters, you may not actually want that).
Honestly, I don't like the deployment story for either Rails or PHP, but again - that shouldn't be a major criteria for selecting a language. Developer productivity is much more important.
-- The act of censorship is always worse than whatever is being censored. Always.
I don't buy it.
I consider myself a moderately experienced C programmer, and by the time I'd been using perl for twenty minutes, I was doing better string manipulation in perl than I do in C. Even now.
Language matters.
And PHP is a sucky language. It's everything you'd expect from a language thrown together with bits and pieces tacked on as people found uses for them, and may never be able to get rid of that cruft without breaking so much code that, well, there'd be no point using it -- as you note, the real point is the availability of support code.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
So basically you're pissed that your hobby language (and make no mistake, that's all Ruby will ever be)
Some hobbies are quite profitable.
there are more "unimaginative programmers" who know it thus allowing business to move forward with doing actual in an attempt to make a profit.
That is why I tend to move towards small businesses and startups. You don't need those "more programmers" -- you need the five or ten programmers it will take to get the job done. More than that is just people warming seats.
But then, PHP makes it so easy to botch the job the first time, you can pretty much guarantee there will be more programmers back to warm seats.
And no, I'm not really pissed about it. Actually, I'm happy about it. See, I know PHP, so I can use it if I have to. I also know Ruby, and there are fewer people who know Ruby. That makes me valuable -- and it makes the one startup out of twenty that's using Ruby instead of PHP that much more likely to succeed.
You'll always a cog in the machine.
I've never been a cog in the machine, not in my working adult life.
You don't understand business, that much is obvious.
I'm not paid to. I'm paid to write good code, which I can do more effectively and more productively in Ruby than in PHP.
Don't thank God, thank a doctor!
Why would I as a business be expected to switch to a language that requires twice as much hardware?
Because it requires half as many programmers, and hardware is far cheaper than programmers.
What you MAY save with software dev speed, you now lose with day to day server maintenance.
Server maintenance? Ah, I see, you're well behind the times.
See, I can fire up another Amazon EC2 instance with a single command, or automatically from a script. And since I assemble and manage them with scripts, once I get it past a single instance, it takes exactly as much effort to manage twenty as it does to manage two.
And your comment about "moving parts" is equally dated, if you're thinking in terms of likelihood for a CPU to fail. Once I've got two, if either fails, the other can notice and fire up a new instance, killing that one. Failing hardware then becomes Amazon's problem, not mine.
And seriously, day to day maintenance? Haven't touched the 3mix server in over a week. If you have to perform manual maintenance on a production server every day, you're Doing It Wrong.
The key to good engineering is to simplify because the more parts, the more chance of failure.
This is true of code, also. Fewer lines of code means fewer moving parts. Ruby commonly means fewer lines of code.
when similar languages such as PHP, PERL and PYTHON can do it with far less hardware is not a very good solution.
Can they, though? Follow the link in the post you're replying to. Ruby is not significantly slower than PHP in real-world benchmarks -- in a few of them, it's significantly faster.
Don't thank God, thank a doctor!
The idiom of "let's throw more hardware at the problem" is a way of saying "we don't know jack shit about how to build a scalable web application,
You're misusing the word "scalable". You probably mean vertical scalability, or performance.
And it's not saying we don't know how to build a performant application. It's saying we don't care, because programmer time is more expensive than CPU time. It's simply not worth it to optimize past a certain point.
you're looking for a miracle since it's a known fact RoR doesn't scale very well.
Citation needed.
Also, you are again talking about vertical scalability. Rails is actually excellent at horizontal scalability, which means, specifically, "Can we throw more servers at it and have it just work?"
Not every PHP app can do that. Nor every Python, or Java app. However, unless you do something stupid, every Rails app can be scaled by throwing hardware at it.
Keep in mind, you will have to do this at some point. No Amazon, or Myspace, or Google, is going to run off a single server, no matter how massive. They all have to scale horizontally. You have to address that problem sooner or later.
So, I'm arguing that horizontal scalability is more important than vertical scalability. Horizontal scalability means you can ultimately handle as much traffic as you can find hardware for. Vertical scalability means you save some money on hardware -- that's all.
just following the RoR hype of it being the best thing since sliced bread, which it's not.
No, it's not, but it's still pretty damned good.
Hype does not automatically make something a bad idea. Does anyone remember the hype about AJAX? I think most Rails hype is tame compared to that, but as it turned out, AJAX is pretty useful. It's not the Best Thing Ever, but it's still useful.
If you can find where I've said Rails is the best thing ever, please, point it out. Otherwise, please try to reply to just my post, not every Rails developer ever.
Don't thank God, thank a doctor!
if usage grows much faster than the complexity of the application, you eventually have to address the problem with programmers rather than hardware, especially if your business model doesn't involve profits growing linearly with usage.
However, there should be some amount of profit which improves linearly -- why wouldn't you throw some Google ads on the site?
As for usage growing faster than complexity, we generally call this "A nice problem to have."
Now I'm not saying that our case is the norm...far from it.
And I'll concede that there are many situations outside the norm, which is why I would love to see Ruby get faster. I see nothing in the syntax and behavior of either language to suspect that Java should automatically be faster than Ruby.
But for now, there's still embedded systems, mainframes, operating system kernels, console video games, and many, many other places where a language like Ruby isn't even remotely appropriate.
I will make one more argument: Every greenfield app should probably at least be prototyped in something like Ruby. If you find yourself in a situation like you've described, you can always rewrite in another language. But since it's a greenfield app, what you want to avoid is letting a competitor get their version out the door before yours, even if your version is more efficient than theirs.
I'm curious whether you considered JRuby?
Don't thank God, thank a doctor!
With Perl 6 being released later this year I'd say that it is a waste of time even reading this article. Better to get ready for the tidal wave which will be the return of Perl.
C/Java/Whatever doesn't require the newlines ... if you prefer non-newlines then:
...now the only real difference is the fact you are declaring what types are in the list, something ruby/python/perl can't do and is one of my biggest annoyances with python (don't do ruby).
ustr: Managed string API with ave. 44% overhead over strdup(), for 0-20B
But now you are comparing RoR (language + framework) to PHP (language). Bad comparison. Thats like comparing a submarine to a volkswagon. I was strictly comparing languages based upon benchmarks of the languages and NOT the frameworks.
I'm willing to take a second look at Ruby but to date it has always come second as a web language for speed, scalability. And the only argument people provide for using it is 'you can develop faster'; well you can in ANY language given a good framework, proper training, knowledge of patterns, etc etc. The thing Ruby DOES provide that enable you to develop faster (like obfuscating looping and stuff like that) unfortunately is also it's achilles heel and causes extra processing to occur causing it to be slower than other languages doing the same tasks.
Now speed and scaling may not be top on your list but when you get your product built and you start to get popular and are getting a couple million hits a day and can't afford all that new hardware yet, and the platform you chose can't keep up, then it becomes an issue. This is why people make a big deal about it. Having working for Amazon as a startup, we doubled our business every month for the first two years from 95-97!!! Ruby would never have been able to accomplish that and we would have had to constantly be replacing and buying hardware. There has to be a stabilization point.
For now, Ruby is GREAT as a small mom-n-pop solution and for smaller shops that don't expect big growth (as long as they can find the developers and tools). But it is not yet ready for large to enterprise deployment and even for that reason, I would stay away from it for medium size businesses due to expected growth. However, with every iteration, it is becoming more and more mature and I expect they will work through these issues in the next 3-5 major releases.
This is my sig. There are many like it but this one is mine.
Which is exactly the attitude that's keeping things from scaling (regardless of whether I'm using this word in it's proper context, sorry, English isn't my native language) -- because you don't care, so why care at all about optimising when well, you can just throw more hardware at it? Sooner or later you'll be spending more on hardware than you are on programmers. Besides, programmers that do not know how to optimise properly should either quit the job or go back to school and study some more.
Twitter.
Scaling is scaling, whether it be horizontal or vertical. Horizontal scaling only gets you so far in the long run as well. Then again don't take my word for it but I've seen that same "oh well we'll just throw more hardware at it" solution blow up in some seriously interesting ways.
Vertical scalability also forces you to know what you're doing when it comes to algorithms and such things. I know, I know, I'm probably a horribly oldfashioned cunt by saying it, but really, if you're going to build a car, you might as well build yourself a fast one instead of a 10 ton truck being powered by a 2 stroke 40hp diesel engine and say "well we can always throw more engines in here".
I'll admit it's good, but the problem comes from people who blindly follow the hype and will claim that RoR IS the best, and can do it better, and what the hell do us old Perl writing coots know anyway. I don't want to go and compare experience e-peens, but my comments on scalability are based on some interesting observations in the past.
Did I say you said rails is the best thing ever? I didn't. Why bring it up in the first place?
There is no sig...
That's even less useful, because then you're just comparing a well integrated Apache module to basically nothing. There are well defined deployment solutions for Rails, not so much for Ruby without a framework.
For any business that isn't planning on going from nothing to the Dow Jones in less than a decade, the business numbers for performance come out quite a bit different. Even if you're only going to get as much traffic as Slashdot, servers are still cheaper than developers. Assuming that you're going to be the next Amazon or Google and wasting money preparing for that early is simply a bad business decision.
Do you have any argument or reference to support your claim that language choice doesn't matter to development time, or are you just going to keep asserting it?
-- The act of censorship is always worse than whatever is being censored. Always.
C/Java/Whatever doesn't require the newlines
It's still more verbose, and you can't chain for-loops. You're also limited to built-in looping structures; there's no support for folds or the like.
...now the only real difference is the fact you are declaring what types are in the list
Types are useful, so long as you have a decent type system. Unfortunately, Java has a very poor type system. I wouldn't necessarily say it was the worst type system ever devised, but it's certainly in the top 10.
It is a practical means of transportation in some but not other environments, it is supposed to be good for you and it is Politically Correct, people seem to think they can pick it up with a minimum of skill and many do, but you would have a whole heck of a lot more fun if you were on downhill skiis or on a snowboard and knew what you were doing.
``You're assuming that it really will be faster to do a project in $newLanguage.''
I am assuming that the development time isn't equal for all languages. I find the contrary assumption (there is no difference in development time among all languages) absurd.
``I have never in my life seen a problem made simpler by changing languages rather than downloading a library.''
That may be so, but this requires that said library exist. That won't always be the case. And what if you actually wanted to write such a library?
``If you want to dispure my point you need to prove the assertion that it isn't so, not just throw some pseudomath in a post.''
I agree that pseudomath doesn't prove anything. On the other hand, the burden of proof isn't on me; you were the one making the original assertion, so the burden of proof is on you. Having said that, there are studies that compare development time across programming languages. One example is "Lisp as an Alternative to Java" (PDF), which finds that development time differs among Lisp, Java, and C++.
Please correct me if I got my facts wrong.
``do you really think a project gets developed faster because a language has blocks and closures?''
Yes.
``I've experienced quite the opposite...if you start using a language that is particularly good in one thing, every problem gets resolved by using this one thing.''
Yes. This is why languages like Ruby are good, and languages like Java are bad. In Ruby, you have simple and powerful constructs that you can pick and choose from; use the ones you like and ignore the rest. In Java, you have no choice but to use classes, and many useful things are lacking from it.
Please correct me if I got my facts wrong.
Rails wasn't Twitter's problem, though there was some initial finger pointing in that direction. The problem was that Twitter initially had a simple synchronous architecture (which, sure, is the easiest thing to do with Rails, as with most frameworks) when it needed an asynchronous messaging architecture, and that they didn't do database optimizations that are out of scope for the web application framework. See, among other things, this article.
Yes.
Since Ruby blocks are structurally pretty much identical to Ruby method definitions, which are themselves pretty similar to function/method definitions in most vaguely C-like (or Algol-derived, if you prefer) languages, I find describing them as "quite unreadable" to be rather odd. If you have a lot of programming experience but none of it in other languages where passing around anonymous functions as arguments is commonplace, it probably seems unusual at first and takes a little bit of time to get over that feeling, but I wouldn't think it would be too big of a barrier for most people.
Sooner or later you'll be spending more on hardware than you are on programmers.
That generally happens later. Premature optimization is the root of all evil.
programmers that do not know how to optimise properly should either quit the job or go back to school and study some more.
The fact that I choose to focus on other things does not mean I don't know how to optimize. Knowing when to optimize is what's important.
I'll quote it again: Premature optimization is the root of all evil. Above all, build a clean, maintainable architecture. If you find out that certain parts of it are too slow, then you start to optimize -- ultimately, you may end up writing some parts of it in C. But when you've got enough traffic that you have to do that, you've got a nice problem, maybe enough money to hire a full-time person who's job is to optimize.
At the point where you've got a thousand servers, a 10% performance gain is a hundred servers you no longer need. At the point where you've got ten servers, a 10% performance gain is only worth it if it takes less than, oh, three hours, given the going rate for dedicated/virtual servers.
And chances are, again, that at this point in your lifecycle, you would probably be better served spending those three hours working on the app itself, to get it out the door.
Obviously, there are exceptions. If you're slurping an entire table into RAM, you're Doing It Wrong, and you're probably only saving yourself a few lines of code, or a few minutes reading SQL documentation.
Twitter.
Aside from the demonstrated fact that Rails wasn't their scaling problem, there's also the part where they still seem to be running Rails, and they still seem to be doing alright. (Correct me if I'm wrong on either of those.)
For that matter, Twitter also demonstrates exactly why you should put off the scaling issue. Twitter now has enough traffic and enough money that they should be able to rewrite from scratch if they have to. Others have tried to make better, more efficient Twitters, but so far, Twitter has first mover's advantage -- everyone is using Twitter, so why would they switch to something else?
It's the classic "worse is better" argument. If it takes you twice as long to get to market with a solution that's twice as efficient, all the money you've saved won't buy back the customers you lost to that first mover.
Horizontal scaling only gets you so far in the long run as well.
It depends what kind of app you're building, but if horizontal scaling works at all, you should be able to continue to scale horizontally as long as you have money to throw at it.
Contrast with scaling vertically, where you have to wait for Moore's Law, which may never kick in for you if you haven't designed for multicore. (Conversely, a horizontal scaling architecture, you can just spawn an instance per core.)
I'll admit it's good, but the problem comes from people who blindly follow the hype and will claim that RoR IS the best, and can do it better, and what the hell do us old Perl writing coots know anyway.
Perl, I get along with just fine. Python, I have no problem with. Erlang or Smalltalk, I have some respect for.
It's people who do PHP just because it'll supposedly be easier to hire crappy programmers, or Java because it's what Big Business uses, that get on my nerves. Especially people who use C because they need performance -- a web app written in C very likely belongs on thedailywtf, unless there's a very good reason for it.
Did I say you said rails is the best thing ever?
What you said was, specifically, other languages seem to have more people who know what they're doing, instead of just following the RoR hype.
See, I don't think I was "hyping" Rails. That's why I said, please reply to my comment, and not to "the Rails comm
Don't thank God, thank a doctor!
Server maintenance? Ah, I see, you're well behind the times.
Where the fuck do YOU work?
And your comment about "moving parts" is equally dated, if you're thinking in terms of likelihood for a CPU to fail. Once I've got two, if either fails, the other can notice and fire up a new instance, killing that one. Failing hardware then becomes Amazon's problem, not mine.
And seriously, day to day maintenance? Haven't touched the 3mix server in over a week. If you have to perform manual maintenance on a production server every day, you're Doing It Wrong.
"server"? "Server"? As in ONE server?? You know half the geeks reading this site work with hundreds of them right? Do you know what happens in a given day in environments with 100+ servers? All Hell breaks loose. There is ALWAYS something that needs to be fixed or monitored better.
if you're thinking in terms of likelihood for a CPU to fail. Once I've got two, if either fails, the other can notice and fire up a new instance, killing that one.
Damn dude, you know there are just a _few_ organizations out there that are running more than a couple web servers right?
Really, the only thing dated here is you. We've pretty much narrowed you down to an arrogant young student somewhere. Get a real IT job before running your mouth off like servers don't need maintenance, complex environments can be controlled from a little script, or things that claim to failover actually do.
"server"? "Server"? As in ONE server??
Company is out of money, so yes, only one.
One which needed maintenance (other than updates) exactly once in its lifetime. And updates can be scripted.
Damn dude, you know there are just a _few_ organizations out there that are running more than a couple web servers right?
Point is that once you've got two, the model works. A few hundred could be done with the same principle -- when one goes down, spawn another.
Get a real IT job before running your mouth off like servers don't need maintenance, complex environments can be controlled from a little script,
In the very real IT job I had (until the economy imploded), I actually didn't do a lot of IT, mostly because, as much as you'd like to mock it, complex environments can be controlled from scripts. Those scripts aren't necessarily "little", but they get the job done.
When I can type one command to provision, boot, and configure a server, and with a little tweak, that command could do the same to n servers, no, there's not really a lot of maintenance. If they were 100 servers, each doing something completely different, you might have a point. But if they're 100 servers running the same app that, more efficiently coded, might run on 20 or 50, it really doesn't take any more effort to run 100 servers than it does 20.
Don't thank God, thank a doctor!
Ruby 1.8.x uses green threads in a single process per interpreter instance, JRuby uses Java threads (which are native threads on most or all platforms, IIRC), Ruby 1.9.0/1.9.1 use native threads with a GIL, exactly, AFAIK, like Python up through and including 3.0. Each of these Ruby implementations will have different threading performance.
Of course, none of that matters for Rails, which is probably where the issue you are talking about arouse rather than Ruby itself, since Rails is still, AFAIK, single-threaded throughout, with experimental threading support.
Every Ruby implementation contains support for spawning additional processes, though deciding whether and when to do this isn't a language function, its an application (or framework, or even application server) function.
PHP is a language a templating system designed very much for building web applications.
Ruby is a general purpose programming language, that is largely popular due to a particular web app framework.
Comparing bare Ruby with no non-standard libraries to PHP for web apps hosted behind another server is at least as bad of a comparison, and arguably far worse, than comparing RoR to PHP.
I've yet to hear a coherent argument for how Ruby fails at scalability compared to any other language, whether PHP or anything else.
Ruby doesn't obfuscate looping. I have no idea what you mean by "stuff like that" other than "other stuff that isn't true, either".
Ruby can be a rather fast language. As fast as Python at least. For more complicated problems I sometimes find it faster than C, att least without making the C code very hairy.
With very little effort you can make a slow program that solves a very complicated problem. If it's too slow, it's not hard to make it faster (but you have to have a clue what goes on inside the interpreter), writing that first slow version and then optimise it to the speed of Python is easier and less time consuming then to write one Python version. And you can start coding before you have a clear idea of what to do.
It's like making an oil painting, you start with that greasy coal sketch, then a greasy oil sketch, repaint, repaint... and then before you know it, it's finished. You could do a better painting in watercolour, if you know more or less exactly what you want to do (or make time consuming preparations), and it would be done slightly faster, if you know more or less exactly what you want to do, but if you don't know more or less exactly what you want to do, you get a horrible painting. I usually prefer faster techniques when I paint (like watercolour, pastel and tempera), but thats because I usually know exactly what I want to achieve. If I don't have a clear picture in my head, nothing beats oil (actually that would be digital painting, but that canvas has to many limitations). When I make a program, I like to think and code at the same time, then Ruby is an excellent tool. If I know exactly what to do then I use C, not Python.
An apache module??? What are you talking about? Perl, Python and PHP vs Ruby??? You selected ONE while I am broadly comparing and naming examples. But to go with your example, I believe you are talking about PHP which was designed to be used as an Apache Module and not as a standalone and as such will always suffer a startup loss of time vs any language since it does not stay running as a daemon in the background. Hence people benchmark it as an Apache module.
Now back to less whining and more comparing of languages...
And sys admins are to maintain all those those servers you are buying are equally cheap. How about the DBA's? etc etc. Everytime you overly complicate your architecture, you extend your cost. The Ruby answer has always been 'so we're slow... throw hardware at the answer' and that has not been a solution for companies that get to a medium size and can no longer afford maintenance or the staff to maintain.
Additionally, Ruby devs seem to think they have a 'MAGIC LANGUAGE' that allows them to develop so fast that all other languages are absolete. Got news for you... all languages have MVC frameworks, all languages can use patterns. These are not new concepts. Ruby is not fast for development. It is merely fast for newbies picking up a language who have never programmed before. And that's even more dangerous because they don't understand the fundamentals of what they are doing.
This is my sig. There are many like it but this one is mine.
The same one sysadmin can handle four web servers instead of two, or eight instead of four. A slow interpreter doesn't make the database any slower, so the DBA bit is irrelevant. The application will probably be limited by something other than interpreter speed anyway; needing more servers at all is just absolute worst case.
You're making this assertion - that language doesn't matter to development speed - for the third time. It's blatantly wrong. Consider assembly language vs Python. The reason that Python is more productive is that it allows for more abstraction and less code. Ruby allows for more abstraction and less code than PHP does, and therefore will be faster to work in. Libraries and patterns don't change this - again, clearly demonstrated by considering Assembly (or C).
-- The act of censorship is always worse than whatever is being censored. Always.