On Wed, Aug 14, 2024 at 2:32 PM Mike Schinkel <m...@newclarity.net> wrote:
> > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks <arvids.godj...@gmail.com> > wrote: > > > > I want to remind everyone on the thread that code does not only have to > be written, which is the "easy part", but it also has to be supported by > everyone into the future and chances that the original author sticks around > are not that high to do it. > > > > The Rust thing is shitposting for the sake of shitposting and memeing on > the theme "rust solves everything" and "lets rewrite everything into Rust". > > Here's a link with the reminder of the hard rules php-src and internals > have: https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md > > And here's the wiki page on the internals etiquette: > https://wiki.php.net/email_etiquette_for_people_new_to_php_internals > > > > PHP has C as core and has allowed C++ for extensions. Expanding that > support is a no-brainer, especially since modern C++ has stepped up in > major ways and I don't think C sees a lot of development any more, so it > makes sense to move towards C++. > > IF there is a serious consideration given to evolving PHP to be written in > another language — vs. just a newer version of C — I think any reasonable > analysis would indicate that none of the languages proposed in this thread > would be appropriate; not Rust, not C++, and not Go. Why not? > > Can you point out where either of us suggested writing PHP in another language? You might be mixing this up with the C11 thread, which has nothing to do with this. All I'm proposing is improving the current C++ support in the engine. https://github.com/php/php-src/blob/master/Zend/zend_portability.h already guarantees compatibility with c++ thanks to the BEGIN_EXTERN_C() and END_EXTERN_C() macros defined right at the top and that are used all around the engine. Notice how that macro compiles to nothing when C++ isn't being used? I'm simply proposing more of those. > 1. Rust is vastly different from C and re-writing in Rust would require > basically rewriting everything from ground up. The scope of such as project > would likely make the failed effort toward PHP6 even look quaint. > > Yes, it is possible that one or a few individuals could on-their-own > devote 1-3 years to write PHP in Rust and then present to the community and > the community could accept it as the next version of PHP. However, AFAIK > there is no one individual or team who is currently or likely to do this, > and having the community accept their work is even less likely. > > 2. C++ is vastly more complicated to program in than C, and adopting C++ > would further narrow the number of people who are both proficient enough in > both C++ and motivated enough to contribute to PHP's codebase. That would > likely be just a handful of people today and with not much prospect for > more in the future. > > 3. While I would love it if PHP were written in Go, I just do not see it > happening because it would take a mostly full rewrite like with Rust and > even as a Gopher I am not sure Go is the language I would pick to develop > PHP in if there were no existing constrains in large part because of its > inability to go low-level enough (pun intended), especially related to > memory management. > > However, there *IS* a language I think the PHP should seriously consider — > if we do seriously consider a new language at all— and that language is > Zig. > > If you are not familiar with Zig — or have simply not explored it yet — I > would highly recommend reading at least the first article if not all of > them: > > — > https://www.infoworld.com/article/2338081/meet-the-zig-programming-language.html > — https://ziglang.org/learn/why_zig_rust_d_cpp/ > — > https://erik-engheim.medium.com/is-zig-the-long-awaited-c-replacement-c8eeace1e692 > — > https://sourcegraph.com/blog/zig-programming-language-revisiting-design-approach > > For those who can't be bothered to visit any of the links but will read > the rest of an email, here are pull quotes from the first article that are > relevant to why Zig should be considered as a successor to C for PHP. I > presented these quotes in order of relevance for PHP and not in order > presented in the article: > > — "Zig sports a high degree of interoperability with C and C++. ... Zig > can compile C and C++. It also ships with libc libraries for many > platforms. It is able to build these without linking to external libc > libraries." > > — "Zig attempts not only to supercede C with its own syntax, but actually > absorb C into itself as much as possible." > > — "(Zig's developer) said “Zig is a better C/C++ compiler than other C/C++ > compilers since it supports cross-compilation out of the box, among other > things. Zig can also trivially interoperate with C (you can import C header > files directly) and it is overall better than C at using C libraries, > thanks to a stronger type system and language features like defer.” > > — "There is no malloc keyword like in C and C++. Instead, access to the > heap is handled explicitly in the standard library. When you need such a > feature, you pass in an Allocator object. This has the effect of clearly > denoting when memory is being engaged by libraries while abstracting how it > should be addressed. Instead, your client code determines what kind of > allocator is appropriate." > > — "Making memory access an obvious library characteristic is meant to > avoid hidden allocations, which is a boon to resource-limited and real-time > environments. Memory is lifted out of the language syntax, where it can > appear anywhere, and its handling is made more explicit." > > — "Zig also includes safety features for avoiding buffer overflows, and it > ships with a debug allocator that detects memory leaks." > > — "Zig also includes a build tool.... Zig’s build tool works in a > cross-platform way and replaces tools like make and cmake." > > — "Zig is being used to implement the Bun.js JavaScript runtime as an > alternative to Node.js. Bun’s creator Jarred Sumner told me “Zig is sort of > similar to writing C, but with better memory safety features in debug mode > and modern features like defer (sort of similar to Go’s) and arbitrary code > can be executed at compile time via comptime. It has very few keywords so > it’s a lot easier to learn than C++ or Rust.” > > — "Kevin Lynagh, coming from a Rust background, wrote, “The language is so > small and consistent that after a few hours of study I was able to load > enough of it into my head to just do my work.” Nathan Craddock, a C > developer, echoed the sentiment. Programmers seem to really like the > focused quality of Zig’s syntax." > > ============ > > Given that Zig was designed to and can compile C and C++ code directly, > "moving to" Zig would likely be almost trivial, at least the swapping out > the C compiler for the Zig compiler part. Then the maintainers of PHP could > decide which Zig languages features to use and where. Over time PHP's > maintainers could choose to evolve the PHP codebase to using more Zig > features over time (or not), features such as `comptime` code generation > that is built into the Zig language. > > Zig's allocator memory model would also likely be a boon to PHP by giving > PHP more control about how and when to allocate memory for PHP programs. > > Using the Zig build tool could also likely make it easier for someone new > to PHP core/extension development to getting a build working on their > machine for local development. > > All of this is moot, it would be a huge investment and a whole other discussion to port PHP to another language. That has nothing to do with my proposal. > And finally, one other (IMO) HUGE benefit of switching to Zig would be > that it would likely be easier for new people to onboard to contributing to > the PHP codebase than if PHP sticks with C or especially if PHP were to > instead move to C++. I know Zig would make it easier for me to contribute. > > #jmtcw > > -Mike > > P.S. One of my goals in the mid-term is to become proficient enough to > work in C on the PHP code base so I could write an extension and/or > contribute a patch to PHP for a passed RFC. > > However, if PHP embraces C++ I will drop that goal because I know enough > about C++ to know about that I to become proficient in contributing to PHP > if it required be programming in C++ would need to become a full time C++ > developer, which is not going to happen. So if you move to C++ then I give > up. > Again, I will reiterate that these proposed changes will not affect the current course of PHP. Development will go on as usual and any bugs introduced by this proposal will be contained to C++ extensions interacting with the code. C devs can act like this doesn't even exist because as far as the C compiler is concerned, it doesn't. On the other hand C++ devs won't have to keep reinventing the wheel whenever they have to build an extension with C++. What is a php extension if not a wrapper for a C/C++ lib? > > That said, me giving up will be no skin off anyone's nose in the PHP > community. But it is very likely my giving up would just be the canary > dying in the coal mine indicating that many others will give up too, and > many more will never even try. > > IOW, if you care about being able to have enough people to maintain PHP > into the future, you should really think hard before deciding to more PHP > to C++ development. And before you say there are lots of C++ developers, > consider that most good C++ would never even consider working on PHP as > they likely do not consider it a language worthy of their time. IF I wanted PHP to be implemented in C++, I would simply fork it. How many thousand RFCs do you think it will take to get anything reasonable done? I'm baffled that I actually have to convince y'all to IMPROVE the current support for C++, but calm down, no one wants you to quit. Cheers, Lanre.
