Hacker News Reader

Comment by echelon | Hacker News Reader

PHP isn't being replaced by Rust or Go. It's being replaced by Medium, Wix, and Squarespace.

At this point, the predominant reason it's still undergoing active development is that there is a metric ton of legacy PHP code. As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.

You're defending the language from an emotional standpoint.

> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core

This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.

Choosing PHP will be like choosing Python 2. In fact, that's my 2030 prediction.

View on HN

> As the businesses still using it either mature, evolve, or fail, the need for PHP will begin to dry up.

People have been calling for PHP's death, or saying PHP is a dying language, for as long as the internet has been around.

It's always the same arguments, that $newHipLanguage will replace it.

Then you actually do some research and understand just how much of the internet is still powered by PHP and will continue to do so for the forseeable future.

So, I'm still waiting for PHP's death. Or for this same predictable comment in 2030.

> It's always the same arguments, that $newHipLanguage will replace it.

It's not that a new language will replace it. It's that the people that hire PHP to solve their problem will now use a platform with no code to manage.

Engineers writing platforms will choose languages other than PHP to write them. You can't spin up multiple request threads to make concurrent non-blocking queries in PHP.

- You can't spin up multiple request threads to make concurrent non-blocking queries in PHP

You mean that you don't know how to: https://github.com/amphp/amp

It's not built into the language? How can we be sure this project with 2k Github stars won't segfault, memleak, deadlock, or have some other horrible bug [1]? I haven't done full due diligence, but I'm already suspicious. The open tickets don't look good [2].

> You mean that you don't know how to

I'm not convinced you found an appropriate answer either.

In any case, this should be a language feature.

[1] It looks like it relies on bindings to an unofficial native code extension.

[2] https://github.com/amphp/amp/issues/300

Don't look at js then.

> You can't spin up multiple request threads to make concurrent non-blocking queries in PHP.

I think you can.

https://dev.to/webong/using-asynchronous-processes-in-php-7i...

> PHP isn't being replaced by Rust or Go. It's being replaced by Medium, Wix, and Squarespace.

Funny that you mention Squarespace as replacing PHP when they themselves are a big PHP shop.

The definitely are not a big PHP shop - they're a big Java shop, with maybe one small PHP acquisition.

This is evidenced in their open-source GitHub projects: https://github.com/squarespace

> This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.

Lots of languages have HTTP tools and frameworks, but not many of them are even comparable in scope to Symfony or Laravel. Out of curiosity, can anyone point me at some frameworks in other languages that have the following things built-in?

* Route matching and dispatch

* URL generation (generate a URL for some route) including signed and temporary URLs

* Middlewares

* Abstractions for dealing with incoming HTTP requests (getting headers, body, uploaded files etc.)

* Abstractions for creating and sending HTTP responses (headers, body etc.)

* CSRF protection

* Database drivers for a couple of backends (MySQL, PostgreSQL, SQLite etc.)

* Database migrations

* Database seeding

* Views/HTML rendering

* Logging capabilities (configurable backends like rotating log files, syslog, Slack etc.)

* Sessions with different storage backends (filesystem, Redis etc.)

* Request validation ("this field is required, has to be a string, between x and y characters long" etc.)

* Translation and localization

* Broadcasting through WebSockets

* Caching with a couple of backends (filesystem, database, Redis etc.)

* Email sending with a couple of backends (SMTP, Mailgun, SES etc.)

* Notifications with different channels (Email, SMS etc.) and backends (SMTP, Mailgun, Twilio etc.)

* Job queues with different backends (database, Redis, SQS etc.)

* Scheduled jobs

* Authentication (different flavors like regular sessions, API tokens etc.)

* Authorization

* Hashing

* Encryption

* Query builder

* ORM with relations between objects, JSON serialization etc.

* CLI commands with option/argument parsing, colored output, progress bars etc.

* Events, including async handling of events

* File storage with a couple of backends (local filesystem, S3 etc.)

