On Tue, 11 Apr 2023 at 12:24, Sara Golemon <p...@golemon.com> wrote: > > I'm saying that the DX for writing extensions is better in other > languages. > > Citation needed. Java's extension API is certainly a hot mess. Python's > is fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice > at first blush, but given that it's closer to an FFI than a proper > extension API, shortfalls inevitably show up when you try to do anything > complex. >
Python's the one I had in mind. Also Node. I've read but not written node extensions and found them very readable. Even when using Native Abstractions for Node.js (nan) which adds a macro layer. With compiled languages I'd think of Nim, Crystal and Swift but have no practical experience with any of them, only having read the source of a few extensions and run through the tutorials to write them. > > And that these days new products come along and provide extensions for > > other languages but not PHP. Which is a problem I can only work around by > > writing an extension. > > Okay. Why is this a problem? This is what's right about OSS. That you > can take two things and smush 'em together because you need something from > both. > I see this as a problem for PHP users and for PHP adoption. Lack of PHP support from vendors is a strategic problem for future ecosystem health. There will be multiple reasons¹ vendors will choose to support other languages and not PHP, but one certainty is it means funded startups are not putting their cash towards PHP. For users of PHP, when we look at using a 3rd party service, I would imagine most of us don't price in the cost of building, maintaining and supporting our own extension. The outcome would be to not use the service - or to change language to one where there isn't this friction. Needing to write an extension to be able to build your app on top makes the platform behind before the race is even started. ¹ I am interested to find out what their reasons are. Why don't companies choose to make PHP extensions? Is it that PHP is inconsequential to them, the perception that PHP users are too small an audience, difficulty of creating the extension, or other reasons? They aren't going to answer me as a random person, but if the PHP Foundation want some market research done then this is your opportunity. > > PHP now has FFI which provides an easier way to extend PHP. I have huge > > hopes for it - but in my experience it doesn't feel finished. > > I agree, it's not finished. But the problem there is also the > opportunity. OSS works best when people who have an actual need are the > ones designing the interfaces and making things better. > > I don't pay attention to FFI because I can write PHP extensions on a my > mobile, while sitting on an island beach and playing board games (true > story). I know that's not universally true, but it's why I'm not putting > the effort in, because I'll end up building the wrong solution by not truly > understanding the requirements (also a true story, take a look at streams > sometime). > > If it feels like FFI is stalled, it's probably because it's "good enough" > for the people who got it to this point. The itch is scratched and the > need is met. > > So when I call the state of FFI an opportunity, I'm not saying "code or > gtfo" as such is sometime vilified. I'm saying this is an open source > project of the purest kind and it really is up to someone to care about a > thing enough to put in the work to make it better. > > And if your reply is, "But I don't know C", then good news! That's another > opportunity. PHP is a nice language, but it's not the only one out there. > C is a mother language, the payoff on learning just keeps coming around. > >From the times I have tried (the last one on this list being around PDO and driver-specific functions) C is not an insurmountable problem, but understanding the PHP/Zend macros was, even after going through the PHP Internals book. It looks like the book has been updated since last time though, which will help. More recently I have been playing with a DuckDB library using FFI and then working through the code at https://github.com/kambo-1st/ipc-duckdb-ffi-extension-workshop / presentation https://docs.google.com/presentation/d/1_hGrKsJey9YvFMGrKk34p_hRmfPU4swiaUhCpVygVjo/edit. That might be manageable to complete. I won't be stepping up to work on FFI because IMO that requires more experience than I can bring - in extension writing, and particularly in using FFI and knowing its strengths and pitfalls inside-out. For keeping track of what I and others find while using FFI, is this mailing list or a GitHub issue the best place to record it? Peter
