Hacker News Reader

Comment by jonny383 | Hacker News Reader

PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in.

I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter.

One thing that still sucks is package management / composer.

View on HN

> One thing that still sucks is package management / composer

What about Composer? Sure is in par with Slack when it comes to memory usage, bit it's functional and feature rich. v2 has partial offline support, faster downloads, etc. (https://php.watch/articles/composer-2).

Composer IMHO is one of the best dependency managers for any language out there.

Disclaimer: the link above is a for a site I maintain.

Having to setup 10gb swap to get it to work is pretty awful.

I've never had to setup swap for a composer install on any machine with >1gb of memory..

composer is so slow tbh. It takes ages to download package and well requires me to setup swap even when i have 4 gb ram in server.

Have you used prestissimo? It allows parallel downloads and makes the process much much faster. https://github.com/hirak/prestissimo

Yeah, using prestissimo makes package installation sooooo much faster. My Laravel project with over 100 dependencies downloads in under a minute, where it was like... 10 minutes before

I'm not sure how it compares, but an alpha for Composer 2.0 was released last week[1] and the release notes seem to imply that it runs in parallel by default now.

> Added support for parallel downloads of package metadata and zip files, this requires that the curl extension is present and we thus strongly recommend enabling curl

1: https://github.com/composer/composer/releases/tag/2.0.0-alph...

I've never had issues with this, what sort of maddening package management are you doing? Are you just talking about installs that's only an occasional hit anyways...?

The speed is the main reason I decided to experiment with building a Node.js module last week that allows you to use PHP as a templating engine for Express apps: https://www.npmjs.com/package/php

I had guessed that PHP might be faster than mainstream JS-based templating systems like EJS and in my tests so far in an app I'm building it appears my guess was right. Even with the overhead of serializing and deserializing the data model from Node to PHP, on one of my more complex templates the PHP version outperforms the EJS version by around 10%.

Did they seriously take the "php" namespace in the registry?!?! That shouldn't be allowed.

Originally the php module on npm was used by a separate project that attempted to implement a PHP parser in JavaScript for Node.js, but was never finished. One work in progress version was published, then the project remained stale for 8 years. I spoke to the owner of the package and asked him to transfer it to me and he graciously agreed.

Is 10% enough to switch though ?

This is honestly the first I’ve ever heard anyone complain about composer. Having experienced a number of other package managers, composer is by far my favorite. Like have you spent any time with npm? Composer is light years ahead in reliability and expectations matching reality.

The amount of fighting I've had to do with setting up NPM for legacy applications, or with any sort of virtualization is insane. I no longer set up Node/NPM on anything automated without NVM, since they seem to drop support for old packages at random. You have to jump through a ton of hoops to make NVM play well when it's effectively installed by root but ran by another user within the container. Running NPM in a unix VM on Windows means you have to update everything with --no-bin-links since symlinks aren't well supported, and there is no fallback. It's baffling that they haven't had some sort of manual copy management when a symlink can't be created.

Meanwhile, I setup composer in a docker file in 4 lines (download, run, move to bin, cleanup), and it works everywhere for any user, respects permissions, etc. I don't think I've run into a single error on composer that wasn't something like a mis-typed command, package, or a host being down.

Funny! I'm dealing with a very similar problem right now. We're trying to port our CI workflow from DroneCI to GitHub Actions and our private NPM packages have been a literal nightmare. In comparison, our private composer packages worked fine with very little fuss.

What are the "modern" features of php? It looks like it's trying to shed it's dynamic nature and add types (with annotations etc). Also frameworks like Symfony / Laravel look more and more like java web frameworks to me. I'm not saying this is necessarily bad but there's nothing modern about types. Also, might make more sense to choose java if you need types.

