
A look at modern PHP - lukastyrychtr
https://lwn.net/SubscriberLink/818973/507f4b5e09ab9870/
======
s1k3s
The amount of misinformation, false claims and unsupported statements in this
thread is mindblowing for the quality that I've been used to see on HN.

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...](https://symfony.com/blog/symfony-was-the-backend-framework-
with-the-most-contributors-in-2019)

[2] [https://github.com/php/php-src/pulse](https://github.com/php/php-
src/pulse)

[3]
[https://trends.builtwith.com/framework/Laravel](https://trends.builtwith.com/framework/Laravel)

~~~
watermelon0
Where to begin?

\- 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.

~~~
alphadevx
Where to begin indeed!

> \- 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](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.

~~~
bernawil

      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.
    

if each web server thread that serves a request ends up spawning a full PHP
process then it's not 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? 
    

proceed with all the rest of the bootstrapping code in parallel instead of
blocking and waiting for each.

    
    
      is a synchronous thread, as described above above. By design.
    

it's a synchronized full forked process. Because the runtime was written using
memory unsafe C features from the start. By design doesn't excuse it being a
bad design.

~~~
alphadevx
It's php-fpm persistent threads (seperate Daemon listening on port or socket),
not web server threads, just to be specific. You have a lot of control of how
many PHP threads you will allow per web node using php-fpm, very reliable
tech. The days of mod_php are long gone.

So I meant one thread per request at the php-fpm level, not Nginx/HTTPD level.

* Edit for spelling

~~~
bernawil
> PHP threads

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.

~~~
alphadevx
Oh I see, yes you are correct each request will bootstrap your PHP code stack
framework each time (mitigate with opcache). Seems weird I know, but it goes
back to that "shared nothing" principal: nothing is kept in memory between
requests. On the plus side of that principal: nothing is kept in memory
between requests that is not currently being used.

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.

------
fredsted
I wonder if most developers that trash on PHP for trivial issues like seen in
this thread haven't been using it for many years, or had a bad experience
(e.g. maintaining a legacy app).

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.

~~~
ragnese
I'm a PHP "hater", so take this for what it's worth.

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.

~~~
macinjosh
> if you try to use a string as a key, but it is a string of digits. It will
> automagically(sic) convert your string to an int and totally F-up your
> dictionary

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.

~~~
jrumbut
My guess is that the numeric indexing thing happens a lot but it's definitely
rare for it to cause a visible problem and even rarer to be identified as the
cause since it is unexpected.

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.

~~~
ragnese
I'm in a similar boat. I've decided that whatever it is that makes PHP
successful must be exactly the same thing that has made JavaScript successful.

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.

~~~
jrumbut
Maybe, in my case since I am currently in the non-PHP phase of my alternating
PHP/non-PHP job history. PHP has been less than 50% of what I've done (the
rest being far more on-trend, if you will) though disproportionately
represented among successful and profitable projects.

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.

~~~
tnorthcutt
_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?

~~~
jrumbut
I think there are a few, and maybe I am the only one who has ever been foolish
enough to think these things or incompetent enough not to achieve them.

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.

------
Svip
Even with PHP7, PHP still feels like it is playing catch up. There is nothing
new or revolutionary in PHP7, just adopting features present in other major
languages. Adopting as other newer languages like Go and Rust seems to be
moving beyond those features. A catch up into a world that's on its way out,
if one will feel so blunt.

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?

~~~
fetbaffe
Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It
is still basically the same language/package. I’m not saying that is bad, but
why does a language need to be constantly revolutionary if it solves what it
sets out to solve well?

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.

~~~
mekster
Other languages haven't caught up on PHP about ease of deployment.

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.

~~~
411111111111111
Thats hot patching, not reloading as I've come to know it in the web
development world.

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.

~~~
vertex-four
You're entirely missing the point by focusing on why someone may or may not
have used the wrong words - with an application written in many other
languages, you have to do something special to be able to update some server-
side code and have that new code be run when you next hit the server.

~~~
411111111111111
If pointing out that he's using the wrong technical term is 'missing the
point', I'm not sure there was one to begin with.

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.

~~~
vertex-four
I can, on my local server, change the code, hit it again, and have my changes
reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java
requires _extra configuration_. That's the point.

