[xionon]

> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server."

This hasn't been a serious problem in a decade.

> We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since...

The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

(ex-Braintree engineer, we processed billions of requests on Rails)

[hellcow]

> types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking.

> This hasn't been a serious problem in a decade.

That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.

[midrus]

While I do like static typing, I find more bugs because people have no clue about security and they think they can do it better by just tying together a few libraries and storing a jwt in local storage or they forget to handle Prisma exceptions or they didn't know what session fixation is or because they forgot to consider a corner case of foreign key exceptions from the database library, etc, etc than because somebody passed a string where an integer was needed.

Giving up frameworks with 10+ years of hardening and documentation and libraries and support etc just because of coroutines or static types or nice syntax or because that's what google does then I should do it too makes absolute no sense to me.

[tinco]

If you're finding bugs in production that a compiler or typechecker could have found then there's something seriously wrong with your test suite. That's how Rails works, if you don't have 90%+ statement coverage it will be hell.

[jshen]

I’ve worked on many large rails apps at scale and large Java apps at scale. There has been no significant difference in the big count between them despite Java having static types.

[Tainnor]

> [...] types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug.

That's a typical response from dynamic typing advocates, but the response is that in a language with a good type system, many more things can be type errors than would be in a dynamically typed one.

For example, from my time writing Ruby, trying to call methods on `nil` was an incredibly common error, but this is simply a type error in some more modern statically typed languages (including Kotlin and Swift).

[djur]

A substantial number of bugs I see where a method is called on nil are business logic errors that result in something not being where it's expected, and those bugs would just manifest differently at runtime with static typing. Every web app I've ever seen in a statically typed language has plenty of logic relying on "unwrap nullable or raise error" mechanisms.

[Lio]

I agree, I think it’s a good reason to use the static typing in Ruby > 3.0.

Any static analysis tool you can use to catch bugs before runtime in production is something we want.