Wow the PHP is going to magically get into the binary?
/s
Yes I could build this with c-go + the PHP and statically link everything (and there might need to be a bit of prayer involved...) ... or I could just write GO and accomplish all the same things with fewer steps.
That knotted up mess is why containers are popular.
There are things Go excels at and there are things PHP excels at. They don’t always overlap. For example, you can write a simple web app in 100 lines of php code, and a process manager in 100 lines of Go code. If you flip the languages around, the number of lines explodes.
I started writing PHP back in the 3 and 4 days... I have been writing go for over a decade.
If I had to add a few dynamic elements to a static HTML site, php is still king.
If we're building an API, go will win hands down. Not only in LOC but performance, and reporting.
When you get into whole pages (think blogs or shopping or... ) a lot of that is going to depend on what framework you're grabbing on the PHP side. There arent a lot of "batteries included" solutions on the golang side... You might end up writing fewer lines of code in the first week but by the end of the month were going to be at feature parity and your quickly going to fall behind.
The moment I need a SPA, on page interactive GUI you're going to end up with a JS framework and an API back end... here again, go will shine.
> If we're building an API, go will win hands down.
I'm not so sure of that. Writing business logic in PHP is usually more concise than in Go, and more flexible. Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP.
>> Also, I can think of a number of json schemas that are impossible to replicate in Go's type system but work just fine in PHP.
Not at all. There are some that would be painful to write "by hand". An expansive and nested set of null fields would suck if I had to spell it all out...
https://sqlc.dev << changes everything. If you add in the YAML (and I hate yaml) you can get your JSON to DB mapping in there, as well as your validations (all output as struct tags).
Everything else that you're going to want (transforming inputs to/from json, logging, auth) is some pretty simple middleware.
You can't fully replicate JSON schemas in either language without writing logic.
In terms of just static definitions, Go has typed container types while PHP has not. That's a pretty common case for JSON. PHP is more convenient at another common case which is heterogeneous maps. Neither of those languages make me particularly happy in that regard.
It also depends on what you're doing with the JSON. If you want/need to walk through it in a single pass fashion, then Go is definitely more fitting.
> PHP is more convenient at another common case which is heterogeneous maps.
Or arbitrary, user-defined keys...
> If you want/need to walk through it in a single pass fashion, then Go is definitely more fitting.
array_map, array_reduce, array_column is pretty good at walking through arrays very quickly, assuming you parsed the json into arrays instead of objects.
If you use the std lib you can write a simple web app in Go as well in few lines of code?
The only difference would be a little bit of boilerplate for setting up application state (a few lines) and the necessary type definitions, which you can avoid with PHP if you just deal in "arrays" instead of classes. But I don't think the LOC would explode for Go.
My big counterpoint is this however:
I would wager for a beginner of either languages, it's much more straight forward to get a server running with Go than with PHP/Apache. There's no configuration, you don't need to install multiple things, you don't need to learn about a thousand footguns, error handling is more streamlined and obvious and you wouldn't have version issues and get showered in deprecation warnings down the line. And even though the PHP docs are quite extensive and useful, they are not on the same level as authoritative Go docs and guides. PHP has three advantages over Go in terms of convenience and ease of use: statelessness, little bit easier to deploy (once set up) and very cheap, easy to use hosting products available.
> If you use the std lib you can write a simple web app in Go as well in few lines of code?
PHP is made for web development though, while Go is made for different use cases. Comparing the standard libraries makes this very clear.
Things PHP comes with that Go doesn't come with (just as some examples about standard library differences): PDO (DB interface), session management, built-in mail sending, localization and internationalization. That's just from the top of my head.
Go has it's places though, and it works well for web development too. But even I who like Go in general more than PHP, can acknowledge that PHP (by default) is better setup for web development out of the box.
That said, I would much prefer Go than PHP too, but hard to argue against PHP for web development without resolving to emotions and feelings.
Apart from localization all of the things you mentioned come with Go as well. There's net/smtp, database/sql. You can implement in-memory sessions in Go with a few lines or use the well established gorilla sessions or similar.
The only thing you _need_ to install via dependencies is a DB driver.
On top of it you are getting a HTML template system with very good security defaults. You are generally better guided and guarded when dealing with HTTP user input. Routing and handling is more explicit and doesn't require you to deal with the Apache configuration syntax etc. There are no arcane configuration footguns like max_input_vars that will silently break your application and so on.
Errors handling and logging are again, more straight forward, universal and explicit.
If you need interactivity, SEE and Websockets are not only easier to use but also a more natural fit for Go.
I think for a language beginner those things are very, very beneficial. Us more experienced programmers sometimes forget how many battle scars we had to earn with languages like PHP.
Btw, making a tarball or a zipfile is also a way to put multiple files into one binary file. You might have even heard of self-extracting zip files? They were very popular, before Windows got a build-in unzipper, I think.
Optionally, you can embed the PHP scripts in the final binary using a Go feature similar to `include_bytes`: https://frankenphp.dev/docs/embed/
But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both).
> But for PHP, it's even simpler: PHP is available as a C library, and we just use it. (libphp can be embedded using static compilation, or used as a dynamic library, we support both).
Yes, but that's completely independent from whether / how you embed the scripts? (Which you do via the the procedure described in your first link?)
Btw, how does your version of PHP compare to Facebook's Hack? I had opportunity to use Hack a few years ago, and I think it's the best language they could have made (from PHP as the fixed starting point).
Well, FrankenPHP avoids that prayer, cause it's already done for you lmao
But obviously the point of using PHP is for its ecosystem, frameworks etc. Go is still missing a lot of that, the Go community has a weird aversion to frameworks.
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/
/s
Yes I could build this with c-go + the PHP and statically link everything (and there might need to be a bit of prayer involved...) ... or I could just write GO and accomplish all the same things with fewer steps.
That knotted up mess is why containers are popular.