[goodrubyist]

Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation? And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy.

[ThalesX]

> Were those startups that went out of business did so because of their stacks/architecture, or are you confusing correlation with causation?

As far as I am aware, and I can tell, it wasn't because of the stacks / architecture, but lack of product market fit. The fact that the response to lack of PMF was to double down on product features and tech (instead of a business pivot), in my opinion, was what made the investor money go poof and the startup die down. I've seen this happen' in too many places (as an employee or consultant) to be a coincidence.

> And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy.

Different stacks for different use cases. If I can't get money with a shitty PHP product offering, it's probably best to figure out why instead of attributing it to my tech stack.

[wpietri]

I have totally seen that too. For me one of the biggest dangers in any tech project, startups especially is caring about outputs more than outcomes. "Look at all the things we're building! Look at how hard we're working!" But those outputs don't matter if they aren't creating more value for the customer.

[Tabular-Iceberg]

> And, there is a good reason people shy away from PHP

I agree, I also strongly dislike Angular and MySQL in addition to PHP. But I also think a much better indicator for success is discipline. Angular, PHP and MySQL, to their credit, aren’t crazy Turing tarpits, you can write good, successful software with them.

I’ve never seen a dysfunctional project where any of the inherent flaws of those technologies even registered on the same scale as the sheer malpractice of everyone working on the product. And this is also the problem with trendy and flashy stacks, developers not learning the stacks properly and using them as intended. Probably due to commercial pressure to push prototypes to production instead of rebuilding properly after learning the stack. I think that should be the takeaway from the original comment, that CTOs need to either budget for building it twice, or stick to a stack everyone knows inside and out.

[JackMorgan]

It's called survivorship bias (1).

The only people pointing to PHP as the right choice that kept them from ruin are those that used it successfully. Therefore, they were building something that fit well with PHP's benefits and didn't expose too many of it's weaknesses. But no one knows for sure exactly what about that project made it a good candidate for a PHP monolith, because we don't really have any science around software engineering, just hearsay and fashion.

Having rescued several 10+ person year PHP projects from ruin, none of them were on the edge because of the language itself. However, the people building those systems made an incredible mess in a short time. I think each language attracts a certain type of developer and comes with it's own community baggage. The PHP community has some highly questionable best practices. But this is true of all programming language specific communities. They tend to be insular and have a lot of "winning the last war" advice for working around the shortcomings of the language's previous major version that have been fixed in the current major version.

(1) https://en.wikipedia.org/wiki/Survivorship_bias

[ThalesX]

> Having rescued several 10+ person year PHP projects from ruin

How did you rescue them? What are your views on Laravel?

[JackMorgan]

The teams were generally adding more bugs per release then they were fixing. Many bugs were caused by duplicated code: "I fixed the bug, but only in 1/18th of the places it manifests."

The projects were using Zend framework 2. We didn't change really anything about the text stack at all.

The solutions were generally three pronged. This isn't to bash anyone, but every failing project I've seen is a skill, talent, or discipline issue, not a technical one. So recusing projects tends to be about training, mentorship, and guidance. Sure, you fix things along the way, but that's more to prove to the devs that you know what you're talking about, so they start to fix things themselves.

First, start a root cause analysis on bugs before fixing them. This often meant that instead of another if statement in the UI because of bad state, there was a larger fix needed to prevent the bad state entirely. These bigger changes were scary, but they quickly turned these projects from spending all their time in emergencies into only a few hours a week.

Second tool was to deduplicate and unit test code as much as possible. No more copy-pasting whole files every time there was a slightly different use-case required.

Third, to stop treating the database like a PHP ORM connection and start treating it like a distinct tool. Things like turning serialized PHP arrays from a single column into separate tables allowed us to start using SQL to query data instead of pulling all records into memory to filter and sort. This rapidly improved performance, which meant fewer support issues.

All boring, bog standard stuff. One project we started a second service in .NET to be the location of new features because half the team didn't want to use PHP anymore. The idea was they could slowly migrate endpoints to the .NET project. But that didn't survive. They got bored with a slow and safe conversion and convinced upper management to approve a total rewrite in .NET with a whole different team building out a microservice mess. The rewrite has been ongoing for 18 months now without a release. I heard they finished their first feature a few months ago, but still aren't live. Meanwhile the PHP project just keeps chugging along. Just goes to show, it's rarely the technology that causes issues, it's the team.

I don't really know anything about Laravel. I'm not really a PHP guy, I'm a project rescuer. Just happens to be most projects I get called into are PHP, C#, and Visual Basic. I've heard really good things about Laravel, but even ZF2 can be made safe, secure, performant, and reliable. It just takes discipline and the right team. That being said, I would consider PHP to be a language that is hard to hire for. There's just so many developers that flood the inbox who don't even know what a function is.

I will say, when I took a contract to build a greenfield web dashboard at the start of the year, I chose .NET 6 and C#. The platform and ecosystem is fine. I've shipped Java, Python, JavaScript, Ruby, Perl, OCaml, Haskell, Clojure, F#, and VB.NET. I picked C# for this project because the company already has a couple dozen C# developers who are pretty talented. I figured if I shipped them something they were comfortable with maybe they'd hire me again down the road.

[tored]

Very common for older PHP projects to store PHP serialized strings in the database. Horrible performance and of course gets easily corrupted of not handling concurrent updates properly.

Rewrites rarely succeeds, it is a typical fallacy for a team to believe that their problems lie in the language they are using and not in themselves. Seen it too many times.

[jaapbadlands]

The point wasn't that you should use PHP, it was to not jump on stack trends. There is a name for your kind of fallacy.

[iLoveOncall]

> there is a good reason people shy away from PHP

