Live data from Hacker News

Goro – An implementation of PHP written in Go

github.com

101–110 of 135 posts

Re: Goro – An implementation of PHP written in Go

#101
post #96
post #15

> PHP is a nice language but is having trouble keeping up with modern languages 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…

It feels like you are downplaying decades of genuine improvement in web development under the guise that it's all just fashion, flavor-of-the-week stuff that has no substance. I get that people have an inverse reaction to hype, but I am disappointed that this is the top comment. 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…

> 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 to business logic and should (IMO) be part of the checked-in code.

Re: Goro – An implementation of PHP written in Go

#102
post #52

Earlier quoted context omitted.

I thought Go was a hip to hate language also. Seems to get a bunch of grief about "missing" things. I quite like it but haven't used much beyond toy projects.

Well, the difference is that the hate is coming from different directions. PHP is hated by nearly everyone except pure pragmatist. Go is hated by somewhat experienced programmers which find the absence of certain features inconvenient. 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…

> 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

Are these actually problems? Just things you have to know, and get used to.

Re: Goro – An implementation of PHP written in Go

#103
post #62

Earlier quoted context omitted.

Servo uses spidermonkey

Oh, I see. Thanks. I assumed the JS engine was written in Rust!

Spidermonkey will probably never get rewritten in rust, as the safety guarantees would be precluded by JIT.

Re: Goro – An implementation of PHP written in Go

#104
post #45

Earlier quoted context omitted.

While true, there is still a tremendous amount of the web that is powered by php and not using WordPress or Magento. Facebook, Yahoo, Wikipedia, even Google.

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.

Just because Google doesn't have a use for PHP doesn't mean it has no use or that it's dated or having "a hard time keeping up." Why would Google want to use PHP when it doesn't have a core competency that uses it?

On the other hand Microsoft does use PHP in some cases, where it makes sense, like company blogs. What's wrong with that? Nothing. The right tool for the right job. People that hate on PHP are usually people that over engineer things. Why build something like Wordpress in .NET or Node.js...when you don't need that, because you already have Wordpress and it works fine for a small site or blog? People will spent 10x the amount of time trying to -not- use PHP on a simple project than to use that time doing something else.

It's like this new "let's containerize everything" movement. Ok, you just spent an hour setting up something that would normally take 5 minutes, and you now have access to a bunch of features your little app will never ever use. Congrats.

No one is saying use PHP to build a super complex webapp, (though you could do that if you wanted!) But for small project PHP is very hard to beat when it comes to time/benefit. Right tool, right job. Simple. Biggest complaint I have against modern developers is the tendency to make a simple thing complex because it's en vogue to use X, vs Y. Gotta build this small web app with 50 users and no need to scale, better build in Node and Kubernetes. So laughable.

Re: Goro – An implementation of PHP written in Go

#105
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.

Google+ did not fail for technical reasons. Everything I saw about it was technically better. It failed for social reasons, facebook already exists and has everyone on it.

Facebook was here already when Instagram, Twitter, Instagram, Snapchat became popular

Re: Goro – An implementation of PHP written in Go

#106

Earlier quoted context omitted.

Oh, I see. Thanks. I assumed the JS engine was written in Rust!

Spidermonkey will probably never get rewritten in rust, as the safety guarantees would be precluded by JIT.

That's not entirely the case - there's definitely research / work being done in this area.

https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new...

https://github.com/nbp/holyjit

Re: Goro – An implementation of PHP written in Go

#107

Earlier quoted context omitted.

Google+ did not fail for technical reasons. Everything I saw about it was technically better. It failed for social reasons, facebook already exists and has everyone on it.

Facebook was here already when Instagram, Twitter, Instagram, Snapchat became popular

All of those did something different to facebook. None of them attempt to replace it. Googles problem is not that they can't move fast, they already move too fast. Every year they totally rebuild an IM platform and create a new music streaming service.

Re: Goro – An implementation of PHP written in Go

#108
post #59
post #54

Earlier quoted context omitted.

> A majority of the web still runs on some variant of PHP, and that guarantees that it's not dying anytime soon. The same is true of Perl, but (depending on your definition of "not dying") it's not clear that Perl isn't dying.

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.

Re: Goro – An implementation of PHP written in Go

#109
post #101
post #96

Earlier quoted context omitted.

It feels like you are downplaying decades of genuine improvement in web development under the guise that it's all just fashion, flavor-of-the-week stuff that has no substance. I get that people have an inverse reaction to hype, but I am disappointed that this is the top comment. 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…

> 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 configurations with your webserver. Check out, for example, this article on configuring PHP properly with Nginx:

https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...

So other than that, yes, it worked. Incredibly well? Not compared to application servers which don't have the kinds of vulnerabilities and configuration complexities caused by the weird impedance mismatch between webservers and FastCGI workers.

The jab about serverless is really condescending and unrelated, but I feel it necessary to point out that I am not really especially a proponent of serverless as it is today. I much prefer long-running application servers. PHP-FPM gives you a bit of both worlds, a combination of them that is far from ideal in my opinion.

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

I am having difficulty responding to this because I think you misunderstood what I meant. I do think the routing logic should be part of the code. Which means, not part of the webserver configuration. If you're using Nginx, which is the server I currently use with PHP, checking your rewrite configuration in with your code is difficult, because there's no `.htaccess` mechanism like Apache, and so you have to deploy the configuration separately.

Post reply on HN