4 ms·

By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box. At this point there was no noticeab

By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box. At this point there was no noticeable increase in response time. I could have probably gone much higher but that was enough for my needs so I stopped. My "secret" is to use a language that is not slow-as-mollasses. A decade ago Rails had a definite productivity advantage over the (mostly Java) web frameworks of the time. That hasn't been true for a while, and there are many performant alternatives. If you're culturally a Ruby or Python programmer you can go pick up Go, or Node, or Elixir and feel at home. If you live in JVM or FP land you've always had fast alternatives (in my case it was Scala). You pay a one-time cost to learn new things but you reap the benefits forever.

fasouto 10y ago
While I agree that some languages could speed things up I think the bottleneck in the majority of the webapps is the access to storage. A propper indexed DB or a cache will be much effective most of the times.
- collyw 10y ago
  Having a decent idea of how a language / framework works would make a big difference a lot of the time. I have seen a lot where joins are essentially done at the application level in loops in the relatively slow language.
  - human_error 10y ago
    > I have seen a lot where joins are essentially done at the application level in loops in the relatively slow language That's an indication of poor programming skills rather than programming language being "slow".
nickjj 10y ago
> If you're culturally a Ruby or Python programmer you can go pick up Go / Elixir And then you're 10 years behind the curve when it comes to community support which is really the only thing that matters when it comes to being productive. That's 10 years of less blog posts, tutorials and most importantly third party gems / packages that have been extracted from many years of real world use cases.
- matt4077 10y ago
  I think phoenix itself is proof that it can be a lot faster the second time around (I'm one of those heretics who believe it's a pretty clever react clone with an added layer of cool innovation). The libraries seem to be filling out quite quickly – and libraries may be a long tail problem. The set of 10 to 15 requirements every project has is basically there.
  - asdf1234 10y ago
    > The set of 10 to 15 requirements every project has is basically there. Even a lot of the really basic stuff like file uploading and image handling libraries aren't in a good state yet. For example, there's nothing that comes close to Carrierwave, Paperclip or Shrine and the Image Magick libraries are nowhere close to their equivalents in Ruby or Python.
    - nickjj 10y ago
      Yep and this is the problem. Initial library support isn't close to enough. It needs to be extracted from a real project and then carefully groomed and enhanced based on real problems. Otherwise you're just sitting there trying to invent something with no use case. You can't invent a beautiful API or account for edge cases that you don't even know exist. This is why Rails will be around and thriving for another 10 years. Until something so drastic comes along that it fully disrupts everything we know about web development, I will still reach for Rails. Right now all of these alternative solutions in other languages aren't offering enough benefits to even think about switching. P.S., I'm not even a Rails fanboy. I use other techs too and tried to get on the bandwagon with Node back in the early days and did the same thing with Go. It took a long time to realize how much of an utter waste of time it is to chase the new shiny thing.
asdf1234 10y ago
> That hasn't been true for a while For building a traditional monolithic website with server side rendering Rails and Django are far faster to develop in than anything in Go, Java or Node and the overwhelming majority of websites will never run into any performance problems with either. > By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box I have Rails applications that hit the database on every request doing 1000 rps on $10 a month Digital Ocean boxes. 1000 rps is not that much and all of these performance metrics are meaningless without extensive knowledge of how the application works and exactly what it is doing.
true_religion 10y ago
Just to answer 'why use Python' from the perspective of someone who uses both Python, Node, and Elixir regularly.... Python has a lot of rich libraries in a broad range of topics. It may not have the very best or fastest library in each topic, but it has at least one powerful easy to use library for anything you can think of. This pretty much makes Python my go-to for explorative programming, or large-application development. The performance intensive parts can always become extensions (thanks to Cython), or be services written in Elixir or Java.

fasouto 10y ago

While I agree that some languages could speed things up I think the bottleneck in the majority of the webapps is the access to storage. A propper indexed DB or a cache will be much effective most of the times.

collyw 10y ago
Having a decent idea of how a language / framework works would make a big difference a lot of the time. I have seen a lot where joins are essentially done at the application level in loops in the relatively slow language.
- human_error 10y ago
  > I have seen a lot where joins are essentially done at the application level in loops in the relatively slow language That's an indication of poor programming skills rather than programming language being "slow".

nickjj 10y ago

> If you're culturally a Ruby or Python programmer you can go pick up Go / Elixir And then you're 10 years behind the curve when it comes to community support which is really the only thing that matters when it comes to being productive. That's 10 years of less blog posts, tutorials and most importantly third party gems / packages that have been extracted from many years of real world use cases.

matt4077 10y ago
I think phoenix itself is proof that it can be a lot faster the second time around (I'm one of those heretics who believe it's a pretty clever react clone with an added layer of cool innovation). The libraries seem to be filling out quite quickly – and libraries may be a long tail problem. The set of 10 to 15 requirements every project has is basically there.
- asdf1234 10y ago
  > The set of 10 to 15 requirements every project has is basically there. Even a lot of the really basic stuff like file uploading and image handling libraries aren't in a good state yet. For example, there's nothing that comes close to Carrierwave, Paperclip or Shrine and the Image Magick libraries are nowhere close to their equivalents in Ruby or Python.
  - nickjj 10y ago
    Yep and this is the problem. Initial library support isn't close to enough. It needs to be extracted from a real project and then carefully groomed and enhanced based on real problems. Otherwise you're just sitting there trying to invent something with no use case. You can't invent a beautiful API or account for edge cases that you don't even know exist. This is why Rails will be around and thriving for another 10 years. Until something so drastic comes along that it fully disrupts everything we know about web development, I will still reach for Rails. Right now all of these alternative solutions in other languages aren't offering enough benefits to even think about switching. P.S., I'm not even a Rails fanboy. I use other techs too and tried to get on the bandwagon with Node back in the early days and did the same thing with Go. It took a long time to realize how much of an utter waste of time it is to chase the new shiny thing.

asdf1234 10y ago

> That hasn't been true for a while For building a traditional monolithic website with server side rendering Rails and Django are far faster to develop in than anything in Go, Java or Node and the overwhelming majority of websites will never run into any performance problems with either. > By way of contrast several years ago I benchmarked a real application hitting 1000 requests/s on a $20 per month Linode box I have Rails applications that hit the database on every request doing 1000 rps on $10 a month Digital Ocean boxes. 1000 rps is not that much and all of these performance metrics are meaningless without extensive knowledge of how the application works and exactly what it is doing.

true_religion 10y ago

Just to answer 'why use Python' from the perspective of someone who uses both Python, Node, and Elixir regularly.... Python has a lot of rich libraries in a broad range of topics. It may not have the very best or fastest library in each topic, but it has at least one powerful easy to use library for anything you can think of. This pretty much makes Python my go-to for explorative programming, or large-application development. The performance intensive parts can always become extensions (thanks to Cython), or be services written in Elixir or Java.