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

51–60 of 133 posts

Re: Ruby 3.0.0 RC1

#51

Post by vinceguidry »

lukeschlather wrote: post #45
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.

Well, the problem is that Rails (and ActiveSupport) is borderline idiomatic Ruby. I imagine the vast majority of Ruby codebases use them. And honestly I don't even know how vanilla Ruby stacks up to Python, it's almost an inconceivable idea (though I left Ruby behind some years ago.)

Rails is dominating Ruby less and less every year. There are plenty of alternative web frameworks to use, and Rails is a really heavy-weight thing to include if you're not building a website. I'll pull in an ActiveSupport module every once in awhile but so few of the things I write are websites that need Rails.

Re: Ruby 3.0.0 RC1

#52

Post by vinceguidry »

desireco42 wrote: post #49
Rochus wrote: post #25

In case someone is interested in the (JIT) performance of 3.0 RC 1 compared to version 2.7.2, here are some measurement results based on the are-we-fast-yet benchmark suite: http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... and http://software.rochus-keller.ch/are-we-fast-yet_crystal_rub... . I see only a slight speedup of the 3.0 (JIT) compared to 2.7 (less than 15%). See here for more information abou…

What I got from this is how fast Crystal is :).

If you want to split the difference there's compiled mruby.

http://mruby.org/docs/articles/executing-ruby-code-with-mrub...

Re: Ruby 3.0.0 RC1

#53

Post by derefr »

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

Re: Ruby 3.0.0 RC1

#54

Post by riffraff »

contingencies wrote: post #41
sudhirj wrote: post #27

Earlier quoted context omitted.

Preventing stagnation and maintaining backwards compatibility aren’t the same thing. Go has a very strong backwards compatibility guarantee, and since they made the guarantee the entire compiler has been rewritten and there have been plenty of additions to stdlib.

Yes, it's possible just not usual to replace everything without effecting interfaces.

but gems in stdlib work fine even for that: if the next version of the gem breaks compatibility the next version of ruby is free to import it, and you can keep using the old interface with new ruby by locking the dependency to the old gem version.

Re: Ruby 3.0.0 RC1

#55

Post by AcerbicZero »

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've found Ruby to be far more "learnable", in that once I learn how something works in Ruby, it will work that way in most every situation going forward, whereas Python has a lot of caveats to its functionality. This might just be due to my use cases, but the Ruby documentation is 100x more useful for getting me from point A to point B than anything I've seen from Python's docs.

I still use Python daily, since its so ubiquitous, I just find myself having a difficult time using it for anything remotely complicated without a lot of extra research.

Re: Ruby 3.0.0 RC1

#56

Post by chrisseaton »

lloeki wrote: post #26
abernard1 wrote: post #12

Earlier quoted context omitted.

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

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.

> While these can eventually come in handy sometimes, they are by and large seldom used

I don't think they are seldom used in practice - I think large parts of the Ruby ecosystem use them pervasively, even if you disregard Rails.

But even if we don't agree on that - it's missing the point. The point is you pay for much of Ruby's metaprogramming, even if you aren't using it. So not using it doesn't help you.

A concrete example is that you pay for `Kernel#binding` every single time you finish using a local variable but Ruby retains it for the binding, even if you never ever call `Kernel#binding`. Even JITs cannot remove this cost.

Re: Ruby 3.0.0 RC1

#57

Post by ritchiea »

what2build wrote: post #47
ritchiea wrote: post #46

Earlier quoted context omitted.

Interesting, I'd say the opposite. In a Rails app that was written consistently with the styles and APIs documented in the Rails docs I have never been more productive. In other micro-framework type environments, regardless of the language, Ruby/Sinatra, Python/Flask, Javascript/Express. Most codebases I've encountered are a mess of inconsistencies introduced by various developers over the years. With a lot of the me…

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.

Re: Ruby 3.0.0 RC1

#58

Post by raverbashing »

jeltz wrote: post #44
raverbashing wrote: post #34

Earlier quoted context omitted.

Ruby might have some qualities but overall it's less polished than python Just as a small example, Edit: .methods, "the Ruby equivalent of 'dir'" doesn't present the results as a sorted list Also the optionality of parentheses sounds like a good idea but it actually makes things more confusing and less parseable

I would argue that is a good thing since it allows for performant access when you do not care about order. If you do not care about order you do usually not even have to allocate an array which means lower memory use. And how hard is it to write. Dir[path].sort Ruby lacks polish in certain areas but this is not one. A d I would argue Python can be pretty tough in places too.

Not that Dir, I mean as in .methods/.instance_methods (or dir(instance) in python )

I fixed it in my original comment

Re: Ruby 3.0.0 RC1

#59

Post by pmarreck »

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

Re: Ruby 3.0.0 RC1

#60

Post by mumblemumble »

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…

I don't think that would really be too bad, TBH. Don't forget that the first project to popularize distributed map-reduce, Hadoop, was a Java project.

All you really have to do to translate map and reduce into an OO paradigm is have the map and reduce operations take objects that implement specific interfaces instead of functions that have a certain signature.

Post reply on HN