The Rise of Hybrid PHP: Blending PHP with Go and Rust
Comments
liampulles
tombert
Web frameworks for me are one of those things that's "great until it isn't".
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]
3eb7988a1663
In the Python world, I see this as the microframework (Flask-esque) vs macroframework (Django). I will take Django every single time.
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.
evantbyrne
The reason Go does not have a grand framework is that the language has a severely underdeveloped type system, which makes building complex libraries that meaningfully complement each other overly difficult. I waited nine years before starting on my first Go database toolkit so I could use generics. I succeeded, but can't shake the feeling that I know I had a better experience doing it with Java in undergrad. Being able to map/filter/reduce from a result type into another generic type would be a complete game changer. Being able specify union types would eliminate my need for the "any" type. Being able to overload would clean up a lot of code. It needs more time in the oven.
liampulles
I think the Java stream API is amazing, and I do like that.
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.
overfeed
> The reason Go does not have a grand framework is that the language has a severely underdeveloped type system
Counterpoint: PHP.
PHP 5.3 had an even less capable type system, but developed several usable frameworks.
evantbyrne
That's a complimentary point, not a counterpoint. I'm talking about Go's type system being restrictive. PHP and many other languages avoided that particular trap by allowing variables to be reassigned to any type. Java and many other languages went in a different direction and instead chose to build more complete type systems.
const_cast
PHP has fully looped back around and have a more capable type system than Go or even JS or Python. It took a long time, but it got there and it did it pretty competently.
In the past it got away with it because of PHP magic. PHP let's you do pretty much whatever, at least in the past.
pkphilip
PHP's type system is so "dynamic" that it is very easy to build frameworks for it.
For instance, PHP allows for even function calls like this:
$language = "German";
$functionName = $language."_send_email";
$functionName("Mike", "mike_1@gmail.", "Text ...");
This sort of flexibility has its own problems and it is only possible because of the very lax type system of PHP but it is also extremely powerful when it comes to developing reusable frameworks.
fozdenn
Yep, In my domain only Go/Rust are useful. The opinionated framework culture never fits the bill. I think Rails/Laravel/Django are great when you have a beaten path for relational DB crud.
billy99k
I've been out of web dev for a few years now, but my issue with frameworks was always the ORMs. Simple CRUD apps always worked fine, but when I had to optimize SQL queries or create something more complex, I would end up having to add hacky additions to the app that always broke upgrades.
zakirullin
PSR to the rescue! For the past ~5 years I've been only using PSR-compatible components, with no framework whatsoever. For both enterprise-grade projects and small services. The reason was the same - those all-encompassing frameworks in long run just don't work. Too many constraints, too much hustle maintaining/updating.
KronisLV
> 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.
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.
b_e_n_t_o_n
I've found this for web frameworks as well. The time you spend learning the framework's abstractions could just be spent picking a queue library or whatever you need and adding it to your Go server.
N2yhWNXQN3k9
In Laravel, the issue is that the framework is sold as "productive" as default. There is no real "beef" to the framework though, IMO. It is better today, but historically it is just a wrapper around symfony with some dependency injection through reflection, questionable serde, tons of magic, and with some unique takes on templates and routing, which are arguably not very good takes? Maybe components are better, but blade in general seems backwards as a template language.
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.
therealpygon
Never really understood using a template language when PHP is first and foremost its own template language. I also don’t understand developers making decisions now about things that might one day have to be replaced. It’s like building a bridge, but letting the plan to maybe have to tear down the bridge 50 years later dictate all the design decisions.
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.
yurishimo
Templating languages in PHP are largely about better ergonomics. Sure, you can have your own helper functions that do the html escaping or an abstraction layer to pass variables into includes without polluting global variable scope, but that’s all boilerplate.
Twig and Blade are both fine templating engines with their own quirks and features but they’re also battle tested and have proven their use over the past decade+. If someone wants to use a dedicated templating language for abstracting away chunks of HTML, it’s low on my list of complaints.
some_furry
> 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.
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.
hu3
> In short, the modern PHP ecosystem gives us the best of both worlds: the ability to build quickly and confidently in PHP, while still having powerful options (C, Rust, Go) for performance-critical parts. This hybrid approach lets us stay productive without sacrificing speed where it matters most.
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.
ThinkBeat
Having been in the C# world for a long time, and the various web/api frameworks.
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.
DoctorOW
To give an example, my main website is C#, I love it from a dev perspective and performance perspective. But I also have PHP on my personal server and will knock out PHP scripts for one off demo projects. I just ssh into my server, `vim projects/example.php` and it's instantly deployed as a link I can share.
hu3
There's `dotnet run` now. You can:
vim projects/example.cs
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
Not the same as PHP I know, but it's close enough for me.
DoctorOW
I'm glad it works for you but I guess that doesn't really cover the use case I was talking about because I want to have a bunch of these. As an example, I threw together a quick web hook processor, data from one service reformatted to fit another. I don't really need to spin up a whole new VPS for an endpoint that'll only be hit once or twice a week, so this is the workflow for doing that on the server I already have.
PHP:
- vim projects/webhook.php
- vim projects/webhook.cs
- Assign a port number
- Reconfigure Nginx/Caddy to serve that port number
- Reconfigure systemd to dotnet run projects/webhook.cs on startupmircerlancerous
Completely agree. I don't work much in PHP anymore, but there's still nothing that's faster or easier to get something up and running. I use it for web services, and command line scripts when I just need something fast.
reactordev
The only reason PHP still exists is because of shared hosting companies and Wordpress.
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.
hnlmorg
PHP might have a bad reputation but I honestly don’t think JavaScript is a better language in real world terms.
I do get why JS appeals to people, but switching from PHP to JS feels a little winning an internet argument — you might feel smarter for doing so but in reality all you’ve done is sunk time into something that doesn’t make you any better off.
tialaramex
There's a firm foundation in Javascript. The choices aren't choices I'd make but they're choices I understand. Brendan Eich knew what he was doing and it shows, indeed if it was made simply of bailing wire and string it'd have been replaced.
For PHP on the other hand - even when I started writing PHP3 - so certainly not the very beginnings, it's clearly just cobbling together whatever works from unrelated half-understood parts and so there's no coherent centre to it, when I last worked on some PHP earlier this year it still felt like bailing wire and string.
hnlmorg
The JavaScript invented by Eich is nothing like the clusterfuck that is the modern JavaScript ecosystem. And modern node.js code will look nothing like the JavaScript Eich developed for Mozilla.
Equally, PHP3 is worlds apart from modern PHP.
Your point is a little like saying “motorbikes are easy to maintain because they’re based on the penny-farthing”. Times have changed and your references are literally decades out-of-date.
zelphirkalt
Do we need to post that JS' weird things link here? Of the basics of JS, few things are sound. The "firm foundation" idea doesn't really work for JS. It might even work better for PHP, and I am saying that as someone, who doesn't want to do PHP ever again.
com2kid
JS is very much a minimal language that has a handful of choices. E.g. arrays being objects with field names that are sequentially numbered integers.
The initial equality operator was a mistake, but that was rectified over a decade ago with `===`. Not having a proper int type sucks and holds the language back in a number of ways, but otherwise the language is wonderfully regular.
And anyone who complains about the ecosystem has obviously never tried python, which after a decade of attempts, is now almost on par with JS of a decade ago!
hnlmorg
You shouldn’t compare backwards.
Saying “at least x isn’t as bad as y” doesn’t further a discussion, it only acknowledges denial about just how bad the problems are with x.
This is particularly true when we weren’t even discussing y (in our case, Python) in the first place.
austhrow743
What if the context isn't that you're switching from PHP though? What if the choice is to stick with Javascript for the full stack, or to also learn PHP on top of Javascript?
phplovesong
JS is basically just a comp target as of 2025. If PHP devs used something like Haxe they would be amazed how safe their programs would be. But i usually just see slop instead.
const_cast
PHP has a much more competent type system than JS and is overall more ergonomic IMO.
Typescript exists, but if I'm compiling something I'm using a real language or framework like dotnet. There's no reason for me to use typescript and node and install 100 packages when I can just install dotnet.
reactordev
install dotnet, and install 100 packages for .net core, asp.net, identity, ef, etc. Don’t kid yourself.
While strongly typed languages are great. I like to be able to get things done. This is why I don’t C++ anymore. This is also why I don’t dotnet anymore. Too much BS with the type system and correctness and the Microsoft way or lack of support or rug pull. They lost me when they killed XNA.
Typescript is actually good, except for the fact that it’s a transpiler to JavaScript. That part sucks.
I want a C++, with Types, with memory safety, with garbage collection, with pointers, with a dev experience like dotnet, but we don’t have those things.
freedomben
I'm not a huge fan of PHP, but for simple sites I think you way underestimate the power and simplicity. It feels old compared to jsx approach, but old doesn't always mean bad. I've increasingly returned to the template rendering model pioneered by PHP and for sites that aren't full blown apps, it is a lot simpler which means faster iteration and reduced cognitive load. I think you really have to decide based on the complexity you need
sublinear
> I think you really have to decide based on the complexity you need
I don't really agree. I think the goal should be to reduce complexity where possible, but not if you're inevitably painting yourself into a corner.
If you want the simplest and most scalable way forward, write static pages and avoid server-side rendering.
zelphirkalt
How would you be painting yourself into a corner with PHP more than with JS? If you use PHP, you can just serve/use JS later. But if you use JS, you will have a hard time serving HTML from PHP later. Aside from both languages kinda being painting oneself into a corner, I don't see how one would do more so with PHP than with JS, out of all the things.
reactordev
The issue is, if I’m using JS, why on earth would I ever use PHP? I can just await file('index.html') or return <IndexPage>
The cognitive load is null. You’re just having trouble breaking apart your learned behavior. Returning a component of jsx is just the same as writing an include for PHP.
sublinear
I'm coming from the perspective of real world business concerns, not hobby projects.
It's inevitable that you will need to host the pages somewhere else like a CDN to lower latency, integrate with other backends, and the biggest one is allowing the frontend devs to have complete control of the HTML so that stylesheets and javascript don't randomly break for reasons out of their control. They should be able to develop everything locally with mocks instead of your server and use whatever build tools and frameworks they want. There are also SEO and accessibility concerns with the page structure. The backend devs should not be making decisions about any of that. Sometimes the client may want quick turnaround on simple but very specific changes to the pages. None of that process should depend on backend teams who don't care and will drag ass about it because they will have to refactor their junky code that hasn't been touched in years.
Getting rid of dependencies and having good boundaries in the code that align with the way dev teams are organized is always a good thing. I'm not sure why anyone would go for SSR unless they haven't done web dev in a while or are working on a legacy project. Even if this starts out as a hobby project, you need to keep things clean for future maintainers.
reactordev
I agree with all of that except for SSR part. SSR is back, like it’s 1996. However this isn’t your old school monolith serving jsp pages with tag classpath hell, this is client side pages served from the server for faster rendering. We now have another layer.
Browser -> Client-Side Server Pages -> Business Logic APIs -> Backend Systems.
monooso
> The only reason PHP still exists is because of shared hosting companies and Wordpress.
Unfortunately I can't think of anything constructive to say about this nonsense.
> 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.
You assume people agree that it's preferable to work in JavaScript.
phplovesong
Sadly this is true. From PHP websites 95% is wordpress/drupal/<cmstool>
k_roy
And still nobody outside of Meta cares about hack.
The niche I think PHP had back in the day has largely been supplanted by Python.
Maybe it’s better now, but after moving on from it to basically anything else after a 25 year career, I don’t miss it.
monooso
I'm not sure what point you're trying to make by mentioning Hack.
At this point it's diverged from PHP to the point that it's basically a different language, is (IIRC) actually slower than PHP 8, and the HHVM doesn't even support PHP any more.
As such, it's not a huge surprise that relatively few people outside of Meta give it much attention.
I also moved on from PHP several years ago, and don't miss it. That doesn't mean I don't recognise that there are still perfectly legitimate reasons to choose it.
k_roy
Yep.
And meta/hack is probably the other huge mainstay of PHP outside of what the person you responded to said. And hack with HHVM was supposed to be the panacea for PHP
Just saying.
What people used to use PHP for tasks, has largely been replaced by Python.
timeon
> And still nobody outside of Meta cares about hack.
Because everyone is OK with PHP. I'm not even using it directly but most of the web runs on it.
phplovesong
Not PHP, but wordpress.
jofla_net
>It will happily accept string in a array of dates, for example.
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!
honorary-hickup
> It will happily accept string in a array of dates, for example
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/
s1mplicissimus
I'm working in PHP for about 15 years by now, and for about 10 of them I was promised generics. In favor of your health, don't hold your breath.
avan1
Author here. thanks for reading my post. actually you still don't need rewrite. running php with workers (swoole, frankenphp, ...) may be as fast as node. and for typed array php has static analysers like phpstan. it support generics and typed arrays with typed comments.
newuser94303
I would never use a Microsoft language since they discontinued VB6. Open Source languages are the only sane option.
mrsmrtss
And you are not using Typescript either, because it's a Microsoft language? Also .NET is open source over a decade already and c# was free and open from the beginning (Mono implementation).
chairmansteve
C# is open source.
1a527dd5
Joined {{company}} when everything was using 5.4, there was a big distaste of PHP back then.
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.
criemen
I'm not so sure: If you think about hiring talent, there's a perception in the wider industry about PHP (rightly or wrongly, let's not debate that here) that'll prevent access to a lot of great developers. So even if not warranted anymore on technical merits anymore, in terms of employer branding, I'd say migrating away from PHP is helping.
adamors
Right on, I wrote a lot of PHP 15 years ago and I swore I’ll never get back to it. I’m a much better developer now and I’ll actively avoid any company doing PHP in 2025.
const_cast
PHP is a very different language than 15 years ago, and large applications are pretty much indistinguishable from Java or dotnet. The type system is more cohesive than JS or even Python at this point.
IshKebab
> now that PHP is awesome.
It's definitely better, but awesome? That's a huge stretch.
avan1
4 years ago we have been in same situation and we choosed to continue in php with choosing version 8. so far it works for us all these years.
tomrod
PHP is growing on me. I'll have to check it out -- thanks for the idea!
klaussilveira
Pasir is like frankenphp, but in Rust. Very promising, but still early in development:
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
avan1
thanks for suggestion. looks cool. but as you said far from production ready. we choosed frankenphp since we saw it got support by php foundation.
imcritic
Does any of this have some kind of support of existing PHP modules?
conceptme
The complexity with debugging and maintenance seem to be overlooked, if you have the option don't do this.
avan1
thanks. but may you explain more. we just choosed frankenphp but i did't see if it makes debugging it much worse.
pancsta
Working with 3 intersecting stacks is more complex than a single stack. Go toolchain is batteries included and coherent. Author admits to not using it bc of legacy (and preference).
avan1
author here. as i mentioned in post i said we choose frankenphp since it's already supported by php foundation and in some cases we might use Go php extensions. i know writing extensions in any language add a bit complexitiy but i believe if the extensions selected wisely they will be somehow fire and forget. for instance creating pdf files would be faster in Go than php. you can create an pdf creator extension and that extension would probebly work for a long time without any adding much effort to maintenance.
imcritic
FrankenPHP sounds promising, but in reality it is a weirdo: no one uses PHP without modules. Where is the list of PHP modules supported by FrankenPHP? Is it possible to compile it with some extra PHP modules? How? I see it is tightly bound to Caddy. I am not much familiar with that webserver, I would prefer nginx, but there's not a single guide mentioning if that's possible to use nginx with FrankenPHP (as a php-fpm replacement). Also, either Caddy itself, or FrankenPHP's docker image is quite opinionated in regards to using let's encrypt certificates and it is not trivial at all how to make it work via HTTP (if something external would provide SSL) or using own certificate.
supriyo-biswas
> FrankenPHP sounds promising, but in reality it is a weirdo: no one uses PHP without modules.
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
}osigurdson
Sometimes I think we should go back to basics: pixels, data, latency / bandwidth. The web is an optimization problem in the sense that we want to render correct pixels at perceptual speed given latency and bandwidth constraints.
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.
timschmidt
In https://github.com/timschmidt/alumina-ui I've been building for WASM using the egui toolkit which just accepts an HTML canvas the size of the browser and starts shouting WebGL at it.
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.
osigurdson
This! Love it!
timschmidt
Thank you. There is still a lot of work left to get it controlling it's first machine. I am currently figuring out how best to build for all the mcu and board combinations I expect to support, and then wiring up motion control to the UI. Just got the node-graph interface for csgrs working and there's still a lot left to flesh it out fully. Advancing slowly :D
Please consider joining the Discord: https://discord.com/invite/cCHRjpkPhQ
I'm the only one in there at the moment. Bring friends! lol
sneak
I was wondering how long it would take for the web to get to this point. It seemed inevitable once canvas became a thing. You don’t even technically need gl or wasm to rewrite an entire rendering engine in js that can just blast pixels at the full-size canvas.
Cool that you’re creating an actual desktop-style gl app with it.
timschmidt
I'm looking forward to the day when Javascript can be just another WASM polyfill loaded with the page with a well-defined, portable, and fast API to the DOM. Also can't wait for WebGPU to be adopted in more places. Right now I rely on WebGL2 because WebGPU isn't available in Firefox/Linux stable by default.
Another minor annoyance is that 'cargo bloat' and similar tools don't yet have backends for wasm, so I need to fix up the native build to make use of that sort of analysis, which I'd like, because I serve the whole application from microcontroller flash where I only have 4 - 16mb to hold application and firmware, including the http server and network stack.
sneak
I don't. I don't want the web to become just a runtime for opaque binary applications. Right now we still maintain some semblance of user control over the DOM and the application; when everything is WASM and WebGPU using its own custom renderer, the ability of people to casually inspect, modify, hack, tinker, and tweak will be completely over.
I learned how to build for the web by looking at webpages and seeing how they worked. What you're describing is the switch from circuit boards of discrete components to everything in a single microscopic IC under a blob of epoxy.
timschmidt
I recognize it as a more or less universal optimization process. Everything important ends up in silicon, if it remains important long enough. And there are several stages of that.
Like you, a part of me years for SGML and The Semantic Web, and where it makes sense in Alumina I am using RESTish APIs.
But I do not pine for Javascript. Language or frameworks. 20 years has been enough. And I do not believe that some of the 4mb minified obfuscated js downloads from a CDN I've seen are in any way more accessible than a WASM binary of similar size. At least there is advanced tooling for the WASM representation. Folks who want you to read their code will still make it easy, and folks who don't won't.
To your point about learning, WASM makes some really incredible systems like https://lovr.org/ available in the browser, which I would have loved to have as a kid, but which also aren't javascript. It's related to Turing completeness somehow, once you let a little software into your structured document, it all wants in. Or maybe it's "if you give a mouse a cookie"?
I understand what you're saying about discoverability. But the developer in me really likes having a relatively simple binary interpreter to target for network-delivered cross-platform binary applications. My hope is that offering such a juicy target to the folks who want to develop applications (including myself) gets them out of all the semantic document features, allowing both sets of code to get simpler and more focused. Because I think they're two different, both entirely valid, tasks folks use the web for.
osigurdson
If you look at a typical next.js type app with all of the build steps, minification, post-css, tree-shaking, client side / server side, etc., it isn't exactly optimized for reverse engineering. Maybe that ship has already sailed.
singinwhale
Thinking about user seeing pixels is seeing just a part of the picture. As all software projects you don't optimize just for immediate user experience but also development time. Time to first draw rarely coincides with development time.
osigurdson
Dealing with over-fetch / under-fetch most certainly does chew up development time. Creating endless api endpoints that are only used by the web UI is also very time consuming (the industry is finally recognizing how dumb this is and moving back to older SSR approaches). How about, "the user is allowed to access this information on the server - system you figure out what / when to fetch portions of this information for viewing"?
redwall_hp
And I don't care about pixels; I want to see structured documents. How I choose to view those is my business.
osigurdson
Got it, you don't care about how the sausage is made. That's totally fine.
networked
It doesn't sound like this is what redwall_hp meant; it sounds like what they meant was that pixels are the wrong level of abstraction. If so, I agree: the web is about marked-up text. When you break it down to the very basics, what you get is a teletype, not raster.
resonious
I tried to propose this with Ruby and Rust. We have a super old Rails monolith and want to hyper optimize just a few endpoints. Simply allowing Rust to "poison" the monolith a bit makes gradual adaption very easy. And you keep a lot of the productivity gains of monolith. But people just seemed to prefer full on network boundaries and separate services.
trog
Very curious what sort of workloads are being talked about here that have the intensity that have C or Rust or Go extensions are necessary? I can certainly believe they exist but I'd be really interested to find out more and why it makes sense to add this complexity into the stack and not solve in other ways.
dakiol
The one thing I don't like about PHP is that the whole application is bootstraped (and autoloading and the configuration is re-evaluated) in every single http request. Sure thing there's cache and all, but it just doesn't feel right (compared, to, for instance, an http server written in golang)
klaussilveira
There are well documented and production-ready libraries that you can use to run your own servers with PHP alone, no need for fpm or mod_php. PHP's JIT is pretty impressive and you would be blown away by the results.
https://www.php.net/manual/en/book.ev.php
duskwuff
It doesn't have to be. Some PHP runtimes allow an application to run in a mode where a single script execution processes multiple HTTP requests:
PetahNZ
This is one of the best things about PHP IMO. It makes it very easy to scale out.
const_cast
It also makes it much easier to debug and forces the complexity down.
bornfreddy
Yup. No shared state by default.
mhsdef
This is one of the things I do like about PHP.
Intrinsically minimized state (to a certain degree).
creatonez
You're right. It's a completely asinine approach. Especially when PHP itself is used as a templating language.
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"
thr0waway001
Good to see PHP still trucking.
RainyDayTmrw
One of these is not like the other. Go is also garbage collected. Embedding a garbage collected language inside another means you have two garbage collectors fighting each other.
ok123456
It turned out that dlopen was the "microservice" architecture we needed all along.
vadepaysa
I owe a large part of my career success to PHP when I learned it back in the day. But recently I picked it up because I had to do some maintenance work and The package management experience was really, really bad.
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.
porker
What did you find bad about composer?
porker
PHP's FFI support is a feature that's 2/3 there and isn't seeing improvements. It makes me miss Python's cffi.
dingdingdang
Bet you don't miss Python's massively lackluster performance when compared to PHP though! Nb. I use both for diff things (good luck instrumenting ai stuff with PHP!) but the fact that I have to reach for C extensions for python to even get a basic loop to run at reasonable speed remains peculiar/scary for me.
preinheimer
Reminds me of how Yahoo! worked back in the day. All their display logic in PHP, with the hard business logic in c extensions.
avan1
if you know more about it, i would glad to hear which extension they did developed for business logic. i used a lot of Yahoo! in back days.
forgotmypw17
I do this with Perl.
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.
phplovesong
How is php easy to setup?
forgotmypw17
Step 1: Copy the files.
Step 2: (There is no step 2.)
maurice2k
There's also RoadRunner, a more PHP like alternative to FrankenPHP:
colesantiago
I bit the bullet rewriting my app from PHP to Go and it paid off for my company, we're talking 20K lines of PHP code, reduced to 4K lines of Go and with the added efficiency gains with it.
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.
criemen
How did you reduce LoC with a move from PHP to go?
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).
yurishimo
Maybe they mean with dependencies? There are some bloated libraries out there but because PHP is a dynamic language, the bloat only matters if it’s in your hot path.
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.
coolgoose
I fail to see how you got 5x lower loc from php to go.
Php isn't perfect but it has a lot of shortcut syntaxes that go just doesn't have
NeutralForest
But the question always is: was the rewrite the reason for the gained efficiency, or the new language?
colesantiago
Both.
Go made this worth it and it also was easy to hand over to another experienced developer.
NeutralForest
Fair, what did you find in Go that you couldn't in PHP? Do you miss anything from PHP?
avan1
i don't recommend rewrite in anycase (had done 2 successful rewrite before but still i don't choose that my self) and new php run times can may be really fast. you can checkout benchmarks. swoole for instance if used with all the functionalities like its specific caches may be so fast (in some cases as fast as Go)
tayo42
Surprised you made it more compact and not have it turn into 40k lines of if err! = nil
Ive done do rewrites of stuff in python and it gets really verbose, plus dependency injection patterns for testing.
benjiro
A ton of stuff in PHP is mostly templating + DB calls for a lot of websites.
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". ;-)
sneak
When I do stuff like this, I just write the front app in the new/fast language, then reproxy the stuff not written in the fast language to the legacy app. You can even add middlewares or caching or metrics in the new app for requests going to the old one, as you can run (fast) code around both the request and the response.
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.
avan1
good idea, which language you choose for that ? also with frankenphp you can just write those required apis to be really fast as go extensions.
sneak
Go, naturally.
avan1
Perfect. we wrote our gateway in Go which handle authentication as well and then pass users data to other services (Go and php) and return their responses.
77pt77
The fact that we're still pretending PHP is a valid solution for almost anything after all these years is a joke.
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.
phendrenad2
PHP really isn't that different from Ruby or Python these days. But, I can see the perspective where none of those 3 are valid solutions given newer better options like NodeJS and Rust.
const_cast
NodeJS is, like, 10 steps back from PHP 8. Worse type system, less safe, package ecosystem is a hot mess, slower... I mean the list goes on and on.
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.
77pt77
As someone who is not a fan of npm/ts I must say I find this almost delusional.
TS is way better than PHP and node is much faster.
sneak
Yeah, I use php colab all of the time to run numpy stuff on gpus, I learned about it in my php data science class in university.
They’re basically equivalent now.
phendrenad2
You're right, there is one area where Python has an advantage over PHP, but it has nothing to do with the language, really, and more to do with tools people have built to transform the language for other purposes. So it's sort of like saying Python and Ruby are completely different because Rails exists for one and not the other.
77pt77
>I learned about it in my php data science class in university.
I rest my case...
avan1
author here. thanks for reading my post. i didn't suggest php for all type of projects. i don't choose that myself. what i just mentioned if the only reason to choose something else for responding some apis faster you still may continue in php for that.
sublinear
This sounds absolutely disgusting to maintain. Where are you going to hire devs that want to work on crap like this?
avan1
as i mentioned we just choosed frankenphp which is officially supported by php foundation. also only less than 5 percent of our code base is in Go. i don't see any problem to hire developers.
I'm starting to build a bit of antagonism to all-encompassing frameworks (e.g. Spring, Larvel, Phoenix, etc.), because while they are productive to build new things with, I seem to always have the same issue on legacy projects built with them.
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.