PHP 8.0.0 beta 2
php.net
php.net
It is one of the best choices (if not the best choice) for rapid prototyping of a program. Its damn fast to similar alternatives (Python, Ruby, Dart, JavaScript), and the standard library is huge.
It does have footguns. I am not a fan of the loose typing, but you can take some steps to mitigate. You can do "===", "strict_types" and type hinting for function input and output. It is similar to C in that the language itself doesnt really do much to stop you from writing bad code. Also the function naming is not consistent, and even function arguments are not consistent. However PHP 8 will help with that somewhat, as you can now do named arguments.
Also PHP has the best language documentation I have ever seen. I would prefer more examples, but its well above some other languages.
PHP is basically a wrapper of C modules.
String functions are ($haystack,$needle)
Array functions are ($needle, $haystack)
Because that's the way the underlying modules worked. I had used PHP for a long time without realizing this.
https://wiki.php.net/rfc/string_to_number_comparison https://wiki.php.net/rfc/saner-numeric-strings
In addition more internal functions throw exceptions instead of notice+return false on completly invalid arguments:
Other than that, PHP is rock solid when it comes to web stuff.
You must be a fast learner then, when 5 minutes is too much.
I keep hearing about how the language has improved, but to me it feels like even if the language gets rid of all its heaps of crap, it still is in a evolutionary dead-end. Is there anything that PHP is developing or adopting that can not be had at other established languages?
(Edit: I never had something downvoted so fast before. This is not concern trolling. I seriously would like to know if it makes sense for a non-PHP developer to look into it)
Modern cryptography is baked in since 7.2.
https://libsodium.gitbook.io/doc/bindings_for_other_language...
Most of the people who shit on PHP have a lot of love for other languages. A survey of the cryptography features the "favored" languages offer will almost certainly fall into two camps:
1. "We wrap OpenSSL"
2. "Go compile it yourself" (i.e. there is nothing baked in)
There's a lot of badness with OpenSSL's API design, especially with asymmetric cryptography. For a fun exercise in these languages, try encrypting with RSA with OAEP padding, but without using SHA1 as your hash function.
For completeness, PHP is one of the languages that wraps OpenSSL too! But it also wraps libsodium, and the community has been moving towards libsodium (unless they need something from OpenSSL for the sake of backwards compatibility) since early in the 7.x series.
If you're going to provide cryptography features in your language, but you aren't shipping modern cryptography in your standard library, you're underperforming what PHP has offered for years at this point. The easiest way to meet the standard that PHP 7.2+ establishes is to add libsodium to your language's standard library.
(There are salient arguments for "why even provide a cryptography feature as part of the language at all?" but most of the languages that see real world deployment are already doing that.)
PHP 5 was released 16 years ago and was a massive evolution of the language. The same is true for PHP 5.2, 5.3, and 7. It's safe to say that your conclusions about the language are no longer accurate.
> Is there anything that PHP is developing or adopting that can not be had at other established languages?
No. I can't think of any reason to start a new project with PHP today. All of its best features are things that have been available in other languages for years. It's also not particularly popular outside of WordPress.
May not be as popular as React/Flask backends, but it ain't nothing.
> infinite number of websites built in PHP and never got hacked!
If I look at the logs of my webservers and scan for bots trying to exploit some vulnerability, I would guess that 80%+ of the URLs would indicate a PHP-based webapp. So, yeah, there are many that never got hacked but there are certainly a good amount of PHP apps that have some vulnerability. Should we blame all the developers who were "doing it wrong" or should we at least make sure that the language is not facilitating such shots-in-their-feet?
But php has been around on the web for a long time as well, so there are a lot of unpatched softwares out there like WordPress.
Probably near 99% of those compromised servers run on Linux, so by your logic, Linux is much more secure than windows servers, right?
You'd have to assume that there is an uniform distribution of vulnerabilities and exploits through the whole set of languages used for web development for that to hold. You are begging the question.
> 99% of those compromised servers run on Linux
If the exploits manage to give the attacker root access to the OS, then yes it would be the problem of the OS. But the attack is to get access to the application. So the issue is at the application, not at the OS. You can argue that this is not the fault of the language, though. However given that a whole lot of the PHP defenders here are using "it is the easiest one to deploy" argument, one has to wonder if a platform that makes it so easy to deploy apps should also be held up for the issue of insecure apps based on it.
I know of no other language that lets you deploy a web app by dragging some files from the left to the right in FileZilla. No setup, No vendor lock in, no nothing. It just works.
Cross-cloud serverless frameworks that wrap AWS lambda + competitors get you somewhat close in other languages, but you still have a lot more setup to go through, and lot fewer hosting providers to choose from.
PHP's deployment and execution models really set it apart.
Deployment is not that simple.
Or, if it is, then you have to allow me the same grace of just being able to plop my Go or Rust binary on that server and have it magically work. It might even work BETTER because I don't need to check if my php.ini matches my dev machine.
No, not really, but it's still very good for casual web development, which makes up the lion's share of all backend code being written today.
Languages don't need to evolve a ton to be popular – just look at Python, which is doing very well despite not having had a ton of radical changes.
Python as a language hasn't changed much, but it made huge strides into the scientific community and got a lot of marketshare from ecosystems like R and Matlab. It's becoming king in the ML/AI side. Go is growing in the backend systems/devops stuff that used to be the realm of Python. Rust is getting more and more adoption as a systems language and focus on safety. Even Java seems to be adopting things that make it less bureaucratic while being general enough for the enterprise.
I am not saying that PHP has to go away or anything. It's just that I wished that new releases could have more interesting things to say besides "it's not as crappy as it used to be".
I don't think there are many people in PHP's orbit who want it to be a better Python, or a better Perl/Ruby/JavaScript.
PHP was written to be a good language for average web development, and I think that's where it will always shine. I'm perfectly happy with a gradual process of making it less crappy.
Having said that, I'd love some of Hack's features (e.g. reified generics, proper list/dict primitives) to make it into PHP.
IMO, no. The language is still near the bottom for both dynamic and "static" typed languages. HOWEVER, if you're doing web backend stuff, Laravel and Symfony are both really solid frameworks.
The direction PHP Is moving in right now is to emulate Java 7, but without generics or concurrency. It's definitely a dead-end unless they come up with something pretty novel and change direction (again).
Why do you say that? It's faster than Python and Ruby for most cases, still extremely simple to deploy, the package manager (Composer) is very predictable and easy to deal with compared to Pip or Rubygems, the documentation is good, etc.
It has clean lambda functions that you can pass around easily and has for more than a decade. Type hinting has been in place for a long time, too, as have enough OOP / reflection constructs to do just about anything you'd reasonably want to do in a language aimed primarily for web development.
The only downside of PHP that I can still point to is that it's sometimes hard to remember the function parameter order for some of the common string and array functions. Far from a dealbreaker, that.
it spawns a new php interpreter for every request, which means for example that symfony framework setup (routes, controllers, service dependencies...) have to run before every request. Sure it does that faster than python, but python only needs to do this once.
deployment is my personal nightmare. try to set the max children or whatever so concurrency is ok but memory does not run out. I mean facebook did it so it has to be possible but damn, that was hard to get `right`. Setting up logging is a mess. There is the application, the admin and the fpm error log, I gave up trying to have every log event logged exactly once. Segfaults are a common occurrence, still. I heard it mentioned just before leaving for vacation.
To be fair the last time I seriously worked with PHP was back when mod_php was still cool. I was able to serve thousands of users on a dual-core Xeon box ~15 years ago - I can only imagine the performance is better in many ways now.
The type system is weaker than Java, which is a low bar.
It has no generics, which means no real containers, no generic functions without dropping all typing, no type-hinted arrays.
Arrays are also not objects, so they don't conform to any interfaces, which is related to the "no real containers" issue.
It took until version 7.4 to actually have covariance and contravariance! Before that it didn't even implement inheritance correctly!
You can't typehint for function-as-param beyond just writing `callable`. So if you want to use those nice lambdas and still be statically typed, you're SOL.
It's definitely fast for a scripting language! So, that's fair. But it's still way slower than many other good backend languages: Java and other JVM languages: Kotlin, Scala, maybe Clojure?, Go, Rust if you're feeling frisky.
I've never used Ruby and I'm generally biased against dynamically typed languages, so that's the background for my assessment. The dynamic languages I've used in anger are Python, JavaScript, Elixir, and Clojure.
The package manager is better than the disaster that Python was the last time I used it. Agreed. It's also better than NPM, but not enough to matter most of the time. It's not better than Hex or Lein. Also, managing packages is a) not the language, which is what I criticized, and b) not where you spend most, or even a large part, of your dev time.
Looking at PHP as a dynamic language, I'd say that the built-in array is still a huge disappointment and the API sucks compared to either of Python's dict or list. It's much cleaner in JavaScript, Clojure, Elixir, and Python to define and operate on new, untyped, objects.
Also, for a dynamic language, I'd at least want SOME benefit to it being dynamic. For JS, Clojure, Elixir, and Python, the REPLs are great. The PHP REPL is... primitive.
None of the things you mentioned in PHP are actually better than any other language I've used except for the package manager. Its lambdas are not even better than any of the languages I've listed. In 2020, decent lambda syntax is table-stakes.
These things are a little advanced for the likes of me. Any chance you'd be so kind as to give me an example of something I can't easily do because of not having this?
> It's definitely fast for a scripting language! So, that's fair. But it's still way slower than many other good backend languages
But those languages require compilation and deploy cycles that are way longer than just getting files on disk, so the total cycle time of development may end up being longer in many cases. It's a tradeoff. PHP probably shouldn't be used for performance-critical things, sure, but then neither should any other dynamic language.
Well, you can do whatever you want in a dynamically typed language. I was discussing the shortcomings if you choose to use PHP's type system.
If I'm using my static types and see `function foo(): Bar` I take comfort that I will receive a `Bar`. If I see `function foo(): array` I have absolutely no idea what that array is. Is it a list of `Bar`? Is it a dictionary of some kind? Is it a heterogeneous list of bools, ints, and Maseratis?
Also, real containers are useful. A true array is a contiguous slab of memory. PHP's array is not. The performance characteristics will be very different. If you had a `Set<T>` type, you could guarantee that there are no duplicates in the set. That is sometimes very useful. No such thing in PHP. PHP arrays can't even be used as a real `Map<String, T>` because if you do `$arr["1"] = new T()`, it wont actually have "1" as a key! It'll transform the "1" into 1 and store it in the 1th slot, like an array!!! Totally flipping useless.
> But those languages require compilation and deploy cycles that are way longer than just getting files on disk, so the total cycle time of development may end up being longer in many cases.
Are you suggesting that you write PHP code and then plop in on a production server without running tests? Because running your tests is comparable to the compile cycle of Java et al. Except in those cases I don't have to write entire classes of tests, whereas you should be writing type-checking-style tests on your PHP code. You just have to be the compiler to make sure your inputs are validated correctly.
> PHP probably shouldn't be used for performance-critical things, sure, but then neither should any other dynamic language.
Then what was the point in comparing PHP's speed to Python? They're both slow and shouldn't be used for performance-critical things. That's fine, but then find me a selling point.
Hardly. PHP-FPM is a confusing mess to set up, and you're still stuck working around the massive mistake of binding routing to the file system.
And I hope you don't try to just rsync up your changes afterwards without some form of blue/green deployments.
> the documentation is good
There is.. a lot of it, for better or worse. Let's compare the functions for concatenating lists between PHP[0] and Scala[1]. The PHP version is way longer and contains several examples.. that are only needed in the first place because the PHP's array type is so messy and tries to fill so many different uses. Meanwhile, Scala's gets to the point, describes how to use it, and uses the rest of the screen estate to help me navigate to anything else that might be relevant.
> It has clean lambda functions that you can pass around easily and has for more than a decade.
Looks like they did finally clean up their baffling closure binding syntax in 7.4... unless you want to bind anything by reference.
That said, it is pretty hilarious to me that they decided to make strings and arrays of strings callable rather than add some kind of first-class function reference syntax. Surely that won't have any confusing interactions with namespaces...
> Type hinting has been in place for a long time
Not of much use without generics. `array` isn't a particularly useful type. There does seem to exist an RFC[2], but it looks dead in the water (no voting table, and the stated vote goal was years ago).
> The only downside of PHP that I can still point to is that it's sometimes hard to remember the function parameter order for some of the common string and array functions.
It's not really PHP's fault itself, but Laravel is a miserable mess of implicit magic. The fact that people often seem to hold it up as the gold standard of PHP doesn't exactly inspire confidence in the community.
[0]: https://www.php.net/manual/en/function.array-merge [1]: https://www.scala-lang.org/api/current/scala/collection/Seq....):Seq[B] [2]: https://wiki.php.net/rfc/generics
fastcgi_param SCRIPT_FILENAME /var/www/index.php;
No, but you can do function foo(SomeClass $x) {...} - doesn't that fulfill the use case for most people? Objects are basically fat types, in a sense, no? And since the OOP hierarchy is respected, I can use interfaces or abstract classes here and get basically what I want...?
Sure, it's not built-in, but I think this is the best solution for now given the size of PHP's language team.
I think for the vast majority of projects, this is not a question you'll be asking yourself when picking the language.
I think PHP is one of the best languages to pick when you want a quick MVP for an online service (one that doesn't require specific things PHP is not good at). The community is one of the largest, there are more developers than nearly any other backend language and Laravel is probably the most complete all-in-one backend framework out there.
So the question is often, is PHP good enough to develop a maintainable app with decent performance, where developers won't hate every minute spent on it. And the answer is pretty much yes with PHP 7+
One thing that PHP does better than any other language for web development is ease of deployment. It isn't really anything inherent in the language that makes it easier to deploy, it's simply that hundreds, probably thousands of web hosts have made deployment easy for PHP. Also, the PHP community has documented deployment and installation scenarios thoroughly.
Deployment might sound like a small piece in the overall picture of building a web app but it is actually hugely important. If you want your users to self-install your web app, or to give them the widest possibly choice of deployment hosts, then PHP beats every other language by a mile.
I always mention this quote from blogger and programmer Jeff Attwood on this topic of depolyment:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." [1]
Guess when he wrote it? 2012.
Sure, we've got VPS and even more hosting options, but in 2020 what other languages can match or even surpass PHP's ease of deployment? Can you give instructions to your relatively non-tech users and tell them how to successful deploy your web app with the same ease as PHP?
I feel like I can ask that question about most established languages and get the same answer back. It still has the easiest deployment and development flow of any language I've ever used. I don't know of a single language that does that right now, and makes going from 0 to 100% much easier, which for smaller pet projects, it's so much less hassle. Upload file, it's running on the web. That's it.
As for all the features it has that other languages have, PHP tends to merge them together. While this means the language is larger than most, it also means I can do things in ways I want to and try new features out.
This doesn't mean I'm not using JS or Go or Java or other languages. But if I'm building a web API, PHP is the one that gets out of my way and lets me build it quickly and easily.
Good documentation and reasonable backwards compatibility.
Probably not, but that's the wrong question. The real question is: If you already know PHP, is there enough incentive/benefit to switching languages? Based on the experience of PHP devs I know (I personally haven't used it in years), the answer is "no" for many (most?) web dev cases.
I would say no, but of course, the same is true of most other established languages. What's interesting about PHP is that it's shifting from being a dumpster fire that you would never pick over a real language like Python/Ruby/node/Java/whatever, to one that's honestly broadly comparable for many tasks.
Is it innovating or doing anything really unique? Well, no, but you don't tend to find much innovation or unique features in any of those languages (these days, anyhow). At best they copy them (eventually) from the innovative languages. :)
> I seriously would like to know if it makes sense for a non-PHP developer to look into it
No more or less so than any other big, mainstream, relatively popular language. Learn it because you need it for a job, or because you'd like to see how another language ecosystem solves common problems. Don't learn it thinking you're going to see anything especially new.
It's a decent language and with frameworks like Laravel you can quickly build reliable CRUD apps, which is the vast majority of websites and development.
I'm coming from an academic background and i was looking to learn a new backend language to create simple CRUD type, web applications. I already know c/c++, java, js and some python but after research it seems that Rails, Laravel and Django are the best options for this kind of projects as javascript on the backend is still a mess. So i've made a little comparison between them to choose what to learn.
Rails: It might be the best full stack web development framework from what i'm gathering, but it's declining fast and Ruby has a small market share outside the US.
Django: It's been always the 2nd or 3rd best option. Django 3.0 is going async which looks great on paper but in reality it needs work. It doesn't have a built-in asset pipeline for modern js development on the front-end. It needs plugins for basic stuff like social, api auth etc. Python has libraries for almost everything but the web is not always a first class citizen.
PHP: It is by far the most popular backend language. Libraries are tailored for web development and are probably well maintained because they are used by huge projects(wordpress, magento etc). For the same reason it won't disappear any time soon because it handles most of the information on the web and also billions of dollars in online commerce. Symfony has the most contributors than any backend framework and Laravel is probably the easiest framework to create an MVP with. Developers love Laravel and the community is huge. PHP is also improving and adopting new language features with a more advanced type system.
So the real question is why shouldn't someone learn PHP in 2020 ?
A language that's easy to make fun of but widely used is an attractive target for improvement.
As companies started adopting TypeScript/Flow into their Javascript pipeline, PHP developers realised the need for something similar in their ecosystem.
I work at Vimeo (which has a lot of business logic in PHP) and I took it upon myself to write a static analysis tool (which you can play with at https://psalm.dev). Other similar static analysis tools were developed at other places that use PHP, and together they have helped make modern-day PHP development a little more orderly.
I'm curious if you guys use PHP at all for any real time workloads. Thats where I've always had struggles with PHP.
Also, have you found the event dispatch system of the modern PHP frameworks to be slower over time?
If most of the stuff you're doing requires an event loop I'd consider other options before PHP, but if it's mainly serving web requests PHP is my go-to.
[1]: https://symfony.com/blog/symfony-was-the-backend-framework-w...
In all seriousness, I think this has more to do with the ease of PHP development comparatively to other stacks. Even Python (arguably just as easy to learn as PHP), has more overhead here.
It also seems to have declining interest after peaking in 2017[2].
EDIT: I was looking at the wrong repository, so my comment about Laravel's popularity is wrong.
1. https://github.com/laravel/laravel/graphs/contributors
2. https://trends.google.com/trends/explore?date=today%205-y&ge...
https://github.com/laravel/framework/graphs/contributors
To me it seems like the ecosystem is growing rapidly. There are at least three large conferences each year, a handful of established podcasts and an excellent video tutorials site. There are also a number of paid services like Vapor for running Laravel on Lambda, Forge for easier server management and Laravel Shift for automatic version upgrades.
I have seen no PHP renaissance anywhere (real life, Hacker News, reddit, or anywhere else), but I also checked TIOBE[1]. PHP's popularity peaked in 2006, when it was 500% as popular as it is now.
Some highlights are union types, a JIT compiler, named arguments, annotations, and match expressions.
The approach to named arguments is interesting. It's nice that you don't have to change the signature of existing functions, but the downside seems to be that you can't enforce the usage of named arguments on callers, as in other languages like Ruby and Python where keyword arguments need to be declared as such.
function foo(string $a, string $b, ?string $c = null, ?string $d = null)
{ /* … */ }
foo(
b: 'value b',
a: 'value a',
d: 'value d',
);In Python you don't need to explicitly declare keyword arguments either (though it is possible). This is perfectly valid and working:
def foo(a: str, b: int, c: bool=None, d: float=None):
pass
foo(b=5, a='something', d=3.0)
# is equivalent to
foo('something', 5, None, 3.0)I can't help but feel that PHPs popularity is mostly tied to Wordpress, and to a lesser extend Laravel (with Symfony coming in behind that).
Not really sure the rest of the ecosystem even matters, outside those core pieces. I'd love to see it fix alot of landstanding issues, and I love that the language has moved forward. I've worked with it professionally over the last few years in various places, and I don't particularly dislike so called "modern" PHP, but its only really good at very specified problem domains (mostly, you have a website, need to display said website. I always had scaling problems for anything other than using it in the context of a template language or very straightfoward database access. Real time APIs? nope. Just couldn't get it done, too much memory pressure)
I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.
A couple issues here.
1. Even if the PHP process exits after each request, memory leaks during the request are still an issue. If I'm looping through 1,000 elements of an array and leaking memory each time, I could end up with a peak memory usage of 100MB when 1MB would've sufficed. That forces me to scale vertically when I might not otherwise need to.
2. Most mature applications have worker processes that may be longer-lived than serving an HTTP request. If PHP leaks memory, it's less suited to those tasks. Maybe you write those in Go instead, but then you have to ask yourself why you didn't just write the whole application in Go.
2. There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.
Straight up misinformation.
> This is likely user error due to a poor understanding of how PHP memory management works.
This is not what the comment I responding to was talking about. They were talking about memory leaks that were not in userspace. PHP's bug tracker has 943 bugs related to memory leaks[1]. That has nothing to do with understanding "how PHP memory management works".
> Unless you're using poorly written extensions then memory management in PHP is quite straightforward.
How exactly do you know whether an extension is poorly written? In many cases, it doesn't matter because there's exactly one extension that does what you need.
You could also be using poorly-written libraries.
> There's a large amount of PHP libraries built to do exactly what you're describing. Long lived PHP processes are live in production across the world.
I know. I use some, and I have several long-lived PHP processes running right now.
If a memory leak is in PHP itself, no library can fix it.
> Straight up misinformation.
Disagreeing with someone (or not understanding them) doesn't mean they're spreading misinformation.
My point was that memory leaks in the PHP virtual machine are still a problem even if PHP usually runs statelessly. Do you disagree?
1. https://bugs.php.net/search.php?search_for=leak&boolean=0&li...
*not to take sole credit. I created RPC framework and initial API, and oversaw a small team of very talented engineers who added a significant chunk of the functionality powering Grooveshark over the years
I usually have to resort to queues, which just adds complexity where I typically don't want it.
I do assume it's not the case, but one of the footguns with PHP is that assigning around large variables/arrays and triggering the copy-on-write can end building up the amount of duplicates of that data being kept alive. Pass by reference, unsets, generators and the like aren't used super often due to a lot of runs being small stateless requests, but sometimes they may be needed.
Ultimately I’ve had less issues with Python for this type of workload and is eventually where we moved.
Exhibit A of your parent's point.
The new PHP7/8 is certainly exciting, is it too late?