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

Everything you need (and don't need) to know about PHP's type system

thephp.website

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Everything you need (and don't need) to know about PHP's type system

#41

Post by tutfbhuf »

fraktl wrote: post #28
bnt wrote: post #14

Earlier quoted context omitted.

Isn’t Laravel the worst performing framework out there right now, like even Rails looks like a viable option in terms of speed?

No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously. Any framework bears overhead, they all optimize programmer's time invested into solving the problem. It's cheaper to buy hardware and scale horizontally rather than swap languages and frameworks hunting for performance. PHP being synchronous by nature is what limits its performance, bu…

> No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously

No, that's outright wrong. Please see the well respected techempower web benchmark: https://www.techempower.com/benchmarks/

> For the ones who will google what Swoole is, some benchmarks I've done on my laptop show 5x (yes, 5 times, 500%) increase in performance when Laravel is ran via Swoole.

Yup, that seems to be correct. What are the drawbacks of Swoole?

Re: Everything you need (and don't need) to know about PHP's type system

#42

Post by mhitza »

muglug wrote: post #39
mhitza wrote: post #16

Earlier quoted context omitted.

Psalm is nice, however I would suggest PHPStan as an alternative for people that encounter a lot of friction with Psalm. For example, in a project using doctrine I have to add a bunch of is null/@psal-mutation-free annotations. As all the methods can return null. However, if Psalm had support for something like phantom types, maybe I could tag entities returned from the database for whom certain fields are guaranteed…

Psalm has levels – higher levels show fewer warnings (just like in PHPStan). Maybe the `@psalm-ignore-nullable-return` annotation is more appropriate for those methods? Do you use the Doctrine plugin?

I set these kinds of tools up to the highest level possible. In my opinion that is where you get the highest value from them.

I was not aware of the any psalm doctrine plugin and will definitely have a look at it. Thanks for the suggestion.

In terms of @psalm-ignore-nullable-return annotation. That definitely sounds like a practical workaround, at the moment.

Re: Everything you need (and don't need) to know about PHP's type system

#43

Post by noir_lord »

admissionsguy wrote: post #32
noir_lord wrote: post #26

Earlier quoted context omitted.

It's gotten a lot better since I started using it ~2009 and now. 7.4 added typed properties. 8 is adding better caching, a jit and my favourite feature match() https://php.watch/versions/8.0#match-expression for all the enterprise heavy stuff I write a nicer cleaner and safer (by default) alternative to switch is going to make some code much cleaner to write and read and really that is what I care about more than alm…

The match expression is so elegant. For the past 10 years I've been puzzled by how verbose switch is.

It's better than switch for a lot of switch use cases, it's still not 'real' pattern matching but yeah I'm looking forwards to it.

Re: Everything you need (and don't need) to know about PHP's type system

#44

Post by bsdubernerd »

osrec wrote: post #10

It actually makes me really happy to see more positive comments on a thread about PHP. It is an incredible workhorse, and doesn't get the credit it deserves. I'm often amused by developers that revile PHP, while going on to use another language, which suffers from a similar set of problems to PHP, oftentimes with poorer performance and more complex toolchains. PHP deserves a little more love, imo.

I always used and use PHP because it gets the s$$$ done.

But truth be told, the hate is deserved. It never was a particularly efficient language, which might not matter that much, but it was riddled with gotchas, warts and horrible solutions to many technical and social problems.

Today PHP is faster than many alternatives, many of its warts got fixed, but I cannot brush off the fact that it's still based on a poorly-designed base and runtime library.

I'm still using PHP when it makes sense, in the same way I'm still using perl where it makes sense.

Re: Everything you need (and don't need) to know about PHP's type system

#45

Post by kyriakos »

bsdubernerd wrote: post #44
osrec wrote: post #10

It actually makes me really happy to see more positive comments on a thread about PHP. It is an incredible workhorse, and doesn't get the credit it deserves. I'm often amused by developers that revile PHP, while going on to use another language, which suffers from a similar set of problems to PHP, oftentimes with poorer performance and more complex toolchains. PHP deserves a little more love, imo.

I always used and use PHP because it gets the s$$$ done. But truth be told, the hate is deserved. It never was a particularly efficient language, which might not matter that much, but it was riddled with gotchas, warts and horrible solutions to many technical and social problems. Today PHP is faster than many alternatives, many of its warts got fixed, but I cannot brush off the fact that it's still based on a poorly-…

I agree with both statements, it gets shit done but has its rough edges. Its improving though and I doubt there's a perfect programming language out there. At the end of the day what matters are results and how quickly you went from idea to production and PHP is one of the good ones for that matter.

Re: Everything you need (and don't need) to know about PHP's type system

#47

Post by paledot »

zerocrates wrote: post #15
paledot wrote: post #13

Earlier quoted context omitted.

Worth emphasizing that this directive applies per file, and affects functions called (not those defined) in that file. Not sure if there's a mechanical reason for that, but if I'm writing a new class I'd like some assurances that it's being used correctly. If I could enforce strict types on calling code, I could do away with a certain class of validation.

The point is supposed to be that once you write in a scalar typehint for a parameter, you don't need to do validation for it being the right type within the function: even if it's called from a non-strict context, that just means PHP will cast it before passing it. So you can avoid type checking code in your function but consumers can still use the more traditional and dynamic style of PHP if they want to. I can't qu…

Good point. My method may behave unexpectedly if you call `sum(true, false)`, but it's not identifiably different than `sum(1, 0)`. Sorry, it was late, and I failed to mention my actual use case: I work on a legacy application and want to enforce correctness on the new code I write. I'd rather write a new module and enforce that the calling code in the legacy app is using it correctly, than try to add strict types to the legacy classes.

Re: Everything you need (and don't need) to know about PHP's type system

#48

Post by fraktl »

tutfbhuf wrote: post #41
fraktl wrote: post #28

Earlier quoted context omitted.

No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously. Any framework bears overhead, they all optimize programmer's time invested into solving the problem. It's cheaper to buy hardware and scale horizontally rather than swap languages and frameworks hunting for performance. PHP being synchronous by nature is what limits its performance, bu…

> No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously No, that's outright wrong. Please see the well respected techempower web benchmark: https://www.techempower.com/benchmarks/ > For the ones who will google what Swoole is, some benchmarks I've done on my laptop show 5x (yes, 5 times, 500%) increase in performance when Laravel is ran vi…

> No, that's outright wrong. Please see the well respected techempower web benchmark: https://www.techempower.com/benchmarks/

I just notified the servers I've to manage (and my coworkers) that we're outright wrong and the load we're seeing is phantasm and that guy from internet told us so since he linked the well respected techempower benchmarks, which apparently reflect real world situation :)

Re: Everything you need (and don't need) to know about PHP's type system

#49

Post by untog »

noir_lord wrote: post #26
jonny383 wrote: post #3

PHP rocks in 2020. Couple it with laravel or something and you get a solid platform to build a monolith-type web app with really fast performance.

It's gotten a lot better since I started using it ~2009 and now. 7.4 added typed properties. 8 is adding better caching, a jit and my favourite feature match() https://php.watch/versions/8.0#match-expression for all the enterprise heavy stuff I write a nicer cleaner and safer (by default) alternative to switch is going to make some code much cleaner to write and read and really that is what I care about more than alm…

Match looks exactly how Rust’s match works and it’s one of my favourite parts of the language. Happy to see it elsewhere too.

Re: Everything you need (and don't need) to know about PHP's type system

#50

Post by tutfbhuf »

fraktl wrote: post #48
tutfbhuf wrote: post #41

Earlier quoted context omitted.

> No. Laravel performs quite nicely. Rails can't be compared to Laravel, it's slower by an order of magnitude, as mentioned previously No, that's outright wrong. Please see the well respected techempower web benchmark: https://www.techempower.com/benchmarks/ > For the ones who will google what Swoole is, some benchmarks I've done on my laptop show 5x (yes, 5 times, 500%) increase in performance when Laravel is ran vi…

> No, that's outright wrong. Please see the well respected techempower web benchmark: https://www.techempower.com/benchmarks/ I just notified the servers I've to manage (and my coworkers) that we're outright wrong and the load we're seeing is phantasm and that guy from internet told us so since he linked the well respected techempower benchmarks, which apparently reflect real world situation :)

If you and your co-workers have both Rails and Laravel in production and your Laravel applications performs better, then I have absolutely no doubt about that. However, there is no evidence that Rails is an order of magnitude slower than Laravel in general, quite the contrary, benchmarks indicating that (non-swoole) Laravel is slower.
Post reply on HN