Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby 4.0.0

ruby-lang.org

Post reply on HN
Print view View original

51–60 of 197 posts

Re: Ruby 4.0.0

#51

Post by byroot »

WJW wrote: post #50
maz1b wrote: post #12

It's never Christmas without a new ruby version. The ruby::box thing looks pretty interesting, from a cursory glance you can run two simultaneous versions of something like a feature or rollout much more conveniently. Also being able to do if condition1 && condition2 ... end on multiple lines rather than one - this is pretty nifty too!

I'm kinda hoping that eventually each ractor will run in it's own ruby::box and that each box will get garbage collected individually, so that you could have separate GCs per ractor, BEAM-style. That would allow them to truly run in parallel. One benefit should be to cut down p99 latency, since much fewer requests would be interrupted by garbage collection. I'm not actually in need of this feature at the moment, but…

They already truly run in parallel in Ruby 4.0. The overwhelming majority of contention points have been removed in the last yet.

Ruby::Box wouldn't help reducing contention further, they actually make it worse because with Ruby::Box classes and modules and an extra indirection to go though.

The one remaining contention point is indeed garbage collection. There is a plan for Ractor local GC, but it wasn''t sufficiently ready for Ruby 4.0.

Re: Ruby 4.0.0

#52

Post by nomilk »

What's the relevance of ractors to the average web dev? Will ractors be useful directly in controllers/models/tasks? Or is it more that ractors will be useful to those working on the ruby language (and perhaps some gems - lower level stuff, perhaps), and therefore to the average ruby(/rails) programmer things 'just work', but faster?

Re: Ruby 4.0.0

#53

Post by Alifatisk »

rsanheim wrote: post #21
ergocoder wrote: post #9

I haven't looked at Ruby for a long time. I've moved away due to the lack of typing. Any degree of typing would be helpful. Does it support typing yet?

_low_type_ is early days still, but I think this approach is clearly the future of ruby typing. If this gets baked into the language for full “compile” time support and minimal performance impact, it will be amazing: https://github.com/low-rb/low_type

Previously, RBS-inline was the closest answer to typed Ruby, it was the JSDoc of Ruby. Recently, when I stumbled upon low_type and tried it out in irb, it finally felt like ”this is it, this is the TS of Ruby” and with runtime validation.

I like it, it deserves attention, especially for those who are seeking for typed Ruby. With this, you can finally experience it, and the syntax feels more ergonomic than with Sorbet.

Re: Ruby 4.0.0

#54

Post by dajonker »

ergocoder wrote: post #9

I haven't looked at Ruby for a long time. I've moved away due to the lack of typing. Any degree of typing would be helpful. Does it support typing yet?

In my honest opinion, if you can't live without static typing, Ruby just isn't for you.

Adding static typing to a dynamic language mostly gives you the disadvantages of both, without a lot of benefits. It's better to stick to languages that were designed with static types from the start.

I love programming in Ruby, having to worry about type annotations and the additional constraints that come with them would take a lot of the fun out of that.

Re: Ruby 4.0.0

#55

Post by pmontra »

mrinterweb wrote: post #15
ergocoder wrote: post #9

I haven't looked at Ruby for a long time. I've moved away due to the lack of typing. Any degree of typing would be helpful. Does it support typing yet?

There is [RBS]( https://sorbet.org/ ) (part of ruby 3) and [sorbet]( https://sorbet.org/ ). To be honest, these aren't widely used as far as I am aware. I don't know if it is runtime overhead, ergonomics, lack of type checking interest in the ruby community or something else. Type enforcement isn't a big part of ruby, and doesn't seem to be gaining much momentum.

> lack of type checking interest in the ruby community

IMHO if we wanted to write types in our programming language we would not have chosen Ruby for our programming tasks. We would have chosen one of the zillion of other languages. There were a lot of them when Ruby got traction about 20 years ago and many other languages have been created after then. It's not surprising that one of the main proponent of typing in Ruby is Shopify, because their path away from Ruby is very costly.

In my case one of the reasons I invested in Ruby is precisely because I did not have to write types.

Does it make Ruby slower than Java, my main language in 2005? Yes.

Is it fast enough for my customers? Yes. Most of them decided to use Ruby, then hired me.

Do I have to write unit tests to check for types? I don't.

Occasional problems that static types would have prevented to happen? Once or twice per year. Overall that's a good tradeoff because pleasing the type checker for non trivial types can be a time consuming task and some errors happen at runtime anyway, when the real world hits with its data a carefully type checked code base or a carelessly dynamic typed one. Think of an API suddenly returning a bad JSON, maybe an HTML 500 page. Static or dynamic typing, both won't help with that.

Re: Ruby 4.0.0

#56

Post by WJW »

byroot wrote: post #51
WJW wrote: post #50

Earlier quoted context omitted.

I'm kinda hoping that eventually each ractor will run in it's own ruby::box and that each box will get garbage collected individually, so that you could have separate GCs per ractor, BEAM-style. That would allow them to truly run in parallel. One benefit should be to cut down p99 latency, since much fewer requests would be interrupted by garbage collection. I'm not actually in need of this feature at the moment, but…

They already truly run in parallel in Ruby 4.0. The overwhelming majority of contention points have been removed in the last yet. Ruby::Box wouldn't help reducing contention further, they actually make it worse because with Ruby::Box classes and modules and an extra indirection to go though. The one remaining contention point is indeed garbage collection. There is a plan for Ractor local GC, but it wasn''t sufficient…

I know they run truly parallel when they're doing work, but GC still stops the world, right?

Assuming you mean "because with Ruby::Box classes and modules have an extra indirection to go though." in the second paragraph, I don't understand why that would be necessary. Can't you just have completely separate boxes with their own copies of all classes etc, or does that use too much memory? (Maybe some COW scheme might work, doodling project for the holidays acquired haha)

Anyway, very cool work and I hope it keeps improving! Thanks for 4.0 byroot!

Re: Ruby 4.0.0

#58

Post by magmostafa »

Exciting to see Ruby 4.0.0 released! The new conditional syntax improvements (if condition1 && condition2) are really elegant. The Ruby::Box feature for true parallelism looks particularly promising for CPU-bound workloads. This could significantly improve performance in scenarios where we've historically had to resort to external services or other languages. Looking forward to seeing real-world benchmarks and adoption patterns emerge.

Re: Ruby 4.0.0

#60

Post by zelphirkalt »

tebbers wrote: post #19
maz1b wrote: post #12

It's never Christmas without a new ruby version. The ruby::box thing looks pretty interesting, from a cursory glance you can run two simultaneous versions of something like a feature or rollout much more conveniently. Also being able to do if condition1 && condition2 ... end on multiple lines rather than one - this is pretty nifty too!

I've been doing if condition1 && condition2 ... end for ages and it seems to work find, what am I missing with this new syntax?!

It's funny how I have been doing this way of writing the conditions in languages, where one can, like Python (if you use a pair of parentheses) and linters have yelled at me for ages to put the binary operator on the previous line. People herald these quite subjective things like truths, just because there is some tool, that they can delegate responsibility to.
Post reply on HN