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'm a longtime Ruby user (among a number of other languages). I feel very productive in Ruby right now, with Python being a close second. It's also vital to the functioning of my current startup (along with Go).
And yet -- I feel like Ruby is growing stagnant. Don't get me wrong: 2.x has brought lots of performance improvements, and some very smart people are constantly making it better, for which I'm eternally grateful. But I can't name a single 2.0-specific feature that I actually use. Refinements were the biggest thing I can think of, and in an informal survey of some other CTOs I know on Ruby stacks, nobody was directly using them.
Additionally, for a lot of the features I've come to love in other languages (e.g. pattern matching), my impression is that no one's talking about them in the Ruby community. Much of Ruby's success came from making it one of the most enjoyable languages to develop in, and that's unquestionably still there. But I stare wistfully across the sea to some of alternative choices, and I wonder how much longer that will be true.
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.
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.
> Erlang-style pattern matching would be nice but I can't say I'm hurting for its absence.
My memory is hazy, but doesn't Erlang have unification rather than pattern matching? If so that seems quite harder to get than "plain" pattern matching (i.e. copying the Scala model with user defined extractors)
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.
> Languages don't need more features as they grow older
I am not sure that is true.
Many of the "old" languages that are still successful seem to have changed over time, while most of those that have stayed mostly unchanged seem to have lost mindshare (even if they had most things to begin with).
It is probably a marketing problem.
One of the features of Ruby is simplicity. In that case, more features will usually mean less simple. The feature of Java and C++ is features, so the way for them to stay relevant is more features.
I have used ruby for a long time so 99% of it makes sense to me, but it definitely is _not_ simple.
Still, some increase in complexity may be acceptable: we have limited destructuring and case equality, pattern matching would be just a bit better.
We have `Struct` which creates classes with positional arguments, but not a version that takes required parame even if it's a natural extension.
We might have better composability for mixins etc..
And we can keep removing things (some more perlisms, for one).
I agree about removing Perlisms. I love pattern matching and don't think it would be more complex. I just don't think adding pattern matching would be easy or performant given Ruby's syntax.
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.
> 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.
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).
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...
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.
I used to develop Ruby C extensions a lot, but I'm just now getting back into the game. What Ruby versions are considered "current" enough that libraries need to support them? Is the 1.9 line still in wide use? How far back in the 2.1 line is in common use?
Normally I wouldn't worry too much about this, except that I've heard that the Ruby C API changes substantially from release to release. Is this true? Anything in particular to watch out for?
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.)
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.
> The current rails (4.x) supports 1.9, but next year's rails (5.0) will require 2.x.
The recent Ruby 2.2-preview1 announcement included a statement that the upcoming Rails 5.0 would require Ruby 2.2 (which should have a general release this Christmas), not just 2.x.
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?
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?
I have used Ubuntu and Mac OS in the past, but I am currently favouring doing all of my work on Windows. All of the tools I need run perfectly fine on Windows (and many of them, not on Linux at all), and it would be a hindrance to switch to another operating system.
It is only Ruby which is difficult to keep up to date on Windows. My question was to try and find a solution.
I have tried using a VM (VirtualBox and VMWare), but it is not a desirable work flow. I currently use RubyInstaller.
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.
Thanks for the response. Ruby is the only tool I currently use in development on Windows which I have flagged as a potential problem to maintain in the future. Thankfully, Ruby is a rather small part of my workflow, so waiting on RubyInstaller is fine at the moment.
My question was more of a concern for the future of my current dev setup. I was hoping someone on HN would know of a better solution to install Ruby on Windows manually, without having to wait on RubyInstaller.
> 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.
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.
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 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 have never used Cygwin before. Thanks for referring me to it. I am currently trying to find the simplest solution for keeping Ruby up to date with the current releases, but having a hard time doing so on Windows. I will experiment with Cygwin at some point.
I hope to see whether Ruby could create a platform like Wordpress with that strong community. A simple plugin system for the world to use and extend. Is PHP stronger Ruby ?
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.
Stock Ruby 2.1 was unusable on heroku because of this issue.
https://bugs.ruby-lang.org/issues/9607