71–80 of 80 posts
Just curious... how come noone else in the ruby scene seems to use an actual debugger? IDEA has a front-end for ruby-debug-ide and it is divine, it puts pry to shame. Does VSCode or others not have this or something? Some of the other stuff mentioned in the blog post... why tail development.log if you can tail stdout and get all that nice console coloration and such? > I hate switching constantly between the browser,…
Hey Julien! Great to see that you finally released this ;)
Yep! Thank you
Earlier quoted context omitted.
Yeah, right. Because all the interesting things nowadays happen on the same server that renders your html and nobody calls into other SaaS APIs or interacts with external systems much. Rails is great for a world where an app was running on one server, but that world just isn't there anymore as much as it used to.
> Rails is great for a world where an app was running on one server, but that world just isn't there anymore as much as it used to. No, that’s still a choice you can make. It’s still possible to make your app run on one server with Rails/Django/PHP and to scale it horizontally and vertically very easily. The requirements of a web app / web site barely changed in 10-15 years, the only things that changed is that new w…
Earlier quoted context omitted.
Rails is practically unusable for anything that requires concurrency inside of serving one request. If you have all your data in the database that your rails app connects to everything is great. If you need to call out over the network to 12 different services to serve your request or want to do computationally intensive things, etc, another language with support for concurrency is a better choice imho.
Can you explain why concurrency within processing a request makes things difficult for Rails?
Contrast that to other architectures like NodeJS where there's an event loop driving execution that would suspend execution and work on the next request while waiting for OpenAPI to respond. This enables you to service thousands or tens or hundreds of thousands of the same kind of request with the same amount of RAM.
There are approaches to improve this in Ruby/Rails like Fibers, however lots of libraries in the ecosystem use global mutable state and assume it's request local. If you have multiple requests served concurrently by the same worker, they'll overwrite this state and bugs will happen. Also baking this onto the language is not very ergonomical (beautiful in Ruby speech) if you compare it to languages where concurrency has been a primary design concern in the beginning.
Earlier quoted context omitted.
Rails is practically unusable for anything that requires concurrency inside of serving one request. If you have all your data in the database that your rails app connects to everything is great. If you need to call out over the network to 12 different services to serve your request or want to do computationally intensive things, etc, another language with support for concurrency is a better choice imho.
Couldn’t you solve this problem with something like this: https://ruby-concurrency.github.io/concurrent-ruby/master/Co...
1. there are lots of problems preventing this working in practice currently (see my sister comment here: https://news.ycombinator.com/item?id=39433274).
2. the result of doing this is not the beautiful ruby code you are used to, compared to languages that have been designed for concurrency from the beginning.
Earlier quoted context omitted.
I dont know People who use Rails really seem to love it. But in 2024 things like react and typescript exists. Python is there for data science stuff Typescript is there for the web. I don't understand why you would pick Ruby instead
> react and typescript These are nonstarters for me. It seems like vercel has corrupted react beyond recognition, and other full-stack frameworks like Remix just do a lot of `rigamarole` to mimic a fraction of what an older fullstack framework like rails/django/phoenix can do. frontend is desperately trying to catch up to backend. backend is trying to capture frontend to seduce people back, and they're getting there…
Just curious... how come noone else in the ruby scene seems to use an actual debugger? IDEA has a front-end for ruby-debug-ide and it is divine, it puts pry to shame. Does VSCode or others not have this or something? Some of the other stuff mentioned in the blog post... why tail development.log if you can tail stdout and get all that nice console coloration and such? > I hate switching constantly between the browser,…
I hate multiple screens more than I hate switching windows :P
Earlier quoted context omitted.
Can you explain why concurrency within processing a request makes things difficult for Rails?
The currently prevailing model in Rails is that a worker is a process that has an instance of your application running (ie the code loaded, global variables initialized etc). Let's say your service makes a request out to OpenAI and waits 5s for a model inference response. During that time, that particular worker that is servicing your request will sit around, needs to keep the 300MB or however big your heap is in mem…
Earlier quoted context omitted.
The currently prevailing model in Rails is that a worker is a process that has an instance of your application running (ie the code loaded, global variables initialized etc). Let's say your service makes a request out to OpenAI and waits 5s for a model inference response. During that time, that particular worker that is servicing your request will sit around, needs to keep the 300MB or however big your heap is in mem…
The global state trap ... I wonder why people still do these things, especially in web context. Basically whenever one uses mutable global state and actually mutates it, one puts off issues to the future, until one day some poor soul has to deal with this or rewrite.