> 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? 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. 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. 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.
