Live data from Hacker News

Ruby 3.0 Preview 1

ruby-lang.org

201–207 of 207 posts

Re: Ruby 3.0 Preview 1

#201

Didn’t see it linked in the preview announcement, here’s the RBS syntax guide: https://github.com/ruby/rbs/blob/master/docs/syntax.md Glanced at it from my phone but it looks good! I’m looking forward to seeing it in RubyMine. Still sad that we can’t write these in .rb files but I wonder if the plan is to go the other way, eventually permit typed code in .rbs? Does anyone know what the story will be with third-party…

It seems like the intent is for RBS to be auto generated from other tooling. Sorbet for example lets you write inline type definitions and is planned to fully integrate with RBS. The other good thing about RBS being in separate files is it can be integrated into a library without breaking compatibility with older Ruby versions.

I wish they'd allow both external RBS files and inline markup.

Re: Ruby 3.0 Preview 1

#202

Earlier quoted context omitted.

“size” is fine. The person you are responding to is trying to say that complaining about multiple options is a bit strange as you can just use one option. Why is it an issue that other options exist? Who cares. There are synonyms for English words as well, is that an issue as well?

They are not synonyms, they mean slightly different things. And that is the problem. Because for small datasets the difference doesn’t matter this results in beginner programmers choosing randomly, which 2/3 of time is the wrong choice.

So if 'length' was the only option and I'd have to do ActiveRecord::Base.connection.execute('SELECT count(*) FROM users').values.first or something it would all be fine?

Re: Ruby 3.0 Preview 1

#203
post #66

This is all great stuff. I’m rather meh on RBS, mainly because separating types from code is less than ideal but I like the potential here. But the right hand assignment operator. What on earth. Nobody asked for that and nobody wants it. Why.

Ruby already had a sort of limited form of rightward assignment, in exception rescue: begin #... do something rescue StandardError => ex #... handle exception end The ex here can be any assignment expression, it's not just a lexical variable. So you could already do this: class Guru def meditate=(exception) puts "caught #{exception.inspect}" end end # later ... rescue OutOfCheeseError => Guru.new.meditate i.e. creati…

Oh the error handler example is kinda cool, especially paired with inline rescues

    def my_method
        .. code ..
    rescue FileNotFoundError => FileNotFoundHandler
    rescue StandardError => StandardErrorHandler
    end
But yea, as is so often the case with ruby, you can really shoot yourself if you try hard enough :P

Re: Ruby 3.0 Preview 1

#204
post #124

>Rightward assignment statement is added. >fib(10) => x This is exactly the kind of stuff I hated when I had to work with ruby in my last gig and why I will never accept a job using it again - soo many pointless and inconsistent ways to do the same thing ... they have method aliases for collection operations like map/filter in standard library ! .NET went with non-standard SQL-like names (select/where) and I'm not a…

The thing that most annoyed me about Rails (not Ruby) was that users.size users.length users.count are all valid, all useful, all have different meanings, are all present in plain Ruby but with different meanings, and contain absolutely no information about what they do. For reference, .length loads everything and gets the length of the collection, .count runs a SQL COUNT query, and .size uses length if the query has…

I learned Ruby by itself and only worked on Rails code later... so I've had a lot fewer core Ruby complaints then most.

But Rails has definitely become a PR problem for the language in terms of how many complaints like this it leads to.

Re: Ruby 3.0 Preview 1

#205
post #163

Earlier quoted context omitted.

In a sense Ruby is sort of a cleaned up Perl but maybe not cleaned up enough. I fell totally in love with it almost 20 years ago but these days I think we have better languages to choose from even if their ecosystems aren't always as rich.

You mean like Dart and Go? For expressivity I'll stick with dirty old Ruby, thanks.

Ruby is expressive and makes for great short demos but becomes a nightmare to maintain in larger codebases with dynamic typing & implicit imports.

Re: Ruby 3.0 Preview 1

#206

Earlier quoted context omitted.

>.NET went with non-standard SQL-like names (select/where) […] Which names do you believe are standard?

Arguably, select/where are less familiar than map/filter to many. I'm not saying that either is a standard, but I can imagine the confusion if you come from say, JS background.

To be fair, map/filter wasn't so popular like now when C# 3.0 (released in 2008) was designed.

Re: Ruby 3.0 Preview 1

#207

Earlier quoted context omitted.

They are not synonyms, they mean slightly different things. And that is the problem. Because for small datasets the difference doesn’t matter this results in beginner programmers choosing randomly, which 2/3 of time is the wrong choice.

So if 'length' was the only option and I'd have to do ActiveRecord::Base.connection.execute('SELECT count(*) FROM users').values.first or something it would all be fine?

Other ORMs separate building the query from executing the query, which is less ergonomic but more explicit. Drawing on Rust, https://diesel.rs/ shows how this approach would work:

    users.select(count_star()).first(&connection)
which is really just a cleaned-up version of your suggestion.

Of course, you could imagine an ActiveRecord-like API to make this nicer:

    User.first{|t| t.count}
    User.first{|t| t.count}.execute!
    User.execute{|t| t.count}.values.first
    # ...etc.
but the underlying problem is that building the query and executing the query are two discrete steps, Rails streamlines them instead of making the separation obvious, and when a system hides complexity it becomes harder to know what it's really doing.
Post reply on HN