Hacker News new | past | comments | ask | show | jobs | submit login
Ruby 2.1.1 is released and Ruby turns 21 (ruby-lang.org)
217 points by petercooper on Feb 24, 2014 | hide | past | favorite | 85 comments



I was a bit surprised about the age, and wondering where it fits into the timeline, so I put together the following list (years corresponding to the "appeared" indication taken from Wikipedia). (There will likely be nicer lists elsewhere..)

  1957 (57) Fortran
  1958 (56) Lisp
  1958 (56) ALGOL
  1959 (55) COBOL
  1964 (50) APL
  1970 (44) Pascal
  1970s     Forth
  1972 (42) C
  1972 (42) Prolog
  1972 (42) Smalltalk
  1973 (41) ML
  1975 (39) Scheme
  1978 (36) TeX
  1982 (32) PostScript
  1983 (31) C++
  1983 (31) Objective-C
  1984 (30) Common Lisp
  1986 (28) Erlang
  1987 (27) Perl
  1990 (24) Haskell
  1991 (23) Python
  1993 (21) Ruby (according to article)
  1994 (20) ANSI Common Lisp
  Mid 1990s Dylan
  1995 (19) Java
  1995 (19) Ruby (according to Wikipedia)
  1995 (19) JavaScript
  1996 (18) Ocaml
  2000 (14) C#
  2003 (11) Scala
  2003 (11) Factor
  2005  (9) F#
  2007  (7) Clojure
  2008  (6) Nimrod (according to speedydeletion.wikia.com)
  2009  (5) CoffeeScript
  2009  (5) Go
  2012  (2) Rust
  2012  (2) Julia
(edit: added Clojure, of course) (edit 2: added ObjC, Dylan, Nimrod, Go, Rust, Julia)


Ruby was first released in 1995, development started in 1993. So, both numbers are right. "Ruby's birthday" is traditionally the start of development. The most interesting info is: Ruby and Python are both not influenced by Java.

An easy answer to the question: "Why didn't they just steal that from Java?"


I'm curious what features of Java would be worth stealing for Python or Ruby?


* Threads without GIL (which also requires an explicit memory model) * concurrency libraries * Garbage collectors that scale to hundreds of gigabytes worth heap, are parallel and concurrent * JIT that performs within a small factor of C code * Tooling support, especially profilers and debuggers are lousy and frequently break in my experience * bytecode weaving/AST transforms at runtime. The whole refinements thing could have been done more cleanly with callsite and method entry/exit hooking

Talking about MRI here. I know rubinius and JRuby exist and offer some of those features


The creation/creators of Java are not responsible for most of the things you listed. They are attributable to HotSpot, built by the fine folks that brought you the best-of-breed Smalltalk implementation half a decade after Java's release.

HotSpot wasn't released until 1999. Prior to that Java did not have a JIT. Java used to be very slow compared to compiled code and HotSpot was a BIG DEAL when it was released in '99.

GC that scales to hundreds of gb? Do you mean Azul, the proprietary and expensive JVM implementation?


G1GC for dozens of GB, Azul (for now) for hundreds and in the future there'll be Shenandoah.

You're right that those features provided by hotspot. But it is the reference implementation for the JVM after all.

The point remains that the java ecosystem - which includes tooling like eclipse/netbeans/yourkit and JVM implementations - provides the things I've listed that I find lacking in ruby.


But by the same measure, JRuby is part of the Ruby ecosystem.


Don't know, but it is a question I get from people coming from Java from time to time.


Real threads ... and ... that's probably it.


Real (presumably, that means native) threads are an implementation detail and not a language feature, and both Ruby and Python use native threads in the current main implementation (and Ruby, and I believe Python, also have implementations that use native threads without a GIL/GVL.)


In both languages threads are an added after-thought and no, I disagree with you - multithreading is not an implementation detail. For example, why do you think classes in Java are immutable?

Also, I consider the standard library to be a part of the core language, because it is. Python doesn't have many concurrency primitives that are commonly used in Java, even really common ones, like AtomicReference or CountDownLatch. Heck, it doesn't even have volatile variables, let alone ForkJoinPool or other niceties. What's actually in the standard library? Well, the multiprocessing library is now baked in for doing "process-based threading", which really means stuff based on fork() that is unportable, because the language implementors gave up on threads a long time ago.

It doesn't stop at concurrency primitives though. For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.

Add to that libraries like NumPy/Scipy that are basically unportable, or Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version, or the myriad other libraries in the ecosystem all written for CPython and expecting a GIL. Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.


> In both languages threads are an added after-thought

So?

