Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124934
Precedence: bulk
MIME-Version: 1.0
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> <CB46B039-CF15-484F-95B3-D22070126D8F@newclarity.net>
In-Reply-To: <CB46B039-CF15-484F-95B3-D22070126D8F@newclarity.net>
Date: Wed, 14 Aug 2024 15:27:32 -0600
Message-ID: <CAM7F2-_AJfRhuJ0rzA8sRQJkoSnQ=5zitOLcgJsze_ybk68=PA@mail.gmail.com>
Subject: Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API
To: Mike Schinkel <mike@newclarity.net>
Cc: PHP internals <internals@lists.php.net>, Pascal Chevrel <pascalc@gmail.com>, 
	John Coggeshall <john@coggeshall.org>, Levi Morrison <levi.morrison@datadoghq.com>, 
	Arvids Godjuks <arvids.godjuks@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000074bddd061fab65f8"
From: lnearwaju@gmail.com (Lanre)

--00000000000074bddd061fab65f8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 14, 2024 at 2:32=E2=80=AFPM Mike Schinkel <mike@newclarity.net>=
 wrote:

> > On Aug 14, 2024, at 3:05 PM, Arvids Godjuks <arvids.godjuks@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 arou=
nd
> are not that high to do it.
> >
> > The Rust thing is shitposting for the sake of shitposting and memeing o=
n
> 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.m=
d
> > 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 i=
n
> another language =E2=80=94 vs. just a newer version of C =E2=80=94 I thin=
k any reasonable
> analysis would indicate that none of the languages proposed in this threa=
d
> 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 proje=
ct
> 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 a=
nd
> 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 =
=E2=80=94
> if we do seriously consider a new language at all=E2=80=94 and that langu=
age is
> Zig.
>
> 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-langua=
ge.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-c8e=
eace1e692
> =E2=80=94
> https://sourcegraph.com/blog/zig-programming-language-revisiting-design-a=
pproach
>
> 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 ar=
e
> 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."
>
> =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 head=
er
> 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 mean=
t to
> avoid hidden allocations, which is a boon to resource-limited and real-ti=
me
> environments. Memory is lifted out of the language syntax, where it can
> appear anywhere, and its handling is made more explicit."
>
> =E2=80=94 "Zig also includes safety features for avoiding buffer overflow=
s, 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 wo=
rks 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 a=
s 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 mod=
e
> and modern features like defer (sort of similar to Go=E2=80=99s) and arbi=
trary 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=9CT=
he 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 cou=
ld
> 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 PH=
P
> 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 gi=
ve
> 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.

--00000000000074bddd061fab65f8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 14, 2024 at 2:32=E2=80=AF=
PM Mike Schinkel &lt;<a href=3D"mailto:mike@newclarity.net" target=3D"_blan=
k">mike@newclarity.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">&gt; On Aug 14, 2024, at 3:05 PM, Arvids Godjuks &lt;=
<a href=3D"mailto:arvids.godjuks@gmail.com" target=3D"_blank">arvids.godjuk=
s@gmail.com</a>&gt; wrote:<br>
&gt; <br>
&gt; I want to remind everyone on the thread that code does not only have t=
o be written, which is the &quot;easy part&quot;, but it also has to be sup=
ported by everyone into the future and chances that the original author sti=
cks around are not that high to do it.<br>
&gt; <br>
&gt; The Rust thing is shitposting for the sake of shitposting and memeing =
on the theme &quot;rust solves everything&quot; and &quot;lets rewrite ever=
ything into Rust&quot;.<br>
&gt; Here&#39;s a link with the reminder of the hard rules php-src and inte=
rnals have: <a href=3D"https://github.com/php/php-src/blob/master/docs/mail=
inglist-rules.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/p=
hp/php-src/blob/master/docs/mailinglist-rules.md</a> <br>
&gt; And here&#39;s the wiki page on the internals etiquette: <a href=3D"ht=
tps://wiki.php.net/email_etiquette_for_people_new_to_php_internals" rel=3D"=
noreferrer" target=3D"_blank">https://wiki.php.net/email_etiquette_for_peop=
le_new_to_php_internals</a><br>
&gt; <br>
&gt; PHP has C as core and has allowed C++ for extensions. Expanding that s=
upport is a no-brainer, especially since modern C++ has stepped up in major=
 ways and I don&#39;t think C sees a lot of development any more, so it mak=
