Each PHP file is an endpoint. As opposed to having routers in code or client side SPA routing.<p>PHP files can be deployed independently, swapped out or updated live.<p>No building/compiling of the php files needed.<p>A single layer as opposed to 'modern architecture' where there's client side back/front end layers, api layer, logic, validator, data access, and ORM layers.<p>Can extend itself as it runs. For example Wordpress, running off of php files can download plugins to its own server (which are just more php files) to instantly extend itself. Without restarting or redeployment. (What other web platforms can do this?)<p>Intuitive, simple, powerful. Can be as easy as editing a php file in notepad and dropping it on a ftp server. Deployed.<p>Amazon lambda may have more in common with PHP in terms of discreet deployable units of functionality. What's old is new again.<p>Compiling/deploying an entire system to change a single endpoint feels backwards after using PHP.
For the kinds of applications people tend to build in PHP, PHP is probably a better choice than Go. I'd still do Django or Rails before PHP, but Go just isn't designed to make serverside-rendered database-backed websites especially pleasant to write.
I love Go, for many situations, but definitely not for a typical user facing website.<p>The community seems bent on the whole "all you need is net/http", but that just isn't practical in modern web development. People like ORMs, easy to handle html forms, security as a default, easy session/cookie handling etc. In the end, web developers want ease of life.<p>Go is a great language for many things, but if it's going to take on the web at large (outside of HTTP APIs), the community needs to grow out of this "net/http or nothing" approach.<p>There is some hope, some frameworks like <a href="https://gobuffalo.io/en" rel="nofollow">https://gobuffalo.io/en</a> are showing up, but the Go ecosystem is dying for a Rails/Django solution.
I agree with the author. Symfony 4 is the best PHP framework at the moment.<p>Trying both Laravel and Symfony I think there is no need for Laravel (anymore). Laravel just has too much magic that will bite you later on.<p>The only thing you should skip in both frameworks are 'annotations'. But this is easy to do.
Go really just isn't designed for the same kind of service that PHP is normally used for. Its best at small API services (and, tangentially, its also pretty great at CLI tools).<p>> They were a little surprised to hear our stack involved Golang and some flat out told us they’d prefer PHP, because that’s what most of our products rely upon.<p>I believe this is the real reason why, and everything else above it is pointless technical justification for a sound business decision. I also believe there's an unvoiced, even more powerful reason, in "I already know PHP and don't want to learn a whole new thing."<p>These are both sound reasons. The technical justifications are not.<p>Choosing Go for something like this was a bad decision. But choosing PHP is only slightly better. Opting for Django, Rails, or Phoenix would have better technical justification, but technical justification is rarely the real reason why we make decisions like these.
Oh man, yes! Doctrine and especially Symfony's Form component absolutely spoiled me.<p>Check out Sylius for a really solid Symfony based application: <a href="https://sylius.com/" rel="nofollow">https://sylius.com/</a>
Symfony 4 is much more lightweight than previous versions. If you create a new symfony 4 project with composer you just get an empty project with just a hand full of dependencies. First time I tried out the v4 (coming from 2.x & 3.x) I thought that the installation did not work properly because stuff like twig (for templating) and other things were missing.<p>The whole integration in composer with the symfony flex component makes developing even easier than before: <a href="https://symfony.com/doc/current/setup/flex.html" rel="nofollow">https://symfony.com/doc/current/setup/flex.html</a>
Um...<p>“Just for fun, I compared apples and oranges again by benchmarking the login page (which doesn't hit any database) for both application versions using Siege.<p>The Symfony application (PHP 7.3, OPcache enabled, optimized autoloader) handles about 1470 req/s. The Go application (compiled using Go v1.11) averages about 18600 req/s.”
PHP is the same but with speed improvements in 7. But even without that the sheer number of high traffic sites built on PHP and proven scalability cannot be ignored or its ease of use and setup.<p>All talk of accessibility and ease for new users often comes off as posturing by some tech folks who then proceed to rubbish any efforts at achieving it and the compromises involved. It fits in nicely with the 'contempt culture' recently covered here.<p>The growing problem for the technical community and new users is the marketing by other languages, frameworks and those vested in these ecosystems which means using forums like this to belittle, rubbish and exaggerate any perceived fault in everything else. PHP's contemporaries like Python, Ruby, Javascript have their many downsides too but these efforts create false binary narratives. This is not a good basis for technical decisions or informed discussion.
It's interesting that he names Symfony 4 as one of the main reasons he uses PHP again after he already used PHP with Laravel.<p>I have a lot of discussions with friends in the startup scene about the topic of Laravel vs Symfony. So far it's a head to head race.<p>I have yet to find a good 'Laravel vs Symfony' comparison page. Yes, there are tons of 'SEO optimized articles' with this title. But I find them all rather uninformative and often even totally wrong and unfair.<p>The page I would love to see would have the same project coded twice. Once with each framework. And then display each file on the left for Laravel and the corresponding file on the right for Symfony.
Question : modern PHP is great for websites, but what are the solutions when you need to make some async work ? For example if I need to make few third party API calls in parallel ? With Laravel I resorted to using queues which feels like more complicated than it had to be (each worker takes up quite a bit of memory). Eventually I switched to SQS + Lambda + node.js.
Is there any mature way to do async work in PHP ? In Node.js for example, it's quite trivial and powerful with promises and async/await
> Honestly, Go is great. Its simplicity is refreshing and its performance unmatched. I would still pick it if we need a small API or something that requires high throughput.<p>I wonder which part is performance unmatched?<p>My opinion would be Crystal language for its simplicity and higher throughput but unmatched performance is behind Rust and C.
What IDE do people use for PHP these days? Editing PHP in a standard text editor is a pain because most don't supporet "Go to definition", or "Find all refernences" (Two killer features of Visual Studio)
Internally, I think PHP is great for prototyping. I have written systems in Go and PHP, and I think each has their strengths.<p>I like the batteries included standard library and single binary deployment of Go.<p>PHP, like others have said, gives you a single endpoint and you can make rapid changes. Its ideal for internal web apps that do not require insane performance.
In all seriousness... doees PHP have C# envy? With all of the stuff that has been put into PHP7 (like typed returns and typed arguments) and stuff being proposed (like annotations), PHP isn't that far off from being a interpreted brother of C#.
Golang is awesome once you submit and accept its intentionally mediocre design as a work of mysteriously genius simplicity. I did that myself and now I love it.
I'm finding that although golang offers type safety it introduces a new kind of error class to applications typically not encountered in web apps of the python/php/ruby/node class.<p>Deadlocks and race conditions.<p>For node, the entire app is a single thread so this just doesn't happen. For python/php/ruby concurrency is abstracted away and handled above the framework layer so the programmer never has to deal with it. You can launch threads in a route handler for these languages but it's not often done and you have nothing like a context object that is basically this abstraction leak that explicitly forces the programmer to constantly be aware of concurrency issues.
Well comparing Go and PHP is kind of difficult, because they are targeting completely different goals.<p>After some years of development, both languages have evolved a lot and they both can be used for many other things, that they haven't been designed for.<p>PHP was a dynamically typed scripting language to build personal homepages (Personal Home Page Tools). Today it is an object oriented, type hinted language that supports functional and object oriented programming, many database management systems and has a package manager (composer). I really like PHP (see <a href="https://github.com/sandreas/m4b-tool" rel="nofollow">https://github.com/sandreas/m4b-tool</a> for a proof), but some concerns about PHP have always been (and still are):<p>- backwards compatibility reaching too far<p>- way too big standard library (see levenshtein function)<p>- the "callable" concept - call_user_func_array([$obj, "method"])<p>- mixing up too many concepts (OOP, Traits, Functional style)<p>- the type system (which is getting better with php 7)<p>- unpredictable statements - empty($x), comparisons (== vs ===) and the "mixed" type<p>- the "array" type being array and dictionary and...<p>- the $ used for variable declaration<p>- $this-> is still needed for calling object methods<p>- "." for concatenation and "\" for namespace separation<p>Another bad thing about PHP is, that on most web servers it is meant to be stateless, which means that you are in trouble using technologies like websockets.<p>Some of these things unfortunately mean that PHP often is much slower than it could be - and this is where "go" can be a successor. Performance. If you really need FAST web apps and performance is the goal, go can be a nice choice. But for getting things done in a not too complex web page, i would always choose php.