People have been saying its dying for years, yet here we are. Your reasoning doesn't quite make sense, not everyone wants or needs to do ML - choose the right tool for the job.
In absolute numbers it may be doing fine. Steadily growing even (I don't think it is).
But in relative numbers, that means a significant decline. In many niches and usecase, that practically means obsolence. Keep in mind that the amount of new people in software development have been almost doubling each year, for decades.
I'm in Ruby and Rails fulltime for over 12 years now. Almost all the work I come across is either legacy, maintenance, upgrading or untangling spaghetti.
One reason for that may be that Rails is optimized for "one man shops", which by nature aren't jobs people have vacancies or hires for.
But the more logical reason is that people just don't start new projects in Rails anymore. Not on a practically significant scale, anyway. For every new rails project, there's probably hundreds of python, typescript, rust, Java and PHP projects. In web alone.
Something can be dying for years and not be dead. Other languages (python, golang, rust, ts) left ruby behind. Even big tech companies founded on rails have diversified their tech (Airbnb, Github, Stripe, etc.).
Most companies will have an DS/ML team. "ruby" doesn't scale (in that you can't write efficient ruby code that can process data at the same level as python/c++ can without writing c-extensions to the underyling cpp libraries).
> "ruby" doesn't scale (in that you can't write efficient ruby code that can process data at the same level as python/c++ can without writing c-extensions to the underyling cpp libraries).
Wait, excuse me, I thought people did not use "python" for high performance code either.
They use a module of compiled fortran/C/C++ or a FFI interface, that happens to be in python. Calling this mass of external modules "python" is extremely naive to me.
Using this naive definition that "X solution is in Y language if it is started in Y language" almost all high performance code in existence is in bash and systemd units.
Great! I understand that ruby has similar access to this "mass of external modules", but where are they? If I need to support face recognition, nudity detection, or recommendation engine, how do I `gem install` them into a sidekiq worker?
Most LLM client code uses LangChain (or that MS one, I forget the name). Where is the ruby equivalent?
From what I saw on several LLM projects, they usually don't use LangChain at all - if they really care about performance, they go straight to huggingface/transformers or even directly to pytorch.
If you want use PyTorch and you're dead-set into using Ruby then you can just FFI LibTorch and you should be fine; torch-rb mostly does that.
Does it work "OK"? Well, I would say for some cases potentially better that Python, but mostly because in python-land version and package management is somewhat of a unmitigated dumpster fire.
LangChain is an API layer wrapping huggingface and/or pytorch. Huggingfacetransformers and pytorch solve a different set of problems than what LangChain solves.
I understand that, but most programmers want the simple `pip install` `gem install` flow to work, without needing to create their own bindings code.
torch-rb offers the barebones. You'd still need to re-implement the model from whitepapers or translate the python version.
You come off as an extremely bitter person. Why so much anger directed at a programming language (of all things)?
Companies you mention HAD to scale up, then their stacks diversified... hell, Facebook was built on PHP, and when he time came for a chat functionality to be implemented they used Erlang, not because PHP is shit, but because concurrency and resiliency was better handled by a different programming language...
Realistically, most applications will never need to scale up. So what's wrong with a nice framework that allows people to just get stuff done?
Umm...pointing to facts based on real data isn't bitter. Did you see even look at the graph that was shared? It's pretty clear ruby is trending downward and I say this as a past long-time ruby advocate and fan.
I think that you're conflating correlation with causation. I think it's more plausible to assume it was the early numbers that are skewed and non-representative.
The fact that GitHub itself was is a killer app of the Ruby on Rails, and that the Rails project itself changed to being hosted on GitHub somewhat very early on it's history [1] had a disproportionate effect on the early community that gathered there.
Now GitHub attracts a much more diverse portfolio of projects, so the numbers you see there are less statistically biased towards early Ruby on Rails adopters.
> Realistically, most applications will never need to scale up. So what's wrong with a nice framework that allows people to just get stuff done?
I've coded with Rails since Rails 3.
There are a few issues with rails:
1/ DHH never gets JS right. CoffeeScript, Asset pipeline, and now the new Turbo. Migrating your FE every 3-5 years to a new language stack is the opposite of "get stuff done"
2/ Rails is built for b2b apps (Basecamp). If your business looks like basecamp, then the conventions will work for you, but if it doesn't (think b2c apps), it won't. Examples: ActiveStorage was a mess with no CDN support (it is better now though), Action Cable only supports a handful of connections compared to nodejs.
3/ No ML support.
If you want a framework that "allows people to just get stuff done" then use Django. It is similar to rails and has all the bells and whistles of the ML community.
That graph is a bit deceptive, it shows Ruby dropping from 19% of commits to 5% of commits. However, since inception GitHub grew by far more than a factor of 4 with GitHub leaving the initial Rails bubble and the rest of the world getting on board.
So in absolute terms the number of Ruby commits grew over that time span, it's not declining, and certainly not dying.
It might be not dying but, for example, our company banned new apps to be build with Ruby and Javascript, instead new apps needs to be build with Go or Rust, existing apps will continue to be written in Ruby and no plans to migrate to other languages, but at some point I think it would be migrated and/or deprecated.
The benefits to go or rust isn't hands-on-the-keyboard developer velocity. Servers in Golang or rust will run faster (lower cloud costs). It also has lower risk of bugs and side effects.
Coding in go is slower than ruby, but debugging go code is 100x easier than debugging ruby or python code.
Once companies hit a certain size, the zoom-meeting time or system design time is an order of magnitude greater than coding time.
Better to learn Python, b/c if you want to do anything with ML, you have to use Python.