The biggest advantages of PHP over Java are build and deploy times, so coding a php app is much more rapid. You can test your app right away, even after a single line change and get immediate feedback on the screen, which I think is important in web dev because a lot of it is visual. The other advantage is the run-time. Java has a slow startup time and when you redeploy then you need to stop/start your entire app. With php you can fix / update one part of your app without the need for a server restart. Another advantage is that php runs each request with a clean state, that means all the variables get destroyed after the request, helping to avoiding memory leaks, and possibly issues with concurrency which Java exposes. Types are great, but sometimes they can get in the way too and slow you down, (I still haven't figured out what those <funny> types mean). In all, development in PHP is so much faster and easier over Java.

> Another advantage is that php runs each request with a clean state, that means all the variables get destroyed after the request, helping to avoiding memory leaks, and possibly issues with concurrency which Java exposes

Care to elaborate? How is that different than java web frameworks?

In a Java web framework, your classes have static fields, so user code or any library can assign values to them.

Language support for a request being ephemeral is far more effective than frameworks proposing it as a good practice.

And everyone working on PHP libraries in C know what a request is and that it ought to be ephemeral, so even outside the core language there's a clearer understanding.

> Another advantage is that php runs each request with a clean state

PHP apps are almost guaranteed to be "stateless", thus scaling up and down is quasi-painless also.

OTOH, sometime you need state, then you feel stuck with a half-finished language.

What are you using state for in a web app or API?

Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting languages working with http servers), it's not the only use case.

When the only place where you can put state is the database then every piece of state is written in the database. Which lead to intelligent individuals (no pun/offense intended) to write clever piece of infra such as Redis. The truth is, for 10 Redis deployment there's 7 (8? 6? Well, a substantial part) where a long living process holding little state would have done the trick. Now you need to deploy, maintain and scale Redis too.

What's wrong with using session variables for maintaining state?

Session variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)

Exactly.

I see downvotes on my GP post, I'm simply stating the fact: if you need state for a building a powerful webapp then obviously there's better runtimes that PHP+Apache, I don't see how one could disagree with that statement, apart from not having sufficient experience in that matter.

There's plenty of good reasons to counterbalance that fact thought, PHP has a very good ecosystem, multiple mature/powerful web frameworks, and cheap/abundant workforce. But it lacks a state holding runtime and for the most demanding applications it's a sufficiently big technical hassle to encourage seeking other runtime and/or language.

Ah, derp. Yeah you're right.

Yeah, but having to use Redis is a must for any web app/API that grows. So all PHP is doing here is forcing you to adhere to best practices of shared-nothing architectures early on.

Personally, I use it for counting concurrent users.

Session management. Logins and other crap.

Should be distributed anyway, Redis or something like that.

If you really need a shared memory pool between requests you can use APCu.

Recently did some nodejs work. It was surprisingly fun. There are A LOT of sharp edges, but working "closer to the metal" is great. Fast deploy and startup is GREAT.

Am an early, vocal Java partisan. Java world HTTP servers fell into a ditch and kept digging. Servlets and JSP weren't too bad. Wasn't crazy about Tomcat or NetSuite, but ok. Then it just got more and more nutty. J2EE, Spring, XML, schemas, annotations, etc.

There's nothing about Java that rules out simple and quick. For medical records stuff, I replaced a huge J2EE/BizTalk style backend with stupid simple process runner for stupid simple tasks. Think Windows OS Task Manager running AWS Lambdas.

In conclusion, I remain sad about the enterprisey detour Java took.

For what it's worth, Java has hit code reloading, even though it doesn't work perfectly all the time.

For one step beyond edit/save/refresh try repl development in Clojure where you get the benefits of the JVM without the startup penalty. After the initial boot, that is.

Whatever the language there is always a group of people slowly turning it into Java. It seems almost impossible to say no to new features.

Dart is another example. Not exactly Java but certainly built in its likeness. What is it with aping Java's verbosity which, to many, is an embarrassment?

Symfony is directly inspired by Spring, and Laravel is an based on Symfony, so yes, that's the direction they are going.

I kinda hate that trend, but it satisfies a cross section of devs who want "serious" enterprise looking code base but don't want to move from PHP. It's still noticeably different from Java, even with the heavy typing and all the inspiration.

Laravel uses some Symfony components, but it isn't based on Symfony. Laravel was heavily inspired by Rails.

> Also, might make more sense to choose java if you need types.

