Hacker News new | ask | show | jobs
by brink 1272 days ago
> What's the general vibe on RoR nowadays?

Most people that use it are fine and productive.

Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

9 comments

I don't think it's denial - I've worked on a ton of rails apps of all different sizes and scales and...I've gotta say, I just don't see the issues you name in production all that often.

It's a problem, but it's not a big problem.

It’s not a big problem until it is.
> Because of lazy evaluation, type issues persist though. Plenty of instances of trying to call string methods on integers, and array methods on nil, and Rails devs in denial that that's a big problem as the app continues to grow.

This is not anymore inherent in the language. Gradual typing support for Ruby is now reasonably mature (companies like Shopify with large codebases have adopted it), so it's up to the team do decide if they want to take advantage of it or not.

For what it's worth I've been working with Rails projects for over 7-8 years and I've never encountered this as a problem
I have to agree on this one, it feels like some people are in denial of type issues within the Ruby / Rails community.

I've been experimenting with Rbs, Sorbet & Contracts though, they have their potential.

The UX is terrible. Separate file for types is just inconvenient. I wish it was something like Python's optional typing
Optional typing in Ruby would be so awesome
To be fair most of typing problems in Rails can be solved by having contracts and an operation pattern, kind of like Trailblazer, although they went a little bit too far lol
> and Rails devs in denial that that's a big problem as the app continues to grow.

As someone who maintains Rails 3 apps ad infinitum, this is where things break down with Rails applications. You can create applications very quickly with Rails if you stay within the conventions. But as the app grows, that discipline breaks down and the structure starts to suffer.

This is true for a lot of web applications. But I think the problem is worse for Rails because it's so easy to get started and create apps. That ease comes back to bite you -- as a giant legacy Rails app that no one on the team understands and no one is interested in fixing or maintaining.

Because of lazy evaluation or because the developers aren't properly documenting their work? A language with a formal type system essentially forces you to provide type documentation, but there is an expectation with dynamically typed languages that you will still document the types (probably in your test suite). Rails in particular makes this a core function of the framework to really push you to do so.
> Rails in particular makes this a core function of the framework to really push you to do so.

This sentence surprised me. How does Rails do it?

I never documented types in Rails and all was well, since 2005.

Rails puts testing front and centre. Testing exists to document how features are intended to function and intended to be used (with the added bonus of enabling machine validation of the documentation).

If a function accepts an arbitrary type, as is the case for all inputs in a dynamic language, one needs to document how the function is expected to behave when given x type. This is ultimately the same as type checking in a typed language. It just moves where the documentation is located.

In that move, it is true that you often lose some strictness in the quality of the documentation. The developers who have an active hatred towards their co-workers may even forgo writing documentation entirely. But if you reach that point you've really got people problems, not technical problems.

I've just added Sorbet and Tapioca to a Rails project and I was pleasantly surprised to find out that it works very well now!

As I add type annotations to my methods, VS Code and Sorbet are giving me similar feedback to what I get from Typescript projects.

I use type assertions for this https://github.com/olegantonyan/typerb
The main problem is active record insanity and poorly designed table relationships/indices that lead to maintenance nightmares.
> active record insanity

What exactly do you mean by that? It's just a bad ORM all around or is there something specific that is insane about it?

> poorly designed table relationships/indices

What does that have to do with Rails? Poorly designed database models are the fault of the developer(s) who designed them.

> poorly designed table relationships/indices that lead to maintenance nightmares.

Like what?