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."
Why are you talking so much about JavaScript when the story is about ruby? I love Perl and believe perl will always be the best so now Iâ(TM)ve posted the same as you.
Because the point of the video was about the cool kids who discovered non blocking I/O async event driven do not understand threading or code quality. Yes you can do something simple VERY fast ... but in actually node.js developers develop their own OS with threading and end up with call back after call back loop spaghetti.
What Ruby 3.0 is attempting to do is just this. It makes more sense to use threads and let the OS deal with assigning them to CPU's and ultilizing which set of code to execute next.
http://saveie6.com/
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.
We should start with the point that not everything that should have promises does, and it will take another couple iterations of the Javascript standard to get there.
Javascript I/O programming creates a hidden state machine. Threading makes it obvious what the states are and what their order is. Implementing a state machine in a switch statement generally does this too, although it's not enforced. Implementing them in promises gives you a state machine where the last state is the innermost block, or you refer to them by name instead of using immediate blocks and then it's a directed graph with no obvious or enforced order.
I don't really have a problem with promises as an I/O paradigm, it's the fact that it's harder to understand the code by reading it from the first line to the last than it would be with threading or even with most well-written state machines in switch statements.
I am sure we can solve this all with syntax.
Bruce Perens.
I'd agree with the siblings that recruiters tend to require significant AND recent experience in the particular programming language asked for. For example, I was once told that because I hadn't used a particular language professionally for two years, then they considered me to not be appointable, despite 15 years of previous experience with it. Adaptability doesn't seem to be valued. Mind you, they also wanted to give them a timescale for a project despite me indicating that a short feasibility study would be required, and that to ask for a breakdown with insufficient information was unreasonable.
Ruby has a better syntax and probably a better object model. I'm sure there are all sorts of good things about Python's current popularity. Tell me though, can we even call this "2/3" morass a transition at this point, or are we just going to deal with these two separate-but-equal codebases forever? Popularity is not meaningless, but language fundamentals matter too.
Rails is certainly past its peak, but it actually works just fine as a set of REST endpoints. I don't know why you think that the framework is mostly about HTML generation. I'm also fairly concerned if you think that NoSQL is ascendant, dominant, or entirely a good idea. SQL as a query language is likely to be more enduringly popular than the relational datastore per se, but neither are exactly dying out. If as you seem to be suggesting, Node development offers a rapid path to buggy code, I am probably going to steer clear of that one, too.
Ruby is a pleasant and concise language. From my experiences in coding golf competitions, it's usually 30-50% shorter for the equivalent line of Python code. If it had a speed advantage, or seemed likely to obtain one, I would expect it to win out over Python in the long run. As things stand, I would expect that Ruby will continue to exist as a glue language, and as a common point between things like Crystal and Elixir. The syntax ideas and standard library functions of Ruby may end up being more durable than the language itself; Python on the other hand has had far less influence on the design of subsequent languages.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
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.
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.