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

171–180 of 197 posts

Re: Ruby 4.0.0

#171

Post by Kerrick »

bvan wrote: 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?

The PickAxe is still amazing. You can buy the fifth edition (for Ruby 3.3) in paper now, or the sixth edition (for Ruby 4.0) as a beta ebook now.

5th: https://pragprog.com/titles/ruby5/programming-ruby-3-3-5th-e...

6th: https://pragprog.com/titles/ruby6/programming-ruby-4-6th-edi...

For a timeline-oriented reference of changes, check out https://rubyreferences.github.io/rubychanges/ and its individual pages.

Re: Ruby 4.0.0

#172

Post by bl4kers »

cutler wrote: post #161
bl4kers wrote: post #154

Earlier quoted context omitted.

There's a Ruby gem for almost anything

MVT for testing mobile spyware? There are whole sectors of industry, such as cybersecurity, where Python shines and Ruby is nowhere to be seen.

In what other language is MVT offered other than Python? That seems like a good example of unique language specialization and not reflective of a Ruby gap relative to any other language. I also don't think that's something you'd bundle & reuse in another offering. In my opinion that's the primary value proposition of building within an ecosystem

Re: Ruby 4.0.0

#173

Post by Kerrick »

adamors wrote: post #18
riffraff wrote: post #13

Earlier quoted context omitted.

There's an official format for defining types in separate files (RBS) and some tooling to type check them (matz doesn't like types next to the source code). There's a pretty battle tested tool to define inline types as ruby syntax and type check both statically and at runtime[0]. It's still not a particularly nice situation imvho compared to typescript or python, but there's been some movement, and there's a newslett…

I’ve used Sorbet on a project for 2 years recently and it honestly was the final nail in the coffin for Ruby for me. Really rough around the edges, lots of stubs have to be added because support for gems is lackluster but whatever Sorbet generates are hit or miss etc. So you end up writing a lot of hard to understand annotations and/or people get frustrated and try to skip them etc. Overall a very bad DX, compared to…

Sorbet is a third-party add-on, not a part of Ruby. It's like if CoffeeScript was your final nail in the coffin for JavaScript.

Re: Ruby 4.0.0

#174

Post by digitaltrees »

mierz00 wrote: post #35
digitaltrees wrote: post #29

Ruby is amazing. I recently built a layer on top of Rails that can generate an API from a single markdown file. I did the same thing in python but it was much harder and JavaScript would have been a beast. Ruby can meta program like nothing else.

Curious to hear more about this, do you have any examples?

We might release it as a framework of gems.

We created an Abstract controller that handles all of the typical behavior for a resource, auth, filtering, pagination, tenancy, import/export, serialization etc.

Then we expanded rails generators to cover ALL typical behavior. And the markdown file calls the generators.

It was a bit complicated to model polymorphic behavior but we got it working thanks to Ruby/Rails.

But the basic premise that made this work is: Use only restful actions; don’t turn it into RPC. Recognize that most RPC/graphql functions are state changes that could have been a patch request. So instead of /clients/activate its /clients with a status attribute for “activate” or “archive”. Then most nested routes aren’t needed, use accepts nested attributes for and return child ids in the show action. There’s more to it that this but by strictly following conventions and modeling the data for rest, the api ends up Super simple.

Our standard controller only whitelists strong params. All other behavior is automatic.

Re: Ruby 4.0.0

#175

Post by Gigachad »

nonconstant wrote: post #159
Gigachad wrote: post #23

Earlier quoted context omitted.

There’s projects trying to implement it. But I’ve never seen a project using typed Ruby. I think most people who cared just moved to typescript.

Stripe is using typed Ruby: they are authors of https://github.com/sorbet/sorbet

I have seen that. But on the smaller companies it’s been my experience that Typescript has universal uptake for the frontend while Sorbet and RBS are things to keep an eye on but not getting any interest in using yet.

Re: Ruby 4.0.0

#176

Post by stouset »

bjoli wrote: post #101
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.

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…