Java is not a replacement for "PHP with types". There is currently nothing you can deploy as easily as a PHP web app. The operational overhead is very low because cheap, robust hosting providers have decades of experience with the most typical LAMP style stack.

I would also disagree in terms of language features. Gradual typing through type hints (and other 'on demand'-style consistency features) is a very ergonomic way to introduce consistency during development (plus implied performance optimizations). You write in 'free-dynamic-mode' initially and then add type hints where they make sense bit by bit, typically in function signatures. There are many examples of this in the (semi?) dynamic world.

You couldn't be more wrong about the ease of deployment.

PHP is one of the hardest things to deploy. You need at least a web server and a process manager. Most popular choices are nginx + PHP-FPM or Apache + libapache2-mod-php.

You also need to learn how to properly configure both of them, since both have like a million options, and default installation doesn't work in a lot of cases (e.g. uploading of files larger than a few MB).

If you don't want to use libapache2-mod-php, you will have to figure out how to deploy two different services, which makes things difficult in a Docker environment.

---

As opposite to that, deployment story with Go, Rust, and similar compiled-to-a-single-binary languages, is a lot easier. Just drop the binary to a server or add it to a Docker container.

Many smaller PHP web sites are deployed on VPSes and managed with CPanel or Plesk control panels. None of what you describe is necessary. The web server is pre-configured and PHP settings can be easily changed. Even setting up PHP on Ubuntu or CentOS is a 5 minute job. Tweaking configuration settings for max upload, max post size, etc. are very common and well understood.

Once everything is in place, most deployments are as simple as copying the new build over and changing a symlink. No process restarts, nothing.

"Easy to deploy" and "Many cheap webhosts are already configured for it" are still very different things. I never found it helpful to conflate them. For example, a VPS with CPanel/Plesk is quite the dependency. As is "a cheap PHP webhost with servers configured for your PHP scripts".

I look at it this way: PHP apps are so easy to deploy, it's a commodity. I run my own dev servers then move them to VPSes, billed to the client, for deployment.

Seconded. I was left scratching my head for a long time trying to work out why php-fpm, when reloaded via systemctl on CentOS 7, was not setting-up /var/run/php-fpm.sock with the correct ownership. I eventually had to write a shell script to resolve the issue. The version of php-fpm in question, by the way, was a more up-to-date version than the CentOS 7 default. Anyway, that's just one example of how mdoern PHP deployments differ from the over-hyped static deploys of yesteryear where you just FTP a bunch of .php files into your DocumentRoot.

For reference, related php-fpm config directives: listen.owner, listen.group, listen.acl_users, listen.acl_groups

And probably some SELinux config as well if the installed php package doesn't have them.

A lot of PHP work is digging around in Wordpress themes & plugins with a bunch of other (third-party) themes and plugins installed, some of them paid which can add another layer of annoyance to testing and deployment and such. Hosting's usually some managed thing rather than anything under your direct control, and usually quirky or limited in some way or another. It's a pretty miserable ecosystem to work in.

PHP itself is, secretly, actually kinda OK. Some major codebases written in it are no fun at all to work with, including the 800lb gorilla that is WP.

Just when you thought it couldn't get worse there's Magento.

Interestingly enough, there was a commit to WordPress core to bump the recommended PHP version to 7.2

If users are running below that, they'll got a notice telling them to contact their hosting provider and get them to upgrade.

https://twitter.com/schlessera/status/1270788445808537604?s=...

Combined with the JS work going on in WP, it's going to be an interesting 5 years I think. I would not be surprised if a lot of WordPress core starts to get rewritten. I know many of the large plugin authors are already pushing full steam ahead with modern PHP features and dropping support for old versions. Now that core can "take the blame" it's a lot easier to justify and I don't blame them.

You don't know how good you have it with composer until you try other package managers.

I took a look at it about 1,5 years ago while having worked with very early versions (2, 3 or 4?) as a teen. It was the first language I put some effort in to learn more about. Not that I remember too much, but it is a complete different language by now.

I would have thought only dinosaurs like Algol or Fortran can be that old.

Composer 2 is coming, and so far it’s shaping up to be vastly improved.

