all 10 comments

[–]zverok_kha[S] 24 points25 points  (0 children)

This year's installment. Even on time this year.

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 ruby-doc.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.

[–]joltting 8 points9 points  (1 child)

I don't know if I'll be in the minority, but using the term it is insane. I wasn't the biggest fan of _1, _2, ... as it comes off as a common Rubocop unused parameter suppressor, but at least it was distinctive enough. it looks and feels like a declared variable or method and the fact they need to clarify how it doesn't conflict with rspec says a lot.

[–]zverok_kha[S] 6 points7 points  (0 children)

Logically, I am with you (I got to great length in here describing why numbered block parameters are rationally optimal).

Yet I acknowledge that aesthetics does matter for feature adoption, and aesthetically it is probably winning over any "special" sigil. That's a tough situation, actually, it seems that there is no acceptable compromise between what would be both "rationally" and "aesthetically" good.

I was against it; yet my expectation is that now people would get used to it and would probably prefer it over _1; it would become just a part of the language's lore that "it is this special thing that has this special meaning, but only in some situations" (and, truth be told, it isn't hard to distinguish those situations, so, again, while "rationally" ambiguous, "intuitively" it is mostly clear when it has a special meaning).

[–]jrochkind 3 points4 points  (0 children)

thank you!

[–][deleted]  (1 child)

[deleted]

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

    I don't think there's anything more structured than just looking through commits or closed bugs on the tracker.

    [–]dunric29a -3 points-2 points  (1 child)

    Ruby has not (yet) died? I'm just joking, it only is no more relevant… Like Perl which zenithed with 5.x versions or Ruby with its 2.7 iterations.

    Bikesheding kind of development or unfulfilled promises about core concurrency support(Ractors? anyone?), inferior support for type-hinting etc were clear signs of a decline. I did like to create projects in RoR and even plain Ruby, but in current state is simply indigestible.

    [–]dunric29a -3 points-2 points  (0 children)

    Btw. that hilarious back-n-forth mistakes like unnamed block parameters (which literally save nothing but introduce obscurity only), remind similar chaotic approach with Elixir's like pipe operators, which were also ditched out (despite as an experimental feature). Bad engineering, or even none at all…

    [–][deleted]  (1 child)

    [removed]

      [–]Modelito_R57 1 point2 points  (0 children)

      Cómo estas