[spdionis]

I'd say PHP is definitely one of those. Modern PHP web development is pretty productive and definitely high quality.

EDIT after reading the article: I do have to agree that concurrency in PHP is a bit of a pain, but those 3d party tools are pretty easy to use and maintain.

> Without significant forethought to several levels of caching; such as in memory caching, op caching ...

This is so trivial to setup it's not even worth mentioning.

> Sure, PHP has PSR standards etc, but they're fairly new and developers have been slow to adopt them.

Everyone I know and every library I use uses those standards. PHP is pretty standardized now, especially compared for example to js.

PHP frameworks work well out of the box and contain solutions for most use-cases.

Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository? Seriously? That's wrong on so many levels. Meanwhile I think composer is one of the best package managers around.

[riquito]

> I'd say PHP is definitely one of those

I still don't like it but the landscape definetely changed, and it keeps getting better.

> Meanwhile I think composer is one of the best package managers around.

Apart from the fact that it uses gigabytes of ram on real projects. At work we ended up using it outside virtual machines, to later copy back the dependencies.

[alexbilbie]

Are you committing the composer.lock file in your projects? Likewise you should try and use as close to absolute version numbers as possible in your composer.json `requires` sections.

I used did a quick test (having run `composer clearcache` each time) on one of my projects:

Without composer.lock: Memory usage: 75.96MB (peak: 87.5MB), time: 38.54s

With composer.lock: Memory usage: 7.47MB (peak: 8.99MB), time: 28.6s

[riquito]

I do, I also have just absolute version numbers. I'm not the only one with such problems

https://github.com/composer/composer/issues/1898

[thejosh]

What's a "real project"?

I use composer every day, and have 0 problems when doing a `composer install` on production.

I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down.

[riquito]

> What's a "real project"?

One of not negligible size. They usually have many dependencies. I can see on our composer.json around ~60 dependencies, and the number will only grow (apart some lucky circumstances).

https://github.com/composer/composer/issues/1898

> I also recommend setting up Toran Proxy, which will allow you to ensure you're not boned when Github goes down.

Yes, that's a good idea

[onion2k]

I do have to agree that concurrency in PHP is a bit of a pain

It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter.

When it does matter just use something else.

[jerf]

"It is, but the overwhelming majority of tasks in a web app don't happen concurrently, so it doesn't matter."

But is that cause, or is that effect? The dominant web programming languages for the last 20 years have all been single-threaded, so of course the web stack looks single threaded. Personally, I find there's a ton of things that ought to be concurrent but aren't. I mean, most other network apps need to do things concurrently, why not web?

Once you start looking at it this way, the staggering number of hacks employed to pry concurrency out of fundamentally single-threaded languages is astonishing.

Go is not the only solution to this, there are many. (Go is one of the more Algol-ish language choices that doesn't involve learning a new paradigm, though, and can make it a relatively easy sell where "Let's all learn Lisp!" or "Let's all learn immutable functional programming!", where "all" may be dozens+ people, may not happen. [1]) But I think in five or ten years, "the overwhelming majority of tasks in a web app don't happen concurrently" is going to sound very 200x-ish.

[1]: Incidentally, for those who are still baffled by Go's success, notice how all the alternatives involve trying to teach everyone a brand new paradigm. While that has its advantages, when it comes to language popularity, not requiring that has its advantages too. I'm a polyglot myself, so I get how Haskell is nice and Clojure is nice and how they open your mind to new paradigms etc. etc., no sarcasm, fully mean it, if you only know C-style languages I fully recommend you go fix that soon, but when you're trying to get a team of people on the clock to switch languages for a nicer concurrency story, cutting the requisite training time by 90%+ raises the bar very high for those other languages, in relative terms. (Even moreso than it sounds; not only is training costs less, but the risk of training failure is also that much less. It compounds.) I do not mean this as "advocacy", I mean it as explanation.

[onion2k]

Personally, I find there's a ton of things that ought to be concurrent but aren't.

What sort of things? I've been writing web software for ~20 years, and the vast majority of things that I've made boil down to "request comes in > validate input data > transaction to database > check transaction worked > write a response". Concurrency has never really been a problem, or even something I've wanted.

[wpietri]

Sure, there are plenty of CRUD apps out there. But an awful lot of apps end up getting jammed into that pattern just because it's the standard paradigm, and not because it's the right one.

Just this week I met with a friend who wanted an app for community meetings that would let people express their preferences in real time, changing their expressed opinions as discussion happens. That way everybody could see how the consensus was shifting in response to discussion without people having to say it out loud.

I quickly whipped together a prototype, and I intentionally didn't use a database because I wanted this to be dynamic. Whenever one person changed something, everybody else needed to see it immediately. That's very easy in a context where you have all your data hot in RAM in one process with easy concurrent-ish access to it: you have a bunch of observer objects that get notifications each time you change something. In database-land, it's a pain.

And it works for me at size as well. Years ago I led a team where we were building a new web product. We were big on test-driven development, and databases are a notorious pain point. We started out without one, figuring that we'd pull one in when we needed it. We ended up never needing one. Our system had incredibly low rendering times (<5ms, even on 2005 hardware), and its 1800 unit tests ran in a couple of seconds. Starting with concurrency saved us so much development pain.

Another common example of where concurrency is valuable is in notifications. Quora and Facebook both have excellent notification systems: dynamic and instantaneous. Twitter's are much rougher, and it's clear they've put a lot less thought into concurrency.

Games, of course. Imagine trying to build agar.io without concurrency. Or look at Google Docs: concurrency is at the heart of what makes them valuable in an office setting.

There's nothing wrong with CRUD apps. There's nothing wrong with all the mainframe batch-processing apps that preceded them, either. But there's more that we can do.

[paulddraper]

"just use something else"

That's what I do!

(Actually, I do that from the start of the project, so that adding something as pedestrian as concurrency doesn't involve a complete port to another language.)

[aries1980]

> Go is nice but when I tried it I really missed something like composer. "go get" and commit your dependencies to the repository?

Why is this a pb? Makes your app is more resilient to external outages and no need to git clone all the repos with historical data.