Hacker News Reader

Comment by krick | Hacker News Reader

Wow. I'm honestly surprised by the amount of people (on the HN!) in 2020, thinking PHP is some pre-historical language clearly inferior to... I'm not even sure what. JS? That would be funny.

(It feels like I'm defending PHP now, which is feels weird, because I can go on for hours talking about the stuff I hate about PHP. But there is a difference between hating it for problems it actually has, and just not treating PHP as seriously useful modern tool which it definitely is.)

That aside, I cannot really treat seriously author's recommendation of Amp, ReactPHP and such as a solution for async. Don't bring up HHVM either. There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now. And for me, it might be the biggest problem it has right now, which seriously hurts in some applications.

View on HN

> There's no real solid support for async/await in PHP, not even in the form Python has for quite a while now.

I'll second this. Async/await support in PHP is at best an ugly hack.

I don't know if we'll ever get first-class async/await support since there is no event loop in the PHP runtime, and because of how PHP works (build and teardown on each HTTP request).

> And for me, it might be the biggest problem it has right now, which seriously hurts in some applications.

What problem are you trying to solve where a lack of async/await would help?

I've encountered dozens, maybe hundreds of problems where it was actually something that would matter. Here's one example. Consider you need to process lots of requests, that require making multiple requests that take a long time to finish (like 10-30 seconds) and you need to do it nearly in real-time. Given there's no sane multi-threading in PHP as well, you end up building your own parallelism support, which requires running lots of workers. Now, every of these workers does some pre-processing, makes a requests and waits for multiple damn seconds, to get the result back, make some computations and get to the next job. Consequently, to handle the same number of requests/sec you need much more workers, which has a lot of overhead, which results in needing more servers.

Sometimes you can use CURL to just make multiple similar requests in parallel and call it a day, but in practice I rarely could make use of it (consider that service you need to call might require some fucked up protocol, like SOAP, so you best option would be to rewrite SOAP client using CURL with parallel requests, which is not fun at all).

At that point you really start thinking some (any?!) other language would be a better fit for the application, but you have tons of very domain-specific business logic written in PHP that you'd need to rewrite for that app, as well as a team of PHP-developers that are not necessarily ready to learn whatever you have in mind, sooo...

> to handle the same number of requests/sec you need much more workers, which has a lot of overhead

When doing multiprocessing, it's advisable to fork() instead of creating fresh processes (or launching them in containers etc). As long as you preload the necessary libraries/modules in the parent process before the fork, children will reference the same memory in a copy-on-write fashion. It keeps overhead extremely low.

This [1] article is for the Unicorn (ruby) webserver but the way it explains forking, signals, and pipes for inter-process control it's absolutely illuminating. These techniques are applicable to any unix-based applications, including php daemons.

[1] https://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-...

Thanks, that's a nice idea. Kind of hard to implement in the setup I'm thinking about right now, but, still, that never occurred to me, so this is something to consider.

But, of course, it doesn't replace proper async/await. First of all, there are other situations where this solution wouldn't apply. And even in described scenario it isn't ideal. For starters, pre-loading everything before fork is really easier said than done: quite often data you need to fetch depends on the result of request, but just so happens to be very much reusable between multiple jobs. Then, it complicates the code quite a bit, makes to constantly keep in mind across the whole codebase things you wouldn't really want developer to think much about to start with. Additionally, it makes DevOps harder as well: people want to rely on LoadAvg (which is very unreliable metric, but explaining this to people every time is not what makes for a friendly environment) and multiple jobs doing nothing just waiting for I/O to finish sky-rocket it. Then some DevOps tools (you don't necessarily know about because of department communication) try to be smart by relying on loadavg and start actually breaking things.

It is a hack, but it works well if you follow the rules. We've deployed stable and scalable APIs using PHP(Laravel/Swoole.) We would have loved to use something more fitting like Go but the time to MVP would have been much longer. While not perfect, it's been great to develop with. Using production code, it provides us ~5x rps (over php-fpm+opcache,) lower latency, better efficiency, and better scalability. However, if variables are set outside the event loop they will not update, so we had to add some additional tests to help avoid this.

> Wow. I'm honestly surprised by the amount of people (on the HN!) in 2020, thinking PHP is some pre-historical language clearly inferior to... I'm not even sure what. JS? That would be funny.

Erm, well, if I compare with any language, that has a thought through type system (PHP: generics missing, no base type one can use instead), proper closures (https://nullprogram.com/blog/2019/09/25/) and actually consistent standard library ... Yes PHP is still a kind of prehistoric language. Basically one cannot do FP properly without proper closures and that forces people to the other end, usually OOP, but that is terrible in PHP as well. Some kind of patched on top "here you have classes" kind of OOP basis, without generics. Great.

And then all the bad practices PHP encourages, with its hundreds of PHP open tags and PHP close tags, intermingled with HTML and JS, which you can see in many popular open source PHP projects (especially Wordpress plugins lol). Sure, you don't need to do that, but then again PHP gives you the gun to shoot yourself in the foot with. Basically you can throw away all the "output HTML immediately" stuff of the language, use a template engine and you will be better off.

I have a good friend, full time full stack dev for the last 2 years. PHP + JS, on a 2 man team/project/product.

He is the epitome of the late bloomer programmer (bachelors in CS and masters in econ math), they started using composer 3 months ago. No package.json yet! No make file, no linting, no CI/CD, no deploy. Though they feel that it'd be great to bundle JS files.

No templating engine either, though they are doing AJAX, so no <?= spaghetti.

Probaly on their next project they might venture beyond PHP. Who knows.

We can't force people to start with Rust. :|

Ha, well, we all started somewhere. My first website also use PHP, although I never did the spaghetti, not even as beginner programmer, but then again I learned it differently in school and also did not make use of JavaScript on that website ... Ah but actually that's not true, my first website was HTML, CSS, JS on a file hoster and uploading in the correct sequence to update the links in the files.

> We can't force people to start with Rust. :|

Yep, we cannot and should not force. Perhaps Rust is also quite difficult for beginners to use, even if with that comes great learning. I consider it a fine language. I only wish it had proper tail call optimization. If it had that, I would probably start a project in it tomorrow. sigh.

Good luck to your friend, hopefully they will dip their toes into something beyond PHP soon.

> proper closures

That link is laughable. Author angrily tries to persuade me (the reader) that "PHP doesn't have closures!" while essentially showcasing multiple ways to use them to do everything (and a bit more) that you could with a JS closure. It could be argued that PHP implementation of those is actually better that in JS, since you actually have a choice if you want outer scope variable to be mutable or not and default to the safe option (immutable), but allows you to use reference if you want it to be mutable. It all boils down to the definition of the word "closure", at which point I'm: okay man, PHP doesn't have closures, I won't argue. Now please show me actually important use case where it prevents you from doing FP, because I can list way better reasons why PHP closures are fucked up in my opinion than that.

> generics missing

True. I hope they'll add them eventually. It's not like PHP competition has (or had until very recently), though. And more generally with types: still not there and, furthermore, some relatively recent additions that could fix things, actually are fucked up.

> OOP, but that is terrible in PHP as well

I don't like how people currently tend to use OOP in PHP, because they try to emulate Java, and Java is awful. But actually, its OOP is pretty much fine. The only thing out of my head that actually feels like a problem in this department is absence of polymorphism. Otherwise, especially since traits were added, there isn't too much to complain.

> actually consistent standard library

A myth. Well, TBH, I was often bashing PHP for that as well (and often sardonically joke about that still), but, honestly, the more experience you have, the better you know that, sadly, every PL is fucked up in this regard. In practice, it's not a big problem though. Half of that is handled for you by the IDE, some I solved for myself by basically writing my own "underscore.js" in PHP with a consistent interface. Anyway, these are coder pet peeves, not real technical indications for or against the language (as opposed to real reasons why PHP sucks: i.e. no async/await, parallelism, lots of broken low-level stuff, etc).

> hundreds of PHP open tags

> which you can see in many popular open source PHP projects

This is a strawman. You use people that apparently are not skillful programmers and use the result of them using the language to demonstrate that the language is bad. I mean, Wordepress probably can be used as a demonstration of "success of PHP in the real word", but, personally, I would never use Wordpress, and its plugins are probably the showcase of the worst programming patterns imaginable. No professional programmer that knows what he's doing uses PHP as a template engine in 2020 except for a quick demo, and the ONLY tag he ever needs is <?php to put in the beginning of every file. So, this is not a problem for an actual programmer, who chooses PHP as a language for his project, because, surprisingly, every alternative just sucks.

> any language, that has ...

Uhm, Rust? I'm not sure I'm familiar with that language, because this "any" language you describe surely isn't Python, JS, Java, C++, Go and pretty much everything else people actually use in production. And I wouldn't use Rust for a generic backend for a generic enterprise, at least not yet.

I agree with some of the points you made and disagree with some of the others.

When a language is missing generics _and_ polymorphism, it becomes really cumbersome to implement something like a chain, to which you can add operations and then run the chain. This is only one example, that I recently tried to do and then was surprised at how bad the type system of PHP is. I could not use generics to make operations generic in their return type and also not for the chain. OK, I thought, I can just use Object then. Nope, because the other types are not subtypes of Object. So Object becomes useless as well. Also you cannot write your own super type for this, because what kind of values can that contain? Cannot use generics to express it! All the same problem again. I believe in the end I settled with only using numbers and limiting operations to math calculation. I stopped investigating further how to do it, because I felt, that already enough of my time had been wasted by PHP. At least give me one of these, Generics or Polymorphism.

With inconsistent standard library, I mean for example the naming of string procedures: https://www.php.net/manual/en/function.mb-strpos.php omg, really?! It simply adds more to all the issues, that give me this sensation of touching something I don't want to touch, when ever having to deal with PHP. Of course I agree, that no matter how inconsistent something is, as long as it works, you can build an interface around it, to make it more consistent. However, we were discussing PHP and not user created libraries.

The type systems or at least the existing types of the standard libraries of Python and Java (Haven't used C++ much and JS is .. well, JS.) are much more usable and consistent than anything PHP has to offer in terms of standard types. This is what I am talking about: https://www.php.net/manual/en/language.types.php.

Yes, WP plugins might be a strawman argument, but then again it is one of the biggest parts of the ecosystem of PHP, as far as I am aware. On the other hand, what you wrote sounds also like a "true scotchman" argument ;) as in: "Well, that's just those WP plugin developers. A true PHP developer would never do that." -- Which might be correct! I've yet to meet that developer though. It's probably also WP's fault, at least in parts, because of how bad the WP API is. Everything relies on mutation and global state, which you can magically get into your posts by calling a procedure which accesses that global state in the middle of your theme code, instead of making sure to pass things in. It leads people to do many bad hacks instead of fixing actual problems. Is all that shit actually thread safe? With so much global state attached, I'd not be surprised, if it has complex locking logic somewhere internally, slowing everything down, or even no such thing and simply failing in a concurrent scenario. I do agree with the practices you mentioned, using template engine, only ever needing 1 PHP tag etc. because of better ways how to structure the code. If I had to use PHP, I'd definitely do all that. But then again, why should I torture myself by using PHP, when I know how to handle more elegant languages? I'd probably look for another job, if people told me, that I have to work with PHP all day. Fixing a bug here and there, applying knowledge about how to write safer, cleaner code, is fine, occasionally.

Perhaps PHP acts as a magnet for a lot of inexperienced developers, who "quickly want to do something on the web" and stick to it, because they do not yet realize how bad PHP is or the code they write in it. Then some of those graduate and realize the mistakes they made and improve upon that. However, their better work is drowned by all the shitty PHP code that's out there. Others never graduate from that level and keep producing shitty code.

I agree, that other languages are also fucked up. And at least we seem to agree, that PHP is seriously fucked up too. Perhaps I would say that there are many languages, which are a little less fucked up though.

I used to think, that Java's "everything is a class (or interface)" approach forced me to do OOP right, but then I realized it is not true and that patterns like the decorator pattern are needlessly verbose to express, when I saw how it Python its just a decorator. Now I dislike doing anything in Java. Java did not even have a way of passing a procedure as an argument until some time ago. One needed to create at least an extra inner anonymous class plus the corresponding interface. Looked really ugly.

I then liked Python a lot. Then I also realized its shortcomings (difficult to manage correct types in big projects or even when you did not look at some code for some time, still the standard "use a class for everything" type system, although at least not as encouraged as in Java, only one expression lambdas, not so convenient way moving of code, because of whitespace sensitivity ...). I am not a Python fanboy.

My tolerance for BS in programming languages has decreased over time, having seen some truly elegant and minimalistic programming languages (Scheme and the books SICP + The Little Schemer), as well as more type safe languages like Haskell or Rust and dipped my toes in "Learn you some Erlang for great good".

My projects have become more abstract over time as well. I used to create useful (or me at least) tools for natural language learning with Python and GTK+3, but now I am looking at things like "How to implement a thread pool for my machine learning library?" or "How do I write a macro, that defines procedures in different ways, depending on the name of the procedure to define?". PHP or Python or Java don't even have macros. I would not even ask myself any of those questions and I would continue to learn.

I hear you.. I think it has just became the popular millennial thing todo to bash php.

Just like it's become popular to attribute things you don't like to millennials, when you have no idea if they are millennials or not.

Reply on news.ycombinator.com