The Future Shape of Ruby Objects | Hacker News Reader

The Future Shape of Ruby Objects

chrisseaton.com

153 pointschrisseaton9 comments

I love well researched but easy to digest posts like this.

For me Ruby remains a really interesting language and I really appreciate the engineering efforts to improve it without loosing what's fun about it.

losing*

It's similar to the way V8 works.

This idea has a huge drawback. An instance, can have different shapes depending on the order you discover the fields, by example, if you have a point(x,y), the shape is different if you assign @x first or @y first.

So even if a code is not polymorphic for a human, it is polymorphic at runtime.

In practice, doing a static analysis of the code (maybe only the constructors of the hierarchy) is still needed to alleviate this issue.

I can't remember how much of the data we put into the original paper, but we found that in practice idiomatic Ruby objects do generally have stable instance variable insertion order and so stable shapes.

Unstable insertion order does introduce polymorphism that's true, but that's a fairly linear and gentle performance overhead. I wouldn't characterise this as a huge problem myself. Mis-predicting object layout if you try to do it statically like Rubinius does is a full-on performance cliff and pretty catastrophic.

Very interesting overview, hopefully MRI will be receptive of the idea.

Fascinating article. Shapes are amazing. It's just like how variables in static data structures are accessed by offset. Shapes are a fully dynamic offsets table that are made static again at run time by the optimizing compiler.

Reading articles like this has the surprising effect of making me wish for something analogous to the Java Community Process. Improvements to the language can be proposed by organizations or individuals. Here, Chris (or -- more likely -- Shopify) could introduce object shaping as a proposal. This would trigger a set of steps [1] that would allow for the proposal to be more carefully studied, an initial implantation put into place, and eventually have it become part of core.

As things currently stand in Ruby-land, however, Matz and DHH rule the roost. This has given rise to split implementations. For example: Sorbet (created by Shopify) and RBS (created by Square) are means to add static typing to Ruby. I am sure each has strengths and weaknesses. The larger point is, however, that there shouldn't be two implementations of something so funamental, even if they are mutually compatible. When generics were introduced to Java you didn't have one flavor from IBM and one from, say, JetBrains. There was just generics.

tl;dr: Ruby (and Rails) would benefit from having a structured, democratic process to introduce changes.

[1] https://jcp.org/en/jsr/stage

>tl;dr: Ruby (and Rails) would benefit from having a structured, democratic process to introduce changes.

Well except Ruby Core has talked about this and doesn't like the idea of PEP or JSR. Those are too much lego alike, and Ruby, even the process of creating it and not just the language itself is very clay modelling like.

While I do wish there are more collaboration and process, I think that is focusing too much on the process alone. At the end of the day we want ruby improvement to be happening at a faster pace. And right now I still think it is a matter of resources, compared to Python and Java.

Fascinating read, I really enjoyed the parallels with Smalltalk and Self.

Reply on news.ycombinator.com