I don’t really think it’s so much that Ruby has declined in popularity (although Rails has), but that Python has exploded as it moved from Academia into data science and ML which are really big right now.

Ruby only ever has one big ecosystem (web development), whereas Python has expanded into several.

But Ruby isn’t going anywhere, so no need to be sad. It’s still a joyful scripting language, and its community is alive and well :)

I used to watch rubygems.org rss to keep myself in the loop. Nowadays it is a deserted wasteland. Many previously popular gems never updated and thus do not work on newer versions of ruby.

I still think Ruby is the more interesting and expressive language. However, for me there's a single pain point that means Python wins in any larger project. That is the behaviour of Python's "import" vs. Ruby's "require". So it's not surprising that this distinction between these languages pops up all over the place. Python tries to be as explicit as possible. While "from import *" is possible it is heavily frowned upon. The Ruby culture doesn't seem to have such qualms; things are often much more hidden and magical. It can make navigating larger projects... even your own... difficult and inefficient.

I can echo this sentiment. I want to love Ruby, but when I work in project in it, I eventually get to point where I have trouble finding where something is defined, which wastes my time — and in general, to your point, it’s harder to find where anything that’s getting pulled into a file is defined. Unfortunately, this dynamism is a concept in Ruby that is part of the reason why it’s so great.

However, recently I started a project with Ruby, thanks to language servers. I’m hoping this solves that issue, but it’s too soon to say.

There’s still other issues with the require mechanism, and Ruby in general, and other languages to try, e.g. Elixir and Crystal. I haven’t been sold yet in terms of what Ruby excels at, and those languages are each different in their own right.

This doesn’t answer all of your points but in terms of finding out where something is defined you can turn a method into a Proc and then ask it. Eg

  some_instance.method(:foo).source_location

There’s a similar method for source definition. Both are useful dealing with over use of meta-programming.

Elixir is much more explicit compared to Ruby in terms of "where is X?" and its compiler apparatus (and user-available hooks and tooling) is getting expanded in 1.11 which is landing soon -- but to be 100% objective, some libraries utilize macros where alias/import/require might be used, which obscures things sometimes.

The tooling still catches all dependencies and their sources though (via `mix xref ...`)

> However, recently I started a project with Ruby, thanks to language servers

What do u mean exactly?

Language servers provide generic autocomplete and other language-specific functionality (e.g. rename a method, find all references to a symbol within your project, find where a symbol is defined, etc) to any editor that supports them. The reference implementation is VSCode, so if you use VSCode you can definitely use language servers, but now that’s it’s picking up steam, support is getting added to other editors, e.g. see vim-coc.

The Ruby language server in question: https://solargraph.org/

Interesting. Do u know what Rubymine is using ? it's own in-house solution?

Come on, use Rubymine or any other smart editor to find definitions..

I've been using Ruby in IntelliJ for nearly a year now at my new job. Up until literally the very most recent version of it, this has definitely not been enough to be able find some methods.

Like, ... 'move' or 'read', or some other horribly overloaded function that is the one that I need to go and find the specific implementation of because it's busted.

You need more than just Rubymine in many cases.

And no, sometimes it's quite difficult to get the exact configuration required to get that code path to figure out what's wrong.

I was fairly unhappy with RubyMine 4-5 years ago, when I last worked in Ruby long-term. Glad to hear it’s gotten better. I’ll have to revisit it, especially if there’s a CE for RubyMine.

To GP: there weren’t at the time any other options for a Ruby “smart-editor” AFAIK. However, like I mentioned in my comment, I’m giving Solargraph [1], a Ruby language server, a try, which is equivalent.

1: https://solargraph.org/

Rubymine is fantastic most of the time. But when projects use too much DSLs and 'magic', nothing helps.

Maybe this experiment of mine is the kind of thing you’d be looking for

https://github.com/lloeki/pak

While I feel sad too, I think the primary reason why it imploded under its own weight was the "magic". I still love Ruby, for all its developer friendliness and the consistency of its idioms. But too much of that sugar leads to bloat, that requires a bunch of hair-pulling for newbies to grok.

