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

PHP 8.4

php.net

Post reply on HN
Print view View original

51–60 of 337 posts

Re: PHP 8.4

#51

Post by jayflux »

mg wrote: post #6

These days, I am super torn about what language to use for new web projects. PHP: - Easy to deploy: Upload files, done. - Easy to develop: Reload page, see changes. - Lots of HTTP tooling built in. - Fast. Python: - Great language. - Great code reuse system: Modules. - Nice framework: Django. - Less breaking changes in recent years.

> Easy to deploy: Upload files, done

I know people love to say this, but does anyone realistically make websites or web apps that way? No, not really. Even with PHP there are frameworks, there is a package manager, there is version control, and there are deployment systems.

Pretending that PHP developers are uploading a .php file to a shared hosting server (like in 2002) to suit the narrative feels disingenuous to me as it doesn’t align with what I see PHP developers doing at all.

Re: PHP 8.4

#52

Post by theodorejb »

pwdisswordfishz wrote: post #46
dadver wrote: post #15

Earlier quoted context omitted.

It can be a major update even though it's a minor version bump.

It could have been, but isn’t. Most of those are rather small, incremental quality-of-life improvements. Nothing revolutionary.

I wouldn't consider all the new features small, but even many small improvements can result in a major improvement.

Re: PHP 8.4

#53

Post by chx »

nneonneo wrote: post #39
dubcanada wrote: post #27

Earlier quoted context omitted.

The global namespace change would break everything. It’s unlikely they would ever do something like that. It’s hard to build on a language used by so many, when you can’t modify the base. Python decided to do 2.7 vs 3 and fragmented the eco system terribly.

They could help by not adding any more cruft to the global namespace . Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the buil…

That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways.

Surrendering the global namespace to the language is not so bad an idea.

Re: PHP 8.4

#54

Post by rty32 »

lofaszvanitt wrote: post #30
anttihaapala wrote: post #16

Oftentimes many of the significant new PHP features are to fix the shortsighted implementation in the previous ones - for example this method chaining with `new` - there was precedent already, C++ got it right well before PHP even existed and with the very same arrow operator that PHP borrowed (and so did Java and JavaScript with .), so the question is why did PHP have to get it wrong at first and for so long. Anothe…

Whats the problem with global namespace littered with utility functions. Do they get in the way? They hurt you? They whisper in your ear? Or with the badly named functions? Or the type juggling? Do they eat your soul?

It could be much easier for user defined functions to collide with standard functions, especially when it happens unintentionally.

Someone else creates a function named array_something in the namespace. Maybe it already exists in earlier versions, maybe it happens to collide with one of the four introduced in 8.4. This function is accessible to you in the current scope. Now, you try to call the function like the way it is defined in the standard library. You get a very confusing error and spend 10 minutes trying to figure if it is you or PHP that is hallucinating. Turns out you have been inadvertently calling that other user defined function. The other user may be completely unaware of the fact that they created a function with naming collision.

To combat this, you need strong IDE help including static type checking, which is not always there for everybody. And it still doesn't help with cases where the user defined function collides with a new standard function.

Most "modern" languages have very few built-in functions in the global namespace. Another example is Go. Correct me if I am wrong, but I believe there is 0 function in global namespace in Rust. println! exists but that's a macro. In other words, the example I mentioned just never happens with these languages.

Not to mention the long list of junk you see in IDE when you type "array_".

I guess you haven't written much MATLAB.

Re: PHP 8.4

#55

Post by mg »

notpushkin wrote: post #38
mg wrote: post #25

Earlier quoted context omitted.

There are of course ways to get "reload page, see results" to work even with Python. After all, computers are touring complete. But in PHP you have it out of the box. Faster, with less complexity and less resource consumption. And you can use the same setup in development as you can use in production.

Maybe I'm missing something, but PHP is not more efficient in that regard. When you load a Python page, it is served by an in-memory process. If code is updated, the process is restarted, parsing the code and initialising the application, but it is done only once. When you load a PHP page, it parses the code and initializes the app for each request . It then tears everything down after the request. There are less was…

In my experience:

PHP is always blazing fast, with no additional setup to make "Reload page, see results" work.

Python needs additional setup. Either by monitoring the filesystem and pessimistically recompiling the application every time a file changes. Causing resource consumption every time you hit save in your editor. Or by having the web workers that serve the requests die after 1s of inactivity or so. Which makes the next pageview slow again, even if no code changed.

I think PHP's advantage is because of 3 things:

1: Recompiling changed files is built in.

2: With PHP you can set your project up in a way that only the code necessary to answer a single request is updated. With Python and Django, all the code for all requests is updated and even code paths that are actually never used.

3: PHP keeps each file compiled to bytecode in memory and only recompiles files that have been changed. Although you might accomplish something similar in Python if you let it pollute your filesystem with cached bytecode files.

Re: PHP 8.4

#56

Post by JodieBenitez »

kijin wrote: post #37
JodieBenitez wrote: post #23

Earlier quoted context omitted.

> - Easy to deploy: Upload files, done. Sure, it works for simple/less important cases. But it also means that your application code is inconsistent while the files are uploading. Stop your service, upload the files, start the service: safer. For a Django app you would upload files and ask Gunicorn to graceful reload... similar, just cleaner.

You can use the same strategy with PHP. Preload all your scripts in opcache. Once you're done making changes, reset your opcache. In practice, any serious project is likely to be version-controlled. Git pull is generally fast enough that it behaves like an atomic change. (By default, opcache will not reload a file that's less than 2 seconds old.)

I'm pretty sure many PHP dev don't know about OPCache. Many of my colleagues don't know for sure. My point is "be aware of the state of your app code and what you execute", and so be aware of the shortcomings of this deployment "strategy". It's sure perfectly fine and easy for small apps / low traffic / not critical apps. I just want to point that it's not inherently good enough and definitely not the universal way to deploy a PHP app.

Git pull to deploy is something I avoid.

Re: PHP 8.4

#57

Post by nneonneo »

If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function.

Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $filter_callback) while the older array_search is ($search_value, $array).

There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code.

I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).

Re: PHP 8.4

#58

Post by conradfr »

idoubtit wrote: post #22

I'm just a PHP programmer for work, but I worry about the orientation PHP has chosen. As French people say: better is the enemy of good (Le mieux est l'ennemi du bien). The two new language features bring a higher language complexity for dubious gains. I hope I won't have to work with these. Property hooks mean that some language magic will turn a property access into a call to methods. It implies that `$this->x` has…

Don't you get tired of managing getters/setters in your entities?

Re: PHP 8.4

#59

Post by nneonneo »

chx wrote: post #53
nneonneo wrote: post #39

Earlier quoted context omitted.

They could help by not adding any more cruft to the global namespace . Adding any globals should be a carefully-considered change. User-defined functions are global by default, and although there are (now) much better ways to write PHP libraries, I can absolutely see some old library defining array_find (one of the new global functions in 8.4) in an incompatible way and breaking new code that attempts to use the buil…

That would be some really old library. Already in 2012 when Composer was released there was PSR-0 and today almost all libraries are Composer managed and using a namespace following PSR-4 which itself is ten years old. A library that old would almost surely not run on PHP 8 unchanged anyways. Surrendering the global namespace to the language is not so bad an idea.

Suppose I want to add some new code to an old website? Or I want to gradually upgrade an ancient code base - twelve years is not so old for PHP, when ancient frameworks like Wordpress are still alive and kicking.

Re: PHP 8.4

#60

Post by conradfr »

mg wrote: post #19
aedis wrote: post #11

Earlier quoted context omitted.

Don't forget Laravel for PHP.

To get to know Laravel, I forced myself to build a project with it for a few weeks and I did not like it. I found myself getting sucked in into a complex project structure and dealing with all kinds of strangeness like "artisan commands", "the autoload cache" etc. With Django, I can build a web application in a single file that has "import django" on top and take it from there: https://news.ycombinator.com/item?id=40…

You can do that with Symfony.

https://symfony.com/doc/current/configuration/micro_kernel_t...

https://symfony.com/blog/new-in-symfony-7-2-simpler-single-f...

Post reply on HN