Live data from Hacker News

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

thephp.website

31–40 of 67 posts

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

#31
post #21

Is there a good reason to still use php when you can use hacklang ( https://hacklang.org/ ) which has much stronger type system. Some would even call it php++.

If you’re building an app to run on other people’s servers, vanilla PHP is much more widely available :(

(Sad because I use Hack in my day job and PHP for my open source projects, and find Hack way more pleasant and productive)

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

#32
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…

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

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

#33
post #31
post #21

Is there a good reason to still use php when you can use hacklang ( https://hacklang.org/ ) which has much stronger type system. Some would even call it php++.

If you’re building an app to run on other people’s servers, vanilla PHP is much more widely available :( (Sad because I use Hack in my day job and PHP for my open source projects, and find Hack way more pleasant and productive)

Hacklang diverged from PHP proper a while ago, but I haven't validated what this actually means. I know interoperability wasn't guaranteed, but with Hack at your work are you able to use composer packages - i.e. Symfony components? The ecosystem around pure Hack packages or frameworks appears quite small/niche.

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

#35
post #29

Earlier quoted context omitted.

Ruby is slower than PHP7+ by orders of magnitude. I doubt it.

Orders of magnitude? Do you thibk that PHP is at least x100 times faster than Ruby?

Alright, maybe an exaggeration. But the difference is huge. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

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

We often have comments like "actually php is not that bad" and then people might think let's give it another try, only to find out that they came across all over the same quirks of language (design) and runtime behavior again. I think the main problem of php is that it's so inconsistent. I would rather prefer a bad language if it would happen to be at least very consistently so.

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

#37
post #22

Main takeaway: strict types won't make your code faster! It may make it slightly slower

The point of strict types is generally not speed, but rather, to make your code more correct.

Correct? I'd probably say predictable.

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

#38
post #29

Earlier quoted context omitted.

Orders of magnitude? Do you thibk that PHP is at least x100 times faster than Ruby?

Alright, maybe an exaggeration. But the difference is huge. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Well that is a benchmark with a set of specific mathematical problems like calculating pi digits. I would rather compare Rails with Laravel e.g. in terms of requests per second or speed of json deserialization. See https://www.techempower.com/benchmarks/ Symfony, Lumen and Rails seems to be somewhat equal in performance, but Laravel is a bit slower in respect to the benchmarked web related criterions.

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

#39
post #16
post #9

Adding a static analyzer (like Psalm [1]) to the mixture makes PHP's types much more powerful. Psalm can use docblock annotations to attach more complex types to functions and variables, including: * A "list" type representing a non-associative array * Types representing specific kinds of values, like numeric-string or non-empty-array, as well as exact values as types (like true and false, or string constants). * Typ…

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?

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

#40

Earlier quoted context omitted.

The point of strict types is generally not speed, but rather, to make your code more correct.

Correct? I'd probably say predictable.

Eh. If MyPy complains that I'm passing an `Optional[Entity]` into a method where only an `Entity` can go, it's just helped me avoid a runtime error when I try to get `entity.name`. Not sure what the exact PHP equivalent is, but there's all sorts of bugs you can easily introduce if you're not careful with types.
Post reply on HN