Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
PHP files can be deployed independently, swapped out or updated live.
No building/compiling of the php files needed.
A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers.
Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.
Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.
Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
Which becomes a security issue due to accidental endpoints or uploads becoming endpoints. Or becomes a mess of imports. Either way, PHP frameworks often end up with a central router anyway.
> PHP files can be deployed independently, swapped out or updated live.
Which means some people try to do that the naive way and end up breaking a few requests that happen during the deployment.
> Can be as easy as editing a php file in notepad and dropping it on a ftp server.
Even worse, Tumblr had an incident where they accidentally changed <?php to i?php (my guess would be editing directly on the server with vim?) and exposed not only their source code but also credentials.
It would have been possible for tumblr to avoid this with good development practices (don’t edit code live, don’t bake credentials into code, etc) but I imagine there was a culture of doing it at the time.
I don’t think it’s fair to tell developers “use our language, it’s super easy!” and then expect them to discard all of those bad habits as they start putting things in production.
These are things very specific to PHP. Yes, there are language-specific gotchas in many environments. But I'm criticising specific things that do exist and that I've seen causing issues in real deployments. Things that make PHP accessible make it also an excellent footgun.
The difference is in handling though. If a config file runs into a BOM, it's likely to tell you on which column and row (0,1) it broke. Same when you compile something. Or it may even recognise the BOM and handle it transparently.
PHP does something different. It outputs it early and when you try to send a header it tells you that's too late. That error is in no way helpful to you at that point unless you already know about this issue, and it won't even help you figure out which file was affected. That part is specific to PHP.
I'm not familiar with Lua pages, but all I can find uses a http / fastcgi server with explicit routing. ASP classic has its own terrible ideas and it's close to death now - 2025 is the last year MS committed to support it, so I don't really think of it as an interesting language anymore.
Of course. That's the only reason to invent languages: to take care of stuff people are not good taking care of, and move the work to the computer, allowing us to work on the level that we're good at taking care of.
Else we'd all be using assembly.
There's absolutely no pride or glory in doing things nicely and securely that the computer could have automated in the first place.
Anything the language allows that it could refuse while allowing devs to express the same features, and that results in bugs is a mistake in the language (e.g. the sorry state of strings in C).
Incompetent people will create incompetent things regardless of the tool. Simpler tools lead to simpler messes while complicated tools lead to complicated messes.
I've seen an attitude that people think they can inoculate themselves from inept programming by using obtuse frameworks as if martin-fowler-speak acts as a drill sergeant making disciplined coders out of the herd.
But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never.
Instead it leads to larger, less maintainable, more convoluted messes that have to be trashed quicker. Giant ceremonial cargo cult style monstrosities with huge circuitous logic - 4, 5, maybe 6 layers, a router calling a controller, calling a service, calling a provider, calling an event model, which runs a single if statement ... as if that's how we protect ourselves against incompetence.
These approaches just lead to wasteful projects where they end up rewriting the whole thing in whatever the framework/language de jour is instead of writing easily maintainable, quickly understandable code that's designed to work for the next 10 years. I've talked to many programmers who are embarrassed by the language they are using ... wtf is that?! They've turned programming into fast fashion.
Then people like to ask what someone's favorite language is, usually when they first meet them, as a social cue, as if we are a bunch of highschool kids following pop music. I mean what on earth... we're supposed to building the future here, not running around like a bunch of spastic fanboys from platform to platform, just to mess everything up all over again in bold new ways using slightly different syntax.
The best thing to do is give people the least abstract thing with the fewest conformity requirements ... essentially make it open ended and then the messes are easier to spot and easier to fix. You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?)
Anyway, new shiny fancy tools with GoF buzzwords won't ever fix incompetence, it'll only make it worse.
>Incompetent people will create incompetent things regardless of the tool
Which is neither here nor there.
For one, it ignores the pragmatic issue, that very competent people (the very people that built the foundations we all work on even) will still make lots of mistakes, even trivial ones, but with severe consequences (e.g. buffer overflows) when the languages don't prevent them.
If only it was just "incompetent people" that made mistakes...
>But after 20 years of bouncing around startups I've never seen the intended results actually happen a single time. Not even close. Not once. Never.
You weren't looking hard enough. Every day millions of programmers don't make "buffer overflow" errors for example, that otherwise they'd have made, because they work in languages that don't allow them.
And they'd have made those mistakes regardless of their programming chops. The best programmers, people that run circles around you and me, still make those mistakes.
The way I think about it is if you think through the entire software stack and all the instructions that get executed across all the machines and their operating systems and programs running underneath before things even get to your code and then all of the standard library and framework code plus your code. For just a simple loading a web page that is a trillion piece jigsaw puzzle and every single piece has to line up or the whole thing just doesn't work.
We do the humbling and the remarkable every day and trillion piece jigsaw puzzles are no joke. It's the exception that you get it right. Given all the pieces required that's a lot of sources of potential entropy and the more it increases the more the system destabilizes and/or becomes unworkable. Things like languages, libraries, frameworks etc make certain decisions on your behalf with the goal to contain some of that entropy within their given abstraction.
Those mistakes aren't easy to spot or easy to fix.
It's about giving code sunlight so that action at a distance and other kinds of magic don't hide errors making them harder to find, get in your way of fixing them, making reproducibility a mess and confirmation simply guesswork.
Its the restrictive design trend of crippling languages which needlessly prevents the sunlight effect from happening along with "information hiding principle" gone completely amuck with the information successfully hidden in dozens of innocently named files with listeners, observers, watchers, triggers and who knows what else being mysteriously called based on reflective programming so not even grep will help you.
Static code analysis and seamless navigation is totally a thing of the past.
Instead, the errors will have the stack of the error handler and that's it. The debugger is useless because stepping through the code is 98% scaffolding.
All these fancy tools bludgeoning any introspection or diagnostic system so the only remaining workable debug system is printing debug variables and rerunning the code like I'm programming on a TI-81 (only that had debug and release run modes...features I can usually only dream of these days) Progress! Welcome to 2019!
It's crazy. This isn't how maintainable code is written
The amateur-to-expert ratio of any topic is directly proportional to its popularity. It's why popular things are polluted with well-intentioned bogus information.
You won't get 4 folders with 26 files handling simple tasks like uploading images to an S3 bucket (saw this huge mess just last week and guess what?! It's broken. I know, surprising right?)
You can see right here on HN anytime a post comes up about using a cloud provider someone advocating putting a layer of abstraction over the provider’s SDK to prevent “lock-in”. As if the CTO is going to one day move their entire infrastructure because a developer promises them they’ve abstracted their code perfectly.
So instead of just being able to read the docs of the SDK, you have a custom QueueManagerFactory that gives you an AWSQueueManager that wraps the Boto3 AWS SDK just so one day if the company decides to move to GCP, someone can write a GCPQueueManager.
See also, developers who think they can effortlessly move from their company’s six figure Oracle installation to Postgres because they used the repository pattern.
Suggesting to just manually go in and change the touchpoints over if the time comes is seen as uncouth, as if we're in an Oscar Wilde play and I'm some unwashed ruffian from the alley.
This is despite the fact that if you do it it'll take 40 minutes manually versus 10 minutes if the Rube Goldberg abstraction machine works as planned (it won't).
Since there's only about a 5% chance (max) that going from say S3 to Azure will ever happen, the extra cathedral of abstraction saves an actuarial 1.5min of dev time.
All that only for 2-4 days of development to make it and the added runtime at every request for the convenience. Genius!
I think it depends on whether the library you're using is well designed and doesn't require contorting code around it. If it's a simple integration I don't see much of a point in abstracting it but if dealing with the library is painful on some level you'd maybe get some benefit from doing so. That being said this is somewhat orthogonal to the issue you're describing
I do have a *Utils module to wrap some calls to the AWS SDK but it’s not to protect from “lock-in” it’s a classic DRY principal of putting a code snippet in a function so I don’t have to remember how to do it every time.
A poor abstraction is always a poor abstraction, but a good abstraction can not only isolate your components from change but also provide a better interface.
I'm not going to write raw HTTP requests to S3 in every place in my code that I need to read/write objects from there. What I'd rather have is a simple abstraction with methods like get(id) -> obj and put(obj) -> id.
Seeing that you can still use the same SQS API from 2006 and that in 2018 AWS still supports SOAP of all things for S3 (https://docs.aws.amazon.com/AmazonS3/latest/API/APISoap.html) , I would much rather be able to just look at the SDK to see how something is used than having to try to debug through an abstraction that the “architect” who was at the company years ago, put in a custom Nuget package trying to abstract the API and imposed s “standard”.
Yeah I have been through that before where the architect of the company wrote his own bespoke ORM, logging framework, etc. and he was the only one who knew how it worked.
> Incompetent people will create incompetent things regardless of the tool.
I think I'm justified in calling myself competent. Nevertheless, with the wrong tools, the things I build are definitely worse than the things I can build with proper tools.
You've never had the reaction of "what on Earth is this crap doing?" And looked at the tool and been like "omg what kind of flunkie wrote this" and then end up forking the project, doing negative coding, fixing the issues, and then having to address the issues threads on GitHub yourself because the "maintainer" stopped responding a year ago?
I mean it's just a huge waste of time. These modern stacks (mostly js) are crap code all the way down.
It's made me want to return to Perl because honestly, it has everything and is somehow mostly idiot free. I probably should...
I have never had that reaction because frankly, I don't think it's appropriate to call people who know less than I do 'flunkies'. Sometimes, I like to approach the situation with humility and ask questions. Other times, I quietly ignore the situation. And other times, if it's a particularly egregious error, I'll write code and explain why I think it is better. But I never call someone a flunkie because words and attitudes like that are incredibly rude and toxic.
The moment you convey that sort of attitude, two things happen. The person you called a flunkie will not learn a goddamned thing from you. And, if they happen to be right, you won't learn a damned thing either. Great choices.
Using failure as infrastructure at a fast paced startups with shoestring budgets and then taking the resources to afford the luxury of a nurturing and caring mentorship for every teenager with a computer is a disaster.
However, you can pursue a culture of excellence without being rude and toxic. You can be kind and humble without coddling.
Edit - I should have added that if teenagers with computers have a good attitude, feel engaged and feel cared about, they can be extremely productive members of a team. And they have a tendency to grow into really amazing engineers (and fine people).
I parsed it wrong. I thought you essentially said "the things I build are definitely worse then relying on a collection of random internet dudes code through npm." But yes, GNU make, emacs, yacc, lex, bison, ar, nm, there's lots of great tools.
I agree with you 100%. I just want to add that this over complication of things is not just an IT thing. Try taking up a new hobby whether it is cycling or surfing. In no time you will have the "experts" telling you that a $200 bike is useless and is a waste of time. You need to spend at least $5000 to be part of the club. Now if you are a "professional" cyclist then spending a lot of money on a bike makes sense. For the rest of us, just getting on a bike for exercise is enough. I think some people just need to show they are better and know more. This is where some of these complications come from. Sometimes, of course, it is just plain incompetence.
It is much more of a lifestyle thing, you're right! With all things, I'll get the functional adequate version and use it until it no longer functions. Sometimes I'll buy multiple so as not to be bothered to repeat the shopping process when one wears out (I own many unopened identical pairs of shoes and glasses for instance)
Brands generally mean nothing to me, new consumer technology I'm generally not interested in, and I have no issues say, taking the bus and getting reading done instead of rolling around in say a Tesla (despite the fact that buying one is well within my financial reach). I honestly don't care in the slightest.
So yes, it's probably a larger personality disposition which manifests itself in this particular way moreso than it is a morsel of objective rational reality.
The people I lambast are the same ones with things like smart speakers and wifi connected refrigerators (I use an old minifridge and I prefer it). It's just a lifestyle; not some objectively poor use of money and time resources.
That's a nice perspective and it helps explain a lot, thanks.
We created higher level languages to reduce time spent coding. We wouldn't be using assembly.
It appears that we think about different terms when visualizing what "incompetent" means.
We create languages to tackle different sets of problems, and we want to minimize human error - that part, I believe, we can agree on.
However, if you perform "SELECT * FROM mytable" (table grows indefinitely) and then sort / limit in the language and not database - you're incompetent, you simply lack knowledge and you didn't even think abstractly what can happen by doing so. There's no language out there that can teach you "right tool for the job" or "keep it simple" or "should I do it, maybe there's another way, did someone else have this problem?", no matter what wizard creates it.
We will never weed out incompetent people by creating languages and a language shouldn't cater to a moron.
Totally disagree with this parental assessment of a language. It certainly doesn't apply to spoken languages or most ideal communication modalities. I think you want to fix your
problem: which isn't a problem for someone else. See this everywhere on this site: SV kultur and the catch22 pronouncements of the correction generation.
Exactly. That’s why most languages, for example have reasonable semantics for strings that don’t allow you to copy a string, overwrite memory and corrupt the call stack.
In a complex product (as in, most professional settings or large services/web sites) the PHP I've seen is grossly complex, and not intuitive—especially WordPress deployments.
Dev teams have to perform all kinds of gymnastics with the PHP code to get it to do what they want, and it's just a flat out nightmare that I've made sure my boss and colleagues know that I have no desire to work with it.
It always ends up a house of cards and full of vulnerabilities so that something is regularly getting exposed that allows at least editorial access. Security issues that should otherwise be no problem.
God knows how many other vulnerabilities exist. Every single server I've ever had has had bots and crawlers polling for common PHP files in an effort to exploit them, should they exist.
I just don't like having even the chance that my back-end source could, for want of a single character, spill out to a web page upon request.
And then there's performance...
Anyway for simple things, sure. For things that don't require much security, sure. For anything else... it's not for me.
I've done enough WP to certainly agree with you. However, I don't think it's fair to judge PHP by how WP has abused it.
WP problem is its desire to sacrifice code quality and best practices for market share. That is, many things don't get refactored (into something OOP based) because there might be backwards compatibility issues. Again, this isn't PHP's fault.
I did one project in Laravel. I was impressed. That said, it takes WP to the opposite extreme. That is, it is has little regard for backwards comparability. Finding answers / examples via The Google is messy and frustrating, at least for someone who was new to Laravel.
I like that it's forward-thinking, but it moves so fast that it has negative impact on user (i.e., dev) experience.
You can create a mess of code, open security holes, and/or be hit with ‘gotchas’ in any web framework
Yes, but the holes and gotchas are worse when they are baked into the language. The thing that Golang gets right, is that the developers are willing to eschew features to avoid gotchas. It's like other languages are sports cars with sexy lines and fancy features that everyone wants, but have to spend more time "in the shop." (An analogy for in the debugger.) Golang is more like a base model Toyota Corolla with a manual transmission.
Not sure what PHP is like. Maybe some sort of modder car. Like Perl and Ruby, PHP grew by readily adding features in response to demand. In that way, it's the opposite of Golang.
PHP is much less complex than most.
That depends on what level you're looking at. PHP is one of those languages that has a lot of complexity baked into it in the form of language design warts. In order to make it a nimble language, you have to ignore/eschew parts of it, and stick to some "good parts."
no, seriously, the old dynamic script as program requiring a web server needed to be configured properly to avoid leaks of a thousand faces .. thanks but no thanks
Just use Laravel and its eco-system, it's just as easy or easier to setup than Flask and easily production ready. This is an old-take on PHP and no longer true in 2019.
This also leads beginners to overestimate themselves, resulting in piles of live, insecure PHP code.
Just because it works, doesn't mean it's good or secure. And while it's very easy to see if something works or not, it's very hard to see if something is secure.
I think you indicated the problem. You can be secure or insecure in just about any language, but the barrier to entry is so low in PHP that it is easiest for beginners to do a lot of damage while still launching an app.
I’d rather there be some learning curve so people understand what they’re doing (or not doing).
Routing is a feature because you can express more complex semantics. Most php apps depend on Apache specific .htaccess files to handle redirects and other routing, and it becomes a mess quickly.
PHP files can be swapped out live because many CGI wrappers don't cache anything in memory, which means at high strain you start dealing with disk load, file locks, etc.
There are many other languages which also don't require compilation, often at the trade off of less performance. Some really clever languages let compilation be an optional step.
A single layer means your frontend logic, data models, and database access all run the risk of being one giant mess. Sure other languages run that risk too, but it's especially prevalent in PHP.
PHP can extend itself - it can also be used to download attack vectors and execute them directly on the server with no concept of code signing. Other languages offer powerful facilities for remote updates if they're desired, but that's usually not the best approach for Web.
You can edit other languages with notepad too.
Being able to deploy a single endpoint to a live server and hoping it doesn't cause problems sounds like terror.
goes to widgets.php too, with its PATH_INFO set to "/you/can/have/multi-segment/paths", but I don't usually go that far. Usually the script name roughly corresponds to the name of a table (or database view), and the PATH_INFO corresponds to the primary key.
Caveat: there are cases where this behavior has resulted in vulnerabilities. e.g., CVE-2018-10661[1]. So if you ever want to implement your own auth module in apache httpd you should be aware of this.
If I'm reading this right, this is something that sounds a little bit like Apache MultiViews but isn't.
1. It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin. This isn't how MultiViews works. The file must exist, and it must be in the document root. A request to /foo won't work unless /foo.php (or foo.html, etc.) exists.
2. This rerouting was supposed to happen only for admins, but the authorization failed, due to a different bug, CVE-2018-10661.
3. The attack then depended on a bug in dbus, CVE-2018-10662
4. Finally it depended on a third flaw, CVE-2018-10660, having to do with shell-script injection.
So I don't think any of this should scare away a person from using MultiViews for .php scripts, which makes setting up clean, maintainable routes easier than any other technique I've seen.
> It doesn't sound like they were using MultiViews at all but some rewrite rule that rerouted all requests ending in .srv to a shell script in /bin
The request to a.srv (in their example) was only authorized because a request to /index.html/a.srv looked like a request to /index.html to the auth module because the auth module did not check PATH_INFO. The request was then passed to the ssid daemon (not shell script) over a UNIX socket.
a.srv ended up in PATH_INFO because index.html existed.
The developer(s) of the auth module only checked SCRIPT_NAME and index.html was valid for unauthed users.
MultiViews doesn't let HTML files have PATH_INFO by default. Only files that Apache considers "scripts" get PATH_INFO (e.g., .php). Therefore /index.html/a.srv would normally return 404 Not Found, even with MultiViews on.
They could have done further configuration to let HTML files take PATH_INFO, but this Rube Goldberg machine of multiple mistakes bears no more connection to MultiViews than mod_rewrite. In fact, I see no mention in the article of MultiViews or its module, mod_negotiation. So how do we know they were using MultiViews and not mod_rewrite, which people use much more often for this amount of indirection?
Either way, this exploit is impossible in the original suggestion, to just use MultiViews with PHP files to remove the ".php"
You know, to this day, if someone came to me and said "we want to run a site for five years on an LTS Linux distro release on a fairly weak machine, with auto-updates to system packages but no other maintenance intended. We're not gonna bother with monitoring or whatever. It's mostly static but it'll have a small dynamic component, say 500 LOC worth, maybe. If we ever have to manually touch this thing aside from maybe bouncing it once or so a year we'll consider that a failure. What should we use?" I'd probably say... Apache and PHP.
Sometimes I'm in the middle of messing with the Lovecraftian horror that is the modern JS stack or screwing with extracting what I need from whatever awful request object someone cooked up or any number of other things that aren't accomplishing anything of business value and I wonder whether maybe somewhere we veered way in the wrong direction, as an industry.
I've seen that Nginx can remove the .php suffix, with its try_files directive. but I haven't see how it can handle PATH_INFO of arbitrary length. Can you point me to the documentation that you're thinking about?
As other commenters point out, most PHP written today goes through a framework that negates most of these points (single entry point, modern architecture, code is precompiles/cached and optimised, simple and intuitive goes through the window)
On the more general point, I am not sure scripting languages lend themselves better to lamdbas, as dependencies are usually external to the system.
For instance PHP often relies on system json/xml libraries. Database access also needs to be precompiled and installed on the system, as would be crypto or internalionalization routines.
Compared to that, I'd expect compiled runtimes can have one single "fat" binary that has most of the risky dependencies and only rely on the bare minimum provided by the system.
>Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
The vast majority of PHP frameworks, even micro-frameworks, don't work that way. They route all traffic (except static assets) to an `index.php`, which then forwards it to a regular router.
.. so you can live swap routes and endpoints even with dynamic routing (without performing any hot-reload dance in your own code), which actually sounds like a neat feature at first.
You conveniently leave out all the security mess of that design, especially WordPress. The plugin system is pretty much the cause of all the security issues in WordPress.
Perhaps end-users should not have the capacity to so easily add third party PHP code, even if it’s “simple.”
I really don't see how Wordpress is a valid argument here. We run several business systems in PHP serving hundreds of thousands of users. Last time I used Wordpress was over 10 years ago for my personal blog. Haven't used it for anything else. PHP is great for us, regardless of how Wordpress performs.
I was primarily responding to the OP that used WordPress as an example of how easily you can add plugins (third-party PHP code). I see that as an anti-pattern, because it encourages non-developers to add PHP code into the system, much of it poorly written and insecure (or not performant).
But that plugin system also is one of WordPress' greatest assets. And you can add PHP code to any part of a "theme" too. If you turned off the ability for themes and plugins to be "added live" then I don't think WordPress would be nearly as successful as it has become.
Did I say that? Please don't twist my words. I was responding to the OP who was talking about the WordPress plugin system, which allows just about anyone to add third-party PHP code into the system. And those plugins have access to everything in the WordPress stack (and the file system for that user).
And I think you can definitely argue that a low barrier to entry means that it gives beginners a lot of power they don't quite understand.
Which is why I think most people steer towards common web frameworks, because not many people can know all the ways you can create security issues.
Then you get into the complexities of various common web frameworks (Zend, etc) and you have to really wonder if the original OPs argument about simplicity and ease-of-use are worth that trade-off from using something else.
> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
Since it's basically just doing eval(loadFile(...)), any language with eval() can do this, for better or worse. Which is like most of them. Perl, Python, Ruby, and Lua, to name the most common.
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
> Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.
This isn't really php specific, with cgi you can do that in any language, even compiled ones like c.
> Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.
Agreed. I must admit I'm guilty of this myself, there is a tendency to start with a framework when there are much simpler and quicker ways to get started, something the world seems to have largely forgotten.
> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
I mean that's just how CGI works, most every HTTP server still supports CGI, nothing stops you from deploying that way. Unless you're using Java or the like of course, then it's not very convenient.
But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to - I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling.
> But the reason why it isn't convenient is because the consensus amongst Java programmers is that it's a bad idea. It wouldn't be difficult to build tooling around if one wished to
That's part of the inconvenience though, one of the advantages of CGI was the low tooling requirements.
> I think in this case, the fact that almost every language has migrated away from CGI-style routing is probably telling.
I mean sure, but beyond not being a very good protocol CGI needs to execute the handler script on every connection, Java is not known for that being cheap.
Wordpress can instantly extend itself and its extensions can instantly self-f*ck the whole thing up.
(Sorry for the WP hate, I forgot to take my pills)
Still, it took quite long time for me to deploy PHP services.
Didn't managed to get seafile(python) working at all. And it was relatively easy to deploy pair of Go services.
Generally, no. Almost any framework has build steps these days, at least `composer install` to get all the dependencies, and usually also special web server configuration, so you don't expose all your PHP files to the web, only the index.php entry point.
Yup :) You very much just `git clone` a Laravel project, point Apache/NGINX (with PHP-FPM configured) to the `public` folder and all you need to do is run database migrations (for the majority of basic deployments).
That chown looks super suspect. Usually you wouldn't want the webserver to have write access to the web application it is executing; that's how you get backdoored.
This is my concern with things like the Wordpress auto updater, but it seems the trade off is not having to worry about manual patch management. Security vs convenience as always.
How I've been running multiple wordpress installs for years:
user: $sitename
- the 'owner' of the whole hosted dir. rwX
user: $sitename-PHP
- the user that php-fastcgi or whatever runs as, r-X permission on the dir, and write permission on the content uploads directory, but CANNOT write to any plugin install dirs, or upgrade php files.
user: nginx
- can read all files except the wp-config.php file, which is limited to only the $sitename group reading it.
then use wp-cli to do automatic upgrades every few hours, and a localhost-only ftp server for wordpress to do plugin installs with. When you try to install a plugin, it asks for a ftp username, host as password. You put in the $sitename user, '127.0.0.1' and $sitename password, and you're set. Those login details are never saved anywhere, so the admin has to put them in each time (or their browser stores them).
Of course. I actually regard this as a fairly major issue with the Linux permissions model. Far too many people do as the GP and accidentally set all the files to executable. Cleaning up after someone has done this on a nested set of subdirectories is quite tedious.
NB if anyone has ever run:
chmod -R u+x . or equivalent
and you run
chmod -R u=rwX the files will stay executable...
You can always use find to set all files to +x and directories to -x but then what if some of files needed to be executable?
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
Not if you're using... literally any modern framework and deploying it properly. This hasn't been the case in years except for common legacy stuff like Wordpress.
> For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
I'm quite sure you can achieve this in golang with plugins[1]. That not as flexable as PHP, mainly because it involves a static type system and a compile phase (and more work in general).
Yeah, running plugins is not a difficult problem in most languages; it isn’t widely practiced outside of the PHP community because most folks don’t want to be the reason their users were hacked.
I'm currently developing a facility to do live updating of processes with running game loops in Go. If one were to add in dynamically loadable libraries (working in Linux, last I checked) one could have the same facility for changing a single endpoint in Go. (It could also be implemented with small executables and reverse proxies.)
I think what this demonstrates is that Go isn't a better PHP. Rather, we're at the point where Go could be used to build a better PHP. The most likely paths for this, are to somehow come up with a big group of developers with a penchant for doing this, and/or have some big company fund this.
>Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.
This doesn’t seem to be a language choice problem, it seems to be a monolith problem, where PHP simply managed to avoid some of the traditional monolith issues by design. Your CD pipelines in any micro service architecture should solve these problems, whether it’s using FaaS or containers, or whether it’s using a compiled language or an interpreted one.
No, I am speaking about the ecosystem. Large, industry-grade projects developed in this language.
What standards did Wordpress set a few years ago? Huge, disjoint sets of files spread throughout the themes folders. How much time does it take me to understand which of these files is causing the error?
Do you still upload your code via FTP directly to the web server? Do you still reset the code cache for the PHP in order for that new code to become live? Well, I am going to be happy when your skill set is made redundant, because you are getting paid to know all of these quirks and they are not making the industry any better.
You can write good code in _anything_. You could even write it on paper and then expense that to a person working for $0.01/hour to execute it. The question is whether the liability of your methods is lower than the liability of other methods.
PHP is essentially the dinosaur from the times when SEO consultants made loads of money. They are still using PHP because they never knew anything better and the scale of the industry is enormous, so it's slow to change.
> Do you still upload your code via FTP directly to the web server?
It's pretty rare that this is even an option, since no one in their right mind would set up an FTP server with access to anything important.
SFTP? I don't see why not. No need to make things more complex than is necessary.
I don't remember any particular problems with code caching when I did PHP development, though maybe you use a different caching tool than I did. Also, Wordpress is its own beast, and is generally reviled by most everyone, expecially PHP programmers.
>> SFTP? I don't see why not. No need to make things more complex than is necessary.
You are trying to argue definitions (SFTP vs FTP when FTP just means “any file transfer protocol”) instead of arguing that uploading any amount of files by any protocol that are immediately picked up by the interpreter introduces nondeterministic behaviour of the website where the users accessing your website only see a subset of the files you were trying to upload.
Doesn’t that just reinforce one’s confidence in the fact that PHP developers are generally quite amature in nature?
Who says you have to upload your code directly to the deployment directory? Upload files, switch symlink. Done. You are talking about a deployment technique that has nothing to do with PHP.
Nah, I am speaking about the general/majority culture of how it is done in PHP.
Do you not see the comments in this specific thread? The guy a bit higher up the chain thinks my issue is with "FTP vs SFTP", rather than "the version of the files at a particular moment in time".
He doesn't even understand why a partial view of the files could be an issue.
And the general sentiment in PHP is that "you can change any file separately, by editing in online on the server - and that is a good thing".
Being able to extend or replace modules easily (and especially online) is something that's challenging in monoliths. The design of PHP avoids this issue. I'm not really making any other statements about the quality of the language here.
> Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.
Except in reality once you want to use non /whatever/file.php as urls - you're back to implementing a router
> PHP files can be deployed independently, swapped out or updated live. Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.
Except in reality, you don't want to deploy directly after editing a file since it's like deploying to production, you're gonna have a bad time.
> A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers.
Except in reality, that just leads to a bunch of spaghetti code with no separation of concerns and impossible to maintain.
> Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
Except in reality, this only works with php apps that have an integrated package manager and even then it leads to problems when a version is incompatible both in php or plugin dependency.
> Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.
Except in reality, serverless lambda is a terrible idea:
1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work
2. when functions change you run into function incompatibility chaos and no smart way to handle that mess
3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't
4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement
> Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.
Except in reality, you are notified of a bunch of potential bugs right there and then, instead of "maybe" finding out about them at runtime especially since PHP will by default consider a non defined variable just an empty string and display it as such on the page, and it's not until Joe User notices it that you'd ever find out.
1. lock in to a specific platform with limited visibility tools and a dependency on a 3rd party when shit doesn't work
The logging analysis tools are excellent and it’s quite easy to tie your lambda logging to whatever tool you are using.
As far as “lock-in”, there is an Amazon provided framework in every supported language to just add a proxy that allows you to use your standard framework (Node/Express C#/ASP.Net, etc) and you cab deploy to Lambda or your traditional web server with no code changes.
2. when functions change you run into function incompatibility chaos and no smart way to handle that mess
What???
3. the "scalability" win is a lie, it's just deferred to whatever data storage service you are using - which ends up blowing up because while serverless scales, the db doesn't
Serverless Aurora (Mysql) and DynamoDB both have autoscaling. You can also auto scale Read Replicas fast with traditional Aurora.
4. addendum to 3, the statelessness of lambda means you can not use local caches to increase your throughput - increasing your hardware requirement
Again not true, if you are calling an endpoint frequently, the instance stays warm for up to around 15 minutes and can maintain state.
Regarding (4) Lambda and friends are not actually stateless between requests; the process is initialized once and then potentially reused many times for hours, so you can cache between requests, both in memory or in the filesystem (AWS Lambda provides 512MB in /tmp).
For the kinds of applications people tend to build in PHP, PHP is probably a better choice than Go. I'd still do Django or Rails before PHP, but Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write.
I have not written a new PHP app in years but recently I had a look at the latest and greatest from the PHP community and its pretty good. The frameworks and tooling look about as good as you will get anywhere and PHP appears to be fast now.
As someone who was about to ditch the PHP ecosystem 6 years ago for something like Rails... frameworks like Laravel absolutely changed the PHP ecosystem.
Also since the release of PHP 7.0, core development seems to have really picked up with good stuff in every release (7.3 was just released a few months ago).
I just do not understand the fascination with Laravel. When the first version of Laravel was released Symfony was already lightyears ahead.
The only thing Laravel had going for it was that you could take more shortcuts, and it was a pain to integrate into any IDE if you wanted decent autocompletion.
I haven't touched symphony from 1.2 but laravel was a lot simpler to use, especially for begginers. no stupid yaml files, the need to definine everything in yaml before. simpler orm and so on.
Laravel is not what it used to be either -- Laravel 5 is far more capable/usable than Rails or Django. It's ecosystem is vaster, much stronger community, better docs, faster -- pretty much every state it's better than it's competitors.
I disagree. Laravel is much less verbose than Symfony and tries to optimize for developer happiness. Couple that with a kick ass video tutorials site (laracast.com) and that Laravel was started at the fall of CodeIgniter giving it a great boost in users.
I've used both Rails and Laravel fairly extensively. The Psy shell and Laravel collections library are quite nice, but not quite as versatile as Rails/pry. However, Ruby has a long way to go to catch up to the PHP interpreter's performance.
Does it? If you declare strict, use strict comparison operators and typehint your arguments and returns, what more care do you need? These are not particularly onerous, the strict declaration is trivially templateable in any editor as it's the first line, you'd write types in any language and getting used to only use === !== and forget == and != is ... easy?
There is an absolutely phenomenal static analyser for PHP called enhanced inspections EA (free version and commercial very) that will flag == when === should be more appropriate (among many other things).
For people not using Intellij (or wanting a tool that can be used as part of commit/deploy setup there is phan which is well executed).
I've mocked PHP for a long time (been using it for various day jobs for over a decade) but they've made massive strides in the last 2-3 years to the extent where used properly it's approach 'not a bad' language status.
1. Generic typehints, for one. Typehinting half the methods as returning a generic `array` is not fun.
2. And that's before you even remember that PHP's array is both a vector and a hashmap, so you need to install a PECL extension or a third-party library to get proper Map/Sequence/etc.
Use < and > for numbers and strcmp for strings. A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?
>A strict type > would be very weird because besides returning TRUE and FALSE it'd need to throw a TypeError, I guess?
Yes, which would make it behave exactly like probably every language with strong runtime typechecks. Very weird indeed. It's obviously much more preferable that the code sometimes does the wrong thing without warning.
And of course with static typing, it would be extremely weird since the code wouldn't even pass the compiler!
It is getting better though. I'm hoping that 8.0 can introduce some real BC breaks that will clean up the mess the language has created over the years.
Flask is a good alternative to Django for building web apps with python on the backend. If I'm using react or vue with a JSON API, I don't need the form support in symfony or django.
However, deploying a Flask/Django/Rails app still is usually less fun than deploying a PHP app of the same spec written w/ Symfony or Laravel.
Configuring a service to monitor gunicorn, which itself took a bit to configure, before I begin configuring NGINX or Apache... it's really a pain in the butt.
You have to make your own cost analysis to see what is most efficient for you.
Writing secure, readable, quality code in PHP is something I'm far more comfortable doing than deploying Flask or Django apps on a VPS. That's a function of my lived experiences.
YMMV, but I think declaring python/ruby on the backend is "the all-around better stack" for everyone is a bit short-sighted imho.
If you compare it to a generalized Lamp stack, sure. Compare it to Laravel, and you have no solid basis for "code quality", worse readability, it's Fortune 100-levle-secure, future-maintenance -- Laravel is more active than any other community out there, and has significantly more tooling.
I'm working on an internal tool for our micro operation (we're 2 folks) built with Flask and it was my main concern.
Turns out, leveraging Dokku and having the right files, ie a Procfile to bind your app to Gunicorn and pushing the repo to the dokku instance was all it took.
Granted, it's for internal use so downtime isn't that big of an issue.
Rest API? Sure. Building webpages? I dont think it was made for that... Although Go templates can work, its still not as flexible as you might want it to be.
Then again these days maybe that is enough for some people. I know a lot of people are eschewing server side page generation entirely for some static js and assets sitting in an S3 bucket that talks to an API server. The only barrier now is SEO, and people are coming up with all sorts of creative solutions to deal with that, as the search engine bots themselves get better and better at indexing js content. That said, I sort of hate frontend js frameworks. You can do everything I just said without them, and really, we should have been doing it for years, like even pre-2010, but we were just too caught up in this markup = server side mentality to really operate that way. Part of it, I think, was that CDNs are a sort of recent thing, and before them you were always running a server anyway, so why not generate the page server side if you're going to go to that much trouble. Also client-side capabilities have dramatically increased, and then you have HTML 5 to consider.
It's true. I don't often do so at work anymore, either—except for utility pages.
But I am rewriting my personal site/blog in Go as a trial run/learning process. I've been critical of Go in the past so I thought I'd give it a... go.
So far I don't mind the experience. No server framework, either. The standard library is actually pretty good, at least for something simple like that.
The only [external] dependency I'm pulling in so far is `blackfriday` for parsing Markdown files (the posts) upon request— I'm much too lazy to write a Markdown parser myself for this purpose.
Well, they thought Go would be an alternative to C++ (1) which has never really been the most popular website backend language.
I'm glad it's working out for you, but I don't think it's a stretch to say it wasn't really designed for it. On its own, that doesn't mean it's a bad fit; but I agree with your parent and think it's awful for this type of stuff.
In go, Querying SQL is very much like doing the same thing with the base libraries for mysql in C. Doing the same in most any other language is much much easier and just as safe.
Credentials: Worked mainly in go for 4 years... 18+ years coding in about 9 languages.
I think the parent refers to lack of automated result to struct mappers, or maybe lack of decent orm... although it’s probably lacking not due to go features, it’s just that kind of magic is typically not the go way.
The lack of automated result > data model mappers is kind of by design with statically typed languages. IMO, Go's structs approach is much more lightweight than languages like Scala where large amounts of time can be spent defining exquisite types. Though - one option is to just accept a slice of `[]interface{}` (or an `Any` in Scala), but then you're negating the type-safety provided by statically typed languages.
WRT ORMs - Go has ORMs, some of them look reasonable. I'm not a big fan of ORMs in general though. IMHO the only valid use cases for ORM's are for applications that need to support multiple database technologies, or where the application developers don't know SQL.
Seems useful, but it’s yet another of those frameworks that introduce spurious CLI tools for „initializing“ the project by generating dozens of files that one either doesn’t need at all or has to replace anyway. I don’t need a tool to generate CSS boilerplate, I can just copy it from somewhere myself if I decide to use external CSS.
One of the reasons PHP was appealing initially was that all this boilerplate and extra files were unnecessary, you just wrote something in the .php file (in Apache’s hierarchy) and could load the web page. As problematic as that was, it let you focus on getting stuff done instead of overwhelming you with ad hoc conventions and dozens of files with no immediate use.
Go is a language with sane defaults and little boilerplate. It would benefit from a web framework with similar principles.
I love Go, for many situations, but definitely not for a typical user facing website.
The community seems bent on the whole "all you need is net/http", but that just isn't practical in modern web development. People like ORMs, easy to handle html forms, security as a default, easy session/cookie handling etc. In the end, web developers want ease of life.
Go is a great language for many things, but if it's going to take on the web at large (outside of HTTP APIs), the community needs to grow out of this "net/http or nothing" approach.
There is some hope, some frameworks like https://gobuffalo.io/en are showing up, but the Go ecosystem is dying for a Rails/Django solution.
> but that just isn't practical in modern web development
People always use this modern term as if it implies something significantly different or more "advanced". The web hasn't changed much. It's still data over tcp sockets to a contained runtime -- a web browser.
> People like ORMs
People in my experience are starting to dislike ORMs. If you have done this for long enough, you realize they are great for getting off the ground, but they inevitably get in your way, and start generating some really bad queries which you have to start one by one replacing with raw SQL statements, at which point you might have well started with raw SQL.
Having come from Rails, and PHP frameworks like Symphony and Laravel at my company, using Go I feel almost like I am more intimate with my code. I understand it better, the dependency chain only ever goes one or at most two levels deep. I will admit the the templating and routing is more "batteries included" in these frameworks, but the other parts that I have control of that I consider much more important (such as how my data actually gets stored and other network calls I have to make), I would much rather do those in Go than in PHP
Speaking as someone who moved from a company that heavily leaned on an ORM to a company that is using jOOQ (a thin Java wrapper around SQL) for everything, not being able to use an ORM is pretty painful.
I greatly miss the nice, clean ORM experience. It's so much better for developer efficiency.
I use go for building websites and it was the first time web development really made any sense. All the other systems out there require tons of tools, and lock you into doing things their way.
So, what makes GO so much of a pain? Maybe ignorance is bliss for me?
> All the other systems out there require tons of tools, and lock you into doing things their way.
Nothing is stopping you from writing everything yourself in any other language. You can do the same in Java or .NET. Then you start finding out you need routing, validation, security, DB access, etc. which golang lacks and ends up making it much more verbose than other mature frameworks.
I made a very simple webapp a few months ago, where students are proposed assignments and can rank them. For that, you need authentication, and DB management: a subject table, a student table, and a ranking table. You have to do all of that manually in go, while other languages have frameworks that take care of it.
Still did it in go because it was a very simple webapp and deployment is so easy with go, but for a more complex task I'm not sure I'd have used it.
I hear this argument a lot. I like to ask, are you writing software or using frameworks?
I am not saying you need to write all your software but if your app is on the lines of declaring a few statements and running a command to generate the rest then I have to ask what you really are doing. On top of that you have to ask how you will approach changing your program using frameworks to the specs of the task at hand?
Also, can you go into what is "manual" about autentication, db management in go? Compared to other languages? Did you mean framework?
> Laravel just has too much magic that will bite you later on.
Especially when that is not explained in the docs or just in a very vague way...
I tried improving the docs by pointing out where magic (e.g. fix naming conventions) is needed and where not, but the mantainer just turned that into vague mush again (after he had even agreed to the changes).
Also if you need any more details that are not in the docs, everyone points you to paid video courses that assume you have a Mac...
That honestly leaves me with a bad taste im my mouth after trying laravel :/
Unless you want to write a ton of transformers, your models will likely know about your database design. If only by virtue of having the same properties.
I think the parent is objecting to the fact that annotations spray this "external" information right in the middle of the controller/model. FWIW, decent tools let you put this info in separate configuration files instead of code annotations, "decoupling" it from the code.
You are 100% right about that. I've nearly tried almost all PHP frameworks, quite extensively I may add and at the end of the day I found that the less framework I use the better and faster my dev is. Now I just use packages from composer as needed and never ever use them anymore.
For me Laravel was a nightmare to use with Vue. Both template engines (blade, vue) use moustache tags so everything has to be declared inside @vetbatim. Then mix doesn't even compare to ease of vue cli imo. Then the nested directory structure was so confusing (was it inside resource folder, or controller folder). I've never been happier since I ditched these opinionated frameworks
Interesting. Coding without a framework is rare these days. I would like to hear more about how you do the basic infrastructure stuff usually provided by a framework:
This is actually something I have been predicting for PHP for a while. Frameworks are beneficial when languages don’t have built in support for the core needs of your task, so those needs a built into the framework and abstracted away.
With both PHP and JS this isn’t the case, which is why you see SO many frameworks for them: all of the parts are already there so the frameworks are mostly just rearranging things. Ruby, Python, Go, etc are general purpose so the frameworks provide a lot more support.
PHP’s biggest hang up for years was lack of name spacing for good module support so EVERY framework had their own version of every core feature you’d need abstracted around its framework naming schema. Can you imagine every framework writing their own database drivers...because that was happening.
As soon as Composer was released it was only going to be a matter of time before the ecosystem started to clean itself up from 9 different ways to install shared code.
PHP's package manager makes it really easy to pull in components a la carte. Similar to OP, I rarely use a large framework like Symfony or Laravel. I have a base application I wrote which I like, and I layer components I trust and whose API fits my preferences as I require them.
Additionally, the PSR project has standardized a lot of APIs (HTTP request/response, logging, cache to name a few), which means if a package conforms to PSR, you get interop out of the box and can quickly swap implementations if needed.
> The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.
If you are using Doctrine the only alternative to docblock annotations is XML because they are deprecating YAML support.
I really hope they build support in the language itself. I can't understand their fierce opposition to a feature every other major object oriented language has. They are only forcing a large part of the ecosystem, everything that is Symfony or Doctrine based, to use the horrible docblock work around.
Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty great at CLI tools).
> They were a little surprised to hear our stack involved Golang and some flat out told us they’d prefer PHP, because that’s what most of our products rely upon.
I believe this is the real reason why, and everything else above it is pointless technical justification for a sound business decision. I also believe there's an unvoiced, even more powerful reason, in "I already know PHP and don't want to learn a whole new thing."
These are both sound reasons. The technical justifications are not.
Choosing Go for something like this was a bad decision. But choosing PHP is only slightly better. Opting for Django, Rails, or Phoenix would have better technical justification, but technical justification is rarely the real reason why we make decisions like these.
You are comparing frameworks with a language here.
I think that if they choose to use a high-quality, modern php framework like Symfony, the technical decision would still make sense in the context of the alternatives you mentioned.
That comparison is intentional, for one reason: Go doesn't have any "frameworks", let alone frameworks that are remotely comparable to the productivity offered by Symfony, Django, or Phoenix. The language actively opposes the development of tools like these. At best, we've got libraries that wrap net/http, io/ioutil, etc and moderately increase developer productivity, but there's nothing holistic and opinionated. The closest you can get is something like gRPC, but its not even the whole story, and it also relies on codegen so that's a disqualification in my book.
This isn't just technical; its baked deep into the culture of Go. And that's fine. Its designed for something different.
I came to Go from mainly C++, Java, and Python background, and I feel like it's the best of all 3 (to me). It's compiled and really fast (like C++), it has a great set of libraries and community interaction/support (like Java), and it has simple syntax that is clear and quick to understand (like Python).
It's not a perfect language (nothing can ever be), but it's become my favorite to use for back-end web services and even taken over some of my scripting workflow.
I can see it being painful if you're trying to render websites server-side though. That's a bit outside of what it's made for
On the topic of web frameworks, though, I firmly believe it is possible to write a delightful web framework with mass appeal (like Rails) in any language, you just need the right influences and conventions, but this seldom happens because the people who could write it are already busy enjoying their framework in the language that they enjoy most.
I talked with a few people who wrote Go servers and while they loved almost everything about the language and ecosystem, they hates the missing generics so much, they still switched to other languages later.
Writing code-generators for everything wasn't fun.
I don't miss generics in Go and I have used generics in C++ a good deal. I think the whole generics argument against Go is largely parroted by people who may not even know what generics even are. C doesn't have Generics either. It's doing OK.
Any language that doesn't have generics, including C and Go, have to work around that limitation. In C, people get around this by using void* (equivalent to using interface{} in Go) or code generation via macros.
I'd flip what you said and say that most of the people arguing against generics in Go don't have much or any experience with them. Which makes sense because a large number of users came from dynamically typed languages.
Personally, I find the concurrency support quite lacking. Compared to Java/Javascript/Python/etc, it's great, but nothing compared to languages like Ada or Elixir.
I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).
Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.
> Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.
Absolutely not. Locks/spinlocks are found in pretty much every significantly parallel software project. It is pretty arrogant to criticize almost all software architectures on earth.
> It is pretty arrogant to criticize almost all software architectures on earth.
Almost all software is programmed with modern languages, which all (imo) have extremely lackluster support for concurrency. It's not a symptom of the programmers, but the tools they work with. Who uses Ada these days?
Locks should only be used when other protection mechanisms are too slow.
Semantically, the critical region protected by a lock is not connected to the lock in any way. This can make debugging races super difficult, and you have to rely on everyone to lock everything at the right point.
Juggling multiple locks in complex concurrent processes is difficult, and prone to bugs.
I struggle to think of where a lock is required, barring the extremely hyperoptimised hot paths within operating systems, or similar applications.
Personally I found it too easy to accidentally forget to check an error, or to shadow a named error return, or to create a nil error that doesn't compare equal to nil. Also to write a method that appears to mutate the receiver but which in fact copies it.
That second example is really surprising. This sort of thing happens all the time in production when lines get moved around. Does anyone know why errcheck misses it?
I mean GoLand is pretty good, but I do also like IntelliJ, so YMMV if you don't like the JetBrains products. And it isn't free.
VSCode is also really good for Go, I was surprised. There are plugins that massively help with testing, syntax checking, error handling, etc. I think it actually catches more issues than GoLand!
I've tried VSCode but it seems to require you to install Go... It can't even find the declaration of a variable or the definition of a function without Go, while Sublime can.
In all honesty, indenting with more than 2 spaces (or, gasp, with tabs) is enough to kill a language for me these days. There are so many competing "new age systems languages" as I call them (crystal/rust/go/nim/d/julia/etc) that you really can pick the one that suits you the most. Crystal is more my speed. Yes go is way more mature, and has all the features I want, but it just isn't set up how I want things to be set up, whereas Crystal is. Is Crystal perfect? No, but it's the closest thing to what I want, and has all the appearances, trappings, etc., that I would expect of a language sent by the gods. The way go code looks just doesn't do that for me, but I'm sure it does for the people who created it.
Because it works well at various levels and is good at producing low error maintainable code. It's also very stable and has a good stdlib so what's written five years ago is still working and makes sense. It's not really fun for me (yet?) and I think something like Django is more suitable in many cases, but choosing a core competency go is a pretty safe bet for medium or large company.
Go's a language for managers that don't trust their developers with their own intelligence. It's either a good thing or a bad thing.
Go is actually simpler than PHP as a language, once one understands "explicit" pointers (though PHP does expose pointers for a few things, arrays for instance since they are copied by default).
As for PHP, it's useful IN SPITE of itself, and that's the issue, the language works against the developer and only the tooling, frameworks and rigorous security practices can mitigate its flaws.
Symfony 4 is much more lightweight than previous versions. If you create a new symfony 4 project with composer you just get an empty project with just a hand full of dependencies. First time I tried out the v4 (coming from 2.x & 3.x) I thought that the installation did not work properly because stuff like twig (for templating) and other things were missing.
“Just for fun, I compared apples and oranges again by benchmarking the login page (which doesn't hit any database) for both application versions using Siege.
The Symfony application (PHP 7.3, OPcache enabled, optimized autoloader) handles about 1470 req/s. The Go application (compiled using Go v1.11) averages about 18600 req/s.”
Yes, but you’re more interested in fruit salad vs. fruit salad. Maybe they actually never have to handle more than a dozen logins.
But they have to change the templates relatively frequently:
> it’s more maintainable for us to do it in PHP right now
Everyone does: it’s like having a good offense: you don’t need to think about defense if you’re constantly scoring goals. A lot of issues can be hidden by being really good at serving content and taking requests quickly.
Hm, I hate to be on the bandwagon, but why WordPress? One of the things that has made PHP become what it is today is a focus on good software engineering and the introduction of language features that are required by that. WordPress did not keep up on the engineering front and there are so many amazing options out there now for well written, well engineered platforms. Even in pre-built blog platforms.
You're not alone mind you, most of the new platforms are not very popular just because of how embedded WordPress is in its ecosystem. It just surprises me that both WordPress never moved on and that the PHP developer community never chose something different when it was clear WordPress had no intention of moving to more modern practices.
WordPress can't really become better without becoming incompatible with itself. It was written just after PHP acquired classes, but chose to preserve compatibility with a codebase that predated that. It's its own ecosystem at this point.
I am completely out of the loop here. All I know is that I really disliked Wordpress and really-really disliked Drupal back in the day. Can you mention some of the better alternatives? Once in a while a PHP CMS is what I gotta deal with and I dread it, because of the said systems.
Check out OctoberCMS. The simplicity and ease of use of PHP while being a very modern and stable platform to build one. Disclosure: I'm the community manager :)
Clients see Wordpress as a business platform/lack of dedicated supported in-house and developers on projects based could keep generate incomes from small businesses.
What are the amazing option do you suggests with batteries include in the language would be ideal.
PHP is the same but with speed improvements in 7. But even without that the sheer number of high traffic sites built on PHP and proven scalability cannot be ignored or its ease of use and setup.
All talk of accessibility and ease for new users often comes off as posturing by some tech folks who then proceed to rubbish any efforts at achieving it and the compromises involved. It fits in nicely with the 'contempt culture' recently covered here.
The growing problem for the technical community and new users is the marketing by other languages, frameworks and those vested in these ecosystems which means using forums like this to belittle, rubbish and exaggerate any perceived fault in everything else. PHP's contemporaries like Python, Ruby, Javascript have their many downsides too but these efforts create false binary narratives. This is not a good basis for technical decisions or informed discussion.
It's interesting that he names Symfony 4 as one of the main reasons he uses PHP again after he already used PHP with Laravel.
I have a lot of discussions with friends in the startup scene about the topic of Laravel vs Symfony. So far it's a head to head race.
I have yet to find a good 'Laravel vs Symfony' comparison page. Yes, there are tons of 'SEO optimized articles' with this title. But I find them all rather uninformative and often even totally wrong and unfair.
The page I would love to see would have the same project coded twice. Once with each framework. And then display each file on the left for Laravel and the corresponding file on the right for Symfony.
Those SEO pages are horrible. I had the same problem.
But there are multiple reasons I choose Symfony 4 over Laravel.
And if you want a code comparison then this small example:
Laravel:
class User
{
}
Symfony:
class User
{
private $id;
private $name;
public function getId():?int
{
return $this->id;
}
public function setName(string $name): self
{
$this->name = $name;
return $this;
}
public function getName():?string
{
return $this->name;
}
}
Laravel looks a lot easier and quicker. And it is.
But good luck next month when you can't remember what properties User has. Your IDE can't autocomplete it. And also good luck working with a team. Your team members have to look up the database model for the User to see what properties are available.
And this is happening in Laravel all the time. Very quick, very easy, a lot of magic but it will bite you in the end.
I don't use laravel anymore, but I had a live template that would generate getters and setters that wrote to set_attribute. As long as you maintained the convention of doing this, you could use autocomplete with getters and setters to accomplish this.
You could also hint these with / @var */ there are ways around it but yes it isn't ideal. I really liked doctrine, perhaps I was using it wrong, but having everything in annotations was pretty nice since migrations etc could run off of it.
With doctrine I ran into issues with performance, which you can alleviate with extra lazy etc, it also hydrated what appeared to be massive objects, which you had to use a custom debugger because print_r'ing one with the recursive references etc caused some crazy issues. I have since moved on from PHP, but if the project calls for it, I have no problem using laravel. While not ideal, it sure is productive to build an API in. I wrote a project in lumen, which is/was a subset of laravel built for APIs, and that was okay to work in. No clue if it still exists.
Question : modern PHP is great for websites, but what are the solutions when you need to make some async work ? For example if I need to make few third party API calls in parallel ? With Laravel I resorted to using queues which feels like more complicated than it had to be (each worker takes up quite a bit of memory). Eventually I switched to SQS + Lambda + node.js.
Is there any mature way to do async work in PHP ? In Node.js for example, it's quite trivial and powerful with promises and async/await
Thanks, that's one solution if making multiple calls is needed.
That was mostly an example though, for example if I wanted to run 3 functions in parallel, I don't find any "easy" and elegant way. Some libraries exist like amp, but it seems a bit heavy handed as the language itself doesn't have great tools for it https://github.com/amphp/amp
Neither amphp or reactphp will let you start running blocking functions in parallel out of the box. They basically just provide syntactic sugar for making single-threaded, cooperative multitasking easier by wrapping php's native ability to read/write to sockets asynchronously (or by using pecl extensions.)
So you can respond to websocket messages or http requests asynchronously but you're not going to be able to implement anything like a parallel merge sort were you offload work to other threads. Things like general purpose file IO are not easy at the moment either.
To keep it simple, it was originally created as sort of a helper instead of a full-fledged language, and just kind of grew into that. As such, its early years were plagued with architecture, security and performance issues, as well as many "gotchas" that could wreak havoc on amateur programmers that tended to gravitate to the language. Couple that with the fact that the maintainers drug their feet in implementing modern paradigms found in other languages and fixing the latter issues in the name of backwards compatibility, and that at the time most PHP knowledge bases were years out of date, and it was a recipe for a poor ecosystem all around.
PHP 7.0 took a huge step forward by straight up removing old extensions that weren't maintained, focused a lot on performance and allowing more strict standards, and tons of new improvements. In addition, more modern frameworks like Symfony and Laravel started to pop up, which helped reduce the stigma of it just being a "scripting" language and made it very pleasant to work with.
I maintain a PHP app that was originally written in PHP 4, and one that was created in PHP 7 and the difference is night and day. I maintain a few Ruby and Python apps as well, but even having used these more often PHP still tends to be my go to for prototyping.
Gotchas in Javascript are syntactic/semantic, because there's no standard library worth its name bundled with it.
PHP's gotchas are syntactic/semantic but mostly on its huge standard library, which is an haphazard collection of functions from sending emails to parsing ID3 tags from MP3 files.
EDIT: JS, as the legend says, was written in 10 days, while PHP grew without much long term vision for years.
I think the parent poster was talking about both being messy in the past, but recently having a major version upgrade that deprecated old features. PHP 7 could be compared to ES6 (as well as ES5's strict mode)
Oof. I haven't read that classic in awhile. Yeah, most of the things in there can't really be fixed without pulling a Python 3 and intentionally breaking backwards compatibility. And the scary thing is people just brush some of these horrifying things off as non-issues.
PHP was one of my first languages, and it took a long time to break some bad habits it taught. I still can't get over the existence of PHP's "arrays." (Mentioned in the article.) The only data structure is one-size-fits-all. It's truly baffling when you approach it with basic CS knowledge, and the rabbit hole only gets worse...
In the context of what you're doing with PHP, that one-fits-all data structure is all you need. I sincerely doubt you had hurdles in your career because of PHP's array :)
The "classic" you're referring to is far from something objective. There will always be problems with languages. That's why we have the human factor who is supposed to be intelligent and work around the apparent issues and make the computer do useful work despite apparent tool glitches.
Sadly, we're just creating better idiots who are only getting better at whining.
Its a quirky little language and the early versions weren't great. The language can be inconsistent in places, and embedding php in the html made for a rapid though sometimes trying experience. Its keeps backward compatibility which keeps those quirks in there. (though with new 7 series php versions older stuff is starting to break.)
Someone wrote an article with a title like "php a language with terrible design" that got traction.
I like the language and with the right framework and templating engine its a pleasure. (I'm moving code from silex to symfony).
I've been to a fair number php meetups and frankly people there seem to be end result focused not so concerned with the language. Frankly I think PHP doesn't have as strong a fan club as ruby/python, which are decent languages but they too come with their own quirks.
> Frankly I think PHP doesn't have as strong a fan club as ruby/python, which are decent languages but they too come with their own quirks.
The reason quite possibly is that those are joy to use where PHP isn't. In my mind the developer happiness should be on top of the list, also the syntax is still ugly however you look at it. The versatility of Python is unmatched. Ruby allows me to do things I could only dream of in other languages, in PHP those dreams are nightmares.
Not really comparable tho. In React, the JS in the HTML is to make loops and conditional rendering, i.e. presentational logic, like in any other templating system. In PHP, you can embed business logic and database accesses in the HTML.
Well yes if you're stupid enough to directly expose your DB to the world then it's technically possible, but barring such idiocy there's arguably more risk of a DB hack through PHP than client side JS in most architectures.
For years it was a very permissive language that allowed you to do a lot very quickly but then with a lot of overhead to make sure things were correct.
E.g., I've seen a payment management suite that was written using php traits, which then had a super class that everything descended from, meaning every service could do everything, completely breaking OOP. For example, a DirectDebitService has methods like processMandate(), processDd(), but then because of the traits it also has access to processCreditCardPayment(). As you can imagine this made unit testing literally anything require lines of set up code and just made things impossible to work with.
With the introduction of classes, and PHP 7's scalar type declarations as actual keywords rather than just PHP docs, as well as the option for strict comparison, plus the ridiculous speed improvement between 5.6 and 7.0.
Further, tools like composer (which I think was actually one of the first modern package managers (with lock files, version selectors), Behat for integration tests, plus the huge steps frameworks have made in removing in overhead have made PHP actually a very nice language to write these days.
Deployment in a micro service context is still annoying as PHP's built in web server is not great, requiring you to have an Ngninx pointing at a PHP-FPM which actually serves each of your microservices.
You may think you can get away with one Ngninx, but then as soon as micro services start requiring things like scaling it's a pain in the arse. E.g. you may wish to do rate limiting or rbac or something for a specific service, requiring an nginx->PHP-FPM in front of each PHP service.
I'm sure there are cleverer ways to get around this but this is the way I always go and the way I've seen other PHP deva go
This may sound trivial but I dislike the aesthetics and ergonomics of typing PHP. In most dynamic languages user.name is 9 keystrokes, but in PHP $user->name is 13 keystrokes.
> Honestly, Go is great. Its simplicity is refreshing and its performance unmatched. I would still pick it if we need a small API or something that requires high throughput.
I wonder which part is performance unmatched?
My opinion would be Crystal language for its simplicity and higher throughput but unmatched performance is behind Rust and C.
Not sure about the OP, but for many Go is the only compiled language they ever used, so they get to attribute features to Go that aren't that unique of it.
O'caml and Haskell are extremely niche in the web server world, and are not especially faster than go. C# is not blazingly fast either. They all seem to be in the same ballpark.
I've been paying a lot of attention and, in my experience (but also according to the highly biased benchmark game), C#/Java/OCaml/Haskell/Go are in the same league, i.e usually 3-10 times slower than C/C++/Ada/Rust/D, and 3-10 times faster than "scripting" languages like Python/PHP/Ruby/Perl.
With (in my experience) go being a little faster than java and haskell, and o'caml being slightly faster than anyone, but nothing significative enough for me to expect an article titled "my Java webapp was too slow so I rewrote it in O'Caml" anytime soon.
Benchmarking is very relative, though. I'd be glad to read evidence showing go is significantly slower than any of those in some domain.
Memory hog only by those that don't know what they are doing and happilly new everywhere.
Yes it is hard to tune, but not so much different than playing with C or C++ compilation switches, across each compiler that is being used in production.
> Memory hog only by those that don't know what they are doing and happilly new everywhere.
Go uses an order of magnitude less memory for most type of workloads though.
Also you don't tune c++ binaries delivered to you. You have to tune the JVM's option to death for big apps. I can't count the number of incidents "solved" by raising the Xmx param.
I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment.
The big question is how properly those big apps were coded.
Go doesn't run Fintech servers, while Java keeps replacing C++ servers. Yes, one needs to code Java with low level tricks like C++, but it is possible and there are many performance experts doing it.
> I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment
How many customers run self-compiled, say mysql binaries? Or mongodb? An tiny minority.
Now how many tune cassandra or hadoop jvms? A big chunk.
You can use niche cases to make a point (fintech is almost the textbook definition of a niche software use case), however what you say is plain wrong most of the time.
Also, I've managed thousands of c++ and thousands of java processes. I'd take c++ ones over java any day.
Proper Cassandra and Hadoop deployments are as niche as Fintech, the large majority could solve their problems with UNIX command line tools.
On my world the team manages deployments, I rather take Java over C++ compilation times, and having tools like Mission Control to monitor cluster performance on production servers.
Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).
As team lead I consider having the interest to master the tooling part of the job requirements and respective evaluation, not specific knowledge full of gothas.
What IDE do people use for PHP these days? Editing PHP in a standard text editor is a pain because most don't supporet "Go to definition", or "Find all refernences" (Two killer features of Visual Studio)
I've always been a fan of JetBrains' IDEs (Webstorm, Pycharm), so I would imagine that their PhpStorm is similarly excellent. (Each of the ones I mentioned are language-specific subsets of IntelliJ.)
For code copletion I use PHP Intellisense but it still doesn't support multiple root folders in the same workspace. For debugging PHP Debug. vscode-php-cs-fixer and vscode-phpstan have helped a lot. In addition I use PHP Namespace Resolver and PHP DocBlocker. Lastly, PHP Getters & Setters may be useful.
Internally, I think PHP is great for prototyping. I have written systems in Go and PHP, and I think each has their strengths.
I like the batteries included standard library and single binary deployment of Go.
PHP, like others have said, gives you a single endpoint and you can make rapid changes. Its ideal for internal web apps that do not require insane performance.
In all seriousness... doees PHP have C# envy? With all of the stuff that has been put into PHP7 (like typed returns and typed arguments) and stuff being proposed (like annotations), PHP isn't that far off from being a interpreted brother of C#.
The point about Go; using those types of tools is generally frowned upon in the community. It's overkill for most (micro)services.
But few gophers build a full-stack website in a single application.
I'm a gopher; I wouldn't want to use Revel or Gorm. I feel I'd be using the wrong tool for the job.
I'd more likely use Django or Symfony when I'd need to build a full-stack SSR.
If a backend API is used by different clients (mobile apps, SPA, servers, ...) using a full-stack SSR framework like Symfony or Django doesn't make much sense anymore. You wouldn't use 90% of the framework's features. It feels like bloat.
But many websites don't need to serve different clients.
The author's decision to go from Golang to PHP makes perfect sense if he's building SSR websites.
Gorm is not bad but I don't think it is an alternative. To start with, the association requires some extra work to save/update which you have to do manually. In doctrine, this is done already.
Documentation, maturity, and community behind doctrine are a lot better.
Funny this, +/- 6 years ago when I last worked with Doctrine I had the same feeling about Doctrine itself. I thought it was a poor replacement compared to Hibernate / JPA.
I'm getting old ;)
Obviously things will have matured since then.
Doctrine implements the Unit of Work pattern. From what you're saying GORM is more like an Active Record ORM.
You're right, that wouldn't make it a good direct alternative.
It's obviously not as comprehensive as compiled or strictly-typed languages, but you can use "php -l" as a linter to catch obvious parsing/syntax bugs. I use this script to check our whole codebase before deployment:
Perhaps because they don't want to incur technical debt to a language/runtime that could change at the whim of one company that probably doesn't have other companies' best interests in mind?
The speed advantage of HHVM has also been largely erased. Some high-profile PHP sites migrated to HHVM before and up to ~2015, but I haven't heard of a single site doing that since PHP 7.0 came out.
> Perhaps because they don't want to incur technical debt to a language/runtime that could change at the whim of one company that probably doesn't have other companies' best interests in mind?
Go has been well received outside of Google. Wikipedia even has a list of companies known to use Go. I'm not sure how up to date it is, but the list includes Cloudflare and Netflix. At least some of them might have the oomph to fork, take over, or otherwise influence Go if Google ever dropped the ball.
Meanwhile, I can't think of any major online service that relies on Hack apart from Facebook and its subsidiaries.
But I agree with the original point about not fully relying on the whims of a major corporate promoter. Priorities can change within, without clear visibility on the outside.
There was a time when hack was new and it was so much faster than php. PHP really got their act together (nothing like a little competetive pressure) and made the 7 series that ran at almost the same speed as hack. People are inertial and won't change unless they have too or something is significantly better.
I fear you are conflating two things: Hack is the language (type system, syntax) while HHVM is the runtime (which can run Hack code, and could PHP until very recently). Your answer on the speed pertains to HHVM.
I only tried Symfony 1.4 and 2.0. And I'm doing Rails from 2.3 to 5.2.
I could go on a very long discussion about why I prefer Rails but at the end of day it's just up to you to compare.
When I started Rails I was building an app with Symfony, took me a week to get it to a good state and it was extra frustrating (I had been doing PHP for 5 years).
I started Rails, learned Ruby on Wikipedia and just general googling and got the same app in a few hours.
To be clear, this just means that PHP has libsodium as an official language extension. Most modern languages have better package management than PHP and make pulling it in as a library trivial.
This has nothing to do with homomorphic encryption, unless I'm missing something.
Golang is awesome once you submit and accept its intentionally mediocre design as a work of mysteriously genius simplicity. I did that myself and now I love it.
I'm finding that although golang offers type safety it introduces a new kind of error class to applications typically not encountered in web apps of the python/php/ruby/node class.
Deadlocks and race conditions.
For node, the entire app is a single thread so this just doesn't happen. For python/php/ruby concurrency is abstracted away and handled above the framework layer so the programmer never has to deal with it. You can launch threads in a route handler for these languages but it's not often done and you have nothing like a context object that is basically this abstraction leak that explicitly forces the programmer to constantly be aware of concurrency issues.
Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals.
After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for.
PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that supports functional and object oriented programming, many database management systems and has a package manager (composer). I really like PHP (see https://github.com/sandreas/m4b-tool for a proof), but some concerns about PHP have always been (and still are):
- backwards compatibility reaching too far
- way too big standard library (see levenshtein function)
- the "callable" concept - call_user_func_array([$obj, "method"])
- mixing up too many concepts (OOP, Traits, Functional style)
- the type system (which is getting better with php 7)
- unpredictable statements - empty($x), comparisons (== vs ===) and the "mixed" type
- the "array" type being array and dictionary and...
- the $ used for variable declaration
- $this-> is still needed for calling object methods
- "." for concatenation and "\" for namespace separation
Another bad thing about PHP is, that on most web servers it is meant to be stateless, which means that you are in trouble using technologies like websockets.
Some of these things unfortunately mean that PHP often is much slower than it could be - and this is where "go" can be a successor. Performance. If you really need FAST web apps and performance is the goal, go can be a nice choice. But for getting things done in a not too complex web page, i would always choose php.
> - the "callable" concept - call_user_func_array(["object", "method"])
For at nearly 10 years now PHP has had support for lambdas, meaning for most uses `$foo()` can be used instead and with the inclusion of the spread operator it's seldom used.
With the "callable" concept i meant, that many things are seen as callable:
[$obj, "methodName"] => callable for $obj->methodName()
"str_replace" => callable for function "str_replace"
["ClassName", "staticMethod"] => callable for ClassName::staticMethod()
"ClassName::staticMethod" => callable for ClassName::staticMethod()
function() {} => callable for a lambda
I would prefer a "ClassMethod" and a "Function" type, instead of using strings.
$x = phpinfo;
$x();
$y = $obj->method;
$y();
But i don't think, this is possible, because PHP supports global constants and function names cannot be distinguished from constants, especially because PHP is not case sensitive regarding functions and classnames.
But I see, that my karma has decreased with this post, so it seems, that not many are in my opinion...
PHP files can be deployed independently, swapped out or updated live.
No building/compiling of the php files needed.
A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers.
Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)
Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.
Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.
Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.