A look at modern PHP
lwn.net
lwn.net
Here are some facts:
- Symfony was the backend framework with the most contributors in 2019 [1] (yes, out of any backend framework written in any language)
- PHP has more active contributors than it ever had [2]
- Laravel is one of the most used frameworks in the world [3]
Then I see statements like "PHP only exists today because of legacies being maintained". Can't provide stats on this, but neither can the people who make these statements. Might be just because I'm a PHP dev myself but I see a lot of new projects started with the above frameworks.
And last, people compare it to languages like Rust or Go since they consider those are "innovative". I hope everyone understands that a language is fit for a certain type of task. PHP was created for website development, and in that area neither Go or Rust are even close to matching it in terms of maturity.
I may be biased but for me, choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core, and except for these two I wouldn't seriously consider any other competitor for starting a new project. Unless, of course, that project is "for fun" and you want to experiment with new technologies.
[1] https://symfony.com/blog/symfony-was-the-backend-framework-w...
Ok, I'll rephrase that:
Django and RoR aren't that far off.
If we just look at [3] above, we see these: https://trends.builtwith.com/framework/Django-Language https://trends.builtwith.com/framework/Ruby-on-Rails
Django, at least on that site, seems to be quite far off. Rails, at least on that site, is ahead of PHP.
I prefer Scala to PHP, the language is much more expressive. When you want to replace a bit of core functionality, in Symfony, you extend the desired class, add it to the dependency injection container, and you're done.
In the Play framework, I once wanted to make a one-line change to the routing. When it turned out I'd have to touch 30+ files which have hardcoded dependencies on each other, I quickly gave up.
Symfony is absolutely amazing. For example, you can import a UserBundle from github, extend the original service class, change a couple of lines and then you have a fully functional user auth system without to rewrite/wire a bunch of things.
Although I don’t enjoy writing PHP anymore, I do miss how mature it is.
[0]: https://symfony.com/doc/current/doctrine.html
[1]: https://www.doctrine-project.org/projects/doctrine-orm/en/2....
[0]: https://www.php.net/manual/en/language.generators.overview.p...
Lately modern PHP frameworks have so a lot of dependencies too. So both stacks are getting fatter as their capabilities grow.
Nobody is forced to write Haskell or Rust, you have to actively look for such positions.
Then again, this doesn't explain why the number #1 language (Python) is so liked...
The elitism of learning a new language and then mocking those that haven't put in the same time and effort to row in the exact same direction, has always amused me. Ive never judged anyone for what tools they use to get their job done, but apparently i am a rare breed in that i am more concerned with the output then the language choice.
I think skill and knowledge of the coders is vastly more important then the language choice... you can write insecure, slow code in any language.
While I think you're right about the elitism hype cycle, I do think Rails and PHP have something in common, though -- they were systems that people who really weren't that interested in learning how to program leapt into in droves, because they were both perceived as "anyone can learn to code" technologies. And that led to an awful lot of bad code written with PHP and with Rails, which in turn contributed to the buzz about both turning sour.
I'm not disagreeing with you, but "website development" is a very broad category. For example, if you definitely need a website with server-side logic and database connections, yes, that's where PHP will shine. However, if you need a more or less static website for your restaurant or portfolio, is it really as straightforward to say "PHP is for website development, write your website in PHP"?
I want to be very clear that I'm differentiating between use cases here, but for something like a technical documentation website, a status page or something similar that does not require server-side logic and databases, I would much prefer using Hugo or some other type of static site generator, and not because PHP is bad but because we're still talking about "website development" but just not necessarily the kind of website that PHP was made to build.
That being said, there are of course static site generators in PHP as well (and probably every other language out there), but Hugo has a special place in my heart just because of the speed of it.
In which case you’re back again in PHP land.
In my mind a "more or less static website" will not require a database, it will not require logic server-side, and it will not require the possibility to add-on plugins for extra functionality.
What's beautiful to me about static websites is that the threat vector is now suddenly nothing but the web server, and when you're serving static web pages that's a pretty small threat vector if you've configured it correctly. As soon as you blur the line between "web site" and "web application" and start including things like databases, forms and API:s you're in a completely different territory and I kind of feel like you should choose that because you really, really need it. Not just as a default.
WP hasn't been a good choice for small business owners for a long time - web security is hard, and hardening a WP install is not simple. There's a ton of options out there that do everything WP does without the overhead: squarespace, weebly, wix, shopify, etc.
For example "foo"==TRUE, "foo"==0 and TRUE !=0 are logically consistent now?
Or json_encode no longer returns null for invalid input?
Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing.
json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error().
Both are unfortunate, of course, but it's hard to fix mistakes made 25 years ago.
I like PHP, less and less since I started with it in the 90s. Largely because of the current stewardship and syntactical changes. Many languages move forward rapidly. A difference between PHP and, say, Python is that PHP seems to move more slowly to the same end. There are still trivially fixable problems that would qualify as breaking changes. Seems lazy. Instead, we have a bunch of hand wringing because those who make the releases are heavily involved with projects that move slowly out of fear...ostensibly because they have customers they don't want to antagonize. They might jump to another framework or language.
Rather than just "fixing" json_decode and breaking backwards compatibility, old code still works.
The business doesn't care about the new shiny. When someone pays to have a simple site developed, they don't want to be paying a contractor in a year to have a bunch of stuff updated so the language it's written in is "more correct" or whatever the overriding reason is to change this. That is completely tangential to what they care about.
I recently went through "modernizing" a 15 year old, 1.93 million line php 5.x app.
We put in a shim for the mysql_ extension as it had been depreciated with 7.x, and fixed up maybe a dozen places where it was doing something exceptionally wacky and then tested like crazy and sent it out the door. Works fine.
The business doesn't care that the code is shit. They care that it makes them a million dollars a month and no matter how gross it is there's no defensible rationale as to why they should stop doing things that make them more money for the next 2-3 years while a team goes through and rebuilds the entire thing to be "more correct".
Something like pyenv/nvm/etc doesn't exist for PHP. You can just install the latest version and with very few exceptions whatever code/library/etc you find will just work. There's a lot more value in that in the real world than "fixing" json_decode.
PLT doesn't care whether "the business" cares.
I can see a pragmatic point there - anything has warts, the warts you know and don't move are easier to contend with (and lint for). I'd still pick Python for most projects in that comparison, but at a certain scale of effort I'd possibly begin to wonder about the trade-offs.
if(gettype($a) !== "...") { return false; }
switch($a) { ... }Also, PHP allows you to add explicit type casting to case statements. e.g.,
case (string) 1:My day job is in embedded and systems engineering, so web is not even my thing, but I find it incredible a workhorse tool like PHP gets so much disdain. Reminds me of the answers Theo de Radt, gave to the enthusiasts: nobody cares about how cool a tool is if nobody is using it. PHP is used by a lot of people, so it is more important than my new favorite darling Nim. Even if Nim sounds awesome its useless and irrelevant from a non enthusiast point of view.
Wordpress is no doubt a powerful force on the web. As a no-code website-creation environment, it's fine. Maybe even good. But as a library, it is godawful.
- No proper connection pooling with circuit breakers.
- No proper multithreading (that works in web environment) or parallelism in general.
- Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server).
- Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.
The reason for this is because PHP doesn't support many things that are expected in any other language.
PHP C API is hard to understand, hard to use, and documentation is subpar.
- There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP.
- Did I mention that almost anything can block? ODBC? PDO? Some 3rd party library? Even set_time_limit cannot help you here. Handling this gracefully is close to impossible.
I.e., for the criticism to not apply in this context, a solid PHP developer...has to also be a solid C developer. Given the context is "using PHP", the former is likely, the latter, not so likely. Exactly how likely I don't know (I don't use PHP, so don't really have an opinion anywaay), but most discussions I've seen around PHP don't also presume the adoption of C.
> - No proper connection pooling with circuit breakers.
PHP has had a "shared nothing" architecture since the very beginning, that includes DB connections. It helps it to scale (think micro-services being stateless in a modern context): nothing is shared between requests, again including connections, by design.
> - No proper multithreading (that works in web environment) or parallelism in general.
I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
> - Almost everything blocks (even `new PDO('mysql:...')` can block for whatever the execution time limit is, if there is an issue with connection or MySQL server).
Well, it depends on your code of course, but pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling? Seems like a strange example. And as mentioned above, no (excluding optional pThreads) support for asynchronous threads in the language, so...?
> - Most libraries are implemented in C instead of in PHP, whereas with other languages people try to avoid native code as much as possible. This means that code is not memory safe, and understanding or contributing is close to impossible.
Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.
> The reason for this is because PHP doesn't support many things that are expected in any other language.
Yes it does, via the C-extensions, see above.
> PHP C API is hard to understand, hard to use, and documentation is subpar.
Yes programming in C is hard.
> - There is no way to easily share memory between processes. You have to rely on APCu (hack), because this cannot be implemented in PHP.
Deliberate design choice, "shared nothing architecture", stateless between requests, as above.
> - Did I mention that almost anything can block? ODBC? PDO? Some 3rd party library? Even set_time_limit cannot help you here. Handling this gracefully is close to impossible.
Yes because each request is a synchronous thread, as described above above. By design.
When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You probably have background threads that do cache invalidation, queue management, etc.
You frequently have to be more reliable than your database.
> he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
I use multiple threads in a single request flow frequently. Dispatching requests to other services or data stores, updating in-memory caches or queues (not Redis, but living within the app itself), etc. It's an important tool.
> Ok now you have just thrown away one of the main benefits of PHP. Remember, Rasmus is a C programmer, not a PHP programmer, so he wanted to leverage that HUGE library of existing C-code from his new scripting language, from the very beginning, deliberately by design.
Good for him. I don't see why that matters for anyone else. It's ugly and inconsistent, takes time to memorize, and leads to errors.
> Yes because each request is a synchronous thread, as described above above. By design.
This limits you to writing basic CRUD. And so many other languages offer this.
You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point.
> I use multiple threads in a single request flow frequently.
So how do you track those? And for how long do they live after the parent request has been processed, or do they block the parent? Gets complicated quickly.
> It's ugly and inconsistent, takes time to memorize, and leads to errors.
Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code.
> This limits you to writing basic CRUD. And so many other languages offer this.
99.9% of web apps are CRUD.
You probably want to report a degraded status so any traffic that can be bled off into another cluster can do so.
> So how do you track those?
There's a thread pool.
> And for how long do they live after the parent request has been processed.
They might live on after the request flow if they're still doing work.
> or do they block the parent?
Depends on the job and the nature of the API.
> Gets complicated quickly.
That's engineering.
> Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code.
That's why I buy a lot of things. It's also one of many reasons why I don't buy PHP.
> 99.9% of web apps are CRUD.
Now that platforms have taken over, I don't think this is the case. Large systems have sophisticated needs that don't always map to a traditional relational data store. PubSub, feeds, queues, concurrency, eventual consistency, vector clocks, etc.
Platforms are going to eat the long tail in the search for growth.
I'm not anti-PHP, so I'm not supporting the grandparent post in general. But as someone who is working on a PHP extension right now, I agree that PHP's C API is under-documented.
The best semi-official documentation I have found is http://www.phpinternalsbook.com/, but it is incomplete. Some important chapters are just blank, eg http://www.phpinternalsbook.com/php7/internal_types/zvals/me.... A lot of questions I can only answer by grepping the source code of the extensions in the PHP distribution itself.
I don't think this is just a case of "programming in C is hard." Some C APIs are amazingly well-documented, especially Lua. If you open up Lua's reference manual (https://www.lua.org/manual/5.3/manual.html#4), it explains just about everything you need to know to write good C extensions. Every public function, macro, and constant is documented. Python's C API is pretty well-documented too.
What to proceed with? Well, any other code of course! Does all code in a current task depend on writing something to a database or reading from it? What if you need to get data from multiple sources? It would be stupid to wait for every single connection to be made sequentially, instead of proceeding with the next one.
This is just one example. This is actually what Node is often lauded for, making a lot of use of single cores, due to putting one "task" at rest and asynchronously proceeding with the next, not blocking.
A bit ironic that you compare it to microservices, because that exact property of PHP makes it massively unsuitable for microservices and scaling, because it requires another layer in between the microservice platform handling the scaling, and the actual application.
PHP has it's uses, but I wouldn't go beyond a classic monolith or "backend/frontend" style application with it, with very little, manual scaling. If you go beyond that, you could probably manage to do that with a proper architecture and doing wonky stuff, but would it be a good fit? Absolutely not.
When you really have to scale, infrastructure, resources, and networks will rapidly overtake any concerns around your choice of language. You can develop crappy architectures in any language, and the inverse is true.
Doesn't work very well with message queues. Sure, pushing messages is not a problem, but consuming? Something has to do it? But it won't be written in PHP. It doesn't work very well with SQL databases, and with that I mean not the querying etc, but connection pooling, so the database server doesn't suddenly gets flooded by thousands of connections because a service is autoscaled due to heavier load (and sadly, that's a real-world example that brought down a database cluster). Tracing is doable, but not ideal, metrics are hacky due to the need of weird extensions to support shared memory, or rely on an external database such as Redis, which kinda defeats the point of metrics being lightweight. And tuning the PHP runtime almost rivals the JRE...
I once asked Rasmus about this face-to-face, during one of his presentations, specifically his thoughts about the pThread extension (https://www.php.net/manual/en/intro.pthreads.php), and he responded that it was not required in a web context, as web servers already have threads per request so its a mute point.
pretty hard to proceed with some code that works with a DB when the connection can't be established, so proceed with what exactly other than error handling?
is a synchronous thread, as described above above. By design.
So I meant one thread per request at the php-fpm level, not Nginx/HTTPD level.
* Edit for spelling
Still, my understanding is that php-fpm spawns processes, not threads. What is "persistent" is the php-fpm daemon itself that's connected to nginx, but each request spawns a whole process which has to bootstrap your whole framework every time. That's the reason frameworks like symfony run almost mandatorily with something like opcache.
Coming from a Java background into PHP, this really confused me at first, until I started to think about PHP's approach as some kind of super-agressive garbage collection: everything gets released in that reqest thread once it's completed.
It's a fundemental design choice of the language that you have to embrace if you want to use PHP (I love it now, simplifies so much), or move on to another language.
Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads and works perfectly. No process forking.
/me clutches pearls
What a travesty! I wish, I, a lowly, stupid PHP developer was smart enough to know about the Actor model!
/s
What about https://www.php.net/manual/en/ref.shmop.php ?
You want this in any scripting language if you don’t want memory use and cycles to balloon out of control for simple tasks. Most any scripting language looking for performance is going “how can I GTFO of myself and into C (or assembly, or maybe these days Rust I guess, in some circles) as fast as possible”.
in both cases you need to understand pointers and function pointers and the difference between your integer type and a c int, but in one case you're at home while you do it. in one case, you could plug in to any existing c library without writing additional c, so if the problem is already solved you just use the ffi and you're done. in the other case, your problem is just beginning
And the reason for this is that those parts are handled by web servers and php doesn't need to handle them. Isolation decision that simplifies things significantly infrastructure wise and that allowed for shared hosting to exist - which in turn brought the costs down and made web as popular and massive as it is today.
BTW, this architecture is not that different from what node and others are doing. Instead of having a language/framework that acts as a web server (but too simple, so you still need nginx in front), and then you need a queue service to delegate the jobs, you have a web server that delegates the jobs (requests) to isolated php processes. Model is the same and that's the model that's used everywhere today, just that the moving parts are partitioned a bit differently in different languages.
Of course, it's not a perfect solution to every problem, but works very good for any not-real-time web site/app and in the end RoR, Django, Symfony, etc. they all work in a very similar way (minus the syntactical nuances). For a massive traffic or language level high parallelism just use something else, no one argues against that.
It's all about simplicity.
In a web app you "multithread" using the web server...
> people compare it to languages like Rust or Go since they consider those are "innovative"
PHP is getting old enough for developers today to be unaware of the history of web development. If you don't know the history, then you haven't seen the twists and turns it has taken. If you don't know the twists and turns, then you don't see how everything from the past relates to the state of the present.
Perhaps the greatest accomplishment of PHP is that the ecosystem so thoroughly solved a certain approach of web development that the rest of the world could move on to try these other ideas (which are of questionable effectiveness.) There's only so many web frameworks, content management systems and general web development libraries that you can build before you start to realize what waste of time it is to keep reinventing the wheel. PHP has an ecosystem which is still strong (and growing) because there's no need to recreate what PHP has done so well.
Wordpress as an example is not going to be replaced. You can't replace Wordpress by building something in a different language. The code base represents mind blowing knowledge which has gone into solving such problems which have nothing to do with a specific programming language. Nobody cares that you can recreate some basic thing with the new shiny. The programming language isn't the problem.
Now Wordpress is possibly reinventing the CMS with Gutenberg (like it or not) and it's not the programming language which is making it possible or hindering. PHP is a great platform to build on.
As your system grows, then your problems change. The tools required to tackle those problems change as well. This is true of everything. You can't manage a Google the same way that you manage a 2 pizza team. To get to that scale, the systems need to change many times over. PHP solved a wide problem, but it's not perfect and it's not one size fits all. Go is great at solving other problems, and it's a generalist when applied to the web domain. It's not a good comparison.
We haven't even started on the business side of decision making. If I want a web presence, this thread is doing nothing for me. I'm just going to fire up Wordpress and move to the next step. Or Laravel if I want a fast prototype, etc.
Seeing how important this history has been in my own area of expertise makes me think I better start hitting the history books which would be important for my other areas of life. If you don't know your history, then you're handicapped when discussing the present.
In fact, I would posit that many of the complaints about PHP come from WordPress’s widespread usage and its slowness to adopt modern PHP features (and to be fair, I do understand that slowness. If you power such a huge portion of the web, making breaking changes to things that could impact tens of millions of sites on the name of modernization is difficult to reconcile). If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.
As are probably most other discussed ecosystems in this thread. Most people doing Go for web development are probably writing JS heavy front-ends which interact with API endpoints on the Go driven back-end.
> If/when PHP becomes just a legacy part of WordPress, it’ll be interesting to see what impact (of any) that has on the languages perception.
What would it be replaced with and why?
Gutenberg still interacts with a PHP back-end. There will always (until web drastically changes) be a need for something to do the API handling. Would Automattic push the community to build that back-end using Go? Node?
At this point, the predominant reason it's still undergoing active development is that there is a metric ton of legacy PHP code. As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.
You're defending the language from an emotional standpoint.
> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core
This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.
Choosing PHP will be like choosing Python 2. In fact, that's my 2030 prediction.
People have been calling for PHP's death, or saying PHP is a dying language, for as long as the internet has been around.
It's always the same arguments, that $newHipLanguage will replace it.
Then you actually do some research and understand just how much of the internet is still powered by PHP and will continue to do so for the forseeable future.
So, I'm still waiting for PHP's death. Or for this same predictable comment in 2030.
It's not that a new language will replace it. It's that the people that hire PHP to solve their problem will now use a platform with no code to manage.
Engineers writing platforms will choose languages other than PHP to write them. You can't spin up multiple request threads to make concurrent non-blocking queries in PHP.
You mean that you don't know how to: https://github.com/amphp/amp
> You mean that you don't know how to
I'm not convinced you found an appropriate answer either.
In any case, this should be a language feature.
[1] It looks like it relies on bindings to an unofficial native code extension.
I think you can.
https://dev.to/webong/using-asynchronous-processes-in-php-7i...
Lots of languages have HTTP tools and frameworks, but not many of them are even comparable in scope to Symfony or Laravel. Out of curiosity, can anyone point me at some frameworks in other languages that have the following things built-in?
* Route matching and dispatch
* URL generation (generate a URL for some route) including signed and temporary URLs
* Middlewares
* Abstractions for dealing with incoming HTTP requests (getting headers, body, uploaded files etc.)
* Abstractions for creating and sending HTTP responses (headers, body etc.)
* CSRF protection
* Database drivers for a couple of backends (MySQL, PostgreSQL, SQLite etc.)
* Database migrations
* Database seeding
* Views/HTML rendering
* Logging capabilities (configurable backends like rotating log files, syslog, Slack etc.)
* Sessions with different storage backends (filesystem, Redis etc.)
* Request validation ("this field is required, has to be a string, between x and y characters long" etc.)
* Translation and localization
* Broadcasting through WebSockets
* Caching with a couple of backends (filesystem, database, Redis etc.)
* Email sending with a couple of backends (SMTP, Mailgun, SES etc.)
* Notifications with different channels (Email, SMS etc.) and backends (SMTP, Mailgun, Twilio etc.)
* Job queues with different backends (database, Redis, SQS etc.)
* Scheduled jobs
* Authentication (different flavors like regular sessions, API tokens etc.)
* Authorization
* Hashing
* Encryption
* Query builder
* ORM with relations between objects, JSON serialization etc.
* CLI commands with option/argument parsing, colored output, progress bars etc.
* Events, including async handling of events
* File storage with a couple of backends (local filesystem, S3 etc.)
* Pagination
* Payment integration
* Full text search with different backends (database, Algolia etc.)
This is basically the feature set of Laravel, I probably missed some things too.
And I don't mean "oh yeah I'm sure there's a library for that" - I mean fully integrated, first-party, tested, dead simple to use and available by default.
Maybe I'm wrong, but I seriously doubt this just exists in any language.
Django.
Revel.
Actix.
Like I can't find any official RoR support for payments, full text search, encryption, pagination, scheduled tasks or building CLI commands.
With Django, full text search seems limited. It supports PostgreSQL, but I couldn't find first-party integration for Algolia, Solr, Elasticsearch etc. or a generic way to add backends (pluggable drivers) for them. There's support for WebSockets through Django Channels, but it seems a lot more basic than Laravel's broadcasting system. No official support for queued jobs or schedules?
Revel doesn't seem to have support for building CLI commands, encryption, emails, pagination etc. Apparently, any kind of database access or ORM isn't even first-party?
The inclusion of Actix in this list confuses me. From what I understand, Actix isn't a web framework at all, it's more like a foundation for using the actor model.
(I didn't exhaustively analyze everything, there's certainly more things missing from some of those frameworks)
I'm not saying they should, just comparing features for the sake of demonstrating that the functionality that's present in modern PHP frameworks isn't readily available in just any random framework in any random language.
The thing is that nobody would choose that configuration for the PC under normal circumstances. Normally you would spec it based on your actual use case and the PC would end up both cheaper than the Mac and better suited to the use case.
Sorry, the point I was originally trying to make might have gotten lost in all the discussion about specific features.
It was in response to this:
>> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core
> This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.
The way I read it, this comment claims that everything that can be done in PHP using PHP frameworks could also be done in almost any other language using one or several frameworks written in that language. In my experience, this simply isn't true. There are other frameworks in other languages that have a feature set similar/equal/maybe superior to what Symfony or Laravel offer in PHP, but those are very rare. Like "there's maybe 2 or 3 of them in existence" kind of rare. Rails, Django, maybe one or two more? It's a short list. Again, not exactly "almost every language" and all that.
Of course, any language could have frameworks offering those kinds of features, but in reality, most simply don't. For a new web project, PHP, Ruby or Python are still fine choices if you're comfortable using those languages. There's nothing wrong with using, say, Go instead. But to claim that Go (just using it as an example here, not trying to criticize Go in particular) just has one or several web frameworks lying around that can do what Laravel, Rails or Django can is simply dishonest.
... Just to avoid confusion
Admittedly, limiting the selection to first-party code might be a bit unfair to frameworks that maybe simply rely more on community-built extensions, but I have to draw the line somewhere, otherwise I guess every framework theoretically "supports" everything through some third-party module that may or may not work ;)
This is all in a performant, reliable and secure compiled language (Java). Language improvements and modern frameworks have also addressed the long-winded code which used to be an issue.
A.k.a., Kotlin. :p
In all seriousness, though. The only thing PHP still has over Java is that when I say my function takes Foo type, you can't give it null instead.
> Hashing
> Encryption
> CLI commands with option/argument parsing, colored output, progress bars etc. (Do you mean a management console? All of them have it.)
Except for those, Django has every single one.
Encryption: Support for securely encrypting, signing, decrypting and verifying arbitrary payloads. In Laravel, you can do:
$plaintext = 'foobar';
$encrypted = $encrypter->encrypt($plaintext); // this will encrypt the plain text, generate a MAC and combine everything into a base64 encoded payload
$decrypted = $encrypter->decrypt($encrypted); // this will decode the payload, verify its MAC and decrypt it, giving you back the original plain text
$decrypted === $plaintext; // true
RoR and Django both have extensible management commands, and all frameworks that I have ever seen allow you to create independent CLI commands (it's on PHP that the CLI is a second class citizen).
I might have missed it, but I couldn't find any documentation on how to create custom commands in RoR. For Django I found [1] (through "python manage.py" from what I understand) and that does look like it's more or less the same as Laravel's "php artisan", with commands provided by the framework as well as the ability to add your own.
Anyway, I wasn't trying to attack RoR or Django, as those are actually the best alternatives to Laravel I know of. I worked on an existing Django project for a bit and while I don't like Python, Django seemed just fine to me for the most part. I did want to express my disagreement when it comes to the original claim of "any framework in any language can do what PHP frameworks can do" though.
[1]: https://docs.djangoproject.com/en/3.0/howto/custom-managemen...
Oh, a complete agreement on that.
This conversation sidelined from some people talking about Java, .Net, Go and Rust. None have anything similar to the big web frameworks. And while I'm not completely sure about Rust, I do believe that none even can have it.
Funny that you mention Squarespace as replacing PHP when they themselves are a big PHP shop.
This is evidenced in their open-source GitHub projects: https://github.com/squarespace
There are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project.
I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes to productivity and ecosystem they don't come anywhere close to PHP. If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel.
(It's for that reason that JSX is the first way-to-splat-HTML-out that hasn't made my skin crawl in...pretty much ever.)
To elide all of the power and powerformance that JSX provides in the situations where it's appropriate as just "HTML tags" fundamentally misunderstands what they are and why they are powerful.
Data structures are more than text. This is a good thing.
That said I'm not sure it'd be as easy to do hiccup in pure JS because names aren't a first class data type there
If you just want to create a web site quickly then php works fine but on the other hand you can do it quickly with js, c# or Typescript also.
I’ve been thinking a lot about this over the last year+. Is this true? Because the deployment model is 1000x more straightforward for CRA vs NextJS (nuxtjs, etc.).
[citation needed]
Fair enough, and same applies to Ruby on Rails.
Let's not conflate "easy and quick to launch an MVP" with "sustainable for long-term development" however. There are many stories on the net how people started with something as basic as WordPress or Rails but had to rewrite in Phoenix or one of Python's frameworks down the line because the maintenance burden of the MVP-grade technology was too heavy.
To a large degree, but not completely.
Some frameworks (actually the runtimes of the languages) allow for much easier and quicker scaling and/or deployment compared to others. But businesses usually prefer to burn money for that as opposed to making an informed choice early on.
But with two recent projects I‘ve worked on neither would be even feasible.
In one there was a requirement to generate custom designed PDFs, and in the other I had to implement authentication via SAML.
Other language ecosystems that would be feasible in these cases: Nodejs, .NET, Java or Clojure because it can live in either of those.
PHP doesn’t just have mature, battle tested and well documented web-frameworks. It also has libraries which do complex things that are very unattractive like PDF generation/manipulation and complicated standards like SAML.
No, they do not. The entire appeal of go is that there is zero innovation at all. It is the most plain, boring, ordinary language around. It does absolutely nothing different or neat or new or special. Instead, it focus on being simple, easy and fast. Just like PHP apologists keep claiming about PHP. The difference is go was developed by competent software developers, so it isn't a broken, buggy, inconsistent mess.
>PHP was created for website development
And yet it is outclassed for that purpose by general purpose languages like go.
>and in that area neither Go or Rust are even close to matching it in terms of maturity.
Age is not maturity. PHP is old. It is less terrible than it was 20 years ago, but it is still worse that any other language except javascript.
Can't speak for others but I've worked on many legacy C++ codebases over the years, it has never been a pleasant experience. Even when it's a C++ 17 codebase the same bad practices from C++ 11 and earlier are all present and accounted for. As are the subtle bugs stemming from an inconsistent standard library and C++'s approach to verbose error handling. I'm sure that there's plenty of good C++ code out there, maybe I've just been unlucky.
I can literally copy and paste what you said replacing it with any language and end up being correct.
Every single language on a legacy code base will have good code and bad code. It has NOTHING to do with the language. It has to do with what the code is and who originally developed it.
This is the best point in this thread, IMHO.
I think it also is due to the fact that PHP is a fairly easy language for a non-coder to pick up little-by-little. One can easily start using it for doing simple things, like injecting dynamic data into a web page. From there one can learn to scale up to full web apps.
I think this lower barrier of entry makes a lot of developers feel insecure. A lot of coders think they are blessed with some sort of special ability to write code. They seem themselves as elite and they use elite tools. When some kid comes in with some PHP snippets and generates a lot of value from that they complain that their code sucks, the language sucks, the developers suck, blah blah.
In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.
True, but most people considering PHP probably aren't considering statically typed languages. They're probably comparing it to JavaScript, Ruby, and Python. PHP holds it's own surprisingly well in that comparison. It certainly has it's fair share of quirks, but so do the others.
PHP usually has a good library for most things. JavaScript usually has 3-5 good choices (but nothing rails-like). .NET often seemed to have nothing, or only proprietary options.
I personally started using PHP because, at the time, the free hosting servers only had support for it. Otherwise, I could probably have picked python, ruby (or even perl). I wasn't a non-coder, but I think that these languages may be self-taught with the same ease as PHP (well, maybe not perl).
> In my 20 years of writing code (starting with PHP) I have learned the lesson over and over again that while writing code commercially the fact that the language has feature X or that it forces certain patterns means almost nothing. Sure, your developers might feel better about themselves but that is about it.
But, isn't that the whole point of using PHP 7.4 over, say, PHP 3 (besides evaluation speed)? Would you code in PHP 3 today, if PHP had not evolved at all?
For C++, you want to complain about unreadable error messages, long compilation times, verbose type declarations, and use-after-free bugs.
Each language is different, and has a different trade off. A good developer can use multiple languages: C++ when you have lots of non-trivial data processing, Python for numeric and complex scripts, bash for bootstrapping and simple scripts, and so on.
I think, the reason is, Facebook poured a load of money/time into PHP. Otherwise it would probably on life-support right now.
Facebook may not have directly funded PHP, but I know for sure at least one of the HHVM/Hack devs (Sara Golemon)is also a huge contributor to the PHP core.
https://www.youtube.com/watch?v=TOveFBc9AyI
https://voicesoftheelephpant.com/2019/07/16/interview-with-s...
I'm saying that back in the days it looked like it will go downhill, but then a big player used it and that saved it.
Front end devs are already programming in JS, so there's less adoption cost than PHP. I can't think of a single reason to use PHP over Node (I know both, and have delivered projects in both).
The comparison to .Net and Spring makes me think you might be a bit behind the curve. Have you tried Node?
1. "I can't think of a single reason to use PHP over Node" this is fine but can you think of a single reason to use Node over PHP. Is adoption cost the only one?
2. "you might be a bit behind the curve" while the original commenter was talking about PHP being "modern" and dimissing talk of it existing because of legacies, criticising someone for being "behind the curve" does smell a lot like that "must jump on every shiny new thing regardles of merit" mentality that drives a lot of the JS ecosystem. What are the material benefits of being on or ahead of the curve in this case?
2. This is not my attitude at all. I've been programming since the 90s.. In the past I've maintained PHP apps for years; maintained a custom web framework for 17 years; I still have sites running that use jQuery.
It's certainly true the JS ecosystem has that mentality... but that does not mean every JS tool can be dismissed with that thinking. NodeJS is 11 years old... it's not a shiny new thing anymore.
Definitely not true in my experience. lot's of people are writing REST apis in PHP.
> NodeJS is 11 years old... it's not a shiny new thing anymore.
I write Node stuff for work at $dayjob, and lot's of stuff is great. But it still has nothing that's close to competing with Rails/Django/Laravel in terms of completeness.
This just shows a lack of understanding of modern PHP. REST APIs are dead simple in PHP using Slim, Lumen, or Symfony REST.
Symfony, Laravel, Drupal and Wordpress would be reasons.
Why not Django or Rails?
PHP runs right out of the box. As long as apache is running and you have an index.php file in your www directory, it just runs. Spring Boot is a pleasure to deploy as well with embedded tomcat, it's possibly even simpler than PHP for local development because you can just give a jar to someone and it works no differently than it would in production.
Django isn't MVC, it's an entirely different architecture. Symfony framework is heavily inspired by Spring [1], and modern frameworks like Laravel heavily influenced by it and extensively use its libraries.
>You don't have the whole dependency injection lifecycle thing to grasp which isn't easy for someone who never seen it before.
Laravel's core is built on a DI container and extensively uses that throughout. Service providers [2] are a key concept to Laravel, which requires you to directly interact with the DI container.
What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can't find an answer that doesn't point to poor design as to why in Java a Stack is a class but Queue is an interface. Java also didn't get generics until v5, which is now probably one of the most definitive features of the language. Java has changed a lot since its inception. If it weren't for modules and (especially jlink) being introduced in java 9 we'd still be dealing with massive production jars. Java has changed a ton and so has PHP, both for the better.
>having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be.
Inspired by doesn't mean the same as. It's no different than any other non-DI frameworks unless you want to write framework-specific packages. Laravel has DI under the hood but you don't have to write annotations nor structure your code in a certain way to be able to use it. It does all of that for you.
>And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?
They're far easier to use with less overhead. You don't need to know tons of annotations and configurations to get requests to behave a certain way. You've already admitted earlier that you've never used Laravel nor Symfony, so I'm not sure why you're arguing about their ease of use when you don't have experience with either. They're significantly easier to use than Spring.
Now I mainly do TypeScript/JavaScript and some Rust on the side.
To me, PHP was more of a limiter rather than painful experience (it was a bit painful though). I couldn't imagine how to even make a chat app.
If not for my moving out of PHP to NodeJS now I wouldn't be a software architect and explore the rest of the fun and challenging part of computing domain.
Of course, it used frames, so that the "send message" part didn't clear every time it refreshed… those were the days! Eventually, my fancy chat app delivered a much better user experience, thanks to an amazing (back then!) JS library — jQuery. I built my first "API" that way! (It didn't use XML or JSON - it just returned chunks of HTML that were appended to a div).
Pure PHP gets annoying when you're dealing with complex data models, or when you're building a combination of frontend plus backend batch processing. Frameworks such as Laravel make this much much nicer to deal with IMHO. Of course, PHP is far from perfect, and its quirks can cause OCD and frustration to some people… :-)
But thanks to PHP (and also thanks to how lenient and chaotic it was), I was able to create very early on without needing to worry about software patterns (I had no clue what MVC was back then!), strict code formatting, learning how to deploy an app (just upload the code and off you go), and so on. PHP got me into programming — and it's also propelled some big-name sites and apps, so I guess it deserves some credit there as well.
And laravel, it was everything I knew. I really liked it, the orm was superb, the template engine was superb. It has it downside though, the big amount of code need to be parsed.
"foo" == TRUE, and "foo" == 0, but TRUE != 0
NULL < -1, and NULL == 0
PHP sez:
Parse error: syntax error, unexpected (T_PAAMAYIM_NEKUDOTAYIM)One simple improvement I would love to see is namespace grouping in standard library. Go has all related functions inside some package. Go pls let me do http.notfound<tab/enter> = http.StatusNotFound. But in php even with inteli I need to google some function/const name.
Unfortunately people tend to uncritically repeat whatever it says without actually paying any mind to the facts that, 1) it's 8 years old, 2) it's flat out wrong about a lot of its claims, 3) it's evidently written by a guy who has no idea what PHP is even intended to be.
But if we're not using it for that purpose anymore, why would we want a programming language that grew haphazardly out of a templating language and is suffused with the quirks of that legacy? Yes, it's better than a decade ago and getting better all the time, but is it good yet? Does it have any advantage over more coherently designed languages?
While the criticism that the "Fractal of Bad Design" post is eight years old is fair, the criticism that the author "doesn't understand PHP" isn't; it's very clearly written by someone who understands PHP and is frustrated by it. Not all of the criticisms are still true, but PHP's huge popularity means that it's very difficult for them to change the language design in ways that truly break backward compatibility.
PHP's biggest advantages, I think:
- it's actually still very fast, particularly if you use a well-optimized framework or (gasp) don't use a framework at all
- it's super easy to deploy, especially for small-scale sites where "first, build a Docker container" sounds like the tech equivalent of taking the Harrier jet to pop over to the grocery store
- it's got a pretty robust ecosystem around it at this point
In my extremely subjective opinion the closer you can come to PHP's laser-targeted ideal of "minimize the setup and just get going," the better off you are, and if you find yourself routinely invoking multiple factories to create dependencies to inject into your inflected reflected dejected container it may be time to either investigate a dynamic language that is not trying to become Java or to just, you know, use Java, but again, that's just me.
WTF?
So what is "PHP intended to be" in this case? And how is the above behaviour the sensible thing to do?
Whatever PHP "was intended to be", this is a gotcha that is absolutely unnecessary and sticks out like a sore thumb in today's ecosystem of stricter and more predictable and stable languages.
Let's not forget that commercial programming should not be about joining tribes that share your personal philosophy. It's about getting a job done. Predictability and stability help a lot with that.
What if the assumed quality is an illusion and every discussion is actually as misinformed as this one, you just lack the knowledge to recognize it? Which doesn't have to be a bad thing since the signal to noise ratio on hn can still be better than somewhere else.
(There is actually a name for this idea, I am unfortunately unable to find it.)
In any case, you read with exasperation or amusement the multiple errors in a story, and then turn the page to national or international affairs, and read as if the rest of the newspaper was somehow more accurate about Palestine than the baloney you just read. You turn the page, and forget what you know.”
– Michael Crichton (1942-2008)
That would not be the entire explanation:
- I almost have bragging rights on certain topics and still find the discussions about said topics here on this site mostly good.
- Other people do actually have serious bragging rights and still continue to show up, so I guess HN isn't that bad.
Edit: although some of the reason for the last point could be the same as the reason why parents change diapers as pointed out a few hours or so ago: https://news.ycombinator.com/item?id=23077102 ;-)
Above all else, circa 2000 we could still rely on Moore's Law and therefore we could rely on a single CPU getting faster and faster every year. But once Moore's Law came to an end, it became increasingly important to be able to leverage concurrency, and PHP had no real story around concurrency (except the course-grained method of starting a new process).
PHP 4 was a very easy language to learn. It did not have many Object Oriented features, instead it encouraged a simple style of simple functions. Ironically, when it came to objects, the default behavior was "pass by value" so PHP 4 was, in a sense, an immutable language, long before that became a popular development style (tragically, it was not optimized to manage memory in a manner that would allow ambitious use of its immutable qualities).
Later, PHP developed an intense envy of languages that were seen as "enterprise ready languages". This lead to a lot of nonsense. First of all, PHP 4 was already good enough that it could be used in an enterprise, but this fact was ignored. Second of all, PHP 5 suddenly adopted a lot of Object Oriented features which added a lot of complexity to the language, but without offering the benefits that might have come from using a language like Java, such as compile time checks.
I used PHP from 1999 to 2011. I built my first and second startups using mostly PHP. However, in the year 2020, I can not imagine why anyone would use PHP. It no longer offers the simplicity that it offered in 2000. It no longer offers the straightforward procedural style that it allowed in 2000. It's "all in one" philosophy is no longer an advantage because now every language has a modern package manager that makes it easy to include whatever is needed. Nowadays, with Javascript, you just type "npm install" and you get every module that you need. And yet PHP still doesn't offer some of what a complex language like Java or C# might offer, especially regarding strict typing or compile time checks or run time efficiency, or a separate set of runtime flags for a compiled version. PHP has become a weird mutant, imitating the more complex languages but without offering their benefits.
And crucially, the other languages have not been stagnant. The community around Java eventually gave up on Struts and started developing light-weight frameworks that made development much easier. And there sprang up dozens of languages that run on the JVM and which offer a wealth of good ideas about how to do modern development. (I became a huge fan of Clojure.)
I seriously can not imagine why anyone would use PHP now. It no longer offers simplicity, but developers don't gain much from all the extra complexity that's been added.
[Added] A final point: this article makes it seem like Composer is something of a victory for PHP: now PHP has a modern package manager just like all the other languages. But this strikes me as a defeat rather than a victory. Circa 2000 I loved PHP because of its "all in one" philosophy. If that style of automatic inclusion is no longer possible for PHP, and therefore PHP needs to become just like all the other languages out there, how does that reflect well on PHP? One more unique strength that PHP once had is now gone.
Thanks for this detailed comment and the historical background, it is very informational!
Surely Django & Rails are also comparable to something like Laravel?
Every reasonable programmer will agree with you that different languages serve different niches. Nowadays however there are several mature and solid web frameworks in other languages, thus PHP is very far from the only -- or the best -- contender in this area.
And yes, you are biased. That's quite okay. I can also make a ton of smaller projects in 2-3 days with Elixir's Phoenix -- some that have a smaller scope I can also do with Rust's Rocket even. But I don't claim they are the "no-brainer" choice. You should not too.
Finally, implying that choosing anything other than PHP makes the project a "for fun" endeavour is disrespectful and does not do your argument any favours.
Some developers live in a kind of technical vacuum where, I guess they assume, the technical features of their programming language are what makes the difference in the value of the business they're building.
In reality, the difference is in how easy it is to hire developers, the package library, overall ecosystem and developer experience, or: how can I make a great product.
The point being, you can hire good php devs.
Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.
* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.
In my previous company (based in Paris, FR) we had a very hard time getting skillful PHP devs, even if there were a lot of candidates.
You are very close to implying that the language doesn't matter if you can hire developers and there are a lot of good packages in the ecosystem.
Having worked on several PHP projects (Most being version 7.0+ and zero of them being older than 5.3), the languages is STILL full of gotchas, and it's a huge drag on productivity. I assert that this DOES matter. Even basic stuff like trying to use the default "array" as a dictionary has absolutely ridiculous issues like if you try to use a string as a key, but it is a string of digits. It will automagically convert your string to an int and totally F-up your dictionary.
I've actually been bitten by that one. And it showed up in production, because I didn't know or care what the string keys might be. Who the hell would've guessed that behavior after working with non-broken languages before?
Inb4 "That just means you're dumb. Just use SPL. You can write bad code in any language."
I've used Symfony. It's good. I haven't used Laravel. I assume it's also good. I still don't know why you'd choose to start a project in PHP today when there are great libraries in many other languages that are not as broken as PHP.
Honestly, PHP 7+ is not horrible, but it's also not better than anything else... In fact, the very best PHP code you can write today looks basically the same as the best Java code you could've written a decade ago.
Most of it won't survive a handful of years at best and most companies won't ever benefit from the attitude of some developers that ever developer on ever task should be writing FAANG level code.
What 3nds yo happening it matter what you do is the next agency / person comes along and claims its not fit for purpose any more and redoes it 'better' and the cycle continues of low value
I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.
The proliferation of Collection classes may be one side-effect of how poweful-yet-awkward they are.
I've been bitten by it and also stuff like 800=="8E2".
I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I have wondered whether something about PHP, or something that it lacks, makes PHP projects easier to estimate.
Ease of deployment? Batteries included standard library? Pragmatic community? Surprisingly adequate performance? It never seems like enough to overcome the obvious deficits. I can neither ignore my own experience nor convince anyone that it's actually great.
It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light of those immensely popular languages, I could see why someone might not think that any of the deficiencies are deal-breakers.
The only-ever-PHP coders I have known tend to be fairly polarized between fear of the unknown and the "grass is greener" attitude.
The ease of estimation thing was an aside, but I'm getting more convinced. With PHP there is only one way to do any feature: look up the library function, type it, refresh the page, and slowly accrete your functionality. With other languages there's some hope of a free lunch and it engages our tendency to optimism.
Asking as someone who's mostly only written PHP (and some javascript, more recently): can you expand on this? What kind of "hope of a free lunch" is there with other languages?
The first is the promise of DSLs and meta programming, where you can tune the syntax of the language to more naturally express your problem domain. When this works it's beautiful, but sometimes it is a distraction and makes the code difficult to debug.
The second, which is conceptually very different but I find it can play out similarly, are rich type systems where you can hopefully build up your application as a series of well defined type relations and transformations. Again, when this works you get really robust, reliable, and easy to modify software but there are often cross cutting concerns or business practices that break the model.
Edit: when I talk about a free lunch or a silver bullet, I am often thinking about the writing of Fred Brooks.
That's about as far as you can go with Java, I guess, but honestly, now that I type that out, I guess that does get you pretty far...
The most salient problem is the fact that the languages do not distinguish between references and values (aka “mutability by default”) which means that the compiler will not maintain those invariants for you unless you annotate things specifically, and the authors of the libraries you use do the same.
My overall preference is for F#, which is ironically a better object oriented language than C#, by virtue of using ML-like syntax instead of C-like. Nonetheless, C# is a passable functional programming language these days, and the language designers keep adding more functional-inspired features with every release.
However, I also use C/C++(Mostly low level embedded), C#, and Golang regularly.
If I was given the choice of what language(excluding C/C++) to launch a new web site I would still choose PHP with `strict_types=1` enabled.
Peter Norvig at some point came to the realization that the deficiencies of Python relative to Lisp were not deal-breakers, and I don't think that stemmed from his limited experience.
Since then I've done (real, professional, for-profit) projects in PHP, Go, Java, Kotlin, Swift, Rust, JavaScript, Elixir, and Clojure.
So when I work on PHP and Java I can feel what they're missing. It's simply the luxury of having experienced working in (what I consider to be) better languages. Clojure and Elixir were not my cup of tea, but I still find them to be better quality languages than JavaScript.
I have met many developers in my life. Some with quite a lot of experience. The VAST majority of them have only ever worked in a handful of very similar languages. Mostly the ones I listed originally (I forgot C# in the list, but that's more-or-less Java++). If I'd only ever used PHP and Java I would literally not know what a good type system looks like. It's ignorance, but not stupidity.
And I'm talking about people I have much respect for. People who I acknowledge are smarter than me. That doesn't mean I don't know anything they don't, though. And if they've only used PHP and Java, then I know some things they might not. That's all.
EDIT: Also, I'm not sure what Peter Norvig has to do with it. I bet he doesn't like PHP, either.
Your comment wasn't about people who like PHP. Your comment was about people who defend JS or PHP to the minimal extent of saying their deficiencies are not deal-breakers.
There are people with broad experience who are willing to accept deficiencies of a particular language if the context is right.
(I don't actually know what the right context would be for PHP; I'm more stating a general principle.)
I was more, in my head, describing people who say "Well, all languages have issues." or "You can write good/bad code in any language." or whatever other bottom-of-the-barrel defenses I often hear and read.
I ended up building out a whole new array class to work around it. The notes at the top of my class file pretty well describe the problem: https://github.com/robsheldon/asinius-core/blob/master/src/A...
There are native-php workarounds and if you're very very careful you can probably maybe encounter this and code around it without triggering any of the strange behaviors, but it's a minefield.
I'm not new to PHP, either. I think by chance people just usually don't encounter the circumstances for this particular bad behavior, but when it happens, it's really bad. Array keys shouldn't be getting implicitly typecasted.
It's no wonder people still lean on the broken foreach. I always use unset() after foreach. It makes me die inside a little.
I'm not that talented. I write bugs all the time. Most of the time, tests save me.
You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.
Not sure about the productivity claim. I once wrote from scratch (frameworks excluded) backend and frontend (version 1) of a multi-tenant, cloud-based video-sharing platform with PHP as the backend (aws cloud) in a matter of weeks.
I once wrote, from scratch (frameworks excluded), an entire backend (and front-end) of version 1 of a hybrid mobile app (backend in PHP) for a medium-size logistics company in a matter of less than 2 months.
I have other examples, but life is too short trying to convince "haters" that they might not be 100% correct.
I was the only developer on both of those projects. Your mileage may vary :)
I personally spend a lot of time hopping among technologies and I always lean heavily on documentation. PHP has pretty good documentation, and this helps a lot in my opinion. I would guess that a lot of developers don't read the docs and just assume that something in a less-familiar language will work exactly like they expect it to, and then call this a "gotcha" when it doesn't.
Because of spaces vs tabs additional overhead. Packages vs built-in libruaries. RAD frameworks like laravel vs Django.
Also, the PHP ecosystem is friendly to beginners. Compare these authentication docs for a PHP project vs a .NET project:
Laravel (PHP): https://laravel.com/docs/7.x/authentication ASP.NET Core (.NET): https://docs.microsoft.com/en-us/aspnet/core/security/authen...
This is available with many other languages as well, i.e. https://github.com/cosmtrek/air
It may require an external tool, but the deployment experience is a lot simpler for Go than PHP.
If I hadn't considered string-number-keys in my code, I would also have forgotten about them in my unit tests. Maybe you're different.
https://repl.it/@JadoJodo/SelfreliantEdibleUsers
edit: Not trying to discount your feelings overall, but just curious about that specific example.
https://repl.it/repls/CompetentBlondInstructions
Here I changed your string index to an int and it still says success!
Seems like a fairly minor language quirk (of which almost every language has) rather than a huge feature that makes one want to avoid the language at all cost.
Of course, feel free to make your own choice when picking a language, but I don't think this is a compelling reason why one would always want to avoid using PHP for their web backend.
Do you truly believe that I articulated that there was exactly one reason that I think PHP hinders developer productivity?
And of course, we brought out the old "every language has quirks" apology. Yes, you can bang a nail in with a rock. But, don't. Use a hammer.
Do better, please.
It's one of those foundational issues that I just can't get over.
...but it's my personal problem - I don't hate PHP.
In all new work we require static typing on method parameters and defined return types. Of course, if your type is 'array' it could be an array of anything but we also try to avoid that and use collection classes. It honestly feels a lot like Java now, without the compile step.
Edit: and by "our" dumbass bullshit, I mostly mean when we thoughtlessly return type T when we claimed we'd return type U
As a mostly-acceptable alternative, we just type hint as array and document the actual containing types in the phpdoc block and run phan for static analysis to catch any potential screwups.
/**
* Method for converting Foos into Bars
*
* @param Foo[] $foos
* @return Bar[]
*/
function convertFoosToBars(array $foos): array
{
// ...
}
I'm sure there are many with well-thought-out reasoning though, like seen in this thread.
It's useful to keep an open mind about things though. I'm probably more a PHP fan, but I can't say that I'm a huge fan of its programming style. It's much more enjoyable to me to churn out applications in .NET or in Ruby, but it's hard to argue with the speed at which I can develop in PHP or with the level of support online for doing so.
So the anti-PHP feeling for this group is broad but shallow. Here's what I think is interesting: JavaScript is here right now. Like PHP, it's incredibly popular, almost mandatory to know in some degreee, and using it for any length of time causes one to build up a catalog of "WTF?" and workarounds and "use this library instead" and a constant churn of "it's great if you use <some framework or conceptual approach> on top of it".
I used PHP a lot, and found it quite pleasant with Laravel, but the latent pool of distaste means I'll never go back. I work heavily with JS now, and can feel that wide puddle of "why do I have to put up with this?" spreading, even while other parts are really good.
I don't know how you overcome this, broadly. Perhaps it doesn't matter, because I think this group (and I'm part of it) blows with the wind more than most, and if the winds shift back, we'll probably come along.
Also, I have a theory that with the more common languages, you obviously find a much broader user base of beginner-level programmers, or, worse, programmers who just don't care about quality, which translates to more dysfunctional code in the community in general. My coworker at one company did not have good things to say about PHP, but when he had to take over a PHP project of mine when I left the company, he said it was some of the most well-written PHP he's ever seen -- organized, easy to follow and modify, etc. He didn't even realize PHP could be written in an eloquent fashion. (Not to brag, I've written plenty of bad code too.) Point being that if all you see in a certain language is jumbled spaghetti code, it's easy to think of it as a bad language.
A good programmer should be able to create eloquent code in any language.
Edit: Realized after posting I may have sounded like I thought you were not a good programmer -- that's not what I was saying at all! You can write eloquent code and still be frustrated with what the framework or community forces upon you.
It's a very good point: the more widespread a language, the larger the proportion of users will be beginners, who will almost certainly confuse their own inexperience with language-driven frustration (again, c.f. JavaScript). My pet theory on the broad appeal of PHP is that it coincided with the easy availability of shared hosting accounts where PHP was the default scripting environment available. The barrier to entry for blogs, shopping carts, forums, everything was incredibly low, leading to an explosion of software, tutorials, walkthroughs, and community that was heavily slanted towards beginners, dilettants and "low end" programmers". I made a living as one for several years, doing PHP for $5-10k jobs, and there was endless small-business work in this segment.
If modpython had worked as well as modphp, the world might look very different today.
As you said, there's almost always a solution to avoid the pitfalls but that makes you more and more "unhappy" with the language over time. I'm one of the rare people who can answer most JS trick-questions correctly, and that puddle has been building for many years (let's say more than 10).
On the other side, I'm very pragmatic and using tools like ESLint and Typescript (well that's just JS with SUPER pragmatic typing in my eyes) started to make it a joy again in the last few years. I hope the trend continues. I can't say the same for my PHP experience.
After years of using a lot of products and seeing which ones succeed and which ones fail, I question whether there's much of a connection between code quality and product success, assuming of course that the code isn't bad enough that it prevents the use of the product.
Heck, I'm not even sure there's a strong correlation between basic product function and success, at least in the enterprise space; I've seen a number of successful products that barely even work. Seems like market positioning and sales are the bigger factor.
One brand of hammer causes RSI. This brand of hammer tends to bend nails unless they're made of titanium alloy at 80% higher cost. The houses built are basically fine, but they have quirks as a result of the builders trying to avoid having to use nails. You lose 10% of your workforce after every project to medical leave and burnout. Everything is fine because people keep buying houses (there's a shortage).
That being said the biggest argument for PHP is productivity and I just prefer Ruby + Rails for that. Honestly though I will say I find PHP more pleasant to work with than Python these days.
I wouldn't be surprised if many of them don't even have that experience. I've found a lot of people just parrot whatever someone else wrote or said without much thought. The tribalism within the development community is approaching what you'll find with in gaming, sports and even politics.
Think this is true. I am one of those php haters, although I wouldn't trash it. I worked with 4 and 5 and the transition between the two, so it is a while ago. I am not fondly remembering that time and have moved to other branches than web development to evade it.
That being said, if I would go back to web development, I would have a look at it. Why not?
PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Pascal, COBOL, Oracle DB and PHP today seems like technologies that only stick around because they are legacies being maintained, not because people start new grand projects with them. Would Wordpress have chosen PHP if they started today?
You could replace "Wordpress" and "PHP" with whatever you want, depending at which point in history this comment is made.
There is nothing wrong with that. Java also follows that philosophy.
> Would Wordpress have chosen PHP if they started today?
According to Matt Mullenweg: no, but does it matter?
People do start new PHP projects, and people use old, but still maintained PHP projects.
If you're looking for shiny new things, look elsewhere. But you don't have to take away the working, well-known "old" away from others.
I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you have a giant ecosystem of existing libraries and a large number of existing developers compensates the fact that the language is not "cool" or is missing some feature that you probably don't need anyway or workaround it with a library.
- Existing team is comfortable with using PHP - Existing project is tightly coupled PHP monolith - Existing project cannot be migrated to other language fast enough if needed
All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people.
I must emphasis though, all party must not freeze in time. They should learn to adapt. PHP is getting smaller. The decline is slow enough to let people migrate or jump ship but fast enough that it is recognizable.
Demands are growing for languages and environments which provide more than PHP, simplest examples would be granular websocket connection control, explicit process control, whitelist-by-default security, rise of cloud and edge computing, and of course, trends, "cool new stuffs" which is not always good for everybody, but always exciting especially for the naives.
There might be a day Java is getting replaced due its huge memory usage or its tendency to be verbose and hard to read. Golang is a contender for the memory usage side of the spectrum, NodeJS is the contender for the ease of use side of the spectrum.
There might be a day C++ is getting replaced due to its "harder to write secure code". C++20 is quite cool, but there's a new cool kid Rust where you most probably won't write bad code, can be actually faster than C++ / C in some cases, and can run on browsers.
May all programmers of old languages survive and thrive and in the new world.
Even for new projects, say you have a desktop app and you want to let the users submit some data and save it on your server(like feedback or crash reports), you can do this on your server with 1 PHP file and a few lines of code, no dependencies on 300 packages.
And it will likely be an order of magnitude more scalable & reliable than the PHP, having proper logging, security features, etc.
Whereas such PHP systems in my experience tend to be unreliable, in need of maintenance and often broken.
The Java/ Spring Boot option will also take you all the way to a high-end commercial system/ large website/ webapp.
It will also be probably faster then a Java framework since you don't have a function call stack 30 levels deep (not a Java issue , all magic frameworks including PHP one have such giant call stacks)
Simple file upload without any future expansion plan doesn't need hours of discussion.
Btw my scenario was about sending feedback ro stack traces, this are just text, no giant file uploads and nothing insecure about it.
I recently upgraded a huge legacy codebase from PHP 5.2 (released 2006) to PHP 7.4 (released 2019) with relatively few changes, mostly changing the use of deprecated functions & misuse of variable references.
PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go.
[0] https://www.indiehackers.com/podcast/007-john-onolan-of-ghos...
Which is totally fine btw. Most work isn't "we're engineering a new motor for a F1 race car", most work is "this car's motor is broken, replace it". You don't need a CS degree and brilliance to write code that deals with databases and APIs, which is the super majority of code.
You need smart people that spend a lot of time on difficult problems to create strategies that are easy to follow and tooling that is easy to use. And then you just need a lot of people using those tools and applying those strategies to real world problems.
What good is it if you have something that allows those that fully grasp it to write things ten times as fast, but you only have 10 people that can actually do that? I'd much rather pick something where I have ten million people that can use it, the output is just so much higher, and you don't get single points of failure because the one guy in your city that knows that language and does freelance work has decided to move on to a different language.
I guess we don't, actually. Oh well. :'). You make a perfectly reasonable business point.
If we want to provide something to the masses, we'll have to provide something that can be used by the masses, not just by a highly trained elite. PHP is mass production development. It's not necessarily elegant (though you can do a lot in it, it doesn't have to be as messy as WP is), but it gets the job done AND it empowers large groups by being easy to learn and not requiring advanced understanding before you can actually achieve something with it.
I do still believe that we want experts that do the kind of work you're describing though. But I believe they shouldn't distance themselves from the ordinary people, but instead find their elegant solutions and then give them a handle so that the uninitiated can use them. Tooling is leverage, individually but even more so collectively. Imho, if you're a brilliant computer scientist and you work on "normal" real world problems, you're wasting your talent. Even if you find the greatest thing that runs 100 times as fast as the previous one, you've sped up one thing out of a million. Instead, build something that'll enable normal people to speed up their projects by factor two, your impact will be immeasurable.
PHP does a terrible job of weeding out the terrible hack programmers. For some reason, people have no problem going into a PHP codebase and monkeying around with it, where something like Rails or Java will at least intimidate them and make them think twice.
Regarding frameworks: of course PHP has an advantage there, because it's a more mature ecosystem. But frameworks written in PHP like Symfony or Laravel tend to forget that they are based on a scripting language (which years of optimization have made very fast for a scripting language, but still), so using their features extensively will slow down your application...
And if you are doing something moderately complex/serious/modern you probably need/want composer anyway - because uploading all of the million files via FTP is cumberstone (let's not even get into the versioning/modern deployment practices). Then you are at shell already and not that far away from other language deployments.
You can start with a plain HTML page and go "Hey, I want to do X" and just throw some code in the middle of the page. When you decide you need a database, MySQL is right there and easy to use. When you decide you need some libraries, you can just download and `include()` them. All of this can just be FTP'd up to some server somewhere.
As this grows bigger, there are tools like composer and frameworks/libraries like Laravel and Symfony. You can still FTP those, but once that gets painful you can start to learn the bit of *nix skills it takes to start managing this different ways.
At no point have you had to worry about nginx/apache/supervisor/anything else. But whenever you're ready, that's all there too.
This is basically the path at least one guy I know took to going from working in a totally non-technical industry to building a massive (almost 2 million lines at this point) application that allowed people in the industry to stop working with a bunch of exploitative big name companies and instead self-manage and earn more money. And now that product makes a bunch of money for him.
And then there's the scales that places like Twitter/Facebook/etc took it.
I think the big thing that always gets missed here is PHP's... egalitarian nature. Yes, at some point it just ends up a in some ways less-good version of other things. But it provides an incredible opportunity for people who aren't engineers to realize their ideas without immediately becoming overwhelmed with needing to learn a huge amount of foundational knowledge before they can lay down their first line of useful code, and seeing that through to crazy places.
There is also a maturity in the tooling and community for PHP that doesn't exist in newer, better languages. There's no shortage of developers, and moreso nowadays there's also a huge body of best practices that embody good software engineering.
If what you want is a monolithic standalone web application paired with SQL, I'd argue PHP is a pragmatic choice from a business point of view. I would also argue that a monolithic web application is all the vast majority of companies need.
The biggest source of bad software and failing to meet business requirements in my experience has been following the industry's whim and rebuilding every time the wind blows in a new tech stack. If you're a PHP shop delivering web applications, you will be able to do that successfully for years to come. Picking the "right" language is a wild goose chase, just be good at the language you choose and you'll be able to deliver good software reliably.
I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
> And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Did they? How?
With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to. No other environment matches that - and no other environment is supported by those hosters. If you want to run something else - like Ruby, which I prefer to use, or something that creates a binary for you - you are looking at a completely different type of hosting. Digitalocean, Heroku - and that's not as easy, if the application is not provided as a one-click-install.
I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on. And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.
> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.
I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.
I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.
I know some shared PHP host that cost $8/year and have larger memory_limit than the available RAM in $5 VPS.
Pretty much every shared host I had to work with (I've been freelancing for a few years), have been terrible, except for two platforms, both of them were expensive and aimed at particular PHP software.
From my experience, the share of people who can only deploy PHP is steadily shrinking. PHP remains the default, and popular, but easily deploying other languages is becoming more feasible, and we're shipping docker containers with Python/Go/Node/whatever code a lot more often these days.
Let's not idealize things. For moderately complex apps, even back in the days, this falls pretty fast: missing PHP modules in default distro installation, PECL/Pear extensions, hosters messing with the php.ini in bad ways, etc. And now the dependency management and deployement systems pushing you to access a shell on your server...
There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.
Also, I don't know about now because I left this ecosystem long ago, but it was very common for apps to bundle their own custom installer scripts (access a webpage, fill a form and so on). Certainly useful for the users but it was never standard and required a lot of work for the developers (and came with their own requirements and bugs).
But I like some of the recent additions to the language. At least the PHP Team keeps up with the competition.
Dart is more suited for this type of thing if one wants a new and shiny statically typed language with great performance.
Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc
I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.
That's a very big If in PHP's case.
It does a few things and does them well.
If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed.
On the other hand, language structure is quite behind others but can't blame when it had been around since 20+ years ago.
The new type hinting is so basic, not sure how realistically useful it is compared to typing in TypeScript.
Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.
The client is mostly a js library or a browser plugins. Either works.
I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.
most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.
yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.
there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.
and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.
As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.
PHP is instant and I'd like to know if there's a solution in node.js that can do the same.
At the same time PHP is trying to reinvent itself by adopting a strong type system and experimenting with async and long running processes. But these are niches that are already filled better by other languages (Java/C#, Node, Go), so it feels like they are fighting an uphill battle. But maybe it is that tenacity of the language to stay relevant that makes it attractive to a younger generation of developers and decision makers.
Greenfield projects are much less important than brownfield projects. After all, a project is new only for the first few months of its existence. After that, it all becomes legacy code :-)
And techs with mainstream adoption in the post DotCom bust era, especially if they're free and Open Source, will be around for decades. A newbie PHP programmer in 2020 will most likely be able to retire in 2065 as a veteran PHP programmer, if he/she so wishes.
Of the first programming languages that cater to novices to some degree (which is important to project health, because excessive gatekeeping is toxic), PHP was the first to make Curve25519 and Argon2id widely available (through the sodium extension). (7.2)
Even with the "just use FFI" mindset of other languages, the experience is janky at best.
For example: Before sodium-plus [1] came along (which was something I created, so I'm removing it from the table for my criticism of the JS crypto ecosystem), JavaScript required knowing which of the following packages to install: [2] [3] [4]
There was no guidance available anywhere. Some of these APIs were suitable for browsers, others for mobile devices, and still others for server-side JavaScript. And their APIs were subtly incompatible with each other.
Java's in a similar situation [5] today.
> Java (Java Native Access): libsodium-jna
> Java (Android): Lazysodium for Android
> Java (Android): Libstodium
> Java (Android): Robosodium
> Java (Android): libsodium-JNI
> Java: Apache Tuweni (crypto module)
> Java: Lazysodium for Java
> Java: jsodium
> Java: Kalium
Yikes.
With PHP7, you just had to update to the latest version (and make sure your OS package vendor isn't huffing or eating glue, which was rare but still existent) and you had it.
There are probably still languages and runtimes today that make using modern cryptography (Ed25519, X25519, etc.) a miserable experience.
Miserable experiences moving to modern cryptography keep peoples' projects trapped in an early 2000's RSA-PKCS#1v1.5 + AES-CBC hellscape reminiscent of SSLv3 but somehow worse.
Thus, I would argue that what PHP did with libsodium counts as revolutionary.
Your move, $languagesThatHackerNewsFindSexierThanPHP
[1]: https://github.com/paragonie/sodium-plus
[2]: https://www.npmjs.com/package/libsodium-wrappers
[3]: https://github.com/sodium-friends/sodium-native
[4]: https://www.npmjs.com/package/sodium
[5]: https://libsodium.gitbook.io/doc/bindings_for_other_language...
It's just a weird comparison. PHP is competitive with JS, Python, Ruby and even Java. But Rust? That's C/C++/D territory. And Go is somewhere in between.
I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
So just out of curiosity, if you hypothetically did start learning web development today from scratch, what would you spend time learning instead of PHP?
-- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen.
I can literally setup and deploy a laravel application on a horizontally scaled setup with CI & autodeploy within an hour -- while maintaining industry standards.
PHP had its problems -- historically, but so did most languages. Do you remember Javascript before Node/React? Or before jQuery/Prototype? It was _trash_.
The biggest "con" to using PHP is that it's "bad" for the resume, no one is excited about it, so when looking to hire for it, most developers don't feel inspired by it -- which is a serious consideration depending on your circumstance.
For me, I just don’t why I’d choose to use it for a green field project. Sure, it’s better now, but people have warned me to stay away from the boogeyman lurking within. Maybe it’s there, maybe it’s not. But why should I take the risk if it’s pretty much the same as other modern languages that might have cool stuff.
Anyone remember Dynamic Drive DHTML? http://dynamicdrive.com/
When working on reviews, it's often as easy as grepping for "unserialize" and working your way from there for an easy bounty.
However, PHP has matured a lot. There is not a hint of register_globals as of now, and we have proper serializers, in addition to RCE-free improvements to original unserialize().
With native support for proper password hashing, sodium, and other improvements lately, one could argue that PHP is one of the most secure languages out there.
I have my reservations against Laravel though. Its excessive use of static methods is not my appetite, and its rapid release cycle gives less headroom to keep track in contrast to Symfony for example, which follows Semver strictly.
Laravel gets a major update about once a year from what I've followed (disclosure: I've been to Laracon twice, you could probably classify me as fanboy) -- I _haven't_ used Symfony, but I have enjoyed the rapid release cycle of Larave. It also generally takes 20-30 minutes to update to the latest major release, and if not, there is a service for $10 or so to update it for you
But for larger projects the available frameworks are just okayish. I think Symfony is closest to what a good framework should be. But every time I use it I wish it would be like .NET
Today .NET core is also available on Linux and very easy to deploy so I don't think I will ever start a big project in PHP again.
But for quick smaller and CMS[1] projects PHP is still my goto language.
[1] If you are looking for a great PHP CMS: https://processwire.com/
I have quite a bit of xp with Python (Django/flask) and less with php.
I think you need VS Code with some extensions, .NET Core installed and you should be off to the races in half an hour.
Most can be done via de command line but an editor like VisualStudioCode could be handy. Personally I use Jetbrain's Rider as IDE on Ubuntu.
Deploying can be done via the `dotnet publish` command. But tools like Teamcity can also be very useful. When you built a webapp it includes the Kestrel webserver. So it is just a matter of running the app and navigating to the port it listens to.
.NET core is a complete set of tools to create console apps, (web)APIs and webApps. This includes the .NET framework.
.net has proper debugging working compared to node.js, has great standard library, can develop 3d games, servers, mobile apps, web apps, machine learning ,desktop apps and even (some) embedded devices.
Great instrumentation and support with quality updates from MS and the community. The IDE is superb and free (community edition at least), drag & drop desktop & mobile app development (if you wish).
I've worked with PHP for about 4 years (5.x - 7.0 days), .net for the next 6 years and node.js for the last 1 year, and every day i work with node.js i wish i could switch everything to .net because it's sooo much better & smoother experience, and everything just works together so well.
C# is an inflexible language that just can not have a modern web framework on it. MS extended it with hard-coded functionality to closely emulate a framework and did an ok job on it, but it emulates a closed down, inflexible framework that is stuck in time. It's not a disaster, but it doesn't compare to the stuff that has kept evolving for the last decade.
The thing that PHP does right that so few languages do is having a stateless core in the webserver. This is an incredibly efficient approach to serving HTTP traffic. Consider the startup cost issues with Java, or Rails' single request at a time model or even Python's startup (and GIL).
The second thing PHP does right is it request scopes everything. Simply throw away everything you created when the request ends. No dangling references and memory leaks (pretty much) like you get with stateful Java services (eg whatever servlets is now).
And the third is no multithreading in the core API. Starting and synchronizing threads is incredibly difficult to get right and adds a huge overhead to everything with little gain when you're just servicing an HTTP request, almost all of the time.
Hack has 2 things PHP7 doesn't quite have that I'd miss:
1. A better type system; and
2. async/await for cooperative multi-tasking.
I still hate the backslash for namespaces though.
I never understood why the HN crowd always ignored this massive benefit of PHP, in a world where it's becoming clearer everyday that keeping things stateless across the stack provides many benefits towards managing complex systems.
Sure, if you're writing a simple CRUD app with and RDBMS backend it can be just fine. But when you're dealing with more complex work just being able to start a goroutine or use an in-memory cache structure is so much nicer than having to deal with external systems.
I love stateless stuff and have started moving a lot of things to Lambdas where appropriate, but I wouldn’t use a completely stateless setup for handling large numbers of requests per unit time.
The Request is a variable, the Response is a variable, they're only in local scope?
And any data the developer uses will also be local -- and thus stateless -- unless they go out of their way to share something. (Caches are a common example, but harder in PHP since nothing by default is shareable.)
You don't need to deal with threads if you're seeking PHP-equivalent functionality.
And if you did need to deal with threads, I find your claims about overheads & difficulty hard to read without a little skepticism. An idle thread is faster to start than spawning a process, an uncontended synchronization takes only 20-250 CPU cycles (ie. a modest number of nanoseconds), and a thread pool can be sensibly managed in 2-3 lines of code.
One unfortunate side effect is PHP's choice to use the word "global" for what isn't really global but request scope. The "global variables are bad" folks look down on the PHP global scope just because of the name.
Tearing down the entire request after processing is (IMHO) a remarkable effective approach.
This doesn't matter a lot in single requests of course, but once you're writing APIs that get considerable traffic, you'll want to cut out those 50ms and the load.
In 2015, I started writing "projectionist" software in PHP to completely automate my home theatre.
I was a projectionist at three different theatres for about half a decade. I spoke with old-timers to really get it right and have been tweaking this script regularly ever since.
I've got a Netflix-style website for my movie collection. I can watch a feature either in my browser or choose to play it in the cinema. I can even schedule a feature for 7:00pm and it will wake-up 30 minutes before with music and nice lighting, assemble all the dancing hot dog ads and trailers, play it, turn the lights on for the credits, and shut itself down 30 minutes after.
The little ODROID running the whole theatre opens a chat room connection over XMPP with my servers so it can respond to controls in the app, whether I'm adjusting lighting or sound levels, putting it in Desktop mode, or manually controlling the curtain and projector.
I just ignore the PHP hate because I find it extremely powerful- it can do everything I could ever need. I also always want to keep an open mind.
I think it's a really simple system overall... It uses XMPPHP (updated for PHP 7) and otherwise it's just a lot of loops, network calls, and proc_* functions.
It keeps getting declared dead, but then, keeps rising from the grave.
I wrote PHP for a long time (more than 20 years). Many, many thousands of lines of it. I got fairly good at it. I wrote my last big application in it about a year and a half ago (PHP 7.3, I think). It's a great application, but no one would want it, as it does the same thing lots of big SaaS does.
Except one single person wrote it, from soup to nuts (no dependencies), in about six months -part time- (it was sort of a "thesis" project for me, as I was re-learning my engineering discipline), and it's quite good quality. So I guess PHP is good for something. I just open-sourced the application, and more or less sent it out to stud.
https://riftvalleysoftware.com/work/open-source-projects/#ba...
I discuss my design methodology for the project here: https://medium.com/chrismarshallny/forensic-design-documenta...
That said, I never really liked the language, and am glad to have seen the back of it. I write full-time in Swift, nowadays, and would be thrilled to never write PHP ever again.
Despite all the hate, though, it's a perfectly good language; especially with all the stuff added in 7+.
And im saying this without hate or malice. I love PHP since I was a PHP dev from 5.2 - 7.0. I built PHP libraries and WordPress plugins that have helped many people. Ive since moved to Node because PHP jobs have dried up in my country.
PHP devs arent respected which is sad because we all belong to the same programming community. And PHP has contributed a lot to the proliferation of websites. At the end of the day programming languages dont matter to businesses as long as it gets the job done at a reasonabe cost.
Languages are tools that suit different needs. Use the best tool for the job, pay attention to industry trends so you don't become a Cobol dinosaur with no job prospects. Switching to node is a good career move but it won't be your last. Node has incredible momentum and developer mindshare. You can accomplish a lot with it but node projects are difficult to maintain.
Never stop learning or growing.
When I got started in 2000, php developers weren't as smart as perl developers. Then it was asp. No serious business would use php over asp. Java developers always had this attutiude but they were always treated as second class from c++ developers who were treated bad by c developers who were using a toy language compared to asm.
At some point 2006/2007 php became cool. But then the facebook movie came out and php was uncool again. Ruby on rails was better (unless you were twitter and wanted to scale). Then node. Go. Serverless.
PHP has always been anticool and looked down on. You need a strong sense of self to get involved.
For people who are busy with life and work, but who want to learn a new cool language, it would answer the question "what's the cool thing right now?". You look at the timeline, it's language X.
This also enables fun future oniony articles like "Go no longer cool", "Rust going the way of the dinosaur", "C++ is the new kid on the block", "Node.js is dead, long live X" etc.
I've seen some codebases using an even older version, and I think I can understand where people are coming from with their angst towards the language - but I think we should look at ourselves before we jump to the bandvagon of just hating something blindly - I remember being part of the "Apple sucks" group for no other reason than hype, and now I've used one for years as a work machine.
For me, having no standard HashMap and having to set strict mode params in functions - is an instant no go. There is no lack of better options.
Could you elaborate on this one, I am not exactly sure what you mean by it.
I haven't touched it (beyond very basic edits on my website, wordpress etc) for over a decade, but recently I inherited an older codebase at my new job. The existing codebase is an absolute mess, worse than the shit posted in those tutorials I mentioned.
But as part of the job (beyond rebuilding the application), I also had to add a big new feature to the application, a REST API. Keep in mind that due to constraints on the systems we install on, it had to be made in PHP 5.2 or 5.3 - one difference being that the older version doesn't even support an array creation shorthand (`$var = []`).
I could keep interactions with the existing codebase to a minimum. The rest was... actually surprisingly all right, thanks to me knowing what a REST API is and how to structure an application properly.
I did have to basically write my own framework (sigh) because pretty much nothing is still available that works on pre-array-shorthand-versions of PHP, but it was fairly minimal; an off-the-shelf router and URL matcher (can't be arsed with writing that myself), middleware for authentication, and a simple class structure to encapsulate different output formats (json, csv, streaming plain text).
Granted, this old version of PHP is seriously rough around the edges, and at the time it already represented great advancements in the language. I mean before 5.4 the language didn't even have a function to set the HTTP response code (you had to write the header manually).
Though I also totally forgot things like array creation syntax and wonder how I could have ever lived without stuff like that shorthand.
Of course you can write good code in modern PHP, but you can write really bad stuff too - more (at least imho) than in other popular languages. And then the whole ecosystem "drags you down" and gives PHP a bad rep -> but I don't think it's totally undeserved.
On a similar note, this actually compelled me to try Rust/something similar instead of just going straight back to Python (which I still love tbh).
camelCase? snake_case? nocase? Who knows what the global function will be.
And who knows what order the arguments should go in. Sometimes the array is first, sometimes not (in array iterating functions like map).
The thing that got my goat the most however was that referencing an undefined variable merely caused a warning, but referencing an undefined key in an array borked it.
And what's with arrays and maps being the same thing?!
The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where you missed to catch an exception and it will code complete stuff.
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the world a little better for a lot of people that need to use it in systems that are built with parts in PHP.I cant see how that is a bad thing.
The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Few of the people I worked with have only one tool in their belt, and they can work in any language. We all have some favorable setup that we think is best for us/others to use in order to build better software with quicker iterations. But all of us (hopefully) also know that few, if any, stacks are 100% solid and consistent after a couple of years. There is always some parts that we wish would not exist, some script that magically does stuff that we do not dare to touch, some service that is written in some fancy language by that awesome dev that worked here 10 years ago or some really central part of our software that is written in Python, talking to a module written in C that needs to be compiled with a specific compiler that went dead 4 years ago. Even if we dream about the perfect system that just works (LIKE I WANT IT) and has a fantastic setup, it is only at specific snapshots of time systems work like that. Time, people, organizations, product requirements, marketing efforts, buzz, hacks, fixes, playfulness, boredom etc all makes system degrade over time and while it is important to manage these debts, it is more or less impossible to have a system in a state where it will always have the tech stack you want right now. That way, we will always have to address bugs in PHP, old Python-versions, rage over custom compiled nginx or whatever. Whether or not PHP is a good language or not is a meta-discussion IMO. If languages that are used by a lot of people gets better over time, that is awesome in my book. Having a perfect tech stack with only funny/new/fancy/awesome tech is at best an interesting mind experiment.
If PHP being slow stops you from being "good enough" then it's very likely that you can just isolate the part where PHP isn't doing a good job, re-write that in another language and keep the parts where PHP is working fine.
Because, if others use it, I have a higher chance of also having to use it.
I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these languages. Had they chosen Python or Ruby or C# or anything else, I would have to use these languages. And it does not apply only to work: if I want to contribute to the Linux kernel, I have to do it in C; if I want to contribute to LibreOffice, I have to do it in C++; if I want to contribute to MediaWiki, I have to do it in PHP; and so on.
Convincing others to not use a poor language reduces the chance of myself having to deal with it later.
people forget though that wordpress, drupal, joomla and magento are all written in php and most likely accounts for 70% or so of all the websites online today.
php is going to be around despite all the negativity and fanboyism of other languages. you can't go wrong with knowing php if you always want something to fall back on if you need a job. while coding wordpress websites isn't the greatest job in the world, it is a job and be thankful for that especially during these times.
I've hardly ever used PHP over the course of my 20 year career, being mostly on C, Java and JavaScript, but on the few times that I have, I have always been really impressed with all aspects of the experience.
Whatever academic semantic deficiencies PHP might have, there is no more accessible language for making web site backends with and its sad that so many people are discouraged from using it.
For web applications, I think PHP's idea of a clean slate for every request also makes a lot of sense and immensely simplifies development. I can write a simple PHP application that handles thousands of concurrent requests without even thinking about threading, synchronization, memory leaks or anything like that because handling that stuff is basically built-in.
PHP has a really good ecosystem. A framework like Laravel can do just about anything you'd need in an application out of the box. Routing, rendering HTML, generating URLs, handling sessions, logging, validating requests, an ORM, translations, encryption, sending emails, queues, schedules, caching - it's all there. I've never seen anything quite as fully-featured in any other language. On Packagist, I can find packages for pretty much anything from clients for obscure SOAP APIs to libraries for handling GraphQL. There's also a lot of great tooling, with a good package manager, static analysis tools like Psalm, code formatters etc. Also, PhpStorm is a fantastic IDE.
Outside of PHP, I mostly have experience with Java and JS.
If you know Java, modern PHP isn't all that different. Java has some nice stuff that I hope we'll get in PHP some day (generics is the big one). I built an application using the Play framework (Java version) a couple years ago and it was quite similar to modern PHP frameworks. However, there was always a bit more complexity with Java. Everything was just slightly more complicated. So with the trade-off basically being performance (which is better in Java) vs. ease of use and developer experience (which I think is better in PHP), I'd choose PHP most of the time.
Now, when comparing it to JS, I'm really glad I mostly get work with PHP instead of JS. I know this might sound strange coming from a PHP developer, but holy shit, JS is a mess. When writing JS, I'm constantly going between "oh, nice, this is really easy to do with Vue" and "what the fuck does that error even mean, how am I supposed to find any problem buried under several layers of bundlers, polyfills, loaders, transpilers and reactive frontend black magic?". If JS wasn't the only thing that works in a browser, I would avoid it like the plague.
Personally, I do not enjoy the Java-style 'enterprisey' direction of PHP. I don't like types, anonymous functions, treats and all the other fancy stuff. To be honest, I think I myself would still be happy with PHP4. I use thin scripts, almost no classes, alternative PHP template syntax and I am completely frameworkless. But I guess I am just a nihilist ;-).
I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature.
I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an ecosystem (GeSHi was used everywhere few years ago), but it looks like no-one is working on it anymore so MediaWiki did an strong technological move to use Python via a sub process.
This kind of move (dropping a existing natively written tool for a tool from another language) shows how bad the ecosystem situation is.
Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).
Parent poster said that they couldn't do that on their host, though. Which breaks a MediaWiki feature (syntax highlighting for code blocks).
This problem isn't unique to PHP. I have seen this is many projects across all kinds of different languages and tooling.
Unfortunately, if there's no good alternative written in PHP, MediaWiki could have either reimplement it from scratch. In my opinion, GeSHi isn't the best implementation of a syntax highlighter, so I get their reason to not adopt it. Writing a syntax highlighter from scratch isn't a trivial task either.
None of this says that the PHP ecosystem is dying though. MediaWiki isn't going to suddenly move away from PHP. Nor will many, many of the other big name projects that are still built on top PHP, and as long as there are big name projects, PHP ecosystem will continue to evolve.
I will say choosing a Python sub-process at the sacrifice of portability (considering how many people simply run this on a PHP webhoster) is quite surprising.
Maybe the worst thing is the composer (it's slow.)
composer global require hirak/prestissimoIt's really good for it's intended purposes and is getting a lot better in latest versions.
This is what programmer and blogger Jeff Atwood - who isn't a fan of PHP - has written about PHP:
"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"
He wrote that in 2012. It's 2020 and I can't think of any other language that has caught up with PHP's ease of deployment. If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
Anything with containers. Docker was a real game-changer here.
>In our dashboard you will find pre-configured Open Source apps like WordPress, Plone and other. They are all based on the official docker images and can be deployed with just one click.
Otherwise I don't see how something like this is that much more difficult https://www.openshift.com/blog/deploying-applications-from-i...
Or this https://kb.sloppy.io/en/articles/1313693-setting-up-mongodb-...
Still if I want to write a simple web app in < 1 day, I would definitely use PHP.
Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests for some domain to an index.php file, or you proxy them to a locally running container (where you also don't have to worry about versions of software installed on that server, clashes between different apps, etc.).
Commercial PHP webhosts also have an "installer" for automating all of this, provisioning databases, etc.
A lot of this can also be automated by various Kubernetes controllers (DNS configuration, TLS cert provisioning, databases, volumes, backups, monitoring etc.) if you already have a cluster. And for packaging installable apps, there is Helm and its charts (e.g. https://hub.helm.sh/charts/bitnami/ghost), you can also manage them from a GUI dashboard (https://kubeapps.com/) or even from a git repo (https://argoproj.github.io/argo-cd/) if you want to have a repeatable history of all changes to the environment, updates, etc.
If using a popular framework the documentation usually provide these lines.
And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
So is setting up a `proxy_pass` to a locally running container that exposes a port to localhost (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...).
Literally, just start `docker run` with a proper restart policy, set up a proxy_pass on nginx and you're good to go (unless the app requires external services, databases, etc., but you have the same problem with PHP).
Plus you don't have to worry about things like "do I have the correct PHP version for all my apps?" or "do I have the necessary PHP extensions installed in the system-global PHP?
>And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
Setting up a Kubernetes cluster is indeed complex. Installing apps into an already configured cluster (e.g. ordered as a service from someone) is not (unless the app itself is complex of course).
I was comparing it to the automation tools that "traditional" webhosts have for installing and managing application deployment, replying to a comment above ("They had to write an installer ecosystem..."). If you just want to have one VPS with nginx on port 80/443 and run apps there, you don't need any of that stuff. The container images are the same either way.
In that sense, PHP is like a early variant of Lambda ;) When there would be a universal, simple-install, simple-use, low-requirement version of Lambda (incl. Gateway etc) we would see a easier hosting market for all the languages beyond the public clouds.
When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.
I suspect you're narrowing the scope of what this article was intended to cover. It is not just a look at PHP 7.4; it's just using the recent PHP release as an excuse for a look back at the history of the language:
With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.
My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now, so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
This meme of people on HN judging articles entirely on their title really needs to die.
> My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now
You keep saying that and I keep replying that nobody was ever arguing otherwise.
> so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
Again, they wasn't. You just assumed they did; presumably because you just read the title and the pre block and skipped over all the rest of the content.
Nope, read it all as I mentioned already.
Personally I liked that php has an ultra low entrance bar: shared hosting for $2, ftp deployment, no advanced syntax to understand. When starting work in teams instead of solo and coding nontrivial business rules, this ease of doing died for me. Moved on.
Many years of JavaScript, doing nodejs since 0.4, it was just like having superpowers and doing isomorphic things. Mixing things every other month with coffeescript, babel, typescript and trying a different framework for every new project. What once felt refreshing is now just exhausting and JS projects tends to end in rewrite loops.
Before/Inbetween/After there were many languages, from C at university, to C#, Ruby, Go, ... . Mostly the tech didn‘t change much, but over time emotions change for me. Longest streak of love had ruby, shortest had Go (just a few weeks before it became disgusting for me). I believe thats Personal and different for everyone.
After all my reflections I finally settled with just two choices of techstacks: Elixir/Phoenix for all things Web and Rust for everything else.
Writing highlevel businesscode , interactive exploration of things, CRUD things and realtime frontends in Phoenix is a breeze. But this ease of use has tradeoffs as always, I always feel that this dynamic code is somewhat „fluffy“, but ist seems that this is a key to prototype and ship things rapidly.
When i do want to do things that feel more „substantial“/„meaningful“ than just assembling yet another web product, I Switch to Rust. Producing a statically linked, crosscompiled binary that is „proven“ to work after discussing with the compiler is deeply satisfying for me. Unlike those „fluff“ / yet-another-web-product work.
Full Circle to PHP: awesome to see static typing available now! But this alone doesn’t make it feel so heavily baremetal for me, still fluffy with types bolted on. It is the fastest php ever, but still in the ballpark of scripting languages. It has mature, productive frameworks, but Phoenix feels superior and leading the way (next rails? Dunno), so why bother if php plays catch up to moving targets?
Software Development has become somewhat like fashion now, and PHP looks like those jeans jackets people had in east germany. Not inherently bad, fully functional for its purpose, but once you experience the taste of freedom in the western world you insist to have „real“ things. Best metaphor I can think of, but as stated: most discussions here are highly emotional, and it’s hard to put that in words.
It has nothing to do with the language itself and everything to do with the user of the language.
[1] The Pervert's Guide to Computer Programming Languages https://www.youtube.com/watch?v=mZyvIHYn2zk
But I still think PHP is really cool when you just want to hack something together and indeed like many people said before run it anywhere without headache. You can output formatted text really easily. Other languages are way more formal about output. I hacked together a song recommendation and voting system for my marriage website in a few hours and people loved it.
That is probably never going to happen. GraalVM native images are a more realistic approach in this space, and even that is not trivial in most cases.
Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.
The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Ajax endpoint that processes a chunk at a time...) and the when I asked a marketing friend of mine who works with Wordpress he said that redis is an “advanced requirement” and I should keep things simple.
In Django land I’ve always set up queues even just to send emails because it keeps things snappy.
What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?
Using Wordpress (or it's plugins) as any kind of reference for what PHP is capable of, is like using McDonalds as the basis for a cook book.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.
PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.
Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .
Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
Picking up Kotlin feels like coming home.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.
You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have.
It also supports class inheritance, abstract classes, interface classes, class traits, etc.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
The first example in that article even highlights that `in_array` has a `$strict` parameter.
I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.
Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.
On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.
I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.
I hope you like working on legacy projects full of spaghetti code.
I stopped coding it professionally almost 20 years ago (!), but it was a great foundation to a ton of stuff, and going back through the release notes and modern frameworks I'm actually thinking I might use it for a few side projects.
Don't let anybody put you off, I say if it appeals to you that you should go and learn it and get some work with it.
It wasn’t bad. Good docs, reasonably easy to run & deploy (except Wordpress). I don’t think I’ll ever use it again more due to career reasons, temperamentally I prefer the backend, but given the same circumstances I’d use it again.
It's common to have things like queue workers implemented as long-running CLI processes. I just checked one of our services at work and there's a queue process that has been running for more than 4 months. There might be others that have been running even longer, but I don't feel like checking every service right now ;)
Projects like Swoole or ReactPHP are trying to make similar things possible for serving web requests too.
I dimly remember that "proper" Unicode support was planned for PHP 6, and being one of the features that delayed that version, and contributed to it being skipped altogether.
The main weakness I see in PHP is the lack of modules. PHP provides namespaces to avoid name conflicts. First of all, that does not completely root out naming conflicts. The developer who puts a namescpace into their code can only hope that it does not clash with someone else's.
Secondly, it makes it necessary that both, the code that provides reusable functionality and the code that uses it have to deal with the issue of namespaces.
A module system like Python and Javascript have is superior to this. Then only the user of the reusable code decides where to put it into the namespace.
Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
I do not see what the use case for PHP is in 2020.
PHP has one of the most abhorrent language syntax designs this side of Perl, and the standard library is wildly inconsistent.
I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
How do you know what version you have deployed unless you copy everything you deploy to some archive somewhere?
How do you roll back?
How do you find out if you monkey-patched something?
Deploying Docker images or static binaries is vastly superior and no more difficult. It's just a new paradigm.
All three of the issues you raise would be solved by involving a VCS somewhere in your FTP deployment.
Incidentally, claiming that either option is "no more difficult" than FTP upload or even using VCS is either disingenuous or at least a little blinkered. FTP can work as simply as copying files between "folders", I've successfully taught my non-techy parents to use FTP. Setting up docker images or static binaries requires significantly more understanding of what's going on but of course provide speed, consistency and scalability benefits.
Containers definitely has its place, but there hundred of thousands problems out there that needs to be solved for a low cost, otherwise it will never be solved, and a container will just increase that cost with little or no gain for the customer.
Many small businesses just want to get online, how does PHP help them? Actually it doesn't.
Small businesses use Wix, Shopify, Medium. Anything that prevents them from having to worry about code.
Python has a ridiculous time it needs to start up, it is not suited for any batch task that requires a lot of process creation.
> PHP has one of the most abhorrent language syntax designs this side of Perl and the standard library is wildly inconsistent.
At least it has a standard library that is both usable (in contrast to the JS ecosystem, remember left-pad?) and actually not that inconsistent if you have experience in developing C - most of what is described as "inconsistent" comes right from there.
And: the stdlib of PHP can easily be expanded upon by a rich variety of Composer libraries that can easily be deployed. Let's compare that to... Java, for example. Three popular dependency managers (and build tools): Ant, Maven, Gradle. Plus classpath worries if you're using Tomcat or other application servers which means you also have their libraries in the mix.
Changing code in production? In PHP it's as easy as changing the file using rsync and automatically all new incoming requests will use the new code, vs Java where you have to restart the server (which for large project means minutes of downtime).
In PHP you just need to add to your HTML page a few lines of PHP code and copy it using scp to any share server hosting that costs 4 dollars a year.
No "automation", no "cloud", no REST APIs, no WSGI/Gunicorn, etc. just plain Apache with mod_php enabled, which is available everywhere. I don't think anything can beat PHP productivity for such simple usecases.
PHP isn't being replaced so much by Python, Go, and Rust as it is being replaced by Medium, Wix, and Squarespace.
This is the direction things are trending.
Unless you're distributing your binary to 3rd parties, why?
If you really don't want to deploy changes to e.g. a single/small number of controller or template files as independent file changes, build your PHP app into a .phar archive, and deploy that.
I don't specifically think PHP, when run (IMO) the best way it can be, is "easier to deploy" but I also don't think it's harder either.
I'm going to ignore your other comments because they're personal opinions and while you express them as facts, I realise you probably mean them as statements of opinion.
But the last part, I just don't understand:
> I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
Who is the "we" in this statement? You clearly don't like it personally, so why does it affect you, at all? I'm not a huge fan of Java, but I don't go around claiming that it should "die" or that humanity is somehow worse off because it exists.
There's no such thing as a client-side PHP application, so it doesn't even compare to e.g. genuine concern over tech choices that are 'forced' upon users of a website (e.g. Flash, SilverLight, ActiveX, javacript bloat, etc). If the backend part of the system does what it needs to do, the language/framework/runtime it's written in/with is meaningless.
I see on their website they are on version 7.x, and have documentation online there also for 6.x, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, 5.2, 5.1, 5.0, and 4.2.
For those with a conservative server software approach who install a Linux distro that will have long term support and then stick with it up until near the end of that long term, and stick with the version of PHP that came with the distro, we have to go back to 5.5 or 5.4 or maybe even earlier to get a Laravel that works with our PHP.
(Symfony appears to be at 5.3, with 4.4 and 3.4 still maintained. 3.4 will work with most major distros that are still in LTS, except I'm not sure about RHEL. 4.4 has the same requirements as Laravel 5.6, and so misses out on some existing LTS distros).
also laravel is open source, if you want to update an old version because you want to run unsupported software, you are welcome to do it yourself also.
Why is PHP trying to become java so hard, if there is already java and .NET ?
But.
I recently joked in frustration that I missed the days when PHP was a cargo cult version of Perl rather than a cargo cult version of Java. It's a joke, it's not a fully fair criticism, but I can't help but feel there's some truth to it. PHP is a fast dynamic language literally designed for embedding in web pages, with a batteries included mindset that shoves all sorts of useful things into the language itself (yes, kind of haphazardly and occasionally in slipshod fashion). If I want to know what the path of the request is, for instance, I could just do:
$url = parse_url($_SERVER['REQUEST_URI']);
$path = urldecode($url['path']);
$request = Laminas\Diactoros\ServerRequestFactory::fromGlobals();
$uri = $request->getUri();
$path = $uri->getPath();
"Come on, it's still fast." Yes! Sure But you know what's faster? Looking at the $_SERVER variable. I can't help but paraphrase a famous quote:
Some people, when confronted with a problem, think "I know, I'll use a design pattern." Now they have two problems.
I know. I know. Using factories and dependency injection containers and tying yourself into knots to avoid anything that remotely looks like a global makes things testable and composable and decoupled, but it is so freaking heavyweight compared to other dynamic languages. Python's Flask web framework has a global context object just called "g", which is essentially a singleton that lets you arbitrarily store properties on it, not just variables but database connections. OMG GLOBAL RUN AWAY AAAA no, you know what? It's fine. Yes, in some sense it's probably more dangerous because someone could come along and blow away your database connection by overwriting the "g.db" property, but maybe sometimes the simpler answer is "well, don't do that."
Look, I've used Symfony, and CakePHP, and Laravel 4. I think I even contributed a test to Laravel 4's testing framework way back when. They're great. And I'm not saying "let's all just throw out objects and all separations of concern and mix HTML and business logic like it's 1999, baby." But PHP is virtually a framework on its own, and at times it feels like many smart people have put a great deal of effort into building entirely different frameworks on top of it, paradigms that PHP wasn't intended to fit into.
So for my new project, I'm just... rolling it all from scratch. I don't have a composer.json file because I don't need PHP-FIG compatibility--although the four-line autoloader I have would technically load any PSR-4 compatible module if I wanted to. It's using the front controller pattern, it has regex-based routing, it has a simple template system with layouts, it has request and response objects, it uses type hinting. It's probably not super great, but it's... kind of refreshing to write this way.
I love PHP despite its warts, and it's great that it's learned so much from Enterprise JavaBeanServerNetSwingPattern land. But I admit I'm kinda hoping for it all to get a little more relaxed about, you know, still being a dynamic language.
go is incredibly weak language in some regards (error handling?)
From these 3 I would still pick PHP for webdev.
Lots of legacy stuff has been removed.
Static typing has been added as a feature back in PHP 7.0.
The paradigm and the workflow are alien to most, the discipline needed to write with it needs learning.
Can you point to some research that scientifically proves that the use of dollar sign in variable names makes it harder to solve computer science problems?
2. Carpal tunnel syndrome, especially on keyboards where "$" can only be reached via shift.
2. rebind your keyboard.
I think it’s a good first tinkering language for people around that age: sort of like BASIC, but for the web.
I am glad PHP is still around; it is a very useful signal on the resume or CV of someone who uses it a lot.
It’s sort of like c# in that regard (exception granted for vertical-specific devs who work professionally to ship commercial apps with Unity), or Visual Basic before it.
Same goes for heavy Java outside of Google/Amazon backend, or outside of Android.
Most of these people are desktop Windows users by choice, too. It’s a very specific type of techie. Perhaps one day I should make an ishkur-style taxonomy. :D
I think this is also why almost all forum software is written in PHP.
It has type hints for function parameters and return types but not for arrays. This makes it useless to me.
I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments to hint to an IDE is not a real solution.
It's still just a vector<void* > in C++ parlance. Nobody would take you seriously if you said "just add comments to indicate what your void* might be" in a large codebase.
I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.
If I have a basket of fruit, all the items in that basket container are fruit. I can't put anything other than fruit in it. It's a basket of fruit. I know how to interact with the fruit due to its type.
If I am able to put dung into my basket, my fruit is spoiled and I cannot assume how to interact with the objects in the basket.
This is a PHP array without types at the array level. I can put dung into it and have no idea how to interact with it.
Or are you saying that a container of any type is perfectly acceptable? Did the other languages (C++, C#, Java) get it wrong?
eg. on this line can you tell me what the array holds and how I interact with it? What does array $operations hold?
https://github.com/magento/magento2/blob/420a8b6209a4e62ede9...
So, if I type out that something's a Banana, and the compiler stops and tells me it's actually an Apple, why did I need to type anything?
> Did the other languages (C++, C#, Java) get it wrong?
I can only speak for Java, but here goes. Here's something that compiles without warning and crashes at runtime:
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
basket[0] = new Apple();
basket[1] = new Banana(); // Crash here
void handleFruit(Fruit fruit) {
if (fruit instanceof Apple) {
System.out.println("Apple");
} else if (fruit instanceof Dung) {
System.out.println("Dung");
}
}
void foo() {
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
handleFruit(basket[0]);
handleFruit(new Apple();
}
void handleFruit(Fruit fruit) {
System.out.println("Do I get called?";
}
void handleFruit(Apple apple) {
System.out.println("Or do I?";
}
Anyway, just like me, this Bucket<Dung> is full of shit. Time to dump it all out. I could put it in the compost, or in the veggie garden. Anywhere that contains Dung. Likewise, the Fruit could go in a Bowl, or a Cupboard.
Here's a first pass at it:
interface Transfer<F, T> {
void dump(F from, T to);
}
class FertiliseGarden implements Transfer<Bucket, Garden> {
public void dump(Bucket from, Garden to) {
}
}
class PutAwayFruit implements Transfer<Basket, Cupboard> {
public void dump(Basket from, Cupboard to) {
}
}
interface Transfer<F, T, X> {
void dump(F<X> from, T<X> to);
}
I can't call how Java handles the above stuff as 'wrong', since that's stating it too objectively. I can only say I disagree with the above design decisions (if they were deliberate) or I find fault with them (if they just turned out that way).
You can't do that in C++. You can slice objects but you'll get a warning in any good compiler.
I would like to know the type of the object I am working with else it'd be "auto everything" in C++ and it makes the code unreadable.
That's basically what I am finding objectionable about PHP because you've got types added as return types from functions, and also types for parameters and you can enable strict checks for the types but none of it makes any sense when you can just get an array of unknown/any type.
It's like a C++ vector of void pointers that you can cast to whatever you'd like it to be and that's really bad. It's also not very maintainable, particularly in large codebases.
It's a strange oversight in PHP given the type "safety" enforced elsewhere. I suspect they just aren't doing it because so much code would break.
I would like to see this typed array introduced so you can look at horrible codebases like the Magento example (there's loads of it) and see at a glance what you're dealing within instead of "an array of unknown type".
I will use your FertiliseGarden function shortly, thanks.