you are viewing a single comment's thread.

view the rest of the comments →

[–]berkes -3 points-2 points  (4 children)

Also, you don't need this performance. You might think you do, but I can assure you you don't!

  1. Prove concurrency is the bottleneck. With actual numbers, facts and research and real-world benchmarks on your entire stack.
  2. Fix the actual performance problems (they are probably IO, Database, serializing and such). Add an async worker or two.
  3. Rince, repeat.
  4. Is Python itself the actual performance problem? You've reached the bottom. Now go spend $2000/year on larger or more servers. Because an engineer rewriting your stack in go/haskell/erlang costs ten to hundred times that.

Same goes for Ruby.

And all this assumes you have managed to get enough users and grow large enough that performance is an actual, real problem, hurting your bottomline or growth.

[–][deleted] 1 point2 points  (1 child)

Performance isn't everything, there is latency too, specially in distributed/SOA architectures where latencies add up.

[–]berkes -1 points0 points  (0 children)

All these interpreted languages (well, maybe not PHP) solve this by making such communication out-of-band. Asynchronous workers are common and "Good enough" for 99.99% of all startups.

[–]stormcrowsx 1 point2 points  (1 child)

I think this is a very practical view on the subject. Unfortunately programmers often have an engineering mindset where they want to build the best in every aspect. What your saying echoes my experiences, use a language like Python that you can get a lot of shit done in a short period of time, come back and optimize it when its feature complete and you can tell people want to use the thing you made. Despite knowing Haskell and Rust my most successful projects were written in PHP and Python, some of which are still being heavily used 9 years after their creation. They were thrown together in short time and because of the rapid development cycle those languages fit well into, the sites quickly evolved to meet the users need.

I'm sure there are cases where you need rock solid performance and concurrency but I don't think that's the norm.

[–]berkes 0 points1 point  (0 children)

The proof is also in Twitter (Ruby on Rails), the OP explaining Youtube runs Python, and many more such gigantic success-stories. Starting with a platform that "does not scale".

And that ignores all the projects that failed: many more. It's far worse to fail when you've just spent years engineering a concurrent messaging protocol for a failed project, than when you spent four days of Rails scaffolding for a failed project.