~~~
erik_seaberg
Rewriting a bunch of text files isn't atomic, so you need to take a planned
outage or atomically rename the source dir so you don't serve 5xx errors from
parsing half-written source. At that point you might as well have a deploy
process, which can be as simple as "rsync && mv" into each host.

~~~
vertex-four
Indeed, but again, I don’t care about that while I’m developing locally.

------
xd
I've been using PHP professionally since ~1999. I remember ripping the Perl
fanboys in the early 2000's until the foundations of PHP started to crumble
with what are issues that stick in peoples minds today; so I do wonder if we
brought it on ourselves sometimes. But PHP moved on carefully to preserve
backwards compatibility. I still have a SaaS first developed back in 2005 on
the latest version of PHP that's happily ticking over with the minimal of
maintenance required - the code base is horrendous but that's because a
developer I had with me at the time made a massive case for "software design
patterns" that he crowbarred into every nook and cranny regardless of if it
was required or not.

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.

[1] [https://stitcher.io/blog/php-in-2019](https://stitcher.io/blog/php-
in-2019)

[2] [https://stitcher.io/blog/php-in-2020](https://stitcher.io/blog/php-
in-2020)

~~~
hnarn
> 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?

~~~
xd
When I started I struggled with browser inconsistencies. Over the years
Javascript has come a long way and whilst I'm not 100% sold on node.js, I like
the idea of using the same language across front and backend so likely would
have gone down that road.

~~~
jstummbillig
If after 20 years of PHP experience you arrived at "not 100% sold on node.js"
as your most likely alternative, that to me more than anything else signals a
strong, ongoing vote for PHP :)

------
KerryJones
As someone who has programmed PHP professionally for 13+ years (and also JS
and Python) I have never run into anyone who can place a solid argument since
the PHP 7 + Laravel.

\-- 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.

~~~
Ayesh
All my projects require PHP 7.4, and it's such a joy to write the modern
almost-strict typed, namespaced, and code that is often inter-operable, tested
with a nice testing framework, and managed with an excellent dependency
manager.

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.

~~~
KerryJones
What's wrong with the static methods? And do you mean beyond helpers?

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

