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

PHP 8.0.0 beta 2

php.net

Post reply on HN
Print view View original

61–70 of 102 posts

Re: PHP 8.0.0 beta 2

#61

Post by tuco86 »

core-questions wrote: post #26
ragnese wrote: post #17

Earlier quoted context omitted.

> Is there anything that PHP is developing or adopting that can not be had at other established languages? IMO, no. The language is still near the bottom for both dynamic and "static" typed languages. HOWEVER, if you're doing web backend stuff, Laravel and Symfony are both really solid frameworks. The direction PHP Is moving in right now is to emulate Java 7, but without generics or concurrency. It's definitely a dea…

> IMO, no. The language is still near the bottom for both dynamic and "static" typed languages. Why do you say that? It's faster than Python and Ruby for most cases, still extremely simple to deploy, the package manager (Composer) is very predictable and easy to deal with compared to Pip or Rubygems, the documentation is good, etc. It has clean lambda functions that you can pass around easily and has for more than a…

I don't agree with the faster and extremely simple to deploy points, at all. Both objections have to do with php-fpm.

it spawns a new php interpreter for every request, which means for example that symfony framework setup (routes, controllers, service dependencies...) have to run before every request. Sure it does that faster than python, but python only needs to do this once.

deployment is my personal nightmare. try to set the max children or whatever so concurrency is ok but memory does not run out. I mean facebook did it so it has to be possible but damn, that was hard to get `right`. Setting up logging is a mess. There is the application, the admin and the fpm error log, I gave up trying to have every log event logged exactly once. Segfaults are a common occurrence, still. I heard it mentioned just before leaving for vacation.

Re: PHP 8.0.0 beta 2

#62

Post by ragnese »

skrebbel wrote: post #43
rglullis wrote: post #7

Earlier quoted context omitted.

I have to confess that I have a lot of prejudice against PHP after having to work with it at the time of PHP3 and 4. It seemed like even worse than Perl in the sense of how many things were just bolted on it as a way that the developers could claim "yeah, you can do that with PHP". After having a blog running wordpress hacked twice by mere virtue of being online, I dismissed it for good. I keep hearing about how the…

By the way you phrase that question, you're dismissing that single key feature that PHP _already has_ that cannot be had at other established languages. I know of no other language that lets you deploy a web app by dragging some files from the left to the right in FileZilla. No setup, No vendor lock in, no nothing. It just works. Cross-cloud serverless frameworks that wrap AWS lambda + competitors get you somewhat cl…

You cannot deploy a PHP app by just plopping a file on an unconfigured server.

Deployment is not that simple.

Or, if it is, then you have to allow me the same grace of just being able to plop my Go or Rust binary on that server and have it magically work. It might even work BETTER because I don't need to check if my php.ini matches my dev machine.

Re: PHP 8.0.0 beta 2

#63

Post by jasonlotito »

rglullis wrote: post #7
mrrsm wrote: post #3

PHP, since version 7.0, has been a much improved language since when many people started hating on it. They have been consistently moving the spec forward and making improvements. It's not perfect, but no language really is after all. It is really nice just seeing issues that have been around for a long time being addressed and fixed.

I have to confess that I have a lot of prejudice against PHP after having to work with it at the time of PHP3 and 4. It seemed like even worse than Perl in the sense of how many things were just bolted on it as a way that the developers could claim "yeah, you can do that with PHP". After having a blog running wordpress hacked twice by mere virtue of being online, I dismissed it for good. I keep hearing about how the…

> Is there anything that PHP is developing or adopting that can not be had at other established languages?

I feel like I can ask that question about most established languages and get the same answer back. It still has the easiest deployment and development flow of any language I've ever used. I don't know of a single language that does that right now, and makes going from 0 to 100% much easier, which for smaller pet projects, it's so much less hassle. Upload file, it's running on the web. That's it.

As for all the features it has that other languages have, PHP tends to merge them together. While this means the language is larger than most, it also means I can do things in ways I want to and try new features out.

This doesn't mean I'm not using JS or Go or Java or other languages. But if I'm building a web API, PHP is the one that gets out of my way and lets me build it quickly and easily.

Re: PHP 8.0.0 beta 2

#64

Post by jasonlotito »

rglullis wrote: post #50
skrebbel wrote: post #43

Earlier quoted context omitted.

By the way you phrase that question, you're dismissing that single key feature that PHP _already has_ that cannot be had at other established languages. I know of no other language that lets you deploy a web app by dragging some files from the left to the right in FileZilla. No setup, No vendor lock in, no nothing. It just works. Cross-cloud serverless frameworks that wrap AWS lambda + competitors get you somewhat cl…

Right, but isn't precisely this "drag from left to right and get a website running" that leads to an endless stream of sites that get hacked because the developer was careless/ignorant enough to leave admin.php with executable permissions?

No.

Re: PHP 8.0.0 beta 2

