Glad to see internal stack traces cleaned up (maybe we can get relative paths some day?) and Set finally get the respect it deserves!
Relative path in stack trace would be so good!
Ruby 4.0.0
41–50 of 197 posts
Re: Ruby 4.0.0
#42I 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?
We have been adding Sorbet typing to our Rails application and it is a positive enhancement. It’s not like Ruby becomes Haskell. But it does provide a good deal of additional saftey, less testing, LSP integration is good, and it is gradual. There is a performance hit but we found it to be quite small and not an issue. But there are area of our application that use Grape and it is too meta for Sorbet so we don’t try a…
Same here. T::Struct and T::Enums at API boundaries has been the sweet spot—typed request/response models, runtime validation at ingress/egress.
I’ve been using this pattern for API clients[0] and CLIs[1]: define the shape once with Sorbet, get automatic JSON Schema generation when you need it.
[0] https://github.com/vicentereig/exa-ruby [1] https://github.com/vicentereig/lf-cli
Re: Ruby 4.0.0
#43It seems Ractor is still work in progress while Fiber has matured a lot in the last few releases. I vaguely remember reading Shopify is using Fiber / Rack / Async in their codebase. I am wondering if Rails will get more Fiber usage by default.
> It seems Ractor is still work in progress
The Ractor experimental status could almost be removed. They no longer have known bugs, and only one noticeable performance issue left (missing Ractor local GC).
But the API was just recently changed, so I think it's better to wait another years.
> I vaguely remember reading Shopify is using Fiber / Rack / Async in their codebase.
Barely. There is indeed this management obsession for fibers even when it doesn't make sense, so there is some token usage there and there, but that's it.
There is one application that was converted from Unicorn to Falcon, but falcon isn't even configured to accept concurrent requests, the gain is basically 0.
As for Rails, there isn't much use cases for fibers there, except perhaps Active Record async queries, but since most users use Postgres and PG connections are extremely costly, few people are using AR async queries with enough concurrency for fibers to make a very noticeable difference.
Re: Ruby 4.0.0
#44Have they improved tooling? I've yet to get any lsp working on windows
It’s below expectations, and even worse on Windows.
Luckily people seem to be aware of this and there was a whole talk about improving Ruby DX.
Re: Ruby 4.0.0
#45I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left. I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, s…
Just by how much better the editor/IDE support is with Python it is a change worth to do.
I just can’t stand the excessive dynamism of Ruby. I understand some people prefer/enjoy it, it’s just not for me.
Re: Ruby 4.0.0
#46I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left. I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, s…
Langchain? I tried using/learning langchain then I found out that it was evolving so fast that even the latest ai models didn't have even remotely up to date information on it! Not to mention the hundreds of Google search results for ---- why do langchain docs suck?
I finally switched to haystack and I have been really happy. (Don't work on corporate ai software this is just for personal use)
Re: Ruby 4.0.0
#47I'm happy to see v4.0, but 2025 was the year I switched from Ruby to Python after gradually drifting back to it more and more. The tipping point was when I had Claude Code automatically convert one of my Ruby projects to 100% Python - and after that, I just had no Ruby left. I spent over a decade enjoying Ruby and even wrote a book about it. At this point, though, Python has won for me: fastapi, pytorch, langchain, s…
Used Ruby for a decade, knew about it for more than that. I still sometimes use ruby syntax to communicate ideas with friends and colleagues.
For me, the killer feature of Python was the typing module and the intellij pycharm community edition being free and RubyMine having a subscription fee.
Re: Ruby 4.0.0
#48Have they improved tooling? I've yet to get any lsp working on windows
IMO programming on windows is just asking for punishment. Unless it’s a Microsoft language, you’re so much better off on Linux or macOS.
To be fair, vscode and .net core on linux is pretty much like having windows and visual studio at this point.
Re: Ruby 4.0.0
#49Earlier quoted context omitted.
I've been doing if condition1 && condition2 ... end for ages and it seems to work find, what am I missing with this new syntax?!
Less likely to cause git merge conflict as you don't change the original line. You only add one.
What we need is a syntax aware git diff https://news.ycombinator.com/item?id=42093756
Re: Ruby 4.0.0
#50It'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 it would be cool and I think it fits very well with the idea of ractors as being completely separated from each other. The downside is of course that sharing objects between ractors would get slower as you'd need to copy the objects instead of just sharing the pointer, but I bet that for most applications that would be negligible. We could even make it so that on ractor creation you have to pass in a box for it to live in, with the default being either a new box or the box of the parent ractor.