Ruby 2.4.0 Released | Hacker News Reader

Ruby 2.4.0 Released

ruby-lang.org

256 pointssply105 comments

Compared to Rust, Go. The list of improvement for a yearly Ruby version is rather small. Some will argue Rust and Go are relatively new, but there are actually LOTS of low level performance improvement done within a year time frame.

Even if you compared to Python 3, the improvement is still rather small.

I know there is always the argument about the lack of resources, and Rust is being backed by Mozilla while Go is being backed by Google. But what about Python?

Exactly how much money is Mozilla spending on Rust, paying how many developers full time? Apple JS Core team is incredibly small, but they manage a B3 JIT compiler with 2 people.

How much money is needed? Matz and Tenderlove both mention they need more resources. Surely we can fund rise? With lots of successful companies using Ruby on Rails. Basecamp, Twitter, Groupon, Github, Gitlab etc. Or Ruby communities lack the compiler / JIT expert, can we hired some?

I am not trying to downplay the Ruby improvement. But I think Ruby needs more contributors. Moving to GitHub to get a higher exposure has been banned due to GitHub not being an opensoure product. But they also dislike hosting on Gitlab for some strange reason.

Just with the python/ruby comparison

I kinda feel like the reason for that is more due to the fact that if python users want change in their language, they really need to either construct their own pre-parser and deal with a lot of potential issues, or post a change, hope it becomes a PEP, and hope it gets accepted. There is very little ways other than that

In ruby, you are enabled to fix so much more of the language to your own liking, so there is much less of a need for the main language to change.

I'm not saying that ruby isn't underfunded, just that it doesn't need to grow as fast as python does

> In ruby, you are enabled to fix so much more of the language to your own liking, so there is much less of a need for the main language to change.

very true. lots of metaprogramming facilities in Ruby that just don't exist in Python. To further underscore your point, take a look at how much of Rails code is devoted to making Ruby more usable/consistent and has a only tangential relationship to web development.

What do you mean moving to GitHub has been banned? This isn't it? https://github.com/ruby/ruby

I'm pretty sure that is a mirror

https://www.ruby-lang.org/en/community/ruby-core/ suggests that the main repo is a self-hosted SVN

There are core contributors who would no longer participate because they refuse to use proprietary systems, even remote ones, and do not even run JavaScript. Matz prefers overall inclusivity to losing the contributors, so a wholesale move to GitHub (instead of RubyMine) is not going to happen.

there are lots of small improvement in ruby too, they are just not on this release notice.

Check the NEWS[0] file for a bunch more.

And Ruby 2.4 is about 10% faster than 2.3.3 according to some non-micro benchmarks[1].

Re funding: AFAIU the problem for Ruby seems to be the paucity of long term sponsorship deals, rather than one-off funding. Python has a bunch of those[2].

The lack of an important "ruby foundation" might be an issue there.

[0] https://github.com/ruby/ruby/blob/v2_4_0/NEWS

[1] https://gettalong.org/blog/2016/ruby24-performance-looking-g...

[2] https://www.python.org/psf/sponsorship/sponsors/

I would love to help hosting Ruby on GitLab. If it needs to be 100% OSS we can maintain a GitLab CE instance. I heard that sequential numbering of commits is also on the wishlist.

I feel that GitLab is the natural home for ruby nowadays. I hope Matz takes you up on the offer sytse.

Thanks Marc!

Rubyists have never been terribly concerned with performance. Ruby isn't a language you use for optimal performance. You use it for other reasons.

https://github.com/smarr/are-we-fast-yet

It is not about optimal performance. Ruby, or specifically MRI here, is anywhere between 20-100x slower. And there are other dynamic languages that is much faster then Ruby. If Ruby is only 2-10x slower no one would complain. But right now it is so far off the chart that is why you see a shrinking usage of Ruby.

There's "Ruby 3x3" plan to increase performance by 10x - https://blog.heroku.com/ruby-3-by-3

So when the plan will be realized, it would be these 2-10x slower than others.

I see a lot of people misinterpreted 3x3 as 9. Meaning Ruby 3.0 is going to be 9 times faster. ( I am guess that is where your number 10x comes from )

The article clear states that, as well as numerous other sources Ruby 3x3 means Ruby 3.0 will be 3 times faster. The problem is it will be 3 times faster then 2.0, and we already have 30-40% speedup from 2.0. So for Ruby 3.0 is likely only 2.2x faster then Ruby 2.4.