> no, I disagree with you - multithreading is not an implementation detail.

Threading is a language feature, not an implementation detail. Whether threads are implemented by way of native threads on the underlying platform (as in JRuby, current CPython or MRI), or green threads in the runtime (as in old MRI, etc.), and, in the latter case, whether the green threads are mapped to native threads on an N:1 (as in old MRI) or M:N (as in the main Erlang implementation) model are implementation details.

> For example Python has the notion of destructors in the language, the reference implementation having a GC based on reference counting, so when implementing it on top of the JVM/CLR or whatever platform that doesn't do reference counting, that's at least one feature that can't work.

Sure, it could, since you could obviously (at the cost of making interop harder) write a Python implementation with its own garbage collector that ran on the JVM or CLR. You might choose to sacrifice portability for better interop with the languages the platform was designed for, but that's a choice.

> Django that says it runs on Jython but nobody mentions that Django needs the MySQL client written in C and won't work with the pure version

Seems to me that's a problem either with Django or the pure python MySQL driver, but not with the Python language.

> Anybody that is fantasizing about Python having a usable implementation other than CPython is delusional.

Perhaps; I'm less familiar with Python's other implementations than with Ruby's (particular JRuby) which is definitely usable, and definitely uses native threads without a GIL.


Thats the case for python. Ruby actually shows that designing a language that runs both on and off the JVM is indeed possible.


I'd rather steal from Tcl/Lua/Go: coroutines+channels


Coroutines => Fiber[0] (since 1.9.stg)

[0]: http://www.ruby-doc.org/core-2.1.0/Fiber.html


Ruby has real threads now.

Java had green threads back then.


By "real", I mean native and multi-core. Does that exist now? I think it exists in JRuby, but in MRI?


MRI has native threads a GIL, but you can already release the GIL and run freely in native extensions.

And this is _not_ a property of native vs. green threading. (And shows how shallow the comparison is, given the number of languages that implement green threads mapped to native threads nowadays.)


All major Ruby implementations use OS threads, but the GIL still limits parallelism in MRI.


according to the wiki

> Python's standard library additions and syntactical choices were strongly influenced by Java in some cases: the logging package,[27] introduced in version 2.3,[28] the threading package for multithreaded applications,[29] the SAX parser, introduced in 2.0, and the decorator syntax that uses @,[30] added in version 2.4[31]


I think the new enums in python 3.4 are based on java enums(module for dynamic typing, for example I beleive comparing them to ints or adding them if they have int values will fail at run time as opposed to compile time) as opposed to enum as an alias for integers.


the creation of both happened without java, but both have been heavily influenced by java today.


Of course Ruby and Python are influenced by Java (there is hardly a maintained language that has not been). Not the initial release perhaps, but don't you think that Ruby has evolved over the 19 years since Java was released? This release alone has been influenced by Java (Generational garbage collection enhancing performance by as much as 100% in some cases)

A question for you is why do you care? If a Java programmer tries to rib you saying that Java is better because x feature was influenced or 'stolen' from Java, just laugh at them and tell them then C++ must be 'better' than Java huh?


how is generational GC a java thing? It's been around since the '80s [0]

[0] 1983 "A real-time garbage collector based on the lifetimes of objects"


Generational GC itself is not specific to java. But if you want to look at state-of-the-art collectors then you'll generally find them in JVMs.


I am speaking language design here. Ruby is a surprisingly conservative language when it comes to changing syntax and semantics.

Sure, runtimes always evolve and cross-pollinate.

I don't care, but as stated in another comment, you often get that question from people joining over from the Java camp.


I forgot Lua and PHP; I also didn't think of Ada. So, for whatever kind of completeness, here are some more:

  1975 (39) Modula      1988 (26) TCL
  1977 (37) Ada [1]     1990 (24) J
  1977 (37) Icon        1993 (21) Lua
  1985 (29) Miranda     1994 (20) Pike
  1986 (28) Oberon      1995 (19) PHP
  1987 (27) Clean       2002 (12) Io
  1987 (27) Self
[1] according to crag

I don't know birth dates for these:

  Agda, ATS, Felix, Idris 
