I wrote PHP from version 3 to version 6... I remember PHP before it had "frameworks"...
PHP ate perl because the battery's were included, you didn't need CPAN, and it had an amazing manual...
Python (pip), Ruby (gems) and Node (NPM) all looked much more attractive because they had rich library's at their core and symphony wasnt really useful yet.
Yet Go eschews a lot of the same package management issues those other languages have. And a lot of go devs look at the standard library the same way early PHP devs looked at it "I dont need a lot more than this".
It's not that go devs are framework adverse we only want what we need and nothing more. In a language that favors composition frameworks quickly become "baggage".
It's kind of interesting to watch someone come from a language with a strong package ecosystem and watch them build their first go project. They tend to cruise GitHub and throw EVERYTHING in the cart. It takes them 3-4 days of working with all that before they are complaining up a storm! You hand that same dev SQLC, Validator, and point them at middle ware and the standard lib and ask them for API's and they come back 2 days later grinning ear to ear.
Go, done well, is brutalism. Blocky, functional concrete buildings have an amazing charm to them... Go is blocky, its utilitarian, its expressive... You dont write cute code in go, you dont try to make go magical, you want clear easy to read and understand code... Your more likely to come back and add features long before you have to address the performance of go.
PHP6? That was long ago because I don't even remember it!
I don't have much to say otherwise, except you could very well say the same "Go is great" without having to shit on PHP and the project that is being discussed here.
Especially since you don't really come off as very knowledgeable on what you're talking about.
It might shock you that I wrote perl before PHP... I have been in the game a LONG time. I was around for php being the language that EVERYONE shit on. I was around when PHP got somewhat huge and respectable. PHP buttered my bread for a number of years and I was one of its bigger advocates.
None of that is very go like at all. Having spent a lot of time with PHP I recognize a good portion of what turns up in that shell script. That having been said there are parts of it (the curl of the diff) with NO context that I would pause and go figure out what the hell that was. It really needs a note as to WHY it's there so I dont have to go hunting. It looks like the shell script is meant to work in the docker container... A real build system might be in order here (make, basel, mage).
It doesn't matter you wrote perl before PHP, actually. You're talking about PHP6 like it's a thing (spoiler alert: it was never released), and you don't seem to have ever used one of the famous frameworks PHP had seen since the 2010s. Even Symfony 1 was here in 2005, and PHP 5.3 brang a complete revolution and growth of the entire ecosystem (thanks to closures and namespaces, at first), which made people embrace PHP more willingly, Composer was released, incredible frameworks were created and used Composer (that's how we got Symfony 2, and Symfony later helped Laravel come as an extremely popular framework).
All of this was funded by companies that believed in PHP, while PHP-haters moved to something else (I know that: my older brother, who's also a dev, did some PHP back then, but was more appealed to other techs like Java).
You moved to Go? Good: PHP doesn't do everything that Go does, because it wasn't meant for that.
We do PHP instead? Perfect: Go wasn't created to develop web-apps in the first place, it's a low-level network-related project, and turned into something way bigger that allows you to code web apps quicker than in Go's early life.
PHP has always been about creating web applications, and will always be, even when some people try to tinker with it on some other levels (like servers using async & threads, or desktop apps).
And honestly, FrankenPHP is an incredibly good combination of both worlds: brings all the scalability of Go, with the flexibility of Caddy (which is written in Go too) in the infrastructure, while allowing us to continue coding with all the incredibly powerful frameworks we have in PHP to create the web app.
It's the best for all the people that have an interest in that.
You can't hate on that unless you just hate for the sake of hating.
> You're talking about PHP6 like it's a thing (spoiler alert: it was never released)
Spoiler alert PHP 6 was a thing. Spoiler alert PHP 6 NOT being released was a blemish on PHP that made a lot of people say "we might not have a future here"... Python spent years going from 2 to 3 while PHP chugged through 4 and into 5. Python ripped the UNICODE bandaid off, the one that PHP could not... https://webcollab.sourceforge.io/unicode.html .
And yes MB strings work... I did a fair bit of I18N work back in the day. PHP string mishandling was in all the dark corners and odd bugs you had to dig out of a codebase. I made good money doing it, it was NOT fun...
>> Even Symfony 1 was here in 2005, and PHP 5.3 brang a complete revolution and growth of the entire ecosystem
No one gave a shit about symphony at the time unless you worked for a body shop. We all wanted to build on Zend, and for good reason. Zend server (the opt cache and debug tools) and corporate backing was one of the things that made a lot of companies comfortable with their PHP plunge. "Open source" was still rather novel coming out of the Y2k bubble, and managers were still old guard and wanted an "IBM" style name (to blame if the shit hit thee fan). There is a reason that magento chose to build on top of ZF. (SO much EAV ptsd).
It also became super common in this time to run a Drupal Or WP site for your marketing department. Slapping theses up was a no brainer, and to some degree still is. These tools a bit reason that PHP still has a massive footprint for such a large portion of the web.
> Go wasn't created to develop web-apps in the first place, it's a low-level network-related project
Umm NO.
> PHP has always been about creating web applications, and will always be
After the 6 debacle and unicode support this limitation is why a LOT of the best php dev's around moved to python, or ruby... Being able to easily reuse your tools in batch processors or cli script in an intuitive way was a boon. RabbitMQ and Sidekiq were eye openers for a lot of early 2010's php devs that things were moving on, that the "pure web" was coming to an end. Yes Composer was a thing, but it seemed pale compared to PIP or Gems (and in a lot of ways still is)...
PHP being on every $10 a month hosting package gave it legs. The fact that it's still so web focused with modern dev is now a short coming... For as much as the langue evolved it needed to evolve here and didn't.
>> And honestly, FrankenPHP is an incredibly good combination of both worlds: brings all the scalability of Go, with the flexibility of Caddy ...
From the PHP side it's impressive. From the Go side less so... One of the joys of writing go is being able to deploy a single binary with ease. I can skip "containers" all together with a standard go program.
Frankenphp has directions to accomplish the same thing... using either a docker container (this should be a code smell), or a shell script. Have you read that shell script? If you have then wee both have the same questions (Oh boy does that thing need some comments). Make, Basel, Mage would be much more appropriate here, because that shell script is UGLY AF... but these would all be harder to get working "containerless".
Unless I missed the hook, that build process doesn't even run tests first...
This is the thing with go. Can I run the tests, Can I build, is the build painful, is there a reason for it being "non standard" (the CGO qualifies here) ... is the build process sane (this one needs a lot of work) ...
This script is entirely optional and is only used to create static builds of FrankenPHP or to create self-executable PHP apps. It doesn't require a Docker image but does need some system dependencies.
It is not necessary to create a standard (dynamically linked) build of FrankenPHP and isn't used in the Docker images we provide: https://frankenphp.dev/docs/compile/
PHP ate perl because the battery's were included, you didn't need CPAN, and it had an amazing manual...
Python (pip), Ruby (gems) and Node (NPM) all looked much more attractive because they had rich library's at their core and symphony wasnt really useful yet.
Yet Go eschews a lot of the same package management issues those other languages have. And a lot of go devs look at the standard library the same way early PHP devs looked at it "I dont need a lot more than this".
It's not that go devs are framework adverse we only want what we need and nothing more. In a language that favors composition frameworks quickly become "baggage".
It's kind of interesting to watch someone come from a language with a strong package ecosystem and watch them build their first go project. They tend to cruise GitHub and throw EVERYTHING in the cart. It takes them 3-4 days of working with all that before they are complaining up a storm! You hand that same dev SQLC, Validator, and point them at middle ware and the standard lib and ask them for API's and they come back 2 days later grinning ear to ear.
Go, done well, is brutalism. Blocky, functional concrete buildings have an amazing charm to them... Go is blocky, its utilitarian, its expressive... You dont write cute code in go, you dont try to make go magical, you want clear easy to read and understand code... Your more likely to come back and add features long before you have to address the performance of go.