* Pagination

* Payment integration

* Full text search with different backends (database, Algolia etc.)

This is basically the feature set of Laravel, I probably missed some things too.

And I don't mean "oh yeah I'm sure there's a library for that" - I mean fully integrated, first-party, tested, dead simple to use and available by default.

Maybe I'm wrong, but I seriously doubt this just exists in any language.

Ruby on Rails.

Django.

Revel.

Actix.

Does Actix really have all this stuff? Signed/temporary URLs for instance? Never used it so just interested.

RoR and Django are probably the closest (Laravel was inspired by RoR). Still, I don't think they support all those features.

Like I can't find any official RoR support for payments, full text search, encryption, pagination, scheduled tasks or building CLI commands.

With Django, full text search seems limited. It supports PostgreSQL, but I couldn't find first-party integration for Algolia, Solr, Elasticsearch etc. or a generic way to add backends (pluggable drivers) for them. There's support for WebSockets through Django Channels, but it seems a lot more basic than Laravel's broadcasting system. No official support for queued jobs or schedules?

Revel doesn't seem to have support for building CLI commands, encryption, emails, pagination etc. Apparently, any kind of database access or ORM isn't even first-party?

The inclusion of Actix in this list confuses me. From what I understand, Actix isn't a web framework at all, it's more like a foundation for using the actor model.

(I didn't exhaustively analyze everything, there's certainly more things missing from some of those frameworks)

Python has an Elasticsearch API available as a package, which is probably why it's not packaged in with Django.

also, wtf payment integration? if i need payment integration, there are myriad of libraries to chose. i don't need my web framework to decide that for me.

Why would RoR bake payments support into the framework? RoR is there to tackle common web application tasks, payments is there for maybe 30% of web apps / services. There's an active debate on what popular libraries should be included in Rails, and all the features you listed can be found in libraries if they aren't in Rails already.

> Why would RoR bake payments support into the framework?

I'm not saying they should, just comparing features for the sake of demonstrating that the functionality that's present in modern PHP frameworks isn't readily available in just any random framework in any random language.

This is the same kind of argument used to prove that Macs are actually cheaper than PCs. Start from the hardware specs of a particular Mac model and configure a PC to match those exactly. It will probably be more expensive than the Mac.

The thing is that nobody would choose that configuration for the PC under normal circumstances. Normally you would spec it based on your actual use case and the PC would end up both cheaper than the Mac and better suited to the use case.

I'm not sure that example is entirely true. A PC would probably still be cheaper, assuming you don't insist on getting exactly the same components and are OK with, say, substituting the Mac's RAM supplied by vendor X with an equivalent product from vendor Y (same specs).

Sorry, the point I was originally trying to make might have gotten lost in all the discussion about specific features.

It was in response to this:

>> choosing php for a new project is a no-brianer. The only other 2 stacks to which I can compare it are the Spring stack of Java or .NET core

> This is absolutely not the case, and you know it. Almost every language has a wealth of HTTP tools and frameworks, and many of them come built-in.

The way I read it, this comment claims that everything that can be done in PHP using PHP frameworks could also be done in almost any other language using one or several frameworks written in that language. In my experience, this simply isn't true. There are other frameworks in other languages that have a feature set similar/equal/maybe superior to what Symfony or Laravel offer in PHP, but those are very rare. Like "there's maybe 2 or 3 of them in existence" kind of rare. Rails, Django, maybe one or two more? It's a short list. Again, not exactly "almost every language" and all that.

Of course, any language could have frameworks offering those kinds of features, but in reality, most simply don't. For a new web project, PHP, Ruby or Python are still fine choices if you're comfortable using those languages. There's nothing wrong with using, say, Go instead. But to claim that Go (just using it as an example here, not trying to criticize Go in particular) just has one or several web frameworks lying around that can do what Laravel, Rails or Django can is simply dishonest.

Actix-web is a web framework, but a rather lightweight one. It doesn't really compare to django/rails/laravel.

