It's only "having trouble" because it can't change its API from month to month to match whatever's in vogue. A majority of the web still runs on some variant of PHP, and that guarantees that it's not dying anytime soon.
More broadly, it seems the author wants to create a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP.
( -smell can also be a thought-smell, but that's another discussion.)
I'd guess the author means "modern languages have a reasonably simple concurrency paradigm supported by language or standard library primitives," which would be about the only reason other than the interest in the task itself I can imagine reimplementing PHP in Go. I wouldn't buy that definition myself (and as the parent says, it's less clear whether it's the right fit for PHP) but it's a place to start in addressing the relative merits the project might actually be claiming.
There's a reason why the world moved on from CGI, even PHP moved on from CGI - and yet, its request model is still based on CGI, executing a script for each request. People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router. How is that superior to the more modern paradigm?
Despite this, the most largely used pieces of PHP software, MediaWiki, Wordpress, etc. tend to use things like the front controller pattern that actually invert the old CGI model into something more like what you would see with application servers in Ruby on Rails, Django, even Go to a degree.
And it turns out to work incredibly well for the most part. It's serverless by design!
> People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router
Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.
This is true of every language used on the web. That's why it's important to start out with the right choices, which in many instances PHP did not do, and is slowly trying to recover.
Facebook, Yahoo, Wikipedia, even Google.
But even for web requests it's terrible. Or at least, it was, last time I used it years ago. Couldn't really do any long-running tasks in response to an HTTP request, or load a single data set into memory to share among all the HTTP requests over the lifetime of the server. (Maybe you could, but I couldn't figure out how.)
I'm quite happy that I haven't touched PHP in years. As fun/cool as this project is, there's nothing I miss from PHP that isn't present -- or even better -- in Go.
It still works on the "new interpreter per request model". But that has advantages in the multicore world: everything is thread-safe by default, and will scale to N cores without any extra work (for shared state people tend to use something like Redis).
It's by no means perfect. But if you stick to the modern bits and use one of the nicer frameworks (like Laravel), then I think I'd prefer it over something like Ruby.
Maybe you have specific needs? At Vimeo it runs reasonably well, with median response time around 30ms.
> Or at least, it was, last time I used it years ago
Ah, PHP 7 was released three years ago and made some massive improvements to performance.
> Couldn't really do any long-running tasks in response to an HTTP request
We add something to a queue, and handle those tasks offline. Pretty simple.
> or load a single data set into memory to share among all the HTTP requests over the lifetime of the server
apc_store does that: http://php.net/manual/en/function.apc-store.php (it's part of a very popular extension)
> I'm quite happy that I haven't touched PHP in years.
Cool, it's not for everyone and all use cases. But it's always there if you need it.
The same is true of Perl, but (depending on your definition of "not dying") it's not clear that Perl isn't dying.
Also if the bankruptcy proceeds as planned, nobody will lose real money. (Btc sale so far covers all the fiat they owe and a bit more)
That said, I like them both somehow. PHP was the first programming language I learned beyond simple hello-world like programs (today, I use it mostly for prototypes only) and Go is my language of choice for performance-intensive tools.
In the end, I have not met any language yet, you can not hate. Smalltalk is beautiful, but can't do arithmetics properly (e.g., `1 + 2 * 3` == 9). Lisp lets you write correct programs, but breaks your parenthesis key. C++ can be fast, but actually doing it is hard and have you ever solved one of those template-error riddles?
That's not Rust.
https://github.com/MagicalTux/goro/blob/3cb3dfe0eef910c03e41...
More php interpreters is of course nice.
For example, in rust you could use:
let res1 = w.Write(...)?;
let res2 = w.Write(res1)?;
Of course C doesn't have a good type system that allows this sort of thing; it was created before such type systems were well known.
I would expect any modern language to at least recognize that there are good ways to sequence and compose types.
if err != nil {}
You get used to that pretty quickly in Go, but it still looks messy to a lot of people.
I'm a little confused on this piece, as PHP does have a cross process opcache. People also use things like apcu to share userspace things across processes (uses mmap).
The point is there is no shared state in the running problem
So, what they are proposing is helpful. But, they seem to be assuming that PHP shares nothing across processes. That's just not true.
which are these modern languages and which are the cases where it is not keeping up?
IMO PHP is one of the languages where development is really quick and the ecosystem is flourishing.
Would you say that JS is dying?
Not to mention Java, which from Google trends it looks like it's an elephant half-way to the cemetery already https://trends.google.com/trends/explore?date=all&geo=US&q=j...
Add in "Laravel" and things look pretty different: https://trends.google.com/trends/explore?date=all&geo=US&q=p...
I know I personally steer any newbie away from Googling up "php tutorial" - most of them are horrible, full of bad coding practices and vulnerabilities. I steer them to a good framework and suggest they peruse its docs.
https://trends.google.com/trends/explore?date=all&geo=US&q=p...
If you are going to write a go program to run PHP to use go specific features, why use PHP at all?
It can also be used as a common in-application scripting language.
Why doesn’t PHP work out of the box on those systems if compiled?
Instead of building PHP apps on a PHP platform built in Go, people should just build apps in Go. Or in C++, D, Nim, F#, C#, or even Java 8 or 10 with that new AOT compiler. (I think F# and C# can also be compiled in advance with CoreRT, but even if they can't, they're a huge upgrade over any interpreted language.)
I would mention Rust except that it's terrible. All popular programming languages in our timeline are bad, and deter millions of smart people from the profession. But Rust is extraordinarily bad and should be replaced.
But a sensible startup mindset. Use whatever setup allows you to get things up and running the quickest. By the time you run into scaling problems brought about by a choice to program in Ruby (if you ever do) you'll have a viable product, and can transition pieces away as you see fit.
Consider the possibility that you consider all of the popular languages bad because there is something about "bad" languages which causes them to become popular. For example, I notice that all of the examples of "bad" languages are ones which let you push out buggy software that is "good enough".