2.2x, in the grand view of things, is still very slow.

Python 2 to Python 3 was a disaster. Matz has made it clear in his speeches that he wont do the same mistake in Ruby. Performance and better memory management will hopefully come in the upcoming 2.5, 2.6 and 3.0 releases. What I want from all those changes is that all my current projects should just work.

Funny, I thought it had happened before in the ruby world with the switch from ruby 1.8 to 1.9 and the pythonists simply followed suit.

That's the obvious comparison. But in the Ruby world, 1.8 has long been forgotten. I don't know anyone still using 1.8, and we're all better off.

In python, on the other hand, years later it's still a shit show. The community still hasn't embraced one or the other. Some people still refuse to upgrade to 3.x. Everything is splintered. It's especially hurtful to newcomers.

I don't have any experience in compilers or JIT but developments in this for Ruby would be amazing. I know lots of Ruby devs who have to learn other languages because Ruby is insuitable for machine learning, matrix calculations etc.

There is actually JRuby, and Truffle + Graal implementation which is VERY fast. The problem is no one is using it. At least not mainstream site. None of the public Ruby Rails site uses JRuby.

I dont mean to be rude but Ruby communities, and within the Core team lacks expertise in Compiler / JIT programming.

Performance related:

  * Hash improvements via better locality for modern CPUs
  * #max and #min without temporary array
  * Speed up instance variable access

Regexes also had some changes which have improved our results on regex-heavy benchmarks by as much as 3x.

Nice! That's good to know.

I still love you, Ruby. I wish we spent more time together.

I was madly in love with Ruby in 2005 but now, Ruby feels like this ex girlfriend you were completely infatuated with and eventually broke up with because you were too young to pay attention to her flaws.

Since I never picked up ruby (I joined Python and now I'm about to pick up ruby). Curious what made you move away and what you've moved to?

It's dynamically typed, which is a deal breaker for me today. I need not just a type system but one that supports parametric polymorphism, so definitely not Ruby, Python or even Go.

You can use traits instead. I know it's different, but it probably solves your problem.

Traits are orthogonal to the dynamic/static question.

My experience has taught me that not having type annotations in a source code makes it very hard to understand and maintain that source in the long run.

Ruby is more than flexible enough for you to add type annotation via DSLs, and use them to drive tests/fuzzing if you want that. There are a lot of people who have done that.

They rarely see much use, though, because most of us quickly experience that the type annotations that seem essential when we work on statically typed languages quickly become less essential once you adopt a more idiomatic Ruby style.

E.g. if you want to output something as text, rather than dictate what should be passed in, call #to_s on it (and optionally handle the failure if it doesn't implement #to_s, if it is reasonable to continue).

Once you adopt the attitude of asking for what you actualy need rather than demanding the client pass in what you think should be passed in, type annotations start feeling like a clamp around your foot rather than a necessity in most cases, and most of the remaining assistance they could provide tends to fall away with test cases you would require in either case.

I used to be a static typing zealot, and I still want things to be "as static as possible", but I've come to accept that most of the time the burdens it adds are not worth the benefits.

I'm sure we can do better, and there are certainly cases where optional static type annotation could be helpful, but at this point I'm not giving up the expressiveness dynamc typing gives me - a static system would need to be practically "invisible" for me to find it acceptable.

My experience has taught me that if static typing improves your code, it's probably hiding deeper flaws.

I won't deny there are some clever things one can do to improve code with sophisticated typing. However, the typical usage is to alleviate the mistakes of bad names and poor design. When I find type errors at runtime, I look for a way to refactor that avoids confusion without needing to add type checking. I don't always succeed, but when I do the code is more elegant.

Statically typed is my deal breaker. See how varied people are? :-)

Can't speak for GP but for me the kicker was that you cannot get any guarantees on the mutability of an object, and the unexpected quirks that could result from it. Example:

https://redmine.ruby-lang.org/issues/6037

You can (must) be pragmatic, of course; and assume that all will go well. But under the hood, it means a great many objects get pointlessly allocated and reallocated - or not, sometimes, with hard to find bugs occurring when a gem author overoptimizes their code to avoid making a few object copies, and ends up mutating your object's properties without you realizing it.

Things have improved since, with e.g. strings being frozen by default if you want them to be since a few versions ago. Even in this changelog, there's a least one point related to memory allocation that touches the performance consequences of needlessly allocating new objects.