(I'm ignoring languages that are used only in a particular context, like R, shells, proof assistants; I made an exception for TeX and PostScript as these seemed particularly important.)


In this day of software developers seemingly needing to keep up with the latest technologies, it is interesting to realize that the languages I use most often are decades old.


You forgot Ada, 1975. Mainly used by the military and contractors. Still in use today, by the way.


also still updated, there is at least an Ada 2012.


Don't forget Clojure, birthyear 2007.


Lua 1994 Icon 1977


no, Lua is 1993...


Ada, 1980.


1975 (ok, release was 1977). Was in active development/production work in 1977. The DOD standardized on Ada in 1986 (I think). I was in the Army then writing Ada (and using Wang - remember Wang?).

Ada is still in use today. Besides the military, there are a lot of "mission critical" systems written in Ada.


A quote from Ruby's author, Matz:

> For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy.

Happy hacking!


In computer science classes, the best professors do inspire you to see the joy of an elegant algorithm. But I can't remember any class in which the joy of language was ever espoused (when I was a student, we learned C, then C++, then Java). It wasn't until I learned Ruby did I grok that writing and reading code could be something of a joy.


I had a great programming languages prof who managed to instill a love of languages themselves in me. He gave a lecture entitled "Scheme as the Ultimate Programming Language", and his love for Scheme was pretty clear throughout multiple classes I had with him. I didn't ever find a practical use for Scheme per se, but his passion stuck with me, and when I discovered Ruby and how it took some of the more clever naming conventions from Scheme, that gave me the push I needed to really dig in and learn Ruby, which is now my favorite language to code in. Matz has definitely managed to fulfill his goal and make programming using Ruby a joy for thousands of programmers. Thanks Matz, and congrats to the entire Ruby community!


Ruby code always makes us sad, as we have to spend all day deciphering the abusive metamagic DSLs that some devs think are cool to use and abuse. Creative is fine on a canvas, less so when you are having to debug some special turd of an app from a Ruby only developer.


DSLs, APIs, design patterns... there are endless metalanguages to learn on top of the programming languages we already know. Just because you can't wrap your head around DSLs as a different kind of API doesn't mean there's "abuse" going on. Ruby is pretty clearly designed to support DSLs, and being able to use a full-fledged programming language within your DSL-based config files is an incredibly powerful tool.


Who's your 'us'?

I'm coding in Ruby full-time for some months now and it's the most friendly language I've encountered, everything feels natural.


Programming jobs are designed to make programmers miserable.


Ruby 1.9.3-p545 was also released today with the following:

"This release is dedicated to the memory of our best comrade, Jim Weirich. Thank you, Jim. Rest in peace."


Speaking from my experience, learning Ruby made programming more fun, elegant, and productive. Thanks Matz! Though sometimes overblown and even cultish at times, the Ruby community transformed expectations about what a language can be. The spill-over benefits have been tremendous to almost everyone. UPDATE: I wanted to thank not just Matz but everyone who made the language easy to learn and the community welcoming.


The article mentions:

> Ruby 2.1 has many improvements including speedup without severe incompatibilities. You can use this on Rails and some applications, and get more comfortable experience.

Since the changelog is very large I'm still interested in what speedups are part of this release. Anyone?


There are huge performance improvements in Ruby 2.1.0 as compared to Ruby 2.0.0, I have seen as much as a 2x improvement in real world settings, and they have to with Ruby now having a generational garbage collector:

http://www.infoq.com/news/2013/12/ruby21

I don't think this current patch release itself contains much performance fixes.


Ok.. I misread that, and assumed the 2.1.1 came with further perf improvements.


Ruby v2.1 have a improved GC which helps a LOT with performace. You can know about Performance changes in these posts:

    http://tmm1.net/ruby21-rgengc/
    http://tmm1.net/ruby21-oobgc/
And 2.1.1 is point release, so only contains bug fixes. It doesn't contain new features.


see my slides: https://speakerdeck.com/samsaffron/why-ruby-2-dot-1-excites-...

only perf related feature is: RUBY_GC_OLDOBJECT_LIMIT_FACTOR ... you can set it to 1.5 to heavily reduce RSS usage of 2.1


Should have released tomorrow to be 21 and 1 day old. Looking forward to many more years with Ruby as my primary language.


> Looking forward to many more years with Ruby as my primary language.

Beware of complacency or you will find yourself unemployable when Ruby will be old news.

I didn't learn any new language since I started C# 4 years ago and I mightily regret it.


Well what's stopping you? Stop regretting and pick up a book!

I don't have much love for C# but if your fundamentals are sound you won't have too much difficulty picking up a new language. 6 months ago I wouldn't have known an NSMutableArray from a bar of soap, a couple of books and some elbow grease later and I'm beta testing my first iOS app for the app store (with a ruby backend : D). And I am far from one of those "polyglot" hyper programming geniuses.

Stop regretting, start working, and keep going. This time next year you'll have another arrow for your bow. It's not rocket science, believe me.


When was the last time a popular non-"platform" language became "old news"?


IMO Perl was as popular 6-7 years ago as Ruby is now. Today... it's not dead, but I wouldn't want to be a monoglot Perl developer looking for work.


Maybe 12-14 years ago? Perl's heyday was the turn of the century, I think.


Is there a such thing as a monoglot Perl dev? I've never heard of it.


Do you really think a majority of the web will be powered by Ruby in 20 years from now ?


Is it really that hard to switch platforms/languages? Learning a new language should not be so difficult, particularly once you've become familiar with a few.

There are so many factors influencing language and API popularity that it's silly to try to bet it all on one language/platform or vendor at any time in your life. Why not just enjoy the ones you use, and when they are no longer of use (for whatever political, technical or personal reasons), switch to something else?


In all fairness, if you don't anticipate a switch many years before you have to make it, you could get caught flat-footed. I personally have taken jobs where I didn't have any primary experience in the platform, but it was for, essentially, pocket change. I would hate to get dependent on a six-figure income predicated on knowing, say, enterprise Java, then suddenly find that nobody's hiring enterprise Java guys anymore and having to take a huge pay cut. Sure I could find a job. That doesn't mean it won't suck.


Does it need to be a "majority"? There are applications being written now, in Ruby, that are intended to still be maintained 20 years from now. Will the "new hot language" be something other than Ruby in 20 years? Well, yeah, by definition.


The majority of the web isn't powered by Ruby now. We have a hodgepodge of PHP, C#, Java, Perl, static, Node, Rails and other Ruby frameworks, Python, any I missed?

People have been proclaiming the death of Java for how long now? And it's still going strong. I'd argue that Ruby will last even longer than Java because it's a nicer language and has more room to grow. Ruby you can port to other runtimes, Java, why bother? It won't outlive the JVM.

The only thing I think that could replace Ruby is Lisp. Maybe in 10 more years Racket will where Ruby is today. I doubt it. By that time, Ruby will be where Java is.


> It won't outlive the JVM.

Well, the JVM will probably outlive the human race, so that's actually a comforting thought for Java developers :)


That sounds so ominous! What are you predicting the JVM will do to the human race??

And why will it comfort Java-ites?

I'm picturing something involving lairs carved out of dormant volcanoes and pools with sharks (possibly with lasers).


No. It isn't now, it hasn't ever been, and I would be surprised if anyone expected it to be so.

The more important question is: will it still be possible to earn a respectable crust doing web development in Ruby in twenty years time? Any person who claims to know the answer to that one is a liar.


By then we'll probably have decided it's a good idea to develop a JSON serialisation for HTML, and we'll all be writing client side web code 3 layers of code generators eventually targetting JavaScript, backed by a .js library that implements an Android VM


Fantastic. This release has all the fixes I'd been waiting on before going to production; I'll be deploying this week. Great work ruby-core and thank you as always. Twenty-one years, wow, time flies!


What are the fixes you were waiting for?



Yep.


This update is important because of the BigDecimal division bug in the bigdecimal gem that ships with 2.1.0 causes incorrect calculations when the denominator is less than 1.

https://bugs.ruby-lang.org/issues/9316


Happy birthday Ruby - my native tongue. Also one of the most welcoming programming communities out there.


Had no idea Ruby was THAT old. Congrats. The one language I need to pickup one day.


It's definitely worth really digging into (get the PickAxe book--it's incredible!). Even if you never use it for a real project, you'll learn new ways of approaching problems that can be used in other languages.


My first programming language. I haven't written a line of it in years, but it made programming feel fun and made me want to learn more. Shout-out to Chris Pine's "Learn to Program" tutorial.


Never fails. One day after I install the latest Ruby, they release the next version.


So, put in you calendar: Both February 24th and December 25th usually see Ruby releases. Don't install on the 23rd or the 24th ;).


With chruby and ruby-install, it's really easy to move between releases, and to new ones.


Via Matz on Twitter - The History of Ruby

https://gist.github.com/unak/3038095


Reading the changelog at that link made me realize that Ruby's core trunk is still hosted on Subversion!


I don't know how get Ruby 2.1.1 in Windows. RubyInstaller/RailsInstaller seems to be less updated


Are you really sure you want it? I tried running 2.0 in Windows for a while, and found enough gem compatibility issues that I don't think it's worth the trouble. I switched to 1.9.3, and almost every gem that was broken in Windows on 2.0 started working again.


RubyInstaller is usually a few days behind, but updated properly nevertheless.


I'm afraid that the latest release on RubyInstaller is 2.0.0-p353 (Nov 2013)



MINASWAN 4 LYFE :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: