Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124933
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
In-Reply-To: <CAL0xaBFwMfAmGQ1xdxVVpJ8hXjFOzZU6ZBE4kF=0OoXZ-LAk-w@mail.gmail.com>
Date: Wed, 14 Aug 2024 16:32:31 -0400
Cc: Lanre <lnearwaju@gmail.com>,
 Pascal Chevrel <pascalc@gmail.com>,
 John Coggeshall <john@coggeshall.org>,
 Levi Morrison <levi.morrison@datadoghq.com>,
 Arvids Godjuks <arvids.godjuks@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <CB46B039-CF15-484F-95B3-D22070126D8F@newclarity.net>
References: <CAM7F2-_i58wfkdspFRGcsDLBp8eDB2aby5ENym3KpWAf+Tq6bw@mail.gmail.com>
 <89C901BF-DCEA-498E-93B0-750C49E6275B@getmailspring.com>
 <CAM7F2-895zXfqyDLt9C0_WYTkAAP9Q4wG86Xz6pn8xHNE2wfFw@mail.gmail.com>
 <0BB4DB2D-62E1-40F9-91F3-7D48367D2CBE@edison.tech>
 <CAM7F2--N28KTb3fqL=qOppMEqxiM+6Mo9d=ztQBUVfYqcWUnXA@mail.gmail.com>
 <9fb2c610-eed9-4773-8158-adef581d6a5b@free.fr>
 <CAM7F2-_HBv8SFrE3+Pb7afyqLXvBr2-paVrdCkpgmFi3ubn2Ww@mail.gmail.com>
 <CAL0xaBFwMfAmGQ1xdxVVpJ8hXjFOzZU6ZBE4kF=0OoXZ-LAk-w@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 14, 2024, at 3:05 PM, Arvids Godjuks <arvids.godjuks@gmail.com> =
wrote:
>=20
> 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.
>=20
> 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=20
> And here's the wiki page on the internals etiquette: =
https://wiki.php.net/email_etiquette_for_people_new_to_php_internals
>=20
> 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 =E2=80=94 vs. just a newer version of C =E2=80=94 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.=20

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.=20=


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 =
=E2=80=94 if we do seriously consider a new language at all=E2=80=94 and =
that language is Zig.=20

If you are not familiar with Zig =E2=80=94 or have simply not explored =
it yet =E2=80=94 I would highly recommend reading at least the first =
article if not all of them:

=E2=80=94 =
https://www.infoworld.com/article/2338081/meet-the-zig-programming-languag=
e.html
=E2=80=94 https://ziglang.org/learn/why_zig_rust_d_cpp/
=E2=80=94 =
https://erik-engheim.medium.com/is-zig-the-long-awaited-c-replacement-c8ee=
ace1e692
=E2=80=94 =
https://sourcegraph.com/blog/zig-programming-language-revisiting-design-ap=
proach

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:

=E2=80=94 "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."

=E2=80=94 "Zig attempts not only to supercede C with its own syntax, but =
actually absorb C into itself as much as possible."=20

=E2=80=94 "(Zig's developer) said =E2=80=9CZig 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.=E2=80=9D

=E2=80=94 "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."

=E2=80=94 "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." =20=


=E2=80=94 "Zig also includes safety features for avoiding buffer =
overflows, and it ships with a debug allocator that detects memory =
leaks."

=E2=80=94 "Zig also includes a build tool.... Zig=E2=80=99s build tool =
works in a cross-platform way and replaces tools like make and cmake."

=E2=80=94 "Zig is being used to implement the Bun.js JavaScript runtime =
as an alternative to Node.js. Bun=E2=80=99s creator Jarred Sumner told =
me =E2=80=9CZig 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=E2=80=99s) and arbitrary code can be executed at compile =
time via comptime. It has very few keywords so it=E2=80=99s a lot easier =
to learn than C++ or Rust.=E2=80=9D

=E2=80=94 "Kevin Lynagh, coming from a Rust background, wrote, =E2=80=9CTh=
e 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.=E2=80=9D =
Nathan Craddock, a C developer, echoed the sentiment. Programmers seem =
to really like the focused quality of Zig=E2=80=99s syntax."

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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.=20

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.=