es sense to move towards C++.<br>
<br>
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.=C2=A0 W=
hy not?<br>
<br></blockquote><div>Can you point out where either of us suggested writin=
g PHP in another language? You might be mixing this up with the C11 thread,=
 which has nothing to do with this.=C2=A0 All I&#39;m proposing is improvin=
g the current C++ support in the engine.=C2=A0<a href=3D"https://github.com=
/php/php-src/blob/master/Zend/zend_portability.h" target=3D"_blank">https:/=
/github.com/php/php-src/blob/master/Zend/zend_portability.h</a> already gua=
rantees compatibility with c++ thanks to the=C2=A0BEGIN_EXTERN_C() and=C2=
=A0END_EXTERN_C() macros defined right at the top and that are used all aro=
und the engine. Notice how that macro compiles to nothing when C++ isn&#39;=
t being used? I&#39;m simply proposing more of those.</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">
1. Rust is vastly different from C and re-writing in Rust would require bas=
ically rewriting everything from ground up. The scope of such as project wo=
uld likely make the failed effort toward PHP6 even look quaint. <br>
<br>
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 c=
ommunity could accept it as the next version of PHP. However, AFAIK there i=
s no one individual or team who is currently or likely to do this, and havi=
ng the community accept their work is even less likely. <br>
<br>
2. C++ is vastly more complicated to program in than C, and adopting C++ wo=
uld further narrow the number of people who are both proficient enough in b=
oth C++ and motivated enough to contribute to PHP&#39;s codebase. That woul=
d likely be just a handful of people today and with not much prospect for m=
ore in the future.<br>
<br>
3. While I would love it if PHP were written in Go, I just do not see it ha=
ppening 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 i=
n if there were no existing constrains in large part because of its inabili=
ty to go low-level enough (pun intended), especially related to memory mana=
gement.<br>
<br>
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 th=
at language is Zig. <br>
<br>
If you are not familiar with Zig =E2=80=94 or have simply not explored it y=
et =E2=80=94 I would highly recommend reading at least the first article if=
 not all of them:<br>
