6 ms·

Ruby 3.1.0 Preview 1

220 points by riffraff 5y ago

ericb 5y ago
Those error log messages will save me time--super excited about that!
kule 5y ago
Was just playing around locally and found one of the undescribed Irb improvements is a drop-down with autocompletion suggestions nice!
- duffyjp 5y ago
  I haven't had a chance to try yet, but I'm hoping some of the irb regressions that began around 2.7 are fixed. Try pasting an array or hash with 1000 or so elements. In 2.6.x it's instantaneous, in 2.7.x it can take minutes--
WalterGR 5y ago
Swapping out a JIT must be an unimaginably complex operation.
- byroot 5y ago
  It's not swapped, both are available for now.
- aardvark179 5y ago
  Not really. Separate out your JIT into well defined components (compiling a method, installing the compiled version, invalidating the compiled version, deoptimising, etc.) and make sure your JITs use those common interfaces. The JVM manages to support multiple JITs (including Graal which is written in Java) and multiple GCs through this sort of approach.
evolve2k 5y ago
Enhanced error log messages are always welcome on the ground :) Reminded me of the work done in elm to explicitly improve their error reporting by deeply considering the user experience [1] Repo for the newly included error_highlight gem is interesting [2], anyone have more background on this ? 1. Elm “the perfect big report” https://elm-lang.org/news/the-perfect-bug-report https://elm-lang.org/news/the-perfect-bug-report 2. Error_highlight gem repo: https://github.com/ruby/error_highlight https://github.com/ruby/error_highlight
- citizenpaul 5y ago
  Unrelated to this but i guess the comment reply time expired to your question before I could answer about the dead physicist. No not without doxing myself. I did some asking for you(and me i suppose) though and most likely what he was working on was something to do with decoherence of entangled qbits for quantum computing.
picardo 5y ago
Good to see IDE support for TypeProf type hints[1]. I've been doing a lot of work in statically typed languages lately, and spoiled by how good IDE integration is with the compiler. Ruby has been moving towards static types for a while, but the lack of IDE support has always been the dealbreaker for me to go back to Ruby. The ecosystem needs more tooling like this. [1] https://github.com/ruby/typeprof/blob/master/doc/ide.md https://github.com/ruby/typeprof/blob/master/doc/ide.md
rememberlenny 5y ago
Can anyone share their experiences using YJIT or RBS in Rails? I’m curious how the impact affects development, deployment, etc.
- byroot 5y ago
  > I’m curious how the impact affects development, deployment, etc. YJIT is pretty much transparent in production, if not it's likely a bug. When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase. But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy. The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps. As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default. [0] https://github.com/Shopify/yjit/issues/87 https://github.com/Shopify/yjit/issues/87
  - joelbluminator 5y ago
    Is it 256 mb for the entire app server or is it multiplied by each Unicorn/Puma process?
    - byroot 5y ago
      Each process, a small part of it might make it into CoW during boot, but that won't make a big difference. If you don't have the free RAM for it and you app is small enough, you can try lower values. Also note that currently YJIT fully initialize that memory to make it easier to debug, so it's not even virtual. That's another thing that is on the roadmap to be improved soon, and ultimately you'll only pay for the part that YJIT really use even if 250MB is allocated. But overall all JITs trade increased memory usage for faster execution, you have to store that generated code and metadata somewhere.
sandstrom 5y ago
I'd like to see Ruby deprecate some of the rarely used standard library items. For example, does Rinda and GDBM need to be in the standard lib? Maybe they're better suited as stand-alone gems? Similarly, I think it should stop bundling some gems. I see they are moving some gems from 'default' to 'bundled', which I guess is some sort of deprecation or demotion -- that's great! ** I'd also like to see them move development onto Github, that should make it easier for more people to participate.
- toomanybeersies 5y ago
  That's been slowly happening [1]. For instance, with Ruby 3.0, net-telnet and xmlrpc were removed from the stdlib and now have to be installed as standalone gems. [1] https://stdgems.org/removed/ https://stdgems.org/removed/
- ksec 5y ago
  >I'd also like to see them move development onto Github, that should make it easier for more people to participate. This has been discussed a few times in the past 5 years. But some member refused to use Github due to it not being open source. Not sure if that is still the case but you could certainly try and ask again.
  - nixpulvis 5y ago
    GitHub is becoming a bloated mess however... if it aint broke don't fix it.
