What's new in Ruby 3.1?

[BiteCode_dev]

I kinda dig the new mapping syntax:

    { a:, b: } #=> { a: 1, b: 2 }

JS does it { a, b } and I find it very convenient, because if you code well, you usually have related things with the same name and repeating the name twice is just boilerplate.

Because of the set syntax in Python, the JS syntax can't work, but the ruby one would be nice.

Since Python keys can be anything, but usually are strings (and hence are quoted), I would probably invert the ":" though:

   { :a, :b }

[nicoburns]

I really like the ruby syntax. JavaScript now has the problem that it can't make code blocks expressions because it's ambiguous with object literal shorthand.

[bobbylarrybobby]

It's not just because of the set syntax; it's also because Python dicts don't treat their keys as symbols, but rather evaluate them as expressions, whereas JS evaluates keys as symbols by default and requires `{[key]: val}` to evaluate them. So in Python you'd have to do something funky where `{a: a}` is `{value_of_a: value_of_a}`, but, say, `{a:}` is `{"a": value_of_a}`.

[dec0dedab0de]

So its a shortcut that if you pass a variable as a key with no value it automatically creates a key with the same name as the variable and assigns the value?

That is kind of neat, but I tend to think of a bunch of {'a':a} as a bit of a code smell. Like maybe I should have used the hash/object/dict to begin with

[lysecret]

there is no way to achieve this in Python right? I miss this from js.

[m12k]

Does anyone know if there's a tool out there similar to https://railsbump.org/ that would allow me to quickly check how many of the gems I depend on are compatible with ruby 3? I know ruby 3.0.x has been the recommended ruby version since rails 6.1, but I'm not sure if that means that a gem that is 6.1-compatible is necessarily also ruby 3 compatible (since rails 6.1 still supports ruby versions as old as 2.5.0)

[tibbon]

Rust has spoiled me. I truly wish this was just built into bundler. I should be able to just update the version, run bundle install, and know what is supported.

Many dependencies have minimum, but not maximum versions specified. Most bugs have to be found at runtime (or via testing, which causes a runtime).

Again, Rust has spoiled me because if cargo build compiles, then it’s almost certainly ok.

[kayodelycaon]

Picking up Ruby 3.0/3.1 after using 2.x for years is head spinning. Lots of new syntax to learn.

A lot of the syntax feels like hacks because Ruby syntax is rather permissive and finding pattens that don’t collide increasingly difficult.

Definitely has me a little grumbly, but I’ll get used to it eventually. Already loving _1.

[gls2ro]

For me I think there are only two major things happening between 2.5 let's say and 3.0:

- Keyword arguments - where there is no way around, you have to change them, upgrade gems...

- Everything else is optional. Code that is written in 2.5 mostly runs on 3.0

Also, I recently updated a Rails app from 2.7 to 3.0 and no code change is required.

I am asking as I am trying to use new syntax in my daily code so maybe I am missing something.

What is the new syntax that you discovered in 3.0 that made your head spin?

[cassiogo]

Im also not in love with the shorthand hash syntax, but besides `_1` I cant remember at the moment what new syntax 3.1 have that 2.0 dont. Pattern matching maybe?

But now that I think about it, yeah, even looking only at pattern matching there is a lot of new syntax going on.

[viraptor]

I love how the idea of highlighting a specific part of the expression that can't be resolved jumped from one language to another within the last year or so and now the most common languages all support it.

(I remember node and python getting it but now can't find that in the release notes - I didn't imagine it, right?)

[bpeebles]

Python, I believe, is getting this feature in 3.11, which is due out in October. But the first 3.11 alpha release got some news talking about it:

https://docs.python.org/3.11/whatsnew/3.11.html

[jhgb]

> the idea of highlighting a specific part of the expression that can't be resolved jumped from one language to another within the last year

CMUCL/SBCL must have supported this for decades.

[madeofpalk]

I don't think Node does this. Maybe some test runners will do similar things to show expected vs actual in assertions?

Or maybe I'm just so numb to it and I don't recall properly.

[asicsp]

As mentioned in further reading section, see also:

Comprehensive Ruby 3.1 changelog: https://rubyreferences.github.io/rubychanges/3.1.html

[neoglow]

> IRB now supports autocomplete, and even shows the documentation when you tab through the options.

Oh this is pretty useful. How many times have I not wanted to learn about how to use a function. Showing the documentation when tabbing through the options can save me a lot of time browsing through the ruby docs. Looking forward to using this while working.

Good to see Ruby is still moving forward :)

[buzzdenver]

What is a compelling use case for omitting values in hashes or method calls? I would think that it just increases cognitive load for the code maintainer, and makes the parser more complex.

[vvillena]

Rust has had this bit of syntax sugar for a while now, it is used for structs. I think it's nice syntax, because it's located in a place where there's no doubt about the meaning. Both Rust structs and Ruby hashes are defined in-language as key-value sets, so whenever there's just one element instead of a pair, it's clear what the meaning is.

[gls2ro]

With keyword arguments there are a lot of cases when we do things like

    def call(batch_id:, language: )
    end

    batch_id = find_batch_id_from_conditions(conditions)
    language = load_language_settings(user.id)

    call(batch_id: batch_id, language: language)

For me, I would gladly replace the last method with call(batch_id:, language:)

[dyeje]

It removes the boilerplate of repeating the variable name when it's the same as the hash key. It's an extremely popular syntax in the JavaScript world bleeding over into Ruby. Personally, I enjoy it because it feels more fluid.

[fourseventy]

I don't like it either. I much prefer simple syntax with limited exceptions and variation. I use ruby every day but I prefer a syntax closer to go.

[hashhar]

I have noticed that Ruby tends to move towards more magic which is true in this case.

I don't see any benefits at all from this.

[phendrenad2]

What's new in Ruby 3.1? Needless, opaque syntax "features" that will just confuse new programmers even more.

[cpursley]

Other than existing code bases, what's the advantage of using Ruby for new projects these days when better tools exist? For example, Elixir - ergonomics of Ruby but cleaner functional approach, distributed and much faster for typical web apps.

[silentprog]

Elixir certainly has its use case, but so does Ruby. Things like the huge amount of available gems and a big community, especially combined with a proven framework like Rails really makes it easy to build applications.

Elixir is well suited for a lot of things Ruby is but also has some shortcomings. For instance, the albeit growing community and available libraries is just not on the same level as Ruby. Furthermore the amount of available engineers knowing elixir can be a problem when hiring (ofcourse these can be trained internally) but in general hiring will be a tad bit harder.

Whilst I agree with you on the technical side (language is cleaner and obviously more performant) I do not agree on the statement dat Elixir is a better tool, as with a lot of things in software it depends.

[Nuzzerino]

I've had professional gigs spanning Ruby, Elixir, JS, C#, F#, and Python. I've found that Ruby is the most enjoyable to work with and has the easiest learning curve. It's a language that doesn't feel pretentious or dysfunctional, and most importantly of all, I can get shit done with it.

[herbst]

> better

Better is a very personal thing :) I like the ecosystem of ruby, always did and never had a reason to change.