I’m sure I’ll get downvoted for it, but strict technical merits aside, Python to me seems built by engineers who lacked any sense of taste. Ruby is beautiful.

Re: Ruby 4.0.0

#177

Post by mierz00 »

digitaltrees wrote: post #174
mierz00 wrote: post #35

Earlier quoted context omitted.

Curious to hear more about this, do you have any examples?

We might release it as a framework of gems. We created an Abstract controller that handles all of the typical behavior for a resource, auth, filtering, pagination, tenancy, import/export, serialization etc. Then we expanded rails generators to cover ALL typical behavior. And the markdown file calls the generators. It was a bit complicated to model polymorphic behavior but we got it working thanks to Ruby/Rails. But t…

What do the markdown files look like?

Re: Ruby 4.0.0

#178

Post by duckydude20 »

blandflakes wrote: post #83
jurgenkesker wrote: post #66

Earlier quoted context omitted.

This year I also switched from Ruby to Kotlin on my hobby/light commercial backends. I just can't stand the way Ruby is not statically typed, and the resulting insecurity around if everything is actually doing what it should do. Kotlin gives me joy, and performance is actually better (trading memory requirements ofcourse, but that's not a big problem anymore). I still love Ruby, but only use it for simple scripts now…

This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing somewhat decrease in the web arena, it's still frustrating to have to manage type relationships in my head. I'm hopeful that the incoming type system work makes me happier there, though…

what advantage/disadvantages does Scala/jvm have over Elixir/otp/beam?

i am learning Elixir and liking the concepts. i am coming from kotlin/jvm and i like kotlin, apart from kotlin-coroutines. planning to migration all threading code to virtual threads. but biggest problem is threadlocal.

Re: Ruby 4.0.0

#179

Post by ngcazz »

pansa2 wrote: post #70
RomanPushkin wrote: post #20

I'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…

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

That core philosophy is a focus on aesthetics which means that API design in Ruby is much more driven by developer taste than practical considerations (for better or worse)

Re: Ruby 4.0.0

#180

Post by blandflakes »

duckydude20 wrote: post #178
blandflakes wrote: post #83

Earlier quoted context omitted.

This has sort of been my issue with Elixir. I've been doing Scala for years but I think Phoenix is really the best web story at the moment for how I want to be building web apps. And while I believe that the benefits of static typing somewhat decrease in the web arena, it's still frustrating to have to manage type relationships in my head. I'm hopeful that the incoming type system work makes me happier there, though…

what advantage/disadvantages does Scala/jvm have over Elixir/otp/beam? i am learning Elixir and liking the concepts. i am coming from kotlin/jvm and i like kotlin, apart from kotlin-coroutines. planning to migration all threading code to virtual threads. but biggest problem is threadlocal.

I think they're pretty different, but there are some places where you can compare them:

1. Hiring and job market - the JVM is simply more employable

2. Ecosystem - in general you can expect the JVM to have library support for most things you're going to need.

3. Typing - if you like static types, you're probably going to miss that in Elixir/Erlang. They're working on a gradual type system for Elixir that looks quite pragmatic, so I'm excited to see how that works out.

The Elixir side of things has some real advantages, though. Runtimes like the JVM are slowly adding threading paradigms that start to look like how the beam works, if you squint enough. Naturally, Elixir already has that, and already has technologies that work very well with it. Virtual threads on the JVM are a smart effort that will take a long time to be complete and will always have to take backwards-compatibility into account, especially if you're in Java itself.

Phoenix is also IMO a best-in-class web framework. I don't think it's universally applicable, but if any JVM language had something like Phoenix I doubt I'd be considering Elixir nearly as strongly (due to my affection for types). So while the JVM ecosystem is broader, it's not uniformly stronger.

I also think that "domain" is much broader for JVM stuff. The web technologies there feel pretty baroque rather than empowering, but you can still do web on the JVM, and Kotlin or Scala in particular IMO serve better for systems where the bulk of the code is internal business logic. I think that even if I adopted Elixir entirely, I'd probably retain some "second language" for deeper systems.

Post reply on HN