There are plenty of businesses that have under 10k users and can live perfectly well with http requests around 500-1000 ms. When there are performance issues, 95% of the times they come from the database, not the language.
I somewhat agree. In general most apps are small where the language choice doesn’t really matter.
Caching is also vastly underutilized, most apps are read-heavy and could serve a significant portion of their requests from some form of caching.
> When there are performance issues, 95% of the times they come from the database, not the language.
Eh, statements like these are always too hand wavy. Resource usage has to do with performance, the DB has no fault in it but the runtime does.
Having worked with Rails a ton there’s a very large overhead. Most apps would see a significant speed up if rewritten in a faster language and framework, with no changes to the DB whatsoever. The amount of memory and CPU expended to the app servers is always significant, often outweighing the DB.
But what do you mean, give me a real example. You loaded too many active_records in memory and it's using a ton of ram? Did you try pluck, batches or even skipping active_record and using a raw query?
Unless you really need to scale for a ton of users, you don't have to go crazy to get decent performances out of rails/ruby. How many requests/sec are we even talking about here?
> When there are performance issues, 95% of the times they come from the database, not the language.
DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. Times have changed considerably. Most especially because DHH now promotes using SQLite, which completely takes the worst I/O offender right out of the picture. Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.
Doesn't matter if SQLite is now viable with rails, no legacy rails app is using it and it's not like you're going to wake up one morning and migrate your production db from postgres, mysql, sql server or oracle just because you felt like it.
In theory the language is slow, in practice it doesn't really matter because the db is much slower unless you're github or twitter and you really need to scale.
When you choose ruby, you trade faster dev time for slower runtime. I am OK with this trade-off 99% of the time. My dev time costs way more than a couple ms lost on my production server.
> When you choose ruby, you trade faster dev time for slower runtime.
Ruby is a beautiful language, but that does not translate to efficient use of dev time. Ruby is not a language that you can quickly write usable code in. Some other languages are clearly more productive. You can create works of art, though, which is still pretty appealing. Ruby does have a place in this world.
It was, again, DHH/Rails that used to make the claim about developer time — premised on Rails eliminating all the so-called "situps" that other frameworks imposed on developers. It is very true that when you eliminate a bunch of steps you can move a lot faster. But:
1. Everyone and their bother have created Rails clones in other languages that also eliminate the same "situps", negating any uniqueness Rails once offered on that front.
2. It turns out those "situps", while a dog in early development, actually speed development up down the road. If you are churning out a prototype to demonstrate an idea that will be thrown away after, its a pretty good tradeoff to ignore what you can, but things become far less clear cut when a program finds longevity.
> Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.
These days the main issue why web apps are slow or fragile is because they are huge React apps that do way too much in the browser than they need too. The response time from the server is rarely the issue unless you're doing heavy analytics. High end React shops do some crazy optimization to try to compensate for this fact. Linear is the only one I've seen do it well with JS.
>> When there are performance issues, 95% of the times they come from the database, not the language.
> DHH used to say that it didn't matter if Rails was slow because the database was I/O bound anyway. But that was a long time ago. ... Nowadays the language (when it is as slow as Ruby) is most likely to be the problem.
Nowadays CPU speeds, available RAM, and network speeds dwarf what was top-of-the-line "a long time ago," making the trope of "Ruby is too slow" much less believable "nowadays."
"Too slow" is a mischaracterization. Ruby was never too slow, only comparatively slow. What DHH was talking about is that when the system was I/O bound, even if you could eliminate all the time spent in Ruby, you'd only see small percentage increases in performance at best. But the calculus has changed. I/O isn't the bottleneck like it was when those statements were made. Now, if you could eliminate the time spent in Ruby, you'd see significant percentage increases in performance.
Nowadays the language (when it is as slow as Ruby)
is most likely to be the problem.
And now state:
"Too slow" is a mischaracterization. Ruby was never
too slow, only comparatively slow.
In response to my identifying the "Ruby is too slow" trope. Furthermore, when you assert:
Now, if you could eliminate the time spent in Ruby,
you'd see significant percentage increases in performance.
This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations. For example, if an overall execution flow takes 1 millisecond and time within the Ruby runtime accounts for 600 microseconds, then the above would be true.
One way to describe your position is disingenuous.
> This implies a performance issue within Ruby when, in fact, the narrative has now been shifted into execution percentage allocations.
Yes, that's right. If you have performance problems then Ruby taking up the large majority percentage of the execution allocation means that Ruby is the problem.
But your incorrect assumption is that you will have performance problems in the first place. Neither Ruby nor databases are that slow.
You must have done that stupid HN thing where you pick random strings of words and try to derive meaning from them without taking in the entire context that surround those words into account?
Modules (mixins) are objects, classes are also objects (of type Class).
The Kernel module is included in the Object class, which means its methods are available to every Ruby object and can be accessed from virtually any scope, including the top-level (global) context where self is an instance of Object called "main."
I think you're unto something. Totally anecdotal, but my father owns around ~10 houses and small apartment buildings in Canada. I think he managed to acquire them all through mortgage refinancing or something like that I really have no idea. He rents the properties to people.
Even though he's a hard worker, he has a normal 9-5 job and his income is pretty standard for a salaried worker. Knowing him, I'm sure he didn't come up with the idea himself, so I bet this is a relatively common thing to do for mid to high income baby-boomers.
I could be totally off base here, but I can see that if most people have the leverage to own 10 houses in Canada through some financial instruments with the banks this could lead to a housing bubble.
For what use-case? Because I've been developing in ruby for over 10 years now and it has been the optimal choice for a ton of companies I've worked for. The lack of static typing is a feature for a lot of people.
I honestly can't believe you're being downvoted when you have the most sensible answer here. The government here in Canada created MASSIVE supply of money out of thin air to keep up with the US and put almost 1/3 of the population on social welfare and everyone is pointing fingers to find who's the most greedy. It's the dumbest thing ever.
The media seems to be doing its damnedest to push any theory that does not tie into the quantitive easing/money printing.
Its fascinating to watch what i suspect is another bigger collapse (than the GFC) start, and NOBODY in the MSM is looking at the elephant in the room wearing a big loud hat that says "IT WAS ME".
The problem with this argument is that it's implying that there is no such thing as clear code. Sure some people think their code is clear when it is not, but that shouldn't stop you from striving to write clearer code.
A long time ago, I had a tendency to write comments to explain code that could be simplified. Refactoring it usually made the comments redundant.
Comments are still very useful when the why is unclear.
There is a culture that the l33ter the code, the more senior I am. So, many people will never refactor code to make it simpler to read. It affects their ego. In fact, I've seen the opposite: simple code refactored into more complex (not by the original author). The mindset: if it's more complex, it must be better.
Java example: rewriting non-stream collections code to use lots of chained streams. Using lambda functions when not needed. Rewriting case labels to use case lambdas. etc.
The fact that you don't believe me blows my mind a little, not going to lie.
Maybe this will convince you a little more? https://refactoring.guru/smells/comments
Don't be too hard on them, they're only a baby after all.
More seriously, I agree with you 100%. Many, many, times I've stopped halfway through a writing an explanatory comment and refactored the to make the comment unnecessary.
This habit was formed by realizing that most people (including me) don't read comments half as carefully as they read code. So if you want something to be noticed and understood, you better put it in the code.
For every fervent user of X, I can find you 5 zealous irrational haters who are 100% convinced that X is just a religious fluff and that there is no way it's actually better than Y (what they are using). I have in fact, been guilty of that kind of thinking myself.
Sometimes the problem is more that the grass looks greener on the other side. When you realize there are a bunch of day 2 problems for the "better" solution you didn't uncover beforehand, many will enter sunk cost territory
I don't understand how it is possible to lie to myself. It requires you to suspend disbelief and say to yourself that something did or didn't happen, that's something I cannot fathom.
Lying to yourself doesn't necessarily require suspension of belief entirely, but convincing yourself whatever you are doing is worth you doing it. Since it's hard (probably impossible) to know the object truth of if something is " right" or not. Then it becomes fairly easy to justify anything, im sure you've done this even if you don't know exactly how to admit it or don't think you're doing it consciouly.
