On 23/03/2020 19:55, Mike Schinkel wrote:
As long as that's true, there will be hosts who disable features you wish
they wouldn't.
Generally that is not the issue with WordPress.
Most managed WordPress hosts support the required ones...
I wasn't saying they disable features you *need*, I said they disable
features you *might want*. This is the part of my e-mail where I thought
I was agreeing with you - having features optional means not everyone
gets them (pretty much by definition).
It sounds like there's a kind of evolved symbiosis in this case - a wide
range of hosts support the optional features WordPress requires, and
WordPress requires as few as possible because it aims to run on a wide
range of hosts. I'm not sure ease of installation particularly factors
into that, it's more about supply and demand.
Regarding choice of language for that mechanism, I'm not sure we need to
look any further than PHP itself: what we're really talking about is making
facilities available to the average user that are currently only available
to extension developers.
If that is the case then we probably need to add more improvements to the PHP
language than have been added in the past 10 years because there is so much you
can't reasonably do in PHP. One example would be to adopt the gradual typing
of Hack to allow for significant performance improvement.
I don't think that's the case for the kind of workload you're talking
about elsewhere in this thread - that is, I don't think rewriting any
part of WordPress in Rust would make much difference to people running
sites on Pantheon.
For specialist workloads, there may well be advantages to binding PHP
with optimized native code; but those are likely to be running in
self-managed environments, where traditional extensions, and now FFI,
would be available anyway.
When I talked about "making facilities available", I was thinking more
about things that userland PHP simply can't do - special types of
objects, manipulation of other parts of the language, hooks into the engine.
It is notable you mention Zephir but make no mention to WASM, which is what I
pointed to as the most promising extension mechanism I currently see on the
horizon.
...
But why no reference to WASM? WASM would let us write extensions in many
languages. Even better, we could write a PHP-to-WASM compiler for a
WASM-specific dialect of PHP.
To be honest, the reason I didn't talk about WASM is because I don't
really understand how it fits into the conversation.
My understanding is that WASM is a cross-platform target for code
written in other languages, filling roughly the same role as JVM, .Net
CLR, etc, but the underlying "OS" is web browsers. PHP's equivalent, at
least in theory, is the Zend Engine.
Running PHP code in the same runtime as other languages could be cool -
that could mean compiling PHP to WASM, or to MoarVM (the current
Raku/Perl6 target); or it could mean stabilising Zend OpCodes so we can
compile JS to them. But I don't think that's what you were talking about.
Could you clarify what kind of thing you think would benefit from having
a WASM layer?
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