Please share it. And don't rely on articles that are more than a decade and 3 or 4 versions of PHP old.

[makeitdouble]

IMHO this very discussion factors in whether you'll want a PHP stack or not.

If you're looking for pragmatic devs that don't care much about the trends, the community or peers' general opinion about a technology, going with PHP will get you this type in spades. Especially if you're looking for experienced engineers.

If you want devs that care about thoughtful designs, elegant solutions and want to enjoy the community, it will be a lot more difficult (not impossible, but it's an uphill battle)

And this has little to do with PHP's viability per se, there's just so much baggage that most devs will self select in one side or another. A language's base design philosophy matters, and it's always better to chose a stack that matches your own philosophy.

[5Qn8mNbc2FNCiVV]

Afaik you cannot discern null and undefined. So, not there and "null"? Either that or I'm going to have to have a good talk with my colleague

[iLoveOncall]

Go have your talk [1]. But that's a pretty weak argument anyway given that:

1. Other languages also do not have this distinction (Python for example AFAIK),

2. It's relatively useless. I get the value of it in JavaScript which has a lot of asynchronous code and frontend where the behavior may indeed be very different between null and undefined, but in a server-side application I don't think the nuance is necessary at runtime, and potential programming mistakes involving that can be caught by a linter.

[1] https://stackoverflow.com/questions/6905491/how-to-tell-whet...

[skinkestek]

https://stackoverflow.com/questions/6905491/how-to-tell-whet...

At the language level PHP has about the same problems as JS.

Thankfully it looks uglier so people get an early warning before using it for everything.

[ThalesX]

> Afaik you cannot discern null and undefined.

This is a discussion for us tech folks. When it comes to business. Customers don't give a rat's ass about this as long as the product provides them with value.

If you're flooded with customers and the tech stack is a pain in the ass, perhaps it would be a good time to start considering this, but until you have this problem, the technical aspects are just wasting investor money and / or engineering time.

[resonious]

When I (an average developer) accidentally check for null but not undefined in the code and it causes a bug, the customer might care a lot.

[ThalesX]

There is always a balance to strike between development and delivery. When creating a system with high potential failure costs, it's important to select a technology stack that minimizes common errors for developers.

For most companies, issues like `undefined | null` bugs can be resolved with just a few code adjustments, resulting in only minor inconvenience for customers. As long as problems are addressed and the product provides value, customers will continue to support it.

There are CEOs and CTOs that feel differently. I wish them luck.

[lelanthran]

> Afaik you cannot discern null and undefined. So, not there and "null"?

So?

Don't similar footguns appear in Python and JS? Why single out PHP for footguns when the other languages are no better?

While I'm not a PHP programmer, I have used most programming languages, and PHP doesn't seem any worse than the competitors.

[proxyon]

How about the fact that most of us are experienced and can attest that PHP is the worst language we've ever used in our careers?

[coolg54321]

I don't think so, i've used PHP at work for more than 10 years till 7.4 point mostly Symfony, it has it's own quirks but i still feel PHP really pragmatic. I don't have any strong feelings against it.

Nowadays im on django/python because im in a python shop and I like python too.

[Hamuko]

Yeah, I feel like PHP is a massive hiring risk. I personally wouldn't want to touch any PHP code unless I'm paid a massive premium for it.

(I mostly write Python professionally, and use Python, Swift and Rust in personal projects in case anyone is wondering.)

[pdntspa]

I can think of far worse fates

Some people write whole-ass applications in bash, the psychopaths

[proxyon]

Ok that's even worse

[arpa]

That is actually better, but you have to be a pervert. Source: wrote some fully featured applications using own bash framework.

[lelanthran]

> Some people write whole-ass applications in bash, the psychopaths

*giggles nervously, then changes the subject.

[Cthulhu_]

I disagree; it's not the language that's bad, it's the community. Too much tech debt that was never removed, too many people that profess to be experts on the internet and give bad examples, and too many people full of themselves building and rebuilding their own frameworks. That was the issue 10, 15 years ago anyway, things have improved but it means people have to pick established frameworks like Laravel.

[crote]

You can't really separate a language from its community, though.

You're getting paid to deliver business logic, which means most work is going to be gluing together libraries. This inherently means relying on community-written code, and related stuff like documentation and StackOverflow answers.

If the community is bad, the language isn't worth using.

[aarondf]

Genuine question, when was the last time you wrote PHP?

[proxyon]

5 years ago and I wish I hadn't.

[chalcolithic]

It was fine in the late 90s. Very adequate for the hosting landscape. I have not touched it since that time

[jcparkyn]

Spoken like someone who's never used Matlab :)

[itake]

> indexes start at 1

- no one

-- Matlab

[MiyamotoAkira]

Pascal had indexes starting at 1 too.

Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C)

Indexes starting at 1 matches with a more natural ordinal sequencing.

[selcuka]

The most evil was Visual Basic where you could configure the default starting index (OPTION BASE 1), leading to weird bugs when multiple people worked on the same codebase.

[itake]

I don’t understand. Either your saying adding or removing elements to an array doesn’t manipulate memory, or you’re saying adding or removing elements in an array does manipulate memory, but the developer doesn’t care due to the GC.

If it’s the second option, why has (almost) every other language chosen with a GC to start arrays with 0?

[haspok]

> indexes starting at...

"I don't understand the word 'index'".

- a functional programmer

[_fat_santa]

Personally I think the indicator of success is not necessarily X stack or Y stack, it's what stack are you most comfortable with? I think one of the problems with those startups you mentioned that used flashy stacks is they are not only fighting a battle to build the product, they are also fighting a battle to learn their way around the new stack they just adopted, and learning all the quirks with it.

I don't think one stack is necessarily better than the other, it's all about how well do the developers know the tech stack in question.