
Ruby 2.5.0 Released - phereford
https://www.ruby-lang.org/en/news/2017/12/25/ruby-2-5-0-released/
======
skywhopper
When I discovered Ruby 12 years ago, it was an amazing moment. All the
features I loved from my previous favorite languages Perl, Smalltalk, and
Scheme in one place, but with a much more reasonable syntax, a far more robust
standard library, a complete and dead-simple packaging system, and a practical
and portable runtime. The fact that it still feels magical, fun, practical,
and pragmatic all at the same time while progressing and improving step by
step each release after all these years is a truly amazing feat, especially
when you compare it to its peers.

So congratulation and thanks to Matz, and all the other Ruby contributors for
creating and maintaining and growing and improving this amazing language
that's still my favorite. 2.5 looks great, and I can't wait to see what's in
store for the future.

~~~
pka
I started a new contracting gig a couple of months ago, in Ruby. I had used it
briefly years before in another project, but it was so long ago that I had to
learn it again basically from scratch.

Although I don't really think the language is anything special (i.e. it's a
standard dynamic OO language), what really turns me off Ruby is this dogmatic,
almost religious aspect of its community.

Take POODR - it's more or less the community bible. If it's not written in
POODR - don't do it. If it is - do it that way or else. It's POODR's way or
the highway.

According to more experienced Rubyists more than 80% of the Ruby community use
Rails. Rails is so widely spread that its development even fundamentally
affects Ruby's roadmap.

Now irregardless of what you think about POODR or OO or dynamic types or
whatever, a homogenous echo chamber filled with people chanting the same
things over and over again is _not a good thing_.

As a counter example, take Javascript. Yes, it has its warts; its equality
table is a joke. Ruby is a better thought out and implemented language in
almost every aspect (although I do like Javascript's minimalism better, but
that's a matter of taste I guess.) However, Javascript's community is as
diverse, vibrant and experiment-friendly as it gets - there are the OO
diehards, but there's also React, fantasy-land, macros, monads. People are
trying out new things constantly.

Now I know you have monads in Ruby too or flow-like gradual typing libraries
or rewrites of Clojure's spec. But at least where I work (and I work with some
very experienced Ruby people) those libraries and the ideas they embody would
never ever be considered as serious alternatives for anything. POODR or else.

~~~
tres
Huh... didn't even know what POODR was...

Guess I've been faking it for the past nine years... I mean, I _did_ start a
company that used Ruby/Rails as the primary platform. And I've worked the last
six years in a shop that currently has a team of about 12 Ruby/Rails
developers...

Don't get me wrong, Ruby's a tool in my toolbox; I use it like I would any
other tool. I like solving problems. Most modern languages make it easy and
fun to solve problems.

I don't like when it's easy to see where a language is encumbered by poor
choices (I seem to have a diametrically opposed viewpoint of your opinion of
the Javascript community; to me, the redundancy, low quality and churn of
community libraries is one of Javascript's greater liabilities). But if it
works for you, that's great.

Language Holy Wars are necessary for young, budding languages and young,
budding programmers. Language Holy Wars help young communities draw others to
their banner and young programmers define themselves. Unfortunately, having
causes and "bad guys" is a big part of the underlying way we work as people.

But at some point, once a language's adoption has reached critical mass & once
you've reached a point where you're comfortable with the underlying paradigms
of programming, these Language Holy Wars get left behind for more interesting
problems.

I mean, I definitely have opinions about what language I'd prefer to be
working in and why, but at this point, I make my determination of technology
based on the right tool for the job, not necessarily my opinion of any given
language.

~~~
pka
(To you and everybody else)

Point taken - apparently I mistook the particular echo chamber I happen to be
in at that moment for a more general symptom. Glad to hear!

~~~
tres
Sorry, I think I got a bit sidetracked in my response.

I do hope that your current situation gets better or that you find somewhere
that isn't so preoccupied with navel gazing.

------
nileshtrivedi
Ruby may not be the cool thing in town it once was, but it remains my
preferred language for prototyping ideas - purely because of its elegance and
expressivity. It truly delivers on its fundamental goal of "developer
happiness". A lot of ideas from Ruby have gone to other languages
(CoffeeScript, Elixir) and many web frameworks are modelled after Rails.

Congrats and thanks to all the core devs! :-)

~~~
abritinthebay
See, expressive I totally get. Absolutely. But elegance? Don’t understand that
one.

Ruby is a cluster of inelegant and over concise cludges in the name of
expressivity. The fact that it was once most famous for one of the most
inelegant hacks - monkey patching - as a core feature speaks to that.

So I totally understand that it’s quick, it’s expressive, and it’s easy to
prototype in. Agreed. It’s lost a lot of it’s shine there now but it’s all
still true.

