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

541–550 of 610 posts

Re: A look at modern PHP

#541

Post by stephenr »

solraph wrote: post #533
stephenr wrote: post #258

Earlier quoted context omitted.

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

If it’s a http api, there’s always curl_multi to do multiple concurrent requests.

Re: A look at modern PHP

#542

Post by pdimitar »

ivanhoe wrote: post #535
pdimitar wrote: post #513

Earlier quoted context omitted.

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

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

To a large degree, but not completely.

Some frameworks (actually the runtimes of the languages) allow for much easier and quicker scaling and/or deployment compared to others. But businesses usually prefer to burn money for that as opposed to making an informed choice early on.

Re: A look at modern PHP

#543

Post by zelphirkalt »

nucleardog wrote: post #434
AegirLeet wrote: post #175

Earlier quoted context omitted.

Some of it is still true, some of it isn't true anymore and some of it simply isn't very relevant. Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing. json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error(). Both are un…

And for many of us, these 25 year old warts are a benefit... Rather than just "fixing" json_decode and breaking backwards compatibility, old code still works. The business doesn't care about the new shiny. When someone pays to have a simple site developed, they don't want to be paying a contractor in a year to have a bunch of stuff updated so the language it's written in is "more correct" or whatever the overriding r…

It's nice, that "the business" does not care, but that does not say anything about the language design of PHP.

PLT doesn't care whether "the business" cares.

Re: A look at modern PHP

#544

Post by ivanhoe »

pdimitar wrote: post #542
ivanhoe wrote: post #535

Earlier quoted context omitted.

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

> 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... To a large degree, but not completely. Some frameworks (actually the runtimes of the languages) allow for much easier and quicker scaling and/or deployment compared to others. But businesses usually prefer to burn money for that as opposed to making an informed choice early on.

And also majority of businesses will never need more scaling up than perhaps upgrading to a slightly more expensive VPS or adding 2 more GBs of RAM.

Re: A look at modern PHP

#545

Post by dpacmittal »

KerryJones wrote: post #480

As someone who has programmed PHP professionally for 13+ years (and also JS and Python) I have never run into anyone who can place a solid argument since the PHP 7 + Laravel. -- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen. I can literally setup and deploy a laravel ap…

Javascript is still trash. What with the insane amount of configuration and build tools, extremely small standard library forcing you to use third party modules which may or may not have tens of security issues and the dependency hell it brings with it. I can go on and on.

Re: A look at modern PHP

#546

Post by kstrauser »

cweagans wrote: post #415
kstrauser wrote: post #339

Earlier quoted context omitted.

Most of the interesting things I’ve worked on would fall down if you couldn’t cache some stuff across requests, like database connections. If every request requires a new TCP connection, even if to something lightweight and fast like a local pgbouncer instance, requests are going to be a lot slower (and the time spent context switching from userspace to kernelspace and back a lot higher) than if you could reuse one f…

You can do that in PHP. The PHP database library has a persistent mode that you can use. See the last paragraph of example 3 + example 4 here: https://www.php.net/manual/en/pdo.connections.php

Sure, but then it's no longer purely stateless, and honestly no more isolated than, say, a Django app (assuming it hasn't been deliberately broken to share state across requests).

Re: A look at modern PHP

#547

Post by wolco »

jbergens wrote: post #355
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…

I think there is a huge difference between web sites and web applications. Most large applications today uses SPA and an api. The api can be done in any backend language and there is not many obvious benfits of using php but some clear drawbacks. If you just want to create a web site quickly then php works fine but on the other hand you can do it quickly with js, c# or Typescript also.

If you used laravel you get things like queuing (tooling around). You can go async. There are some advantages.

Re: A look at modern PHP

#548

Post by CSSer »

dpacmittal wrote: post #545
KerryJones wrote: post #480

As someone who has programmed PHP professionally for 13+ years (and also JS and Python) I have never run into anyone who can place a solid argument since the PHP 7 + Laravel. -- Let me clarify, PHP is useful with context. For building web apps. Each language has its best-uses. Laravel has the strongest ecosystem and community out of any language/framework combo I've seen. I can literally setup and deploy a laravel ap…

Javascript is still trash. What with the insane amount of configuration and build tools, extremely small standard library forcing you to use third party modules which may or may not have tens of security issues and the dependency hell it brings with it. I can go on and on.

I was raised in the darkness, so things don’t often look as bad as they are to me. Regardless, the clear distinction between PHP and JavaScript seems to be that I can choose whether or not I’d like to use one but not the other (and no, wasm doesn’t count because it still requires JS).

For me, I just don’t why I’d choose to use it for a green field project. Sure, it’s better now, but people have warned me to stay away from the boogeyman lurking within. Maybe it’s there, maybe it’s not. But why should I take the risk if it’s pretty much the same as other modern languages that might have cool stuff.

Re: A look at modern PHP

#549

Post by cweagans »

kstrauser wrote: post #546
cweagans wrote: post #415

Earlier quoted context omitted.

You can do that in PHP. The PHP database library has a persistent mode that you can use. See the last paragraph of example 3 + example 4 here: https://www.php.net/manual/en/pdo.connections.php

Sure, but then it's no longer purely stateless, and honestly no more isolated than, say, a Django app (assuming it hasn't been deliberately broken to share state across requests).

It's still completely stateless from the dev standpoint (even if it's not truly stateless under the hood). It's more like a caches connection if that makes sense.

Re: A look at modern PHP

#550

Post by aosmith »

mnm1 wrote: post #416
piotrkubisa wrote: post #252

Earlier quoted context omitted.

The really nice thing of Symfony framework is database schema mapping and migrations, which have compatibility with numerous database systems and provides abstraction layer [0], that among many options of interfaces have quite handy YAML-formatted schema mapping [1]. Nothing extraordinary these days but it is really stable and simple to use. [0]: https://symfony.com/doc/current/doctrine.html [1]: https://www.doctrine…

Do you ever profile doctrine? I found its overhead to be 10x the actual time of my average query. Most of the time is spent hydrating. I wonder how people can put up with such a level of performance reduction and still claim they are using decent tools.

Oh doctrine, those were the days... I spent a couple years working on a project that was eventually rewritten in rails because there was a memory leak that required restarting the server ever night via cron.
Post reply on HN