Is Ruby Dying? 400
New submitter John Moses writes "I have been working with node.js a lot lately, and have been discussing with co-workers if node.js is taking steam away from Ruby at all. I think the popularity of the language is an important talking point when selecting a language and framework for a new project. A graph on the release date of gems over time could help determine an answer. The front page of RubyGems only shows data on the most popular, but I am really interested in seeing recent activity. My theory is that if developers' contributions to different gems is slowing down, then so is the popularity of the language."
Re:Short answer: no (Score:5, Informative)
Nice try (intentionally spelling "java script" is not cute, dude!).
Here, I fixed it to you [google.com].
Not a surprise, anyway.
Re:Nope (title capitalization sucks, btw) (Score:4, Informative)
No. Next question, is Slashdot dying?
Slashdot will be dead as soon as the new "design" comes out.
Re:ruby is obnoxious (Score:3, Informative)
For quick and dirty scripts, you can just define your methods and variables and not deal with classes. They're added to the main object, much like javascript globals and functions are added to the window object.
Re:Node.js (Score:4, Informative)
No, more like: http://pastie.org/private/ij3rdcgtkgteefgwj57mfg [pastie.org]
I realize that's just an example of simple inheritance, but not bad for using nothing more than functions and prototypes. Yes, it's a little verbose. You can also do prototypal inheritance, etc. The point is that with just a couple of constructs, JavaScript can do things that most languages must separate into many more statements, expressions, etc. But to clarify, I am *not* saying JavaScript is awesome; it clearly has limitations. But it is pretty amazing what all can be done with such a simple language. It is misunderstood.
Re:Short answer: no (Score:5, Informative)
the compiler is free to rearrange the order of the fields as it sees fit.
No, it is not. ISO/IEC 9899:1999, 6.7.2.1 "Structure and union specifiers", paragraph 13:
"Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning."
The C++ standard has a similar provision. What's unspecified is whether there is any padding between the fields.
Re:Node.js (Score:2, Informative)
Long polling for 2,000 concurrent users? Trying streaming real-time multimedia to 5,000 concurrent users using a single process, no threads, and with each stream customized for each user on-the-fly by splicing in announcements and advertisements. And I wasn't even aiming for performance. I stopped at 5,000 because it was about as high as I could go without the network being saturated. My user CPU time was less than 40%, with the majority of the time spent in the kernel dealing with TCP. After looking at my numbers I figure I could saturate a 10Gb link with a week's worth of effort--run a couple more event loops in separate threads and tweak the network stack with IRQ pinning or some other hack. And that's before I bother looking for bottlenecks and optimizing my code. I know I do way too many needless memory copies.
Although, I should say I use straight-up C with a smattering of Lua for, e.g., handling the logic of advertisement selection, which is ugly and has lots of code churn.
I've been doing asynchronous programming in C and other languages for well over 10 years, before libevent event existed. Today's processors are so ridiculously fast that a Perl script would easily handle long polling for 2,000 concurrent users without breaking a sweat. Do long polling for 20,000 connections on Node, with a significant fraction of those active at any one time, and then you'll have something to be mildly proud of.
If you need to do any amount of heavy lifting, you have to use C. For everything else, almost any scripting language will do. I don't like C++ because people tend to go nuts with Boost and other bloatware and end up with performance not much better than something like Node or Lua. Same thing for Java.
At the end of the day, CPU performance allows scripting languages to look like highly optimized C applications 10 year prior. Frequency isn't getting faster, but caches are growing, which is often more important, anyhow. But if you want to maximize performance today for today's hardware, you still have to go back to the old tools.