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.

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.

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.

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.

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.

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.

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.

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

Not sure if you even understand what you're talking about.

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.

That's not hot reload, and pretty much every language has frameworks that are capable of that.

Hot reload is trivial in Common Lisp, and only marginally less so in Elixir. Turns out it's just not enough of a differentiator to actually tip the scales.

Go itself is also not a revolutionary language, actually the fact that it isn't revolutionary is one of it's "raisons d'etre". Go is mixing up various popular concepts into a reasonably compact package.

> why does a language need to be constantly revolutionary if it solves what it sets out to solve well?

That's a very big If in PHP's case.

If anything PHP is THE language that solves what it sets out to solve.

It does a few things and does them well.

What is the problem of admitting PHP solves the problem of quickly deploying web sites?

Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.

Am I the only one scratching their head at this argument in 2020? 15 years ago when shared hosting was more common I would buy it, but I just don't find myself wasting time on figuring deployments out in other languages/frameworks. By far the biggest time sink in that area is setting up continuous integration and monitoring/alerting systems, and those problems are exactly the same regardless of language.

I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0].

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

[1] https://symfony.com/

Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things done, and using a very common tool helps with having a large pool of people you can call upon.

From a business perspective this might also translate into lower development costs and easier access to talent.

Generally lower quality talent. That's half the reason PHP got its abysmal reputation. Brilliant programmers using PHP must be annoyed that they're thusly tarnished. I suppose that's not so different from JS. To the flames with both of them, though, I find them genuinely depressing languages to work with.

> Generally lower quality talent.

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.

Our abstractions become the basis of our imagination - do we want developers to think and experience joy? Do we want their minds to spark and innovate and solve and embrace the full power of computing? Can anything compare with the illuminating glow of a powerful abstraction that reveals a new technique - perhaps not 'world changing' - that improves our software and our programmatic structures?

I guess we don't, actually. Oh well. :'). You make a perfectly reasonable business point.

And business is, imho, not just "for profit", but society in general. I feel about it similar as I feel about wood working mastery. Creating incredible joints with extreme attention to detail and a lot of experience fascinates me. But to build furniture for more than one person a year, I'd prefer nails, power tools and a bunch of people that are experienced enough not to nail parts of their body to the wood.

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.

I think that that's also a good point. It makes me wonder about the useful limits of abstraction if accessibility (broadly defined) is the goal.

>> You don't need a CS degree and brilliance

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.

Some (perhaps even most) problems don't need top tier coders, so hiring them for such problems is a waste of resources.

This. I was using TypeScript for anything that looked like I'll be the sole maintainer but for something that could last for 10+ years, I started it out as PHP as I may not be the only maintainer one day and can't ask the client to look for more specialized talents for no good reason.

I'd say typescript is easily far enough into mainstream adoption that you can safely use it knowing others will be able to maintain it in the future.

Well yeah, if you would pick one technology that even PHP would compare favourably too, it would be Node... my thoughts on Node were always: just because Google built V8, which makes it possible to run JS fast enough to use it in the backend, doesn't mean that you have to do it.

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

PHP still remains incredibly accessible, the documentation and legacy of problem solving means you can find help for any problem you'll encounter and the lack of complicated tooling makes it easy to focus on the problems that matter.

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.

Most of the time you do not chose a language or ecosystem because it has some cool syntax or some new feature. As an example if you need to do X you look at what solves X the best, if I can do X by installing say ffmpeg and write a bash script I will do that and not cry that bash does not have some cool feature.

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.

X sometimes stands for problems above technical problem, such as:

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

Sure, but sometimes X is something like you have a video and you want to use the GPU to analyze it and the best library for that is in C and there are great python bindings. So a professional developer would use C or Python and not waste his client time by trying to create it's own unmaintainable CoolLang bindings (where this dev is just now learning CoolLang and there are not that many people that know CoolLang).

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.

You can do this in Spring Boot/ Java, with one Java class and one config file.

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.

You installed a framework Spring for a simple feature to grab some text from a POST request and dump it into a database. Since in general you don't have thousands of users sending feedback at the same time I don't need a framework and if you know how to correctly create SQL statements you don't need a framework for SQL. There is nothing to log, if the db call fails you can put some text in a log file or do a curl to a different url to notify you.

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)

I'd use whatever lightweight and secure I can find at a moment.

Simple file upload without any future expansion plan doesn't need hours of discussion.

It depends on the customer, will they give you a server dedicated for your Java framework so you can handle at maximum 5 POST request per day or will day give you access to the existing website they have for the company, that already has PHP,mysql installed. Honestly you are not doing the fair thing for the customer if you ask for a new server because you want to use your prefered tool and not the best thing for this job.

Btw my scenario was about sending feedback ro stack traces, this are just text, no giant file uploads and nothing insecure about it.

Yes, and all three of them has very good backwards combability, one of the most underestimated features in a language for developers but one of the most important ones for building a stable business.

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.

> But with fewer people self-hosting these days, that has become less an advantage.

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.

> 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

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

The only issue of that I still encounter is hosters misconfiguring the php.ini, rarely.

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.

Oh how I hated the fact that php.ini could change so much of the PHP behaviour... can't say I miss those days.

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.

This is changing now. There are no new php.ini changes that would affect how the parser or VM works. The lessons from things like safe_mode and register_globals are learned so well.

and magic_quotes...

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

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.

I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP".

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.

It's not really a question of money, the VPS where you can do what you want can even be cheaper.

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

Unless you are running continuous load, the $4 PHP shared hoster is probably more powerful than $5 VPS.

I know some shared PHP host that cost $8/year and have larger memory_limit than the available RAM in $5 VPS.

memory_limit is the upper bound you "allow" PHP to allocate. You can allocate more than the available RAM, and have your OS swap or PHP crash.

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.

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

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.

I think that's kind of part of the point though -- PHP provides a gentle slope from "single HTML file" to "big project".

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.

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

Kubernetes and go for example.

A question I ask myself often is what niche does a language fill, and it seems a little like the traditional niche of PHP has been eroded away in the last decade. Many of the things that gave PHP an edge (ease of deployment, templating within your HTML files, direct SQL queries) are no longer considered the correct approach.

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.

> There is nothing new or revolutionary in PHP7, just adopting features present in other major languages.

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.

> only stick around

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.

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

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

Rust and Go for writing a cusomizable CMS like Wordpress, really? Also PHP playing catch up and not breaking up my stuff with every point release is just fine. It means stability, maturity. Even Node.js has LTS releases.

Dart is more suited for this type of thing if one wants a new and shiny statically typed language with great performance.

Not only is PHP playing catch-up. It's only playing catch-up to Java. That's... not the highest bar, IMO.

Well, Rust is playing catch up with the "change code and run" speed of PHP.

Do the two overalp in their niches at all? You'd write a web server in Rust. But is there much effort put into Rust web frameworks?

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.

There is lots of effort by Rust devs, even if the libraries are not as mature or easy. I don't believe you meant to be disrespectful here. I think better a better words could be any of manpower, maturity, or time.

Same as Java, ~adding~ backporting boilerplate from other JVM stuff.