Slashdot Mirror
Can Ruby Survive Another 25 Years? (techradar.com)
TechRadar marked the 25th anniversary of the Ruby programming language by writing "there are still questions over whether it can survive another 25 years."
The popularity of the Ruby language has been bolstered for many years by the success of the Ruby on Rails (RoR) web application framework which dominated the web scene, particularly among startups who wanted something that deal with much of the heavy lifting... But RoR, although popular, isn't the superstar that it was and It has faced fierce competition as issues such as scaling have become a greater concern for web companies. The JavaScript framework Node.js, for instance, has become popular as it requires less memory to deal with numerous connections because of its callback functions...
To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. "We've created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released," Matz confirmed. You can try the initial implementation of the MJIT compiler in the 2.6 preview1... Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper: "With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0," and TechRadar reports that it's obvious that Matsumoto "will do anything he can to enable Ruby to survive and thrive..."
And in addition, "he's thoroughly enjoying himself doing what he does... and his outlook is quite simple: Programming is fun, he's had fun for the last 25 years making Ruby, and at the age of 52 now, he hopes that he'll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in -- a now lost -- notebook, at the age of 17."
"We want Ruby to be the language that is around for a long time and people still use," Matsumoto tells another interviewer, "not the one people used to use."
To improve performance further Ruby is introducing JIT (Just-In-Time) technology, which is already used by JVM and other languages. "We've created a prototype of this JIT compiler so that this year, probably on Christmas Day, Ruby 2.6 will be released," Matz confirmed. You can try the initial implementation of the MJIT compiler in the 2.6 preview1... Probably the clearest overview explanation of how MJIT works is supplied by Shannon Skipper: "With MJIT, certain Ruby YARV instructions are converted to C code and put into a .c file, which is compiled by GCC or Clang into a .so dynamic library file. The RubyVM can then use that cached, precompiled native code from the dynamic library the next time the RubyVM sees that same YARV instruction.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0," and TechRadar reports that it's obvious that Matsumoto "will do anything he can to enable Ruby to survive and thrive..."
And in addition, "he's thoroughly enjoying himself doing what he does... and his outlook is quite simple: Programming is fun, he's had fun for the last 25 years making Ruby, and at the age of 52 now, he hopes that he'll get to spend the next 25 years having as much fun working on the language he dreamt up and wrote down in -- a now lost -- notebook, at the age of 17."
"We want Ruby to be the language that is around for a long time and people still use," Matsumoto tells another interviewer, "not the one people used to use."
Event-driven I/O is a good idea. It happens that Node already has a good one because it's a web standard, and it inherits it from Chrome along with the rest of Javascript. However, event-driven I/O is easily done in C, Ruby, Python, Java, anything that supports coroutines. Many of these languages also support lambdas, anonymous blocks, and closures. Yes, even C++ has lambdas and will have futures (like closures) in the next standard. The syntax for them is sort of clunky next to Ruby.
C programmers haven't just learned about select() and poll(), they've had them for a long time. These allow them event semantics on the existing Unix I/O primitives and you can build an event I/O library on top of them.
Javascript doesn't really offer all of the desirable features of modern programming languages. After all, the goal was for it to look like C. We'll end up with a nicer language with a first-class event-driven I/O library and no native I/O.
Bruce Perens.
Code lasts a log time, so there will be users here and there. But, I highly doubt it will thrive. Python is gaining and has an advantage of very good interoperability with C libraries and improving overall performance thanks to projects like NumPy and the like. It's use in data science and other projects as well as in CS education will continue to help the overall implementations, Python competes in the language space that Ruby is in, and I think it does it very well, even with the issues around the 2/3 versioning. Honestly, Ruby is behind Python, and that gap is increasing.
The original advantages of Rails are disappearing. More and more of the MVC work is moving to the client side, and the server side is increasingly oriented towards just providing REST services. The amount of server generated HTML, a big part of Rails initially, is very rapidly decreasing. And while Rails is evolving, that legacy still exists. And other stacks have caught up. NoSQL make the ActiveRecord pattern much less needed for example. So, if you want raw speed in terms of time to implement, Node and the MEAN stack are really more competitive. Of course, that speed comes at a real cost and NodeJS has it own problems.
All in all, Buby faces enough challenges that will take too long to fix via language and runtime changes for its future to be vibrant. I expect it will fade in the face of Node, Python and even the resurgence of strongly typed frameworks (Java, C#, Scala) alongside newly revived languages like Erlang (and it's modern cousin Elixir) that embrace patterns for scaling that serve the whole modern web well.
I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL for his whole career and only wanted to program in JOVIAL for the rest of his career. I guess my business didn't matter much to that recruiter.
Most of the really good programmers can learn a new language on the plane to their new gig.
Bruce Perens.
They might learn the language on the plane, sort of, but ghe whole standard library of most modern languages? No way.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
People are looking at this from the wrong perspective. No offense meant, but I think that includes you too.
I rather suspect that you are a long-time Windows-based programmer.
Of course C is more performant. It's not a high-level language. It is intermediate-level at best. That's why C++, for one example, is higherl-level and therefore easier to use but slower. And interpreted languages will always be to some degree slower, because of their very nature. But they are also capable of doing more with less programming effort, and that is THEIR forte.
Further, there are fully-compilable versions of Ruby, such as MacRuby and jRuby. They don't give up very much to become compiled; only a few convenience features.
As for C libraries, that's partly what scripting languages are FOR: tying together low-level efficient libraries into higher-level finished products.
You say "for the real work, people will always turn to native code" but that's plain BS. People and companies do not have time or budget to low-level-code everything they do. A smart programmer will use the language appropriate to the task, and that often means tying that "native code" together using higher-level languages.
Your opinion of Python, for example, is just wrong. Python, despite its language inconsistencies and weird significant-white-space formatting, has been adopted by the scientific community as probably the go-to language of choice. It may not be used commercially as much as some others, but it is going to be around a long time.
The long and short of it is: each language has its particular strengths and weaknesses. Industry watchdogs predicted the imminent demise of Ruby over 10 years ago. That hasn't happened. In fact only 2 years ago, experienced Ruby programmers in the US commanded the highest salary of any language. I haven't checked more recently. But the market is a good place to look when one is making such "predictions".
While Ruby is 25 years old, it did not gain wide attention in the United States until nearly 10 years later. So as a practical matter, in the US, it is 15 years old.
It is approximately as performant as Python, and has a more consistent structure and syntax, so I suspect the scientific community will eventually shift over to Ruby over Python, unless it skips that step altogether and goes into functional programming.
As for Ruby "scalability issues", that is a myth that has weirdly persisted for at least a decade, in the face of abundant contrary evidence. Here are companies that have had no trouble at all scaling Ruby: AirBnB, Fiverr, Github, Goodreads, Groupon, Hulu, Indiegogo, Kickstarter, MyFitnessPal, Pixlr, Scribd, Shopify, Square, Strava, Twitch, UrbanDictionary, WhitePages, and ZenDesk.
There are many more, of course, but those are just some names that people might recognize.
I suspect the scientific community will eventually shift over to Ruby over Python
Unlikely. The reason the scientific community is using Python is that Python has SciPy, a rich and powerful collection of libraries. The heavy lifting in SciPy is done by compiled Fortran library code. Right now a Python program using SciPy is nearly as fast as the same program written in Fortran, and Python is dramatically easier to use. And it probably doesn't hurt that Python added a matrix multiply operator (infix @), just for the benefit of SciPy users.
In science and engineering, Python is now benefiting from network effect, where everyone uses Python because everyone else already uses Python. For Ruby to steal these users it would have to do something dramatically better and to date Ruby hasn't even matched Python. And if Ruby did get an edge on Python I predict that Python would implement something similar and keep its position as the language for science and engineering.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
You don't need to. Nobody knows the whole standard library of any language now.
I don't think he was implying you needed to memorize it all. But you need to be pretty familiar with large portions of it to be even reasonably productive, which can take weeks/months. Of course you won't know 100% of it and you'll learn more as you use it, but spending only a couple hours to learn the language you can't possibly know enough of the standard library to claim you "can program in X". That's more like "I'm still learning X".
I've used both Python and Ruby for years.
Personally I think Rails killed (or is still killing) Ruby. Largely because Rail apps scale poorly and beyond a very basic level become hopelessly unmaintainable.
I agree that Python is quickly becoming dominant in the scripting language space. Largely because of libraries like scikit. And bluntly, this isn't the 1980's anymore. Back in the day you coded in C except where you had to jump into assembly for a bit of speed. But these days I think the right design slice is to do the performance-critical parts in C (or maybe C++ or something similar) and use a scripting language as the glue code.
There are a lot of things about Ruby that I think are awesome and much better than comparable languages (my favorites is how the pattern-matching operator ties into switch/case statements and exception handling). But the world is moving on and sadly, Ruby is likely to be left behind.