I will share a concrete example where I've recently run into this problem.

In order to make use of OpenStruct, `require 'ostruct'` first needs to be declared. Our code neglected to make that declaration, and we saw failures when it was deployed. This code, however, passed all of our tests. We discovered it was because our testing framework included rspec-expectations, which has a dependency on diff-lcs[1], and diff-lcs itself declares `require 'ostruct'`[2]. Because of this, ostruct was loaded globally before our code was tested, which silently masked the underlying issue.

This being said, I do understand the sentiment that this feature seems superfluous and may introduce unnecessary complication, especially from a Rubyist's point of view. The underlying mental model of Ruby dependency management is different from many other languages, and it's something to keep in mind when coming from other languages that do have scope for declared dependencies.

[1] https://github.com/rspec/rspec-expectations/blob/v3.13.3/rsp... [2] https://github.com/halostatue/diff-lcs/blob/v1.5.1/lib/diff/...

I really like Ruby, I do sort of wish it could focus on it's own identity a bit.

Some new features feel almost prescribed from other languages? Like, RBS and Namespaces specifically... they don't really fit the model of Ruby exactly, but they need to be there so Ruby can be presented as "having" type-safety and a-solution-for-monkey-patching. I'm all for taking inspiration from other places, but Ruby wasn't quite built around the same axioms that other programming languages started from.

I would like to second (or _third_) this opinion.

I've been working with Ruby for 20 years, and I've not needed something like this. This feels like adding a lot of complexity for little practical benefit. The trade-off feels off. I don't think this is worth the additional complexity.

While I agree with the sentiment here, ie. that Ruby doesn't necessarily need namespaces, I think it's also not necessarily good to base Ruby usage on what Shopify is doing. They have so many expert Ruby devs, and whole teams that write extra tooling, that I'd argue they shouldn't be compared to pretty much most of the usage of Ruby/Rails out there

Try using the Pay gem and others that assume a global singleton for a multi-tenant app (as in multiple different websites under different domains with different Stripe API keys). Lots of gems assume this and their configuration is global.

I personally would love to have this feature!

I shared my quick take in another comment tree, but I reread and understand the semantics a little better now, and I like it less, especially the notion that an instance of an object might transform when crossing Namespace boundaries. I get that it is similar to refinements in some ways, but this feels like it would be even more surprising, and I can foresee some gnarly bugs coming from this unless it is trivially easy to visualize the changes to an object between namespaces.

I'm updating my opinion from "mixed feelings" to "against" on this.

That's because you are aware of the limitations. Ruby is really powerful and allows you to manipulate existing modules, but you shouldn't do that because it will leak everywhere.

This namespaces feature allows you to manipulate existing globals, but keep it isolated in your own namespace. That seems pretty good to me :) Because it remains isolated, you can also use these features more aggressively.

I thought being able to do this with Nodejs was a near capability.

Over the past two years, I have come to understand that this contributes to the nightmare that is the Nodejs ecosystem (and the browser JS exosystem in general), at least when it comes to writing reliable software.

> I've been using Ruby for over 10 years

Maybe after a decade or two I wouldn't care, but as someone who has only used Ruby casually I would steer clear of it for anything serious, largely due to the lack of namespaces.

Why am I not surprised Shopify uses Rails.

Yeah, and I rather them focusing on performance instead of features. 2.7.8 is still the fastest and it’s getting old.

Most definitely. When I worked with existing Ruby codebases, it was surprisingly hard to answer the question "where is this defined" when every import is dumped into a single global namespace. I had no idea where stuff came from, and neither the IDE.

I mean, nothing is stopping you from doing something like:

  require 'foo'
  Bar = Foo::Bar

Ew. No.

I agree and I am overall mixed on this.

One of the tradeoffs that (imo) has been net positive in the Ruby ecosystem, is how a project has to ultimately load and run a single set of versions of all dependencies. It creates some extra maintenance work on one hand, but the result is that it encourages the ecosystem to not have to face the hell of having 3 or 5 or 10 versions of each common dependency within a project.

I recognize that this is an occasional cost to library maintainers, but in the long-term has contributed to benefits. My perception is that Ruby libraries have smaller list of dependencies than similar libraries in some other languages. There are several reasons for this, but this ecosystem pressure to stay compatible with a range of dependency versions is one of them.

It feels to me like this leads to a sweet spot for small- and medium-sized projects, and I can see it might have an upper limit? I have not been in the situation, but heard of situations where the largest projects inevitably run into needing specific versions of two separate libraries that don't agree on a version of a common dependency.

