Ruby 2.1.3 is released

Can confirm, I used this backport https://twitter.com/hone02/status/512254413000695808 codetriage.com memory usage dropped by about 200mb, saw my request time drop and CPU load drop. Freaking amazing <3 <3 <3

Won't this put more weight in the "long tail" of response times for server applications, since the occasional full GC would stop the world after a thread or process had accepted a request and begun processing? Are there any response-time numbers for Rails sites in-the-wild running 2.1.3 vs. 2.1.2?

I agree, although I do feel like runtime performance was the big problem with Ruby a few years ago. So fixing that was pretty huge.

Ruby 2.0 introduced named parameters with default values and 2.1 introduced required named parameters. These are useful.

For example, there are cases where you can replace options hashes with named parameters and get rid of guard clauses for key presence as well as lines that assign default values to keys in the options hash. And you don't have to index an options hash of course. The splat operator can be used to pass upstream options hashes to downstream methods taking named parameters so you can just refactor the downstream-most methods taking the options hash and get all these benefits.

It isn't so much that it's stagnated, but that it's so nice to start with that improvements are either going to be incremental in nature, or under-the-covers such as GC changes.

What I long for from other languages (looking at you Python) is the vast array of library bindings.

If you have any idea how much of a clusterfuck parsing Ruby is, you might understand why special-sauce like pattern-matching is going to take a while...

https://github.com/ruby/ruby/blob/trunk/parse.y

Languages don't need more features as they grow older. While Ruby isn't perfect, it does have the right "core" set of features in my opinion. What we're seeing happening to Ruby right now is fantastic. The language is getting some speed and memory enhancements. The next big face lift I expect to see Ruby get will involve better abstractions for concurrency in MRI.

I think the main reason for refinements not catching on is because of how poorly they were rolled out. I believe they were explicitly described as not for production use in 2.0 and how they worked changed in 2.1 (but I think they are now considered stable). The level of trust in the feature hasn't been high but may grow in time and especially once 2.1+ becomes the norm (after Rails 5 is released, I think).

As a longtime user of Ruby, improving performance is by far the primary thing I want out of the MRI team. Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence.

One of the topics that's been discussed for a long time is breaking the standard library into gems (installed by default), so they can be developed and improved separately from the core language. That's probably the #2 priority for me.

One of Ruby's strengths (and sometimes one of its weaknesses, too) is that it has a fairly decentralized ecosystem. The standard library is small and has had few additions since Rubygems was added to the core distribution. Frankly, it could stand to have more taken out of it.

Ruby is already a pretty big language (in terms of core features and syntactic complexity); I think the core team is well-advised to exercise caution in adding new features.

> And yet -- I feel like Ruby is growing stagnant.

I don't think that's really true. Its true that the releases since 1.9 (which, despite the wonky versioning, was in a sense the last thing that was really a major version bump for Ruby, similar to Python 3.0 -- and dealing, in a different way, with many of the same issues, particularly string encoding) have been less "big feature" releases, there've been significant but less-disruptive new features (both structural language features like named parameters and core / standard library enhancements) since then.

Really? I dislike them intensely. They always seem "inside-out" to me and it makes it really hard to group things into releases visually. I like Debian's changelogs so much better because they are release oriented.

You can expect libraries to follow Rails' lead.

The current rails (4.x) supports 1.9, but next year's rails (5.0) will require 2.x. So about the time that rails 5 comes out I would try to be ready to run 2.x in order to enjoy library compatibility.

I believe Ruby-FFI, if it does what you need, is more stable across Ruby versions than the Ruby C API, its also, unlike the C extension API, usable across Ruby implementations -- MRI, Rubinius, and JRuby all support it (not sure if any of the other implementations do.)

Personally I'd just hold out for awhile until the community updates everything. I personally am waiting for Brightbox to update their Ubuntu ppa packages before making the switch, as that's what all my production Ruby apps are running on.

I don't mean to come off as an ass, but just curious.

Why do you want to develop ruby (or anything else) with windows? Especially since most servers (where ruby is popular) are linux servers? All colleagues I've had running windows always seem to have to jump so many hoops that the *nix crows don't.

Also, no unix shell and package managers, how do you deal with it?

Have you tried using rvm under Cygwin ? If you can use rvm and Cygwin, you should be able to use the latest Ruby version.

I am not sure what the relevant tickets were, but I know that Luis wants to release, but some bugs in 2.1 were holding him back. Best ping @luislavena on Twitter.

I'm guessing that you'll probably have to build it yourself. Are you sure you want to use it, though? I haven't installed anything later than 1.9.3 32 bit on Windows since I discovered that that was the latest version that Nokogiri had pre-built binaries for, and using it with anything newer would require me to figure out how to build it against that version. It seems that anything newer than that may be a minefield of bugs on Windows.

But it is still my preferred language for scripting and automation on Windows.

Why not Vagrant? Yes, it's a VM, but it really makes it much easier.

Is the issue of using ssh/CLI the issue? If you plan to use Ruby professionally, you're gonna need those skills.

Additionally, some things like Redis, common to many Ruby apps, just won't run on Windows.

> Without being told to use a VM, installing Linux, buying a Mac, and without settling for the 2.0.0-p481 release of RubyInstaller; is there any way for a user to install this version of Ruby on Windows?

Yes, you can build from source.

OTOH, unless you want to develop windows-specific Ruby software (or work specifically on improving Ruby-on-windows), you are probably better off using a VM -- vagrant is your friend.

Here you go: http://rubyinstaller.org/downloads

(if possible, it's usually ~24 hours until the windows packages come in)

Fortunately this release does include a Windows release. The home page doesn't yet include a news item for this round of releases, but 2.1.3 is available on the download page.

http://rubyinstaller.org/downloads/

PHP has more ubiquity, so it's a least common denominator sort of thing. You can find tons of hosts running a LAMP stack, but not so many supporting Ruby. That is mainly because the tooling needed to maintain a Ruby application server has some additional complexity over PHP, which is mostly plug-and-play. Passenger helps a lot with that, but it's nowhere near the distribution level of PHP, so that is restricting the ecosystem currently.

Basically, most people looking to setup a WordPress install can't deal with even the simplest CLI. So things like Heroku or a one-click Digital Ocean box are out.

This could be a good idea for a startup...