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."
No wifi, garbage collection not as good as Lisp; Lame.
They don't need to be compettive on performance. They just need to improve performance to "barely tolerable slow" as opposed to "intolerably slow".
Too busy to just google for 2 sec before spouting off? .Net , or pure Ruby
Rubinius>Rubinius all aimed at among other execution speed.
Here is jRuby using java VM , Maglev using Smalltalk VM , IronRuby using MS
Help fight continental drift.
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.
all of them?
Python is skiing and ruby is snow boarding. One's more fun than the other but they are more similar than different.
that is asking for a bloody long post that will boil down to. The ruby syntax is cooler yet more obscure, the vm is slower but just because there is less money behind it. It must be nice to have a big company like Google behind you. *scoffing at the php fans and their Zend touting* (PS, im a python fan) when I say that the syntax is cooler, i give the example that the for loop is implemented as a call to an iterator so you get this http://refactormycode.com/codes/2-ruby-simple-loop.
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.
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?
You know, you have a point. I think all dynamic languages could probably learn something from the recent Javascript speed-up projects...
Except Ruby isn't slow.
And yes, I am happy about it being twice as fast, because it was already fast enough.
Don't thank God, thank a doctor!
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!
So in other words... if you want something decent and fast, use Java???
This is my sig. There are many like it but this one is mine.
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.
Sorry it wasn't clear. No it is Ruby implemented to run on a Virtual Machine. You write your Ruby code as normal and it gets compiled to byte code that run very fast. This is how Java is fast. Ruby can in principle be as fast as Java. Ruby is not inherently slow just the current implementation is somewhat slow.
Help fight continental drift.
Ruby uses explicit 'end' to mark blocks, Python doesn't. Ruby uses OOP for pretty much everything while Python doesn't (i.e. [].length vs len([], [1,2,3].each{|i| ...} vs for i in [1,2,3]:). Python follows a philosophy of doing something exactly one way, while Ruby doesn't have a problem allowing multiple ways to accomplish the same thing. Ruby uses $ to mark global variables, @ to mark member variables, Python uses explicit 'self.' to do it.
Overall however they look and feel pretty similar.
Ruby is meant to be more comfortable and expressive in the hands of a programmer than Python. That means more power and more elegance, but also less regularity, more features, and more emphasis on conciseness instead of readability and learnability. (Python is surprisingly readable for non-Python programmers, which I have found handy more than once.)
Personally, I use Python at work because I'm terrible at remembering linguistic features and syntax. At work almost every neuron in my brain is devoted to C++, so for everything else I need a nice, simple, even stupidly simple language that complements C++. Plus if someone inherits my Python code and says *gasp* "But I don't know Python!" I can honestly say, "Don't worry, you have nothing to worry about. You can learn it in a couple of days."
People tell me Ruby is more natural and expressive, and I believe them, but if Python ever lets me down I'm skipping straight to the Red Pill, aka Lisp, which I have enjoyed recreationally on occasion. (I keep some spare neurons for myself for fun. Don't tell my boss.)
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.
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?
Big disclaimer: Perl does as well. Ruby differentiates itself here by disallowing infinite ways.
ROMANES EUNT DOMUS
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!
JRuby is an interpreter, written in Java. It does not compile Ruby to Java bytecode.
Incorrect. I certainly DOES compile Ruby to Java bytecode. Read the blogs of Charles Nutter, John Rose and Ola Bini for more information.
Being bitter is drinking poison and hoping someone else will die
So in other words... if you want something decent and fast, use Java???
Pretty much, yes. Welcome to the 21st century.
Being bitter is drinking poison and hoping someone else will die
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...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=php
Except that slideshow is comparing the performance of popular frameworks for different languages. So they're showing that Rails is an efficient framework. That's a perfectly valid point to make (the language makes it easy to write a better algorithm, or maybe the framework is just more efficient), but it doesn't say anything about how fast the code is executed.
I switched from Perl to Ruby as my everyday sysadmin and glue language, and I use it pretty extensively. I love Ruby, but I won't try to handwave away its faults. In my usage, it's undeniably, dramatically, slower than Perl. We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
A script to parse a huge, complex data file sucks ten times as many CPU cycles to do the same work. For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
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.
Here's my take, having used both languages in anger. First off, let me call out a number of similarities between these languages. They're both OO, dynamic, and provide reflection capabilities (useful for meta-programming). They've both been influenced by functional languages. They both have active, vibrant user communities. Both have many open-source and shipping commercial applications that leverage or are fully built on these languages. While there are notable syntactic differences, I find that there's a certain shared "feel" between Python and Ruby.
Now I'll call out the differences I find interesting. Python's import model (akin to #include for you C folk) is stronger than Ruby's require when it comes to larger applications. By "stronger", I mean that it's more explicit and therefore provides greater assurance against unintended effects from referencing a different module/class/object than you intended. This is a two-edged sword, since Ruby's code loading approach is less verbose and affords the construction of tools like Rails' Dependencies module which automatically finds code via a convention-over-configuration model. (e.g. calling require is never needed for the main application code of a Rails application if you just follow the file vs. class naming conventions -- this is *very* handy, IMO.)
I'm big on powerful abstractions in programming languages. On this count, I find that Ruby wins hands down. The Python community has had a muddled approach to some key areas that Ruby had early clarity on via lessons learned from Smalltalk. Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python. Blocks are nothing more or less than anonymous functions, aka "lambdas", but their beauty lies in their syntatic integration. Consider the Ruby iterator pattern:
... end construct is a block. a is a Ruby Array object. The conventional iterator method each calls the block once for every element in order, as you'd expect. The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
a = [3,4,5]
a.each do |x|
puts x
end
The do
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer. Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
class File
def File.open(name,mode)
file = File.new(name,mode)
if block_given?
begin
yield
ensure
file.close
end
else
return file
end
end
end
And the list of uses goes on and on. Blocks are a foundation component that makes Ruby well-suited for writi
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!
That doesn't do the same thing at all, and won't do the same thing in the incompatible Python 3 as in Python 2. The Python equivalent to that Ruby would be:
for i in range(1,11): print i
The Python is more readable, but the operation of Python's range(1,11) is a bit less obvious than Ruby's (1..10).each IMO.
Certainly better performance is a Good Thing, everything else being equal, and in some projects execution speed is vitally important. For a great deal of purposes, however, Ruby's speed is more than adequate. Its benefits easily outweigh the cost of irrelevantly being slower than some other languages in such cases.
It has always been 'fast enough' for appropriate programming problems. If Ruby is too slow, you're in the wrong problem domain to use Ruby.
Note that there is, and can never be, OneTrueLanguage(TM).
Efficient development is all about playing to the advantages of the development tools available to you. Complaining about weaknesses is usually indicative of a lack of understanding.
John_Chalisque
So now it's only "really slow" as opposed to "really really slow"?
It's really really simple: a speed improvement of a factor x means you multiply the number of "really"s by 1/x.
Had it been three times as fast, it would have been merely "real slow".
If you're ever reduced (hah!) to fractions of a single letter, just scale the ASCII value of that letter. So if it was 24 (=2*12) times as fast, it would be half an r, or "8 slow".
It has always been 'fast enough' for appropriate programming problems. If Ruby is too slow, you're in the wrong problem domain to use Ruby.
Note that there is, and can never be, OneTrueLanguage(TM).
Efficient development is all about playing to the advantages of the development tools available to you. Complaining about weaknesses is usually indicative of a lack of understanding.
Very true. Should not stop you working on them, (weaknesses) tho'. A lot of progress is driven by criticism - constructive or otherwise.
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.
[ruby is more OOP than python:] [].length vs len([]), [1, 2, 3].each vs for i in [1, 2, 3]
Given my understanding of OOP, those are not particularly good examples.
len([]) is equivalent to [].__len__, a method invocation on the object in question. Different classes can define different __len__ methods.
for i in some_object calls some_object.__iter__ behind the scenes; same thing again: a method with different definitions across different classes.
What defines OOP is not where you put the dot, but what the dot means, which roughly speaking is the method lookup in a vtable. Ruby and Python both do that, so they're both OO. Python just puts a little syntactic (and semantic) sugar on it.
Something I'm more likely to agree with: Python and Ruby are both more OO than C++ with respect to the collection classes.
Why is that? Because (for example) vector.size and set.size aren't overridden versions of (a hypothetical) collection.size.
In Haskell parlance (note: "class" means two different things in C++ and Haskell), the code
...
template <T> int foo(const T& t) { return t.size(); }
uses class-bound polymorphism with inferred classes. Meaning that the set of types T for which the code is valid is the class of types that have a size method. The inferred-ness (roughly speaking) means that you don't write template <T extends has_a_size_method>
If you still believe Ruby is more OOP than Python, could you point out either (1) another example, or (2) why you disagree with my thinking?
I hope one or more of us can learn something from this discussion :)
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.
Being "roughly competitive" with PHP isn't saying much...
Like saying "I'm basically as knowledgable as Joe the Plumber"
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.
It's much harder to hurt yourself badly on a snowboard... but of course you still can if you really try.
If you still believe Ruby is more OOP than Python, could you point out either (1) another example, or (2) why you disagree with my thinking?
The difference is that Ruby is OOP from the start and through and through, while Python get stuff patched in a little bit at a time with every new version. See Pythons print-statement vs Ruby puts for example.
OOP aside, another difference worth mentioning between Ruby and Python is that in Ruby the () for function calls are optional. So [].length works just as well as [].length().
via overflow.
--
Now, write that 100 times by sunrise or I'll cut your balls off.
I have a vast variety of [engines] where we [run] our [code].
No existe.
You really need to work on your form; this is at best a 2 out of 10 on the Ruby/Python trolling scale. Generally, you want to pick something that's subtly false, or which requires deep knowledge of the topic to expose the problem with the assertion, not something which is known to be false by folks who have even cursory familiarity with the subject.
Of course, it's not going to match C, OCaml or even Java in terms of speed. Speed isn't a strengh of dynamic languages, but that doesn't mean it isn't important and it is a weakness relative to Ruby's direct competitors (other dynamic languages and other implementations of Ruby).
Take the comparison of Ruby with Python on the language shootout:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=ruby
With a 2x increase there, Ruby is still behind Python (which isn't standing still) and not doing that well on memory usage either. That can be the difference between handling everything on one server, or buying two.
I still do Perl.
Half the reason is that Perl is a bit insane and breaks all language design rules -- but still works. That makes it fun. The other half is that the community is so good; CPAN is a result of that and, also, you don't have so much of that disgusting hype (like you just commented on); like you, I'd rather not be identified with a community doing that.
Ruby do look sweet and Python seems usable (if a bit boring). But with the "Perl Best Practices" book becoming so popular and Moose (et al), I can't motivate a switch. The largest problem with Perl today IMHO is that it takes a bit more time and energy to learn.
Karma: Excellent (My Karma? I wish...:-( )
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...:-( )
It seems that you are one of those who never really used it for any serious work. If you had - you wouldn't put this kind of comment. Ruby has already been pretty fast _for what it is meant and used for_. Of course - extra speed gain never hurts but the speed (while highly welcome) has not been the most important problem in the 1.8 versions.
I understand that you tried to be funny, insightful, informative, whatever with your First Post and there is not much time to seek insight knowledge before putting up the First Post...
Now, mod me down freely. My karma can't get any worse...
This line of reasoning is moot. Kernel is automatically required in Ruby, so the Kernel method calls are similarly included in the language syntax. Not to mention that a lot of methods Kernel has are put in separate modules in Python (exec, system, sleep, rand) or are methods of objects (split, chomp), so you could argue that Ruby is less OO than Python.
But either way, as I said, this argument is moot. Even if Python has automatically included methods instead of a single Ruby class of which all methods are included, so what? In Python you can override the few included methods (import my_pretty_print as print), in Ruby you can override your Kernel object and the methods you want to replace. In both languages it is (rightfully) bad form to do so and discussing the OO-ness of a language on such a level is as pointless as comparing dick-lengths.
Remember, it's how you use it that counts.
This sig is intentionally left blank
One has to wonder if you actually ski or snowboard. Other than the fact that they are both done on snowy downhill slopes, there is no similarity.
I am very small, utmostly microscopic.
you know, bad analogies are like a wooden banana.
I agree with you, except that :
len() is a shortcut for the __len__ method, which you can redefine.
>> [].__len__()
0
there is not do() method on iterables, however. (I think in this case it's more readable, but it can be debated)
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.
Um, it's pretty competitive against Python and PHP. I guess they're pretty much doomed against Smalltalk and JS too? Oh, wait..
What the hell are you talking about? None of what you said makes sense.
Slashdot is proof that Sturgeon's Law applies to mankind.
Wow, what does line noise look like in your reality?
Nope, I'm pretty sure neither of those look like line noise.
...snip...
Well, actually understanding what's going on does require a bit of knowledge of the way the languages work, but my point was that it's irresponsible to go from an assertion like "up until Python 3.0 print was a statement" to "Python isn't really object-oriented" or "Python's OO is just bolted on", because even a basic understanding of how Python works shows that to be false. Let's consider an easy example, a simple function which adds two numbers (Slashdot's comment system will eat the indentation of the function body, but that's neither here nor there):
You might call this function by writing add(2, 3), which would return 5. That turns into a method invocation, delegating to the __call__ method of the function, which is an object: add.__call__(2, 3). And that, in turn, expands into an invocation of the __call__ method of the class of the function object, with the function object passed as the first argument to get the self reference, and the rest of the arguments following: types.FunctionType.__call__(add, 2, 3) (all functions in Python are instances of FunctionType, which is accessible through the types module if you ever have a need to do things manually without resorting to Python's function-definition syntax).
From just this simple example it's clear that the object-orientation really does go all the way down, and that the existence of the print statement in older Pythons was a "bolted-on" wart of an OO language rather than being the other way around. The same is true for the other "special" statements in Python; these are not vestigial remnants of some non-OO language which got an object system tacked on, they are bits which were added on to an OO language for pragmatic reasons (print was turned into a function in Python 3.0, but assert and del, remain as special cases).
This also reveals a few interesting points of Python/Ruby comparison:
I like that. Is it original?
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++.
So what if it is? I run my whole business on ruby. Speed of execution is not an issue even in the slightest. But what is an issue is that I can make improvements and additions very quickly. *That* speed is very important to me.
Python's range() makes more sense if you look at it without an explicit starting value. range(5) returns [0, 1, 2, 3, 4] -- the legal indices for a list of five items.
Humans are lazy. We look for easy ways to compare things, even if the comparison is not actually valid. Comparing languages by their speed of execution makes little sense, but it can be boiled down to a number, and that makes it attractive.
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.
No.. just it's last SEVERAL incarnations that have been slow. That and a bunch of empty promises of how it will be faster and more scalable. One of these days they may deliver but by that time the other languages will most likely hav doubled THEIR speeds.
This is my sig. There are many like it but this one is mine.
... This is how Java is fast.
Java people always say Java is fast, but if Java is fast, why does EVERYTHING written in Java seem so slow? Do Java people just look at benchmarks and not ever look at real-world uses? This is a serious question. I'm constantly hearing that java is fast, and consistently seeing only (OpenOffice, Eclipse, ANY Java "applet" online) java being hideously slow?
"If it walks like a very very slow duck..", etc.
-- 'The' Lord and Master Bitman On High, Master Of All
We don't really disagree, but I'd quibble with a few points (In OO, the Moose/Mouse stuff seems to beat OO for all mainstream languages as of today; what a twist! Closures are cool and useful. Also, Perl 6 -- at last -- seems to grow into something really, really exciting.)
As I wrote, a good part of the reason I like Perl are the smart and interesting people in the community; I'd be plain embarrassed to stand with a crowd that do that kind of hype. (I'm not really sure it's the Rubyists that are those boring trolls, btw?)
Karma: Excellent (My Karma? I wish...:-( )
Yeah, other than the fact that they're both winter-time leisure activities involving strapping one or more long pieces of fiberglass to your feet, in order to make your way down a snowy slope, they're nothing alike!
And the parent got modded "insightful"? Sheesh.
> 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.
Consider the Ruby iterator pattern:
Having not used Ruby, I've never quite gotten why this is so special. The Python equivalent would be:
It's not creating an anonymous function, but it's doing the same work otherwise. Can you give an example of why the Ruby way is better? I'm asking genuinely; I'd really like to see what makes this cool.
The neat thing here is that it's easy and natural to implement your own custom version of each for your classes. By defining this one method, and including the mixin module Enumerable on your class, you get definitions for a bunch of other useful standard collection methods such as map, find, select/reject and so on.
What does that buy you over Python's list comprehensions or generator expressions?
Dewey, what part of this looks like authorities should be involved?
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...
I think the reason for the comparison is:
1) both are scripting languages.
2) People just assume that PHP is scalable. It runs Wikipedia, and lots of other huge sites. If Ruby can be compared favorably to PHP, then it's hard to argue that it's "too slow" to base a usable framework off of.
3) Rails people tend to have a bit of a grudge against PHP people. Play nice, children!
You want the truthiness? You can't handle the truthiness!
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.
Apps like Eclipse or OpenOffice are pretty massive though. You can argue other apps with similar functionality (Office, Visual Studio) are just as big and are much faster, but they have custom memory management and aren't compiled from bytecode. It's the price of running platform-independent software.
Oh yeah and I think OpenOffice doesn't run on java, just *with* it for extended functionality. The whole system is p bad though.
It means that people who rely on PHP can no longer use speed as a reason for continuing to use it.
I'd rather be lucky than good.
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?
Specifically, Ruby blocks are a single great primitive that covers the ground of a number of separate, less powerful entities in Python.
Blocks are covered by generators and with-statement. They are separate, but certainly not less powerful (and most Python fans would argue they are more intuitive).
a = [3,4,5]
a.each do |x|
Yeah,
for x in a:
print x
is so much less readble ;-).
The neat thing here is that it's easy and natural to implement your own custom version of each for your classes.
Yeah, and it's every bit as natural to implement python generators.
Now, Python provides for the special __iter__ method to allow user-defined classes to support iteration. But Ruby's block-based mechanism is fully general and available to the Ruby programmer.
... generators again ...
Blocks' utility goes beyond iteration, into a wide variety of other cases where anonymous functions are useful. Some motivating examples may be helpful. Another one from Ruby's standard library:
File.open('foo.txt','w') do |f|
f.write(some_content)
end
This illustrates the Ruby idiom for resource cleanup. Here we're guaranteed that the file will be closed after the block runs. The implementation of open isn't magic, it can be expressed (**simplified slightly) as:
This is why Python has "with" statement now. Can you bring up something that is *not* covered by with statement or generators? No?
I know this is a bad idea on ruby fanboy thread, but all of this post is just a strawman that is reminiscent of typical rubyhink (i.e. comparing ruby against an obsolete version of Python).
Ruby guys should stick to comparing ruby against Java, it will be a much easier crowd to attract. People familiar with Python are typically much less impressed by these antics.
Save your wrists today - switch to Dvorak
The ruby 1.9 is to python roughly as Java -server is to c using gcc (ratio of about 1.5). This is not "totally unusable" when comparing Java to C. The interpreted languages are all within one order of magnitude slower than the compiled languages. This does not change much, and people are still happy to use interpreted/dynamic languages because of the increase in development agility and lower time to solution.
Languages aren't inherently fast -- implementations are efficient
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
IMO, Ruby's use of blocks is simpler, cleaner, and more elegant than the variety of Python techniques that cover different parts of what Ruby does with blocks. But, largely, its subjective.
...and currently modded "Informative." Yay Slashdot.
Reality is the ultimate Rorschach.
they're hard to eat?
``speed (while highly welcome) has not been the most important problem in the 1.8 versions.''
Actually, for me it is. Speed, unpredictable performance, and the huge memory overhead of (what should be) small objects. Note that these are all implementation issues; all can be improved without having to change the language proper.
Please correct me if I got my facts wrong.
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.
Actually, Python's OO was pretty much "just bolted on", but that happened several iterations of the language ago. Somewhere before 1.4. Possibly before 1.0. (I wasn't there.) As of 1.4, however, the bolting on process was still pretty evident. It's become less and less so with each iteration, until now the interface is pretty smooth. You can still see a few cracks here and there, though possibly with Python3 those will have disappeared.
Python isn't, and never tried to be, Smalltalk. literal numbers haven't been objects. (Possibly they are as of Python3.) This has been for the sake of efficiency, but it's lead to several cracks in the syntax, and many special cases. (Not as many as C++, though. Not nearly as many!)
I think we've pushed this "anyone can grow up to be president" thing too far.
I do both and disagree--they are similar.
Programming in python and ruby, or snowboarding and skiing ?
Python doesn't do inclusive ranges?
It's quite handy for zero-based indexing. It's also convenient for splitting a big list into a bunch of little ones:
[a, b) = [a, a1) union [a1, a2) union [a2, a3) union [a3, b)
Literal numbers have been objects since Python 2.2, which was released on the 21st December, 2001.
>>> dir(4)
['__abs__',
'__add__',
'__and__',
'__class__',
'__cmp__',
'__coerce__',
'__delattr__',
'__div__',
'__divmod__',
'__doc__',
'__float__',
'__floordiv__',
'__format__',
'__getattribute__',
'__getnewargs__',
'__hash__',
'__hex__',
'__index__',
'__init__',
'__int__',
'__invert__',
etc.
You can create subclasses using class foo(int). Everything is an object in Python.
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.
OpenOffice was big and slow long before it accumulated a nontrivial amount of Java code. The OpenOffice wiki lists exactly which functionality depends on the JRE. I don't see anything performance-critical in there. (Oh, and how did I know that? Because I've seen your argument debunked so many times on Slashdot it isn't even funny.)
As for Eclipse, I really don't understand. I have used Eclipse to write Eclipse RCP apps, and it's pretty miraculous the way it handles its own source code -- thousands of source files in many dozens of packages. If you compare IDEs by how quickly they pop up the "Print..." or "Save As..." dialogs, then Eclipse might rank near the bottom, but on large projects, I worry more about the performance hit of navigating, compiling, searching, and refactoring thousands of files. Eclipse does very well by those standards.
Eclipse support for C++ sucks ass compared to its Java support, though. If you tried developing C++ code in Eclipse then I'm sure it disappointed, but the problem there is not Java but the fact that C++ is not a big development priority for Eclipse.
Ruby still beats ASP.NET and Flex for speed and style, and it runs on Linux!
Did you read the article I linked to?
-- The act of censorship is always worse than whatever is being censored. Always.
Except that slideshow is comparing the performance of popular frameworks for different languages.
I believe it also does a comparison of a raw Rack request versus a non-cake PHP page.
I won't try to handwave away its faults.
Neither than I -- only pointing out that most people aren't even doing benchmarks. It's just accepted that "Ruby is Slow". I'm not saying it's fast, but I am saying that when you say things like this:
We're talking order of magnitude here, not marginal stuff that only shows up in benchmarking.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial. They'd also be great to establish this point:
For what I do, that's OK, because the ten minutes to run the job is completely dwarfed by the development time saved by using a sane language.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and the Perl script is ten times faster, that would pretty clearly show the advantages of each language.
Don't thank God, thank a doctor!
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.
>>Being bitter is drinking poison and hoping someone else will die
>I like that. Is it original?
Unfortunately not. Friend had it in his mail signature, he saw it (or something like it) somewhere on the net, couldn't remember where.
Being bitter is drinking poison and hoping someone else will die
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!
No, the OO has been there from day one; Python 0.9.0, the first public release, was an object-oriented language.
What you may be getting at is the fact that originally Python had two type hierarchies, similar to the way .NET and Java still distinguish between "primitive" types ("value types" on .NET IIRC), which include things like numbers, and everything else; hence on those platforms some types have to be explicitly or implicitly wrapped ("boxed") in objects for certain use cases. This doesn't change the OO tenor of the language, really (the biggest stumbling block was simply that the primitives couldn't be subclassed directly, so workarounds were provided to allow user-defined classes with the correct behavior), and the unification of those two hierarchies started a long time ago; everything you'll interact with in Python today is derived from the base object, which is one definition of OO (but, importantly, not the only such definition). A few years ago I heard Guido describe it by saying that in Python, everything is an object but not everything is necessarily an instance of a class (something that's actually been changed now, since everything derives from object these days), which is fine by me.
So maybe it comes down to someone's personal definition of "object oriented", which is of course possible given how many definitions of the term there are, but for general statements about types of languages I don't see any reason to say Python isn't or wasn't "object oriented" (unless your personal definition is one of the extreme ones which basically only admits Smalltalk, in which case that's your problem and not Python's).
Meanwhile I think I've shown pretty clearly that Python is thoroughly object-oriented and that the OO is so deeply embedded in the language that claims of being "bolted on" just don't hold up.
JRuby has an intrepreter, written in Java. It also has a Just In Time compiler to JVM bytecode. It also has a Ahead of Time compiler to JVM bytecode, just like Java.
Blessed are the pessimists, for they have made backups.
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.
That would explain the "cracks" I noticed. I haven't bothered to understand Python very deeply. (Well, to remember the pieces I didn't use.)
I sort of remember that I knew what you said when I was first learning Python, but that was a long time ago, and I haven't used it consistently enough to remember that kind of detail (i.e., the details that don't affect the code I was writing).
I think we've pushed this "anyone can grow up to be president" thing too far.
``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!
It's worth mentioning, that slideshow actually shows that Rails is much more efficient than CakePHP, but also that Merb is much more efficient than Rails.
That distinction is going away -- Merb is being merged into Rails (Merb 2 is Rails 3). I'm just pointing out -- you said Rails is an efficient framework, and it's about to become much more efficient, at the same time as Ruby just got twice as fast.
Don't thank God, thank a doctor!
JRuby has an intrepreter, written in Java. It also has a Just In Time compiler to JVM bytecode. It also has a Ahead of Time compiler to JVM bytecode, just like Java.
If it's compiled, does that mean that it would suddenly be appropriate to use generics? I suppose it's more complex than that?
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".
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.
Just wanted to see if I could jump onto a Joe The Plumber thread. I've never thought about Joe the Plumber and PHP at the same time but okay, yeah, that works.
quite right. Cool being a double edge sword. obscure means less readable here. It also doesn't help my programing that there are so many dam ways to do it.
It might be nice to have some simple examples and numbers to back that up -- besides just factorial.
I did... I'm not kidding when I say my parser is ten times slower.
If you're comparing a ten-line Ruby script with a hundred-line Perl script, and the Perl script is ten times faster, that would pretty clearly show the advantages of each language.
That'd be a 100x speedup, per line. :)
It's not that extreme. In my use, Ruby's only 1.5x as dense as good clean Perl (use strict; not using default variables; not hacking and overloading data; etc). My Perl is strictly procedural with lots of very tight, fast loops, and shallow, unabstracted data structures.
My Ruby is very OO with a great many very short methods (and resultant deep call stacks), rich objects, and highly abstracted data. The ease of maintenance - not the LOC count - is what makes it faster to code... And I'm clearly handing a lot of extra work to the interpreter.
Clearly I could transliterate the algorithms between the two languages, and the speed difference would narrow. You can write BASIC in any language... I've written Perl in Ruby. But that doesn't make the basis of a good benchmark. I think it's more meaningful to compare code written like the language was meant to be used. Both of the coding styles above are what I find comes naturally to me when writing in each language.