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

221–230 of 610 posts

Re: A look at modern PHP

#221

Post by simion314 »

echelon wrote: post #196
simion314 wrote: post #106

Earlier quoted context omitted.

I like this about PHP, you don't have a callback hell. I don't disagree with you just sharing my experience here, we might work on different kind of problems.

I work on highly concurrent backends that handle 100k requests per second across a cluster, and PHP will never work in those situations. Any time you have to orchestrate multiple data store or service calls in the background, you don't want to block. Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage. PHP bakes you…

Yes, I never disagreed with that, best tool for the job. But your problem is not the usual stuff that web projects are about.

Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .

Re: A look at modern PHP

#223

Post by bufferoverflow »

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.

I think you can.

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

Re: A look at modern PHP

#224

Post by missosoup »

alphadevx wrote: post #216
echelon wrote: post #207

Earlier quoted context omitted.

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

Just FYI since you've done it twice and might want to know, it's not mute point. It's moot point.

Re: A look at modern PHP

#225

Post by echelon »

alphadevx wrote: post #216
echelon wrote: post #207

Earlier quoted context omitted.

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

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

You probably want to report a degraded status so any traffic that can be bled off into another cluster can do so.

> So how do you track those?

There's a thread pool.

> And for how long do they live after the parent request has been processed.

They might live on after the request flow if they're still doing work.

> or do they block the parent?

Depends on the job and the nature of the API.

> Gets complicated quickly.

That's engineering.

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

That's why I buy a lot of things. It's also one of many reasons why I don't buy PHP.

> 99.9% of web apps are CRUD.

Now that platforms have taken over, I don't think this is the case. Large systems have sophisticated needs that don't always map to a traditional relational data store. PubSub, feeds, queues, concurrency, eventual consistency, vector clocks, etc.

Platforms are going to eat the long tail in the search for growth.

Re: A look at modern PHP

#226

Post by aetherspawn »

realharo wrote: post #103
aetherspawn wrote: post #77

Earlier quoted context omitted.

They had to write an installer ecosystem around installing docker images, whereas with PHP and most stock server configs you can SSH a file into a server and you're pretty much done. Still if I want to write a simple web app in < 1 day, I would definitely use PHP.

In such a manual workflow ( "you can SSH a file into a server" ), you still have to setup at least URL rewriting in nginx for any PHP app using routing (which is basically everything using any PHP framework or micro-framework). Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests…

For most apps, the URL rewriting is optional.

Re: A look at modern PHP

#227

Post by giantDinosaur »

luckylion wrote: post #197
giantDinosaur wrote: post #158

Earlier quoted context omitted.

Our abstractions become the basis of our imagination - do we want developers to think and experience joy? Do we want their minds to spark and innovate and solve and embrace the full power of computing? Can anything compare with the illuminating glow of a powerful abstraction that reveals a new technique - perhaps not 'world changing' - that improves our software and our programmatic structures? I guess we don't, actu…

And business is, imho, not just "for profit", but society in general. I feel about it similar as I feel about wood working mastery. Creating incredible joints with extreme attention to detail and a lot of experience fascinates me. But to build furniture for more than one person a year, I'd prefer nails, power tools and a bunch of people that are experienced enough not to nail parts of their body to the wood. If we wa…

I think that that's also a good point. It makes me wonder about the useful limits of abstraction if accessibility (broadly defined) is the goal.

Re: A look at modern PHP

#228

Post by giantDinosaur »

mekster wrote: post #153
mxschumacher wrote: post #97

Earlier quoted context omitted.

From a business perspective this might also translate into lower development costs and easier access to talent.

This. I was using TypeScript for anything that looked like I'll be the sole maintainer but for something that could last for 10+ years, I started it out as PHP as I may not be the only maintainer one day and can't ask the client to look for more specialized talents for no good reason.

I'd say typescript is easily far enough into mainstream adoption that you can safely use it knowing others will be able to maintain it in the future.

Re: A look at modern PHP

#229

Post by fetbaffe »

ur-whale wrote: post #172
fetbaffe wrote: post #63

Earlier quoted context omitted.

Of course. Why change that for zero gain? Powershell does too. Can you point to some research that scientifically proves that the use of dollar sign in variable names makes it harder to solve computer science problems?

1. Waste of time and mental cycles: forces the programmer to do the parser's job because the language designer was too lazy to build in the logic to recognize variables. 2. Carpal tunnel syndrome, especially on keyboards where "$" can only be reached via shift.

1. Personally I find it easier to read variable names prefixed with dollar signs, it differentiates variables from other symbols, which makes them very easy to find, especially now when many languages gives information overload by lots of type information etc. My eyes can scan code faster.

2. rebind your keyboard.

Re: A look at modern PHP

#230

Post by camjw »

echelon wrote: post #214
AegirLeet wrote: post #203

Earlier quoted context omitted.

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

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