Also, many people are still using that ‘fractal of bad design’ article from years ago to bash on PHP, even though a number of the assertions are no longer applicable.

Years ago on GitHub when the new Composer logo was just pushed, I commented (on the relevant commit) that it looks more like a "conductor" than a "composer" or perhaps they meant "composer/conductor" which isn't uncommon in the music industry. My comment was promptly deleted. Oh, well.

The point of calling a "fractal" and talking about the "design" is that while you can only look at the surface in an article of reasonable length, it points toward strutural and systemic failings within the language itself.

The problem is that PHP is built on bad foundations and while many of the superficial problems can be mitigated, the underlying foundations can't be fixed without breaking changes. (Or, as Python proved, even if you make breaking changes, you may still not fix many core issues.)

All languages get this way over time, usually as decisions that made sense early on become baggage. But when a language makes poor decisions early on, it accelerates that timeline.

yet you don't see articles about how bad python is, it still receive lot of praises and much love. This is telling a lot about how fair are some comments about PHP.

Python gets love for a number of choices it made right early on, and that its core langauge is obviously well thought out. Even very old Python is generally readable and clear; except for some colons, it looks like pseudo-code.

This is the same reason I think Java gets a lot of respect: they had a few core language design ideas and built the language around them. People will say COBOL's syntax is horribly verbose, but you can see what they were trying to do.

So you might dislike those choices, but your critique becomes about the consequences of the choice, which implicitly is something the person making it can't know at the time.

With PHP, people are complaining that users have to live with a whole host of accidents or poorly thought out ideas that are now baked in.

Other languages get criticized for that, too. Python was hammered over their poorly thought out support for unicode in Py3K[4], which blocked many distros from supporting it until around 3.4. (And, generally, most people agreed Python3 was a mess until ~3.6 and the whole transition is widely seen as a case study in what not to do.)

Java gets dislike for similar bad choices. Java's Date class is pretty notorious[2] as a how-not-to. Java arrays are covariant, and it was staring them in the face as they coded the ArrayStoreException[5] to deal with otherwise perfectly valid assignments. But the .NET one-upped them by knowingly making their arrays covariant, despite knowing it was a problem in Java. (Probably to make it possible to run Java on the CLR.)

To pick on Javascript, critiques of promises[3] center around the fact that people proposed using monads, and the designers brushed it aside as theoretical. The famous 'wat' presentation[1] talks about behavior in Javascript (and others) that is magical and bizarre, and it's principally because Netscape has some neat ideas they didn't think through.

[1]: https://www.destroyallsoftware.com/talks/wat

[2]: https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-...

[3]: https://github.com/promises-aplus/promises-spec/issues/94

[4]: https://click.palletsprojects.com/en/7.x/python3/

[5]: https://docs.oracle.com/javase/7/docs/api/java/lang/ArraySto...

Python received much of its latest praise from introductory level college students that haven't done much programming other than "import numpy". I've used python and sure i like it better than other "bad languages" but when you look around in the real world you see that it's not the best or the most popular choice.

- cloud/ops space has moved to Go

- Java/C# are overall better languages and more productive environments than python for large scale services.

- A million websites still use php and the community is thriving. Billion-dollar companies use ruby to transact billions of dollars (stripe,shopify).

- Js is eating the world

Python found its niche in AI/ML space and sure is a great language but that's it?

All languages? Ruby doesn't seem to have suffered this fate. Still as elegant and full-featured as ever. Clojure just goes from strength to strength.

> not so bad to work in

Yeah, if you know it well enough, maybe. It's horrible to work with as a newcomer or someone who only needs to touch it once in a while.

I'd be interestd to see how much faster Laravel is compared with Rails and also how they compare in memory usage. Last time I looked on Techempower I was surprised to find Laravel performing more slowly than Rails in some of the examples.

> One thing that still sucks is package management / composer.

How? I mean, what are the problems with it?

Personally it's mostly composer update and require that fail in docker or a VM because of the memory requirements, otherwise it works well.

Also I hate json for config files because you can't comment things.

To be fair most package managers suck.

What do you dislike about composer?

Reply on news.ycombinator.com