Hacker News Reader

Comment by sinsterizme | Hacker News Reader

This is very good timing for me, I just left my python dev job and am starting a job where they use Ruby. I’m very excited to be using Ruby again, it’s a much nicer language to use for a variety of reasons I can’t possibly enumerate. Ruby’s stdlib and surrounding documentation is pristine, I vividly remember being appalled when trying Python for the first time and thinking where the rest of it was. The major issue I find with Ruby (and that I saw mentioned elsewhere in this thread) are imports / requires, which is much too magical in Ruby; Python’s import is way saner

View on HN

Ha, I just did the same thing. It's definitely a bigger shift than I expected!

I think the biggest difference so far is the quality of dev tooling. Python's native type system has enabled a lot of really good editor functionality. Ruby has Sorbet, which seems good, but it's _much_ slower and more cumbersome. After a save to fix a red squiggly line, there's a 5 second delay before the typechecker / linter figures out the code has updated, run, and updated errors in-editor (note: this could be due to the size of the repo, but it's still a pretty tough experience)

In the company codebase it's pretty well set up and VSCode come pre-configured. But yesterday I tried setting up a little ruby project on my personal machine and couldn't figure out the combination of extensions to make basic auto-complete and jump-to-definition functionality work at all. To their credit, Microsoft has made Python development incredibly straightforward by giving a One Best Way To Do It and making sure there's good LSP support.

Python has its warts for sure, but I've grown to really appreciate the language and its ecosystem.

Ruby's imports aren't magical by default. Autoloading frameworks make them so.

The fact that ruby makes this possible means the community will take advantage of it, to the point of abusing it sometimes. This hurts understandability of the code base. Too many times I would open a ruby code base and spend significant amount of time tracing where things are defined (mostly relying on suboptimal searching) because of the lack of explicit imports/requires.

An easy way to do that is to use the Pry gem. If you're in a pry console, you can use `show-method Thing.foo` and it will show you the method, which file and line it's defined in, etc. Pry is a great tool and this feature makes is a blessing.

Python can do this magic too and the community hasn’t abused it. Every part of modules and module loading is swappble, mutable to the point where modules can be arbitrary classes if you want.

It would be 2/10 difficulty to add transparent module autoloading to Python because you can just hook into module loading and arbitrarily modify or replace the module objects.

You wouldn’t even need a courtesy import because the main module is still a module.

Even without an autoloader, Ruby has a single global namespace, so you have access to everything that has been required at any point from anywhere.

If anything autoloaders enforce that constant names match filenames, making it easier to locate the source.

Reply on news.ycombinator.com