Back then, I found Obj-C (and Swift, maybe?) more conforting in this respect, with most things being immutable unless you explicitly requested the mutable version. And I liked ARC a lot. (I haven't programmed much in recent years, so can't say what I'd use today if I were neck deep into code. Probably Swift.)

Another issue was that Ruby was then attracting a lot of end-users that had no formal software engineering skills. Which is fine for day to day tasks; not so much when they start distributing libraries. (Always vet your gems' authors and source code.)

I still love Ruby, mind you. It's beautifully expressive and it's still my preferred language for non-trivial "glue" tasks.

"Accidental" mutability in gems tends to cause pain - spotted this one in Rails, for example.

https://github.com/rails/rails/pull/25735

Maybe you were actually too young to know how good it really was. :P

I'm very likely older than you are, so... no.

It was very good at the time. Not so much today. We've learned a lot in language design and Ruby feels very antiquated (mostly because it's dynamically typed).

Try Crystal, her younger sister. Just as beautiful but more nerdy and fast thinking.

Can we stop using women as a metaphor now? Especially if beauty is the first criterium and she's apparently just waiting to be "tried"? Thx

Which statically typed language do you feel offers the same level of developer comfort as Ruby?

My favorite statically typed languages are Haskell, Rust and C# but I prefer Ruby over them whenever possible.

> Which statically typed language do you feel offers the same level of developer comfort as Ruby?

So far, Kotlin has hit that sweet spot for me.

What have we learned? Does LISP feel antiquated to you as well? How about Java?

What have we learned in language design that wasn't known prior to Ruby? It's not like static vs dynamic hasn't existed in languages since the 50s to early 60s. Alan Kay, in creating Smalltalk (granted in the 70s), was motivated by the limitations in static type systems. If you think a language like Haskell has solved that limitation by providing an extensible form of static typing, fine, but it existed before Ruby (1990). Elm isn't breaking new ground on this front.

I appreciate that you were responding to the analogy the parent comment offered, but without concrete criticisms it comes across to me as a sort of haughtiness and an insult to those who haven't caught up or are too blind to have dumped Ruby by now. That seems especially out of place in a thread about a new version of the language.

To me, Ruby feels like this ex-girlfiend I was completely infatuated with and eventually broke up with because I was too young to pay attention to the fact that her flaws were in all the right places instead of the ones that truly matter.

Soo, so true.

Working with Tensorflow, python is unfortunately the only realistic option. I'm getting the hang of it, but I'd still love to use ruby for it – it's all just data wrangling, it doesn't even need to be fast, and ruby code is just beautiful (to my eyes, I know it's a matter of opinion).

I've also only recently discovered the beauty that is rake. Especially for data pipelines it's a fantastic tool. Hit a bug? No need to rerun everything – it'll pick up at the exact step that failed. One of ten data files changed? It knows exactly what needs to be redone. Etc.

Make does the same thing, but boy is rake syntax nicer.

> python is unfortunately the only realistic option.

https://medium.com/@Arafat./introducing-tensorflow-ruby-api-...

https://github.com/somaticio/tensorflow.rb

Pretty cool to see a binding.pry analog moved into the standard library.

Could binding.pry/binding.irb be shortened at all? It's a mouthful.

Sure.

    require 'pry'
    module Kernel
      def debug; binding.pry; end
    end
    
    x = "hi"
    debug

I was imagining more at the level of the standard library or the pry library.

Or do you recommend this monkeypatch in practice?

Won't the binding then be your monkey patched debug method on kernel instead of where you called it from?

Yes.

    irb(main):008:0> x = "1"
    => "1"
    irb(main):009:0> debug
    [1] pry(main)> x
    NameError: undefined local variable or method `x' for main:Object
    from (pry):1:in `debug'

If you really want to do this, you can use binding_of_caller[1] to create binding object (`Kernel.binding`) up in the call stack:

    require 'binding_of_caller'
    require 'pry'
    
    module Kernel
      def debug
        binding.of_caller(1).pry
      end
    end

Then:

    irb(main):008:0> x = "1"
    => "1"
    irb(main):009:0> debug
    [1] pry(main)> x
    => "1"

[1]: https://github.com/banister/binding_of_caller

That's an editor problem.

Interesting choice to remove `tk` from the stdlib. It always felt a little neglected in terms of documentation and maintenance, but it was nice to have a simple graphical toolkit guaranteed with the runtime.

I tried to use it, settled on Shoes instead. Tk isn't free, you still have to install OS dependencies, and it's API wasn't very Rubyish.

You'd think Ruby would be swimming in easy-to-use widget libraries. But it still isn't. Shoes fits most of my needs, though I'm still working on my workflows and tooling. It's annoying that I can't just write to the console or drop in a pry session, but I'm slowly figuring it out.

Yeah, Tk certainly isn't a pleasure to work with in Ruby. Maybe my experience was colored by the fact that it always worked out-of-the-box on my desktop (I guess the libraries were preinstalled).

I've looked at Shoes multiple times for various projects and it always looks terrific, until I remember that installing it involves downloading a 64-bit binary from a website. I've bitten the bullet before and done it, but it's an (ugly) step backwards compared to `gem` and the Qt/Gtk+ bindings that can be installed via `gem`.

Yeah, shoes :( Such potential. I could never quite get it updated to Ruby 1.9. Sigh.

It looks like recently, there has been a convergence of hashtable implementations across a number of programming languages. Details differ, but the general structure is now to use two arrays, one for storing the data in insertion order (thus maintaining order without a doubly linked list), and another array serving as a hash, which contains indexes into the data array. This general idea works both with chaining and open addressing. In the last couple of years PHP (first HHVM then Zend), then Python (first PyPy then CPython), then Ruby (MRI) have switched to using this layout. Interestingly, Python has previously not made guarantees about order of hashtable elements, so this layout is advantageous even if maintaining insertion order is not a hard design constraint.

How do they remove elements from the first array? Suck it and do O(N), or is it storing (value, deleted?) pairs?

Look at the index as given by the hash?

Oh, so as you iterate the array, look up the value in the hash and if it's not there skip it?

The downside is you end up accumulating dead values.

It also helps with cache locality.

Why was BigInt and FixNum unified into Integer? Don't they already both subclass Integer?

It seems they just made it harder to write interfaces that take advantage of machine precision integers. They didn't remove either arbitrary precision integers or machine precision integers, they just made them harder to distinguish. Why is this an improvement?

because the existence of Bignum and Fixnum is effectively an implementation detail, Float is now implemented in a similar way for example, without having corresponding Flonum and Bigfloat.

There isn't (at least I've never seen it) any reason to distinguish between the two, Fixnum wasn't the proper tool to do machine-precision integer operations either (31 bit).

But isn't hiding implementation details best done by using an interface (like the Integer superclass) rather than some flag somewhere with branching logic? Fixnum _is_ useful for C extensions to quickly convert to `int`, but now I suppose you don't know whether an Integer is cast-able to an `int` unless you inspect this flag in a new custom way.

Looks like it breaks gem install json -v '1.8.3' - it does however work with json 2.0.2

And it's likely the static vs dynamic programming debate has been around longer than you coding ;).

We detached this subthread from https://news.ycombinator.com/item?id=13252935 and marked it off-topic.

Not sure why they decided to release on Christmas eve / day, but looks good.

Because tradition. Most of the major ruby version are released on christmas day.

I didn't know that. TIL. :-)

And it actually comes from perl, which used to announce their next big release on christmas. but it never came, and they claimed they never said which christmas, just one eventually.

It's defined in their (somewhat oddball) version policy: "MINOR: increased every christmas, may be API incompatible"[1]

[1]: https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-po...

Because ruby was one of the gifts given to the new born king, baby Jesus.

It sure beats frankincense

And mir. Wtf is mir?

https://en.wikipedia.org/wiki/Myrrh

https://en.wikipedia.org/wiki/Mir

https://en.wikipedia.org/wiki/Mir_(software)

https://blog.rust-lang.org/2016/04/19/MIR.html

https://www.youtube.com/watch?v=WIjBO26qjYM&t=45s

Not completely sure why I was downvoted, but I'm sorry for any offense I might have (accidentally) caused

Unlike Reddit, jokes are generally not we received on Hacker News. The community prefers relevant, on-point discussion to keep a high signal to noise ratio. This isn't to say some jokes aren't tolerated, but it's best to shy away from them unless you have something really great to add.

We should be able to crack a smile in response to light-hearted comments like that at Christmas :)

See, this is probably why I don't get many upvotes. Joking is pretty much my default response to everything

Reply on news.ycombinator.com