Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goro – An implementation of PHP written in Go

github.com

Post reply on HN
Print view View original

111–120 of 135 posts

Re: Goro – An implementation of PHP written in Go

#111

Post by debaserab2 »

nicoburns wrote: post #84
mholt wrote: post #80

Earlier quoted context omitted.

> 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…

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…

> use one of the nicer frameworks (like Laravel)

Yikes

Re: Goro – An implementation of PHP written in Go

#112

Post by cityzen »

debaserab2 wrote: post #111
nicoburns wrote: post #84

Earlier quoted context omitted.

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…

> use one of the nicer frameworks (like Laravel) Yikes

And?

Re: Goro – An implementation of PHP written in Go

#113

Post by swsieber »

wwweston wrote: post #88
baroffoos wrote: post #48

Earlier quoted context omitted.

Facebook forked PHP to make Hack to try and make PHP usable. Yahoo is yahoo. Wikipedia wouldn't have the resources to change anything. Google has a wiki page for their developers telling them to never ever use PHP for any google project.

> Facebook forked PHP to make Hack to try and make PHP usable. Facebook clearly found PHP usable before they created Hack, otherwise they would (a) not have bothered and (b) may well not have existed in the first place. The accurate statement is probably closer to "FB created hack to adapt to performance demands at an unusual scale and add some additional typing discipline bringing additional order across a large eng…

I'd take it one step further:

At Facebook scale, performance gains have huge returns (adding typing can improve pefromance), so they try to improve all parts of their infrastructure, not just PHP.

For example, Facebook's bolt for native code: https://code.fb.com/data-infrastructure/accelerate-large-sca...

PHP probably did have more low hanging fruit than say C, I'll give them that.

Re: Goro – An implementation of PHP written in Go

#114

Post by insulanus »

cglace wrote: post #108
wolco wrote: post #59

Earlier quoted context omitted.

PHP is growing these days. Some of the hip crowd are coming back, small business never left and globally it is gaining as more developers come online. PHP offers so much so easily it's hard to replace.

Why choose PHP over python, node, ruby, elixir, go, etc. There are just so many great choices that offer just as much and more than PHP. I get that PHP has made major strides over the years. I just don't see why you would choose PHP for a greenfield project.

Well, my guess is that PHP offers a lot more to the beginner.

When you've been doing this a while, you can appreciate what e.g. Python gives you in structure, maintainability, and lack of foot-guns.

But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be really valuable.

I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath.

Re: Goro – An implementation of PHP written in Go

#115

Post by dymk »

bouncycastle wrote: post #92
wild_preference wrote: post #81

Earlier quoted context omitted.

No, the alternative here would be to just let the write()'s throw and let upstream handle them. You don't try/catch to catch an error just to re-throw it for the same reason you don't try/catch every single line of your program. Exceptions are one reason other languages don't need this "if err throw err" code, without making a comment on if either is superior.

Yeah, but an error error is not really an exception. Often in Go, errors are used to mark different states, such as EOF which are expected and you can deal with locally and have more control whenever you want to return or not, for example, you can test the error in the same if condition and decide whenever to keep going - usually you do. Error handling code is more local rather than all over the place, plus no need t…

> Often in Go, errors are used to mark different states, such as EOF which are expected

Then it's not an error, and Go has once again forced people into writing something semantically confusing and/or incorrect because it lacks basic abstractions.

Re: Goro – An implementation of PHP written in Go

#116

Post by muglug »

jchw wrote: post #109
muglug wrote: post #101

Earlier quoted context omitted.

> its request model is still based on CGI, executing a script for each request 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…

>And it turns out to work incredibly well for the most part. It's serverless by design! Worked incredibly well compared to what? CGI was a performance nightmare, forking per request. CGI and FastCGI have both been a security nightmare. HTTPoxy, Shellshock, Pathinfo, and more. Setting up PHP correctly is cumbersome and depends on a complex interaction between sometimes confusing php.ini options and fairly complex conf…

> Setting up PHP correctly is cumbersome and depends on a complex interaction

One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

> If you're using Nginx

I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

The point I'm trying to make here is that for most web request use-cases, PHP can help you get what you want. But if there's a paradigm you prefer, use it. If you control the stack, the world is your oyster.

Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

