4 ms·

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 div

by itake 3y ago

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). checkout how ruby has fallen off a cliff on github: https://madnight.github.io/githut/#/pull_requests/2023/3 https://madnight.github.io/githut/#/pull_requests/2023/3

pelagicAustral 3y ago
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?
- rufugee 3y ago
  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.
  - ElectricalUnion 3y ago
    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. [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/c67e985994362290308073ed2793dd8e7f2a76db https://github.com/rails/rails/commit/c67e985994362290308073...
    - itake 3y ago
      Even github is moving off ruby. Their search tool was re-written in golang and rust, cutting their server costs in half.
- itake 3y ago
  > 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.
speleding 3y ago
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.
ElectricalUnion 3y ago
> "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.
- itake 3y ago
  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?
  - ElectricalUnion 3y ago
    > Most LLM client code uses LangChain 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.
    - itake 3y ago
      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.

by itake 3y ago

pelagicAustral 3y ago

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?

rufugee 3y ago
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.
- ElectricalUnion 3y ago
  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. [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/c67e985994362290308073ed2793dd8e7f2a76db https://github.com/rails/rails/commit/c67e985994362290308073...
  - itake 3y ago
    Even github is moving off ruby. Their search tool was re-written in golang and rust, cutting their server costs in half.
itake 3y ago
> 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.

speleding 3y ago

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.

ElectricalUnion 3y ago

> "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.

itake 3y ago
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?
- ElectricalUnion 3y ago
  > Most LLM client code uses LangChain 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.
  - itake 3y ago
    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.