> I'm an experience developer (about 30 years at this point), and about 12 years ago I decided to do a volunteer project for a nonprofit in PHP

> mysql_xxxx functions

So, you used PHP 12 years ago and comment based on that.

You have a point though. I used this internet thing about 17 years ago, it was terrible. Only dial-up. SLOW! And don't talk to me about browsers. Netscape? Internet Explorer? Ugh. Forget it. I don't care what they might have changed, or replaced or completely removed, its always terrible.

The language/runtime have problems, just like every other language/runtime that exists, but complaining about a version from 12 years ago and comparing functions that aren't even part of the language anymore seems a little odd to me.

>You have a point though. I used this internet thing about 17 years ago, it was terrible. Only dial-up. SLOW! And don't talk to me about browsers. Netscape? Internet Explorer? Ugh. Forget it. I don't care what they might have changed, or replaced or completely removed, its always terrible.

We have only one Internet. But we have a lot of alternatives for Php to choose from.

If you have an Internet provider that gave you horrible service, will you give them another try even when your current provider is great in every way, just because the only good thing with your past provider was they gave you a connection in a day, instead of 3 days as with your current provider....

After 12 years? I wouldn't consider them to be the exact same as when I left them at least.

But what is the reason why I would look back at PHP, when there have been better alternatives available for quite a while now?

I'll be honest I don't really care what languages people use, not my place to convince you back. Just saying there's quite high chances PHP has changed at least a tiny bit over the past 12 years

I started using PHP when it was in version 3 and still use it occassionally. It has changed, but not considerably. The function naming is still a mess (backwards compatibility), arrays are completely inappropriate (naming them "bags" would be better), some decisions were so baffling (safe mode and magic quotes, superglobals, square brackets for arrays...) that I simply don't trust PHP to ever get better.

But there was a reason for experienced developers to use it - hosting. You could write a web app, ftp it somewhere and it would just work. There was no other platform aside from asp which would offer that. Nowadays this doesn't matter much, but 10 years ago it was great.

As a language though? Ugly. Just plain ugly.

I get safe mode, magic quotes and superglobals - but don't most languages use square brackets for arrays?

It certainly doesn't seem like a controversial thing to do.

If php3 to php7 isn't a considerable change to you, I'm not sure any change to anything ever, would register as a change for you, would it?

Left C 12 years ago...Came back to C this year. That's still the exact same thing.

>And it's not asynchronous. There's not even a good reason to use a synchronous language for web development today. Not to mention the ease of running NodeJS code in a debugger, or running tests in a browser and debugging it there...

This is still true today, and this fact alone makes it not worth trying out as a server language.

You just said you use Go for everything. Since when is Go asynchronous?

Also, claiming that only the programming model and language that introduced the term "callback hell" should be used is a pretty big claim to make..

Go is asynchronous. [1] It's a huge point of the language, and why it's working its way to the top of the new TechEmpower benchmarks [2].

> "callback hell"

It can be ugly to look at, but it's fast.

And I thought we weren't using references to 10 years ago to judge a language? Promises minimize callback hell with a far better (more functional) interface, and async/await (usable today with transpilation) banish it entirely.

[1] https://gobyexample.com/goroutines

[2] Preliminary results: https://www.techempower.com/benchmarks/previews/round13/ -- Go has been seriously optimized over the past six months, so the last round of results is less impressive, but still strong: https://www.techempower.com/benchmarks/

If using threads means the language is asynchronous to you, every language ever invented that has threads <including php> Is asynchronous.

JavaScripts asynchronous nature is nothing like that of go/etc with threads: JavaScript is inherently single threaded with an asynchronous event loop.

As for callbacks, who mentioned 10 years ago. promises were added to the ecma script last year.

Edit:

Your message seems to be inconsistent.

Every failure or less than great situation in your favoured languages has just been fixed in the last few years.

The things you complained about in another language were fixed/removed years ago but you say it's still just as bad.

>If using threads means the language is asynchronous to you,

Goroutines are not threads. It's named after a "coroutine," which is an async function (like a generator) where you can pause execution of a task (to wait for IO, for instance) and then resume it at a later time. Coroutines give you implicit async/await style programming, without having to use extra keywords. The language Lua supports coroutines natively, for instance, including explicit yields to use them as generators, if you need. Goroutines give you coroutines with a bonus: Actual thread hopping (and multiple channels of communication possible, so you can effectively have more than one "yield" channel).

If you have 400,000 Goroutines running on 4 CPUs, your Goroutines can task switch between those 4 CPUs using 4 OS threads (or 8, or whatever number you determine is best for your app) as their IO events queue up. It is async, and each Goroutine has around 10k of RAM overhead, not counting data you're storing yourself (it varies by architecture, but that's a reasonable estimate; I've seen between 6k and 16k on different architectures).

