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'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.
sdk's come and go..
look, nobody cares nowadays if I know symbian c++. they do care that I've been working for 15 years making apps for handsets.
people care even less that I could do vesa 2.0 programming for dos. they might care that I knew enough to download the few docs needed for accomplishing that back in the day.
and back in the day.. people would get jobs for symbian programming purely because they knew enough to compile something. now there is a market surely for jovial only programmers, but hey come on if you think about that, they never went an extra mile.
real reason for why someone would stay on that would probably be that nobody expects you to churn out code quickly in the usual gigs for that sort of a language.
there's plenty of older guys who have had the luxury of churning out just few hundred lines of code per year - or even less, being a resident programmer at whatever bigger company doing just one specific part of some huge budget thing. very few people from my generation ever had that sort of luxury. sure it would be nice. I would probably still enjoy trying to crunch down some mobile java to smaller kb size. nobody is going to pay for that though, not even those who should.
sometimes you know a sdk is going to be goneski in a year and the app you're making will never make it's money back on that platform.. but even then plenty of companies wanted to make windows phone apps.
world was created 5 seconds before this post as it is.
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
I came in to cleanup a project built by one of those guys. 2+ decades of experience and a Java architect. It was a PHP sure where he used factory factory factories to initialize the entire codebase.... completely ignoring that in PHP you get a new thread for every request. He left when he couldnâ(TM)t figure out why the web server had to be forcibly rebooted on a 45m cronjob.
The same site also used inline static JS to set the destination of top menu items:
Itâ(TM)s important to understand how a language behaves in context, not just be able to pick up languages fast.
I'm out of my mind right now, but feel free to leave a message.....
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.
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.