Hacker News Reader

Comment by IshKebab | Hacker News Reader

Hmm I'm no Python fan but I'd take it over Ruby any day, because it's so much easier to read a codebase. This is based on me trying to follow Gitlab's code.

The problems with Ruby seem to be:

* No static typing (I think there is Sorbet but apparently it's not very good and Gitlab doesn't use it).

* The lack of "syntax" makes it hard to grep for things. For example you can't find where `foo` is called by searching for `foo(` or `.foo` like you can in Python.

* It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results.

Maybe it's elegant and nice to write, but it's definitely awful to read.

View on HN

>* It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results.

I've had to take care of 3 large ruby codebases at different companies and this is what kills ruby for me.

A lot of ruby programmers think they are being clever when writing crazy dynamic ruby code, but they are only creating technical debt.

Years later when they have left and the "context knowledge " is gone from the team, the Ruby code is a huge mess of "magical" code.

And rails with its "implicit" functionality depending on method name. A lot of Ruby feels like "magical" to me (in that, things work because of some hidden implicit readmson).

I prefer code that is explicit, in your face. You can quickly see what it does and how it does it. Principle of least surprise and "don't make me think".

As a language it's pretty, I like to say that Ruby is really object oriented while python is a mix of stuff (why len(x) instead of x.len??)

Agreed. As a long time Ruby developer, I smack knuckles every time someone dynamically defines methods.

If I can’t find def method or def self.method, your code is not passing my review.

I'll take dynamically defining methods over method_missing

> No static typing (I think there is Sorbet but apparently it's not very good and Gitlab doesn't use it).

Sorbet is great, just not with generics yet. And if you use it the LSP will allow for finding references to method calls. If Gitlab doesn’t use it they’re missing out. Maybe they are too busy writing about how great their culture is to worry about such things…

If you don’t want dynamic identifiers, configure rubocop to prohibit it and enforce it through CI builds.

> It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results.

I guess the only reason this doesn't happen the same way in Python is because developers are told to repeat "explicit is better than implicit" 100 times before joining the community.

I can't find any single reason why the language would discourage it.

> It seems to encourage highly dynamic code where even identifiers are dynamically created, so often you'll find an identifier, and try to search for its definition but get zero results.

I wouldn't say it encourages it explicitly but it makes it far too easy. There is usually no need for highly dynamic code in code that is not part of a library.

Since when does Python have proper static typing? Also, why grep in the age of lsp?

Does lsp work well for Ruby? Back when I was writing Ruby (about a decade ago), static analysis tools typically had an even harder time finding things than grep.

It works fairly well if you use Sorbet, which has only been around for a few years.

Python type hints with Pylance/pyright are surprisingly good. Not Typescript good, but still pretty decent.

> Also, why grep in the age of lsp?

I'd rather not! But Gitlab doesn't use static type hints so I have no choice.

Reply on news.ycombinator.com