Now of course, there exist other simpler frameworks (a la sinatra), but when your posterchild is a thing like Rails, you can't expect people to not be burnt in the long term and still come back.

I recently started using Sinatra for side projects and it’s an absolute pleasure. It’s simple and reliable. I think it should get a lot more recognition.

Ruby is a good little language, I used it quite a bit for time. Rails is a horror that I've run from whenever possible.

Thorsten Ball's writeup [1] on the architecture behind Unicorn is one of the single most informative pieces I've ever read about fork-based multiprocessing, signals, and pipe-based ipc. The information there can be applied to any platform and, imo, is a must-read for anyone operating in a *nix environment.

[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...

How is it any different from when Apache 2.0 got introduced?

What? My comment was praising the blogpost.

Ruby is changing. I doubt it will ever be as big as the Python world, but I can see it coming back into fashion. I’ve been paying attention to the community and it’s still very active.

I think there's a lot of burnout in the JS ecosystem, and many are looking for the efficiency of Rails. However, I'm not certain if Ruby on its own is gaining more of a foothold. For a few years it looked like you'd seen more Ruby generalists with tools like Chef and Puppet, but I think Docker has taken a lot of wind out of those sails.

And then Rails 6 came along and brought NodeJS by way of Yarn and WebPacks. I'm still pretty light on deep Rails knowledge (currently doing my first non-toy project with it), but I was not pleased to see that this pile of bloat now appears to be a requirement.

It's the default and you can opt-out.

If you're interested in front-end performance, having a webpack build pipeline for your frontend assets is quite useful, especially if you want to leverage libraries like react or vue and build interactive reusable components, or leverage existing ones.

Tree shaking, minification, chunking, splitting, etc. will help you deliver a faster initial page load, which is a better overall experience and is also factor in search ranking for your public pages.

Front-end engineering has changed because users expect interactive experiences. Rails has an opinionated way to solve this differently using turbolinks and Rails UJS. A very significant proportion of folks don't want to go that route, enough for it to become the default.

>Chef and Puppet

And Vagrant.

Rails jobs are still plentiful. I don't see what's gonna wipe them all out in the coming 10-20 years. Especially if you live in North America, Rails is still super popular. But yes outside Rails there's mostly devops for Rubyists.

Have you looked at Crystal?

https://crystal-lang.org/

I have exact the same thing with Coffeescript. First left behind because apparently most Javascript dev's think ESx is now better than Coffee. And after that they joined the strict typing frenzy.. I hope the next front-end/node language will be a little more joyful.

im not fan of ruby but python was on its death bed and it came back to life only because of "data science" and "machine learning" since it was wasier to write it in python than in some compiled language and so it exploded since every big tech jumped on it right away and here we are. never say miracles don't happen :D

ruby has nothing to offer so it was left behind. maybe possibility to take your old code and ccompile it into C and gain massive performance will put ruby back on map, but i would not count on it. ruby was just a sillicon valley favourite pet that's no longer the case so i would not keep my hopes up for a big return.

I also love Ruby, it's all the little things. It helps me along and makes me happy every time I manage find a solution to a problem. "Woah! Can I really do it just like this?!?!"

Yeah, this. With Python -and I love Python, don't get me wrong, it got me a job- I find myself doing more tasks that feel boilerplate-y and bureaucratic. Ruby is a language that I'd call "delightful", in that a lot of annoying things are easy and intuitive.

This feeling is one of the only things I've found to help keep hobby programming fun while also working full-time as a programmer. I am happy to let everyone at $work favor us writing Python for this reason :)

I was intrigued by it for a while. I can remember the jokes from years ago that it should be renamed the Rails programming language. I find it a shame when an otherwise interesting language gets pigeonholed into single framework.

For sure. Ruby is great for things other than rails, like automation, writing server scripts, and of course small api servers/web sites using sinatra.

I use it all the time and still haven't actually done anything with Rails.

The last thing I wrote in Ruby was a script to help manage my email inbox using imap.

I've worked with Ruby for ~15 years now, and I've used Rails maybe 2 of those and it was the worst experience.

I think Rails really was a very mixed blessing for Ruby - on one hand it brought a lot of people. On the other hand it associated the language with a whole lot of practices that has done long term damage.