Identifying it as an experimental feature (disabled by default) seems like a reasonable way to make progress and iron out any problems.

Even this proposed feature is very similar to Common Lisp packages.

If video exists of the presentation, would love to see it.

It's not straightforward to prevent the original name from existing, though you can play games with File.read() and class_eval, but if you just want it to be available under a different name, and don't mind that the old one is there too, you can just do:

    require 'foo'

    module MyPreferredNamespace
      include Foo
    end

Ruby doesn't have real modules. You're right, that they are just namespaces. They are global variables with extra typing.

If you use a third party library, when you require something, you have no idea what "modules" or other values it creates polluting the global namespace. This at least assigns those values to a local variable where they can be accessed and doesn't make them global.

That said, I'm not a fan of ruby and all the workarounds to try to make it like a more sane language that it isn't.

It allows you to namespace things that aren't themselves namespaced. That way you can just require things that, might say, have the same module names as your own code without worry. I'm curious if this namespace mechanism could, say, isolate monkey patches. Probably not, but it would be nifty.

Using Ruby modules to namespace things is certainly possible, but is very often cumbersome. Modules also "hardcode" a namespace: that is, if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere -- or, in other words, namespacing is controlled by library author, not user. The proposed feature shifts that control to library user.

this would be a major breaking change

I can rest your mind, I've being coding Ruby for 17 years now, and I've never seen two gems or even files define the same global constant in a way that wasn't intentional. It's fair to say it's not at all pervasive.

That said, I do think there's use to this. First of all it would allow fancy platforms like RoR to make more effective use of namespaces. Right now you always need to specify the fully qualified name of a constant whenever you're defining it, which is just not aesthetically pleasing.

Another potentially useful place for this is in migrations. If you could just move the old implementation of a thing into a subdirectory and then load it into a namespace you make references to it a lot more explicit, and you give the replacement architecture full freedom within its root namespace.

Just to say, it's not only bad behavior that would be enabled by this feature. I definitely agree that having gems not sticking to their own modules would be a very bad thing indeed.

Yeah, and it kind of defeat passing PORT as a global variable. Like you might expect PORT=2917 to do effect these apps ports.

I'd say Ruby is more relevant than Elixir. But you're correct (IMO) that Ruby had a big moment but has died down since. At one point it almost felt like the default choice in startup land. Not so today.

Ruby on Rails specifically has a batteries included approach that lets you get up and running very quickly. But my perception is that as JavaScript has leaked into the server (benefits of writing the same language on front and back end) it's eaten into Ruby's mindshare. Python also finally moved on from its 2 vs 3 nightmare and shares many of the benefits of Ruby.

Ruby on Rails is still very much alive and well.

https://news.ycombinator.com/item?id=43130546

https://news.ycombinator.com/item?id=43881035

https://news.ycombinator.com/item?id=42253735

and more: https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...

Use whatever you feel most effective in. I would say Ruby is around much more than you might expect by the sounds of it. (The usual big names touted on the Rails homepage + many start ups + agency products) though it's definitely over the hype period.

For being employable... I'd say Ruby is going to be near the middle of the pack. Elixir is going to be near the harder-side, and JS is going to be near the easier-side... on average IMO.

If you think ruby intrigues you, give it a try! You've got precious time + motivation for this sort of thing, but messing around with a programming language is not much effort if you're intrigued. Getting a feel for it is a sub-weekend project away. It's my favourite language for bodging, the scripts I make in ruby for little data-mashing or system things are surprisingly stable and readable, even a year or two later. (Compared to a nodejs, perl or shell script... which all tend to have understandability-half-lives of a month for me haha) Automate something you find annoying.

As much as I enjoy using Elixir, I’m not sure at the moment learning Elixir over Ruby gives more options for being hired.

Open any “Who is hiring” and compare number of Elixir positions vs Ruby.

Rails/Ruby is still top 10 on Github landscape in Pull Requests. Though it's lived through a relative decline people talk about it less because a lot of other frameworks and languages have improved in light of what the ecosystem had.

That said I feel like Elixir/Phoenix is doing a lot of things right today and if I were invested in one or the other I'd stick with that one. But I'm more of a bootstrapper than someone who looks for a job. Ruby is #8 in Pull Requests and Elixir #24 on Github. Source: https://madnight.github.io/githut/#/pull_requests/2024/1

If I were just looking to be marketable I'd consider Python, Java or Go... but I don't love working in those languages as much as I do Ruby (or Elixir for that matter).

Learning a new language makes you more employable, not less :)

lolwut?