Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 3.0.0 RC1

ruby-lang.org

Post reply on HN
Print view View original

81–90 of 133 posts

Re: Ruby 3.0.0 RC1

#81

Post by JohnBooty »

what2build wrote: post #30

Anecdotally, since I got away from Ruby, working on software became way more productive and tolerable. Maybe it was something with the corner of the Ruby world I fell into, but the syntax sugar options and “cleverness” that enabled was maddening to deal with, and permeated that crowd. Code bases with mixed styles are a thing in any language, but the Ruby-ists around me found a way to make one project look like half a…

I've done Rails full time for around six years on two different teams. A big chunk of that time involved working on a codebase whose size rivaled some of the largest in the world.

Rubocop (with some tweaked rules; it's IMO too restrictive out of the box) was a big lifesaver in terms of steering both teams toward a common, readable coding style and mostly eliminating debates over style at PR review time.

Re: Ruby 3.0.0 RC1

#82

Post by bestinterest »

sandGorgon wrote: post #23

I look at Ruby and I think of Dart. Not from language semantics perspective..but specialisation in a very narrow usecase and around DX. But really unbeatable in that usecase. all racehorses are one-trick really.

I feel sort of similar for most languages,

low level? Rust/C/C++

'corporate' work? Java/C#

Android? Kotlin

iOS? Swift

ML / Data statistics? Python

Re: Ruby 3.0.0 RC1

#83

Post by ksec »

burlesona wrote: post #6

RC1 is a little bit late for a Christmas Day release (which is a long-running Ruby tradition). I wonder if they’ll make it, and if so, if 3.0.0 will be less stable than usual.

Consider Shopify and Github both have been testing on 3.0 and Rails Master.

I say it is pretty good.

Re: Ruby 3.0.0 RC1

#84

Post by pmarreck »

bestinterest wrote: post #75
pmarreck wrote: post #59

Earlier quoted context omitted.

> 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, th…

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…

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.

Re: Ruby 3.0.0 RC1

#85

Post by rat87 »

abernard1 wrote: post #12
atomicnumber3 wrote: post #10

I'm glad to see they're picking up native type-hinting. I don't like many of the existing bolt-on type systems for Ruby and the whole thing feels so much more kosher when it's official. The concurrency stuff is cool but I can't really comment on it, my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I really wish ruby had won over python as the "general p…

> I wish all the "big data" tooling was written in Ruby. On a practical note, Ruby's heavy use of reflection, inheritance and method_missing style dispatch currently makes performance for big data tasks less than ideal. Python is less expressive but its "one true way" makes things like vectorization and type specialization easier for data tasks. Sometimes you really just need a better Fortran.

Python isn't less expressive for the most part except for lack of blocks(although can be emulated with decorators and def _), and ruby's strategic lack of parentheses and not being to add/change methods in c based classes.

Python has just as much access to reflection, it has more powerful and arguably easier to shoot yourself in the foot inheritance (python has multiple inheritance while ruby only has mixins). Python also has method_missing in __getattr__. Arguably python tends to use these less often then ruby but I've definitely used both reflection and __getattr__. I've also once had to debug a really hairy multiple inheritance issue(in a test framework that used base classes to test different hardware features where you might want to have both you'd need to use multiple inheritance and then make sure they were initialized in the right order, multiple inheritance can get really annoying)

Re: Ruby 3.0.0 RC1

#86

Post by pmarreck »

kuiro5 wrote: post #78
pmarreck wrote: post #59

Earlier quoted context omitted.

> 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, th…

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)

Re: Ruby 3.0.0 RC1

#87

Post by lillesvin »

bestinterest wrote: post #75
pmarreck wrote: post #59

Earlier quoted context omitted.

> 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, th…

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…

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

Re: Ruby 3.0.0 RC1

#88

Post by dragonwriter »

bestinterest wrote: post #75
pmarreck wrote: post #59

Earlier quoted context omitted.

> 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, th…

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…

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

Re: Ruby 3.0.0 RC1

#89

Post by dragonwriter »

pmarreck wrote: post #84
bestinterest wrote: post #75

Earlier quoted context omitted.

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…

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.

Re: Ruby 3.0.0 RC1

#90

Post by cutler »

abernard1 wrote: post #48
mumblemumble wrote: post #40

Earlier quoted context omitted.

I'm inclined to agree. One of Python's strengths in this space is that it's a procedural language with just enough in the way of object-oriented facilities. That makes it possible to write reasonably object-oriented libraries with easy-to-learn interfaces, while still sticking to procedural idioms for the actual data hacking. Which, in turn, means makes it a comfortable environment and interfacing mechanism for both…

Totally. Another thing is that outside of scientific data applications, ordinary data processing apps at scale have been map-reduce for a long time. That's an inherently functional paradigm that's closer to Python. Having parallelized heavily OO Ruby code across machines by unrolling it into functions that could be sent data payloads... that's not a fun thing to sell in an OO culture. In Python you're kind of already…

Functional paradigm closer to Python? I think you mean procedural as Guido has openly professed his distaste for all things functional to which Python's crippled lambdas bear witness. Ruby, on the other hand, with its procs, blocks and lambdas, supports an elegant functional style even if it is implemented in OO.
Post reply on HN