Ruby has a lot going for it, but as other commenters point out, the metaprogramming nightmares of the language have held it back 10-30 years behind modern language ecosystems, depending on the feature you're looking at. Celebrating "jump to source definition" (sometimes working) for such a mature language is a symptom of the nature of the language. Sometimes insane dynamic freedom is really useful, but it comes with heavy drawbacks.

The fact IntelliSense and jump-to-source are supported at a very superficial level goes to show the heavy drawbacks of dynamic types.

Sorbet may fix things, but at that point, just use a language with more mature tooling around types, like Python or TypeScript.

Dynamic types offer dubious marginal benefits but bring tons of downsides. The demonstrations in this article reflect that.

I was tired of feeling slowed down by grepping in large Ruby code, and the artificial boundary gems create requiring a `bundle open` to keep digging. I created my own Ruby LSP to solve these problems: https://github.com/pheen/fuzzy_ruby_server

I think it works well, is stable, and I would still reach for it over Shopify's LSP personally. Feel free to use it! Though as a heads up, I don't work in Ruby much anymore unfortunately so I'm not actively working on it or accepting issues.

I used to work at a Ruby shop. As a language, Ruby can be elegant despite the overall weirdness, and some of my coworkers were really productive with it.

On the other hand, the Ruby community seems stuck in the 2000s, with some of the self inflicted Ruby pains and attitude being fairly similar to what some Python devs were doing in the late Python 2 era.

These days, I still like Ruby and I would enjoy building some little project with it, but I would rather make a living using other stuff.

How does this compare to the JetBrains solution?

Ruby is nice, I just find the DX to be far behind the other languages. Like code completion is barely working.

I'm aware of the limitations of a dynamic language in terms of the looking up references and implementations of types/functions.

For everyone commenting about those and who haven't, I suggest trying RubyMine to set expectations on what is possible first.

Rubymine is the only editor I’ve ever used that gets the code navigation consistently right without any config. You can even navigate to dependency implementations. It’s invaluable with understanding really large code bases.

Excited to try this to see if it measures up.

I started a small service recently in rails. I'm forcing sorbet with typechecking (you can still set things to false like tests which sometimes are a pain to get to pass). It feels almost like a typed language with LSP jump to etc. It's getting there.

One drawback of Ruby code completion is that it tends to require partial execution of code that may contain side-effects, and this is inherently dangerous.

Writing my own Ruby code is fine but debugging others code is a PITA.

Possibly off topic:

"Look up the source" in 2024 is a symptom of a wider problem. Ruby was innovative in the 1990s but it is starting to fall behind the times.

Those of us who are old enough to remember the euphoria that greeted the release of Ruby on Rails in 2004 are mostly surprised to see Ruby's current, limited market share. There was a moment when it seemed like Ruby was going to sweep the whole world of software. But that didn't happen. The mutability that made Ruby so fun also makes it difficult to maintain Ruby codebases over the long-term.

For awhile Ruby seemed relevant in fields beyond Web development, such as devops. I recall 12 years ago a startup tried to recruit me, they were going to revolutionize devops by building automations for Chef. But the metaprogramming in Ruby made it less than ideal for devops work. That startup failed. In most places I now work, a combination of Ansible and Terraform dominate, save where the company uses the constellation of tools surrounding Kubernetes to manage everything. The places that use Chef have been using Chef for 15 years, no new company chooses Chef today.

There was a stretch after 2004 when Ruby was trying to break into new areas. GTK bindings for Ruby were developed and some people experimented with desktop Ruby. But that never took off.

Many of us who loved the metaprogramming in Ruby, but wanted a better structure for that metaprogramming, moved on to other languages such as Clojure.

Some of us loved Ruby because it allowed easier polymorphism than Java did -- after all, you could use higher order functions to produce functions, but without having all the ceremony of building a Factory. But folks who just wanted the polymorphism of functions returning functions eventually moved to NodeJS.

Ruby always felt fluid and magical in a way that made it seem vaguely unsuitable for data science, and eventually Python came to dominate data science.

The Ruby community witnessed the conflict between Rails and Merb, and their eventual union, and eventually Rails became a comfortable framework for quickly generating an API. But for anything that needs high levels of write throughput, no one would chose Ruby, and so other languages have taken some of the market share.

Even on the Web, some big companies (Twitter, AirBnB) either gave up on it completely, or now only use it for templating the frontend, or offering an API to support the frontend. For backend processing, many companies have moved away from it.

In short, Ruby has been losing market share for awhile. In some fields, such as devops, where it used to be competitive, it has almost completely disappeared. It survives only in Web development, and only because of Rails.

None of this can be very inspiring for Ruby developers.

[dead]