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

141–150 of 197 posts

Re: Ruby 4.0.0

#141

Post by lern_too_spel »

Calavar wrote: post #100
screenothethird wrote: post #80

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.

Because Ruby is just a better thought out language than Python is. It had a sane package management story 15 years before Python. It doesn't rely on weird hacks like exception throwing for iterator control flow. It doesn't have nearly as many warts and footguns on basic operations (for example, in Python csv.writer(file).writerows(rows) is broken unless you remembered to set the newline mode on the file; in Ruby file…

Everything being mutable by default, including strings, is about as big a foot gun as you can find in a high level language.

Re: Ruby 4.0.0

#142

Post by ezekg »

prh8 wrote: post #138
__float wrote: post #109

Earlier quoted context omitted.

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??

I was assuming Stripe, but would love to hear of others!

Re: Ruby 4.0.0

#143

Post by [deleted] »

empthought wrote: post #72
pansa2 wrote: 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?

[deleted]

Re: Ruby 4.0.0

#144

Post by zingar »

__float wrote: post #109
block_dagger wrote: post #95

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.

Very curious to hear about the specific cases where types make tests unnecessary.

I spend my working life swapping between Ruby and typescript projects and the typescript project is utter garbage with poor test coverage that needs a day of human QA for every build whereas the Ruby project is well tested such that we know that CI passing means it’s good to be released.

Re: Ruby 4.0.0

#145

Post by zingar »

danmaz74 wrote: post #114
block_dagger wrote: post #95

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.

> adopted Sorbet and it is nothing but an impediment to progress How so? I never really missed types in Ruby, even if I like them a lot in typescript, but right now I'm doing some "vibe coding" on a personal project and I was thinking about trying Sorbet. I think that it could help Claude Code avoid some mistakes it often makes which make it waste a lot of time fixing.

Interesting: how is CC in your experience at writing tests and then using them to avoid mistakes?

Re: Ruby 4.0.0

#146

Post by Lio »

auraham wrote: post #118

I gave it a try a few months ago. The first thing that I searched for was the REPL. Comparing it with Python, I prefer ipython over irb. It would be nice to see some improvement on DX on the REPL side

What actionable things do you think IRB is missing vs ipython?

Re: Ruby 4.0.0

#148

Post by woodruffw »

chucke wrote: post #133
empthought wrote: post #72

Earlier quoted context omitted.

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).

> 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

I think Guido left the BDFL role in 2018, and we’ve gotten walrus operators, structured matching, and exception groups since then (just off the top of my head). There’s also been significant language/grammar accommodations towards type annotations.

Overall, I’m of the opinion that Python’s language evolution has struck a pretty nice balance — there’s always going to be something new, but I don’t feel like the syntax has stagnated.

Re: Ruby 4.0.0

#149

Post by bjoli »

qezz wrote: post #134
bjoli wrote: post #101

Earlier quoted context omitted.

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

Well. If python is a dynamically scoped language, what they do is correct. If they are lexically scoped (which python is described as) the variable defined in the if should never have different visibility in the same scope.

In a lexically scoped language you don't define variables conditionally. What ruby does is also icky, but obviously the developers of both python and ruby wanted to save the developer an extra declaration. The ruby version is at least more correct from a lexical standpoint (it is set to nil if left "nondefined").

Re: Ruby 4.0.0

#150

Post by danmaz74 »

zingar wrote: post #145
danmaz74 wrote: post #114

Earlier quoted context omitted.

> adopted Sorbet and it is nothing but an impediment to progress How so? I never really missed types in Ruby, even if I like them a lot in typescript, but right now I'm doing some "vibe coding" on a personal project and I was thinking about trying Sorbet. I think that it could help Claude Code avoid some mistakes it often makes which make it waste a lot of time fixing.

Interesting: how is CC in your experience at writing tests and then using them to avoid mistakes?

When writing non-vibe-coded software I use CC a lot to write tests, but I have a skill to tell it not to create redundant tests, which otherwise it tends to do, and I have to check them anyway to ensure that they cover what needs to be covered, and sometimes to trim them down.

When vibe coding, what I noticed is that CC tends to make mistakes which it does catch with tests and fix on its own, but my hope is that using Sorbet this will happen much less, and thus development will go faster with less (slow) test cycles.

Post reply on HN