edsrzf

The world that PHP grew up in has changed. The language and community have matured, and in the process PHP has lost most of its competitive advantage: low barrier to entry.

It used to be:

  * Moving from static HTML to dynamic server code was a matter of changing file extension and adding PHP tags.
  * Many shared hosting services supported PHP.
  * Deploying was a matter of copying files to the server.

Projects that started from HTML + PHP tags grew and became unmaintainable messes. The PHP community learned from this and evolved in a different direction. You can still _write_ PHP code in the old way, but it's strongly discouraged and (rightfully) seen as a bad practice. You don't even use PHP as a templating language anymore. Symfony and Laravel have their own templating languages that dynamically compile to PHP.

Modern PHP code looks very much like Java or C# -- classes, OO design patterns, and so on. Except in most ways, it's worse than Java or C#. Why would anyone start a new project in PHP?

Deploy models have also changed. You're usually not copying files to servers, but deploying Docker images or other formats. PHP has no particular advantage in this new world.

If PHP wants to turn things around, it needs to figure out what makes it unique or better than other languages. Right now, there's really nothing.

I find it bizarre that urlscan.io displays recent scans from paying customers. I assume GitHub is large enough that they have to pay, anyway. If they're not, who is?

Honest question: what science? Any good papers you could recommend?

After a quick search it seems that NPS originated in a Harvard Business Review article, which I don't consider a credible source of scientific results. The scientific papers I'm seeing mostly seem pretty skeptical, judging from the abstracts.

I live in Auckland and the tech scene has really been booming in the last year or two. Obviously it's no SF bay area, and there are now companies struggling in the current economic conditions, but it may be worth another look in, say, a year.

This is pretty interesting and useful. Now where are the details about how to get ElasticSearch to behave this way? :)

The problem is that there actually are patents covering GraphQL. So anybody who writes an alternative GraphQL server implementation is potentially infringing upon those patents.

The issue with the GraphQL spec is that people actually want a patent grant for alternative implementations, but there isn't one.

I normally hate it when people immediately trot out the old "premature optimization" quote, but it really applies here.

Please don't go around naming all your returns just because today's compiler happens to generate better code with them. This is a compiler issue that I'm confident will be fixed one day, especially if you do the right thing and file an issue.

But by all means, if you're profiling and your inner loops are actually slowed down by this, then make the change. And add a comment so that someone might be able to change it back some day when the compiler's improved.

Could you please link to some docs for the cached flag you mentioned? I can't find anything about it.

I think calling it a "mess" is hyperbole, but yes, it's true that it has shortcomings and may be deprecated and replaced.

One non-obvious downside is that the Go 1 compatibility guarantee doesn't apply to struct literals that don't use field names. (I suspect you're aware of this, but other readers might not be.)

So it's possible that a future version of Go could add a field to some struct you're using and your code will stop compiling when you upgrade. It's an easy fix, of course, so it's not that big of a deal, but it's worth realizing.