[lstodd]

I'm the author, and that's the truth.

Can't see how this can be replicated as a controlled experiment nowadays, unfortunately.

But if you define exactly what's a request, what's a response, and what the connection/response ratio is let's have a race.

Like, you set the parameters, and whoever serves that on lower-capability hardware wins. Py3 plus low-level C/Rust hacks vs Elixir, say.

[dzik]

That's the thing. You can always hack something in C to prove there is a better way for a specific task. In the past I did things like that just for fun. But in the real world it does not work like that. You buy into things as a whole, accepting their pros and cons as a whole. If you need to hack - change your tools.

[lstodd]

Please do not beat the strawman. And don't set him on fire. He's innocent.

I offered to beat whatever you've done by tweaking the Py3 stdlib. Not by writing a plain C implementation.

If you for some reason doubt that this old python thing is of the real world - let me disappoint you. It was done because nothing else could do those 100K rps back then. And it did the thing for five years, until the whole stack was ditched.

[ramchip]

I think you’re misinterpreting the point of the article. It’s not gloating about how much they scale, or saying their particular tech beats other techs. It’s just explaining how to solve a specific scaling issue on a specific platform.

As an Elixir user who had to deal with high connections/s in the past, I found it interesting and useful. I use Elixir for reasons that have nothing to do with performance so a language comparison isn’t particularly interesting.