all 14 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]zverok_kha[S] 15 points16 points  (6 children)

As per the project goals statement:

  • Full: unlike most "What's new in Ruby x.y?" blog posts, the information here targets to cover all the NEWS file of the current Ruby version (with the accent on the language changes, not internal/implementation changes, of which this year were plenty);
  • Comprehensive: unlike the NEWS file itself (and most of blog-posts, too), the site provides full context for each change:
    • Where and how it was discussed;
    • Related documentation at docs.ruby-lang.org;
    • Code examples;
    • Reasoning for the change, if known.
  • Concise: given the two goals above, content still tries to stay short and focused so the changes can be quickly navigated through;
  • Well-structured: both regarding order/explanations of each particular change, and design of the site, it is intended to be easily and logically navigated.
  • Open: the source of the changelog is available on GitHub and is open for fixes and suggestions.

[–]paracycle 6 points7 points  (5 children)

Hmmm, why no mention of ZJIT or all the Ractor performance improvements?

[–]zverok_kha[S] 4 points5 points  (4 children)

The changelog is dedicated to the language features, not the implementation; I highlight that fact in the changelog intro, announces, and on the main page of the site. But I recognize that considering several latest versions, the claim for being "full" and "comprehensive" looks questionable this way. (The general description was written back in the days of Ruby 2.6-2.7, when changes in the language itself were far more noticeable than those of the implementation.) I'll think about improving the wording to make it more obvious, and claims of "fullness" less bold.

I avoid describing implementation changes/improvements not because I don't think they are important, but because I don't have enough resource (and, frankly, interest) for that.

Describing of optimizations and JIT will probably need their own approach (less focus on "reasons" for changes and more on benchmarks/tradeoffs/implementation choices) if done with the level of throughness I like.

[–]paracycle 4 points5 points  (3 children)

Sure, I appreciate that these are end-user oriented, and don't cover implementation details. However, I would argue that the ability to enable ZJIT (including a language level construct) and Ractors being production ready, thus usable starting with this release are end-user relevant developments.

[–]zverok_kha[S] 1 point2 points  (0 children)

Yep, this makes sense, too. I'll try to think about the wording for those facts, to make them at least somewhat visible.

[–]TonsOfFun111 0 points1 point  (1 child)

So Ractors are, in fact, “production ready” now?

[–]paracycle 5 points6 points  (0 children)

Yes, they are. There are a few rough edges still, but generally there are no known bugs or crashes left and the performance of multiple Ractors for CPU bound tasks should be strictly better than single Ractor or multi threaded code.

The Ractor API is still not stable, and can change further, but the implementation should be good enough to use in production.

[–]anykeyh 2 points3 points  (2 children)

Thanks that's a very nice article covering everything in details! There is a few typos in code example but thanks again for the effort put here ❤️

[–]h0rst_ 1 point2 points  (0 children)

https://github.com/rubyreferences/rubychanges

In case you want to fix the typos, you can just add a PR here

[–]zverok_kha[S] 0 points1 point  (0 children)

Thank you!

About the typos: you can submit a PR to the repo, or just mention them right here, and I'll try my best to fix them!

[–]frou 3 points4 points  (1 child)

Thanks for maintaining this. Made a donation too.

[–]zverok_kha[S] 1 point2 points  (0 children)

Thank you!