PHP-Tokio – Use any async Rust library from PHP
github.com
github.com
It sounds like the actual async features come from Revolt so I’m not 100% sure where Rust fits in. Because the rust lib used is async as well, they’re compatible?
php-tokio's integrates the https://revolt.run event loop with the https://tokio.rs event loop; async functionality is provided by the two event loops, in combination with PHP fibers through revolt's suspension API (I could've directly used the PHP Fiber API to provide coroutine suspension, but it was a tad easier with revolt's suspension API (https://revolt.run/fibers), since it also handles the base case of suspension in the main fiber).
Yes, I'm planning to support my fork of ext-php-rs, given that it will be heavily used by our mongodb driver.
I've actually sent an email to David Cole, asking him to make a maintainer of the original repo, but he hasn't replied yet, feel free to send your MRs to our fork in the meantime!
php-tokio plugs into revolt, which in turn allows it to coexist with any async library based on or compatible with revolt (i.e. the entire amp ecosystem, PSL, reactphp, etc...).
Can we just agree on "PHP used to suck but it was very easy to work with, reason why it got traction. Things got better over the years and those that only saw the early years, rightfully only remember how much it sucked, while those that use modern versions see how much it has changed"?
This comment is super interesting to me, not because it contains anything I haven't heard before, but because the phrasing managed to break through my "bubble" of being the type of PHP naysayer you're talking about by making me realize just how similar this trend is to some other tech products that I'm not nearly as down on (I use btrfs on my personal machines, and I worked for several years at MongoDB, both of which seem to suffer from similar views of "fool me once and I'll refuse to ever give you another chance, no matter how much changes"). I still probably won't end up using PHP myself, given that I don't really do much web development anymore, but you've at least gotten one person to reconsider their opinion on PHP, so thank you for that!
BTRFS had bugs that could be fixed, so when they're fixed you can use it. While with mongo, it's still fundamentally a schemaless datastore. If you have a fundamental problem with that, then there's no bugs that can be fixed to make it ok.
I think in these cases you need to separate out the core criticism over simply temporary issues.
Lot's of people people who hate on PHP's "design" (not the code bases created from it), didn't understand what was going on. PHP allows taking any C program and writing a wrapper around it, and they would often just use the C program's API, which would then become part of the PHP API for that extension .
There was amazing inconsistency there, yes, when looking through a formal lens. But it was not "designed" so much as "grown" - it was an organic thing made for delivering. It was quickly able to have huge amounts of functionality added that didn't happen as fast with ASP or Cold Fusion, and I didn't find it nearly as gnarly as Perl.
I was rather partial to Classic ASP with JScript myself... Although the biggest issue in that whole space was a lot of the addons were commercial and expensive COM libraries. VB6 added a lot of value and made it more useful. It was a much different time in the mid-late 90's though.
These days, I'm still more inclined to fave JS environments such as Deno or node, that have vast and rich options for everything. Though the language itself still has a lot of detractors, even for TS. I've also been enjoying the bit I've played with Rust.
Which is a great and smart way to improve PHP for the people who still have to work in PHP. But none of it is original to PHP, or provides a compelling reason to use PHP instead of the options where all these things originally were copied from.
Or would it be OK to recognize that most ecosystems adapt good ideas from each other?
And yeah, many different ecosystems adopt ideas from one another. And it's often a good thing, though it can be hard for people with a lot of experience in something to see new syntax/ideas sometimes. It's also sometimes hard for people to invert/twist their thinking in different ways. I see this a lot when OO devs try to work with FP concepts. Another example is getting used to Rust's pattern matching and enum values.
I/O is almost always the blocker.
To only competitor I see is Rails. No other framework has such a rich and powerful ecosystem for web development.
Language features and non-web usage: basically everything
Handling concurrency/streaming: Phoenix
Simplicity while providing batteries: Flask
Backend/front-end integration: Blazor
I’ll definitely give you non-web usage and most of language features (even though PHP nowadays has first class type support, which can’t be said of Rails, unfortunately). And yes, concurrency is all but absent.
Apart from RoR, I haven’t used much else in the full stack framework space, so I’d love to hear!
Instead of Inertia, we have Livewire now Filament for amazingly quick and super powerful admin panels (like Avo for Rails)
Not including everything else available for auth, payments, basically any non unique SaaS feature has a good package available.
There is definitely concurrency with Swole (and implemented in Laravel with Optane, giving a 2x speed boost by default.)
This is just an example, not a strict advocation... I've been more fond of batteries not included options myself, and in particular been admiring rust options a lot.
EDIT: Also forgot to mention, PHP is great for cheap hosting, and still provides one of the simplest ways of building a server-side webapp (everything can live in an index.php file) so that is another benefit if you're looking for that.
The go ecosystem is a ways behind and whatever you compile in Node today will break tomorrow.
What would I gain by switching?
I think everything I wrote a decade ago in node still runs fine.
For the most part, I haven't had too much trouble the past couple years taking an existing project and running on a newer runtime. I have seen a lot of incompatible library breaks trying to update dependencies though.
Ironically, I think the worst libraries for breaking changes are actually the testing libraries themselves. Having to jump 2-3 major versions to update to latest is an exercise in extreme frustration.
I appreciate a lot of what Deno is doing in their direction, though I've felt a few breaking changes along the way there too.
My experience with PHP/Laravel has been that Laravel is an awesome framework on what is nowadays a ‘decent enough’ language.
For comparison, at least PHP has first party type support nowadays, whereas Rails does not.
PHP of the past didn't “suck”, but people who grew PHP in it current state, because they wanted a “professional” language definitely made it suck.
RIP PHP.
The documentation was easy to navigate as well. This is often an overlooked aspect of it.
It was comparable to ASP which was also popular at the time.
Come on now, it is Linux, Apache, MySQL, and PHP === LAMP...
it was more than just easy of getting a server going, it over all ease of development, PHP was MUCH easier to work with as a developer than ASP or Perl, or any of the other early web lang's
At the time some saw it as an advantage, today everyone agrees that it does not scale
+1
I fall into the latter and will always defend it. PHP had a very similar development arc to JS.
I mean, probably the sensible choice - backwards compatibility is very important. But it does mean that a lot of the things that made PHP awful still make it awful.
You can usually recognize it because people refuse to explain why something is "good" or "better now", instead just blanket-asserting that it is.
It introduced such drastic breaking changes, that probably a lot of systems which were previously perfectly serving their users will be abandoned. Projects that could have stayed on the internet and served their users just fine.
It broke the order of parameters in join statements.
It broke calling static functions without the need to declare them as static.
It broke adding properties dynamicly to objects.
It broke easy string handling for many functions where Null was rendered as an empty string.
And these changes make PHP code more bloated. There is now no way around adding more declarations to your codebase than before.
Some of these breakages had 30% votes against them, including the original author of PHP:
https://wiki.php.net/rfc/deprecate_dynamic_properties
The bar for breaking changes should be much higher.
Python's update from version 2 to version 3 caused a lot of pain. But at least it made the code leaner. Allowing users to go from "a=float(b)/c" to "a=b/c" is a good thing. Forcing users to go from "function f()" to "static function f()" is a bad thing.
Upgrading a codebase to PHP 8 is not an insurmountable task, I've upgraded our 1 million SLOC codebase at work in just a few weeks, with the help of tools like https://psalm.dev and our own strict coding standard.
Rector, which can automate these changes.
Rector is a very nice project, but I still haven't gotten around to integrating it into our codebase at work, because it uses phpstan instead of Psalm, and apart from being slower than Psalm, phpstan kept having various issues and crashes while scanning our codebase, unlike Psalm which mostly worked out of the box (I even became maintainer of Psalm, due to the large amount of additional performance improvements I added due to our needs @ work).
At work, we're currently using Psalm with a few extensions that make some autofixes as needed, a bit like Rector.
It introduced such drastic breaking changes, that probably a lot of systems which were previously serving unsafe and error-prone code to their users will be abandoned. Projects that should have been updated ages ago and served their users dangerous code.
It fixed the order of parameters in join statements.
It fixed calling static functions without declaring them as static.
It fixed adding properties dynamicly to objects.
It fixed string handling for many functions where Null was rendered as an empty string.
And these changes make PHP code more secure. There is now no way around adding more declarations to your codebase than before.
Most of these breakages had 70% votes in favour:
PHP5 code is horrible in almost any metric and I'm astonished that websites running old PHP code are so seldom hacked.
PHP expects programmers not to do stupid things... I guess that is too much to ask in the modern era where "programmers" do not want to have to actually program anything, they instead want make a function statement, then have AI fill in the rest for them, or use a Low Code or "RAD" framework to abstract away all the actual programming so they can do the "fun design stuff" ...
In my case, I used a combination of Rector, integration tests, and sending exceptions to Sentry to successfully upgrade a PHP code base from version 7 to 8.
I don't think it broke any of that, I think it fixed all of that.
And PHP 5,7 will continue to work just fine for a while. There still supported backports and images of PHP 5 to this day on any major operating system.
HN when modern PHP is involved: PHP8 was a bad idea! They shouldn't have gotten rid of the legacy stuff!
All of those decisions were made for specific reasons. I’ve noticed anyone complaining about PHP 8 for legacy reasons was barely off of PHP 5.
The last release of PHP 5 was less than 5 years ago.
Javascript from 20 years ago still works fine. That's the way it should be.
PHP is not like that, like in every other language where you can control the entire environment, it evolves and things break, and that's the way it should be, that's why we have semantic versioning.