------
thdrdt
I've been using PHP for over 15 years and always liked it. There is no other
webserver language that's so easy to use and so deployable while still being
fast.

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/](https://processwire.com/)

~~~
nsomaru
What if you’re looking for a great way into .net web dev on Linux? I’ve been
struggling to find a good guide that combines dev env, deployment and a good
web framework. Any advice?

I have quite a bit of xp with Python (Django/flask) and less with php.

~~~
thdrdt
Maybe this is a good place to start:
[https://dotnet.microsoft.com/learn](https://dotnet.microsoft.com/learn)

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.

------
cletus
It saddens me to see some of the (largely baseless and otherwise largely
historical) hate for PHP. I use Hack in my day job, which has at this point
diverged from PHP, and I like it for the most part.

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.

~~~
spdionis
> The thing that PHP does right that so few languages do is having a stateless
> core in the webserver.

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.

~~~
kstrauser
Most of the interesting things I’ve worked on would fall down if you couldn’t
cache _some_ stuff across requests, like database connections. If every
request requires a new TCP connection, even if to something lightweight and
fast like a local pgbouncer instance, requests are going to be a lot slower
(and the time spent context switching from userspace to kernelspace and back a
lot higher) than if you could reuse one from an in-memory pool.

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.

~~~
cweagans
You can do that in PHP. The PHP database library has a persistent mode that
you can use. See the last paragraph of example 3 + example 4 here:
[https://www.php.net/manual/en/pdo.connections.php](https://www.php.net/manual/en/pdo.connections.php)

~~~
kstrauser
Sure, but then it's no longer purely stateless, and honestly no more isolated
than, say, a Django app (assuming it hasn't been deliberately broken to share
state across requests).

~~~
cweagans
It's still completely stateless from the dev standpoint (even if it's not
truly stateless under the hood). It's more like a caches connection if that
makes sense.

------
pachico
I have been coding in PHP for 15 years (not exclusively) and indeed many
things had to improve. Nevertheless, many other languages also had to. Just as
an example, PHP had a much more mature vendor requirements system than Go and
years before! What I see many people tend to fail to observe is that a
language is also good as the amount of value it can being to the business and
in that PHP was and still is phenomenal. Anyhow, I'm really happy to see how
it has evolved.

------
thrusong
I've been programming in PHP since 2007 and I absolutely love it. I've long
ignored the hate for it here. I worked hard and followed best practices to get
good at PHP.

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.

[https://www.youtube.com/watch?v=Cc8K6lg7Ag8](https://www.youtube.com/watch?v=Cc8K6lg7Ag8)

~~~
infamia
This is fantastic! Do you have a code repo somewhere?

~~~
thrusong
Unfortunately, no, I haven't published the source code. I'd maybe like to
commercialize it in the future, but it would require either some tech to
compile PHP or would need to be re-written.

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.

------
ChrisMarshallNY
PHP is the Web's C++.

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...](https://riftvalleysoftware.com/work/open-source-
projects/#baobab)

I discuss my design methodology for the project here:
[https://medium.com/chrismarshallny/forensic-design-
documenta...](https://medium.com/chrismarshallny/forensic-design-
documentation-54541925d30e)

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+.

------
vatotemking
This may sound hurtful but hear me out - One thing worth mentioning why
someone would not want to use PHP in 2020 is that a PHP programmer is looked
down upon by other programmers.

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.

~~~
wolco
In fairness the wheel has turned and node developers are seen as not
respected. If you haven't moved to go/rust/serverless by 2018 the cool market
has moved.

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.

~~~
optymizer
As a fun, tongue-in-cheek project, someone should build a website with this
timeline of languages going from cool to uncool.

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.

~~~
vatotemking
You forgot the "X is considered harmful" article.

------
tommica
I've worked with PHP since 5.4, and to me the language has not been the
obstacle, it has been my own skill-level that has held me back, and still is -
I lack very much the core architectural skills in getting forward as a
developer, among many other things.

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.

~~~
jinzo
I got back into web development in the last year or so. Previously I did
mostly Python/Django and then 5 years of something unrelated to dev. Now I'm
working in a fairly typical PHP/Wordpress mixed joint, and now I understand
why PHP has the bad rep - because it allows/tolerates/even encourages bad
practices (and beyond the usual "shoot yourself in the leg" we can see in
other popular/common languages). And I guess that is one of the reasons why a
lot of libraries/plugins/php code out there is simply bad. For example: Seeing
heavy mixing of PHP code and HTML output in 2020 is a horrible sight for me
(and it's waaay to common in what I saw).

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).

~~~
fatboy
The thing I hate about php is the inconsistency and unpredictability for new-
to-php developers.

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?!

~~~
simion314
FYI when you start a PHP project you need to change your dev machine php.ini
to be super strict, so all warrnings should just error out.

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.

~~~
stonogo
It never made sense. The original hash bucketing mechanism for the function
lookup in PHP was the length of the name of the function, so each new function
was named a specific length to ensure the function list was evenly distributed
across the hash table.

~~~
simion314
Can you link or be more clear? I assumed you are talking about the array and
string related functions that are not consistent in argument order.

~~~
cesarb
The parent comment is referring to [https://news-
web.php.net/php.internals/70691](https://news-web.php.net/php.internals/70691)
(found via
[https://news.ycombinator.com/item?id=6919216](https://news.ycombinator.com/item?id=6919216)).
Quoting from that link:

    
    
      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.

~~~
simion314
Thanks, I did not know that bit of history.

------
hising
Why do these discussions always end up in some black/white dicotomy? Are there
situations where PHP is a valid part of a tech stack? Sure. Are there places
where, if you could choose, PHP is not a good choice in the stack, Yup.

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.

~~~
cesarb
> 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?

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.

~~~
hising
I guess the "poor" in "poor language" is in the eye of the beholder and I get
your point. Have you found yourself lucky in convincing the world in not using
any language yet?

------
thrownaway954
people make fun of php all the time... just see the comments in this thread.

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.

~~~
ainiriand
I am a PHP dev with 12 years of experience. I think I have been unemployed 1
week total.

~~~
thrownaway954
good to hear that. have an upvote :)

------
fergie
PHP -> much better that people often give it credit for

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.

------
AegirLeet
I'm a PHP dev and I'm pretty happy with the language, especially some of the
things introduced in recent versions. I think it's a fine choice for anything
that doesn't fall in the "low-level, high-performance" or "mobile/desktop app"
categories.

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.

------
gabordemooij
Funny, while I see that many people enjoy the features that come with this
maturity (and I am happy for those people of course), I long for the
simplicity of the classic style PHP.

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 ;-).

~~~
luckylion
I do like the enterprisey direction personally, mostly because it works so
well with a good IDE. I'm using PHPStorm and once you've got your project set
up, code completion/suggestion and inspections are something I love.

------
Narann
Depicts language feature, PHP ecosystem is dying. For me, an example is latest
MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated
anymore, to pygments (Python) using a sub process.

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.

~~~
dastx
This is a side effect of open source. GeSHi, and many others, suddenly stop
getting maintained, and more often than not, project ownership doesn't get
passed down.

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.

~~~
fnord123
That's not a side effect of open source: it's a side effect of any dependency.
If you were using foxpro, any google service, apis from companies bought by
Apple, etc then the dependencies stop being maintained or vanish altogether.

------
perttir
I use php daily. Mostly Symfony/Laravel stuff. There are still some stuff it
needs what other languages have. (Can't really right now remember all the
stuff i stumble upon sometimes which gives me the feeling "damn if i could do
this like i do it in rust/java/cpp/(w/e)")

Maybe the worst thing is the composer (it's slow.)

~~~
Eremotherium
Try Prestissimo, which enables composer to download packages in parallel

    
    
      composer global require hirak/prestissimo

~~~
Epskampie
The dependency solver is what is slow, not so much the downloading.

~~~
conradfr
Also doing a composer update in a container with not much ram is sometimes
properly impossible. Although that may have changed with the recent 2.0.

------
fimdomeio
It's sad that php as such a bad rep that I figured I should say "I code in Go.
Php? Yeah I can do that too" so I don't get some eye rolling and an instant
prejudice I'm a cheap coder. For it's age php is great and pretty easy to
setup (having to intall separate modules for imagemagick and cryptography is
just a tiny assle). Composer should really solve it's large memory usage
problems, but other than that it's pretty good.

It's really good for it's intended purposes and is getting a lot better in
latest versions.

------
jerng
Meanwhile JavaScript/ECMAScript's syntax creep is turning it into PHP.

~~~
riteshpatel
Noticed this recently when doing an ES6 course. So many additions look similar
to modern PHP!

~~~
Dylan16807
If it's modern PHP specifically, are you saying that both languages are adding
a bunch of the same things? That doesn't really sound like one language
turning into the other.

------
open-source-ux
Whether you like or hate PHP, it has achieved something that no other language
has done - made it easy to host a dynamic website or app on the server. Other
languages may claim to be 'web-friendly' (e.g. Python, Ruby) but when it comes
to ease of deployment, they are anything but 'web-friendly' or easy.

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?

~~~
realharo
_> 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.

~~~
barbegal
But in the overall scheme of things it's order of magnitudes more difficult to
deploy. PHP is upload a file whereas docker requires many more steps (for
example: [https://kb.sloppy.io/en/collections/156106-getting-
started](https://kb.sloppy.io/en/collections/156106-getting-started) )

~~~
realharo
The first section in that link literally says

 _> 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...](https://www.openshift.com/blog/deploying-applications-from-images-
in-openshift-part-one-web-console)

Or this [https://kb.sloppy.io/en/articles/1313693-setting-up-
mongodb-...](https://kb.sloppy.io/en/articles/1313693-setting-up-mongodb-and-
mongo-express-on-sloppy-io)

~~~
aetherspawn
They had to write an installer ecosystem around installing docker images,
whereas with PHP and most stock server configs you can SSH a file into a
server and you're pretty much done.

Still if I want to write a simple web app in < 1 day, I would definitely use
PHP.

~~~
realharo
In such a manual workflow ( _" you can SSH a file into a server"_), you still
have to setup at least URL rewriting in nginx for any PHP app using routing
(which is basically everything using any PHP framework or micro-framework).

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](https://hub.helm.sh/charts/bitnami/ghost)),
you can also manage them from a GUI dashboard
([https://kubeapps.com/](https://kubeapps.com/)) or even from a git repo
([https://argoproj.github.io/argo-cd/](https://argoproj.github.io/argo-cd/))
if you want to have a repeatable history of all changes to the environment,
updates, etc.

~~~
hu3
URL rewriting in nginx for PHP is about copying 5 lines from a google search.

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.

~~~
realharo
_> URL rewriting in nginx for PHP is about copying 5 lines from a google
search._

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...](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass)).

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.

------
alphadevx
Many of the features highlighted in that article as "new" are from PHP 5.x, so
it reads more like a list written by someone who has been out of touch with
PHP development for a number of years.

~~~
laumars
Did you actually read the article or just the headings? Any features that pre-
date 7.x are discussed as being 5.x features and, where applicable, the author
expands on how it's been further refined / improved upon in 7.x releases

~~~
alphadevx
Yes I read it, why accuse me of not doing so? The main block of sample code is
highlighting OOP features in PHP, but PHP has had most of those features since
5.3, e.g. namespaces, so my point still stands. Those features are not part of
"PHP showing its maturity in release 7.4", but have been around since at least
2009, so why lead with that example?

~~~
laumars
The article says those features are from PHP 5:

 _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._

~~~
alphadevx
I accept it mentions that in the content, I guess its the title I find
misleading. You can see on this very HN thread, lots of confused replies are
falsely equating those features as new developments.

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.

~~~
laumars
> _I guess its the title I find misleading._

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.

~~~
alphadevx
> 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.

------
anonyfox
Many emotional language bashing comments here, and everything between „php is
dead“ to „php is awesome now“.

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.

------
qu4ku
If you want to know why-the-hate watch this[1] talk — one of the best and eye-
opening talks I've ever heard.

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](https://www.youtube.com/watch?v=mZyvIHYn2zk)

------
dep_b
Tried PHP again (using it since the 3.x days off and on) a few years ago and
didn't dislike it. It would be great if types were even better enforced. But
then again I could have been working with Microsoft MVC instead and have an
even better experience, especially in terms of autocomplete in an IDE (because
C# has stronger types and they are more logical to find by trial and error,
like typing a . after a string value), something which I highly value.

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.

------
zabil
Never worked in PHP, but I watched this talk, "Let's program like it's 1999",
about PHP's influence on JSX and React. I quite enjoyed the talk.

------
p4bl0
I very rarely write PHP and will probably never have to use these features,
but I think that the combination of the FFI and preloading can be quite a
powerful thing.

------
leeshire
so is PHP worth learning right now? and what is the job prospect looking like?
if I study the language for the next few months what is the lickely scenario I
will find a career in it.. I actually enjoy and like PHP unlike other people
idk what it is about the languauge it looks fun and enjoyable to play with .
Plus it's simple and easy opens doors to more complex languages later on down
the road

~~~
creshal
> what is the job prospect looking like?

I hope you like working on legacy projects full of spaghetti code.

~~~
michelb
In that case it really doesn't matter where you work.

------
cageface
PHP, Python and Ruby all feel to me like last-generation languages. IMO we
should be building new frameworks on modern languages that support concurrency
& static typing. The most promising new stack I've seen is Kotlin's KTOR
framework. Thanks to the expressiveness of Kotlin it's not really any more
verbose than something like PHP or Ruby but it's far more powerful and robust.

~~~
solraph
Alas, I feel the same way. After much thought this weekend, I concluded that
it was time to move on from PHP. I decided against the any other scripted
language (Ruby, Python), as it felt like more of the same.

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.

~~~
72deluxe
Why not C++ in this area? The more I use PHP the more I appreciate C++'s type
system.

~~~
solraph
No garbage collection, doesn't compile to Javascript[0] and everything on
Android is moving to Kotlin anyway.

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.

[0] [https://kotlinlang.org/docs/reference/js-
overview.html](https://kotlinlang.org/docs/reference/js-overview.html)

------
ashtonkem
I ended up using PHP while I worked in a design shop, as it was extremely easy
to both implement designs in and easy for low-tech clients to run.

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.

------
2ion
Is it possible to write long-running processes well in PHP today? Is the
memory management of PHP up to the task? Or is it all a *cgi-based execution
model? This question still is what makes it hard to place PHP. Basically all
"high perf"/"high load" applications of it I know about run under PHP-FPM or
webserver modules or uwsgi.

~~~
AegirLeet
Long-running processes are definitely possible. You obviously have to be a bit
more careful not to leak memory.

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.

------
enesunal
"PHP is losing because of its maturity"

------
root_axis
Ah, it's like old times again. Nowadays all the language-snob threads are
directed towards JavaScript, but I remember the days when PHP was the language
of choice for what HN considers the inferior programmer. Fun memories, all
this thread is missing is a link to the fractal of bad design rant.

~~~
localareaman
It's not language quality and merits per se that are important. It's much
about establishing status within a tribe that counts. PHP is seen as a low
status language because many junior or moderately skilled programmers use it.
Rust is a popular language among up and coming young programmers because they
expect to over throw the dominance of older C++ programmers. Haskell is for
the high priests if that is your path to power and status.

~~~
root_axis
I agree with your analysis.

------
block_dagger
As someone who started my career in PHP in 2002 and switched to Rails in 2008,
I can say I do not miss PHP. I still maintain my old apps only because of the
high pay associated, not because it is joyful. PHP's version of "mature" does
not match other modern langs, not even close imho.

------
dilandau
PHP is great. Nothing comes near as close when you just want to shit some SQL-
queries onto a page, or add some basic interactivity. Just drop your scripts
in /var/www and let apache do the rest. It's like magic.

------
cutler
What put me off PHP for life was the assumption by employers and recruiters
that PHP rates are at least 20% lower than for JS, Rails or Django. PHP just
isn't respected professionally.

------
perlgeek
Can anybody comment on the state of Unicode in PHP?

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.

------
ctas
My startups running on PHP and I definitely don't regret it. The language is
simple, you have easy access to talent, knowledge, and thousands of mature
libraries. Most of the times boring is better.

------
no_gravity
PHP has a lot going for it. It is popular, fast, has a nice syntax and a ton
of useful functionality baked right into the language.

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.

------
echelon
For web backend, being able to ship a single binary, such as what Rust and Go
can provide, is really nice. I don't see PHP as a more compelling solution
than either of those languages.

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.

~~~
piokoch
Think of a simple landing page with a form to save data from a form and send
out an email with confirmation.

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.

~~~
psychoslave
Aren't there a zillion online services that provides that product out of the
box, most likely for free, only requiring a browser and some monkey clicks
around? -> No PHP, HTML or web server.

~~~
stephenr
By that logic, nobody needs to write any thing because there's always some
"online service" to "do stuff".

~~~
echelon
I think the logic is that those served by PHP are better served by platforms.
Those with advanced needs are going to use a different language.

PHP isn't being replaced so much by Python, Go, and Rust as it is being
replaced by Medium, Wix, and Squarespace.

~~~
stephenr
As someone who works with PHP reasonably often, I'd say you have a very
limited view of what PHP is actually used for in 2020, if you think 3 hosted
blog services will replace it.

~~~
echelon
The majority of PHP usages tend to be, frankly, unsophisticated Wordpress,
WooCommerce, Magento, and Drupal sites that are hacked up to support
e-commerce. These needs can now be met by a vast array of ecom and omnichannel
platforms.

This is the direction things are trending.

------
JadeNB
Why was the title changed from "PHP showing its maturity in release 7.4",
which doesn't seem clickbait-y or anything?

------
DonHopkins
Now the trash dumpster is no longer actually on fire, and it has nice bright
orange flames painted on it, like a racing car!

------
aceman22
Laravel is the best REST api framework in existence for any language. Change
my mind.

~~~
tzs
How well are older releases of Laravel supported?

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).

~~~
mtnGoat
i would probably look at updating and keeping a more secure OS that can run
modern software. Asking a framework to maintain a version of their framework
for a version of PHP that is no longer supported, is not realistic.

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.

------
jeisc
please check out these fast php products swoole, amp, workerman n peachpie at
[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

------
tabtab
I really miss optional named parameters. I hope PHP adds that feature.

------
somurzakov
can anybody explain what is the purpose of static typing in a dynamic language
? It's not like you get benefit of compilation like java/C#.

Why is PHP trying to become java so hard, if there is already java and .NET ?

~~~
proto-n
You can compare static typing in php to typescript or static typing in python.
It's for correctness, not performance.

------
chipotle_coyote
I'm starting a new project in PHP now. I've used the language for a _long_
time, I think starting with the 3.x days, and it's come a long way. There's a
lot of good things about it.

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']);
    

But that's not The Right Way anymore, is it? Instead, I should use a PSR-7
compliant request object, and do this:

    
    
        $request = Laminas\Diactoros\ServerRequestFactory::fromGlobals();
        $uri = $request->getUri();
        $path = $uri->getPath();
    

"Okay, Chipotle, but that's just one more line, stop whining." Sure, but it's
three lines that instantiates a Request object that in turn instantiates
Stream and Uri objects and importa two Traits and implements, I don't know,
let's say four? four Interfaces, and--

"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.

------
pojntfx
If you're starting with WebDev in 2020, choose Go or Rust. Concurrency &
safety + simple deployable static ELF binaries > weak typing and legacy bloat.

~~~
simion314
Why would I use Rust for Web dev or anything else that is not some low level
system programming? I mean if you want to write some toy project and want to
learn sure, but for a serious project I would chose something that uses a
higher level programming language, that has a big and stable standard library
and that also has a big community made , well tested libraries to work with.

------
ur-whale
Does php still use $ for variable names in 2020?

~~~
fetbaffe
Of course. Why change that for zero gain? Powershell does too.

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?

~~~
ur-whale
1\. Waste of time and mental cycles: forces the programmer to do the parser's
job because the language designer was too lazy to build in the logic to
recognize variables.

2\. Carpal tunnel syndrome, _especially_ on keyboards where "$" can only be
reached via shift.

~~~
fetbaffe
1\. Personally I find it easier to read variable names prefixed with dollar
signs, it differentiates variables from other symbols, which makes them very
easy to find, especially now when many languages gives information overload by
lots of type information etc. My eyes can scan code faster.

2\. rebind your keyboard.

------
sneak
I wrote my very first webapp in PHP when I was a teenager, and my first dozen
paid apps shortly thereafter as a consultant. PHP was a lot worse then, but
still has a lot of the same fundamental issues that it won’t ever be able to
escape without becoming a different language.

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.

------
72deluxe
I still can't see how it can be "mature" if it offers an iterable returnable
type like in the article example yet doesn't indicate the type of the object
it is returning!

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.

~~~
mrkeen
I still can't see how C++ can be "mature" if you have to indicate the type of
object it is returning!

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.

~~~
72deluxe
But it's not a hint to the compiler. It's stating a fact to the compiler.
It'll stop compilation.

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...](https://github.com/magento/magento2/blob/420a8b6209a4e62ede97bb66768cc904c936c941/app/code/Magento/AsynchronousOperations/Model/BulkManagement.php#L100)

~~~
mrkeen
> But it's not a hint to the compiler. It's stating a fact to the compiler.
> It'll stop compilation.

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
    

You and I know Dung doesn't belong in a basket, but Java sure doesn't. It will
not warn about me comparing Fruit to Dung, nor is there a way to ask the
compiler to warn me that I forgot to handle Banana:

    
    
      void handleFruit(Fruit fruit) {
        if (fruit instanceof Apple) {
            System.out.println("Apple");
        } else if (fruit instanceof Dung) {
            System.out.println("Dung");
        }
      }
    

Here's another one:

    
    
      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?";
      }
    

In the first code sample we established that the basket could only contain
Apples, but now when you handle something from the basket, it's apparently any
Fruit. And when you handleFruit an Apple, there's no warning that the compiler
is making a choice between the two acceptable handleFruit functions.

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) {
        }
      }
    

It compiles, but it's missing the only safety check I really cared about - the
contents must match (even if the containers vary!) Let's introduce another
type variable X to assert this:

    
    
      interface Transfer<F, T, X> {
        void dump(F<X> from, T<X> to);
      }
    

Now it asserts what I want it to assert, but it doesn't compile.

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).

~~~
72deluxe
Yes that Java example is bad and terrible. I'm honestly amazed you can do
Fruit[] basket = new Apple[]. That's terrible.

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.

