Live data from Hacker News

Ruby 4.0.0

ruby-lang.org

131–140 of 197 posts

Re: Ruby 4.0.0

#131
post #93
post #78

Earlier quoted context omitted.

Part of it is because Ruby imo, have a very nice syntax. With type annotation, it's becoming "ugly", a lot more verbose. It's no longer English-like. I do agree type have some advantages, but we need to get the DX right. I've been using Ruby for more than 10 years now, and I only started using LSP recently. To me it's a nice addition but I can live without it. Type is just one of the tools, not the only one imo. Not…

> With type annotation, it's becoming "ugly", a lot more verbose. It's no longer English-like. In our codebase that uses Sorbet I find this is really only true at function boundaries. Within a function it is pretty rare that anything needs to be spelled out with inline annotations to satisfy the compiler.

This is my biggest irk about Sorbet: because its signatures are wordy and because it can't infer the generic type of a private method, it slightly pushes you towards NOT extracting helper methods if they are going to be 2-5 lines. With Sorbet annotation, it'd easily become 10 lines. So it pushes towards bigger methods, and those are not always readable.

If only private methods would be allowed not having typing at all (with a promise of not being used in subclasses, for example), and Sorbet would be used mostly on the public surface of classes, it'd be much more tolerable for me.

Re: Ruby 4.0.0

#133
post #70

Earlier quoted context omitted.

> fastapi, pytorch, langchain, streamlit, and so on and on It's telling that your reasons for switching are all features of Python's ecosystem, not of the language itself. A lot of developers are moving to Python because of its libraries, and in many cases they don't care for the language at all. That's causing a problem for Python: many of these developers who'd rather be using different languages seem to want to mo…

None of what you say about Python is true. It’s not even plausible. The Python language hasn’t even had any significant syntax changes for four versions now; versions 3.11-3.14 are basically all internals optimizations. Why would you write something so clearly false?

Both are true. Different camps meant that any significant change to the language was scrutinised loudly. If my memory doesn't fail me, the last significant changes from the time Guido was still in charge, and he mostly abandoned the BDFL because of backlash. Since then python has been on a constant "analysis paralysis" state, with only efforts about performance pushing through (no one complains about a faster horse).

Re: Ruby 4.0.0

#134
post #101

Earlier quoted context omitted.

It’s just inferior to Python, nobody is making a more complex argument than that. Why ever use Ruby when there’s a virtually identical system that’s faster with a bigger community.

Ruby is a lot less awful than Python in my opinion. That is of course a very subjective opinion. The only reason I write more Python than Ruby is that ruby lacks the libraries I need. Somewhere along the line Python got all the momentum, and ruby got none and now python is better if you just want to get shit done. But man. I wish it was the other way around. I have one code snippet that summarises what I dislike abou…

> in ruby it also works, but the variable is at least always defined.

How is this even a pro? I agree that Python scoping rules are frustrating, but tbh not sure if I would prefer Ruby's behavior in this case

Re: Ruby 4.0.0

#135
post #128

For someone wanting to learn Ruby in 2025/26, what are some good up-to-date references, outside of the official documentation? Are there any recently-published books which stand-out?

I've done the pragmatic studio elixir and erlang courses and they are high quality. They do the same for Ruby and Rails[1]

[1]: https://pragmaticstudio.com/rails

Re: Ruby 4.0.0

#136

Earlier quoted context omitted.

To be fair, vscode and .net core on linux is pretty much like having windows and visual studio at this point.

Without the debugger, unfortunately. You still need VS or Rider for that.

The debugger works fine on Linux?

The only thing missing are some profiling tools.

If you really need those you're better off with Rider which is integrated with DotTrace.

Re: Ruby 4.0.0

#137

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?

Ruby has always been typed.

Re: Ruby 4.0.0

#138

Earlier quoted context omitted.

As long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothing but an impediment to progress.

I work in a large Sorbet codebase (though it isn't a Rails one) and it's a huge boon IMO. The number of tests we don't need to write because of Sorbet is really nice. It does occasionally require structuring your code differently, but I find the type-system-encouraged approach often gives a more elegant and harder-to-misuse interface in the end.

You work in a large Ruby codebase that _isn't_ Rails?! Are you hiring??

Re: Ruby 4.0.0

#139
post #85

Am I the only one who expected something bigger in a major release? With Ruby 3 we had the whole “3x3” story and significant performance improvements. This release feels more like a minor version, something closer to 3.5. I don’t want to downplay the work done by the maintainers on the contrary, huge thanks to them. But I do feel the version number is a bit misleading. That said, the work on the ZJIT[1] compiler is m…

eh, it's just a little celebration. Let Matz have it.

One issue is gems which are locked `ruby For a more concrete example, the grpc gem locks Ruby versions ( 3.5, whereas we are able to do 3.5-preview1).

So unless I feel like doing a lot of grunt work (which I don't), I can't even test Ruby 4 in our app until they release a new version. And while I recognize this is an issue with the gem, it is a consequence of choosing to do 4.0.

Re: Ruby 4.0.0

#140

Earlier quoted context omitted.

As long as Matz is firmly against, inline typing should never be a part of Ruby. I started working on a large Rails codebase that adopted Sorbet and it is nothing but an impediment to progress.

I think it will need to be a strong 3rd party that basically gives it the Typescript treatment. Adds type annotations to the core language syntax. The compiler does type checking, strips the annotations, and outputs plain Ruby.

Sorbet is backed by Stripe.

Why is it important to be a separate layer that compiles to plain untyped Ruby?

Post reply on HN