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)
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.
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.
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.
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.
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?
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.