Re: Goro – An implementation of PHP written in Go

#117

Post by Ayesh »

koudos wrote: post #61
wolco wrote: post #56

Earlier quoted context omitted.

Those facebook improvements made there way back into the core. Google might be able to move quicker if they allowed php. Facebook killed them in social. The type of products google can offer is limited by this decision.

Not sure PHP is the reason reason why Google failed at competing at Social

It is not.

Re: Goro – An implementation of PHP written in Go

#118

Post by Mave83 »

insulanus wrote: post #114
cglace wrote: post #108

Earlier quoted context omitted.

Why choose PHP over python, node, ruby, elixir, go, etc. There are just so many great choices that offer just as much and more than PHP. I get that PHP has made major strides over the years. I just don't see why you would choose PHP for a greenfield project.

Well, my guess is that PHP offers a lot more to the beginner. When you've been doing this a while, you can appreciate what e.g. Python gives you in structure, maintainability, and lack of foot-guns. But when you're still in the "how does this work? Why won't this work? It worked!" phase, having less boilerplate, and fewer non-problem domain concerns (types? modules? tuples? Say what you mean, Old Man!) might be reall…

best documentation in my opinion

Re: Goro – An implementation of PHP written in Go

#119

Post by jchw »

muglug wrote: post #116
jchw wrote: post #109

Earlier quoted context omitted.

>And it turns out to work incredibly well for the most part. It's serverless by design! Worked incredibly well compared to what? CGI was a performance nightmare, forking per request. CGI and FastCGI have both been a security nightmare. HTTPoxy, Shellshock, Pathinfo, and more. Setting up PHP correctly is cumbersome and depends on a complex interaction between sometimes confusing php.ini options and fairly complex conf…

> Setting up PHP correctly is cumbersome and depends on a complex interaction One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me. > If you're using Nginx I don't have any…

>One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

I disagree. I think PHP was so massively successful because it was part of the mighty LAMP stack. The LAMP stack wasn't great because it was free of configuration, it was great because anyone could pick up an existing setup and just use it. A non-technical person could get a Bluehost or Hostgator account and get Wordpress running in under an hour.

But once you move from shared hosting to VPSes, the plug and play fun goes away. At reasonably moderate traffic, you have to tune things and debug weird issues. And debugging it, in my experience, is actually very challenging.

The best part of the LAMP stack today is that it offers a very quick way to get a good development environment. Since scripts are read off the disk, you get "auto reload" for free. That is nice, but given how mature other development environments have become, it's no longer a huge selling point to me.

Is the ease of use of the LAMP stack worth the negatives of PHP as a programming language? In my opinion, no. To me, it's only really 'yes' if you already have a very large PHP application, or you are writing software for people running LAMP stacks to deploy.

>I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

If you're using .htaccess, it sounds like you're probably using Apache as an HTTP server. Varnish is a caching server.

>Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

I never said PHP was bad. I am making the case that the application server paradigm where you have long running programs handling requests is better than the CGI and Fast-CGI paradigms where you run scripts per request. You can put band-aids on it, like caching very aggressively, but at the end of the day you will never get the 'free' amortization of per-request costs like you will with a proper application server.

That said, I totally think it's fair to use evidence from 7.5 years ago. A, these configuration difficulties exist today, and my proof is that I also have them today. B, Track record matters! PHP and PHP-FPM have been around for decades. Having constant security issues is a sign of endemic issues, such as what we saw with software like Wordpress or Drupal.

Re: Goro – An implementation of PHP written in Go

#120

Post by bouncycastle »

dymk wrote: post #115
bouncycastle wrote: post #92

Earlier quoted context omitted.

Yeah, but an error error is not really an exception. Often in Go, errors are used to mark different states, such as EOF which are expected and you can deal with locally and have more control whenever you want to return or not, for example, you can test the error in the same if condition and decide whenever to keep going - usually you do. Error handling code is more local rather than all over the place, plus no need t…

> Often in Go, errors are used to mark different states, such as EOF which are expected Then it's not an error, and Go has once again forced people into writing something semantically confusing and/or incorrect because it lacks basic abstractions.

Actually, any type can be an error, just as long as it impliments the Error interface. Go is more about interfaces - if some type impliments some interface, then that's what it is.
Post reply on HN