On Wed, Aug 14, 2024 at 4:30 AM Pascal Chevrel <pasc...@gmail.com> wrote:
> Le 14/08/2024 à 05:03, Lanre a écrit : > > > > Mozilla introduced Rust years ago, yet Firefox remains primarily C++, > > with only about 3% of the codebase in Rust. > > Hi, > > 10.3% now https://openhub.net/p/firefox/analyses/latest/languages_summary > > Firefox is 31 million lines of code, that means 3.4 million lines of > code written in Rust. > > Rewriting everything in Rust has never been a goal but Rust is usually > favored over C++ for new projects or rewrites. I don't think you can > take Mozilla as an example (pro or con) in the context of PHP as the > contexts and constraints are way different. > > Regards > > Pascal > > So how is Rust relevant to this conversation? PHP is implemented in C AND C++ already, except it has shitty C++ support. I bring that up and propose improving it and what am i met with? Stupid questions about rust with stupid reasons for not wanting this in core. I mean look at this shit: - If it's so easy and transparent to improve support for C++, it could easily exist outside of core as a set of header files to make the lift lighter for someone looking to use it. Sounds like that project already exists (no idea, didn't look into it). - Even if it's "easy" with a few header files, it's still adding a whole new thing required to maintain the project because now someone has to own and maintain a C++ API and every change to the "real" C engine needs a corresponding C++ API update. Who here long-term is going to own that engine-level API and make sure it's "the C++ way"...you? The way you're behaving I wouldn't trust you to not rage-quit today... so who then? What happens if there is a conflict between "the C way" and "the C++ way" in regards to a new engine-level API down the road? What kind of extra thought / energy / consideration do we need to put into engine-level API changes in the future because now we have to maintain two distinct engine APIs? - If it's not so easy and transparent (e.g. requiring us to start modifying the engine because C++ isn't happy), I'm opposed to the idea because conceptually I'd like to see any such effort spent on improving support for a future-looking language. I honestly don't care what that is, but considering Linux's recent embracing of Rust I think that's got some merit to consider. For the record, I don't personally even code in Rust so attacking me like I've got a horse in that race is pretty ridiculous. - I don't believe that just because something is prevalent means it's good. Entire governments are starting to recommend not using C/C++ because of the security risks posed by its non-existent memory safety. If PHP was being written today, it wouldn't have been written in C. Clearly this guy has no clue what he's talking about, yet I'm supposed to convince people like him? His suggestions range from "leave it to a third party lib" to "i don't trust you to not rage-quit". I'm not asking for anything extreme—just to improve the API. Yet, I'm being told that C++ is obsolete because of Rust. That's why I mentioned that Firefox is still primarily written in C++, even though they've introduced Rust. I'm not expecting a full Rust rewrite from them (which would be both unwise and wasteful); I just want to highlight how unreasonable it is to suggest that improving C++ support in the engine is pointless. Cheers, Lanre.
