Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Ruby Open Source Programming

Can Ruby Survive Another 25 Years? (techradar.com) 195

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."
This discussion has been archived. No new comments can be posted.

Can Ruby Survive Another 25 Years?

Comments Filter:
  • 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.

    • I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL [wikipedia.org] 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.

      • by tigersha ( 151319 ) on Sunday April 08, 2018 @02:01AM (#56400371) Homepage

        They might learn the language on the plane, sort of, but ghe whole standard library of most modern languages? No way.

        • by AuMatar ( 183847 )

          You don't need to. Nobody knows the whole standard library of any language now. Not even a simple one like C. You learn the parts you use, and google for more stuff as you need it. Occasionally it means you'll write an algorithm instead of using a built in, but the time lost is generally minimal. If it isn't, you'll probably think "I wonder if this already exists" before you finish.

          • by jon3k ( 691256 ) on Sunday April 08, 2018 @09:41AM (#56401281)

            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".

            • by Junta ( 36770 )

              I think the issue would be if you are very familiar with one particularly rich standard library (e.g. Java) you know there's something to look for in another language.

              The things that can be missed are obscure realities of a language that tend to also be missed by veterans. In my experience, for example, even long time python developers are frequently unaware of memory views, bytearrays, and such that can speed up a large class of functions dramatically or make things a lot easier in general (I too often se

            • by AuMatar ( 183847 )

              No, you don't. I've done it multiple times in my career- you learn the syntax and jump in, picking up the library as you go along. It just means you sometimes write a bit of extra code. I wouldn't put it at expert level on my resume, but you can be reasonably efficient and get tasks done. Remember we used to program with minimal libraries and still make progress in new languages. You just might write a bit of redundant code that gets cleaned up (or not) later.

              • by jon3k ( 691256 )
                So you're claim is you can be "reasonably efficient" in a language after spending a couple hours with it? Maybe we just have very different ideas of what "reasonably efficient" means.
                • I think he is describing an "80-20" rule or some-such: that coding common tasks using standard libraries can be accomplished in a few hours, especially drawing on decent example code. Yes, you can get stuff done that way in a reasonably productive way, especially if you have experience in similar languages (all languages draw on previously used syntaxes and paradigms).

                  But yes, you are only just learning the language.

                • by AuMatar ( 183847 )

                  Or maybe my definition has less to do with knowing every trick of the language, and more with getting tasks done. There's two major things here:

                  1)Actual coding is only 10-20% of programming. Architecture, debugging, organizational skills, etc are far more important, and are almost completely language agnostic. There were definitely subtle you would have trouble finding because they had to do with language tricks/oddities, but most bugs are logical bugs.

                  2) You can be reasonably efficient and not do everyt

                  • I don't really even want to know what the tricks are, even using my main language!

                    If I was using Ruby and something was hard, I'd use C. If I was using C and something was too hard, I'd use ASM. If it requires a trick in ASM, it wasn't even a trick it was a processor feature.

                    My advice in Ruby is, use baby-Ruby. My advice in C is, use baby-C. My advice in ASM is, don't complain, upgrade until you can do it in C.

                    In Perl they have ideology that prevents that from being good advice. The good news, they have eno

        • That is why modern languages have strong IDE support.
          That mostly eliminates the need to learn 'standard libraries' completely.

          • by Junta ( 36770 )

            Of course, only if you know where to look. If you don't know a standard library function exists, you may waste time rolling your own, and probably not as good as the language runtime provides. No IDE is going to look at your function and recognize there's a standard library equivalent.

            • No IDE is going to look at your function and recognize there's a standard library equivalent.
              Every IDE does that. Did you ever use one?

              • by Junta ( 36770 )

                I have used several. If I write a function called copydata that takes two filenames and then does an open on both of them and manually reads from one and writes to another, I have not met an IDE that will say "hmm, the way that function works, you *sure* you shouldn't be using this standard library function?

                Sure when you try to make one and shadow another, it will point this out. Completion may complete a function name that you were about to do and give insight. If you however do not get caught by one of

        • by Junta ( 36770 )

          I will say I'd rather deal with the ramp up of a programmer as they fail to be aware of a standard library feature than someone who has more time in with the language I want but seems to lack good problem solving skills. Particularly with code reviews, you can recognize patterns that are bad.

          Of course, if you have a blind leading the blind scenario, that can't be good. I once sat in with a java team and a developer with over a decade of java experience was asking me if I had any thoughts on why file copie

        • I personally keep the API documentation open while I'm coding anything serious, even if it is stuff I use frequently. It only takes a couple seconds to glance at a function signature, and surely I'll read more if I have doubts instead of just forging ahead and waiting for failed tests to save me.

          I'm not going to learn a whole API on the plane, but why would ever need to know a whole API? I'll need to know a few functions at a time, and they'll change depending on what part of the code I'm in. The real probl

      • by q_e_t ( 5104099 ) on Sunday April 08, 2018 @02:11AM (#56400387)
        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.
        • I'm fairly certain that's less of a problem and more an useful indicator of the kind of people you don't want to work with.
      • 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.

      • Most of the really good programmers can learn a new language on the plane to their new gig.

        Not that extreme, but my assumptions are the same. I assume that a good programmer can pick up a language over the weekend and after two months of daily use, can become an expert at it.

        But I find many candidates in the very old & very young buckets that appear to want to remain experts in their language of choice. The older group, I understand, they are basically retiring in 5+ years and just want the easy slide into it. Money isn't that important anymore and, with that out, there is plenty of opportu

      • by HiThere ( 15173 )

        Learning a new language is easy. Learning how to use it is difficult. Learning the system specific libraries can be a real pain. Even in the languages I'm most comfortable in, I still need to drop into looking up references whenever I want to use a library I haven't used frequently.

      • by haruchai ( 17472 )

        I once interviewed a programming candidate, sent to me by a recruiter, who had only programmed in JOVIAL [wikipedia.org] 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.

        In the case of that candidate, it's probably not a good idea for him to try switching languages; he'd end up writing JOVIAL code in Java or Python, would look like a literal translation of German into English, or worse.

    • by e70838 ( 976799 )
      Java is declining because of Oracle. If Oracle made Java opensource with no strings, there would be a huge regain in popularity. IMHO the trial against Google has hurt a lot the reputation of Java.
    • by DrXym ( 126579 )
      This is an odd statement because very few programmers are so stuck in a rut that they only ever program one language or technology their entire careers. I've programmed Modula 2, Pascal, C, C++, C#, Java, Javascript, JavaFX, Rexx, Groovy, Typescript, Ruby, Perl, Obj C, Visual Basic, TCL, LUA, Rust and more besides. Using stacks, APIs and protocols too numerous to count, many of which are defunct. On numerous operating systems, some defunct.

      It doesn't bother me if a language or tech dies because my skills

  • by Bruce Perens ( 3872 ) <bruce@perens.com> on Saturday April 07, 2018 @11:47PM (#56400075) Homepage Journal

    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.

  • There is even an object-oriented version these days.

    https://supportline.microfocus... [microfocus.com]

  • by ndykman ( 659315 ) on Sunday April 08, 2018 @12:19AM (#56400159)

    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.

    • by Tablizer ( 95088 )

      It's a security risk put too much of the app logic on the client side, let alone being tripped up on client-specific bugs. Then again, risk hasn't stopped a lot of questionable trends/fads.

    • Honestly, it feels like Python is behind both Node and Ruby in terms of development (though not popularity). Where are new Python features? Why do current Linux distros still ship with Python 2.7? And why can I still in 2018 not shift() a goddamn array?
    • 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.

      • by ndykman ( 659315 )

        There's some good points here, but i would note that Python as a language has its fans as well and some would argue it is quite well designed overall. Personally, I find Ruby can be a bit too clever in places, but such things are a matter a taste.

        I don't disagree that the adoption of NoSQL could be problematic, merely that those looking for speed of implementation are increasingly adopting it and it is displacing Rails. Fairly or unfairly, Ruby is often tied to Rails, and as interest in Rails subsides, it i

  • by K. S. Kyosuke ( 729550 ) on Sunday April 08, 2018 @04:38AM (#56400611)

    "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.

  • Every once in a while Ruby crashes and burns when installing gems...on a system seemingly identical to another one that works fine.

    Once the Ruby guys can fix that I'm sure Ruby will do fine.

    • by Mandrel ( 765308 )
      Compilation of Gem native extensions can fail on systems with restricted memory, such as VPSs for which swap space hasn't been configured.
  • Ctrl-f "RPG"

    It's still doing a lot of commerce, so why shouldn't any other useful language?

  • by Zobeid ( 314469 ) on Sunday April 08, 2018 @08:41AM (#56401053)

    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.

    • by david_bonn ( 259998 ) <davidbonn AT mac DOT com> on Sunday April 08, 2018 @10:26AM (#56401441) Homepage Journal

      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.

    • You are wildly off-base with respect to Ruby, and in respect to OOP, "crazy geezer" is the kindest characterization. Ruby and Python are extremely similar as scripting languages. I don't know what you read about either language, but this is an offensively stupid post.

      • by Zobeid ( 314469 )

        It's "offensively stupid" to simply relate what I have observed? I didn't make any of this stuff up.

        • You did not invent any experiences. You're were sufficiently outraged by the idea of object orientation, because of your own inadequacies, that you stopped reading something that mentioned the subject. In doing so, you somehow missed that Ruby's "hello world" is shorter than Python's, and that in general the only difference in scripting is that Ruby has less required syntax. Not understanding such basic logical abstractions as classes is also completely absurd, but if you can say such things and remain empl

  • I'm curious, never used the Ruby ecosystem, what does it offer that others don't? If nothing, isn't it normal to go the way of the Dodo?
  • by lasermike026 ( 528051 ) on Sunday April 08, 2018 @01:59PM (#56402437)

    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.

  • I'm given to understand that Ruby is slow in part because all objects can be "monkey patched" at run time. I've always taken it as the language where you can serve web pages from an integer if you like. 3X faster than old Ruby is still not fast, right? All the JIT in the world can't help you if there's no clean mapping from the language's objects to the machine's objects. You'd need some kind of "lock" optimization keyword in the language, and perhaps other fundamental changes.

    Other posters have mention

  • by fahrbot-bot ( 874524 ) on Sunday April 08, 2018 @03:20PM (#56402733)

    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?

"Nuclear war can ruin your whole compile." -- Karl Lehenbauer