- _odey 5y ago
  Looks like dbm/gdbm were removed from the ruby repo, just not documented in the release notes: https://github.com/ruby/ruby/pull/4525 https://github.com/ruby/ruby/pull/4525 https://github.com/ruby/ruby/pull/4526 https://github.com/ruby/ruby/pull/4526 https://github.com/ruby/ruby/pull/4619 https://github.com/ruby/ruby/pull/4619
- Mikeb85 5y ago
  > I'd also like to see them move development onto Github, that should make it easier for more people to participate. From: https://www.ruby-lang.org/en/community/ruby-core/#following-ruby https://www.ruby-lang.org/en/community/ruby-core/#following-... > The current primary repository of the latest Ruby source code is git.ruby-lang.org/ruby.git. There is also a mirror on GitHub. Usually, please use this mirror.
toomanybeersies 5y ago
I'm not sure that the new "valueless" hash syntax is an improvement. From my experience with Typescript, it's a common source of bugs. But I'm sure that people had similar complaints when compact hash syntax was introduced in Ruby 1.9, and now nobody even thinks about it. So I'm sure I'll survive.
- maxfurman 5y ago
  I'm in the opposite camp - I love the short object syntax in JS and the way it mirrors destructuring. I'm very happy to see something similar come to Ruby! But, that said, I think that the Ruby version is ugly compared to JS and the extra colons are noisy. I assume there's some reason why the parser can't read `{ x, y }`, as ruby is notoriously hard to add syntax to.
  - pqdbr 5y ago
    Count me in as well, very happy to see this addition.
  - hvis 5y ago
    > I assume there's some reason why the parser can't read `{ x, y }`, as ruby is notoriously hard to add syntax to. Something in the parser using the colon after the first identifier to disambiguate between hashes and blocks, probably.
maxfurman 5y ago
Very confused by the example of the "pin" operator given here - what is it for, and what is the improvement in this release?
- dangerbird2 5y ago
  Definitely not a clear description, but I believe it stands for "pattern matching in". Ruby's new pattern matching uses a sytax of case {{ value }} in {{ pattern }} {{ code }} ... end the new feature apparently allows expressions, rather than just local variables, in the pattern spec. They probably should have included the link to the feature ticket: https://bugs.ruby-lang.org/issues/17411 https://bugs.ruby-lang.org/issues/17411
- Lammy 5y ago
  https://docs.ruby-lang.org/en/master/doc/syntax/pattern_matching_rdoc.html#label-Variable+pinning https://docs.ruby-lang.org/en/master/doc/syntax/pattern_matc...
fourseventy 5y ago
"foo(x:, y:) is a syntax sugar of foo(x: x, y: y)" This syntax sugar is a nightmare to me. Very confusing and for what? To save 2 keystrokes?
- onlyrealcuzzo 5y ago
  I really wish there was a command to `un-sugar` a script - especially intelligently built into editors. That way - if you're new to a language and don't want to deal with all the cognitive overhead of syntactic sugar (or if you just find some particular feature really complicated) - you could "un-see" it.
- dragonwriter 5y ago
  > To save 2 keystrokes? A lot more keystrokes if you are using meaningful argument and/or hash key names, but the big benefit is, IMO, readability (at least, that's the big benefit I see with the very similar syntax in JS.)
  - sodapopcan 5y ago
    I just don't see the readability arguments. I think it hurts readability in a big way, especially in JS where it can be mistaken for destructuring. I've seen firsthand people who defend this syntax get confused. Sure, it's brief confusion, but if anything introduces any kind of confusion at all, I don't see the benefit. `foo: foo` is verbose, sure, but I don't know how one could argue that it isn't readable. It's about as clear as you can get.
- mostlysimilar 5y ago
  It's only two keystrokes if your parameters are single characters. def some_method(with_longer_parameters: with_longer_parameters) do_something(with_longer_parameters) end vs def some_method(with_longer_parameters:) do_something(with_longer_parameters) end
  - cpb 5y ago
    Is it to spare keystrokes in method definition, or rather, in method invocation? Your second definition reads that `with_longer_parameters` is a keyword argument with no default. Still, you've illustrated the keystroke savings with your choice of parameter names :-)
drumpkid 5y ago
No news on Ractors improvements :'(, maybe next year
Mikeb85 5y ago
Nice, compiling it now. Will be fun to play with YJIT and try the new features.

220 points by riffraff 5y ago

Those error log messages will save me time--super excited about that!

kule 5y ago

Was just playing around locally and found one of the undescribed Irb improvements is a drop-down with autocompletion suggestions nice!

duffyjp 5y ago
I haven't had a chance to try yet, but I'm hoping some of the irb regressions that began around 2.7 are fixed. Try pasting an array or hash with 1000 or so elements. In 2.6.x it's instantaneous, in 2.7.x it can take minutes--

WalterGR 5y ago

Swapping out a JIT must be an unimaginably complex operation.

byroot 5y ago
It's not swapped, both are available for now.
aardvark179 5y ago
Not really. Separate out your JIT into well defined components (compiling a method, installing the compiled version, invalidating the compiled version, deoptimising, etc.) and make sure your JITs use those common interfaces. The JVM manages to support multiple JITs (including Graal which is written in Java) and multiple GCs through this sort of approach.

evolve2k 5y ago

Enhanced error log messages are always welcome on the ground :) Reminded me of the work done in elm to explicitly improve their error reporting by deeply considering the user experience [1] Repo for the newly included error_highlight gem is interesting [2], anyone have more background on this ? 1. Elm “the perfect big report” https://elm-lang.org/news/the-perfect-bug-report https://elm-lang.org/news/the-perfect-bug-report 2. Error_highlight gem repo: https://github.com/ruby/error_highlight https://github.com/ruby/error_highlight

