Comment by IshKebab

Comment by IshKebab 21 hours ago

Can you tell me why exactly? I've never used Rails but I have tried to understand and modify Gitlab's Ruby code and honestly it was a completely incomprehensible mess. I'm no stranger to large codebases but Gitlab is almost impossible to follow and it seems to be entirely because they use Ruby.

I mean if you look at one file the code seems fairly clean and well written, but if you try and figure out e.g. where a function is called from... well good fucking luck! There's no static typing to help you, and even worse it seems like almost everything is "magically" connected. Like you'll have a function called `foo_bar()` and if you grep for that you get zero results. In the end you'll find that in the `Foo` class there's a list of strings including `BAR` and it constructs the identifier from those.

Absolute nightmare. But people do seem to love Rails... so why?

ukprogrammer 18 hours ago

I echo the sentiment that you MUST use a debugger when working with ruby/rails. When using a debugger, magic becomes a call stack that is transparently visible. Once proficient and familiar with the conventions, reading it becomes a lot easier.

For Rails's productivity, there's many reasons. One is the 'Active Stack' which acts as a 'standard library' of sorts for the framework.

It provides extremely seamless tooling all the way from the most frontend of concerns (ActiveView - HTML/JS) to the backend (ActiveRecord - SQL ORM layer) and anything in between (ActiveController - HTTP Requests, ActiveMailer - Emails etc.). These tools are simple, robust and cohesive.

These primitives are built on by the community to provide powerful tooling (Devise, OmniAuth, amongst others) that allows one to implement the standard plumbing most SaaS/CRUD apps need in a few minutes - billing, auth, emails so you can get to writing business logic in a few minutes and have the boring stuff solved quickly.

Implementing just these basics in JS can take many hours and have you scratching your head wondering "Why are there 20 different ways to implement X? Why is there no tried and true way for something that are surely been done thousands of times? Why hasn't someone abstracted these details all away yet? Why do I have to npm install for this basic functionality? Wait, why did my build tooling just break?"

Reply View 1 reply

IshKebab 17 hours ago

So basically it's that it comes with built in libraries for common tasks? Authentication is definitely a super annoying thing to have to set up manually so I can see the attraction there.

Reply View | 0 replies

nisa 16 hours ago

You are not alone. Joined a company with a rails codebase and I really came to hate convention over configuration if you are not familiar with the convention. I've found Ruby on Roda and dry-rb much more understandable. I guess it's really a matter of taste. I've did C++ and Java before and while I appreciate Ruby rails is too much magic for me. I also hate to run into errors in runtime that a typed language would have catched.

Reply View 0 replies

vidarh 19 hours ago

Learn to use a remote debugger, and how to show the method source location.

This may sound snarky, but it's a good faith suggestion. Ruby has all of the tools to make debugging easy, but they're different than what you will expect if you come expecting things to work like in the static typing world.

But as much as I love Ruby, I do agree that Rails has too much unnecessary "magic". Much of which more modern Ruby is a reaction to. Personally I avoid Rails for my Ruby web projects.

Reply View 4 replies

IshKebab 19 hours ago

I mean... that sounds like a pretty horrible dev experience. Every time I want to understand a piece of code I have to actually run it? Insane.
For example I'm trying to understand Gitlab's merge train behaviour. Do I have to set up an entire Gitlab instance from source, then create a project, set up CI, run a merge train, all while running Gitlab in a debugger and then set a breakpoint and then finally I can see where the code is called from?
I've also done a lot of work on VSCode which is similarly large but mercifully written in Typescript. For that I just right-click->find all references. It takes 3 seconds.

Reply View | 3 replies
- vidarh 9 hours ago
  
  In practice it is not. And no, you don't have to run it, but it makes things a lot easier to do so.
  And no, you don't need to do what you suggest, you just need to load all the code into a running Ruby REPL.
  It is one consequence of Ruby being as dynamic as it is, but another is that the codebases tends to be far smaller. Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
  
  Reply View | 2 replies
  
  IshKebab 9 hours ago
  
  > load all the code into a running Ruby REPL
  That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?
  > Anywhere from half to 1/10th of the size of codebases in statically typed languages is my experience, including with direct translations.
  That sounds highly implausible.
  
  Reply View | 1 reply
  
  vidarh 3 hours ago
  
  > That counts as running it if you ask me. And I don't see how just loading the code would help you find the callers of a function?
  Loading it lets you introspect the code for calls. It's not necessarily always trivial to know what the type of the target object will be unless you're prepared to execute candidate methods, but it's rare for this to be an actual issue in practice. The more typical way of doing this would be to call piece of the code but without the elaborate setup you argue you'd need.
  You can also use Ripper or Parser to analyse the code if you insist on not loading the code, but you're then making things harder for yourself for no good reason.
  And that's really what it boils down to: If you insist on doing things the way you would for a static language, then yes, you will have a bad time.
  That's a you issue, not a tooling issue.
  > That sounds highly implausible.
  It's nevertheless true. I've translated multiple projects feature for feature from C, C++ and other languages to Ruby over the years. It's only implausible to people inexperienced with Ruby.
  
  Reply View | 0 replies