<br>
=E2=80=94 <a href=3D"https://www.infoworld.com/article/2338081/meet-the-zig=
-programming-language.html" rel=3D"noreferrer" target=3D"_blank">https://ww=
w.infoworld.com/article/2338081/meet-the-zig-programming-language.html</a><=
br>
=E2=80=94 <a href=3D"https://ziglang.org/learn/why_zig_rust_d_cpp/" rel=3D"=
noreferrer" target=3D"_blank">https://ziglang.org/learn/why_zig_rust_d_cpp/=
</a><br>
=E2=80=94 <a href=3D"https://erik-engheim.medium.com/is-zig-the-long-awaite=
d-c-replacement-c8eeace1e692" rel=3D"noreferrer" target=3D"_blank">https://=
erik-engheim.medium.com/is-zig-the-long-awaited-c-replacement-c8eeace1e692<=
/a><br>
=E2=80=94 <a href=3D"https://sourcegraph.com/blog/zig-programming-language-=
revisiting-design-approach" rel=3D"noreferrer" target=3D"_blank">https://so=
urcegraph.com/blog/zig-programming-language-revisiting-design-approach</a><=
br>
<br>
For those who can&#39;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 pr=
esented these quotes in order of relevance for PHP and not in order present=
ed in the article:<br>
<br>
=E2=80=94 &quot;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 libr=
aries.&quot;<br>
<br>
=E2=80=94 &quot;Zig attempts not only to supercede C with its own syntax, b=
ut actually absorb C into itself as much as possible.&quot; <br>
<br>
=E2=80=94 &quot;(Zig&#39;s developer) said =E2=80=9CZig is a better C/C++ c=
ompiler 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<br>
<br>
=E2=80=94 &quot;There is no malloc keyword like in C and C++. Instead, acce=
ss 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 cl=
early 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.&quot;<br>
<br>
=E2=80=94 &quot;Making memory access an obvious library characteristic is m=
eant to avoid hidden allocations, which is a boon to resource-limited and r=
eal-time environments. Memory is lifted out of the language syntax, where i=
t can appear anywhere, and its handling is made more explicit.&quot;=C2=A0 =
<br>
<br>
=E2=80=94 &quot;Zig also includes safety features for avoiding buffer overf=
lows, and it ships with a debug allocator that detects memory leaks.&quot;<=
br>
<br>
=E2=80=94 &quot;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.&quot=
;<br>
<br>
=E2=80=94 &quot;Zig is being used to implement the Bun.js JavaScript runtim=
e 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 safet=
y 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 compt=
ime. It has very few keywords so it=E2=80=99s a lot easier to learn than C+=
+ or Rust.=E2=80=9D<br>
<br>
=E2=80=94 &quot;Kevin Lynagh, coming from a Rust background, wrote, =E2=80=
=9CThe 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 N=
athan Craddock, a C developer, echoed the sentiment. Programmers seem to re=
ally like the focused quality of Zig=E2=80=99s syntax.&quot;<br>
<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
Given that Zig was designed to and can compile C and C++ code directly, &qu=
ot;moving to&quot; Zig would likely be almost trivial, at least the swappin=
g 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&=
#39;s maintainers could choose to evolve the PHP codebase to using more Zig=
 features over time (or not), features such as `comptime` code generation t=
hat is built into the Zig language.<br>
<br>
Zig&#39;s allocator memory model would also likely be a boon to PHP by givi=
ng PHP more control about how and when to allocate memory for PHP programs.=
<br>
<br>
Using the Zig build tool could also likely make it easier for someone new t=
o PHP core/extension development to getting a build working on their machin=
e for local development.<br>
<br></blockquote><div>All of this is moot, it would be a huge investment an=
d a whole other discussion to port PHP to another language. That has nothin=
g to do with my proposal.</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
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 instea=
d move to C++. I know Zig would make it easier for me to contribute.<br>
<br>
#jmtcw<br>
<br>
-Mike<br>
<br>
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.<br>
<br>
However, if PHP embraces C++ I will drop that goal because I know enough ab=
out 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++ dev=
eloper, which is not going to happen.=C2=A0 So if you move to C++ then I gi=
ve up.<br></blockquote><div>Again, I will reiterate that these proposed cha=
nges will not affect the current course of PHP. Development will go on as u=
sual and any bugs introduced by this proposal will be contained to C++ exte=
nsions interacting with the code. C devs can act like this doesn&#39;t even=
 exist because as far as the C compiler is concerned, it doesn&#39;t. On th=
e other hand C++ devs won&#39;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?</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
<br>
That said, me giving up will be no skin off anyone&#39;s nose in the PHP co=
mmunity. 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 mor=
e will never even try. <br>
<br>
IOW, if you care about being able to have enough people to maintain PHP int=
o 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, consid=
er that most good C++ would never even consider working on PHP as they like=
ly do not consider it a language worthy of their time.</blockquote><div>IF =
I wanted PHP to be implemented in C++, I would simply fork it. How many tho=
usand RFCs do you think it will take to get anything reasonable done? I&#39=
;m baffled that I actually have to convince y&#39;all to IMPROVE the curren=
t support for C++, but calm down, no one wants you to quit.</div><div><br><=
/div><div>Cheers,</div><div>Lanre.</div></div></div>

--00000000000074bddd061fab65f8--