I feel like this is a solution to a problem nobody really has in practice, by simply following conventions, and I've been using Ruby for over 10 years. If byroot -- who works at Shopify on the largest Rails codebase in existence -- echos the same sentiment, then maybe it should be scrapped.
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.
They didn't say where it was deployed. I'd often only test some changes in staging rather than locally, because they rely on some specific other service I don't want to spend time setting up. It's very common.
Typically with rails applications, test dependencies are not used for local development (i.e. running the rails server on your local machine), they are separate groups in the Gemfile.
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 used Ruby a lot a long time ago and built medium to large scale enterprise apps on the Rails framework before I moved on to other projects involving Golang and Elixir. Somehow I had more fun and more safety working with Elixir, which was only just getting started as a brand new language trying to establish itself.
It was only after working with Go that I realized how much compile-time safety and performance I was missing out on with Ruby.There's no doubt I would use Ruby today again, but I can't imagine going further beyond simple scripts and workflows. I have recently tried building a very small website with Rails, and I was somewhat surprised the framework did not mature all that much, and type safety and IDE support still seem to be iffy. There is so much unwanted magic that I still see with Ruby on Rails in general. I was looking up to Crystal to address some of the issues I described above, but unfortunately it just remained as a less mature language. Elixir was great, but with the experience I have had, I will actually drop heading into the functional programming world. That leaves me with only one choice, which is Golang. I am not a fan of everything it has, but it is fairly easy for my fellow engineers to pick up, and the IDE support has been nothing short of fantastic.
This is really really a big stretch, but I have always been hopeful towards looking for a TypeScript sort of compile-time layer for Ruby. It may probably never happen though, sadly.
Sorbet helps. We’ve even created a typed HTML template engine and it helps catch a lot but also allows using the Sorbet LSP to rename things and of course correct autocomplete.
> I was looking up to Crystal to address some of the issues I described above, but unfortunately it just remained as a less mature language.
I'd be interested to hear what you find lacking in Crystal, too. For me it would be editor support, last time I tried the LSP I couldn't get it to work.
Last time I checked I heard the compile times were still awful. And the entire community lacking some basic packages and enough developers that it still made it hard to find support or help for issues one may encounter.
Compile times seem fine to me, compared to other code I've compiled. I haven't noticed a particular basic package that's missing either, but that may depend on who is asked. I've also had reasonable responses from the existing devs, it feels more like Ruby in the late 2000's (friendlier, less political).
> but with the experience I have had, I will actually drop heading into the functional programming world
Could you elaborate on this? It's a valid resolution, but I consider Elixir to be on the pragmatic side of the functional paradigm, so I'm wondering what pushed you away.
Sure, this was a few years ago.
Don't get me wrong, I liked it, but all the other existing and new engineers on my team have expressed a lot of concern about the entire paradigm shift and that Elixir was unnecessarily complicating things in terms of implementing simple logic.
A lot of junior engineers also have been unhappy with the kind of shift going away from the traditional procedural/oop styles.
If I was working on a solo project, I would pick Elixir over Rails any day. The LSP server and tooling alone makes it stand up very strong.
Almost every recent (in years) Ruby feature is not a novel idea. Even the origin was a Perl/Smalltalk/Lisp crossover so the axioms were pretty well known.
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.
I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
> Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing.
I'd like to hear of a real use case for namespaces that existing conventions don't already solve.
Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>".
Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing:
module MyGroup
include Module1
include Module2
...
end
In other words, wrapping them doesn't remove your ability to use short non-namespaced names.
Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace
For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby:
def wrap_load(path) = class_eval(File.read(path), path)
module Test
# some_file.rb will act as-if defined within Test
wrap_load("./some_file.rb")
end
You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies.
Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.
Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new.
And why would you bother doing that when it would be a breaking change?
On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
>Avoiding name conflicts between libraries: Applications can require two different libraries safely which use the same module name.
>
>Is this a problem that happens on a regular basis? I believe Ruby has a pretty well established convention for libraries to expose a single module with a name that correspond to their gem name.
I really don't think we want to make it easier for newbies to alter gem naming conventions and run multiple versions of a gem within the same project, this sounds like a genuine nightmare to me. I've found from jumping in to fix broken and crippled rails projects for startups that the fuckup surface area is already high enough.
I've been working with Ruby full time for pretty much 20+ years as well and there's many parts of it I've never used, although when I need one of it's many features, I love that it's there. I just used a refinement for example last month for the first time to help clean up some code that I didn't want polluting top level classes everywhere.
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
Shopify would benefit a ton from "some" namespaces. In a way, packwerk[0] was an attempt at bringing some namespaces benefits.
But I don't personally think Shopify would benefit from this specific implementation of namespaces (a couple colleagues do). I'm personally not even sure Namespace is a proper term to describe that feature. It's more some sort of lightweight sandboxing to me.
Also:
> They have so many expert Ruby devs
If anything, the average Ruby expertise at Shopify is likely noticeably lower than in most Ruby/Rails shop.
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.
Can you expound a bit more? It seems like Pay encapsulates itself pretty well. I'm not sure I really grok how namespaces could improve or fix whatever is broken here.
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.
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.
Having upgraded one large and two small applications in the last few years, this is not my experience. Even without YJIT, just upgrading to Ruby 3.2 and beyond saw performance improvements over the same application on 2.7.
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.
That's only during runtime. Simply reading code can be annoyingly difficult without hard references. Especially when the code is coming from a gem.
Many times LSP's can't figure out where the code is coming from if it's a few layers deep. Then you're stuck with the time consuming method of running the code and doing something like what you're describing above just to read it.
As someone who has no idea how Ruby works, how does Emacs show where any function is defined, right down to line number? Emacs has a big mudball of single namespace too
I see a lot of comments here asking about practical motivations for this feature. One I'll share is that in a gem I help maintain, we benchmark git branches of the gem against `main`, and we also benchmark against multiple other gems that sometimes have namespace collisions with each other. To make this work, we use a third-party gem[0] and an anonymous module trick[1] that are each a bit hacky.
That being said, I have no particular stance on whether this feature is a good change to the language; in a decade of Ruby this is the only situation I can recall that really merited it, and the concerns articulated by byroot and others do resonate with me.
I've been happy with some of the great improvements to Ruby in the past year. But this one really leaves me scratching my head. It seems like a lot of complexity for what I perceive as a negative value feature. I'm concerned about damage to the gem ecosystem by encouraging gems to bundle version locked dependencies. The last thing I want is a gem deciding to have multiple versions of other gems in my app.
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.
This is a really interesting feature addressing something Ruby has long-lacked.
But I think the more interesting story is the widespread opposition to the way this was forced through in spite of major conceptual problems, bugs and performance regressions.
I remember Matz gave a presentation touching on how Ruby was inspired by Lisp and particularly Emacs Lisp, which was the one he had access to. You still can feel a similarity up to now, with the single big old dynamic namespace where you can monkey-patch anything if you feel like it.
This post (2019) by David Bryant Copeland about npm security goes into some of the complications that arise when multiple versions of a dependency are allowed to be loaded simultaneously:
To add to my other comments ITT, I was thinking how the proposed name-spacing in Ruby would work is, in one way, diametrically different from Go where you'd normally import a package with the name that was chosen by the package author. But, at the same time, you could choose to import it under a different name or with no namespace at all, using the dot prefix. I'm not sure which is better. I suppose I could agree Go has a better default when it comes to namespaces.
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
First the Data class and now this, very interesting to see! Is there any certain use case where this is well suitable? Because we already have Modules and from my understanding, can be used to namespace things. Or is the appeal here that you can perform the namespacing dynamically through ”require”?
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.
Ok, understood. This being into account, would it not even better to make the most obvious way to code some logic most likely shaped without this issue in the first place.
Because, if the external dependency smells that bad, what the root cause? If that is crap code produced thus for some reason (unskilled/over-time-bound-pressured person for example), then probably this is better to avoid using this code altogether. And if this is instead because the language encourage easy path with bad outcomes, then it might make more sense to make a proposal with a facility to instead make the path of least resistance be something of more enjoyable outcome.
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.
> if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere
It will be identified as such by e.g. the default `inspect`, but nothing stops you from `include`-ing MyModule into another module or class, or even the global scope so that you can reference MyClass without MyModule.
I'm against this because it will be abused, and cause chaos vis-a-vis well-established conventions in the Ruby world.
The example given in the ticket, defining a global constant PORT in the root namespace and then loading it separately into two apps--nobody actually does in Ruby this today, because it is well-known that it will cause conflicts. Any gem (Ruby library) that did this sort of thing has long-since been barked at and corrected--the solution is simply to nest the constant inside your main module e.g. MyGem::PORT.
Now, gems will be free to define whatever constants/modules/etc. they want. When someone files an issue, the response can be: "Oh you don't like that I redefined Array? Load my gem in a namespace!"
In the micro, this is definitely a useful crutch for using badly-written/badly-behaved code.
(In the example, it usefully provides a way to maintain sanity when `app1.rb` and `app2.rb` both define a global constant named `PORT`)
However, I'm not sure how much existing code is defining stuff in such a poorly considered way. (I don't mean that rhetorically. Maybe it's more pervasive than I think)
Furthermore, would adding this feature to the language actually encourage such bad behavior? (Would it even be "bad" behavior at that point?)
So I'm kind of leaning toward "I can see how this would be useful, but I don't want the language to condone such a bad practice."
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.
Honestly after 15 years in ruby, changes like this always make me wonder who they're for. Saw way more value in the old-school simplicity - you ever feel like new language features just pile on more headaches than they fix?
I know Ruby is still used in some codebases but what's its actual relevance in the webdev/fullstack landscape? I am currently 5 months into learning Elixir/Phoenix for fullstack and I already know a few Js based frameworks. Ruby always intruiged me, but I'd like to stay employable
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.
Yea, I am tackling Elixir to avoid learning tech specifically designed for solving scaling issues with languages not made for scaling. Elixir is wonderful for this. How's Ruby considering scaling and performance? I always compare Ruby on Rails to Laravel for some reason
I did Ruby on rails professionally for many years, and have also done elix Phoenix professionally for many years now, and I would advise you to continue with Phoenix. Getting really good at elixir and Phoenix can make you an extremely powerful and employable developer. Should you find yourself in a situation where you need to switch to Ruby and rails, you will have a huge leg up because rails follow as many of the same patterns as Phoenix, and the Ruby language is very simple to learn for someone coming from elixir. Just my two cents of course
that's great advice, but finding Elixir/Phoenix jobs seems to be few and far between (and seem to be for less pay). Where are you able to find your Elixir / Phoenix jobs?
You typically choose Ruby on Rails because you want to get up and running fast, not because you want performance. That said, in most RoR codebases the performance bottleneck is networking, database etc not the language itself. As and when e.g. the database becomes a bottleneck there are various mitigations available to you.
In a way, Rails is the OG for rapid application development considering its influence and impact on tech startups over the 2010s.
These days you'd build a blog in 20 minutes by vibe coding it in Cursor and deploying it on to some serverless edge compute platform or something.
Almost 20 years ago you'd build a blog in 20 minutes by installing rails and running a few commands on the terminal to generate the UI, backend, DB schema/migrations and all that, and then `git push heroku master` to see it deployed on the web. Quickly enough you'd git gud and wouldn't need to lean on the scaffolding tools.
At least in London there's still a pretty strong market for it, and the overlap in syntax between Ruby and Elixir is enough that you could take your pick (the Elixir shops I know of will look for experienced Ruby engineers by default because the pool of Elixir engineers is much smaller).
Could you point out where do you get your data from? Anything to back-up your claims that Rails is in decline and Elixir/Phoenix is growing? For a time not long ago I was heavily into looking for an Elixir gig, but couldn't really find offers, while there were still tons of offers for Rails development.
You scale Rails by adding servers (or containers) behind a load balancer and by scaling up the database server in the same ways you would do it for another server technology, including Phoenix.
By the way, I've seen many more Rails projects than Phoenix ones but they share the same general architecture: (server or containers) + db. The only difference is that we usually run Ruby jobs inside sidekiq and we use Tasks or GenServers for Elixir jobs. We wrote our own code to restart and try again jobs that eventually failed (we can't lose a job because of a deploy or a reboot.)
Yes, Redis is usually the backing store for Rails' Sidekiq.
With Elixir we stored the job data in a PostgreSQL table and started a process with the id of that record as argument.
When we had to restart the BEAM (deploy, reboot, anything) a process would look at that table and start a process for every record not marked as complete. If a process failed too many times and its supervisor gave up on it, we could restart it manually by calling a function in the console with the record id as argument. Or we could start all the processes of a given type at once, or all of them.
So we basically wrote a small subset of Redis and of Sidekiq admin.
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.
We actually use Prawn PDF at work so I have soooome degree of contact to Ruby already, I might check it out at some point. Thanks for the detailed answer!
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).
As someone who can't stand Ruby, I am personally against this feature. I'd rather have my Ruby experience universally miserable, with no deception, instead of having, say, half of the language decent and sane, and another half, well, be traditional Ruby.
Edit: apparently, people who do love Ruby are also against this feature, for roughly the same reasons. Kinda funny, but entirely reasonable in hindsight.
I feel like this is a solution to a problem nobody really has in practice, by simply following conventions, and I've been using Ruby for over 10 years. If byroot -- who works at Shopify on the largest Rails codebase in existence -- echos the same sentiment, then maybe it should be scrapped.
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/...
Very helpful example.
`diff-lcs` no longer uses `ostruct` as of 1.6.0 (granted, that was released in February).
Does that mean you develop code without running it locally?
The first execution of new code is in CI?
They didn't say where it was deployed. I'd often only test some changes in staging rather than locally, because they rely on some specific other service I don't want to spend time setting up. It's very common.
Locally you’d have all the dependencies installed. In production you’d leave out development and test dependencies.
Typically with rails applications, test dependencies are not used for local development (i.e. running the rails server on your local machine), they are separate groups in the Gemfile.
Spring and bootsnap muddy the waters. You do not have hermetic dev and test environments in Rails.
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 used Ruby a lot a long time ago and built medium to large scale enterprise apps on the Rails framework before I moved on to other projects involving Golang and Elixir. Somehow I had more fun and more safety working with Elixir, which was only just getting started as a brand new language trying to establish itself.
It was only after working with Go that I realized how much compile-time safety and performance I was missing out on with Ruby.There's no doubt I would use Ruby today again, but I can't imagine going further beyond simple scripts and workflows. I have recently tried building a very small website with Rails, and I was somewhat surprised the framework did not mature all that much, and type safety and IDE support still seem to be iffy. There is so much unwanted magic that I still see with Ruby on Rails in general. I was looking up to Crystal to address some of the issues I described above, but unfortunately it just remained as a less mature language. Elixir was great, but with the experience I have had, I will actually drop heading into the functional programming world. That leaves me with only one choice, which is Golang. I am not a fan of everything it has, but it is fairly easy for my fellow engineers to pick up, and the IDE support has been nothing short of fantastic.
This is really really a big stretch, but I have always been hopeful towards looking for a TypeScript sort of compile-time layer for Ruby. It may probably never happen though, sadly.
Sorbet helps. We’ve even created a typed HTML template engine and it helps catch a lot but also allows using the Sorbet LSP to rename things and of course correct autocomplete.
> I was looking up to Crystal to address some of the issues I described above, but unfortunately it just remained as a less mature language.
I'd be interested to hear what you find lacking in Crystal, too. For me it would be editor support, last time I tried the LSP I couldn't get it to work.
Last time I checked I heard the compile times were still awful. And the entire community lacking some basic packages and enough developers that it still made it hard to find support or help for issues one may encounter.
Compile times seem fine to me, compared to other code I've compiled. I haven't noticed a particular basic package that's missing either, but that may depend on who is asked. I've also had reasonable responses from the existing devs, it feels more like Ruby in the late 2000's (friendlier, less political).
> but with the experience I have had, I will actually drop heading into the functional programming world
Could you elaborate on this? It's a valid resolution, but I consider Elixir to be on the pragmatic side of the functional paradigm, so I'm wondering what pushed you away.
Sure, this was a few years ago. Don't get me wrong, I liked it, but all the other existing and new engineers on my team have expressed a lot of concern about the entire paradigm shift and that Elixir was unnecessarily complicating things in terms of implementing simple logic. A lot of junior engineers also have been unhappy with the kind of shift going away from the traditional procedural/oop styles. If I was working on a solo project, I would pick Elixir over Rails any day. The LSP server and tooling alone makes it stand up very strong.
Almost every recent (in years) Ruby feature is not a novel idea. Even the origin was a Perl/Smalltalk/Lisp crossover so the axioms were pretty well known.
Yea generally agree with this take. Feels like we’re getting features shoehorned in.
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.
I disagree. I've also been working with Ruby for almost 20 years and quite a few times I came across a situation where I definitely wanted to wrap my library in a module for name-spacing and it was almost always cumbersome. I'd rather not wrap it and let others (or myself) use the library name-spaced under whatever name they choose. Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
> Right now, if you're working on a gem, you have to think really hard how to name it so its top-level classes an modules don't conflict with any other modules and classes found in the Ruby ecosystem.
Follow gem naming conventions and this is a non-issue -- both FooBar::Record and BazQux::Record can coexist for foo_bar and baz_qux gems, respectively. If a gem is defining other top-level constants outside of their gem module, then that's considered against convention, i.e. bad practice, and the language should not be modified to allow such a thing.
I'd like to hear of a real use case for namespaces that existing conventions don't already solve.
Wrapping `Record` in `Foobar` or `BazQux` is just not a good pattern, even if it's common place and is included in current guidelines. Most of the time, you don't have gems that would use the same class and thus would rather not type a long name-spaced name every time you want to use `Record`. But when you do have gems with conflicting classes, you'd have the power to wrap one of them or both in a short namespace identifier and be in charge of the naming. Using modules for wrapping is a pattern currently, but modules should primarily be used for mixins, not name-spacing.
If you don't have a conflict, and the module is wrapping everything, nothing stops you from doing "include <yourmodule>".
Similarly, if you want to group modules that don't conflict together under a short module name, nothing stops you from doing:
In other words, wrapping them doesn't remove your ability to use short non-namespaced names.Using `include` of specific functionality into a class that will use it is furthermore an idiomatic way of avoiding that extra typing without polluting the global namespace
For that matter, you can often achieve close to what you're arguing for as well without actually making any changes to Ruby:
You can do better than that, to get closer to emulate `require` rather than `load`, and handle dependencies.Overall, I think the fact you can do these things suggests you could probably write a good enough plug-in `require` monkeypatch suitable for the rare cases where `include` from within a class or module without needing a language extension.
What's the difference between FooBar::Record and ns1::Record? Nothing, except the latter pushes encapsulation onto the user.
This is not the Ruby ethos.
Realistically it would be FooBar::Record and ns1::FooBar::Record too, unless gems start replacing their top level module FooBar with FooBar = Namespace.new.
And why would you bother doing that when it would be a breaking change?
On a purely syntactic level snake_case gives me a clear indication this is something different (not a module). But the underlying mechanics of how namespaces would work, as I've mentioned in another comment, is that the choice of picking namespace identifiers is shifted to users of gems/libraries. I think the proposal might further benefit from maybe giving libraries default namespaces and, for example, Go does exactly this: you can import a package with the namespace prefix defined by package author, but you can also change it or import it without a namespace prefix at all.
I think byroot got it exactly right with:
>First, I'm not convinced by the motivations:
>
>Avoiding name conflicts between libraries: Applications can require two different libraries safely which use the same module name.
>
>Is this a problem that happens on a regular basis? I believe Ruby has a pretty well established convention for libraries to expose a single module with a name that correspond to their gem name.
I really don't think we want to make it easier for newbies to alter gem naming conventions and run multiple versions of a gem within the same project, this sounds like a genuine nightmare to me. I've found from jumping in to fix broken and crippled rails projects for startups that the fuckup surface area is already high enough.
I've been working with Ruby full time for pretty much 20+ years as well and there's many parts of it I've never used, although when I need one of it's many features, I love that it's there. I just used a refinement for example last month for the first time to help clean up some code that I didn't want polluting top level classes everywhere.
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
Shopify would benefit a ton from "some" namespaces. In a way, packwerk[0] was an attempt at bringing some namespaces benefits.
But I don't personally think Shopify would benefit from this specific implementation of namespaces (a couple colleagues do). I'm personally not even sure Namespace is a proper term to describe that feature. It's more some sort of lightweight sandboxing to me.
Also:
> They have so many expert Ruby devs
If anything, the average Ruby expertise at Shopify is likely noticeably lower than in most Ruby/Rails shop.
[0] https://github.com/Shopify/packwerk
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!
Can you expound a bit more? It seems like Pay encapsulates itself pretty well. I'm not sure I really grok how namespaces could improve or fix whatever is broken here.
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.
You can see Ruby core perf improvements at the link below, going back 4-years.
Even though this is from the YJIT folks, they include the non-jit improvements as a comparison.
https://speed.yjit.org/history.html
Having upgraded one large and two small applications in the last few years, this is not my experience. Even without YJIT, just upgrading to Ruby 3.2 and beyond saw performance improvements over the same application on 2.7.
Huh? How is 2.7 the fastest ? There have been tons and tons of major performance gains since then, even without getting into yjit
I wish ruby went with hard/explicit imports like python or js.
Solves this problem and "magic" that so many complain about while retaining all the other great things to love about Ruby.
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.
Use the `method` method to get a reference to the one you are concerned with, then call `source_location` on it.
That's only during runtime. Simply reading code can be annoyingly difficult without hard references. Especially when the code is coming from a gem.
Many times LSP's can't figure out where the code is coming from if it's a few layers deep. Then you're stuck with the time consuming method of running the code and doing something like what you're describing above just to read it.
As someone who has no idea how Ruby works, how does Emacs show where any function is defined, right down to line number? Emacs has a big mudball of single namespace too
And even good type checkers can't infer every symbol statically where Python/JS has no issue with it.
I mean, nothing is stopping you from doing something like:
Ew. No.
I see a lot of comments here asking about practical motivations for this feature. One I'll share is that in a gem I help maintain, we benchmark git branches of the gem against `main`, and we also benchmark against multiple other gems that sometimes have namespace collisions with each other. To make this work, we use a third-party gem[0] and an anonymous module trick[1] that are each a bit hacky.
That being said, I have no particular stance on whether this feature is a good change to the language; in a decade of Ruby this is the only situation I can recall that really merited it, and the concerns articulated by byroot and others do resonate with me.
[0] https://github.com/panorama-ed/memo_wise/blob/main/benchmark... [1] https://github.com/panorama-ed/memo_wise/blob/main/memo_wise...
I've been happy with some of the great improvements to Ruby in the past year. But this one really leaves me scratching my head. It seems like a lot of complexity for what I perceive as a negative value feature. I'm concerned about damage to the gem ecosystem by encouraging gems to bundle version locked dependencies. The last thing I want is a gem deciding to have multiple versions of other gems in my app.
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.
This is a really interesting feature addressing something Ruby has long-lacked.
But I think the more interesting story is the widespread opposition to the way this was forced through in spite of major conceptual problems, bugs and performance regressions.
Identifying it as an experimental feature (disabled by default) seems like a reasonable way to make progress and iron out any problems.
I remember Matz gave a presentation touching on how Ruby was inspired by Lisp and particularly Emacs Lisp, which was the one he had access to. You still can feel a similarity up to now, with the single big old dynamic namespace where you can monkey-patch anything if you feel like it.
Even this proposed feature is very similar to Common Lisp packages.
If video exists of the presentation, would love to see it.
This post (2019) by David Bryant Copeland about npm security goes into some of the complications that arise when multiple versions of a dependency are allowed to be loaded simultaneously:
https://naildrivin5.com/blog/2019/07/10/the-frightening-stat...
To add to my other comments ITT, I was thinking how the proposed name-spacing in Ruby would work is, in one way, diametrically different from Go where you'd normally import a package with the name that was chosen by the package author. But, at the same time, you could choose to import it under a different name or with no namespace at all, using the dot prefix. I'm not sure which is better. I suppose I could agree Go has a better default when it comes to namespaces.
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:
I think in a way it's similar to ShadowRealm in JavaScript. https://github.com/tc39/proposal-shadowrealm/blob/main/expla...
First the Data class and now this, very interesting to see! Is there any certain use case where this is well suitable? Because we already have Modules and from my understanding, can be used to namespace things. Or is the appeal here that you can perform the namespacing dynamically through ”require”?
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.
Namespace isolates monkey patches.
>I'm curious if this namespace mechanism could, say, isolate monkey patches.
Wasn't that the purpose of refinements? Perhaps I am misremembering, because I never had a need to reach for refinements myself.
You still need to rely on the library maintainers to use them. This mechanism allows you to sandbox a library that doesn't.
Ok, understood. This being into account, would it not even better to make the most obvious way to code some logic most likely shaped without this issue in the first place.
Because, if the external dependency smells that bad, what the root cause? If that is crap code produced thus for some reason (unskilled/over-time-bound-pressured person for example), then probably this is better to avoid using this code altogether. And if this is instead because the language encourage easy path with bad outcomes, then it might make more sense to make a proposal with a facility to instead make the path of least resistance be something of more enjoyable outcome.
Proper namespaces are a good thing to have regardless. Relying on gem maintainers to not pollute the main namespace was always suboptimal.
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.
> if I use modules for name-spacing, it will always be "MyModule::MyClass" everywhere
It will be identified as such by e.g. the default `inspect`, but nothing stops you from `include`-ing MyModule into another module or class, or even the global scope so that you can reference MyClass without MyModule.
I'm against this because it will be abused, and cause chaos vis-a-vis well-established conventions in the Ruby world.
The example given in the ticket, defining a global constant PORT in the root namespace and then loading it separately into two apps--nobody actually does in Ruby this today, because it is well-known that it will cause conflicts. Any gem (Ruby library) that did this sort of thing has long-since been barked at and corrected--the solution is simply to nest the constant inside your main module e.g. MyGem::PORT.
Now, gems will be free to define whatever constants/modules/etc. they want. When someone files an issue, the response can be: "Oh you don't like that I redefined Array? Load my gem in a namespace!"
Do we really need a new “code container” type for this? Could modules not serve the purpose by localizing require. e.g.
So everything bar.rb loads in safely within Foo?this would be a major breaking change
In the micro, this is definitely a useful crutch for using badly-written/badly-behaved code.
(In the example, it usefully provides a way to maintain sanity when `app1.rb` and `app2.rb` both define a global constant named `PORT`)
However, I'm not sure how much existing code is defining stuff in such a poorly considered way. (I don't mean that rhetorically. Maybe it's more pervasive than I think)
Furthermore, would adding this feature to the language actually encourage such bad behavior? (Would it even be "bad" behavior at that point?)
So I'm kind of leaning toward "I can see how this would be useful, but I don't want the language to condone such a bad practice."
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 call that some pretty bad behavior; behavior that I'd like to... if not dissuade, at least not encourage.
Namespaces are one honking great idea -- let's do more of those!
Honestly after 15 years in ruby, changes like this always make me wonder who they're for. Saw way more value in the old-school simplicity - you ever feel like new language features just pile on more headaches than they fix?
[dead]
I know Ruby is still used in some codebases but what's its actual relevance in the webdev/fullstack landscape? I am currently 5 months into learning Elixir/Phoenix for fullstack and I already know a few Js based frameworks. Ruby always intruiged me, but I'd like to stay employable
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.
Yea, I am tackling Elixir to avoid learning tech specifically designed for solving scaling issues with languages not made for scaling. Elixir is wonderful for this. How's Ruby considering scaling and performance? I always compare Ruby on Rails to Laravel for some reason
I did Ruby on rails professionally for many years, and have also done elix Phoenix professionally for many years now, and I would advise you to continue with Phoenix. Getting really good at elixir and Phoenix can make you an extremely powerful and employable developer. Should you find yourself in a situation where you need to switch to Ruby and rails, you will have a huge leg up because rails follow as many of the same patterns as Phoenix, and the Ruby language is very simple to learn for someone coming from elixir. Just my two cents of course
that's great advice, but finding Elixir/Phoenix jobs seems to be few and far between (and seem to be for less pay). Where are you able to find your Elixir / Phoenix jobs?
Will follow this advice then, thanks for letting me know!
You typically choose Ruby on Rails because you want to get up and running fast, not because you want performance. That said, in most RoR codebases the performance bottleneck is networking, database etc not the language itself. As and when e.g. the database becomes a bottleneck there are various mitigations available to you.
In a way, Rails is the OG for rapid application development considering its influence and impact on tech startups over the 2010s.
These days you'd build a blog in 20 minutes by vibe coding it in Cursor and deploying it on to some serverless edge compute platform or something.
Almost 20 years ago you'd build a blog in 20 minutes by installing rails and running a few commands on the terminal to generate the UI, backend, DB schema/migrations and all that, and then `git push heroku master` to see it deployed on the web. Quickly enough you'd git gud and wouldn't need to lean on the scaffolding tools.
At least in London there's still a pretty strong market for it, and the overlap in syntax between Ruby and Elixir is enough that you could take your pick (the Elixir shops I know of will look for experienced Ruby engineers by default because the pool of Elixir engineers is much smaller).
20 minutes? Who’s got time for that?
The original DHH demo video[1], from 19 years ago, was a blog in 15 minutes.
AI is clearly rubbish! :P
1. https://m.youtube.com/watch?v=Gzj723LkRJY
Shopify, GitHub, Intercom, among others are built on Ruby/Rails. I think it'll scale fine.
> How's Ruby considering scaling and performance?
Shopify, Github, AiBnB, Square, Instacart, etc...
There's more big apps/websites using Rails than Elixir or Phoenix...
> There's more big apps/websites using Rails than Elixir or Phoenix...
Sure, but thats a weak argument considering Ruby on Rails is considerably older than Phoenix and adoption is in decline while Phoenix grows.
Could you point out where do you get your data from? Anything to back-up your claims that Rails is in decline and Elixir/Phoenix is growing? For a time not long ago I was heavily into looking for an Elixir gig, but couldn't really find offers, while there were still tons of offers for Rails development.
It's proof that it works. The things exist.
You scale Rails by adding servers (or containers) behind a load balancer and by scaling up the database server in the same ways you would do it for another server technology, including Phoenix.
By the way, I've seen many more Rails projects than Phoenix ones but they share the same general architecture: (server or containers) + db. The only difference is that we usually run Ruby jobs inside sidekiq and we use Tasks or GenServers for Elixir jobs. We wrote our own code to restart and try again jobs that eventually failed (we can't lose a job because of a deploy or a reboot.)
Well most Javascript based apps ive seen utilize stuff like Redis for scaling, this for example isn't needed with Elixir.
Yes, Redis is usually the backing store for Rails' Sidekiq.
With Elixir we stored the job data in a PostgreSQL table and started a process with the id of that record as argument.
When we had to restart the BEAM (deploy, reboot, anything) a process would look at that table and start a process for every record not marked as complete. If a process failed too many times and its supervisor gave up on it, we could restart it manually by calling a function in the console with the record id as argument. Or we could start all the processes of a given type at once, or all of them.
So we basically wrote a small subset of Redis and of Sidekiq admin.
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.
We actually use Prawn PDF at work so I have soooome degree of contact to Ruby already, I might check it out at some point. Thanks for the detailed answer!
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 :)
Oh I already consider myself a Polyglot, I just need tools that make building fun. I try to leave Js frameworks in my private projects
As someone who can't stand Ruby, I am personally against this feature. I'd rather have my Ruby experience universally miserable, with no deception, instead of having, say, half of the language decent and sane, and another half, well, be traditional Ruby.
Edit: apparently, people who do love Ruby are also against this feature, for roughly the same reasons. Kinda funny, but entirely reasonable in hindsight.
lolwut?