Phoenix too

You have to understand, all of that is irrelevant! Because PHP is old and shitty, it mixes camel_case and SnakeCase and the order of arguments in the standard library is inconsistent! Bah.

camelCase and snake_case

... Just to avoid confusion

It made me giggle, which I assume was the point.

Rails should match that, if you accept that a small part of the feature list is provided by (popular and commonly used) plugins.

Yes, as mentioned in my other reply, I think Rails is probably the closest competitor and can do most (although not everything) of what Laravel can. Django is the third option I think comes very close.

Admittedly, limiting the selection to first-party code might be a bit unfair to frameworks that maybe simply rely more on community-built extensions, but I have to draw the line somewhere, otherwise I guess every framework theoretically "supports" everything through some third-party module that may or may not work ;)

Spring Boot has most of the important parts of this. And super easy to call a library for anything else, or write 10-20 lines of code yourself.

This is all in a performant, reliable and secure compiled language (Java). Language improvements and modern frameworks have also addressed the long-winded code which used to be an issue.

> Language improvements

A.k.a., Kotlin. :p

In all seriousness, though. The only thing PHP still has over Java is that when I say my function takes Foo type, you can't give it null instead.

Mojolicious (Perl) has just about all those things. It's been a while since I've looked at it.

What do those mean?

> Hashing

> Encryption

> CLI commands with option/argument parsing, colored output, progress bars etc. (Do you mean a management console? All of them have it.)

Except for those, Django has every single one.

Hashing: Support for securely creating and verifying cryptographic hashes, like you'd need for password hashing.

Encryption: Support for securely encrypting, signing, decrypting and verifying arbitrary payloads. In Laravel, you can do:

  $plaintext = 'foobar';
  $encrypted = $encrypter->encrypt($plaintext); // this will  encrypt the plain text, generate a MAC and combine everything into a base64 encoded payload
  $decrypted = $encrypter->decrypt($encrypted); // this will decode the payload, verify its MAC and decrypt it, giving you back the original plain text
  $decrypted === $plaintext; // true

As for CLI commands, I meant the ability to easily create your own commands. Here's [1] the relevant Laravel docs, for example. You can create commands and they will have access to all the things you can use in a HTTP context too, other than the actual HTTP stuff like the current HTTP request, because there obviously isn't one. So, for example, you could write a command that would use the ORM to perform some maintenance tasks on your database.

[1]: https://laravel.com/docs/7.x/artisan

You mean, an crypto library exported by the framework instead of you specifically importing it? I don't see the gain (as a consequence, I have no idea if other frameworks do that).

RoR and Django both have extensible management commands, and all frameworks that I have ever seen allow you to create independent CLI commands (it's on PHP that the CLI is a second class citizen).

I think having good, secure, easy to use and hard to misuse crypto makes a ton of sense for any framework. The framework needs these internally anyway (to offer encrypted sessions for example), so you might as well expose them to the developer too.

I might have missed it, but I couldn't find any documentation on how to create custom commands in RoR. For Django I found [1] (through "python manage.py" from what I understand) and that does look like it's more or less the same as Laravel's "php artisan", with commands provided by the framework as well as the ability to add your own.

Anyway, I wasn't trying to attack RoR or Django, as those are actually the best alternatives to Laravel I know of. I worked on an existing Django project for a bit and while I don't like Python, Django seemed just fine to me for the most part. I did want to express my disagreement when it comes to the original claim of "any framework in any language can do what PHP frameworks can do" though.

[1]: https://docs.djangoproject.com/en/3.0/howto/custom-managemen...

> I did want to express my disagreement when it comes to the original claim of "any framework in any language can do what PHP frameworks can do" though.

Oh, a complete agreement on that.

This conversation sidelined from some people talking about Java, .Net, Go and Rust. None have anything similar to the big web frameworks. And while I'm not completely sure about Rust, I do believe that none even can have it.

Reply on news.ycombinator.com