Hacker News Reader

Comment by derefr | Hacker News Reader

First pattern matching, and now type-hinting and message-passing actors. Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby?

Not to say I’m not grateful! I’m mostly an Elixir dev, but since the Erlang Runtime System sucks at POSIX (bad at pipelines, bad at exit codes, bad at trapping signals, etc.) I personally switch to Ruby when I need a glue language. It’s nice to see the available paradigms in these (actually very different) languages “coming together”, in a way where I can spend less time mentally mode-switching, and just keep thinking in (functional, pattern-matching, concurrent-actor) terms.

Just think how pleasant it will be to write a “show a spinner as you poll a resource in the background” code in Ruby, now that we’ve got actors. :)

View on HN

> Is the goal of Ruby right now to claw back all the people who moved to Elixir by adding Erlang features to Ruby?

One has to wonder.

I don't think I'll go back. I found that I was coding almost exclusively in a functional style, in Ruby (because it was easier code to test and it seemed to produce less bugs/fewer mental-model problems), then realized I was still missing out on the guarantees that Elixir gives you, then I thought, what's the point in staying when I could get guarantees that eliminated entire classes of bugs for free?

Having done Elixir for a few years now, I RARELY have to go into "debugging mode", I've never even had to fire up Elixir's version of "pry", and my tests have caught all but a few bugs. All my logic lives in sensible locations. It's pretty nice! At least for web dev.

I see a lot of Elixir lovers but I just can't wrap my head around a lot of the idioms. Is it bad I much prefer loops to reduce? Also modelling complex domains things just flow better in my brain with OOP, whenever I go to draw things I put them in boxes with as little state as I can.

I would love love love to see two people approach the same exact problem with OOP and FP and see the rewards of both.

However I really love pattern matching from Elixir real game changer of a idea, excited to see it come to Java and Ruby soon and the lightweight threading models come to both of those languages also.

I always preferred Brian Gotez's argument that you should be functional within objects. https://www.youtube.com/watch?v=8GWZE2Y2O9E

Even in Ruby, no one uses loops, they use Enumerable. Eliminates off-by-1 errors!

Reduce (inject, etc.) are tricky to understand at first but once you do, you realize the power in it. Granted, it’s harder to understand than loops, but loops with iteration and mutability get you into a lot more trouble.

It sounds like you’re simply not over the learning curve yet.

> Even in Ruby, no one uses loops, they use Enumerable.

Enumerable#each is quite deeply equivalent to a for…in loop.

But no one uses for loops in Ruby because not only are they basically an alternate syntax for Enumerable#each, but they became non-idiomatic because in earlier versions (through at least 1.8.x, IIRC; I think this may have been resolved by the switch to YARV in 1.9) “for” had some implementation inefficiencies which made it notably slower than #each.

> Is it bad I much prefer loops to reduce?

No. That's the reason that we have multiple different tools at our disposal. :)

My rule of thumb has always been to use the tool that I, myself, find more effective—not what others say would be the most effective in an ideal world where I know everything about every programming language in existence. That means that I've written a handful of shell-scripts in PHP, some CLI-tools in Ruby (that would probably run a lot faster in Go), and a couple of "API"s in Bash.

> Is it bad I much prefer loops to reduce?

It…depends what for.

There are things loops are more clear representations of intent for, there are things map is a more clear representation of intent for, and there are things reduce is a more clear representation of intent for.

Reduce is just a loop that's already been written for you!

FWIW I'm balls-deep into Elixir, pardon my language, and I almost never write recursive functions.

Do you have any tips for people coming from Ruby land on how to model things with a more functional approach? For example I've been watching some of 'On Writing Software Well' series https://www.youtube.com/watch?v=D7zUOtlpUPw by DHH and found it really useful for OOP land.

Also any idea on how StimulusReflex / new Hotwire compares to Phoenix LiveView if you have had a chance to look at it yet?

I had the same epiphany; the hard-won "best practices" I had discovered in Ruby/Rails ended up looking a lot like second-rate functional programming.

Having spent the last year with Elixir in production, I don't plan to go back. Things like Ecto, ExUnit, error handling using "with", Phoenix Presence, domain modeling using Phoenix Contexts, Absinthe for GraphQL have made programming a joy.

I love that phrasing: “hard-won best-practices in Ruby turn out to be merely second-rate functional programming”

That, plus Elixir was literally 5 to 10x faster at a sampling of tasks I threw at both (but this was a few years ago)

Much as I'd like to switch to Elixir I see hardly any contracts calling for it right now. i.e. for every 300 or so Ruby gigs there'll be about 2 or 3 Elixir ones.

Ruby will never be Elixir or Erlang but if you can improve an existing thing why wouldn't you? Adding useful features from Elixir/Erlang to Ruby seems worthwhile, even if it doesn't get you all the benefits.

There will likely to be much work that won't be rewritten from scratch that would benefit and money to be made doing so.

Reply on news.ycombinator.com