It's not Ruby that's slow, it's your database • Hacker News Board

Re: It's not Ruby that's slow, it's your database

#191

Post by likeabbas » Wed, Nov 09, 2022, 10:15 PM UTC

Mikeb85 wrote: post #57

likeabbas wrote: post #2

No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.

> No, Ruby is slow. Its GC is ungodly slow. Ruby is quicker than Python and that's the most popular programming language there is at the moment. > And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency You definitely can. You've been able to fork processes for longer than I can remember. Ractors just became a thing, making multithreading cheaper and easier. Ruby's also had multit…

> Ruby is quicker than Python

Python is slow as shit too. I would never use either language in a user path production environment.

> fork processes

Forking a process takes upwards of 50ms vs forking a thread is in microseconds. That might not seem like a lot, but a use will be able to tell the difference between a 50ms page load time and a 150ms page load time. Also, multi processing is not optimal for sharing memory like a local cache.

My ultimate point is there’s truly no reason to use these languages when Java, Go, and Rust are around

Re: It's not Ruby that's slow, it's your database

#192

Post by likeabbas » Wed, Nov 09, 2022, 10:16 PM UTC

joshmn wrote: post #5

likeabbas wrote: post #2

No, Ruby is slow. Its GC is ungodly slow. And you can’t truly multithread, thus you can’t properly parallelize or maximize concurrency.

How many developers will really need it though? It's fast enough for Stripe's API, it's fast enough for Shopify; hardware in exchange for productivity is a pretty fair trade.

Stripe’s API is one of the slowest of any payment processor, and it’s a major source of contention within the company

Re: It's not Ruby that's slow, it's your database

#193

Post by likeabbas » Wed, Nov 09, 2022, 10:18 PM UTC

kaba0 wrote: post #116

JohnBooty wrote: post #74

Earlier quoted context omitted.

If you need maximum requests per second for sufficiently high volumes of traffic - ie, Stripe/Twitter/FB/whatever stuff - then yeah Ruby/Python/etc doesn't cut it. If your needs get extreme enough (high frequency trading?) then Java doesn't cut it either. Most (I suspect > 99%) use cases don't fit these criteria. I know this is skewed a perception is skewed a little by the HN crowd, where many folks legitimately are…

Java is used in HFT, and for the variant where it is not fast enough, general purpose CPUs are not fast enough so not even hand-written assembly can compete anymore. They use FPGAs for that kind.

Java is used in HFT for markets that have a time window, but only because they tune the GC to never kick in during market hours

Re: It's not Ruby that's slow, it's your database

#194

Post by int_19h » Thu, Nov 10, 2022, 12:11 AM UTC

lukaseder wrote: post #144

int_19h wrote: post #76

Earlier quoted context omitted.

That really depends on the language - specifically, on whether it already has constructs that can map nicely (e.g. LINQ in C#), or macros to define them, or syntax that is generally amenable to DSLs even without macros in the picture (e.g. Lisps). SQL itself is also not a particularly well-designed query language. E.g. the order of the query doesn't reflect the natural data flow (SELECT .. FROM .. is reversed - compa…

SQL is powerful. A DSL that "fixes" things in this area getting all the other language feature interactions right isn't trivial, all the while users have to learn yet another language. Take PRQL for example: https://prql-lang.org . It looks nice, but the examples are very basic. What about window functions, grouping sets, lateral, DML, recursive SQL, pattern matching, pivot/unpivot etc. Might be doable, but perhaps,…

A good DSL is not easy to implement, of course.

But the point here isn't just that it can be more regular than SQL. Integrating with the syntax of the host language is also a considerable advantage, ideally with static type checking.

Re: It's not Ruby that's slow, it's your database

#195

Post by arkis22 » Thu, Nov 10, 2022, 12:13 AM UTC

aaron_m04 wrote: post #182

arkis22 wrote: post #34

Earlier quoted context omitted.

rails, postgres, PORO, and htmx is a monstrously productive stack

What is PORO?

plain old ruby object. basically you take your truth from the database and you plug it into an object that takes the data and functionally produces a data output that you feed to your view.

Re: It's not Ruby that's slow, it's your database

#196

Post by arkis22 » Thu, Nov 10, 2022, 1:16 AM UTC

ithrow wrote: post #59

arkis22 wrote: post #34

Earlier quoted context omitted.

rails, postgres, PORO, and htmx is a monstrously productive stack

If you are one Rails, why not the hotwire stuff?

https://github.com/hotwired/hotwire-rails

deprecated. they use stimulus and its worse obfuscated JS than htmx IMO

Re: It's not Ruby that's slow, it's your database

#197

Post by arkis22 » Thu, Nov 10, 2022, 1:17 AM UTC

boredtofears wrote: post #104

arkis22 wrote: post #47

Earlier quoted context omitted.

you're looking for what? my personal million dollar website or my billion dollar startup?

just any evidence to back up your argument

just my years of experience, sorry

Re: It's not Ruby that's slow, it's your database

#198

Post by BeefWellington » Thu, Nov 10, 2022, 4:27 PM UTC

wiseowise wrote: post #132

BeefWellington wrote: post #90

Earlier quoted context omitted.

Ruby is quicker than Python and that's the most popular programming language there is at the moment. Do you have any reputable sources for this? All I can find are benchmarks run by companies with clear vested interests in showing one language is faster than the other. Also, this isn't quite the strongest argument for its performance; popularity hasn't been tied to performance for a long time (see: all those years No…

Java is one of the most performant languages there is, so I’m not sure what’s your point here.

It is now but was absolutely not at introduction, nor when it started leading charts of "most used languages"

Re: It's not Ruby that's slow, it's your database

#199

Post by supermatt » Thu, Nov 10, 2022, 5:45 PM UTC

tpxl wrote: post #186

supermatt wrote: post #152

Earlier quoted context omitted.

Nope, single digit millisecond performance for me on those nodes when the tables are cached - anything else and you are complaining about performance of the storage medium.

How much data? We were doing a few million writes/day on peak days and the nodes couldn't keep up.

A few million writes a day is still well within the write performance of one of those nodes. But... we were talking about querying the data, no?

Re: It's not Ruby that's slow, it's your database

#200

Post by tpxl » Fri, Nov 11, 2022, 9:26 AM UTC

supermatt wrote: post #199

tpxl wrote: post #186

Earlier quoted context omitted.

How much data? We were doing a few million writes/day on peak days and the nodes couldn't keep up.

A few million writes a day is still well within the write performance of one of those nodes. But... we were talking about querying the data, no?

Well yes, but if your database is busy writing, it's going to have less time for reading.