I wrote a lot of PHP from 1999-2008. First as a hobby, then professionally. From 20 LOC guestbooks to payment gateways used to process millions in payments. It wasn't until recently that I was sure I'd written more code in any other language than PHP. These days I'll occasionally poke around with it or patch a bug, but that's about it.
Is it a perfect language? No. But which language is? (I can hear the Lisp crowd grumbling.) It's fast. The only ceremony you need to write executable code is the <?php tag. It has a very rich standard library -- even if some of the function names make me want to stab people.
My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?
PHP has taken a lot of flack over the years. Mostly from people who never really worked with it. A lot of the criticism really should have been aimed at certain PHP developers, rather than the language or the community at large. PHP's low entry barrier is a blessing, it's how a lot of developers were introduced to programming. It's also a curse, because a lot of very inexperienced programmers managed to become prolific at getting code out there, code which was ugly, bug infested and a security nightmare. But it's not fair to attack a language over its inexperienced users.
PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in.
I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter.
One thing that still sucks is package management / composer.
> One thing that still sucks is package management / composer
What about Composer? Sure is in par with Slack when it comes to memory usage, bit it's functional and feature rich. v2 has partial offline support, faster downloads, etc. (https://php.watch/articles/composer-2).
Composer IMHO is one of the best dependency managers for any language out there.
Disclaimer: the link above is a for a site I maintain.
The speed is the main reason I decided to experiment with building a Node.js module last week that allows you to use PHP as a templating engine for Express apps: https://www.npmjs.com/package/php
I had guessed that PHP might be faster than mainstream JS-based templating systems like EJS and in my tests so far in an app I'm building it appears my guess was right. Even with the overhead of serializing and deserializing the data model from Node to PHP, on one of my more complex templates the PHP version outperforms the EJS version by around 10%.
This is honestly the first I’ve ever heard anyone complain about composer. Having experienced a number of other package managers, composer is by far my favorite. Like have you spent any time with npm? Composer is light years ahead in reliability and expectations matching reality.
What are the "modern" features of php? It looks like it's trying to shed it's dynamic nature and add types (with annotations etc). Also frameworks like Symfony / Laravel look more and more like java web frameworks to me.
I'm not saying this is necessarily bad but there's nothing modern about types. Also, might make more sense to choose java if you need types.
A lot of PHP work is digging around in Wordpress themes & plugins with a bunch of other (third-party) themes and plugins installed, some of them paid which can add another layer of annoyance to testing and deployment and such. Hosting's usually some managed thing rather than anything under your direct control, and usually quirky or limited in some way or another. It's a pretty miserable ecosystem to work in.
PHP itself is, secretly, actually kinda OK. Some major codebases written in it are no fun at all to work with, including the 800lb gorilla that is WP.
I took a look at it about 1,5 years ago while having worked with very early versions (2, 3 or 4?) as a teen. It was the first language I put some effort in to learn more about. Not that I remember too much, but it is a complete different language by now.
I would have thought only dinosaurs like Algol or Fortran can be that old.
Composer 2 is coming, and so far it’s shaping up to be vastly improved.
Also, many people are still using that ‘fractal of bad design’ article from years ago to bash on PHP, even though a number of the assertions are no longer applicable.
I'd be interestd to see how much faster Laravel is compared with Rails and also how they compare in memory usage. Last time I looked on Techempower I was surprised to find Laravel performing more slowly than Rails in some of the examples.
Yes. The thing he did wrong IMO was to unleash a scripting language hiding in SGML-ish processing instructions without HTML-aware context-dependent escaping upon the world (when SGML has plenty of rules for delimiter recognition in particular parsing contexts), and then later make up for this with braindead quoting routines (like real_escape_string). In other words, the quick and dirty way was chosen, and that choice has plagued websites in the form of injection attacks (and DDOS using PHP injection attacks targetting even non-PHP sites) to this date.
When the guy who created Smarty (his name escapes me) and announced it on the core PHP developers mailing list, the other developers practically begged him not to release it and told him outright how redundant it was. He did it anyway. PHP may deserve some hate but we shouldn't blame PHP for Smarty existing.
You end doing real, production work on some codebase that uses Smarty. You grasp why. Your next PHP project uses Smarty because you learnt some good things about it. Always balance the pros and cons. Until real world work is done, almost all hate is based on judgement done in blog posts.
I strongly agree Smarty is beyond terrible (and I've used it and read the source code, so I know its problems first hand) and the fact that it even exists is indicitive of deep flaws in PHP, but I don't believe Rasmus has ever realized that he did anything wrong. He just doesn't care.
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I DON'T CARE about this crap at all." -Rasmus Lerdorf
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rasmus Lerdorf
DonHopkins 9 months ago | parent | favorite | on: YAML: Probably not so great after all
One of the most ridiculous examples of this was the Smarty templating language for PHP.
Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.
So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.
>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?
>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
I've written many languages (starting with ML –Machine Language).
I'm currently developing in Swift, and loving it.
I wrote PHP for about 20 of its 25 years. I never really got to love the language, but got fairly good with it. I don't miss it much.
I have used it to write some industrial-scale systems, though. It's a perfectly good language, and is still under active development and improvement; with a vast user base and [m|b]illions of pages of support.
Even though a lot of us like to live on "the bleeding edge," I've found that it's a good idea to stick with the classics for shipping code.
Nowadays, "the classics" includes JS and Python, so there are definitely good, well-supported, mature alternatives to PHP.
I also programmed C++, and ran a C++ shop, for many years. I always find the hate poured onto C++, with the annual "C++ is dead" pronouncement, quite amusing.
> PHP to have str_contains() A function that checks if a string is contained in another string? That should only take about 25 years.
For anyone else confused by the newest thing on the list who is wondering what the heck str_contains() does that you could not already easily do with strstr() or strpos() since time immemorial, the answer is nothing.
The only difference between str_contains($needle, $haystack) and strstr($needle, $haystack) and strpos($needle, $haystack) is that after they all make exactly the same C function call:
I personally don't object to 'trivial' functions sprinkled in my stdlib. I mean your own comment already highlights it, the return value of strstr() and strpos() is not intuitive, whereas you expect a boolean for a 'contains()' function.
Of course, it also highlights one of PHP's often repeated criticisms, that of function naming inconsistency.
Most people don't know this and the timeline also doesn't make it very clear: PHP never started as a language but as a templating system for C.
Feature requests were quickly added and that's why PHP became a language with a lot of quirk's.
Today that is totally different. As a scripting language it is blazing fast. It still has some strange corners, but it's amazing that a templating system because such a wide used language.
I started with PHP 15 years ago, but after 5 years I just moved to Java.
The worst thing with PHP was people and standards, everything was a mess, there was no right way to do stuff and larger projects had like 100 different implementations for the same thing. PHP was really challenging to work with as coming to a shared agreement for how one should implement stuff was a recipe for personal conflicts.
So after a few years, I just started to code web applications with Java. A completely different, but much more enjoyable environment and much more friendly people.
I guess PHP is much more fun today, it was really fun to code in PHP as it was really simple and you feel productive and powerful. But in the old days, bad defaults often caused issues in production. And some of the documentation/knowledge sharing was dangerous(tutorials lacked warnings and information about preventing SQL injections).
> "man, why I have to type this silly whitespace?"
I assume it's a joke, but I often have people in my classroom that have been doing python for some times and that keep typing the whitespaces themselves instead of using an editor that does it for them.
But again, I've seen some coding without any syntax highlighting.
Now I never assume people know even the most obvious things.
Did you try HTML::Mason or were you stuck with CGI::Application or even plain old cgi? Mason is like PHP but its dependenc on mod_perl made unfortunately made it a non-starter for cheap hosts. Catalyst was an abomination but I think Mojolicious deserves more adoption that it gets.
I started my professional developer career with PHP 5.2 I think end of 2006.
While the langugage design was garbage, I the developer experience was quite awesome.
This was a curse and a blessing. On the one hand it lowered the bar for many people to get into programming, on the other hand it led many people to believe they can do anything even when venturing in system designs that were much above their pay grade.
I switched to JavaScript in 2011 and again, it was mostly for DX.
The language felt more light-weight (no $ or classes), while it still had similar problems as PHP and being able to use it full stack eased context switching rather much.
Node.js deployments felt much slimmer than setting up PHP with Apache/Nginx too.
I still missed a bit of the "drop a source file in a folder and its an API" feeling.
Last few weeks I played around with Cloudflare Workers and that got me a bit of the PHP feeling again. I can simply say "This file runs at that path" and be done with it.
Same. I love Go, the language, much more than PHP, but Laravel.. Laravel is really great.
I wish Go had something as convenient and complete as Laravel. Unfortunately that's impossible to achieve in a static language without polymorphism (generics) or metaprogramming.
I'm waiting for Go to introduce polymorphism and I'll be watching closely to see how 'post-generics' web frameworks make Go great again!
While I don't use PHP today, it always makes me wonder at deceptively easy it is to deploy a PHP app.
There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts.
You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways.
On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up. Most other languages and frameworks can't do this, or the way they do it involves doing very complicated things or using even more complicated tools to solve the problem for you.
It's funny to think back in the early 2000s I was using PHP and deploying was brain dead simple then, but fast forward almost 20 years and it's still pretty much the case today -- at least it seems that way based on the talks I've seen around using PHP in production over the years.
It's so crazy to see how far the language has come, and how much it's matured! I started working in Perl around '98-99, switched to PHP in 2000 just after PHP 4 came out, and ended up running a company around it for all of my 20's. Very thankful for the language and community that made that possible.
These days I still write a fair bit of PHP, but mainly C# and Go, and some Javascript. I understand the criticisms of each language, but I don't mind the type inference/coercion in scripting languages and don't find it actually results in that many bugs. Although I do appreciate the clarity of choosing your types and understanding their performance implications in C# and Go. I guess it comes down to the right tool for the job, and some jobs do just fine without strict types.
Since 7, PHP's also gotten fast enough that most web-related tasks are just faster to solve with it, and it's so easy to deploy a Go binary alongside it for performance-critical parts that it feels like a killer combo in terms of productivity vs performance. Really itching to play with Roadrunner next, which blends those two together into a single app server (https://roadrunner.dev/).
I've been working with PHP for a very long time and apart from web it is also very good at writing shell scripts too.
One of my recent project called 'howdoi' (1) is written in less than 70 lines of code (ignoring ws) - no libraries, no deps and backward comptabile to 5.0. Just copy-paste the file and it's go! If you know how to use it, it's really useful language.
Fine. After 20+ years of PHP development I'm going to give it a shot. Will be attempting to migrate from VSCode. Any tips for that transition in particular, or for setting up PHPStorm in general? I have a subscription to Laracasts and plan on watching that series, but I'm not sure if it's outdated. Thanks!
There’s a fairly good plugin for JetBrains IDEs called “Key Promoter X” that reminds you whenever you do an action (click build, open a terminal, change directories) of the keyboard shortcut to do that same thing. It’s very handy for getting into the workflow quickly.
I second the PHP Inspections (EA Extented) plugin.
If you use Symfony don't miss the plugin, it's almost (dev-)life changing.
If you use xdebug take the time to set it up (way easier these days but can still be challenging depending on your setup), breakpoints work great.
More related to all Jetbrains IDEs:
One often overlooked aspect is the database integration (look at the tabs on the right). In addition to replacing most needs for a third party program it gives you autocompletion for your in-code sql querys.
Checkout the git integration. From the "annotate" entry menu to the all fantastic diff/merging/etc tools.
Lean to use the different searches, "in path" (toggle the preview option), classname, file, or the global shift-shift.
Try all the integrated tools, the terminal & ssh, the http client, the live templates, etc.
Lean about the local history (usually in the context menu above the git entry), it will save your ass at some point (it can restore entire deleted-by-mistake folders).
I wish more digital subscription models were more like the jetbrains one. If you paid for one year continously they handle it like you own that specific phpstorm version, even if you cancel your subscription.
That said, I wish I could subscribe without having a company ._.
I have a theory that PHP is kind of like erlang -- as a framework and dev environment, not the language itself.
Each request is pretty much independent of the others, and each one can independently crash.
There was also CGI, but CGI always felt a little heavier, and the crashes were harsher (usually just a 501 error and nothing more). PHP embraced the crashes more and provided more information allowing faster debugging.
As a result, generally it was pretty easy to make resilient software.
Critically, PHP also embraced SQL databases, so that crashing meant aborting the transaction (if any). Erlang never meshed quite as well with transactional databases, so trying to keep consistent shared state in erlang felt tricky. In PHP, it was natural.
I first met Rasmus during my pre-internet BBS days in Toronto, and reached out to him shortly after moving to the Bay Area in '95 when he told me about his pet "Personal Home Page" project. What an amazing trajectory!
What ever happened to the PHP-FIG? I noticed in the timeline projects kept dropping from it in the past 2 years. It seemed to have a lot of momentum for a while producing PSRs that were very widely adopted.
If you are the geerlingguy I think you are, Drupal sure had an exit after Larry, and Symfony decided to step out too. Laravel didn't really follow PSR to begin with.
I use Slim framework extensively nowadays, and it has a surprisingly PSR 2,4,7, AND 15 support.
[+] [-] elric|5 years ago|reply
Is it a perfect language? No. But which language is? (I can hear the Lisp crowd grumbling.) It's fast. The only ceremony you need to write executable code is the <?php tag. It has a very rich standard library -- even if some of the function names make me want to stab people.
My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?
PHP has taken a lot of flack over the years. Mostly from people who never really worked with it. A lot of the criticism really should have been aimed at certain PHP developers, rather than the language or the community at large. PHP's low entry barrier is a blessing, it's how a lot of developers were introduced to programming. It's also a curse, because a lot of very inexperienced programmers managed to become prolific at getting code out there, code which was ugly, bug infested and a security nightmare. But it's not fair to attack a language over its inexperienced users.
[+] [-] jonny383|5 years ago|reply
I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter.
One thing that still sucks is package management / composer.
[+] [-] Ayesh|5 years ago|reply
What about Composer? Sure is in par with Slack when it comes to memory usage, bit it's functional and feature rich. v2 has partial offline support, faster downloads, etc. (https://php.watch/articles/composer-2).
Composer IMHO is one of the best dependency managers for any language out there.
Disclaimer: the link above is a for a site I maintain.
[+] [-] kethinov|5 years ago|reply
I had guessed that PHP might be faster than mainstream JS-based templating systems like EJS and in my tests so far in an app I'm building it appears my guess was right. Even with the overhead of serializing and deserializing the data model from Node to PHP, on one of my more complex templates the PHP version outperforms the EJS version by around 10%.
[+] [-] donatj|5 years ago|reply
[+] [-] joelbluminator|5 years ago|reply
[+] [-] karatestomp|5 years ago|reply
PHP itself is, secretly, actually kinda OK. Some major codebases written in it are no fun at all to work with, including the 800lb gorilla that is WP.
[+] [-] ralfhn|5 years ago|reply
[+] [-] raxxorrax|5 years ago|reply
I would have thought only dinosaurs like Algol or Fortran can be that old.
[+] [-] geerlingguy|5 years ago|reply
Also, many people are still using that ‘fractal of bad design’ article from years ago to bash on PHP, even though a number of the assertions are no longer applicable.
[+] [-] rplnt|5 years ago|reply
Yeah, if you know it well enough, maybe. It's horrible to work with as a newcomer or someone who only needs to touch it once in a while.
[+] [-] cutler|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] mschuster91|5 years ago|reply
How? I mean, what are the problems with it?
[+] [-] fxleach|5 years ago|reply
[+] [-] AegirLeet|5 years ago|reply
[+] [-] wiradikusuma|5 years ago|reply
Rasmus realized that he had done something wrong when people started writing template engines for his template engine in his template engine"
:D
[+] [-] tannhaeuser|5 years ago|reply
[+] [-] Zelphyr|5 years ago|reply
[+] [-] juangacovas|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] DonHopkins|5 years ago|reply
"We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I DON'T CARE about this crap at all." -Rasmus Lerdorf
"I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests." -Rasmus Lerdorf
https://news.ycombinator.com/item?id=20736574
DonHopkins 9 months ago | parent | favorite | on: YAML: Probably not so great after all
One of the most ridiculous examples of this was the Smarty templating language for PHP. Somebody got the silly idea in their head of implementing a templating language in PHP, even though PHP is ALREADY a templating language. So they took out all the useful features of PHP, then stuck a few of them back in with even goofier inconsistent hard-to-learn syntax, in a way that required a code generation step, and made templates absolutely impossible to debug.
So in the end your template programmers need to know something just as difficult as PHP itself, yet even more esoteric and less well documented, and it doesn't even end up saving PHP programmers any time, either.
https://web.archive.org/web/20100226023855/http://lutt.se/bl...
>Bad things you accomplish when using Smarty:
>Adding a second language to program in, and increasing the complexity. And the language is not well spread at all, allthough it is’nt hard to learn.
>Not really making the code more readable for the designer.
>You include a lot of code which, in my eyes, is just overkill (more code to parse means slower sites).
https://web.archive.org/web/20090227001433/http://www.rantin...
>Most people would argue, that Smarty is a good solution for templating. I really can’t see any valid reasons, that that is so. Specially since “Templating” and “Language” should never be in the same statement. Let alone one word after another. People are telling me, that Smarty is “better for designers, since they don’t need to learn PHP!”. Wait. What? You’re not learning one programming language, but you’re learning some other? What’s the point in that, anyway? Do us all a favour, and just think the next time you issue that statement, okay?
http://www.ianbicking.org/php-ghetto.html
>I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.
[+] [-] ChrisMarshallNY|5 years ago|reply
I'm currently developing in Swift, and loving it.
I wrote PHP for about 20 of its 25 years. I never really got to love the language, but got fairly good with it. I don't miss it much.
I have used it to write some industrial-scale systems, though. It's a perfectly good language, and is still under active development and improvement; with a vast user base and [m|b]illions of pages of support.
Even though a lot of us like to live on "the bleeding edge," I've found that it's a good idea to stick with the classics for shipping code.
Nowadays, "the classics" includes JS and Python, so there are definitely good, well-supported, mature alternatives to PHP.
I also programmed C++, and ran a C++ shop, for many years. I always find the hate poured onto C++, with the annual "C++ is dead" pronouncement, quite amusing.
But I really like Swift.
[+] [-] xd|5 years ago|reply
Really interesting for anyone wondering what the thinking was behind function naming and other inconsistencies jump to: https://youtu.be/wCZ5TJCBWMg?t=987 and https://youtu.be/wCZ5TJCBWMg?t=1466
[+] [-] tzs|5 years ago|reply
For anyone else confused by the newest thing on the list who is wondering what the heck str_contains() does that you could not already easily do with strstr() or strpos() since time immemorial, the answer is nothing.
The only difference between str_contains($needle, $haystack) and strstr($needle, $haystack) and strpos($needle, $haystack) is that after they all make exactly the same C function call:
which returns either a pointer to the needle string in the haystack string or NULL,• str_contains() return false or true, depending on whether that pointer is NULL or not,
• strstr() returns false or the part of haystack starting with needle, depending on whether that pointer is NULL or not, and
• strpos() returns false or the offset of needle within haystack, depending on whether that pointer is NULL or not.
It's equivalent to just writing (strpos(...) !== false) in your current code.
The rationale for adding str_compare() is that strstr() and strpos() are not intuitive, easy to get wrong, or hard for new developers to remember.
[+] [-] Cthulhu_|5 years ago|reply
Of course, it also highlights one of PHP's often repeated criticisms, that of function naming inconsistency.
[+] [-] thdrdt|5 years ago|reply
Feature requests were quickly added and that's why PHP became a language with a lot of quirk's.
Today that is totally different. As a scripting language it is blazing fast. It still has some strange corners, but it's amazing that a templating system because such a wide used language.
[+] [-] olavgg|5 years ago|reply
The worst thing with PHP was people and standards, everything was a mess, there was no right way to do stuff and larger projects had like 100 different implementations for the same thing. PHP was really challenging to work with as coming to a shared agreement for how one should implement stuff was a recipe for personal conflicts.
So after a few years, I just started to code web applications with Java. A completely different, but much more enjoyable environment and much more friendly people.
I guess PHP is much more fun today, it was really fun to code in PHP as it was really simple and you feel productive and powerful. But in the old days, bad defaults often caused issues in production. And some of the documentation/knowledge sharing was dangerous(tutorials lacked warnings and information about preventing SQL injections).
[+] [-] elpescado|5 years ago|reply
Then I learnt PHP, because whole internet seemed to move to Apache+PHP. I thought, "man, that's Perl done right!".
Then I actually learnt Perl, looked at my PHP code written earlier. I thought "WTF?"
Now I use Python. I think "man, why I have to type this silly whitespace?"
[+] [-] tasuki|5 years ago|reply
[+] [-] BiteCode_dev|5 years ago|reply
I assume it's a joke, but I often have people in my classroom that have been doing python for some times and that keep typing the whitespaces themselves instead of using an editor that does it for them.
But again, I've seen some coding without any syntax highlighting.
Now I never assume people know even the most obvious things.
[+] [-] cutler|5 years ago|reply
[+] [-] k__|5 years ago|reply
While the langugage design was garbage, I the developer experience was quite awesome.
This was a curse and a blessing. On the one hand it lowered the bar for many people to get into programming, on the other hand it led many people to believe they can do anything even when venturing in system designs that were much above their pay grade.
I switched to JavaScript in 2011 and again, it was mostly for DX.
The language felt more light-weight (no $ or classes), while it still had similar problems as PHP and being able to use it full stack eased context switching rather much.
Node.js deployments felt much slimmer than setting up PHP with Apache/Nginx too.
I still missed a bit of the "drop a source file in a folder and its an API" feeling.
Last few weeks I played around with Cloudflare Workers and that got me a bit of the PHP feeling again. I can simply say "This file runs at that path" and be done with it.
[+] [-] bovermyer|5 years ago|reply
It's... comfortable. That's probably the best way I can describe how I feel about it. I've missed working in PHP, despite how much I enjoy Go.
[+] [-] zippoxer|5 years ago|reply
I wish Go had something as convenient and complete as Laravel. Unfortunately that's impossible to achieve in a static language without polymorphism (generics) or metaprogramming.
I'm waiting for Go to introduce polymorphism and I'll be watching closely to see how 'post-generics' web frameworks make Go great again!
[+] [-] nickjj|5 years ago|reply
There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts.
You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways.
On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up. Most other languages and frameworks can't do this, or the way they do it involves doing very complicated things or using even more complicated tools to solve the problem for you.
It's funny to think back in the early 2000s I was using PHP and deploying was brain dead simple then, but fast forward almost 20 years and it's still pretty much the case today -- at least it seems that way based on the talks I've seen around using PHP in production over the years.
[+] [-] lux|5 years ago|reply
These days I still write a fair bit of PHP, but mainly C# and Go, and some Javascript. I understand the criticisms of each language, but I don't mind the type inference/coercion in scripting languages and don't find it actually results in that many bugs. Although I do appreciate the clarity of choosing your types and understanding their performance implications in C# and Go. I guess it comes down to the right tool for the job, and some jobs do just fine without strict types.
Since 7, PHP's also gotten fast enough that most web-related tasks are just faster to solve with it, and it's so easy to deploy a Go binary alongside it for performance-critical parts that it feels like a killer combo in terms of productivity vs performance. Really itching to play with Roadrunner next, which blends those two together into a single app server (https://roadrunner.dev/).
[+] [-] superasn|5 years ago|reply
One of my recent project called 'howdoi' (1) is written in less than 70 lines of code (ignoring ws) - no libraries, no deps and backward comptabile to 5.0. Just copy-paste the file and it's go! If you know how to use it, it's really useful language.
(1) https://news.ycombinator.com/item?id=23230157
[+] [-] OwnsE|5 years ago|reply
[+] [-] jedieaston|5 years ago|reply
[+] [-] conradfr|5 years ago|reply
If you use Symfony don't miss the plugin, it's almost (dev-)life changing.
If you use xdebug take the time to set it up (way easier these days but can still be challenging depending on your setup), breakpoints work great.
More related to all Jetbrains IDEs:
One often overlooked aspect is the database integration (look at the tabs on the right). In addition to replacing most needs for a third party program it gives you autocompletion for your in-code sql querys.
Checkout the git integration. From the "annotate" entry menu to the all fantastic diff/merging/etc tools.
Lean to use the different searches, "in path" (toggle the preview option), classname, file, or the global shift-shift.
Try all the integrated tools, the terminal & ssh, the http client, the live templates, etc.
Lean about the local history (usually in the context menu above the git entry), it will save your ass at some point (it can restore entire deleted-by-mistake folders).
[+] [-] _def|5 years ago|reply
That said, I wish I could subscribe without having a company ._.
[+] [-] joosters|5 years ago|reply
I don't think I'm going to rotate my desktop monitor just for your website :)
[+] [-] jeffdavis|5 years ago|reply
Each request is pretty much independent of the others, and each one can independently crash.
There was also CGI, but CGI always felt a little heavier, and the crashes were harsher (usually just a 501 error and nothing more). PHP embraced the crashes more and provided more information allowing faster debugging.
As a result, generally it was pretty easy to make resilient software.
Critically, PHP also embraced SQL databases, so that crashing meant aborting the transaction (if any). Erlang never meshed quite as well with transactional databases, so trying to keep consistent shared state in erlang felt tricky. In PHP, it was natural.
[+] [-] BiteCode_dev|5 years ago|reply
Not the case anymore with phpfpm.
[+] [-] atgreen|5 years ago|reply
[+] [-] Minor49er|5 years ago|reply
[+] [-] geerlingguy|5 years ago|reply
[+] [-] swongel|5 years ago|reply
PHPixie thread: https://groups.google.com/forum/#!topic/php-fig/cjLBp2weYaA
[+] [-] Ayesh|5 years ago|reply
If you are the geerlingguy I think you are, Drupal sure had an exit after Larry, and Symfony decided to step out too. Laravel didn't really follow PSR to begin with.
I use Slim framework extensively nowadays, and it has a surprisingly PSR 2,4,7, AND 15 support.
https://github.com/php-fig/fig-standards
The repo is quite active.