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

41–50 of 133 posts

Re: Ruby 3.0.0 RC1

#41

Post by contingencies »

sudhirj wrote: post #27
contingencies wrote: post #15

Earlier quoted context omitted.

prevent stagnation Or irritate a long term user base? PHP has been very successful long term, largely I would argue because of maintaining almost complete backwards compatibility.

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.

Re: Ruby 3.0.0 RC1

#42

Post by hak8or »

burlesona wrote: post #9
Wonnk13 wrote: post #5

I've been writing Python for close to a decade off and on. I'm just now dipping my toes into Ruby and have found it quite fun- excited to dig deeper into this and Rails :D

Be sure to check out Jeremy Evans on GitHub and his whole suite of tools: Rosa, Sequel, etc. Rails is good, but the ecosystem beyond Rails is better in many cases.

Ah sequel. I did a stint of ruby on Rails work many years back, and remember seeing sequel for the first time. It's documentation web page is honestly probably the best "what is this" and "getting started" page I have ever seen for any library.

I don't know if it's the library itself or the documentation contents or the documentation website theme, but it jives absurdly well for me. I also really like the simplicity+flexibility of the library itself, and have yet to find anything even close to it in the c# or c++ world.

Re: Ruby 3.0.0 RC1

#43

Post by prh8 »

simias wrote: post #35

I tried Ruby over 10 years ago and while I really enjoyed the language itself (vastly more than, say, Python for instance) I was completely put off by the insanely poor performance of the interpreter. I remember trying to get it to run on a rather slow FreeBSD box back then and just loading a simple script with a few dependencies would take literally seconds! Perl and Python were easily an order of magnitude faster.…

Yes

Re: Ruby 3.0.0 RC1

#44

Post by jeltz »

raverbashing wrote: post #34
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 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.

Re: Ruby 3.0.0 RC1

#45

Post by lukeschlather »

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.

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

Re: Ruby 3.0.0 RC1

#46

Post by ritchiea »

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…

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 mess, effectively re-writing the core features of Rails and it's most popular gems.

Rails, if done correctly, is a remarkable tool to allow developers to focus on the business logic and UI of their app and forget about the "filler features" that pretty much every app needs implemented. On the other hand if you write Rails code without reading the docs and re-invent the wheel rather than doing things the Rails way, essentially running an app in the framework without using the framework methods, you can create yourself a monstrous unmaintainable codebase like no other.

Re: Ruby 3.0.0 RC1

#47

Post by what2build »

ritchiea wrote: post #46
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…

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.

Re: Ruby 3.0.0 RC1

#48

Post by abernard1 »

mumblemumble wrote: post #40
abernard1 wrote: post #31

Earlier quoted context omitted.

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'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 writing code that way, so increasing performance by splitting the data onto different machines is simple.

Re: Ruby 3.0.0 RC1

#49

Post by desireco42 »

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

Re: Ruby 3.0.0 RC1

#50

Post by tylersmith »

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 agree 100%. Ruby is my favorite language but for anything that isn't purely a solo project I've moved to harder-to-misuse tools for exactly this reason.
Post reply on HN