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

531–540 of 610 posts

Re: A look at modern PHP

#531

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

I discuss my design methodology for the project here: https://medium.com/chrismarshallny/forensic-design-documenta...

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

Re: A look at modern PHP

#532

Post by vertex-four »

erik_seaberg wrote: post #522
vertex-four wrote: post #342

Earlier quoted context omitted.

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.

Re: A look at modern PHP

#533

Post by solraph »

stephenr wrote: post #258
solraph wrote: post #236

Earlier quoted context omitted.

Ironically, the root cause that made me think of that example was AWS. The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms. There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.

... you do know that you can send a response to the client, close the connection and do something else before the process "finishes" right?

I do. However, the process would have stuck around until it finished. It wouldn't have changed our overall RPS at all.

Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.

Re: A look at modern PHP

#534

Post by seangrogg »

eropple wrote: post #514
MisterBastahrd wrote: post #296

Earlier quoted context omitted.

It's amusing to me to see all the hate for PHP, especially when the original lazy gripe was that people hated when faced with code that was mixed with templates. So completely different than the dominant modern front-end frameworks.

At least one of those front-end frameworks doesn't "mix code with templates", it represents HTML as code . (It's for that reason that JSX is the first way-to-splat-HTML-out that hasn't made my skin crawl in...pretty much ever.)

GP could've easily been talking about the many other libraries/frameworks that DO use templating, though: Template Syntax in Angular/Vue, Glimmer in Ember, etc.

Re: A look at modern PHP

#535

Post by ivanhoe »

pdimitar wrote: post #513
stunt wrote: post #200

Earlier quoted context omitted.

Most of the comments against PHP are from developers that wrote PHP There are still some issues but considering the current state of language, frameworks, libraries, and the ecosystem, it's very practical and productive environment to build any project. I've been doing Typescript, Scala, and recently also Go in last few years. Scala and Go have decent language design and I'm a fan of both of them. But, when it comes…

> If I was about to build my own web startup, I'd definitely build it with PHP because I'm sure I could launch it 10 times faster with Laravel. Fair enough, and same applies to Ruby on Rails. Let's not conflate "easy and quick to launch an MVP" with "sustainable for long-term development" however. There are many stories on the net how people started with something as basic as WordPress or Rails but had to rewrite in…

True, but I still haven't heard of anyone having to rewrite Symfony or Laravel project because of the frameworks themselves, usually it's poor design choices that could have happened in Django or RoR or Express as well (and that happens all the time, I've seen a lot of node projects that sucked because of lack of planning and we had to practically rewrite them from a scratch). No framework can save you from being careless (nor it should IMHO). In the end, unless you're building something really super popular it really doesn't matter which framework one chooses as long you learn how to properly use it and you don;t suck at programming... it's just vim vs. emacs type of problem, it's simply a personal preference, both are great, just use what you enjoy the most...

Re: A look at modern PHP

#536

Post by ragnese »

romellem wrote: post #515
ragnese wrote: post #262

Earlier quoted context omitted.

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

The PHP deal-breaker is that it casts[0] string keys that contain "valid decimal integers" to "the integer type"? Seems like a fairly minor language quirk (of which almost every language has) rather than a huge feature that makes one want to avoid the language at all cost. Of course, feel free to make your own choice when picking a language, but I don't think this is a compelling reason why one would always want to a…

I'm getting quite tired of the nonsense straw men in this discussion.

Do you truly believe that I articulated that there was exactly one reason that I think PHP hinders developer productivity?

And of course, we brought out the old "every language has quirks" apology. Yes, you can bang a nail in with a rock. But, don't. Use a hammer.

Do better, please.

Re: A look at modern PHP

#537

Post by merb »

tzs wrote: post #304
watermelon0 wrote: post #178

Earlier quoted context omitted.

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

> There is no way to easily share memory between processes What about https://www.php.net/manual/en/ref.shmop.php ?

not atomic

Re: A look at modern PHP

#538

Post by ivanhoe »

eropple wrote: post #514
MisterBastahrd wrote: post #296

Earlier quoted context omitted.

It's amusing to me to see all the hate for PHP, especially when the original lazy gripe was that people hated when faced with code that was mixed with templates. So completely different than the dominant modern front-end frameworks.

At least one of those front-end frameworks doesn't "mix code with templates", it represents HTML as code . (It's for that reason that JSX is the first way-to-splat-HTML-out that hasn't made my skin crawl in...pretty much ever.)

JSX just reverses the story, it's js with islands of html tags thrown in it instead of being html with code in it... in the end when you look at an average presentation component it's still like 90% html tags and some js mixed all together...

Re: A look at modern PHP

#539

Post by ragnese »

jrumbut wrote: post #482
tnorthcutt wrote: post #446

Earlier quoted context omitted.

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?

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

You're not the only one. I have to actively resist the urge. In some sense, I see the appeal of Go in making this kind of "mental masturbation" not even possible.

On the other hand, I've dug myself deep enough, enough times, that I've developed a decent sense of when these endeavors are likely to pay off (writing an actual DSL never has for me, and likely never will unless you're coding to a very stable spec). But there's a TON of low- and mid-hanging fruit to be had by "making impossible states unrepresentable" and when you draw the line in the right place, it pays massive dividends.

Re: A look at modern PHP

#540

Post by ivanhoe »

watermelon0 wrote: post #178
s1k3s wrote: post #112

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…

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

> The reason for this is because PHP doesn't support many things that are expected in any other language.

And the reason for this is that those parts are handled by web servers and php doesn't need to handle them. Isolation decision that simplifies things significantly infrastructure wise and that allowed for shared hosting to exist - which in turn brought the costs down and made web as popular and massive as it is today.

BTW, this architecture is not that different from what node and others are doing. Instead of having a language/framework that acts as a web server (but too simple, so you still need nginx in front), and then you need a queue service to delegate the jobs, you have a web server that delegates the jobs (requests) to isolated php processes. Model is the same and that's the model that's used everywhere today, just that the moving parts are partitioned a bit differently in different languages.

Of course, it's not a perfect solution to every problem, but works very good for any not-real-time web site/app and in the end RoR, Django, Symfony, etc. they all work in a very similar way (minus the syntactical nuances). For a massive traffic or language level high parallelism just use something else, no one argues against that.

Post reply on HN