I've coded in rails for 7+ years. imho, its a dying language.
Better to learn Python, b/c if you want to do anything with ML, you have to use Python.
Better to learn Python, b/c if you want to do anything with ML, you have to use Python.
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.
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).
checkout how ruby has fallen off a cliff on github: https://madnight.github.io/githut/#/pull_requests/2023/3
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?
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.
[1] Commit history on the main branch of rails/rails via github goes as far as Apr 10, 2008 https://github.com/rails/rails/commit/c67e985994362290308073...
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.
So in absolute terms the number of Ruby commits grew over that time span, it's not declining, and certainly not dying.
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.
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.
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.
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.