This article is just as valid if you ran :%s/Rails/Django/g. I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.
Doesn't the article say exactly that?
Use Rails
71–80 of 88 posts
Re: Use Rails
#72Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails. But as of couple of years ago, Rails came with a number of drawbacks: 1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/…
One new thing on the table is that AI (github copilot, openai) seems to perform way better on non-statically-typed languages. Anecdotally, the suggestions are way better in ruby than go.
I could guess why, but I'll let others speculate.
Re: Use Rails
#73Earlier quoted context omitted.
Yeah, there are small, niche solutions for solving concurrency for very specific use cases vs general support for this in the language. This doesn't help you when you are using the AWS SDK to make HTTP requests or when you want to hide latency of making a DB query and and HTTP request concurrently. I'm currently working on a large Rails App in my day job and lack of concurrency support is a major limiting factor for…
I understand your general point, but these solutions are not niche. They cover almost everything needed in web dev. The niche problems are the ones that arise at scale, which is when a business typically has the resources to solve them. (Hint: you don't have to solve them in Rails). Large app / company challenges don't apply to new apps. Statements like "I wouldn't start a new app without a great concurrency story."…
You can build a great NodeJS monolith, be very productive and not end up in a corner where you have to spend years of effort fixing your early technology choices down the road. It's not a zero sum game and completely rewriting millions of lines of business logic that your company is relying on for revenue is a hard sell.
Re: Use Rails
#74Earlier quoted context omitted.
You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.
Where did I say anything like that?
"The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something."
The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging with the Rails community.
I get it that most startups in the early phase don't care if a request is taking 200ms or 1s and should just go with whatever is easiest to implement. The tendency to generalize this thought to mean that nobody ever needs to care about these problems is crazy though.
Re: Use Rails
#75Earlier quoted context omitted.
I understand your general point, but these solutions are not niche. They cover almost everything needed in web dev. The niche problems are the ones that arise at scale, which is when a business typically has the resources to solve them. (Hint: you don't have to solve them in Rails). Large app / company challenges don't apply to new apps. Statements like "I wouldn't start a new app without a great concurrency story."…
You can build a great NodeJS monolith, be very productive and not end up in a corner where you have to spend years of effort fixing your early technology choices down the road. It's not a zero sum game and completely rewriting millions of lines of business logic that your company is relying on for revenue is a hard sell.
You're saying that NodeJS monolith comes with no downsides compared to Rails at early stages. We disagree here.
From my brief surveys, nodejs ecosystem comes with less security out of the box, less standardized project structures, fewer thoroughly-designed and supported packages (vs cutting edge experiments), more complex upgrade paths, more projects getting abandoned, all of which can slow you down every day. Friction from these can be deadly.
On the other hand, being in the corner at scale doesn't force you to rewrite everything. Just the piece that put you there. You can leave Rails app to handle most things, and extract parts of specialized infra as needed.
Would be curious to look at specifics — what kind of pains your company is experiencing with Rails today.
Re: Use Rails
#76Earlier quoted context omitted.
Where did I say anything like that?
"The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something." The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging wi…
I honestly feel like you're responding to an entirely different person, despite the fact that you quoted my post.
Rails can scale horizontally just fine for a huge, huge majority of business cases. If you have a business critical use case that truly needs however many thousands of things done in a tight loop inside a single process...obviously Rails is not the tool you should be using.
I did not say "the ability to optimize something is a trivial niceity". I said "concurrency often gets in the way more than it helps unless you're trying to optimize something". I'm not sure if you're purposefully misrepresenting my words, but it does feel like you are especially given the "so you never make HTTP requests" comment you started this thread with.
Re: Use Rails
#77Earlier quoted context omitted.
I'm actually curious what the distinction is in your view. I've never really considered a column to be a foreign key when the constraint isn't used. Having a column that we give business logic context to is useful, and indexing a column that should contain values for another table is helpful for query speed, but at least in my opinion they really aren't foreign keys unless that constraint lives directly in the databa…
Excluding multi-column keys and joins, I'd describe a column as a foreign key in the context of a given query; i.e. when that query references a unique column in a JOIN condition on a related table. This differs from an explicit declaration of a foreign key constraint which provides all the useful referential integrity characteristics that you eluded to. If you said to me "Database Foo doesn't support foreign keys!"…
I’ve worked at 3 large scale startups now that removed all their FK constraints due to performance and inflexibility issues. The lack of them never really caused an issue - I’ve never missed them. If you have a services / multiple db architecture you’re going to have to deal with dangling references anyway.
I think they’re somewhat obsolete as a concept.
Re: Use Rails
#78Earlier quoted context omitted.
"The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively trying to optimize something." The assemption that the ability to optimize something is a trivial nicety vs an essential tool to keeup your business running and growing boggles my mind every time I'm engaging wi…
I honestly feel like you're responding to an entirely different person, despite the fact that you quoted my post. Rails can scale horizontally just fine for a huge, huge majority of business cases. If you have a business critical use case that truly needs however many thousands of things done in a tight loop inside a single process...obviously Rails is not the tool you should be using. I did not say "the ability to o…
I also have the feeling that you are talking to a different person. I'm talking about latency, you are talking about bandwidth. I'm talking about concurrency, you are talking about parallelism.
You can scale up any Rails app super easily by throwing money at the problem, it's trivial. When a single page load or API request to it takes 20 seconds, it doesn't help you if you have 1000 servers that can respond to hundreds of requests in 20 seconds each, when you need that request served in 500ms. This means that while serving a single request you might need to do things concurrently (like make an http request to an authz service and do a db query at the same time).
Re: Use Rails
#79Earlier quoted context omitted.
I honestly feel like you're responding to an entirely different person, despite the fact that you quoted my post. Rails can scale horizontally just fine for a huge, huge majority of business cases. If you have a business critical use case that truly needs however many thousands of things done in a tight loop inside a single process...obviously Rails is not the tool you should be using. I did not say "the ability to o…
I also have the feeling that you are talking to a different person. I'm talking about latency, you are talking about bandwidth. I'm talking about concurrency, you are talking about parallelism. You can scale up any Rails app super easily by throwing money at the problem, it's trivial. When a single page load or API request to it takes 20 seconds, it doesn't help you if you have 1000 servers that can respond to hundre…
The amount of APIs in the world that require concurrency within a single request scope to meet latency needs approaches zero.
In practice, you don’t make that db call until the auth request is done and the user is verified. In practice, you don’t make the outgoing api call until you already have the results of the db call, because you need your data to form the outgoing request. Etc.
APIs where intra request concurrency is needed absolutely exist. But they’re the exception not the rule, even at large scale tech co’s. And yes. Rails is a bad choice for those.
Re: Use Rails
#80Earlier quoted context omitted.
You can build a great NodeJS monolith, be very productive and not end up in a corner where you have to spend years of effort fixing your early technology choices down the road. It's not a zero sum game and completely rewriting millions of lines of business logic that your company is relying on for revenue is a hard sell.
You're saying that NodeJS monolith comes with no downsides compared to Rails at early stages. We disagree here. From my brief surveys, nodejs ecosystem comes with less security out of the box, less standardized project structures, fewer thoroughly-designed and supported packages (vs cutting edge experiments), more complex upgrade paths, more projects getting abandoned, all of which can slow you down every day. Fricti…
"being in the corner at scale doesn't force you to rewrite everything. Just the piece that put you there. You can leave Rails app to handle most things, and extract parts of specialized infra as needed."
You can't easily, because this now puts a network boundary between your Rails app and the part you extracted. A network boundary that requires you to do IO, which will (by default) cause you Rails app to blockingly wait for a response (vs not doing so in other runtimes, ie Node).
"Would be curious to look at specifics — what kind of pains your company is experiencing with Rails today."
Some things I've seen in the last 3 month:
* Rails timing out after 30s while allocating 500MB of memory (mostly) in ActiveRecord to compute 5MB of JSON to return to an API caller
* 90% of request latency of ~10s spent waiting for downstream services to respond to requests. Most of these could be fired off concurrently (ie `Promise.all` in node). 9s/10s this Rails worker is sitting around doing nothing and eating up ~300MB of memory.
* trying to extract out Authorization to a centralized service (so that other extracted services don't have to call into the monolith in order to make authorization decisions) is a major pain as the monolith now has to make calls out to the centralized auth system to in order to make authz decisions.