Doesn't Slack use Java for its messaging system?
That's not mentioned in the blog why they didn't use PHP for this.
Taking PHP Seriously
51–60 of 673 posts
Re: Taking PHP Seriously
#52Earlier quoted context omitted.
Node is actually one case where depending on the project it could be very easy to make a case for PHP :) if you need a simple API backend you can use PHP and not deal with whole async thing.
Actually for that project Node would have an advantage over PHP with job handling and realtime functionality. But currently I only care about a fast MVP.
For "real time" node def. will beat PHP :) But Elixir/Phoenix will destroy either one and thanx to BEAM it's actually can be considered soft real time system.
Re: Taking PHP Seriously
#53For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).
It's extremely mature, stable, reliable, and easy to reason about. Personally I wouldn't choose it but, for a larger company, if you already have engineers that know it - and trust me many will - it's not a bad choice. This is especially true if you are just serving a simple website for a product or service, even basic e-commerce. 90% of websites out there don't need Rails, or Python, or Go, or Node.
Laravel is a pretty solid alternative in PHP vs Rails.
Re: Taking PHP Seriously
#54For greenfield project main question would be why? It's not horrible but what do you exactly gain? With so many options around it's actually hard to make a case for PHP (and I have being using it since 2000).
I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.
hmm, node has a lot less involved with getting up and running than PHP
but you'll probably spend a few hours stuck with npm the first inevitable time a package doesn't work as expected
Re: Taking PHP Seriously
#55Well this is seriously making me rethink my opinion on the PHP workflow, if Hack is as much of a game changer as the article claims? Could anyone here comment on their experiences with it, and its pitfalls?
You're asking about Hack, and the only response I see so far is about HHVM. So!
I've seen Hack used in a multi-tens-of-MLOC codebase to gradually insert types. It made huge differences in the kinds of changes that were possible; you can, e.g., rename a class or method, or change the order of its arguments, with confidence comparable to that in a C++ codebase. Most developers hack-ified everything they could get their hands on, and did all new work in Hack, without any external encouragement.
Re: Taking PHP Seriously
#56The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…
> So what's the catch? About 2-3 orders of magnitude in performance. That’s the catch. And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc. And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framewor…
That 2-3 orders of magnitude difference is in an area that runs pretty quickly however.
People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
Re: Taking PHP Seriously
#57> a typical Python application server, e.g., the debugging
> cycle will look something like “think; edit; restart the
> server; send some test requests.”
the "most typical" Python stack (wouldn't call it a application server) is probably built with Django where you don't reason about the Server restart, it's as fast as changing something in PHP.
P.S.: I don't use Python that much anymore. Other people would say that the thing I'm using now takes endlessly long to compile and has some wierd operators.
Re: Taking PHP Seriously
#58Earlier quoted context omitted.
I'm currently hesitating between PHP and Node.js for a new side project and I'm leaning towards PHP simple because I could do it 50% faster due to my experience with it.
hmm, node has a lot less involved with getting up and running than PHP but you'll probably spend a few hours stuck with npm the first inevitable time a package doesn't work as expected
We run Nginx in front of both node and PHP so can't say it takes significantly less time to setup node then PHP for production use. Composer is a reasonable take (reapoff? :)) of npm. Yarn seams really nice though.
Re: Taking PHP Seriously
#59The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…
Elixir and the Phoenix framework work like this, with a process spawned per request.
'Process' is an extremely overloaded term. It's more of a green thread for Erlang VM applications.
Re: Taking PHP Seriously
#60Earlier quoted context omitted.
> So what's the catch? About 2-3 orders of magnitude in performance. That’s the catch. And it’s the reason why even with PHP you use things as opcaches, cache database results in external daemons, you use process pools with fastcgi instead of actually creating new processes, etc. And hacking those things on top of PHP make your program even worse to reason about than just using a daemonized system with actor framewor…
That 2-3 orders of magnitude difference is in an area that runs pretty quickly however. People go to a lot of trouble to optimize the front end system, but tie it all to the same database that bottlenecks well before the web server. There are certainly times where PHP or CGI aren't fast enough for the job, but I think people tend to unfairly blame them in situations where the underlying problem is more systematic.
> but tie it all to the same database that bottlenecks well before the web server
that's not true. especially not in the DaaS space.