It always seems to be a challenge to upgrade dependencies for these projects. Its usually because (in building the thing) one can't fully follow the "prescribed" way of doing things with the god framework, because each project has to deal with a niche infrastructure environment and/or business context that requires some hack or additional dependency. Then when you need to, say, upgrade a language version, you can't follow the god framework's guide for doing this (if there even is a decent one) because it will break your workaround. So you end up with this hodgepodge which never gets updated until it reaches a critical point where it cannot continue to run on your infrastructure, and it forces a big migration project.
Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.
I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.
If you're making a simple app then web frameworks can feel downright magical (like the original "Build a blog in 15 minutes with Rails" demo [1]), but for anything that gets even remotely complicated, I find that they generally just get in the way.
I personally have grown to prefer the "mid-level" HTTP setups, like Express with Node.js or Vert.x with Java.
[1]
Flask prescribes so little that every project is a snow flake. Which of the N available options will you pick to handle auth/templating/cookies/email/whatever. Real decision fatigue when trying to enable core functionality. Extra special is that many of these libraries are single author creations, so maintenance and security are a mixed bag.
Django - every project roughly looks the same. You get so much out of the box that you must have special requirements if you must supplement with libraries. Since so many bits are first party, you have greater confidence that code is being maintained/checked for security problems.
Counterpoint: PHP.
PHP 5.3 had an even less capable type system, but developed several usable frameworks.
Not having the equivalent of hibernate level ORMs is not a disadvantage for me personally, just because I don't like ORMs - Asking chatgpt to spit out some SQL and mapping code for me and being able to tweak the actual SQL over time is preferable (but again that is just my preference).
I don't really agree with the idea that Go has an underdeveloped type system, I think its contraints lend itself to productivity in other ways. Of the various languages I've worked with, Go programs I expand have the highest chance of working the first time I run them, because the compiler and language server A) give meaningful indications of mismatched usages and B) older Go projects have a very good chance of just working, without me having to worry about getting them going with my IDE again. B is a product of the fact that they have been very conservative with the language.
Can you give any specific examples?
I'd like to see which of these are open source. And whether or not they're funded for maintenance.
Ever want to type `$model->foo instead of $model->getFoo()` but then have `$model->foo` magically call `$model->getFooAttribute()`, but fall back to `$model->getAttribute('foo')` if that method doesn't exist? Then that magically calls some casting methods, and possibly even fetches infinite records from a remote store? It is so artisan, bro. I can tell you more if you got five minutes.
The fact this happens to lead to more organized and testable code masks the wastefulness in the original goal of such an effort. It simply trades back-side efforts that may or may not ever be required for additional front-side effort with the result of making things easier later if it happens to be needed. I’m not saying it is completely a bad thing, more that it isn’t de-facto a good thing either.
I guess, like with all things, the important part is finding the right balance for the situation.
This matches my experience, literally took months to migrate an older Spring project to something with fewer CVEs and bugs. Created some new bugs and issues along the way, including one where compiling it on Windows would produce a .jar that runs fine, whereas compiling it on Linux changed something in how the Spring beans are initialized, leading to it failing to even start (the settings for allowing lazy initialization changed nothing).
> Using a selection of libraries to build up the elements of a web service, and creating your own high-level abstractions for utilizing them, does require an additional time investment, but it leaves you in more control to do upgrades piece by piece, and to pivot the way things work when it is needed.
Yes and no. If you only wire things up, then sure. But depending on how much code your devs have to write (and depending on the devs), you might actually end up with a bespoke mess if you have to dig into writing various base mechanisms (think transaction handling, scheduled tasks, task pools for parallel execution, key/value stores and caching, validations, auditing and metrics, file uploads and downloads etc.) - one that will have less documentation than something like Spring Boot, you won't be able to ask anyone how to solve issues in it, alongside sometimes just having architectures that neither scale nor work properly, because it isn't something battle tested over literal decades.
> I feel like the Go ecosystem follows the latter approach more than most, and it was bit of a mindset shift for me at first, but I've grown to appreciate it.
I still agree with this, to me it feels like the correct approach is indeed to give you most of the tools you might need for the technical bits and make you (or other devs) only write a bit of glue to wire everything up, to order how data moves through your system (resources, services, validators, repositories etc.) according to whatever business rules you might have. Things really go south when you miss out on that detail.
In the Java land, I think Dropwizard is a good example of that: it uses a bunch of mostly idiomatic libraries that are well tested, without being quite as rigid as Spring (and Spring Boot), letting you set things up as you please and also not getting in the way too much: https://www.dropwizard.io/en/stable/getting-started.html
In Go, I really like that a lot of the stuff is already present in the standard library.
I understand this for a large codebase where rewriting is not feasible.
But if that wasn't the case, a C# APIs achieves both speed of development and execution in my experience. You'll rarely need to reach for C++ or Rust.
PHP is great but the language still doesn't allow things like typed arrays. It will happily accept string in a array of dates, for example.
PHP is really nice if you dig into it, it includes so many great functions and functionality built in for creating web stuff.
It also has a number of issues,. but to quikly put something together PHP take the win in my limited opnion.
PHP’s initial appeal was you could do scripting on the server side, “turn off PHP with a ?>” spit out normal html, and “turn back on PHP with a <?php”.
For a beginner programmer, it was simple, easy to understand, and had an include so your designs were’t nested table hairball messes of garbage. (but your CSS was definitely garbage).
Today, it’s so easy to run JavaScript, I can build a basic jsx site in under an hour, just like I can with PHP and includes. With Bun, I can quickly write a data access layer as well and wire up crud APIs w/ JWT auth. A weekend project in both.
Yeah theres a bunch of oddities that rear their head from time to time.
I've had one peculiar JSON de-serialize bug lately that really threw me for a while. I normally do the json_decode() with the second arg set true, which yields an assoc arr. This doesn't tell the whole story though. IF the key is numeric when decoding, PHP will make its key an int! and not a string like the rest. I'm guessing it does the equivalent of an is_numeric() check or something.
This yields an array with keys which could be ints and strings :/
Still for all its warts though it is a fantastically Frankenstein of a language!
While completely true, you are using static analyzer anyway which won’t let you do this.
The generics support will likely come in the near future, there has been momentum in it again: https://thephp.foundation/blog/2025/08/05/compile-generics/
But as PHP have released newer versions I'm convinced our migration away from PHP (which is just finishing) is probably a step backwards _now_ that PHP is awesome.
Everyone still thinks it is like 5.x days, it really isn't.
It's definitely better, but awesome? That's a huge stretch.
https://github.com/el7cosmos/pasir
Which uses the following Zend API bindings for Rust:
https://github.com/davidcole1340/ext-php-rs
There's also all sorts of interesting experiments, like ngx-php, which basically embeds PHP via Zend API inside an nginx binary: https://github.com/rryqszq4/ngx-php
And workerman, which has a hybrid backend of asio libraries, so you can get pretty fast runtimes: https://github.com/walkor/workerman
I think some orgs just need to take the jump and plan a rewrite, add tests (easier with Go) and just do this if they are a PHP shop, I would say it's worth it.
Instead of blending Rust/PHP or Go together and having an unmaintainable mess of a codebase.
Go is a pretty verbose language, whereas for me PHP is somewhere in the middle of the pack in terms of verbosity (Haskell would be on the terse side, enterprise Java and Go on the verbose end, particularly due to the constant error-checking after every function call).
But I would say a 20k line PHP app is pretty small… we probably have 20 different 1k+ files in our app. They’re not pretty but they’re still fast enough and they work so I’m not gonna try and rewrite them just for giggles.
That said, when working on this legacy behemoth, it’s not uncommon we find a way to delete a few hundred lines because there are so many old features that aren’t needed by the business anymore so we can remove that cognitive load from codebase. Maybe that had a similar experience and the rewrite was just a good time to get buy in from the business to admit that the features weren’t important anymore. We run an e-commerce site so there are lots of little marketing experiments cluttering the app and it’s a constant churn to remove old ones and add new ones for people to tweak and test with feature flags. Removing dead code is just a part of the job.
Php isn't perfect but it has a lot of shortcut syntaxes that go just doesn't have
Go made this worth it and it also was easy to hand over to another experienced developer.
Ive done do rewrites of stuff in python and it gets really verbose, plus dependency injection patterns for testing.
If you combine Go + Templ for instance, your "if err" are mostly on the DB calls. What you needed to check in PHP anyway.
Yes, the if err != nil is extreme frustration when your doing for instance, type conversion. But if your already doing this with reflection in your DB calls (by casting to the correct types in your struct), that saves a ton.
Same with getting external data, casting it directly to structs and if something is wrong, its a single "if err".
And if your just doing PHP style programming in Go, well, _, ignoring errors like PHP does and you can panic/recover to make Go act as badly as PHP, to save on the "if err". ;-)
It should be more like: what pixels is the user about to see? What data is need to set the the pixels? What data is likely needed next and optimistically pre-fetch - something like that.
I get to forget about HTML and Javascript, CSS, most of the complication of the browser and web, and just write an application in my favorite language which will run fast and deliver GL accelerated graphics to it's users.
I am really happy with WASM / WebGL for being abstractions which allows for this.
Cool that you’re creating an actual desktop-style gl app with it.
https://www.php.net/manual/en/book.ev.php
Intrinsically minimized state (to a certain degree).
And solutions that try to fix this (custom templating engines, runtimes that run the whole thing inside a continuous PHP process) are simply putting lipstick on a pig.
The solution is to use a language that wasn't originally called "Personal HomePage"
You usually build the modules yourself in the Dockerfile, for example for the "pgsql" module:
RUN apt-get update && apt-get install -y libpq-dev && docker-php-ext-install pdo_pgsql && apt-get remove -y libpq-dev && rm -rf /var/lib/apt/lists/*
http://:80 {
# rest of the Caddyfile directives
}amqp,apcu,ast,bcmath,brotli,bz2,calendar,ctype,curl,dba,dom,exif,fileinfo,filter,ftp,gd,gmp,gettext,iconv,igbinary,imagick,intl,ldap,lz4,mbregex,mbstring,memcache,memcached,mysqli,mysqlnd,opcache,openssl,password-argon2,parallel,pcntl,pdo,pdo_mysql,pdo_pgsql,pdo_sqlite,pdo_sqlsrv,pgsql,phar,posix,protobuf,readline,redis,session,shmop,simplexml,soap,sockets,sodium,sqlite3,ssh2,sysvmsg,sysvsem,sysvshm,tidy,tokenizer,xlswriter,xml,xmlreader,xmlwriter,xz,zip,zlib,yaml,zstd
https://github.com/php/frankenphp/blob/main/build-static.sh#...
It’s the best of both worlds - the new app gets to see all of the traffic, but doesn’t need to implement 100% of the routes. Any added to the new app can just take precedence over the old one, carving out the path-space that gets reverse proxied.
It seems like doing FFI for this is overly complex; I’d rather take the small perf hit of doing another request to a different process.
I really think there's a big opportunity for somebody to create the astral.sh for PHP.
With a proper package manager, PHP can do way more than what it presently can.
Not only that, but now we have these "frankenstein" solutions with all the interop problems on top of PHP.
Just shows that as a species humans really can't learn.
We can "lipstick pig" a lot of those problems by using typescript or whatever, but now we're compiling JS and the output isn't even fast. At that point use a competent compiled language like C# or Rust.
They’re basically equivalent now.
One of the reasons I like Perl is because of its high committment to backwards compatibility.
I like PHP because it's so easy to set up an installation of my app, but the breaking changes have bit me hard in the past, so I try to minimize its use.
Together, it's a great combo.