4 ms·

> 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

by brink 4y 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.

randomdata 4y ago
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.
- pmontra 4y ago
  > 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.
  - randomdata 4y ago
    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.
endlessvoid94 4y ago
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.
- wiseowise 4y ago
  It’s not a big problem until it is.
pizza234 4y ago
> 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.
flippinburgers 4y ago
The main problem is active record insanity and poorly designed table relationships/indices that lead to maintenance nightmares.
- fknorangesite 4y ago
  > poorly designed table relationships/indices that lead to maintenance nightmares. Like what?
- theonething 4y ago
  > 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.
Alifatisk 4y ago
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.
- gosukiwi 4y ago
  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
- oleg_antonyan 4y ago
  The UX is terrible. Separate file for types is just inconvenient. I wish it was something like Python's optional typing
  - Alifatisk 4y ago
    Optional typing in Ruby would be so awesome
jack_riminton 4y ago
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
oleg_antonyan 4y ago
I use type assertions for this https://github.com/olegantonyan/typerb https://github.com/olegantonyan/typerb
randito 4y ago
> 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.
multiplegeorges 4y ago
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.

by brink 4y ago

randomdata 4y ago

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.

pmontra 4y ago
> 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.
- randomdata 4y ago
  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.

endlessvoid94 4y ago

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.

wiseowise 4y ago
It’s not a big problem until it is.

pizza234 4y ago

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

flippinburgers 4y ago

The main problem is active record insanity and poorly designed table relationships/indices that lead to maintenance nightmares.

fknorangesite 4y ago
> poorly designed table relationships/indices that lead to maintenance nightmares. Like what?
theonething 4y ago
> 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.

Alifatisk 4y ago

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.

gosukiwi 4y ago
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
oleg_antonyan 4y ago
The UX is terrible. Separate file for types is just inconvenient. I wish it was something like Python's optional typing
- Alifatisk 4y ago
  Optional typing in Ruby would be so awesome

jack_riminton 4y ago

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

oleg_antonyan 4y ago

I use type assertions for this https://github.com/olegantonyan/typerb https://github.com/olegantonyan/typerb

randito 4y ago

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

multiplegeorges 4y ago

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.