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."
But fads go in and out. Meanwhile COBOL I heard is still popular in older enterprises. Will node.js and Rust have the same fate 10 years from now? Java seems to be declining but still is active on older software projects.
http://saveie6.com/
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.
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.
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.
I still have more fans than freaks. WTF is wrong with you people?
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
"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."
That sounds very much like Smalltalk/X to me. Will be interesting to see how well this works for Ruby. In Smalltalk/X, however, larger pieces of code were compiled ahead of time this way; the JIT compiler in Smalltalk/X to my understanding doesn't use the intermediate C route or generate .so files.
Ezekiel 23:20
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
As for python being the scientific language of choice- that's just wrong. Its still C and Fortran. Serious scientific computing requires performance, nobody would dream of doing that shit in python.
Not anymore. These days a high level language is one that doesn't have a preditable mapping to instructions and memory access, C still has that, and C++ can have that if you use it right.
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.
That's flat out not true. Bad C++ is slower than good C and bad C is slower than good C++. The only thing that makes C faster than C++ is the restrict keyword, which all major compilers support for C++ as an extension.
Idiomatic C++ is often faster than idiomatic C, compare for exampe std::sort to qsort.
SJW n. One who posts facts.
I think Ruby has been overshadowed by the huge success of Python. Recently I set out to learn a new high-level interpreted language, something for easy scripting and prototyping, somewhat like the role BASIC (at least in its more advanced variants) used to fill. I was drawn to Python and Ruby. They both made a similar sales pitch, they sounded good. But which would it be?
Well, I have a friend who is already a Pythonista, and it appears to have more mindshare all around.
In all my web searches about Ruby, I kept coming up with Rails, Rails, Rails. Ruby on Rails is great for web development! Ruby is a great language for web development! (In case you all haven't guessed, web development is something I have no interest in.) And, oh yeah, Ruby can supposedly, theoretically, be used to create stand-alone applications, though we don't really talk much about that.
The other thing that irked me was Ruby pushing OOP in my face, hard. In Ruby everything is an object! EVERYTHING!! (This seems to be true in Python as well, but they don't harp on it like this.) Then I look at the Ruby tutorials, and they immediately launch into discussion of classes and objects, before even basic stuff like flow control. Well, I'm one of those crazy geezers who thinks that OOP is oversold. Sometimes useful, yes, nice to have built into a language, sure, but there's no point in messing with it just to dash off a quick script or simple little application. If I just want to say Hello World, I shouldn't have to begin by defining classes. Didn't we go through that madness already with Java? Was no lesson learned? So, I got a tutorial book on Python. Classes are covered in chapter 22, not in chapter 1. To me, that's a lot more sensible. And if I merely want to use my classes as a slightly fancier counterpart of C structs, Python doesn't judge me.
By comparison, the only really dumb thing I've encountered with Python is its ridiculous use of white space. I guess I can learn to live with that.
C is abstracting away only two things: the names and amount of registers, and the way how you call functions/use the stack. ... that is up to you. But might lead to strange eyes when you get a bad grade in a test ..
It is considered by academics not to be a high level language
Of course you could disagree
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
C is a high level language. A high level language is anything that's not a 1:1 mapping of instructions. Stop trying to redefine terms.
Who's definition are you using? I consider C to be a high level language (albeit at the very bottom of them) because it's machine independent, so it allows abstraction of the underlying system implementation. I'm just curious how we define these things because I can't find a clear definition from anyone I trust.
In sceinftific computing, your developers are largely not programmers, but scientists. This is why Fortran has enjoyed more relevance in that field than everywhere else, it maps more closely to how they express and learn math.
It is also the case that when it comes to intensive operations, they are generally merely supervising standard modules. specifically, python scripts can supervise numpy code, and that implementation is what matters not the text the scientist is typing.
Essentially, they need a "glue" lanuage, they don't need the glue to be fast, they just need the pieces to be fast. They need languages that relate to their professional experience and/or a language that won't intimidate them. IPython and numpy are very prominent reasons why python has been relatively popular in scientific computing.
Certainly, scientific computing cares a lot about c and python, but they care too about python.
XML is like violence. If it doesn't solve the problem, use more.
On Friday a fellow engineer asked me what I thought about Crystal lang. Crystal lang is a Ruby like language that compiles down to machine code. Intrigued I took a look. That language is similar to Ruby but it has static typing which has a performance advantage. I wrote some test code. It was fast. The language itself is a little different from Ruby. What makes Ruby, in addition to syntactic sugar, are gems. Crystal's analogue are Shards. I noticed that the style of Shards is more procedural and less object oriented. This is my first impression of the language. It left me wondering what I would lose if I migrated from Ruby to Crystal lang.
I love Ruby. I love the syntax. The performance can be an issue sometimes but there are workarounds. Let's be honest, Python won the war. Python solved many problems with it's built-in types, language simplicity, and good performance. For all Ruby's syntactic sugar Python grew and dominated. There are extremely helpful Python modules that have made entire industries. Performance matters.
When I tested Crystal lang I asked myself if there was an analogue in Python. Quickly I thought of Cython. I never had a reason to use it but I was looking for compiled self contained binaries that I could use on some of my weirder systems where installing dependences is difficult. I work in the docker space so Go seemed like a good choice. With in less that an hour I was producing statically linked binaries. My code was simple so I did not have to tackled the more complicated bits but it was a good first go.
Python in Cython is still Python. Crystal lang is like Ruby with completely different modules. What Cython is doing is different from what Crystal is doing. Cython is taking Python code converting it to C which and running it in an embedded Python interpreter. Crystal is producing machine code without an interpreter which theoretically has performance advantage. The advantages of Crystal may not out weigh the advantages of Python and Cython.
I applaud what the folks at Crystal lang are doing. I may not use Crystal because it doesn't fit what I'm doing but I would love to see them grow and develop. If I need something compiled from a scripting language I would use Cython over Crystal. Win 1 for Python.
This is pretty much the blessing and the curse of Ruby - its philosophy works excellently for the best programmers (who are able to write clean and DRY code etc.), but is not really a good fit for mediocre ones, unlike Python or JS. And since there are always only so many best programmers, and majority is always average or worse, Ruby is sort of destined to be niche'y, which may ultimately spell its failure, or it may not. Personally I am enjoying coding in it, even though I am far from the "best programmers", but whether the language is going to last, I cannot be so sure.
Ruby creator Yukihiro Matsumoto says Ruby 3.0 "has a goal of being three times faster than Ruby 2.0,"
Yukihiro. You know that's not really how version number work - riight?
It must have been something you assimilated. . . .
Great post generally, and I agree that Ruby is unlikely to 'get an edge' in scientific computing. That said, the difference in the languages tickles just beyond the reach of that last phrase -- I'm pretty sure the aspects of Ruby that resemble Lisp can't be bolted onto Python. Especially the blurring of code and data (a la Lisp) -- a 'bolt a feature on' response is nigh-on-impossible expressly because that vast range of python libraries won't work lisp-like code/data ambiguity.
Python's great, and as a scientist/data geek, I love working with SciPy. As a hacker, I love working with Ruby. The synapses they tickle are so far apart, they're not even orthogonal.
I've also noted a steady growth in Lisp-mindedness. Over Lisp's 60ish years, cLisp, Clojure, Ruby etc seem to be growing mindshare. Slowly, and in fits and starts, but growing. Lisp's ability to craft parsers and DSLs have gotten us to where DSLs like like LUA are mainstream. There are skunkwork Lisp-like languages in some top tech firms. Fun stuff, fun times.