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

71–80 of 133 posts

Re: Ruby 3.0.0 RC1

#71

Post by speedgoose »

latortuga wrote: post #39
speedgoose wrote: post #17

Earlier quoted context omitted.

It's becoming quite common in JavaScript, but usually with a const/let keyword in front so it's easier for the brain to understand that you are reading a destructuring assignment.

I believe you are misunderstanding how this new feature works in Ruby. You've brought up destructuring assignment in javascript which flows right-side values by key to left-side variables. In Ruby, this new syntax is "rightward" assignment, values flowing from left to right: 3 => x # assigns 3 to x [4, 5] => [x, y] # assigns 4 to x, 5 to y

Indeed. It's very different. Thanks for the clarification.

Re: Ruby 3.0.0 RC1

#72

Post by oblio »

Rochus wrote: post #63
oblio wrote: post #61

Earlier quoted context omitted.

15% is a decent speedup.

When implementing a JIT I would hope for a much higher speed up than 15%. In comparison: LuaJIT with the JIT switched on runs about five times faster than the most recent PUC Lua interpreter, see http://software.rochus-keller.ch/are-we-fast-yet_lua_results... . Compared to that 15% is nothing.

True, but I would imagine that a lot more time has been invested in LuaJIT, since this is just the first release of the Ruby JIT. Plus isn't Lua better suited for optimization, from the get-go?

Re: Ruby 3.0.0 RC1

#73

Post by pelasaco »

Lio wrote: post #33
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…

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1] 1. https://github.com/ruby-concurrency/concurrent-ruby

you can still go with jruby and have best of both worlds.

Re: Ruby 3.0.0 RC1

#74

Post by what2build »

ritchiea wrote: post #57
what2build wrote: post #47

Earlier quoted context omitted.

Rails is not vanilla Ruby. And web apps are not the only software that needs to be written. I moved on from Ruby land right as AWS was blowing up, and admitted I have never worked in Rails.

You're correct, Rails is not Ruby. But in my experience 80%+ of the Ruby ecosystem is Rails. But now I'm even more curious what problems you encountered with Ruby because I find it to be an excellent scripting language, especially if performance is not a major concern.

To be fair, it’s probably not Ruby, but the clever linguists I was working with 2008-2012 era.

Everyone brought their preferred syntax and there was much less of a “let’s solve the problem, not be clever” sentiment back then.

That said, Python almost makes such things impossible. Decorator patterns are the only thing I can think of in Python that ever made me really think.

6 to one, half dozen to another. How we start out thinking about problems has an impact on what syntax works for us best later on. I’m in my 40s and started in electronics, designing boards that shipped in Nortel kit.

I started with C and little else, not digging into OOP until hardware work went overseas. Perhaps my brain is over specialized to prefer a particular way of visualizing code I need to write.

Re: Ruby 3.0.0 RC1

#75

Post by bestinterest »

pmarreck wrote: post #59
derefr wrote: post #53

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…

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

Re: Ruby 3.0.0 RC1

#76

Post by crb002 »

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…

Ruby should be one VM per CPU with message passing like I did for the Blue Gene/L port. Threading can't scale between cgroups let alone kernels.

Re: Ruby 3.0.0 RC1

#77

Post by crb002 »

pelasaco wrote: post #73
Lio wrote: post #33

Earlier quoted context omitted.

> my rule is "if you're going to even think about threads, just use Java or go" since concurrency is so nice there. I could see reasons for preferring Java over Ruby but concurrency isn't one of them considering that Concurrent-Ruby running on JRuby gives you access to all of Java's concurrency tooling.[1] 1. https://github.com/ruby-concurrency/concurrent-ruby

you can still go with jruby and have best of both worlds.

Or bake it into a task graph and use the gmake executor.

Re: Ruby 3.0.0 RC1

#78

Post by kuiro5 »

pmarreck wrote: post #59
derefr wrote: post #53

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…

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

Re: Ruby 3.0.0 RC1

#79

Post by Rochus »

oblio wrote: post #72
Rochus wrote: post #63

Earlier quoted context omitted.

When implementing a JIT I would hope for a much higher speed up than 15%. In comparison: LuaJIT with the JIT switched on runs about five times faster than the most recent PUC Lua interpreter, see http://software.rochus-keller.ch/are-we-fast-yet_lua_results... . Compared to that 15% is nothing.

True, but I would imagine that a lot more time has been invested in LuaJIT, since this is just the first release of the Ruby JIT. Plus isn't Lua better suited for optimization, from the get-go?

I have no information on how much time was invested in the implementation of either of the VMs. Lua has many similarities both with Smalltalk and Ruby. It has also a very powerful closure concept, which unfortunately is not yet supported by the tracing JIT.

Re: Ruby 3.0.0 RC1

#80

Post by cutler »

abernard1 wrote: post #31
lloeki wrote: post #26

Earlier quoted context omitted.

I believe you’re confusing Ruby with Rails. While these can eventually come in handy sometimes, they are by and large seldom used, but Rails heavily leverages such patterns for flashy yet ultimately questionable magic. As a long time Rubyist, I believe Rails, for all its innovation, has been warping the view of what Ruby is, and when and how to use its features responsibly.

I concur. The dynamic inheritance part of Ruby is still core even in a non-Rails ecosystem. That does make optimizing performance more difficult. But on a much simpler level, a lot of Pythonic data code is just functions + values, without them being complected in an object. That makes a lot of stuff like wrapping numerical libraries in C very easy in Python. I think you'd still have a bit of a culture shock writing p…

I don't think that's been true for quite a while. Even a function like len('abc') is implemented as 'abc'.__len()__ under the hood so no different from Ruby really.
Post reply on HN