Hacker News new | ask | show | jobs
by revskill 904 days ago
I hope Ruby 4.0 could allow explicit import and avoid implicit, global namespace gem import mechanism like nowsdays.
4 comments

You might be interested in Chris Salzberg’s Im [0], already usable on Ruby 3.2, or the discussion about the speculative “namespace on read” feature [1].

[0] https://github.com/shioyama/im

[1] https://bugs.ruby-lang.org/issues/19744

Implicit or explicit, I’m OK with the global namespace.

On paper it’s awkward, but in reality convention and social norms make it rarely an issue.

The global namespace only supporting exactly one version of each gem encourages a health culture of stable ABIs and deprecation periods too. An absolute dream compared to some language ecosystems

I'm feeling a bit ignorant, but isn't this a Rails thing and not a Ruby thing? I know that for most projects that's a distinction without a difference; but, that may be a decision from the Rails devs and unrelated to what Ruby's devs do?

Or I'm speaking out of my ear and completely wrong (and I don't know which :D)

It's a Ruby thing. Ruby only has a single global namespace, no imports.

If anything Rails autoloading (Zeitwerk really) make it much easier to find where constants come from as it enforce a constant name -> file name convention, so all you need is fuzzy file search.

You're right, implicit import (autoload) is an opt-in feature. Rails used to use autoload by default as of 3.x/4.x. It's been quite a while since I used Rails, so I'm not sure if this is still the case.

Ruby imports have always used a single global namespace. I'm not convinced that this is an issue in practice - it's worked just fine for several other languages.

There's a big difference between Rails autoloading and Ruby autoload, in that Rails is implicit and conventional from the constant name plus load paths, whereas Ruby is explicit as one declares where to find each constant.
I mean, only because it's possible to learn to live with doesn't make it pleasant. Especially for managing large projects it can get unwieldy. Most high level languages I can think of have moved away from this approach.

I used to be a huge Ruby fan but having exposure to Python where this isn't an issue, life is just easier.

It's a matter of personal preference and/or which one you've learnt to live with first.

I like how Ruby's imports work - just load a file, similar to C. On the other hand, modules in Python always felt like something to overcome rather than "just works as you expect".

To each their own, I guess. After working with python/lua, I really appreciate not needing to do manual imports all over. I'm glad ruby makes this so easy :)

Oh, and not needing __init__.py files in order to import something. Goodness, what an absolute pain.

I really like the Python/Lua module system. To each their own...
I agree, but Ruby folks seem to consider C style transitive inclusion to be a feature. I found it and several other aspects of Ruby to be maddening (and productivity-sapping) for the 1.5 years I spent with an otherwise pretty nice language.