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++.
Everything you need (and don't need) to know about PHP's type system
21–30 of 67 posts
Re: Everything you need (and don't need) to know about PHP's type system
#22Main takeaway: strict types won't make your code faster!
It may make it slightly slower
Re: Everything you need (and don't need) to know about PHP's type system
#23Is 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++.
A lot of what Hack introduced to the PHP community has become available in suitably forward-thinking ways to allow for a sensible amount of backwards compatibility and are opt-in.
For example, you can set strict typing on a per-file basis.
`declare(strict_types=1);`
I believe that the performance difference between the two is negligible now too. So it really just comes down to personal preference/platform legacy.
But Hack is on a different path which is potentially going to make it harder to share code between PHP and Hack.
PHP still has by far the larger community.
Given the choice today, I’d run with PHP.
Re: Everything you need (and don't need) to know about PHP's type system
#24Earlier 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…
Adding Phan to this conversation initially created by the creator of a PHP, now in the hands of TysonAndre who does an insane amount of good work on it
For users of the intellij family (idea or phpstorm).
https://plugins.jetbrains.com/plugin/10215-php-inspections-e... is amazing and well worth the price.
It has a free variant which is still amazing but lacks all the inspections of the paid variant.
https://plugins.jetbrains.com/plugin/7622-php-inspections-ea...
Re: Everything you need (and don't need) to know about PHP's type system
#25PHP 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.
Isn’t Laravel the worst performing framework out there right now, like even Rails looks like a viable option in terms of speed?
> Isn’t Laravel the worst performing framework out there right now.
I'm more of a Symfony than Laravel guy but I've done both enough to know that application architecture and environment configuration has more of an impact than either framework's "performance" does.
Silly things are slow in most web frameworks.
Re: Everything you need (and don't need) to know about PHP's type system
#26PHP 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()
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 almost anything else.
That it also returns a value is just the cherry on top. I am so tired of reading bad code with poor intent that has no comments and no documentation that's written in the most counter intuitive way.
Re: Everything you need (and don't need) to know about PHP's type system
#27Is 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++.
Having "much stronger" type system cannot be anyone's definitive reason for deciding to go with Hacklang instead of PHP.
Type system doesn't guarantee that the programmer will utilize it properly, produce optimal code or even figure out the problem that is being solved by writing an algorithm.
You also need to pay attention to the ecosystem, problems that come with HHVM, the fact you're undoubtedly tying yourself with Facebook and what you're gaining / losing with the decision to go with a fork of PHP.
Re: Everything you need (and don't need) to know about PHP's type system
#28PHP 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.
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, but we have Swoole that fixes it and makes it faster.
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.
Re: Everything you need (and don't need) to know about PHP's type system
#29Earlier 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?
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?
Re: Everything you need (and don't need) to know about PHP's type system
#30Is 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++.
Hack isn’t still commonly used outside of FB, and for the right reasons - the PHP community is much bigger. Very few projects test for Hack compatibility, and the performance gains aren’t worth it these days (they were 5 years ago, but not so much these days)