Live data from Hacker News

A look at modern PHP

lwn.net

601–610 of 610 posts

Re: A look at modern PHP

#601

Earlier quoted context omitted.

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

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

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.

Re: A look at modern PHP

#602
post #293

Earlier quoted context omitted.

I doubt that Facebook tries to hire Hack devs off the street. No one uses Hack except FB. They hire PHP developers and teach them Hack in boot camps. The point being, you can hire good php devs.

Facebook probably just hires super bright developers, not PHP developers per se. Those developers can pick up Hack in a couple of months.

Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months.

Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my career.

* as language we define the language, its syntax and semantics, not any other library or the ecosystem. And yes, the standard library is still just a library. Knowing a list of functions and parameters does not mean knowing a language.

Re: A look at modern PHP

#603
post #593

Earlier quoted context omitted.

Ah, that's new! had no idea PHP copied this concept from java. Rails completely avoids dependency injection. You know what, if the php community starts to heavily type annotate and use a framework like Symfony, I start to fail to see the point of using that and not java.

Indeed. PHP has been trying so hard for so long to be a dynamically-typed Java I don't know why they don't just rebrand as DJava or something like that. I've never known any commonly-used language relinquish its own identity the way PHP has.

>I've never known any commonly-used language relinquish its own identity the way PHP has.

What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can't find an answer that doesn't point to poor design as to why in Java a Stack is a class but Queue is an interface. Java also didn't get generics until v5, which is now probably one of the most definitive features of the language. Java has changed a lot since its inception. If it weren't for modules and (especially jlink) being introduced in java 9 we'd still be dealing with massive production jars. Java has changed a ton and so has PHP, both for the better.

Re: A look at modern PHP

#604
post #603
post #593

Earlier quoted context omitted.

Indeed. PHP has been trying so hard for so long to be a dynamically-typed Java I don't know why they don't just rebrand as DJava or something like that. I've never known any commonly-used language relinquish its own identity the way PHP has.

>I've never known any commonly-used language relinquish its own identity the way PHP has. What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can…

I'm referring mainly to the idiomatic fanfold PSR doc comments which litter PHP codebases along with the head-scratching practice of inserting a blank line between each line of code, the upshot of which is that you're lucky to be able to read 10 lines of code on a screen without scrolling.

Re: A look at modern PHP

#605
post #604
post #603

Earlier quoted context omitted.

>I've never known any commonly-used language relinquish its own identity the way PHP has. What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can…

I'm referring mainly to the idiomatic fanfold PSR doc comments which litter PHP codebases along with the head-scratching practice of inserting a blank line between each line of code, the upshot of which is that you're lucky to be able to read 10 lines of code on a screen without scrolling.

Those "complaints" aren't even focused on the language but instead the developer. I still don't know what your original comment was about other than seemingly being irritated PHP isn't still in the same state it was 15 years ago.

Re: A look at modern PHP

#606

Earlier quoted context omitted.

For us techies, no, it doesn't really matter. For average business owners who buy a WordPress template and some 5€ hosting in order to set up a business card web site on their own, on the other hand, it matters a lot. So if your project targets that group of people then PHP is pretty much the only option; anything more complicated than an FTP upload/MySQL import is pretty much to advanced for them and they generally…

Who's doing that anymore? Either you (or your staff) are technical enough to manage installing a web framework on a server, or you use any of the numerous managed sites instead. (Squarespace, Wix, Webflow, Wordpress.com, Shopify, Facebook, etc) The last thing a non-techie business owner needs is to worry about setting up a random server with bad PHP code.

There's plenty of businesses selling business card web sites built on WordPress. They usually install it on whatever hosting the customer orders and then leaves the rest up to the customer.

Re: A look at modern PHP

#607

Earlier quoted context omitted.

Facebook probably just hires super bright developers, not PHP developers per se. Those developers can pick up Hack in a couple of months.

Normally, bright developers acquire a new language* within a few weeks, if they already know the paradigm from another language. Hack is OOP, and so are many others, so I would expect a bright developer to learn hack in 2-3 weeks, not months. Heck, I just read the docs of hack for 2 hours, and I already got a good sense of what the language can do. I worked with PHP internals, and a bunch of other languages in my car…

Well Ruby is OOP, is it gonna be super easy for me to get a java web development job? All things being equal a hiring company will go for someone with 3 years java experience over my 8 years Ruby experience. Facebook has no choice since no one knows their language, but most other companies will hire someone with the particular experience of their stack if possible.

Re: A look at modern PHP

#608
post #603
post #593

Earlier quoted context omitted.

Indeed. PHP has been trying so hard for so long to be a dynamically-typed Java I don't know why they don't just rebrand as DJava or something like that. I've never known any commonly-used language relinquish its own identity the way PHP has.

>I've never known any commonly-used language relinquish its own identity the way PHP has. What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can…

I disagree. PHP was always supposed to be beginner friendly, fast to prototype, dynamic etc. Java was never any of these things. Having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be. And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?

Re: A look at modern PHP

#609
post #603

Earlier quoted context omitted.

>I've never known any commonly-used language relinquish its own identity the way PHP has. What do you mean by this? I can take a guess, and it seems like you're upset PHP has progressed beyond its humble beginnings as a templating language into a fully fledged OOP language with frameworks rivaling Spring, such as Symfony and Laravel. Sure, PHP has its issues, but so does Java if you want to go that route. I still can…

I disagree. PHP was always supposed to be beginner friendly, fast to prototype, dynamic etc. Java was never any of these things. Having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be. And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?

>I disagree. PHP was always supposed to be beginner friendly, fast to prototype, dynamic etc.

>having it's major frameworks become so heavily inspired by Spring isn't what PHP used to be.

Inspired by doesn't mean the same as. It's no different than any other non-DI frameworks unless you want to write framework-specific packages. Laravel has DI under the hood but you don't have to write annotations nor structure your code in a certain way to be able to use it. It does all of that for you.

>And again, if I have a type annotated codebase which is more and more a Spring clone, why wouldn't I just use Spring? What's the upshot to go with PHP + Symfony then?

They're far easier to use with less overhead. You don't need to know tons of annotations and configurations to get requests to behave a certain way. You've already admitted earlier that you've never used Laravel nor Symfony, so I'm not sure why you're arguing about their ease of use when you don't have experience with either. They're significantly easier to use than Spring.

Re: A look at modern PHP

#610

Earlier quoted context omitted.

> 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. A bit ironic that you compare it to microservices, because that exact property of PHP makes it massively unsuitable for microservices and scaling, because it req…

I've been hearing that "PHP does not scale" arguement for many, many, years, in many, many, variations. When you really have to scale, infrastructure, resources, and networks will rapidly overtake any concerns around your choice of language. You can develop crappy architectures in any language, and the inverse is true.

Not my experience. At scale, once you go down the 'cloud native' (kubernetes) path, the infrastructure part becomes relatively straight-forward, but PHP's weaknesses become very apparent.

Doesn't work very well with message queues. Sure, pushing messages is not a problem, but consuming? Something has to do it? But it won't be written in PHP. It doesn't work very well with SQL databases, and with that I mean not the querying etc, but connection pooling, so the database server doesn't suddenly gets flooded by thousands of connections because a service is autoscaled due to heavier load (and sadly, that's a real-world example that brought down a database cluster). Tracing is doable, but not ideal, metrics are hacky due to the need of weird extensions to support shared memory, or rely on an external database such as Redis, which kinda defeats the point of metrics being lightweight. And tuning the PHP runtime almost rivals the JRE...

Post reply on HN