Taking PHP Seriously (2016)
slack.engineering
slack.engineering
* https://news.ycombinator.com/item?id=12703751
* https://news.ycombinator.com/item?id=15262981
PS. Would you mind adding a [2016] in the title? It will show readers they probably need to take a historic context to understand the article correctly.
I have yet to work a day job in Rust, but I've worked in Java, C++ and Go so I'd be quite confident applying to a Rust position as long as it wasn't specifically security focused... I would be less confident in how quickly I could pickup Prolog - I think my brain works well for the nuances of the language but I'm less certain.
A lot of interns end up using php(symfony). If they know Perl or Java they can pretty much jump right in. Python they take a little bit though not much more.
When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.
PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.
"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).
"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).
I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?
Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.
Chewing through TBs of data every hour? Probably not a good idea to use Ruby.
Doing a bunch of really heavy math? Probably not a good idea to choose PHP.
Doing a SaaS service? C++ probably isn't a good choice.
There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply them everywhere.
In fact I think there are certain organizational benefits to partitioning your language use by skills required to maintain that section of code. When you're a startup there's no benefit at all, but as companies grow you can use that to smoothly transition into separate teams with different expectations around testing and feature flexibility.
PHP is faster than Ruby. [1]
PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2]
PHP is an extremely popular language as the backend for SaaS, and arguably one of the oldest and most successful. [3]
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
[3] https://insights.stackoverflow.com/survey/2020#most-popular-...
It's not helpful to be faster than the language that the parent implied wasn't fast enough.
I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.
More generally, "it depends".
I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)
I suspect they meant the kind of heavy math that the PHP 8.x JIT is trying to improve performance for.
It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.
I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.
Meta-programming? Yes. Object-oriented programming? Meh. CLOS is nice, but not vastly superior to anything else. Something else? Depends on what that something is.
I spent a lot of my career consulting as a mess cleaner, more or less, and even very smart people end up making a mess sometimes. Time constraints, shifting goal posts, all of it.
I’d say the worst thing I ever see, regardless of tools, is premature optimization getting in the way of everything else.
A "smart" and/or a "senior" programmer knows not to optimize prematurely.
But maybe I latched only on this one sentence and missed your point. Sorry if that's the case.
Languages like Java, Node, C#, etc are great but unlike PHP you can't just drag and drop a .php file on a webserver, point your browser at it and go.
Basic things required for web development like connecting to a MySQL database are made trivial in PHP.
Code is executed synchronously in PHP and as mentioned in this article requests are stateless which makes the logic much easier to follow and debug than say Java where you have state or Node where you have callbacks and promises.
PHP also gives you the flexibility to write procedural, OO, or even functional code. This flexibility is off putting to some, but it allows the language to be useful no matter what your skill level or preferences are.
Another thing that's easy with PHP is debugging. You don't have to worry about compiling code or accidentally taking down your entire server (most of the time) if you encounter a critical error. If one of your PHP pages runs into an issue you can enable debugging with a line of code, make your fix then hit the refresh to see if it's working.
I learnt to code writing PHP when I was 16 years old. Me and my friend had an idea for a startup but neither of knew how to program beyond a little bit of ActionScript. We were good with computers, but if we decided to use Java I'm certain the project would have never have gotten off the ground because of the steep learning curve.
PHP allowed us to skill up with the language and enabled us to move fast despite not really knowing what we were doing. Writing PHP in the ICT room at lunch with my friend was some of the best memories I have of school... I doubt I'd be doing this today if it wasn't for how much fun I had learning and building stuff with PHP when I was younger.
"Trivial to connect to a database" isn't a selling point. It is a liability when put in the hands of inexperienced programmers.
It's a perfectly reasonable choice for web development, just like a Chevy Caprice is a perfectly reasonable car for a taxi service (as evidenced by the thousands of them in NYC, still plodding along). You'd still rather ride in a Mercedes E430 taxi (long time European standard)... unless you had never experienced both, in which case you probably think the Caprice is just fine.
And if you knew Ruby, Python, Java, C#, Kotlin, or better yet F#, Clojure, or Elixir, you'd most likely enjoy using one of them rather than PHP.
There are three reasons to use PHP.
1. it works
2. it is well integrated with web servers
3. you can find some of the cheapest contract labor who know how to program in it (compared to other, less common/popular languages)
Bonus 4. you need to extend Wordpress by writing a plugin or theme (and Wordpress is the Caprice of CMSs...)
15 years of PHP dev work. Games, mobile apps, health care, etc. I have been unemployed for 2 days in 15 years. PHP runs %80 of the internet. Talk to anyone at facebook that wears a suit on friday -- they code PHP (and it seems to scale for them). I think I will be 90 years old hacking on PHP.If you really don't like how the arguments are passed just use an IDE. Or get stuck with real problems like a transition from python2 to 3. (wtf)
PHP doesn't run in the browser. For browser programming there's literally almost no choice. TypeScript seems to be an improvement but even that compiles down to JS. Same for ReasonML and BuckleScript and Elm.
Kinda funny having php devs shit on python backwards-compat
I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overreliance on C extensions for speed ...), haven't changed. As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content.
I lol'd.
SPAs are a fad. Apps that rely heavily on REST API and browser rendering rank terribly on Google.
Create a SPA and help your customers discover your competitor on the first page of Google.
Generally, when I'm building a business, I prefer not to assume that Google will eventually, at some point in the future, solve the crawling a SPA site problem and finally discover my site.
I'd rather get my 70%-80% organic search traffic today, with any boring server-side rendered tech stack.
Why people use js/spa/etc stuff as the basis for a content/marketing site... I don't know. I mean... yeah, I know why - mostly to expand their skill set. But there's usually no functional benefit, and usually some drawbacks, as you're pointing out.
SPAs are great if your customers actually want an application. Figma, AirTable, Google Sheets. These don't make sense as server rendered pages.
If you're in the publishing business and need your articles to rank high on Google, then yeah its probably not a good idea.
EDIT: Or Slack for that matter
The question is: so what if PHP even has caught up? What could I possibly gain from going back to it? I would have to rebuild context and learn a whole new web framework in a language whose syntax I personally do not enjoy. So no matter how good it's become, it's totally not worth my time and energy to switch back to it.
> By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.
Is there a modern web framework where a failed request can crash the entire server? I'm not sure this is a problem in other languages.
> Second, concurrency. An individual web request runs in a single PHP thread.
Huh, so maybe this could be an interesting concurrency model. But it's not that different than say, Node's promises. The only difference is Node's promises aren't tied to literally making a web request.
The restarting the server problem also is not an issue. Almost every mature web stack I've seen has hot reloading. Yes, even in 2016.
There are certainly reasons to use PHP, but the trap I see a lot of PHP proponents fall into is assuming that the benefits they see are somehow unique to PHP. Laravel fans love to cite packages, migrations, the ORM, etc. as reasons to use PHP. I certainly think all of these are great features but they're not unique to PHP.
Erlang/Elixir (or any BEAM language) runs every request in a separate green thread which scales much better than OS threads since most of those green threads can be generously multiplexed on just 4-8 CPU cores due to 90% of the time being spent waiting on a database.
One OS thread per request is such a... strange thing to brag about in 2020.
For web development though, not really. Elixir is much better there and I am saying this as a guy who had 8 years with Java and 6.5 years with Ruby on Rails (and consulted and helped 10+ PHP and JS projects in the meantime).
That being said, at some point in 2010-2015 timeline it became essential to master Javascript to do anything good on the web, and so it became a diversion of precious resources to continue to invest in PHP as well.
Instead the progression has just been to recreate the PHP high level architecture in Javascript/nodejs.
So we took the best parts of PHP and brought them to NodeJs land, and then you can cut your costs because you don't have to learn or invest in the full PHP stack.
I imagine async of Node may help somewhat.
I love it. My professional career moved to .NET and Python over the last decade, but if I'm building for myself, I build in PHP.
Whatever foibles people claim are in PHP are really just personal gripes about features they don't like, while ignoring all the other pieces that are ideal for web API development. Frankly, I believe first-class duck-typing and nearly-zero impedance with JSON make PHP a first-class citizen of the web. Duck-typing pairs so well with dynamic typing that I don't know why so many languages abuse themselves with the alternatives.
I remember the Docker switchover being very confusing. Why do all these people need such elaborate instrumentation around their development environments? With PHP, the kitchen sink is always there, and always consistent (we'll ignore money_format() for now). Once I really started using other language environments, the pain points that necessitated Docker cropped up, and of course the deployment benefits are excellent. It was just a very confusing couple years trying to figure out why the Node and Python guys were living like animals.
Anyways, cheers to another 20.
I’m trying so hard not to rant here, so I just wanted to confirm that those are the only positives he outlines about the language.
I think it's a superior model to the long-running application. Unless your company has 0 developers in it who make a memory leak, or make a fatal uncaught exception.
In fact, the popular PHP-FPM way to host PHP does just that.
If you want to take it to the extreme, there's always CGI, of course.
Plenty of languages have support for hot reloading, which means you can just edit, save, refresh exactly the same as in PHP, with the added benefit of not having to use PHP.
I agree wholeheartedly with this. I prefer statically-typed languages w/ a bit of local inference (I end up in java usually, but C# got it right) and I consistently see people in my world underestimate the edit/reload workflow. Even a small compilation step is enough to break flow and make development a chore, once you've worked that way.
As a side note: java not allowing signature changes and requiring a whole server restart is absolutely awful. It didn't have to be this way: the DCEVM[1] was presented at the 2009 JVM Language Summit[2], by Thomas Wuerthinger. He patiently demonstrated and explained how his work allowed for hot swap of arbitrary class changes, while the Sun guys sitting in the audience told him that what he was demonstrating was impossible. We ended up using the DCEVM for a long time, but as of right now I'm back to restarting my server when I make breaking changes. It's a funny world.
¯\_(ツ)_/¯
[1] - This is a modern fork of the project: https://dcevm.github.io/
I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
This virtue was incredibly valuable to me when I was throwing a website together with ducttape and bubble gum and it was the only way (that I knew of) to be able to clearly and quickly see the results of my changes. With tests in the picture I think it loses a lot of that value - it still has some since nobody likes writing front-end tests but most of your code changes should be "proven" by some level of automated test coverage.
Well, in that case then you'd be in a much better position to answer than I am.
I write tests, too. I guess I'm not as good of a software developer - because just as my code has bugs and unexpected edge cases, so do my tests, and they don't catch every mistake I made, since I'm the one making them.
Not that hard, there's a bias showing.
First, those things you've mentioned are nothing to sneer at, are actual very good decisions (even if accidental) for a webserver-centric language.
They enable even naive developers to achive good scalability and isolation, and make fast development/debug cycles trivial.
Second, PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language - all of the above points are already made in TFA.
Most arguments against it are moot today, or only apply superficially to the standard library, not the language (order of arguments, and so on).
Plus, it is speedy too, post 6, and especially post 7 (and there's a whole new JIT in 8). In any case, it has constant work on speed and memory reduction.
And of course it has a huge ecosystem of libs, projects, and frameworks, including not available anywhere else projects like Wordpress.
And the standard library (warts included) between JSON, DB drivers, LDAP support, SMTP, etc., is one of the most complete ones this side of Python, and perhaps even fitter than Python's for typical web development work.
Plus the deployment model is one of the best. Copy your files to a directory. Done. Add a redirect instruction to your server if you want to make it more fancy...
For third party libs, composer is up there with any major package dependency/install solution.
And for the core libs, plugins, etc installation is handled perfectly by the standard package managers in all Linux distros (and probably Windows too), and is even easier with MAMP, WAMP, etc for local development. Trivial to dockerize too if that's your thing.
No, most of bad parts are still here, all the stdlib inconsistancies and co are still here. Just because add more functions to a language doesn't change the bad design decisions at its core. The weird mix between dynamic typing and Java style rigidity (without most of its benefits) didn't go away.
What makes it a different language since PHP 5? more type guards? no, it's still a templating language.
The mixed typing is... honestly, it's amazing. You really need to try it out for yourself in PHP7 or 8 - you can lean on really strict type checking in your application, go the old route or generally adhere to strict typing and relax that for entry points and library calls.
Lastly, PHP has come down hard and actually introduced backwards compatibility in a few key places to address some of the biggest WATs, I've been pretty impressed by the balance of the language stewardship.
It does definitely have warts, but there are warts on everything that people actually use in industry.
PHP has some great properties, and if you're tolerant of its sharp edges, great. But up until recently (and perhaps still?) it's got many of its safeties turned off by default. When I left PHP, (insecure) mysql bindings still came included pretty much universally, but often not PDO. They have every amazing helper function under the sun at your fingertips (urlencode and htmlentities!) but also some tremendously dangerous ones (backticks! variable variables!).
What's most striking to me is that Slack is 100% off of PHP now (onto Hack). There's something telling when neither the syntax nor the runtime nor the standard library are sufficient for the biggest users of a language. With recent versions of the core runtime finally getting fast, I wonder if they'll rip off the bandaid and break backwards compatibility to dull some of the larger sharp edges.
Unfortunately PHP is more capable as a language than shells while still having all those poorly thought out parts that will make you hate it if you try to exploit it to it's full capability.
Of course this mind set doesn't help much for existing massive code bases where all of the application logic is written in PHP.
It was somewhat amusing to see some of the same people that made fun of this later espouse the virtues of AWS Lambda.
Combine it with Laravel and nginx, and you've got an enjoyable stack in my opinion.
Does anyone start a new php project without a framework these days? There are some great ones (Laravel, Symfony, PimCore, etc.).
I would personally love to get beyond that bias. However, every single time I install any piece of software written in PHP, it's simply a nightmare (e.g. Matomo, rss-bridge).
Unhelpful error messages, unexplained or undocumented features, all held together with metaphorical duct tape.
I always have to dive into the source code to figure out things that a README or tutorial should be able to help me with.
I can't recall ever doing that with tools written in any other language.
Is it simply that PHP programmers care so little about their products?
I have the same opinion about Python btw. Just today I had to install a complex toolkit for flashing ROMs and you can guess that thing absolutely didn't work on the first try and I learned much more about "pip" than I ever wanted to.
But when looking at PHP in terms of deployment and making traditional SQL-based websites/API's it's unmatched. Just reading up on deploying Python code using uWSGI, or connecting to a SQL database gives me headaches, and the confusing package management and versioning system makes things even worse. Running Node feels unpredictable, with the server crashing because you forgot to catch an exception somewhere or having some weird state.
With PHP it's just: write the code, copy the files to a server and stuff (usually) just works. That's why i keep using it. Not that pretty, but it always gets the job done.
Can anyone explain this to me? I know if a string starts with the number, PHP takes the number part and throws the rest, so "0123foo" should be 0123 for the comparison, so why is that false?
[Incorrect original post: 0123 evaluates to the integer value 123]
We already know the painfully obvious answer to this question even if it's not listed in the "reasons": because the technology decision makers were comfortable with PHP and they wanted to use it.
"Whew... we're all totally psyched with node, and all have experience with it, know how to solve problems with it... but we're going to commit to Django. We don't want to, but we're going to."
Does that exchange ever happen? I've seen the opposite - almost every tech stack I've seen at small and medium sized companies was primarily the result of the few decision makers who had experiences (good or bad) with specific tech which influenced their decision to use X.
Not that big a deal at all.
presumably if it's a thread per websocket then they're using something else to serve that?
It's helpful to be able to reuse some domain code between the two if necessary, but IO cannot be done the same in ReactPHP because it needs to be async. Good news is ReactPHP has a ton of really great async libs (mysql, redis, etc.) https://reactphp.org/
As others have said, Swoole is also an option, it's more like Go (coroutine style). Personally, I think it's super cool, but not something I want to use, because the majority of the userbase is chinese and the docs and ecosystem suffer from the language barrier.
All written in PHP.
I'm not sure what relevance that has to this article. I could name a lot more software written in PHP that is poor. Does that tell us anything about PHP itself? I don't think so.