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?
TL;DR: Log impure actions. If you minimize and group side effects, you don't need to log as much. Pure functions can be recomputed any time if you know their inputs.
Event buses can be useful, but it's hard to look at an event being published and know what it does and whether it's important. Whereas the importance of a logger call is usually pretty clear. Logs are rarely load-bearing, but an event can mean anything.
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.
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.
The Go library's standard AST package[1] similarly stores comments and whitespace information. It has to, since it's used by gofmt, and you wouldn't be very happy you lost comments when formatting your code.
I'm Evan Shaw. I have been writing high performance, scalable backends and RESTful APIs in Go (Golang) for the last five years. I also have strong C and C++ skills, as well as experience with a variety of other languages and technologies. I'm good at diving into and making sense of unfamiliar code bases to add features, optimize, or refactor.
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.
It used to be:
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.