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 :)
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.
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.
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.
some_instance.method(:foo).source_location
There’s a similar method for source definition. Both are useful dealing with over use of meta-programming.The tooling still catches all dependencies and their sources though (via `mix xref ...`)
What do u mean exactly?
The Ruby language server in question: https://solargraph.org/
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.
[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...
And Vagrant.
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.
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 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 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.