But elegant? It’s concise, not elegant.

~~~
stouset
Disagree 1000%.

Just because you _can_ write a monstrosity in Ruby doesn’t make the language
itself inelegant.

Ruby, of the many languages I’ve used, has by far the highest potential for
code being poetry. You can find solutions that are incredibly simple and
understandable due to so much boilerplate being remove from the syntax.
Likewise you can write code that’s impressively concise without being
inscrutable — I’m continually astonished by how _readable_ Ruby can be.

One exercise in particular sticks out in my mind. Many years back, I
implemented the first few dozen Project Euler problems in Ruby. However, I
imposed a limitation: each solution had to be under 72 characters (library
inclusions are fine), a single logical line, and _readable_. The end result
was surprising at how naturally it ended up working — the solutions ended up
being little more than the high-level conceptual approach, translated
literally to code. Solutions ended up looking like the following:

    
    
        (2 ** 1000).digits.sum
        (2..10_000).amicable_numbers.sum
        1901.to_year.upto(2001.to_year - 1).select {|d| d.mday + d.wday == 1 }.count
    

Sure, these depended upon injecting new methods into core classes, but who
cares? For _this_ problem it led toward incredibly straightforward and
readable solutions for these problems. If this were library code I wouldn’t
dream of doing it this way, but for application code — why not?

I have yet to see any other language with Ruby’s capacity for readable
conciseness.

~~~
dmitriid
> Sure, these depended upon injecting new methods into core classes, but who
> cares?

I, as a developer reading your code 6 months later, care.

When something fails, it's nearly impossible which of the magic methods were
injected by which magic library.

~~~
nfm
Not really. It's hard for your editor to do this statically, but there's heaps
of good tooling for finding the method source and docs dynamically.

    
    
      pry> show-source SomeClass.class_method
      pry> show-source AnotherClass#instance_method
      # List an arbitrary object's class methods, instance methods, methods mixed in by included modules
      pry> cd some_object
      pry> ls
    

The runtime knows how to execute your program (it's not random) so everything
you want to know is available.

~~~
dmitriid
You realise you just validated my point, right? :)

~~~
stouset
I'm not sure you did.

People who don't use Ruby seem to think this is a huge thing that you run into
constantly. It's not. People are for the most part pretty responsible with
these things.

------
WJW
I started using Ruby only in April this year due to starting at a new job.
Having used and/or dabbled in C, Java, Python and Haskell before (amongst
others), I find it super interesting to see how Ruby manages to take some
interesting parts from each and manages to integrate it into a very pleasant
programming experience. Also the rspec testing library is nothing short of
magic, none of the compiled languages have anything that even comes close IMO.

For the cases where you have a tight loop taking up 99% of the actual CPU time
it is also relatively easy to hook in C or Rust or whatever. Also, sometimes
you hit hardware performance limits regardless of the language you use. We
have some streaming download servers written for 99% in Ruby using the libCurl
bindings that and they easily manage to fill up the 5 Gbps pipe* per server
that AWS gives us.

* You can get 20 Gbps for some instances, but only to other instances in the same group. The biggest to the 'outside' seems to be 5 Gbps.

~~~
fred123
I'd be very interested to know what you mean by "nothing short of magic". I've
had a quick look at the rspec documentation and as a Python dev this looks
very similar to what's in the Python standard library. Would that be
considered magic as well or does rspec have some cool features that I have
missed?

~~~
chrisseaton
rspec’s internal DSL is based on Ruby’s multi-line anonymous functions. I
don’t know how you achieve a similar design in Python where you don’t have
those in the same way. How do you write the equivalent of ‘it ‘does something’
do ... end’ in Python syntax?

~~~
pmontra
This seems a good starting point
[https://stackoverflow.com/questions/37334668/is-there-a-
pyth...](https://stackoverflow.com/questions/37334668/is-there-a-python-
equivalent-for-rspec-to-do-tdd)

TLDR: not as nice as RSpec but close.

~~~
chrisseaton
> not as nice as RSpec

Right, well that probably answers the question about what they thought the
magic is.

------
geraldbauer
FYI: I've collected articles / blog posts about what's new in Ruby 2.5 over at
the Ruby Advent Calendar [1]. The list so far includes:

\- Standard Gems 2.5.0 - Default Gems, Bundled Gems // by Jan Lelis,
Idiosyncratic Ruby

\- 10 New Features in Ruby 2.5 // by Junichi Ito, Ruby programmer @
SonicGarden.jp

\- 10 More New Features in Ruby 2.5 // by Tom Lord, Software Developer from
London