citizenpaul 5y ago
Unrelated to this but i guess the comment reply time expired to your question before I could answer about the dead physicist. No not without doxing myself. I did some asking for you(and me i suppose) though and most likely what he was working on was something to do with decoherence of entangled qbits for quantum computing.

picardo 5y ago

Good to see IDE support for TypeProf type hints[1]. I've been doing a lot of work in statically typed languages lately, and spoiled by how good IDE integration is with the compiler. Ruby has been moving towards static types for a while, but the lack of IDE support has always been the dealbreaker for me to go back to Ruby. The ecosystem needs more tooling like this. [1] https://github.com/ruby/typeprof/blob/master/doc/ide.md https://github.com/ruby/typeprof/blob/master/doc/ide.md

rememberlenny 5y ago

Can anyone share their experiences using YJIT or RBS in Rails? I’m curious how the impact affects development, deployment, etc.

byroot 5y ago
> I’m curious how the impact affects development, deployment, etc. YJIT is pretty much transparent in production, if not it's likely a bug. When we tried MJIT in production to compare it against YJIT, it causes lots of request timeouts on deploy, because the JIT warmup would take 10 to 20 minutes and it's much slower during that phase. But YJIT warms ups extremely fast and with a much lower overhead, it's seemless on deploy. The only thing you may need to tweak is `--yjit-exec-mem-size`, it defaults to `--yjit-exec-mem-size=256` (MB) which is not quite enough for larger apps. As for development, it would work, but with code reloading enabled, you'd likely exhaust the executable memory allocation pretty fast, because for now YJIT doesn't GC generated code [0]. It will come soon, hopefully before the 3.1.0 release, but that's one of the reason why it's not enabled by default. [0] https://github.com/Shopify/yjit/issues/87 https://github.com/Shopify/yjit/issues/87
- joelbluminator 5y ago
  Is it 256 mb for the entire app server or is it multiplied by each Unicorn/Puma process?
  - byroot 5y ago
    Each process, a small part of it might make it into CoW during boot, but that won't make a big difference. If you don't have the free RAM for it and you app is small enough, you can try lower values. Also note that currently YJIT fully initialize that memory to make it easier to debug, so it's not even virtual. That's another thing that is on the roadmap to be improved soon, and ultimately you'll only pay for the part that YJIT really use even if 250MB is allocated. But overall all JITs trade increased memory usage for faster execution, you have to store that generated code and metadata somewhere.

sandstrom 5y ago

I'd like to see Ruby deprecate some of the rarely used standard library items. For example, does Rinda and GDBM need to be in the standard lib? Maybe they're better suited as stand-alone gems? Similarly, I think it should stop bundling some gems. I see they are moving some gems from 'default' to 'bundled', which I guess is some sort of deprecation or demotion -- that's great! ** I'd also like to see them move development onto Github, that should make it easier for more people to participate.

toomanybeersies 5y ago
That's been slowly happening [1]. For instance, with Ruby 3.0, net-telnet and xmlrpc were removed from the stdlib and now have to be installed as standalone gems. [1] https://stdgems.org/removed/ https://stdgems.org/removed/
ksec 5y ago
>I'd also like to see them move development onto Github, that should make it easier for more people to participate. This has been discussed a few times in the past 5 years. But some member refused to use Github due to it not being open source. Not sure if that is still the case but you could certainly try and ask again.
- nixpulvis 5y ago
  GitHub is becoming a bloated mess however... if it aint broke don't fix it.
