Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A look at modern PHP

lwn.net

Post reply on HN
Print view View original

211–220 of 610 posts

Re: A look at modern PHP

#211

Post by ainiriand »

echelon wrote: post #198
tcd wrote: post #195

Earlier quoted context omitted.

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

> 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

Re: A look at modern PHP

#212

Post by alphadevx »

laumars wrote: post #192
alphadevx wrote: post #71

Earlier quoted context omitted.

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?

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…

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.

Re: A look at modern PHP

#213

Post by ainiriand »

kangoo1707 wrote: post #210
ainiriand wrote: post #205

Earlier quoted context omitted.

- No proper multithreading Maybe you are not familiar with PHP multithreading in recent times but I have been using https://github.com/krakjoe/pthreads and works perfectly. No process forking.

still, no proper multithreading, in comparison with Java, C#, Elixir...

Define proper please.

Re: A look at modern PHP

#214

Post by echelon »

AegirLeet wrote: post #203
echelon wrote: post #180

Earlier quoted context omitted.

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 i…

> 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 *…

Ruby on Rails.

Django.

Revel.

Actix.

Re: A look at modern PHP

#215

Post by akie »

AegirLeet wrote: post #203
echelon wrote: post #180

Earlier quoted context omitted.

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 i…

> 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 *…

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.

Re: A look at modern PHP

#216

Post by alphadevx »

echelon wrote: post #207
alphadevx wrote: post #201

Earlier quoted context omitted.

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 gener…

> but pretty hard to proceed with some code that works with a DB when the connection can't be established When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc. You probably have background threads that do cache invalidation, queue management, etc. You frequently have to be more reliable than your database. > he responded that it was not required in a web context, as web servers alre…

> When you can't query your DB, you hit your resident memory cache. Redis, Memcached, etc.

You would query those first surely, before loading the DB? Regardless, I've been using Redis and Memcache for years from PHP, so mute point.

> I use multiple threads in a single request flow frequently.

So how do you track those? And for how long do they live after the parent request has been processed, or do they block the parent? Gets complicated quickly.

> It's ugly and inconsistent, takes time to memorize, and leads to errors.

Rasmus will admit the same, but he will also admit he does not care (I've seen him say this during a talk). Nobody bought your product because it had beautiful, consistent code.

> This limits you to writing basic CRUD. And so many other languages offer this.

99.9% of web apps are CRUD.

Re: A look at modern PHP

#217

Post by solraph »

perttir wrote: post #67
cageface wrote: post #40

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.

Php supports (somewhat) strictly defined types. You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have. It also supports class inheritance, abstract classes, interface classes, class traits, etc.

It does, and using PHP in strict mode, in combination with tools like phpstan is what led me to looking for a language that is even better in that regard.

If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.

However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.

Re: A look at modern PHP

#218

Post by echelon »

fetbaffe wrote: post #124
pm90 wrote: post #36

Earlier quoted context omitted.

Most webhosts provide some kind of support for containers don’t they? Perhaps I’m completely missing the point here? I’ll readily admit that Im young enough to have used docker to deploy apps nearly everywhere I worked. Is php useful for ultra low cost websites? Is it low maintenance? Is that the appeal? Genuine question.

Many small businesses just want to get online, how does a container help them? Actually it doesn't. Containers definitely has its place, but there hundred of thousands problems out there that needs to be solved for a low cost, otherwise it will never be solved, and a container will just increase that cost with little or no gain for the customer.

> Many small businesses just want to get online, how does a container help them? Actually it doesn't.

Many small businesses just want to get online, how does PHP help them? Actually it doesn't.

Small businesses use Wix, Shopify, Medium. Anything that prevents them from having to worry about code.

Re: A look at modern PHP

#219

Post by vertex-four »

411111111111111 wrote: post #146
mekster wrote: post #121

Earlier quoted context omitted.

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 ar…

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 ar…

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.

Re: A look at modern PHP

#220

Post by onli »

AegirLeet wrote: post #203
echelon wrote: post #180

Earlier quoted context omitted.

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 i…

> 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 *…

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