4 ms·

> From historically just adding features whenever to know adding hundreds of breaking changes per minor release. Should be noted that it stopped being the case

by esskay 2y ago

> From historically just adding features whenever to know adding hundreds of breaking changes per minor release. Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it. PHP spent a long time running on fumes with little backing. It's now got huge financial backing from Jetbrains, Wordpress Symfony, Laravel etc and theres now people paid to work on it, which has dramaticly improved the quality and quantity of improvements, which are mostly focused around performance and bug fixes. The performance gains arent just figures on paper either. There was a real world improvement of around 12% on PHP 8.3 alone.

ChrisMarshallNY 2y ago
Doesn’t Facebook still run most of their backend on Hack[0] (compiled PHP subset)? [0] https://hacklang.org/ https://hacklang.org/
- Shish2k 2y ago
  Hack is only PHP in a very ship-of-theseus sense - it has PHP _vibes_ but they replaced the language, the runtime, the standard library, and all of the infrastructure (and all of them much improved over PHP IMO - especially XHP [equivalent to JSX, where HTML is a first-class citizen in the language syntax])
- that_guy_iain 2y ago
  I think the fact Facebook decided to just fork that language instead of improving it shows how bad the core development was. The internals newsletter was just brutal. I remember reading a thread from a Facebook dev asking who quietly just reverted his commit. No discussion, no nothing, the code was just reverted if someone didn't like it. I really think that was a major misstep by the project.
  - ChrisMarshallNY 2y ago
    > I really think that was a major misstep by the project. Oh, yeah. As someone who has written and maintained a lot of "infrastructure-level" stuff, I have come to learn that releasing a project that serves users, or is infrastructure for other projects, is like having children. Making them is fun. Releasing them, is a pain, but, once they are out there, it is my Responsibility to support them, and accept that they have their own agency. I can't just go in and pretend that I'm Lord Farquaad, and treat the project as if it's my private fiefdom. It's now a public resource, and my decisions and actions affect a lot of others. I also tend to write software that supports folks with a rather ... pithy ... demeanor, so screwups can result in not-pleasant feedback. That's a big reason why I don't mind that most of my public repos aren't popular.
that_guy_iain 2y ago
> Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it. The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines. And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 part-time. The rest were volunteers doing it as a hobby. That full-time developer who was paid by Jetbrains decided he wanted to work on another project. This resulted in the next release being pretty much nothing. At which point, everyone realised this language went from funded to not funded and they created the PHP foundation.
- esskay 2y ago
  I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language. I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
  - that_guy_iain 2y ago
    > I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language. They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar. And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change. > I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric. It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes. I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain. The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.

by esskay 2y ago

ChrisMarshallNY 2y ago

Doesn’t Facebook still run most of their backend on Hack[0] (compiled PHP subset)? [0] https://hacklang.org/ https://hacklang.org/

Shish2k 2y ago
Hack is only PHP in a very ship-of-theseus sense - it has PHP _vibes_ but they replaced the language, the runtime, the standard library, and all of the infrastructure (and all of them much improved over PHP IMO - especially XHP [equivalent to JSX, where HTML is a first-class citizen in the language syntax])
that_guy_iain 2y ago
I think the fact Facebook decided to just fork that language instead of improving it shows how bad the core development was. The internals newsletter was just brutal. I remember reading a thread from a Facebook dev asking who quietly just reverted his commit. No discussion, no nothing, the code was just reverted if someone didn't like it. I really think that was a major misstep by the project.
- ChrisMarshallNY 2y ago
  > I really think that was a major misstep by the project. Oh, yeah. As someone who has written and maintained a lot of "infrastructure-level" stuff, I have come to learn that releasing a project that serves users, or is infrastructure for other projects, is like having children. Making them is fun. Releasing them, is a pain, but, once they are out there, it is my Responsibility to support them, and accept that they have their own agency. I can't just go in and pretend that I'm Lord Farquaad, and treat the project as if it's my private fiefdom. It's now a public resource, and my decisions and actions affect a lot of others. I also tend to write software that supports folks with a rather ... pithy ... demeanor, so screwups can result in not-pleasant feedback. That's a big reason why I don't mind that most of my public repos aren't popular.

that_guy_iain 2y ago

> Should be noted that it stopped being the case close to a decade ago now. Since PHP 8 things have changed a lot and it's a significantly better platform, both in terms of usage and the people behind it. The breaking changes section of UPGRADING file for PHP 8.4 is over 200 lines. For 8.3 it was over 100 lines. And when it went to version 8, there was only 1 full-time developer working on it and as far as I know 0 part-time. The rest were volunteers doing it as a hobby. That full-time developer who was paid by Jetbrains decided he wanted to work on another project. This resulted in the next release being pretty much nothing. At which point, everyone realised this language went from funded to not funded and they created the PHP foundation.

esskay 2y ago
I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language. I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric.
- that_guy_iain 2y ago
  > I assume you're referring to what the upgrade guide refers to as "Backward Incompatible Changes". If so reading through the list I can't see a single one on there that has a major impact, in fact I'd wager that 99% of all 8.3 instances will have no issue upgrading to 8.4 as they are all very superficial changes to some very legacy areas of the language. They changed error handling. That is a major impact. If things start throwing errors when they previously didn't it results in your app breaking because how you were handling errors is no longer applicable. Now you have third-party libraries, etc all breaking because the PHP core team can't be bothered to follow industry standards. And yes, SemVar is, at this point, the industry standard to the point people use 8.* in their composer require because they expect SemVar. And changing error handling in very legacy areas of the code is the worst especially when there isn't even an RFC to say that they would be doing it. The fact it's legacy means people don't expect it to change. > I'm also not seeing 200 on there, though you said "200 lines" are you talking about the length of the article, if so thats not really a helpful metric. It's useful in giving an impression of the number of changes. Especially, when given an example of another release to see how they're increasing. And it's extremely useful when comparing to other languages where the breaking changes section either doesn't exist or it's extremely small. 200+ lines even with formatting and some lines taking two ends up with over 100 breaking changes. I get it, you like PHP and you're protective over your tooling. I use PHP heavily, in fact, I'm building my business on top of it. But that does not remove my ability to look at how everything is compared to other languages and see there is a major problem. On Ubuntu, it has packages for each minor release whereas in Python it's just python3-*. Why? Because PHP's reputation for adding breaking changes whenever (despite the claim that they're really good at it) has been there for so long that even Linux distros know that people need to deal with that pain. The problem with me being mainly a PHP developer is, I know all the problems. You can't BS me like you can devs who don't work with it so much.