> most new hires would have no idea how to write a SQL query.

probably why people think rails is slow. our integration partners and our customers are constantly amazed by how fast and efficient our system is. The secret is I know how to write a damn query. you can push a lot of logic that would otherwise be done in the api layer into a query. if done properly with the right indexes, its going to be WAY faster than pulling the data into the api server and doing clumsy data transformations there.

1000%. It’s all about limiting those round trips to the database…

Constructively, I would suggest some areas for study:

- relative speeds of programming languages (https://github.com/niklas-heer/speed-comparison)

- database indexing (https://stackoverflow.com/questions/1108/how-does-database-i...)

- numbers everyone should know (https://news.ycombinator.com/item?id=39658138)

And note that databases are generally written in C.

Constructively, I just wanted to say that you can't claim that something is fast if speed is thanks to something else. OP said people thinks rails is slow but if you have a fast query it's a solved problem. Even python would be fast in this instance with an optimized query

> Even python would be fast in this instance with an optimized query

I wasn't trying to argue that ruby is slow (it objectively is). I was arguing that its slowness is irrelevant for most webapps because you should be offloading most of the load to your database with efficient queries.

Unless the database is in your process's address space (SQLite, Datomic, etc) your first problem is going to be shipping the data from the database server to the application process.

You've correctly identified that filtering a list is slower than looking up from an index. Congratulations.

Thank you, let me give you the eli5: I just wanted to say that you can't claim that something is fast if speed is thanks to something else