_odey 5y ago
Looks like dbm/gdbm were removed from the ruby repo, just not documented in the release notes: https://github.com/ruby/ruby/pull/4525 https://github.com/ruby/ruby/pull/4525 https://github.com/ruby/ruby/pull/4526 https://github.com/ruby/ruby/pull/4526 https://github.com/ruby/ruby/pull/4619 https://github.com/ruby/ruby/pull/4619
Mikeb85 5y ago
> I'd also like to see them move development onto Github, that should make it easier for more people to participate. From: https://www.ruby-lang.org/en/community/ruby-core/#following-ruby https://www.ruby-lang.org/en/community/ruby-core/#following-... > The current primary repository of the latest Ruby source code is git.ruby-lang.org/ruby.git. There is also a mirror on GitHub. Usually, please use this mirror.

toomanybeersies 5y ago

I'm not sure that the new "valueless" hash syntax is an improvement. From my experience with Typescript, it's a common source of bugs. But I'm sure that people had similar complaints when compact hash syntax was introduced in Ruby 1.9, and now nobody even thinks about it. So I'm sure I'll survive.

maxfurman 5y ago
I'm in the opposite camp - I love the short object syntax in JS and the way it mirrors destructuring. I'm very happy to see something similar come to Ruby! But, that said, I think that the Ruby version is ugly compared to JS and the extra colons are noisy. I assume there's some reason why the parser can't read `{ x, y }`, as ruby is notoriously hard to add syntax to.
- pqdbr 5y ago
  Count me in as well, very happy to see this addition.
- hvis 5y ago
  > I assume there's some reason why the parser can't read `{ x, y }`, as ruby is notoriously hard to add syntax to. Something in the parser using the colon after the first identifier to disambiguate between hashes and blocks, probably.

maxfurman 5y ago

Very confused by the example of the "pin" operator given here - what is it for, and what is the improvement in this release?

dangerbird2 5y ago
Definitely not a clear description, but I believe it stands for "pattern matching in". Ruby's new pattern matching uses a sytax of case {{ value }} in {{ pattern }} {{ code }} ... end the new feature apparently allows expressions, rather than just local variables, in the pattern spec. They probably should have included the link to the feature ticket: https://bugs.ruby-lang.org/issues/17411 https://bugs.ruby-lang.org/issues/17411
Lammy 5y ago
https://docs.ruby-lang.org/en/master/doc/syntax/pattern_matching_rdoc.html#label-Variable+pinning https://docs.ruby-lang.org/en/master/doc/syntax/pattern_matc...

fourseventy 5y ago

"foo(x:, y:) is a syntax sugar of foo(x: x, y: y)" This syntax sugar is a nightmare to me. Very confusing and for what? To save 2 keystrokes?

onlyrealcuzzo 5y ago
I really wish there was a command to `un-sugar` a script - especially intelligently built into editors. That way - if you're new to a language and don't want to deal with all the cognitive overhead of syntactic sugar (or if you just find some particular feature really complicated) - you could "un-see" it.
dragonwriter 5y ago
> To save 2 keystrokes? A lot more keystrokes if you are using meaningful argument and/or hash key names, but the big benefit is, IMO, readability (at least, that's the big benefit I see with the very similar syntax in JS.)
- sodapopcan 5y ago
  I just don't see the readability arguments. I think it hurts readability in a big way, especially in JS where it can be mistaken for destructuring. I've seen firsthand people who defend this syntax get confused. Sure, it's brief confusion, but if anything introduces any kind of confusion at all, I don't see the benefit. `foo: foo` is verbose, sure, but I don't know how one could argue that it isn't readable. It's about as clear as you can get.
mostlysimilar 5y ago
It's only two keystrokes if your parameters are single characters. def some_method(with_longer_parameters: with_longer_parameters) do_something(with_longer_parameters) end vs def some_method(with_longer_parameters:) do_something(with_longer_parameters) end
- cpb 5y ago
  Is it to spare keystrokes in method definition, or rather, in method invocation? Your second definition reads that `with_longer_parameters` is a keyword argument with no default. Still, you've illustrated the keystroke savings with your choice of parameter names :-)

drumpkid 5y ago

No news on Ractors improvements :'(, maybe next year

Mikeb85 5y ago

Nice, compiling it now. Will be fun to play with YJIT and try the new features.