181–190 of 216 posts
Earlier quoted context omitted.
Rails is slow. Ruby isn’t slow. Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work. What makes Rails slow is the process around so much object creation and destruction, but this is exclusive to Rails itself. You put a Sidekiq worker up against a Go worker for some background processing and the performance is comparable.
> Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work. Yes, this is exactly the problem. Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. And now your RoR deve…
In Python you can write your low level extensions directly in Rust via PyO3 [0]. I guess there is something similar for Ruby.
Earlier quoted context omitted.
Rails is slow. Ruby isn’t slow. Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work. What makes Rails slow is the process around so much object creation and destruction, but this is exclusive to Rails itself. You put a Sidekiq worker up against a Go worker for some background processing and the performance is comparable.
> Ruby has the same thing that every other language has, call outs to C code under the hood for most of the real work. Yes, this is exactly the problem. Ruby is so slow that you end up writing C extensions when you want to do any non-trivial computation. The documentation is bad, the tooling is bad, the build/CI complications are bad, and there's not much community info online about the process. And now your RoR deve…
Perhaps for a classic C extension that's true, but (for portability across Ruby interpreters and other reasons), using FFI is usually the preferred way to do new C interop, and none of that is true for FFI.
Ruby/Rails backend with a React FE seems to be pretty popular these days, and is where I spend most of my time, but honestly I'd rather go back to Rails views with Stimulus for some of the components that need it. 3 years ago we were breaking monoliths into microservices, now it seems that we overshot that, and I'm much more likely to see people sticking with one main monolith, and maybe one or two other services. Si…
I've taken the approach of building the monolith first with an architecture that allows me to easily pull parts of it out into services when I hit constraints and need that scalability.
The boosts to dev speed from a monolith / monorepo over a more "scalable" approach are huge and allow you to focus on business problems instead of self imposed tech challenges.
Earlier quoted context omitted.
If you push to keep your code organized into modules with simple function APIs, and make sure that code outside your modules doesn't use the package internals directly, then your function APIs can be easily extracted into a REST/gRPC call, and the only thing that changes (to the first approximation) is your internal service (function) calls become external service (api) calls. Obviously you now need to add an API cli…
I've been there. This only seems to 'work'--until you try to raise throughput/reliability and lower errors/latency. What ends up happening is that the module boundaries that made sense in a monolith don't make sense as microservices when communications are allowed to fail. Typically the modules are the source-of-truth for some concern with consumers layered above it. This is the worst pattern with microservices where…
Keep all your code in one repo, deploy that codebase to multiple servers, but have it acting in different capacities.
1 email server, 5 app servers dishing out html, 2 api servers
Etc
It works very well and was able to handle spikes of traffic during super bowl ads without any problems.
Earlier quoted context omitted.
How?
Service Oriented Monolith. I.e. you can organise a monolith in pretty much the same way you would organise a micro service architecture.
A properly organized codebase scales very well when partitioned into services.
It is my default approach for all new projects for the last 10 years or so.
I recommend it without hesitation for startups all the time.
> Great for CPU-intensive tasks. Ruby is among the slowest languages out there. Which is fine for most webapps, but calling it great for CPU intensive tasks... I don't understand what logic is being used to come to this conclusion.
When I get half a million users I’ll start worrying about it. Most startups fold way beyond this point. Saving dev time and the pleasure and ease of working with Ruby more than make up for the speed difference.
Check out some of the comments above about "service oriented monolith".
That being said, know your limits. If you are doing a lot of image processing for instance it may be worth investing in an external service in a language that is a better fit for that problem.
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR. At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the bo…
Earlier quoted context omitted.
1. You can find a RoR developer.
Or not! Here in Toronto we've had a req open for a senior Ruby dev since like last October. We're seriously debating switching over to something else for no reason other than lack of available Ruby talent. Relatively view new devs are picking up Ruby nowadays. Job posting is here if anyone's interested --> https://angel.co/company/akira-2/jobs/106786-sr-full-stack-r...
I read a post like that and think "why bother when I can get paid the same for doing one of these things well somewhere else".