\- Performance Improvements in Ruby 2.5 // by Jesus Castello, Ruby Guides

\- yield_self in Ruby 2.5 // by Michał Łomnicki

\- Improved stacktrace display in Ruby 2.5 // by Michał Łomnicki

\- Ruby 2.5 Series // by Amit Choudhary, Mohit Natoo et al @ BigBinary

[1]:
[https://planetruby.github.io/advent2017](https://planetruby.github.io/advent2017)

------
greysteil
Nice to see the 3x3 work continuing to go well with that 5-10% speed up. For
anyone who hasn’t seen it, Ruby declared a target for Ruby 3.0 to be 3x faster
than 2.0.

[http://engineering.appfolio.com/appfolio-
engineering/2015/11...](http://engineering.appfolio.com/appfolio-
engineering/2015/11/18/ruby-3x3)

~~~
diminish
What particular speed improvements do we expect from 2.5.0 release? String
interpolation speedup?

~~~
greysteil
ERB generation should be a lot faster, which will be a boon for a lot of Rails
apps, and according to the release notes there's a 5-10% performance
improvement overall from removing all trace instructions from bytecode.

~~~
semiquaver
Rails has not used the stdlib ERB implementation for a long time. As of 5.1 it
uses erubi [0] and prior to that it used erubis. [1] So the performance
improvements to the stdlib ERB implementation will not affect rails apps.

[0]
[https://github.com/rails/rails/pull/27757](https://github.com/rails/rails/pull/27757)
[1]
[https://github.com/rails/rails/pull/16773](https://github.com/rails/rails/pull/16773)

------
elliotlarson
Oh, it looks like Bundler didn't make it into the standard library for the 2.5
release. The commit to bring it in was reverted just before the release, with
very little explanation. I mean, it's not like `gem install bundler` is that
hard to do, but I'd be curious to hear why.

~~~
ksec
Same thoughts here, I thought that was the important step to gemify everything
in 2.6. Are they reverting course?

------
artellectual
Was waiting for this!! Super happy about this. I’ve come to expect this every
year now at this time.

Ruby is still one of the most productive languages out there. I just love it.
It gives me great joy that 10 years ago I chose Ruby to be the language for my
future.

My wish this coming year is to be able to contribute more to the Ruby
ecosystem.

Btw I’ve also built something using MRuby this year. The whole ecosystem is
just great.

~~~
eropple
I've really wanted to find a good use for MRuby (probably to noodle around
with game development, as an embedded language) but figuring out where to
_start_ is really hard. Any tips?

------
CiPHPerCoder
Ruby's SecureRandom is finally sane to use? It's like Christmas or something!

[https://bugs.ruby-lang.org/issues/9569](https://bugs.ruby-
lang.org/issues/9569)

Now to update the "how to generate secure random numbers in various
programmming languages" documentation.

------
taf2
Anyone else noticing syntax ruby parser regressions?

e.g.

    
    
      class FooBar < Foo
        prepend_before_filter only: [:create, :destroy] { 
      request.env["hello.skip_timeout"] = true }
      end
    

was valid in ruby 2.4 but invalid now in 2.5

~~~
InAnEmergency
I believe this syntax was only accidentally valid: [https://bugs.ruby-
lang.org/issues/13939#note-5](https://bugs.ruby-lang.org/issues/13939#note-5)

------
iovrthoughtthis
rescue on do blocks!!! Wooooo. Merry Christmas!

Ruby is a joy to use.

~~~
Lockyy
Can’t beat reversing the backtrace output for making Ruby even more enjoyable.
Slogging up through a huge pile of calls was one of the few things that drove
me mad.

~~~
taf2
Just need to rework all these

e.backtrace.first lines to e.backtrace.last

Or maybe my favorite which is still good

puts “#{e.message} #{e.backtrace.join(“\n”)}”

~~~
sampriti
That code will still work, they are using the experimental feature only when
the backtrace is printed to a tty.

------
raitom
Every year it's the Christmas gift I wait the most!

------
burlesona
There's no such thing as a perfect language, but Ruby is a very nice one, and
the community is just such fun. The tradition of major version releases on
Christmas Day each year is one of my favorite things!

Cheers to Matz and all the Ruby contributors :)

------
hit8run
I absolutely love ruby and its community :) My software goals for next year:
\- Start a new platform built on Ruby/Rails. \- Contribute to the ruby eco-
system. \- Enjoy it.

------
drchiu
Love Ruby. Back a few years ago before I learned to program properly, I found
a lot of the syntax of various languages to be hard to understand. I was not
trained as a computer science major, mind you. Nonetheless, the syntax of the
Ruby language made things easy enough for me to digest. Heck, even ended up
starting a Ruby based software company won’t employees — something I couldn’t
have imagined doing even a decade ago.

------
jph
Test Driven Development (TDD) gets a huge improvement with the new coverage
capabilities for methods and branches. Thanks Ruby team!

~~~
ajmurmann
I'm surprised by this comment. Having done TDD for many years now I've only
ever felt the need for coverage tools on code that wasn't initially TDDed. If
you do proper TDD your coverage is always pretty damn close to 100% and you
are already well aware of where it isn't because you struggled TDDing in the
first place.

~~~
allcentury
That's true until you decide to delete tests/code that is no longer in use.
Then it becomes much more difficult to track down dead code paths

------
drish
> Mutex is rewritten to be smaller and faster. [Feature #13517]

This is something I find to be using quite a lot, great to see this.

------
taf2
looks like we have some gem authors that need to update their stuff...

google-protobuf-3.5.0-universal-darwin requires ruby version < 2.5, >= 2.0,
which is incompatible with the current version, ruby 2.5.0p0

[update]

looks like this is resolved by forcing bundler to compile instead of grabbing
the precompiled versions.

------
nazgob
Many thanks to all who contributed!

------
onetwotree
Hey they finally fixed the issue with SecureRandom using OpenSSL instead of
the OS CSPRNG implementation!

I worked for a company a few years ago that made security software, with Ruby
as a primary language, and this caused no end of frustration...

------
rajangdavis
I had installed Ruby on a Windows 10 machine a few weeks back and had some
issues setting up Ruby 2.4.*.

I forgot where the issue came from (I think it was some issue with bundler or
ruby gems), but can I install 2.5 without breaking my set up?

------
knodi
Jebus!! this is about Ruby 2.5.0 release not about why you think Ruby sucks.

------
artsky
Awesome! I'm excited about the new yield_self method, and the general
functional programming direction that Ruby is moving in.

------
igravious
Thank you Matz & co. <3

------
pankajdoharey
i loved ruby and i still do but my focus has now shifted to scheme/clojure and
lisp family dialects like racket, and i don’t see a reason to return or move
to anything else it feels like my search is over.

~~~
eropple
If your "search is over", you're doing it wrong. Something sucks about
everything you are using, no matter what it is. There is a better thing, even
if you must make it.

~~~
vemv
Would agree with your view, but Lisps are arbitrarily powerful by the means of
macros and interop.

In my daily work (Clojure) I can use different concurrency and typing models
than Clojure originally envisioned, via core.async, clojure.spec. This is not
some fairy tale or toy/PLT project.

How many languages can fundamentally change themselves without breaking things
or getting awkward?

~~~
eropple
Lisps are arbitrarily powerful, yes, sure. Once I too was a Lisp head, I am
familiar with the advocacy.

They also read awfully even with an editor designed for them. They aren't
human-first languages. S-expressions are _easy for a computer_ , they are
_hard for a human_. So, yeah, that can be improved, too. "But you can do it
with macros"\--other people _won 't_, and so you are thus devolved to the
minimum set everyone can agree upon, and it's gonna be awful.

And so there is room to grow outside of one's parentheses, too.

~~~
vemv
Threading macros (-> / ->>) can greatly improve readability, putting lisps on
par with Ruby (which I appreciate much).

Best of all, emacs/Cursive lets you trivially transform a sexpr into a
threading form, and back. So one doesn't even have to do much effort for
refactoring nested (a(b(c(d calls.

~~~
eropple
I totally get that--what I'm saying is that, much like something like C++, you
can only practically use the subset everybody you have to work with will agree
is acceptable. Threading macros, IMO, help but don't really _solve_ the
readability problem, and it's still a far sight from Ruby, but it's a good
step. But you have to get Bill the chin-stroking graybeard down the hall to
use them when they're "not how he uses Lisp." Contrast this to a language with
more guardrails--the equivalent of that threading macro in Ruby (or in Scala,
or in F#) is just...The Way You Do It, it's the standard of the tools
involved.

You're transforming a linguistic readability issue into a cultural problem of
agreement and that's a _waaaay_ harder problem to solve, IMO. Lisps are cool.
But every problem raised to "cultural problem" is so much harder to solve.
(When was the last time you saw an indent war in Ruby?)

~~~
vemv
Your observations are on point, and collaborating with lispers is not free of
bitter moments.

At work we use cljfmt (similar to gofmt) plus a variety of hacky formatters
and conventions. It works for us and I hope to open-source part of our stack
at some point!

The experience is similar to that of Rubocop - which btw is the reason why
there aren't indent wars (or similar) on Ruby.

Great to decomplect how code is written (however you please), from how it is
committed (autoformatted).

------
sadiqmmm
Awesome! :)

