5 ms·

Ruby/rails is full of shortsighted crap like this. I feel stuck, our whole backend is legacy rails and I can’t escape.

goatlover 2y ago
Bit of a strong claim when the Erlang/OTP was designed to handle massive concurrency without colorful methods. Given that both Erlang and Ruby are inspired by the message passing semantics of Smalltalk.
- lmm 2y ago
  Unicoloured languages are great as long as your code doesn't have to actually do anything (which is lots of modern code, to be fair). Try writing a physics simulator or 3D renderer in Erlang and see how that goes.
  - pmontra 2y ago
    Erlang is not great at math performance, also because it uses arbitrary length integers. There is a nice comparison between several languages, including Erlang at https://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell https://stackoverflow.com/questions/6964392/speed-comparison... It all depends on how the code is written. Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your point. However, how is that related to using sync/async vs message passing?
    - lmm 2y ago
      > Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your point. However, how is that related to using sync/async vs message passing? If you want to write high-performance code then you need to be able to write synchronous code and have control over what your yield points are. If you take the "all calls are potentially async, runtime does what it wants" approach (i.e. "no function colouring") then you just will not be able to do that.
- igouy 2y ago
  > … Erlang … inspired by the message passing semantics of Smalltalk. What makes you think that?
  - goatlover 2y ago
    The Wikipedia entry says Smalltalk was one of it's influences and Joe Armstrong, co-developer of Erlang, mentions message passing as the fundamental aspect of OOP that Erlang gets right.
    - igouy 2y ago
      The Wikipedia "Influenced by Lisp, PLEX,[2] Prolog, Smalltalk" seems to be un-sourced ! > … Joe Armstrong … mentions message passing … Where?
    - igouy 2y ago
      Here's something Joe Armstrong's PhD thesis does reference in the context of message passing: "4.5 Programming Notations Based on Message Passing" p33 "Concepts and Notations for Concurrent Programming", Gregory R. Andrews and Fred B. Scheider, Computing Surveys 15(1) March 1983, pp 3 - 43 [pdf] https://www.cs.cornell.edu/fbs/publications/LangSurv.pdf https://www.cs.cornell.edu/fbs/publications/LangSurv.pdf
rco8786 2y ago
Legacy codebases that are a joy to work with are few and far between, in any language.
segfaltnh 2y ago
Rails doesn't scale well in my experience. Or maybe rails devs don't scale well. The language and framework are both centered around developer happiness, which in my experience drops off around 10,000 lines. That's about when projects start getting difficult.
- pmontra 2y ago
  A Rails project I'm working on has this LOC Ruby 12169 ERB 2339 Vue 24895 Js 4526 The Vue frontend is indeed more complex than the Rails backend, and in my experience Vue is much simpler than React. My customer organized the Rails app with models, controllers, api/v1/controllers, jobs, services (naming only the most important stuff). It's not bad to work with.
norman784 2y ago
I also work on a legacy Ruby/Rails codebase, what I dislike is Ruby as a dynamic language, I'd prefer typed languages, but overall Rails didn't changed too much in the last 14 years that I know it (I didn't used too much in the past), but the concept is still the same to this day, few changes to the API/syntax, but otherwise if you know Rails, if you know Rails, it is most likely that you find very easy to work on any Rails app.

Bit of a strong claim when the Erlang/OTP was designed to handle massive concurrency without colorful methods. Given that both Erlang and Ruby are inspired by the message passing semantics of Smalltalk.

lmm 2y ago
Unicoloured languages are great as long as your code doesn't have to actually do anything (which is lots of modern code, to be fair). Try writing a physics simulator or 3D renderer in Erlang and see how that goes.
- pmontra 2y ago
  Erlang is not great at math performance, also because it uses arbitrary length integers. There is a nice comparison between several languages, including Erlang at https://stackoverflow.com/questions/6964392/speed-comparison-with-project-euler-c-vs-python-vs-erlang-vs-haskell https://stackoverflow.com/questions/6964392/speed-comparison... It all depends on how the code is written. Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your point. However, how is that related to using sync/async vs message passing?
  - lmm 2y ago
    > Eventually somebody managed to make the Erlang code faster than the baseline C, then someone else made the C version 8k % faster, which proves your point. However, how is that related to using sync/async vs message passing? If you want to write high-performance code then you need to be able to write synchronous code and have control over what your yield points are. If you take the "all calls are potentially async, runtime does what it wants" approach (i.e. "no function colouring") then you just will not be able to do that.
igouy 2y ago
> … Erlang … inspired by the message passing semantics of Smalltalk. What makes you think that?
- goatlover 2y ago
  The Wikipedia entry says Smalltalk was one of it's influences and Joe Armstrong, co-developer of Erlang, mentions message passing as the fundamental aspect of OOP that Erlang gets right.
  - igouy 2y ago
    The Wikipedia "Influenced by Lisp, PLEX,[2] Prolog, Smalltalk" seems to be un-sourced ! > … Joe Armstrong … mentions message passing … Where?
  - igouy 2y ago
    Here's something Joe Armstrong's PhD thesis does reference in the context of message passing: "4.5 Programming Notations Based on Message Passing" p33 "Concepts and Notations for Concurrent Programming", Gregory R. Andrews and Fred B. Scheider, Computing Surveys 15(1) March 1983, pp 3 - 43 [pdf] https://www.cs.cornell.edu/fbs/publications/LangSurv.pdf https://www.cs.cornell.edu/fbs/publications/LangSurv.pdf

rco8786 2y ago

Legacy codebases that are a joy to work with are few and far between, in any language.

segfaltnh 2y ago

Rails doesn't scale well in my experience. Or maybe rails devs don't scale well. The language and framework are both centered around developer happiness, which in my experience drops off around 10,000 lines. That's about when projects start getting difficult.

pmontra 2y ago
A Rails project I'm working on has this LOC Ruby 12169 ERB 2339 Vue 24895 Js 4526 The Vue frontend is indeed more complex than the Rails backend, and in my experience Vue is much simpler than React. My customer organized the Rails app with models, controllers, api/v1/controllers, jobs, services (naming only the most important stuff). It's not bad to work with.

norman784 2y ago

I also work on a legacy Ruby/Rails codebase, what I dislike is Ruby as a dynamic language, I'd prefer typed languages, but overall Rails didn't changed too much in the last 14 years that I know it (I didn't used too much in the past), but the concept is still the same to this day, few changes to the API/syntax, but otherwise if you know Rails, if you know Rails, it is most likely that you find very easy to work on any Rails app.