#65

Post by beberlei »

rglullis wrote: post #7
mrrsm wrote: post #3

PHP, since version 7.0, has been a much improved language since when many people started hating on it. They have been consistently moving the spec forward and making improvements. It's not perfect, but no language really is after all. It is really nice just seeing issues that have been around for a long time being addressed and fixed.

I have to confess that I have a lot of prejudice against PHP after having to work with it at the time of PHP3 and 4. It seemed like even worse than Perl in the sense of how many things were just bolted on it as a way that the developers could claim "yeah, you can do that with PHP". After having a blog running wordpress hacked twice by mere virtue of being online, I dismissed it for good. I keep hearing about how the…

PHP has sort of done serverless in 2000, so evolutionary dead end is a a bit harsh :)

Re: PHP 8.0.0 beta 2

#66

Post by Denvercoder9 »

toupeira wrote: post #11

Article with an overview of the changes: https://stitcher.io/blog/new-in-php-8 Some highlights are union types, a JIT compiler, named arguments, annotations, and match expressions. The approach to named arguments is interesting. It's nice that you don't have to change the signature of existing functions, but the downside seems to be that you can't enforce the usage of named arguments on callers, as in other languages…

> Python where keyword arguments need to be declared as such.

In Python you don't need to explicitly declare keyword arguments either (though it is possible). This is perfectly valid and working:

    def foo(a: str, b: int, c: bool=None, d: float=None):
        pass

    foo(b=5, a='something', d=3.0)
    # is equivalent to
    foo('something', 5, None, 3.0)

Re: PHP 8.0.0 beta 2

#67

Post by rglullis »

beberlei wrote: post #65
rglullis wrote: post #7

Earlier quoted context omitted.

I have to confess that I have a lot of prejudice against PHP after having to work with it at the time of PHP3 and 4. It seemed like even worse than Perl in the sense of how many things were just bolted on it as a way that the developers could claim "yeah, you can do that with PHP". After having a blog running wordpress hacked twice by mere virtue of being online, I dismissed it for good. I keep hearing about how the…

PHP has sort of done serverless in 2000, so evolutionary dead end is a a bit harsh :)

Do you mean cgi-bin? If that is the case, Perl and C had it beat. ;)

Re: PHP 8.0.0 beta 2

#68

Post by FranOntanaya »

no_wizard wrote: post #20
webignition wrote: post #10

Earlier quoted context omitted.

What are the memory leak problems? I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.

Manipulating complex data structures that are large and/or trying to manage long running processes cause memory leaks. I often find I have to jump through hoops I don't have to in other languages to deal with these kinds of problems, for instance. I usually have to resort to queues, which just adds complexity where I typically don't want it.

> Manipulating complex data structures that are large

I do assume it's not the case, but one of the footguns with PHP is that assigning around large variables/arrays and triggering the copy-on-write can end building up the amount of duplicates of that data being kept alive. Pass by reference, unsets, generators and the like aren't used super often due to a lot of runs being small stateless requests, but sometimes they may be needed.

Re: PHP 8.0.0 beta 2

#69

Post by wanderr »

webignition wrote: post #10
no_wizard wrote: post #8

If the JIT for PHP ever becomes good enough it solves the memory leak problems PHP to this day is still plagued with, that might be enough to convince me to use PHP again, possibly, for some workloads. I can't help but feel that PHPs popularity is mostly tied to Wordpress, and to a lesser extend Laravel (with Symfony coming in behind that). Not really sure the rest of the ecosystem even matters, outside those core pi…

What are the memory leak problems? I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.

This is true. As far as I understand, the only issue with memory leaks have been around super long running processes that create cyclical references that cause refcounting to not "notice" that something is free. I have never had a memory leak problem with a web service, and I wrote* the PHP backend for Grooveshark (45 million monthly users, averaging 2 hours per visit, running on half a dozen front end web servers. Sadly I don't remember RPS figures at this point)

*not to take sole credit. I created RPC framework and initial API, and oversaw a small team of very talented engineers who added a significant chunk of the functionality powering Grooveshark over the years

Re: PHP 8.0.0 beta 2

#70

Post by wanderr »

diek wrote: post #19
webignition wrote: post #10

Earlier quoted context omitted.

What are the memory leak problems? I was under the impression that PHP's stateless nature, with a whole new instance of everything coming into being for each request, somewhat sidesteps the capacity for problematic memory leaks that could otherwise exist for processes that remain alive between requests.

Most web workloads will use some sort of process cache, like php-fpm, simply because spawning a process for each request is very inefficient. So the process and any extensions used can leak memory over time across requests.

php-fpm is typically configured to restart those processes after some number of requests, just in case there is such a leak. But I have not seen those leaks happen between process restarts, state is still wiped clean between requests, so leaks should be rare/difficult and probably most likely the result of faulty extensions.
Post reply on HN