A bit of context: Once, I decided to write a single post with a tongue-in-cheek title, which would take all the new syntax additions to Ruby that people find useless/annoying and try to look at their design reasons and consequences.

While writing it, I understood that it should be a series of posts: too much material to fit in one. But at that moment, I still expected each post in the series to be just a small note and be written in a day or two, and that’s why I didn’t start to post it on Lobste.rs (which is probably my favorite no-BS discussion platform): didn’t want to spam people with five links in a week.

Eventually, it turned out that every entry requires a lot of work and produces a reasonably long and discussable post approximately once per week, so from now on, I plan to post the new entries here. The “pattern matching” feature, though, unlike others chosen for the series, requires so much discussion it produced three blog posts. Here are other parts: 2, 3.

And here is the rest of the series (so far):

• That useless Ruby syntax sugar that emerged in new versions: an intro/ToC/plan;
• “Useless syntax sugar”: Numbered block parameters: an entry about anonymous/default block parameters.

Pattern-matching is one of the most consequential additions to the language in 15 years. It’s completely changed how I write things.

In particular, my http handlers are entirely oriented around mapping result objects to http responses using it.

case find_user(params[:id])
in Success(user)
  response.json = serialize(user)
in Failure[:not_found, id]
  response.status = :not_found
  response.json = { message: "user not found: #{id}" }
in Failure(error)
  logger.warn "unexpected error", error: error.inspect
  response.status = :internal_server_error
end

I love this. I wasn’t aware of this series, I’ll have to check out and share (this +) the rest with my team.

Also, was your example of case ... in Point purposefully constructed as to relate to the phrase? I got a kick out of it regardless.

From my time trying to implement them in TruffleRuby I do remember having the patterns bucketed into Array Patterns, Hash Patterns and Find Patterns [*a, ..., *b]. They are such an incredible abstraction, hiding away so many loops an nested conditionals, and I like how it’s practically presented in this series. I personally think all the work behind pattern matching was certainly worth the effort (I don’t even come from FP), and it does a lot to keep Ruby as my favourite mainstream language to date.

This is great. I have been using pattern matching but I didn’t really feel like I understood it.

I dunno why but I was confused by the p statements. Maybe it’s because I usually omit the parentheses from them, or because I usually use puts for output, but I legit sat there scratching my head long enough to be embarrassed. @zverok Maybe if you formatted it more like REPL output? Like

thing = 1
stuff = 2
{ thing:, stuff: }
=> { thing: 1, stuff: 2 }

[Comment removed by author]