PHP is worth learning and using(bulletproofphp.dev) |
PHP is worth learning and using(bulletproofphp.dev) |
I started out doing PHP back in the everything-is-WordPress heyday. It was easy to SSH/FTP directly into sites and edit things live, and that was also a very normal thing to do. I got good at PHP and felt kind of defensive when people said how bad it sucked. Right tool for the job and all that. But, after some time doing it, I knew I wanted to break out of my PHP shell and learn another language. For some reason I felt like I could only pick one more language to learn, so I was hesitant to do so. I ended up going with Ruby. Only then did I understood what all the crap talk about PHP was about. It's probably both a language problem and an ecosystem problem. The ridiculous, complicated iteration over deeply-nested array-dictionary-combo data structures with various counters stuck in local variables here and there that I had previously considered normal vanished before Ruby's sleek Enumerable module. Of course you can code better PHP and avoid writing those kludges, but as a junior coder, that's the thing that stuck out to me when I switched from a PHP shop to a Ruby shop. Kludges and the worst inherited Frankenstein projects of my career. I swore I'd never work on PHP code again.
I spent several years doing Ruby, and along the way picked up several other languages and now can't fathom why I originally had such hesitation to pick one to learn. After gaining enough experience to be a senior engineer, a friend recruited me for a job doing PHP. This was at a big company with tens of thousands of enterprise customers, high-scale stuff. The money was good, and I had heard a lot about how PHP had cleaned up its act since the 4.x days. It's object oriented now and has a proper standard lib! I spent 3 years there, and I have to say the engineering talent there was good. Many ideas from other languages like Ruby's Enumerable had been replicated in our toolkit.
However, the vast majority of the code was still weird data structures that are unique to PHP development because of its lack's both real arrays and real dictionaries. PHP has indeed acquired standard lib, but many pieces of it still have a crap implementation. It's like they went out of their way to make lousy APIs for things like dates, times, and durations. In every other language I've used, you can easily compare time durations (is 1 hour longer than 1 minute?). PHP DateIntervals are not comparable. The API for creating a new DateTime object at a specific date is still to pass in a specially formatted string. Or, if you don't like that, you can create a DateTime for "now" and then mutate it to set the date. They may be adding language features to catch it up with other languages, but it seems like they're obstinately doing it in the most PHP-like way possible
Long-lived resources like database connections, Redis connections, etc. plagued us. We had a whole middleware in our stack dedicated to holding open proxy connections to things like MySQL. The thing that PHP enthusiasts say make it so attractive (edit, save, refresh) also bites you in the ass because PHP processes spin up and die with each request. There is no long-lived process holding onto those resources.
As of 7.3, It was still the same old PHP I knew back in 4.0. It's still crap and this time I swear I'll never work on PHP code again ;)
And yes, PHP is not as bad as it used to be anymore.
Apart from that, I don’t see a lot of benefits.
There’s a reason why people are generally not doing scientific computing, machine learning, hardware integration, systems programming, etc. in PHP (yes, there are likely some obscure projects doing all of those, but in general, it’s not done because of limitations in the PHP runtime).
If you already know PHP, you can probably have a long and healthy career in that space. But if you’re new to programming, you’ll probably be better off learning Python or Rust, or maybe one of the platform-oriented languages like C#, Kotlin or Swift. JavaScript is also a very popular choice, because it’s currently the only thing you can easily use in the browser, but that might change with the rise of WASM.
And there are big sites written in Python, too. Reddit, YouTube, some Google apps, Spotify, Netflix.
Rust is still a bit young, but also has several web frameworks like Rocket. No big case studies that I know of, but Rust still has many more fields of applications than PHP does.
For very large projects, however, I advise against it. The dynamic type system bites you a lot in my experience. I prefer static typing.
Don't get me wrong, I would not like to use older php these days. But just throwing 2 files onto an ftp was always php's biggest strength. It somewhat retains that for "installing" php, which still is often just "copy to server" which makes it really nice for users. But I feel it mostly lost that ease of use for people learning to program.
Now, it is still a solid language considering performance and such. It has proven itself to be. But without the easy way from zero to programmer, I am also not sure it is a better choice than anything else. Especially since it always had so many terrible footguns and at least in my opinion is also atrocious to look at.
This might be an unpopular opinion but I think PHP gained mindshare in the early days because Coldfusion (CFML) was neither free nor open source.
Disclaimer: I still maintain my PHP site from '08, so I'm current on trends.
It's a tool, use it or don't. Why do we have this weird slap fight every 2 months? It's so weird
"PHP is good now!" "No it isn't!" "That was PHP 4!" "array and string functions" "abstract it with a framework" "PHP is slow" "It isn't" "it is look benchmarks nobody will ever need"
See y'all in 2 months haha
From Pyjokes: Coding in PHP is like peeing in a swimming pool. Everybody has done it, but it's best not to talk about it.
Register globals was turned off in later versions of PHP 4. Magic quotes was turned off in PHP 7, released in 2015.
PHP today is no more "unsecure by default" than any other language.
roadrunner is a PHP server developed using golang, utilizing goroutines for high performance.
both used by Laravel Octane, providing very easy integration with the framework.
Other than that, php-fpm & FastCGI allows integration with many interestin webserver including Nginx, Caddy, Lighttpd, etc.
[1] https://github.com/swoole/swoole-src/issues/4434 [2] https://news-web.php.net/php.pecl.dev/17446
If self-hosting, Nginx and FPM is well-tested and very fast.
At some point you ask yourself - why did I do all of this to a Model T? Sure, it has some modern facilities but the language itself was never designed and so none of it feels cohesive. The syntax is off-putting. It's just a ton of nightmare for what reason? Why? There are so many other languages to choose from and PHP has no competitive advantage other than $3/mo GoDaddy hosting.
The PHP dev will look at a Model T DIY'd into "The Homer", and beside it a 2016 Toyota Corolla.
The PHP dev will argue, sincerely, that The Homer is just as practical of a daily driver as the Corolla. You have to just walk away from this kind of person.
In the early days of Mono, there were some attempts at using C# outside Microsoft circles, like building Gnome-apps with GTK#, but most of those projects have faded away.
"How do I make a web page talk to a database?"
I'd say: Well, you know that HTML file? Rename it to become a PHP file and you're almost there!
As pretty much all cheap hosting already offers support for PHP (and MySQL for that matter) this would almost always work.
I would love to be able to do this with NodeJS, but imagine teaching that to an absolute beginner. The conversation would have to begin with hosting platforms / SSH / server management / reverse proxies etc....
In a similar fashion, I abstracted away the database connection, query and returning of results into one lazy-inited function, so talking to the database really was just like
<?=q("select name from users where id = $userid") ?>
PHP's parameterization features in PDO can be abstracted so you can turn this into:
$vars = array(":userid" => $userid);
q("select name from users where id = :userid", $vars);
[0]: as in, I would have nightmares trying to introduce beginners to full JS stack vs I would have nightmares thinking what they will end up coding when they easily become dangerous with PHP (which is I guess why there are so many bad PHP codebases: it's super easy to start)
Will never understand why some people find that so offensive and will tell you that you mustn't use it or imply that you are ignorant or stupid for using it.
I think JS can be worse. There are things that are possible with dynamic languages that are literally impossible with static ones.
So think of PHP less as a "bad language" and more of a code smell.
Requesting `index.php?something=X` implied `$something = "X";` in the global scope at the beginning of "index.php". And since the global scope was not limited to a file, tracing a variable through files and side effects was a nightmare. Even understanding the code intent was often hard!
Before PHP7, there were many elements of the language that were meant to simplify its usage, but had awful consequences in many cases. Even more because it bent the PHP community toward a quick and dirty process. "Magic quotes", the automatic escaping was one of those abominations. For any request input (e.g. POST form data), it added backslashes before single quotes. It was meant to protect data automatically in case it was inserted into a SQL request... It granted no security gain in this context, and was a mess for any other use.
Surely that depends on when the PHP in question was originally written.
Lots of new good things in php7/php8. The typecasting is way better than before, but it still allows you to be more "dynamic" if you want to.
- Web frontend: Javascript/TypeScript
- Web backend: Javascript/TypeScript, Python
- Performant backend (where you manage threads and queues): Go, Java, Rust
- Machine learning: Python
- Command line scripting: Python
- Command line tools (binaries, eg 'ripgrep'): Rust, Go
- Mobile: Kotlin, Swift
- Systems/bare metal: Rust (discourage C/C++)
- Desktop games: C#, C++, GLSL, Rust (in ten years)
Mix and match.
The safest three to learn that give you the most flexibility are probably Javascript/TypeScript, Python, and Rust. You can build almost anything with those three.
I've done shell scripts in PHP. Mobile development in Ruby, JS and haxe. Web development with Go. Nothing is stopping you, and if you know the language it is usually not to weird either.
Recent example, while Android has adopted Rust for replacing their bluetooth stack, the newly introduced Android Games Development SDK focus on C and C++.
Or Microsoft, despite all their security speech, Azure Sphere OS and RTOS only support C on the official SDK, and the new WinUI components are all based on C++.
And naturally anyone wanting to contribute to the Rust compilers, most likely will need to brush up their C++ skills if they intend to mess with GCC or LLVM internals.
C++, though, agreed.
Sure, Rust is _fun_ but there's little demand for it right now in the market.
You didn’t use “I” at all, but it seems likely there are some other rules going on here.
"I have used PHP for years." The first sentence establishes the subject is "I".
"Like it." etc Because this sentence doesn't have an explicit subject, it is implicitly the same one, "I".
As I recall, "wa" and "ga" were the Japanese particles which established new subjects. Say you wanted to talk about Bob's new car, you'd say something akin to "About Bob's new car, is expensive. Arrived last week. Has poor gas economy."
You notice the pattern. Mimic it. Struglle with it. Persevere.Endure. Will you reach perfection? Maybe not. No problem. Satisfaction is few layers below.
Not sure that I have any tips for you. Other than that it is often helpful to remove unnecessary words when communicating. This is something I have become sensitive to over the years. I used to write a lot more voluminously but I find it is harder to convey messages to people when they are confronted with a wall of text.
Coming from a C background, I found PHP easy to step into as many of of the underlying libraries and common functions are wrapped and available in PHP (with similar names).
PHP shines when you're trying to get a server-rendered web app off the ground. It's the VB6 of the web. Nothing else matches its development velocity, from keyboard to working code.
And may His Noodly Appendages help you if you come across a function being used which has no documentation and a single decade-old comment from someone asking how it works...
And so, to plaster over it's many flaws, people start layering framework upon framework upon framework, each of which slows down the language significantly from all those shiny PHP performance benchmarks you see. And then they wonder why their shiny "what's an array? we need to transit 20 different chained method calls for that" is so slow...
And half of them are documented even more poorly than PHP itself. At least their code is in the same language you're already writing, though.
The non-documented functions are often rare and very minor and obivous functions.
This layering framework on top of frameworks sounds made up. Mostly people either use Symfony or Laravel. There aren't layers of frameworks. Your example is nonsensical. Frameworks are slower than simple code, this is true for every language.
And Symfony and Laravel are both well documented.
This comment overall seems to be written by someone who has come in with very little knowledge on PHP worked on a project for 3-4 months. When you work those style projects you're often working on poorly constructed projects. I'm pretty sure I can jump in on a project written in any language that has been poorly constructed and I will end up going wtf.
The non-documented functions are indeed often rare. That's all that can be said about them. They're about as obvious, on average, as the rest of PHP's functions are obvious.
Sure, until you want to have a UI framework, and an API framework, and ...
LOL @ Laravel being well documented. There's a tutorial and there's autogen API docs. And that's it.
This comment overall seems to be written by someone who has worked with PHP for a few years and thinks he knows everything there is to know about it.
I've been using PHP since PHP3 and professionally since PHP4, but thanks.
Nice work PHP
I haven’t worked in PHP for I don’t know how many years, and I probably still have an unfair negative reaction to it. It has a strange cultural idiosyncrasy I find more limiting than anything about the language itself. But I’m happy to see it evolve and I’m happy to see it evolve alongside other technologies I work with more readily.
> You might have heard people say that PHP was "doing serverless before serverless was a thing", and this is kind of true.
I believe that PHP is...not bad I guess? I'm sure it can make good things. But after reading this I have no idea why I would pick up PHP over any of the other capable tools out there.
I worked with PHP 9-10 years ago. Still not impressed to this day. Why should I use it? Terrible type coercion that can and will catch you with your pants down is my chief complaint -- that alone is enough for me to never touch it again. I want predictable tools, not something I actively have to fight against so I can get my job done. How is this even considered productive?
So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
*Python* A disgusting level of flexibility (probably too much). You never really get trapped into anything, you can even (but should not) overwrite functions during runtime. You can make and break all the rules. Supports a number of modalities (often badly). Really killer console-based debugging tools (I love pudb for instance).
*Elixir* Insanely durable data/process model that makes it incredibly difficult to damage a working path through a non-working one. Never have your entire web app crash again. Pattern-matching and message-passing based language makes expansion easy and low risk. Macros are best used carefully but when appropriate are a breath of fresh air.
All the languages are turning complete. By definition you can solve any problem with any of them.
In the Python ML world only the matrix libraries - numpy and similar APIs like torch.tensor and jax feel natural and click in my brain. The rest - data frame, visualization, scientific libraries; I'm not very sure how to explain it, but it always feels like some context switch is needed between using Python the language, and calling out to these libraries.
I also like other languages, some because they are a pleasure to use, or give me an opportunity to learn something new... but mostly because they pay the bills.
I don't think there is anything wrong with that, these are just the tools of the software engineer, nothing more. We use the tools that are appropriate for the job, no reason to make it into something deeper than that.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
it's faster than python, but my grandma is too and she died in 1993. However, function calls are extremely slow. If you would bench something like a naieve fibonacci implementation (or ackermann's function) you would be surprised.
If someone is new to software development and in an area of the world where it's not mostly PHP shops, so bigger cities, I don't really understand the benefit.
PHP is often used to do certain things or it may be faster for you to whip something up in Laravel but if you had someone who was a complete blank slate and could chose any language and any framework in a town that doesn't have PHP jobs...why? What's the reason then?
I really think these articles come off really strange like they're trying to convince me as a "fact" but are really just nostalgia, like someone who goes off about how "cars were built so much better back in the day, there's still uses for older cars!" Maybe there is a grain of truth there and some real reasons behind it (repairability) but for 95% of use cases it's just that there's no contest, for a new driver, in an average situation there's no benefit towards going to an older car, and the guy going on about "older cars are the best", while they may have some weird reason that does actually apply to them (and as far as this analogy goes, I think Fortran is a better example than PHP in this case than PHP as for some maths applications it apparently still has an edge but that could have changed) honestly it's just nostalgia/trying to indoctrinate people...
You might as well try to convince me I should start my next business with cutting edge software written in Fortran or COBOL.
That said, php's online documentation is one of my "gold standards" for what good language documentation should provide. (At least it was the last time I had to reference it.)
Is php totally worthless in 2021. Absolutely not.
Is php the best language to spend your limited time learning in 2021? Almost definitely absolutely not as well.
What I do not like is the syntax. Call me picky but referencing attributes with -> instead of a dot (.) is ugly to my eyes and I prefer JS, Ruby or Python when it comes to the pure look of the code.
Generally I'm not a fan of dynamically typed languages because I just feel way more productive when I have proper code completion and type safety.
In general whatever works for you and makes you happy is good enough.
:)
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
The PHP language can be used as a templating language itself:
<?php
$user = 'root';
?>
<p>
Hello <?= $user ?>
</p> @page
@{
var user = "root";
}
<p>
Hello @user
</p>Only thing which hurts there: not everywhere deployed like PHP is :)
And technically you need a 2 files boilerplate. But that will vanish within the next year when I understand the .NET team right.
- Is the "your app gets initialized and torn down for every request" true for frameworks like Laravel and Symfony?
- Does this model uses OS threads? Does it uses green threads?
And then a few remarks about the language:
- I feel like the Go model is a way better model for server software than async. Since PHP is mostly used for server software, I feel like they shouldn't go with async. Python is currently going through the transition and it's painful and long.
- It feels a bit weird to see how full of objects PHP is. Modern languages (Go, Swift, Rust, TypeScript) tend to use less objects, and more plain imperative code or slightly functional code in my experience.
However, error handling continues to be an issue. It isn't uncommon for PHP to fail silently. That would be one complaint I have against PHP.
Not only this, but PHP/MySQL is such a reproductible stack, if the code is properly written you can run the same app on tens of different server configurations (Windows, Ubuntu, CentOS, various versions of MySQL and PHP) without having to change anything.
IMO that's extremely powerful in its simplicity and while you can get it in other languages, it feels like like a "core competency" for PHP (just like how async code is easier in javascript than in python, because JS kind of had it from day 1)
It adds its load of complexity on how to run the apps itself, you need an external server, apps often requiring some customization of the server that will run it (either mod-php or php-fpm). It means that parts of our app settings lives outside of the app, it also make updating php itself quite annoying.
In my opinion, high level languages should not expose async primitives to the programmer - this should be abstracted away by the language and its runtime. Go is doing this (all I/O is async under the hood), and it's awesome: You can write synchronous/sequential code and get the performances of async. I would love if other languages copied that.
Modern PHP wears a business suit and wants to buddy the "big boys" (Java/C#) of the world. You'll have deployment pipelines, strong push towards classic OOP, strict type checking etc.
I personally think ruby for instance is leaner in its dev process in most real world projects.
Furthermore if I'm working with JS/TS, hot reloading even makes it so I don't even need to refresh the page. I can even inject code into arbitrary places with the debugger (as if I'm editing the source)!
So, all these other ecosystems are on par with the PHP...
I'm glad PHP adopting ideas from other communities, and that the community is becoming more cohesive, though.
Aside: I used to write PHP before (back in the 3 to 5 days), and worked for a big web hosting provider that had a big shared hosting customer base; PHP was by far the most popular technology in that space.So, I'm not trying to bash on PHP.
Locally however it is save, alt-tab, ctrl-r and immediately you see the result. Absolutely no waiting.
These days I rather use Quarkus for this but until Quarkus arrived this was a huge advantage that PHP had over every other language and framework I was aware of.
Also the documentation was fantastic compared to most of the stuff I have had to suffer through on Java, .Net and even React and Angular.
Every thing you may reasonably wonder about was described in a clear, straight forward way and included examples.
PHP already has caught up to others with 5.6, these days PHP 8 doesn't lack anything found in other major languages.
What is still confusing is the standard library, but only for people who never worked with C/C++ before - as most of the native PHP standard library actually originates as a verbatim copy of the C/C++ libraries.
1. WordPress uses it
2. PHP is far less terrible than I remember (having used it in very early days)
I manage a WP (woocommerce) site for a small business. It's not my day job, it needs to be simple. Most of the "day job" is handled by content management users. I have written a fair amount of plugins though to enable custom functionality and the process is perfectly fine.
I looked at Ruby, I looked at Python, I looked at node. There's nothing as simple and, frankly, as mature aside from commercial platforms like Shopify that charge an arm and leg.
The two things I can think of quickly, that I like about php, over another, is the ease of code->browser. You have to manage 0 build configurations or pipelines to get what you want working. Just download the files and open a browser. The second, is 100% transparency with third party libraries. Because of the lack of ability to compile, when I download a third party library, I'm getting their actual true source, and can much easier, navigate and understand the library right through the ide, without having to read a bunch of docs online and that it's true to source. Being able to control click into third party libraries is quite liberating.
But maybe this is just me.
There's not a lot that is comparable to the PHP ecosystem when it comes to bespoke web-based e-commerce, or anything to do with bespoke customer or content management.
If you're trying to integrate with some weird 3rd party API, chances are there's going to be something written in PHP, or you can easily pay someone to do it for you.
Not only this, but there are agencies providing long-term support for parts of this ecosystem.
Other languages with strong ecosystems in this area would be Java, or Ruby, I think. I like Java for the same reason, and would probably like Rails. Anything that has "batteries included" is good to me.
2. The PHP ecosystem is quite mature, and packages are of good quality in general
3. Dependency management works well. You will rarely end up in a state where your dependencies are incompatible between each other (something that happen often with npm for instance)
4. It's faster than python/perl/ruby
In general I would never bring them up on this site. It's just not worth my time or effort. I've even gone so far as to ask people who have posted my blog posts here to take them down. Hacker News has one of the worst groupthink cases in tech, where if you speak against various core beliefs you get absolutely hammered with trolls both on the site and off of it. Having a reasonable discussion about the pros and cons of PHP is just not something this site is capable of supporting.
Also, same as many other open source languages, there seems to be a tendency to pick up every language extension someone proposes hoping that it might win over some developers, but I'm not really convinced. Does PHP really need a "match" control structure (https://www.php.net/manual/en/control-structures.match.php) when it already has good ol' "switch" and "if/else"? Of course, I also like the more flexible (Pascal/)Go-style switch statement better than the "classic" C-style one, but maybe they should have given it some more thought years ago instead of slavishly following C/C++ then and inconveniencing thousands of developers by introducing a new keyword now?
Particularly, PHP 8.1 has some changes that low key force people to update, such as the use of return types when extending a built-in classes (https://php.watch/versions/8.1/internal-method-return-types).
As someone who still owns their rent coding PHP, I really enjoy the development of the language from php 7 onwards. It certainly feels better in any way compared to the 5.x or even 4.x days.
As long as we do not get another python 2 vs 3 disaster, I am happy.
Using ASP and want to calculate an MD5? Oh, you need to pay an add-on for that. Want to send an email? Ditto.
Then there was PHP, with all included (and cheaper hosting, because Linux). I started working on a web shop and after a month ASP was legacy and PHP the new cool thing, together with MySQL instead of using... Access as "database" in ASP.
If having the same code working for a long time is the most important for you then you should probably use java or .net. Maybe c++ also but that is not as popular for building web apps.
Then I didn't have enough time to maintain it, and I stopped paying attention to it for a while.
Later I checked my homepage again, the webhosting company updated the PHP version, nothing works anymore. It is not simple to fix, so I gave up.
I am not going to spend the same amount of effort on making my homepage in PHP again. Trust is easier lost than gained.
I would still be willing to code something in PHP for someone else, because hey, if it stops working in a year or two, it's their problem, not mine. But I would warn them that something like this is possible, and in my opinion likely to happen.
It's very hard for me to treat a language seriously when I could write code that simply won't be valid PHP in 2 years time, or worse, behaving differently.
Given the severity of some past PHP vulnerabilities, being on an old version can certainly be a problem.
> I guess they might do it again from 7.x to 8.x, we'll see.
PHP 8 has some _massive_ breaking changes
So yes, let me express my antipathy toward the PHP language and its ecosystem.
I work not "well". It has hundred of issues that are not, and will never be addressed. Like the inconsistent choice of function names, the antic (if not prehistoric) way of extension managing, the clumsiness of xdebugger, the bugs in the PDO library, etc.
I spend 80% of the time trying to figure out "a hack", and spend too much time on php.net & stackoverflow hunting for the right answer.
But that's just not true.
All the things you mentioned are a yum/apt/nix/pacman/ install away on Linux, and probably as simple to install on macOS. I'm sure Windows has installers for these, too.
So, it's no harder to develop in them than it is in PHP.
You could argue it's cheaper because you don't have to pay for a shared hosting provider to host your files. However that's a bit moot since even back in the day there were LAMP stack Vagrantfiles that would automate this local setup.
Also, when speaking about dev velocity or time-to-start: you forgot JavaScript, which probably has much greater development velocity than anything else.
Furthermore, PHP is rarely just PHP in production. PHP also comes with various runtime modes (CGI, FPM, etc), .htaccess rules (or nginx equivalents), a bunch of runtime language and feature toggles that are partially controlled by the system (ie your hosting provider), and some can be controlled by the application.
The ephemeral process nature of the language makes some tasks very difficult to do in a performant way (but there's caching, so that's at least mitigated).
I've seen so many developers (worked for a hosting company) come complain to us about slow servers when in fact they'd just be doing silly stuff. And it was hard to blame them, because the language encourages that model, and the "performant" was was usually orders of magnitude more difficult to implement (ie indexing, image resizing, or most types of batch processing).
I'll not go into the horrors of how easy it is to mishandle file uploads in PHP (there's plenty of those around) and how many times people got easily hacked this way.
However, I think this recurring misconceptions how easy PHP is to develop in needs to stop. PHP comes with a lot of complexities. Worst kind of complexity to learn: hidden complexity.
I'd rather say that this is actually one of the biggest selling points for PHP. Opcache and JIT works great, and reduces the overhead, but ironically, PHP is great for serverless applications.
I do a lot of work with PHP, both legacy and new code. The number one mistake I see with PHP sites set up by amateurs or cheap hosting services is running Apache+PHP on the same server as MySQL or Postgres. Separate those and performance and stability problems go away. That’s because relational databases consume as much memory as they can get, not because PHP is inherently slow or unstable.
<?php
function fib($n)
{
if($n === 0) { return 1;}
if($n === 1) { return 1;}
$r = fib($n-1) + fib($n-2);
return $r;
}
$n= (int) $argv[1];
$r = fib($n);
printf("%d %d\n",$n,$r);
| Language | n | time(s) |
|----------------------+----+---------|
| php (7.4.25) | 42 | 422.0 |
| python3 | 42 | 90.0 |
| haskell (ghc -O3) | 42 | 13.8 |
| f# | 42 | 5.6 |
| ts | 42 | 2.8 |
| ocaml (ocamlopt -O3) | 42 | 0.98 |
| C (gcc -O3) | 42 | 0.66 |
time php fib.php 42
23s
time python3 fib.py 42
1m1s
If we're talking in comparison to slow interpreted languages like Python, then function calls in PHP are not particularly expensive. Debuggers can make them quite expensive though.
Edit: Just to note, PHP's execution time drops to 4s with enabled JIT.
Yes this is a microbenchmark. Yes, I know binet's formula... Yes it's weird function calls are so slow in php.
with php 8.0 (jit enabled) you get something like 120s (for n= 42)
https://twitter.com/ArkadiuszKondas/status/11196548025800212...
PHP 8.0.12:
$ time php fib.php 42
42 433494437
real 0m29.274s
user 0m29.003s
sys 0m0.105s
$ time php -dopcache.enable_cli=1 fib.php 42
42 433494437
real 0m26.341s
user 0m26.179s
sys 0m0.058s
----------------------------------------
PHP 7.3.5:
$ time php fib.php 42
42 433494437
real 10m23.573s
user 10m16.592s
sys 0m1.828s
----------------------------------------
Settings for PHP 8:
PHP Version => 8.0.12
auto_globals_jit => On => On
pcre.jit => 1 => 1
opcache.jit => tracing => tracing
opcache.jit_bisect_limit => 0 => 0
opcache.jit_blacklist_root_trace => 16 => 16
opcache.jit_blacklist_side_trace => 8 => 8
opcache.jit_buffer_size => 0 => 0
opcache.jit_debug => 0 => 0
opcache.jit_hot_func => 127 => 127
opcache.jit_hot_loop => 64 => 64
opcache.jit_hot_return => 8 => 8
opcache.jit_hot_side_exit => 8 => 8
opcache.jit_max_exit_counters => 8192 => 8192
opcache.jit_max_loop_unrolls => 8 => 8
opcache.jit_max_polymorphic_calls => 2 => 2
opcache.jit_max_recursive_calls => 2 => 2
opcache.jit_max_recursive_returns => 2 => 2
opcache.jit_max_root_traces => 1024 => 1024
opcache.jit_max_side_traces => 128 => 128
opcache.jit_prof_threshold => 0.005 => 0.005Let me give you an example;
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-python3-2.html
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-perl-4.html
I have seen the same unjust comparison with the majority of the examples and decided to stop relying on this page for validating programming language performance.
No they do not.
Let me give you an example:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
*** You ignored the Python code that does not use ctypes.
> I have seen the same unjust comparison with the majority of the examples…
No you have not.
There are 10 different tasks.
pidigits accepts the use of third-party libraries (GMP)
regex-redux accepts the use of third-party libraries (PCRE)
That's 2 out of 10.
In comparison, other programming languages are hard to figure out. Python, Ruby, Java etc all need some kind of a package manager to install dependencies (PHP apps are self-contained) and need to have the correct runtime version installed (PHP just needs to be in the general neighborhood of what's required, since most broadly used packages seem to be written in a backwards compatible fashion). This is scary and unfamiliar, and highly technical. If you're deploying on a VPS (because rarely anyone has managed Python/Ruby/Java hosting services), you've now also become the sysadmin with full responsibility for the box, including patching and downtime. Compared with shared PHP hosting, it's bonkers.
> package manager to install dependencies (PHP apps are self-contained)
PHP has Composer, which is one of the best things to happen to the ecosystem. Chances are, the piece of software you install will manage its dependencies in this way, and I'd be reluctant to install it if it didn't, as you wouldn't be able to update the software easily.
Not a fan, but that is definitely a very good argument.
Then you have the myriad of static site hosts that also take 2 clicks to host something without even having to write any code.
If we're talking about simple templates to open a store or a simple landing page there are so many no-code options like Wix/Shopify/SquareSpace/Square that I don't think PHP offers any significant advantage.
Languages tend to go through a few years of flavour-of-the-week fads (think of the Vue/React/Angular competition, and all the also-rans that we can't remember now). If you get in too early, there's a fair chance you'll bet on the wrong ecosystem, and end up with unsupported dependencies or difficult to maintain code. In the worst case, you scrap the whole thing in six months and write it for a new framework to keep it alive.
PHP went through that phase back when "we've got to support IE6 users" was a legitimate talking point. You can be reasonably confident Wordpress or Laravel are here to stay.
PHP is also fundamentally a hugely battle-tested platform. It's been ran on 486s in the broom closet, and entire rack clusters in data centres. If you have some performance or usability problem, there's a good chance someone else has had it already and worked out a solution. With some new language, your odds of "never seen that before" errors are much higher.
These days I write server code in C++ :(
I look at it this way sometimes: there are the interpreted languages, the VM-based languages and then systems languages.
PHP is a good option in the "interpreted" languages category, if your problem domain is web-based, as it includes a lot of built in functionality for web-based problems. It's also open-source, reasonably performant, has an improved type system, has a C-like syntax and enjoys features inherent to a scripting language e.g. fast startup time, so would be a good option for lambdas.
Finally, one of the features that has been unreasonably good about PHP is the shared-nothing request model, which makes running a website on PHP a stable experience, in an imperfect world of weird state issues and libraries that might sometimes have a bug that leaks memory.
There are also other options in the "interpreted" category which I would fully expect people to also look into, however that's not to say PHP isn't a good contender for this space, given learning time is a limited resource.
However I would expect people to know a VM-based language and a systems-based language (or at least a bit of one) in addition.
Do you plan on creating a start-up that you intend to scale to a babillion customers? That you intend to hire teams of developers for? Probably not a good idea.
Are you a new programmer trying to figure out which language to learn first? Absolutely not. Python, Java, JavaScript, C# are much more flexible if nothing else. Anybody who tries to convince new programmers to learn PHP is doing them a great disservice.
Not interested in PHP in the slightest, but how is this myth still going around?
Wikipedia, Pornhub, Facebook (initially at least) were all built on PHP. There are hundreds of other examples.
Laravel nowadays has an outstanding reputation and I doubt it's performance is lagging so far behind Django for example.
More generally, after all these years I still need to see a story of a startup that failed because they chose the wrong stack. There are some blog posts with spurious claims in this sense, but really, when has a startup with good product-market fit and a finely designed product ever failed because they chose PHP instead of something else?
But I agree with you.
It depends what location you're in. In Europe there are pockets where PHP is very popular, where learning it can open up the job market.
In Europe there is a lot of PHP. Even in the bigger cities. And as someone who knows a lot of different programming languages, modern PHP with Laravel is pretty hard to compete with on a productivity basis.
The point is not to prove that one language is better. For the most part, for web development, there isn't much difference in productivity for a programmer competent in the language between (JS/NodeJS, PHP, Python and Ruby) Java is a little more heavyweight for pure web development but if you have a bunch of backend services that need to be reliable you will find the type system to be of help.)
What is more important for productivity is a deep familiarity with the frameworks, and tools -- the IDEs CI systems etc. that you need to build and deploy your solution.
The other important thing is the ease with which you can hire programmers for that language in your market. Here in India finding PHP programmers is easier than say finding Kotlin programmers but harder than finding Java programmers. But that is not the case in other markets like the US. There is also the issue of perception of candidates. If like you, a large majority of candidates think the language is legacy, you'll end up having to pay more to hire them (because they will be harder to find -- most of the extra cost will be search costs not salary costs.)
To the extent that the PHP community can convince folks that it is not a legacy language (and it really isn't) that is good for not just the language but the overall tech community. And this article furthers that goal well.
You’re getting ready to launch, and you’re going to need a marketing site and a site with documentation and help articles for users. Do you write that site in Go?
Hell no. You hire someone cheaper whose skillset isn’t systems programming or ML, and they spit out a templated site in a weekend that looks sleek and makes a good impression, and when you need more content you tell them and they turn it around in an hour, and you spend your time on the Go stuff.
And that market, the market for Good Enough sites that front Really Good products and are fast to work with: that’s a great market for a lot of people who want to sling some code, get things done, clock out at 5 and spend time with their kids in a nice house in the suburbs. That’s why for people who want that kind of life, I recommend learning some PHP (or rather, learning the super-common frameworks that use PHP).
Hum... Probably. (I personally have a thing or two against Go, but yes, probably.)
Is the site some empty generic marketing that you'll put up to fill a feature list or is it meant to be useful? On the first case, sure, go offshore to somebody cheaper.
But on the second case, the time you can waste due to language, framework, software architecture and every other technical aspect is almost irrelevant near the time you will spend creating content. And you can't offshore the content if you want it to be great.
Yes! https://gohugo.io/ would be a great choice for that kind of thing.
I mean most of the marketing websites are build with such PHP tools.
Honestly if all I needed was a marketing site and a place to host my documentation, I would 'write' it in something like Squarespace.
But the trend didn't continue. People did it for a whilw, but then moved on to other models which still worked for PHP because few apps really need live data and concurrency like that.
The problem for PHP is that the reputation for being "a dying language" stuck.
I added more value to a tech agency and their clients with PHP than several of the senior Java guys did combined. And they were talented. Just set in their ways and lacked a focus of getting things done and adding value.
They'd waste time overbuilding shit that nobody used because it was interesting to them, not that it would create value for the client or end-users.
Also, I took over several large Node projects built by hipsters and they are the messiest code bases I've ever seen. And I've inherited a lot of trash PHP ones over the years.
Regarding the concurrency thing with PHP - ReactPHP is very nice, PHP 7 and on performance gains were massive, and real-time (search, chat, etc) can be better handled by Algolia/Pusher/etc anyway.
The Node hype train had a great run. And I still like Node. But PHP is the language of getting shit done.
it's quite a nice language, and for many many cases is certainly fast enough these days.
Depends if you want a job or not.
At least in many European countries, there are plenty of them doing PHP.
In fact, when doing our Java and .NET consulting sales for Web projects, PHP is the adversary, not Python, Ruby, Go, Rust, or whatever is on the frontpage, like everyone likes to discuss over here.
Those "few dozen hours" reading PHP docs and tinkering could also be used to learn Python, Ruby, or Javascript, each of which are almost certainly better choices with broader applicability and more modern ergonomics.
Python gets you web backend + ML, Javascript gets you web backend + web frontend. Ruby gets you a multi-paradigm language with nice ergonomics and cats. PHP gets you job offers customizing Drupal and Wordpress websites.
If you already know a "scripting language most popularly used for websites", then you could choose to pick up Rust, Nim, Go, Swift, or Kotlin instead. It's much better to have a new kind of tool in your belt than a second hammer.
The world is full of so many choices. PHP has a lot of incredibly compelling alternatives. Unless your job demands PHP, you're probably better off looking elsewhere.
1. You're using it for actual work
2. Learning it will teach you something fundamental
I feel like the only way 2. might happen with PHP is if it's the first language you're learning.
By learning PHP, you are effectively locking yourself into the narrow niche of backend web development (ask me how I know!), whereas other languages have much broader target platform appeal.
As an example, the obvious competitor to PHP of Javascript already beats PHP by also providing backend web services, but also has support from AWS lambda, GCP Cloud functions, and even the somewhat esoteric embedded javascript for micro-controllers options.
> Do you shoot for what has had longevity, or what's rising?
Coming back to your original question - I think it's both. Depending on what you wanted to do, I'd pick Javascript (see above), then depending on what else you wanted to do, one of Golang, Python, C#, or Kotlin.
The question is who's hiring/where will you work, and what will you work on? In my area, there aren't many PHP shops. So it could be Wordpress or Facebook/Meta. PHP might be long-lived, but if you have to relocate to find a PHP job, does that help? Same with e.g. COBOL, Sharepoint, etc. And to be fair, what's rising has that problem outside tech centres.
Something popular like Python is generally a "better" investment, covers more bases.
But what is, if not Motorola 68000 Assembly? Do you shoot for what has had longevity, or what's rising?
Pointing out that there is not absolute certainty about what is the top choice for a better idea does not make php, or visual basic, or 68000 worth spending your time on in 2021.
Some popular choices in this bubble seem to be:
- clojure
- common lisp for some reason
- php is mentioned often here, also not sure why
- rust
- swift if you're into ios/apple, kotlin if you're into android
- typescript
Yes, though heavy optimization in opcode caching and JIT keeps it fast and the primary process manager today (php-fpm) generally keeps a pool of PHP processes persistent. Each request is initialized from scratch but there's no disk nor interpreter hit after the first.
There are, of course, frameworks that simply handle HTTP requests directly (amphp, swoole) that operate as persistent application servers, so state is maintained.
> Does this model uses OS threads? Does it uses green threads?
No. PHP webserver backends are generally a long-lived forking model.
> I feel like the Go model is a way better model for server software than async
Swoole [1] offers a coroutine and channel model. It's incredibly fast and the techempower benchmarks [2] attest to the raw speed.
> It feels a bit weird to see how full of objects PHP is
Agreed. It's often way over the top with Java-esque OOP complexity. It does depend on the libraries in question but the popular ones are very heavy (Symfony). You can of course write very simple imperative code just fine too.
https://symfony.com/doc/current/configuration/micro_kernel_t...
Many other PHP projects, such as Laravel and Drupal pick-and-choose Symfony framework components in this way.
* If you have a memory leak your complete server will get killed some time later when running out of memory * If you have a bug which crashes your web server every running request is killed * You get all the hard-to-find concurrency bugs when multiple requests concurrently can access some objects.
With PHP's model of (1) initializing and destroying all the state on every request and (2) every request running in it's completely isolated virtual space you don't have any of these problems.
And if you really want to have a long-running server with shared space you can have that too, take a look at Laravel Octane.
q('select name from users where id = :userid', compact('userid'));
q('select name from users where id = ?', [ $userid ]);
That's true, but as a beginner I feel like starting with Rust is a lot more accessible, and could help someone switch into C++ later.
So from that point of view, learning about lifetimes, modular code, and that bounds checking isn't evil are already good education stepping stones.
With PHP, you install the toolchain, save a file and the page becomes available.
With JS/TS, you install the toolchain, and then enter a complicated process of yarn/npm incantations in the command line to get the project working right. The manual may say "yarn add typescript" but in practice there's always more setup and configuration to be done before it works well.
For "real" projects, there's not that much of a difference between yarn and composer. For getting started, though, the process is a lot more involved.
Another problem is that running Javascript on the backend is almost completely different from normal frontend development. If you want to store state, you end up using the same (or even worse, a similar) programming language with completely different contexts and available libraries and methods. You can't document.createElement in the backend to tell the user that an operation succeeded or failed, even though that's what you'd do if you were working on a frontend file.
With PHP, you can't do frontend, so whenever you write frontend code, you can't get confused. In my opinion, this makes learning PHP backend dev a lot easier. It's only natural that you choose to continue working in the language you've started you development career in. You can see that by the fact that there are still people who swear by VB.NET, despite everything.
The JS ecosystem does have the advantage of coming with a debugger, but PHP users can get the same by hooking their PHP install into the PHPStorm debugger. I think it doesn't matter much which language you use at that point, it's just a tooling preference.
All in all, I think both languages have their uses. If PHP really was as bad as people say it is, it would've died out already.
Maybe you haven't heard of startups failing because of choosing the wrong stack, but I'll wager you don't hear about most startups failing because...why would you? Also, have you heard of startups re-platforming? Either because the current stack is falling apart or the company is acquired by a bigger fish and they need to integrate with other services so parts end up getting rewritten to Java/C#.
The fact is PHP is good for making websites, and that's all you'd really want to do with it. There are other languages that are good at making websites and they are more popular and have other benefits.
If you are building things with PHP and it's working for you, then awesome. But seriously, why encourage it?
I had a friend in college who would always point it out (in English, where it's not very common). I still notice it often years later and I'm pretty sure it's thanks to her making me aware of it.
Thanks for the insight!
Do any other languages have the same kinds of optimisations that PHP has with FPM where it keeps the process alive but pretends it's a complete fresh execution at the language level? (getting the performance benefits of a persistent process, while having the simplicity of CGI-style execution).
I know that's how the TCL and Perl FastCGI implementations work. I suspect that's how most of them work, and there's lots of languages supported by FastCGI.
I'm not aware of other languages where it is baked into a language itself, but FastCGI libraries tend to be basically drop-in replacements for CGI ones (at least it's the case with common C, Perl, and Haskell libraries; sometimes CGI and FastCGI libraries are combined, so that they are usable in either setting): you get the optimization, while still can pretend that it's a regular CGI. I guess the primary difference from PHP is just that global/static variables would survive.
Doesn't all that make you long for the days of ./configure --prefix=/somewhere/sane && sudo install -d -o yourusername /somewhere/sane && make install? Just add empscripten to the tool chain and you can do web things with it, sort of...
Not that I would not also prefer node over PHP ... But that is mainly because of C/C#/Java familiarity and frontend code reuse/familiarity than anything else.
I honestly always wonder: as opposed to what? Let's take my simple requirement, a small business ecommerce store that's not going to look like trash and where non technical users can make pages, edit descriptions, etc.
I can do: WordPress, Magento, or I can pay a SaS provider. Essentially both do it yourself approaches are PHP and Magento has really sabotaged itself with the complicated migration. SaS means higher costs and if I want custom functionality (and yes, the business needs it), it ranges from impossible to possible but a headache.
So here is a business that is now online for a minimal cost for two years, allowing great flexibility for me, while allowing completely non technical users to get crap done.
Who is writing the code in the first place? They're uploading existing code to a shared host through FTP but then who wrote the code? Is it a prepackaged Wordpress? But then Wordpess hosts already exist.
If the developer is giving them a zip to upload, why can't the developer handle the deployment as well?
You moved the goalposts so far that the example doesn't make any sense anymore.
I'm currently working for a company where all our microservices were written in Node.js by juniors.
JS can absolutely be worse than PHP
1. https://www.audero.it/blog/2016/12/05/monkey-patching-javasc...
You'd have to try really hard to make callback labyrinths in JS match the mess that came out of the above combined with runtime-as-template-engine. This was basically idiomatic at the time.
The value of a form input with the name “foo.bar” will instead be available under $_POST[“foo_bar”].
Microbenchmarks are meaningful as long as one doesn't read too much from them. This benchmark shows that PHP seems to have a problem with recurrent calls.
So yeah. Don't make PHP your first language. Probably not your second either. But if you've played with Python, and learned to write the simplest and clearest thing that can possibly work, if you've worked in C, and decided that's as close to the bare metal as you ever want to get, if you've learned enough Java to know when to use the SeriousBusinessFactoryProxyInterface, if Haskell has made you realize that programming is really just math... then sure, learn you some PHP, write a toy web project and discover that the simple things really can be simple.
I still don't know of any stacks where it's easier to write a simple, low maintenance side project that will stay up for years without issue, where multiple projects can share a $5 / month VPS, than the LAMP stack.
But PHP is a quite nice language with a lot less ceremony than many other languages. Especially nowadays as the article says.
Go make a Wordpress site!
I get that there's a lot of legacy PHP sites, that you could end up finding yourself working on. But there are still plenty of new Drupal and Wordpress sites being built.
You could also say that building a site with these tools as akin to "customising", as a lot of what you're doing is configuration rather than coding (but I would say sometimes JS + NPM is pretty similar). There are still opportunities to push yourself with coding, with some fairly complex Drupal sites being built.
There's no alternative to dropping a file on a LAMP server that goes with almost 0 maintenance for price that goes to almost 0 with 0 downtime whenever you make a change.
PHP is my tool of choice whenever I need to create an simple endpoint but don't want to deal with the hassle of running and monitor a full blown application. At best, the alternative to that is AWS Lambda but that's a wall garden in itself
> then you could choose to pick up ..... better to have a new kind of tool in your belt than a second hammer.
Different tools for different job
It was the SQL part of the book that helped me build the SQL skillset that is an integral part of my day job.
Used a book similar to this one:
https://www.thriftbooks.com/w/professional-php4-programming_...
haha. My first ever project as an intern in 2004 was exactly this.
Which I suppose is just a fancy way of a copying files to the server.
Something doesn't quite add up across everyone's results here, but the extremely slow result at the top of the thread is almost certainly a debugger slowing things down.
Edit: I was missing `opcache.jit_buffer_size`, and saw the runtime drop to under ten seconds with that correctly configured.
The original promises syntax and chaining in ES6 were not particularly user friendly.
Have you played with Shiny (shiny.rstudio.com). If you're building a website for interactive data exploration and analysis, it is very hard to beat.
But if you need a site spun up for something and it's not the main focus of your business, shooting for the middle of the market makes a lot of sense. Wordpress is super easy to set up and create pages on, and there are tons of people with expertise in it. It's the kind of thing even non-programmers can administer, which makes it accessible to people who have skills in other stuff like marketing or social media management.
I was more thinking if you want to build an interactive site, what is the go to Go web framework?
Along the same lines with the Wordpress example, I'd choose Ghost for that as I come from the JS end of the spectrum also. I wonder what the Go based options are here? If I ran a Go shop I'd probably lean towards that (unless, of course, they're all horrible :)
Just another reason why the "each request gets a process" architecture can work well. You generally don't need to worry about async stuff in PHP, because your request has the whole process to itself.
$x = [1,null,'xxxx', collect([])];
You can also add annotations like `/* @var []int */`. External tools (psalm, phpstan) use annotations in their static analysis of the code and will raise an error if $x elements are not integers.
Of course, it's far from Haskell, but my experience with types in PHP is smoother than in Python. Though it was 2 years ago in Python, and the environnement has probably matured.
In my opinion, a worse problem with PHP is that classes properties are dynamic. `class A {}; $a=new A; $a->x=1;` is perfectly valid and will add a property to the object that does not exist in the class. There's no simple way to forbid this, even at runtime (hacking the magic `__set()` creates other pain points).
There's a current RFC that is aiming to deprecate this 'feature'.
Aside from PHP, can you think of any other topics that can be problematic in this regard? So far i haven't personally run into any that would get me disproportionate amounts of negative votes, however i find myself curious about it. The only i could personally think of would be Perl and the discussions surrounding its history.
Perhaps i've just been lucky so far, or maybe you can tackle some of those topics by phrasing your points as questions or just pointing out that those are subjective views, instead of absolute truths, thus stimulating a discussion, rather a clash of opinions.
Personally, i think that sites like Habr or some Reddit communities could be more biased as far as discussions about topics go, due to the specialization present (e.g. a blockchain centric subreddit might not be receptive of criticism, even if constructive), however i've also heard similar things about Team Blind, whereas my HN experience has generally been fairly pleasant.
For bonus points, do state one provable and visible fact: that Signal (the program that's always recommended as a replacement for Telegram in HN) is not completely open source either, and then suddenly even more people appear to explain to you how that's somehow okay for Signal but not for Telegram. Even more puzzling.
Another one: mention Rust, no matter how. Somehow you're suddenly a zealot, you work with a "flavor of the week" language apparently (nevermind that it's at least 10 years old), and you also feel the need to tell everyone about it everywhere you go, and let's also not forget that C++ can do everything that Rust can and you're a bad programmer for not realizing it. I learn so many new things about myself every time I mention Rust around here! (warning: this was sarcasm)
HN isn't as neutral and factual as you might be imagining it. I've seen ugly and shameless appeals to authority by very prominent and high-profile members of this community.
Just some hivemind topics-
* Free Speech. This community tends to be extremist about this, which in turn means anything that can be construed as limiting free speech will, somewhat ironically, not result in a productive conversation.
* Corporate Libertarianism. This community also tends to be extremely pro-corporate, and there's a lot of "if you don't like it work somewhere else". That being said I've seen some push back against this lately.
* Meritocracy. If you challenge the idea that silicon valley is a meritocracy people seem to get really upset.
I would definitely say that there are reddit communities that are worse, and some that are better.
That said, in regards to freedom of speech, i feel like some of Bryan Lunduke's (just as an example) arguments wouldn't necessarily invite hostility, despite their delicateness - such as the idea of de-anonymizing the internet and what implications that could have and what it'd look like.
Of course, it might invite prolonged discussions with no clear conclusion, because there are just societally complex topics with layered tradeoffs where no one can definitively cover all of them, but in my eyes that's not necessarily bad, as long as everyone remains civil.
I know I've certainly been wrong about a lot of things, though thankfully people so far have corrected me and let me better myself.
And if you want to integrate Hugo with anything, Go is the way.
Even with a standard Hugo set-up, most content is in Markdown files, so one could also just train someone from marketing on how to edit those. Not exactly rocket science.
I'm quite happy with the Web niche, it's one of the longest lived, the stablest, the most open, and has some of the longest backwards-compatibility records around.
I can write a website today which will work in 25 years worth of client software! I think that's remarkable.
Simplistically speaking, all I have to do is stick the path hashbang at the top of a php file, follow with the business logic and run it as a shell script. Clears any urgent ad-hoc request within a day.
I believe that PHP is the easiest way to just Get Things Done when you're starting out with a programming language. To deploy a website, you sign up for a free account somewhere, often with a free subdomain like mywebsite.cheapwebhosting.com, put the files on there and hit refresh. Seeing a result immediately is very motivating for beginners, and PHP doesn't require knowing anything complex like DOM manipulation to generate web pages the way Javascript does. If there were as many free web hosts that allowed the same ease of use for C# or some other language with inline templating, I'm sure it'd take off just as easily.
The language isn't as bad as people claim either, I think it's on par with languages like Python and Javascript. PHP has its quirks, like using a dollar sign for variables, it's really not that much worse than its competitors. Shorthands like $_POST/GET/SESSION are such a relief to work with compared to the "professional" languages with their frameworks upon frameworks and complex, layered objects representing state. It's a great tool for setting up a simple website, maybe even a very basic web shop, where the "big boys" are complete overkill. A website like HN doesn't need more than a few PHP files to function until it hits a certain scale, and even then scaling up PHP websites is relatively easy.
I think the real reason people hate PHP is because it's a language used by a lot of beginners and intermediate programmers who overestimate their ability and deliver subpar projects that someone else now needs to maintain or rewrite. I wouldn't want to inherit some kind of custom blogging engine written by an intern three years ago in any programming language, and because of its ease of development many PHP programs are just designed badly.
- install/update PHP or go with the outdated version that shipped with their system.
- have a hosting service that will accept random PHP files
- know what their hosting's PHP version/configuration is to match it locally. For instance their hosting will keep the most secure config possible, thus no out of the box fetching of URLs.
- endlessly fight to find syntax errors as they are too new to have a linter. Depending on the PHP version they settled on they won't have error logs in one place but two.
- fight the endless stream of out of date tips and tricks left by 2 decades of PHP programers of various pedigree.
All of these have different variations for different languages, they all have their barriers and dead bodies in the closet. My take is that PHP isn't specially beginner friendly at this point, at least not as friendly as it was when it began.
Making a public website from scratch will be complex anyway, so they might as well go with a saner setup that uses a templating language and not write code right into the HTML. It won't be much harder and they'll have a fighting chance to find up to date tutorial to host their project easily (hosting a rails project on Heroku for instance could be miles easier in that respect)
You can have deployment pipelines etc, but if you like, you can still develop the ancient way - it still works.
Now you can put .py files into your www folder, like .php files.
One can also use old school CGI to serve their site, it’s super lightweight and you just upload the file at the right place, for almost any language. But that has been deprecated for the last 2 decades now.
[1] e.g. "Symfony\Component\DependencyInjection\Loader\Configurator\ContainerConfigurator"
I would have to question how relevant a piece of core plumbing is to a regular user of the framework, as a regular user of the framework would likely never come across this class.
Also if you're working in the domain as a Symfony core developer, the idea of a ContainerConfigurator is not so insane, if you're developing a dependency injection container.
> you need an external server
Spoiler, you need an external server for everything on the web; you've just been brainwashed to think serverless is actually that.
Lots of languages and frameworks make it easy to be self-hosted with there own server. In Python, .net, Go, Rust this is quite common.
This means that your app can be a self-contained app + server and the server part can have some business logic as well.
With Go, .net, Rust apps (and potentially others) that's quite nice to be able to produce a single binary app that you can just run anywhere without installing any framework or setting up any external server and it's ready to listen to incoming queries.
That can even be a good enough setup for home things that are not exposed to the web and where setting up reverse proxies could be overkill.
So yeah, you technically don't need one for Ruby or Node.js, but I sure would.
Global PHP configuration options have become less important over time, with resource limits and extensions being most of what has to be configured now.
It is cruel, and something Universities have been doing forever.
That's not true for Java or C#.
You can't know everything. Programming is about abstraction; so abstracting away devops is a feature (in some contexts), lack of that is a downside (in some contexts).
Hosting (as a service, and shared hosting) is a very complicated business if you want to do it right.
Also, when picking hosting providers, there are many things that factor into this. Social, political, and economic status are one thing (of the dev and the client). Another thing that comes to mind is the client's (or sometimes even dev's) location/jurisdiction (or the website's audience).
The availability/locality plays a giant role in selection in non-western countries. For example, some European countries/ISPS have super-fast internet within them or up to the closest IX (internet exchange), but horrendous speeds towards anything beyond the IX; sometimes these are intentional (alas, curse politics) sometimes they're not.
We had many clients that would migrate to us because they had these issues with previous providers because we were different from other hosting providers.
Disclaimer: I used to work for a hosting company
I don't use it any more, but in 2002 when shared hosting and deploying by uploading files via FTP was the thing it was a lot easier to get started with than Perl or Java (which I desperately tried to get into back then).
So it was almost the first language I used to make actual money.
PHP's "prescient" model demanded one OS process per request which is frankly absurd and I don't get how anyone views PHP in serious light because of this single fact alone.
If I did that I'd have missed a hell of a lot of cool stuff in life haha
What's been useful about PHP (and many other stacks) is that the good ideas from other worlds usually get assimilated in over time. PHP is not always at the bleeding edge with respect to language development, but that's just fine. The PHP ecosystems often adopt/adapt useful ideas/techniques from other ecosystems relatively rapidly, and that's just fine too.
You're 100% right.
My original comment focuses on PHP because I was specifically addressing the "PHP is the easiest to develop in" idea.
I realise that it might seem a bit too critical maybe because PHP was the only topic in it, but I didn't mean it to come off like that. Hopefully I redeemed PHP a little bit in the follow-up comment! :D
At the end of the day: every ecosystem/language has its own "that shadowy place over there" :P
If we are talking about building large web applications then performance, maintainability and other things may start to be more important than fun and then c#, java, go and others can be really good solutions.
I didn't mean to imply that other languages don't have complexities. All ecosystems come with their own boons and complexity issues (hidden or upfront). The thing I wanted to address is the general idea of "PHP is the simplest to develop in, it's just uploading a file" (paraphrasing) shouldn't be taken at face value, and that's why I pointed out some of the complexities when working with PHP that PHP developers tend to forget (or some ignore).
But, because PHP is so easy to get started with, a lot of the complexity initially gets hidden away, and sometimes people learn about it the hard way.
JavaScript used to be much the same, but it has gotten better in the recent years. Maybe PHP has gotten better in this aspect too, but I could be ignorant because I've not been keeping up with PHP as much
PHP makes it easy for beginners and amateur programmers to get something working without knowing much.
Because of the low-barrier to entry and simple hosting setup people have written a lot of crap PHP code over the years. I know, I see it and work with it.
Amateurs and well-meaning power-users can get some web pages up and running easier with PHP than with almost anything else, so while inexperienced programmers can write bad code in any language a large number of them choose PHP.
None of those facts mean PHP is not suitable for "real" development and "real" programmers. It is not obsolete or dying. A professional programmer who knows how to build production-quality web sites can get great results from PHP. That requires putting in the same time and effort needed to learn any other language and set of tools.
If anything, PHP has proven it works in this regard.
PHP works, but imho starting a new company or career with PHP is a mistake.
Why would it be a mistake?
On the one hand I have a few examples of huge, successful projects written in PHP and I know they are still around 20 years later and haven't been rewritten in another language. I use projects in PHP on a daily basis (Nextcloud, Rainloop, Wordpress) that work well and have been maintained for years. On the other hand I have a few comments calling out PHP without convincing arguments. Something is wrong.
I practice Python and Javascript daily, I've written PHP code 10 years ago, still use some of my code. I occasionally update PHP code on a website I manage. I've seen good things in the new versions.
Should I begin a new project today, I would not rule out PHP that fast. I like Python and Typescript, but PHP projects are often a breeze to install (unzip, done) and survive system upgrades and reboots easily as long as php-fpm runs. Projects in other languages need more babysitting. I know, I also use web software in other languages, including one I author.
PHP is dead simple to write too.
I would probably go for nodejs for something that requires Websockets or SSEs (or a compiled language). Otherwise, I'd seriously consider PHP because it does not require setting up something like uwsgi or celery, write reverse proxy rules, write init service files or running Docker. Put the files in www and it's done. Also no code for managing routes, the file system organization does this for me. No memory leaks, everything is thrown at the end of each request. The architecture is robust.
It works for them, but I wont tell random people starting a business now to go with pen and paper, 99% of the time that would be a bad advice when there are much much better alternatives now.
But companies might want to use PHP, because it has a rich ecosystem, which handles corner cases.
Chances are, if you want to send out bulk email, or connect to a payment provider, there's going to be a library in PHP that allows you to do that, often with long term support from an agency.
A corner-case I recently had was needing to decode an email. There's a function for that: quoted_printable_decode. This is a common situation for PHP. If you have some sort of issue around the web, there's likely to be a PHP solution.
And if you're a small business that needs a bit of bespoke software written, then you can easily hire someone, and know a decade later, you'll be able to hire someone if the requirements change.
Much of this can also be said of the Java ecosystem.
Just recently, I was using a small business that managed their bespoke business process built on a PHP CMS. They don't need 2000 reqs/second.
It's not that I never tried anything else. I got through 8 languages and made what I feel is an informed choice.
> Much of this can also be said of the Java ecosystem.
And yet, so many programmers and companies moved on from both Java and PHP to other tech and are managing very well. The company I work for has mere 6 backenders and we serve millions of visitors regularly without ever hitting >70% CPU on 3-4 servers.
Citing the entrenched state of affairs is not an argument either. It's an appeal to statistics (a good chunk of which are flawed as well).
I'm not going to try and convince anyone to stop using PHP or Java. Truth is, most programmers want stable predictable careers and there's nothing inherently wrong with that. I simply am not in that group.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
I gave some reasons, citing problem domains for which there are stable, supported solutions in PHP. e.g. payment gateways, email handling, and citing the availability of programmers who can support medium bespoke or tailored systems. This isn't an "appeal to statistics" it's a strength about the ecosystem.
Similar to Python having many solutions and libraries built around data science.
> I'm not going to try and convince anyone to stop using PHP or Java.
I thought you were asking a question.
And that with a language that everyone can use.
A simple PHP page 10 years ago on a low-end server using mod_php could do 100k+ rps. Add more logic to it and performance will decrease.
"How many companies need X" is not a discussion, it's an exchange of opinions and won't ever go anywhere, so I refuse to start it.
I was merely responding to the claim that PHP had "prescient" ideas. It didn't.
And yes, 4,5k USD/month is massively good salary for Europe.
On the other hand, I see many job offers with salaries being just a joke (idk if they find any good developers for such money)
In eastern and southern europe: that's probably good for a junior engineer, and perhaps average for a senior
In northern europe: that's probably average for a junior, below average for a senior
For example, in Berlin it seems to me that average salaries are around 70k EUR/year (6.6k USD/month) and really good salaries are well above 90k EUR/year (8.5k USD/month).
You can see more data in https://www.levels.fyi, which it is skewed to the high side, but gives you an idea about what good offers are nowadays.
I'd consider a PHP job, but only if they quarantee they don't have any of those legacy maintaining things lying around.
I see your point, but there is lots of legacy code (in any language) laying around and making shit tons of money for their owners - hence the need to maintain these systems.
PHP had no common way to do anything for a long time and you still see it from people writing PHP today.
* It's waning in popularity, new programmers aren't being taught and there isn't a lot of incentive for them to seek it out * Other languages are also good at making websites but many are more popular and more flexible - machine learning, video games, front-end web development, enterprise services (and sure PHP can be "enterprise" but many new cloud/apache projects are java first)
So yeah, I'm not saying PHP is dead...just that it's not a good investment for new developers and it's questionable for new projects.
Pick whatever you want. Just don't pick a language that is known to be on it's last legs.
It's not as 'trendy' as it once was, but it's better than ever and still widely used.
Also I wasn't pointing out what you say, you're reading into it a bit. I haven't used PHP in a long ass time. But it seems like not a bad choice for certain markets, at least as much as Python and Ruby imo
I’ve heard that exact sentiment over and over since the RoR community aggressively started with their anti-php agenda in about 2006.
So if you need a job you would probably have better chances knowing PHP then knowing Rust. But if in your area is raining with Rust jobs then go ahead and learn only Rust.
Don't get me wrong, my whole point is that this 'simplicity' is given in any ecosystem these days.
Except live coding via FTP is something you consider part of the simplicity, then you are stuck with PHP :)
Heroku is fine but imagine you are agency managing 50 small sites. Heroku is like 7usd month minimum? You can pay 350usd month for Heroku or put it all on 20usd VPS and result will be same.
That's why all self-hosted CMSes worth something are in PHP world and there are very few in python/rails/node.
Also its not like PHP devs have been living under a rock for 20 years and don't want nice things. Git deployment is offered even by many shared hostings, people use SFTP+rsync, or things like https://deployer.org/. And there is very active market of server management tools like https://forge.laravel.com/ https://ploi.io/ https://moss.sh/ that combined with attributes of PHP will give you your own little super easy heroku.
And scaling... well most people don't need scale, you scale CMSes by caching anyway. And you can run pretty big scale just on one machine. And if you want automatic extreme scaling it's not like you can't do that with PHP https://vapor.laravel.com/
However the way rails apps works with phusion passenger is exactly what you are explaining. I can run hundreds of apps next to each other on a tiny VM. Once a app is loaded I don't have to rebuild the state on each request, if it is not needed anymore (or rather another app needs the resources more) it gets unloaded again.
Setting up passenger, nginx and git for pushing is also a job of 10 minutes max.
I get there is a market for PHP, I too recommend wordpress when I don't want to code something for someone. I just don't see it's 'simplicity' as argument.
> All languages can be used by everyone.
Now consider brainf#ck.
You see? For all practical values of used not every language can be used by everyone.
This is of course an extreme outlier (but absolutely not the worst I think) but there is a spectrum, or rather field of possibilities.
PHP is trivially simple to get started with. A teenager can manage to do it alone.
But I like the idea that these people may exist out there :)
Sure. In that area PHP still more or less dominates. But I thought we were discussing the actual programming?
> I thought you were asking a question.
That's exactly why I said what you quoted me on: to reassert that I am looking for a good answer on "what does PHP do better" and I am not in fact seeking to change hearts per se.
Over my career, I've worked with companies using PHP in sales. One of those had over a million customer subscriptions, the other was a multi-national looking at PHP for a greenfield e-commerce project. I noticed working in Europe some high-growth agencies that use PHP.
> So tell me again, why should I use PHP? How will it truly help me? What does it do better than everyone else?
> But I thought we were discussing the actual programming?
Your original question just said "use PHP". PHP is a general purpose web scripting language. It's similar to Python or Ruby. It is generally more performant and later versions have a gradual type system. It's traditionally run as a shared-nothing single-threaded script, which makes it easy to reason about, and in real life has proved to be a stable way to run things in production, as it avoid bugs that can arise around stale state, multi-threading and it keeps running if other libraries have bugs that leak memory.
Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
Arguably, the thing that would make you use it over Python, or Ruby, is the ecosystem, especially around content management and e-commerce, as the language itself is roughly comparable to others. Also I think there are more agencies that support PHP, rather than Python or Ruby.
I think we have a vastly differing definition of "in production". I'll agree PHP was good enough for plenty of things, and likely still is. But good enough in general to run things in production as it's understood today? You'll find that many people will disagree with you here, not just me.
> Later versions have introduced a JIT and support for concurrency concepts such as fibres, as in the upcoming PHP 8.1 https://php.watch/versions/8.1/fibers.
That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now. Happily Erlang/Elixir are having lightweight and transparent parallelism and concurrency for a long time now. Languages like Go and Rust also progressed very well in this area so I am looking to work more with them in the future as well.
---
I think you and I are not aligned on what is "successful" or "good enough". You seem to insist that statistical success speaks something of the merits of a technology, and this is where I and many others disagree: people just adapt to what's given to them. That doesn't say almost anything about if the thing is good or not. People simply get what they can. Back then PHP was available so they took that. The rest is post-hoc rationalization. Stretching the simple and isolated historical fact "people used PHP because there was nothing else viable at the time" to mean that "PHP is good and successful" is where I'll disagree with you.
But yep, we severely digressed from the original discussion. I am OK with that though.
What is this out of the park career path I'd have had choosing ruby? Can you share some more details?
Almost the best advice I can give to a developer is stop being fixated on language, and start being fixated on how to solve business problems, on communicating coherently (and like a human being), and being able to quickly grok complexity. The language you program in is almost the least important part of the offer (as long as you're competent in it)
Where? At Facebook? Or somewhere else?
Running software that customers use, directly or indirectly.
I've supported servers running PHP and Java software in production. The shared-nothing per-request nature of PHP meant I didn't have to deal with a bug in a misbehaving library causing memory leaks and taking down the application server.
> That's what I mean, not only for PHP but for like 99% of all programming languages: they play catch-up, waaaaaaaaay too slowly and gradually, with things that should be baseline by now.
PHP's problem domain has been web-based e-commerce and content management systems. In this area, PHP powers most of the web. You'd want to use PHP in this field, over other languages. Every improvement around PHP has been to advance this goal, such as the recent addition of gradual typing. There's no question of "catching up" in this area. That it is broadening out into different areas, great.
> You seem to insist that statistical success speaks something of the merits of a technology.
If the technology doesn't have a marketing department, or large companies forcing people to use it, then arguably, this does, as otherwise people would just use something else.
There have also been many other qualitative improvements to PHP over the years. I also mentioned its shared-nothing architecture, which is a qualitative, not statistical aspect behind PHP's success, as it has proven to provide stability in production. People use PHP because in certain problem domains, it is qualitatively, and statistically (assuming you mean, it benefits historically from a wide number of successful, maintained libraries) the best tool for the job.
Do all of these make it faster than PHP?
We'll need to look at it a year or two from now and compare oranges to oranges; the new Ruby JIT (YJIT) is optimized for real world web apps, not for some artificial fibonacci benchmark. Shopify is using benchmarks on actual Rails apps like their store front to see the improvement (https://speed.yjit.org/). If I had to bet I think yes Shopify is serious enough about this to make Ruby faster than PHP - who is working on PHP internals now - Zend? In the end it's mostly a question of how much resources you throw at a problem.
Honestly, I have no idea how it compares to PHP. If I wanted truly fast I'd use a compiled language. The point is more that Ruby is still being used and improved upon all the time; far from 'dead'.
Exactly the same with PHP. The handful of Rails devs I know bemoan the fact that fewer shops are growing their Rails/Ruby use. I did a stint at a shop that was mainly PHP, but they migrated most stuff to a combination of node and python, because "they couldn't find php developers". While it was sort of true, they couldn't find affordable php devs to work with the legacy mess (which was only 5-6 years old), and it was cheaper to have less experienced (but more) node/python folks come in and rebuild distinct bits of the older PHP stuff (at least, that was my understanding as an outsider - this happened after I left).
Some orgs are moving away from PHP - others are moving towards it. Same with Ruby, although I don't see as much movement toward Ruby as I do with PHP. But I do also see orgs moving away from each.