4 ms·

> a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP. But even for web requests it's terrible. Or at least, it was,

by mholt 8y ago

> a version of PHP that's not focussed on web requests, which is sort of the entire point of PHP. 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.

nicoburns 8y ago
PHP has gotten a lot better. New APIs have been added on top of features like classes. And many of the worst of the older APIs have been deprecated. 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.
- debaserab2 8y ago
  > use one of the nicer frameworks (like Laravel) Yikes
  - cityzen 8y ago
    And?
deleted 8y ago
[deleted]
muglug 8y ago
> But even for web requests it's terrible 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 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.

by mholt 8y ago

nicoburns 8y ago

PHP has gotten a lot better. New APIs have been added on top of features like classes. And many of the worst of the older APIs have been deprecated. 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.

debaserab2 8y ago
> use one of the nicer frameworks (like Laravel) Yikes
- cityzen 8y ago
  And?

deleted 8y ago

[deleted]

muglug 8y ago

> But even for web requests it's terrible 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 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.