Go is better async than JavaScript, because a Goroutine started on one thread can get processed on another, so a few thread-hogs won't block a task. A single Goroutine could cycle between all your worker threads, in fact, though I think it tends to stick with a single worker thread ("thread affinity"). It's probably the most asynchronous you can get in a language (only the Erlang VM/Elixir is in the same class of language, as far as I know).

Do you think PHP could handle 400,000 concurrent WebSocket connections on one server? Go can. How much RAM would you need to handle 400,000 CPU threads? Maybe 64Gb instead of ~8Gb in Go? Wouldn't CPU switching alone be starving most of the threads and redlining the CPU at that point? In my experience you start seeing serious slowdown around 5,000 threads. I'd guess you'd need 50x as many servers to handle that many connections on PHP. Maybe 100x. You need to support a million users? Is it better to have 3 servers or 300?

> The things you complained about in another language were fixed/removed years ago but you say it's still just as bad.

PHP is architecturally single-thread-per-request. Full stop. Even PHP 7 and HHVM. That simply doesn't scale as well as async, as I described above. The complaints I made were why I bailed on it years ago. I'm sure PHP has gotten a lot better than it was when I used it, but given that it still misses the mark architecturally, I have zero motivation to give it a second chance.

But given that NodeJS has far surpassed it in community support (as well as by many performance measures -- HHVM is quite fast at raw processing speed now, though not as high throughput because of the lack of true async), why is PHP still relevant except to continue to maintain existing code bases? (I've worked with several of those as well -- Joomla and Drupal in particular -- and neither was something I'd consider worth using, having looked at their internals and terrible performance. Joomla was a complete disaster; Drupal only slightly better.)

>Every failure or less than great situation in your favoured languages has just been fixed in the last few years.

Your point? Even if they all were only better as of yesterday, they're still better. Or are you defending your choice of a few years ago?

And actually, Promises have been available using polyfills for years. The proposal was made at least six years ago; I can't find the exact date, but I found a reference added to the CommonJS wiki in 2010 [1]. The Q library dates back to 2010 as well. [2]

I concede that there may have been a period of time where PHP was better than JavaScript, by the criteria I'm using today, because PHP did improve a lot after I first encountered it, while JavaScript only more recently developed its compelling advantages. It looks like Node was released in 2009? In 2009 I was using OpenResty (Nginx+Lua) to do my (small amount of) server work, which can still be more performant than both Node and PHP. But NodeJS has shot past in terms of community support, which is critical, TypeScript is awesome, sharing code on client and server is awesome, isomorphic rendering is awesome, and performance is good enough (compared to Lua) that NodeJS just wins for me, big time. Except when I need the extra speed, and for that I use Go.

Go is a brand new language, relatively speaking. So of course they're still making major improvements. Performance has already surpassed HHVM, even for raw compute tasks. It's a better fundamental architecture, giving it an edge, and performance will likely improve still more, though they're already hitting diminishing returns: Some of the worst case performance they see now may get 2x-4x faster, but typical app performance is probably only 10-20% short of optimal. I mean, they're already beating C++ on the server. How much better can they go?

Use whatever language you want; if your background and/or current job is PHP, so be it. It's not as bad as it was 10 years ago, for certain. Just don't expect anyone to pick it up based on its merits. There are too many other, stronger options available today.

[1] http://wiki.commonjs.org/wiki/Promises/A

[2] https://github.com/kriskowal/q/graphs/contributors

Sounds like you just had a very bad experience with PHP, but it could have happened with most languages, honestly. I got (only) 20-year experience, but I have come across quite bad C codebases, poor Perl applications and terrible Java code, and I have thought 'never again' more than once, too.

In fairness, PHP was in a different place 12 years ago. The language has improved in that time. There are still lots of warts but the language and ecosystem have worked together to push it forward.

I'm going to be honest, I only use it because of company lock in. I hated it for many years but some of the stuff released and some of the stuff on the way in the internals is quite exciting.

Not impressed by your comment at all. If you think that the age of Nikita Popov or Andrea Faulds is any indicator of their "competence" I suggest you actually take a look at their contributions.

My comment just said that they are just college students. And the links are to prove that. Those are just facts. I don't know why people are pissed.

Edit: It is not just their age. I have seen their contributions (RFC's and implementations) and had conversations with them. And my opinion is also based on that...

There are lots of PHP-lovers in this thread. My above comment got voted down to -2 as of right now.

Everyone focuses on the "my experience is old" and not on the "it's not an asynchronous language" part. Oh well, I lost some Internet points.