Goro – An implementation of PHP written in Go(github.com)
github.com
Goro – An implementation of PHP written in Go
https://github.com/MagicalTux/goro
134 comments
I might even go so far as to say that the contention isn't true. In fact, these days I tend to assume the word "modern" is a developer thought-smell. Unless its user can explain what they mean by modern, it's best to assume it's a set of personal aesthetics informed largely by available fashions/habits in the first half decade of a developer's career (which can be fine, it's just the term modern carries waaay more weight than it should).
( -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.
( -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.
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 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.
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.
> 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.
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.
>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.
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.
> 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.
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.
[deleted]
>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.
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.
> it can't change its API from month to month to match whatever's in vogue
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.
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.
A majority of the web runs on one of a handful of programs that use php...WordPress, Magento...
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, 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.
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 engineering team."
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 engineering team."
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.
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.
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.
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.
There's also Laravel, which is more popular than both Django and Rails on a worldwide basis (https://g.co/trends/9CGj5). Rails and Django are more popular in the US where I hear PHP is not very popular...
Interesting, I have seen a surge of Laravel + Vue.js in recent projects. And many companies wanted to move back to PHP / Laravel from Ruby Rails / Django.
> Google has a wiki page for their developers telling them to never ever use PHP for any google project.
I didn't know that, but it makes sense - the things that PHP's good for (getting a web-based service backed by some sort of datastore up and ready to receive requests) are not the things that Google (on the whole) cares about.
Google instead cares that the thing can be improved and maintained by your colleagues, few of whom know PHP.
I didn't know that, but it makes sense - the things that PHP's good for (getting a web-based service backed by some sort of datastore up and ready to receive requests) are not the things that Google (on the whole) cares about.
Google instead cares that the thing can be improved and maintained by your colleagues, few of whom know PHP.
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 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.
It didn't failed for Social Reason, it failed because it was an inferior product for the mass. Facebook succeeded because its concept is simple enough for even your GrandMa and Dad to understand.
Google+ was designed by geeks for geeks.
Google+ was designed by geeks for geeks.
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.
HHVM can't make its way entirely back to core, and is in fact completely separating from PHP entirely now[1]. If I recall correctly, while PHP7 implemented better op-caching, it has _not_ implemented JIT compilation yet.
1. https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
1. https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
This is true. But HHVM lit a fire under the php devs to get php7 out the door with significant performance improvements. (php6 never saw the light of day). Php has improved so much with the 7x releases.
Php7 is pretty damn fast with apc cache and some tuning. Not to mention it doesn't have any of the silly restrictions that hhvm had.
It hasn't - a JIT compiler (if it comes) will come in PHP 8.
Employee of Google here... really? Where does Google use PHP?
> 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.
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.
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.
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.
> 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 (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.
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.
[deleted]
> 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.
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.
One component is the fact that it comes out of the box on a great many hosting providers and it's part of the old "standard" LAMP stack. You don't have to set up any reverse proxy crap and the architecture is simple enough - you access a .php file which is really just HTML with some embedded code and it interprets the file. The concept couldn't be any closer to JavaScript which I suspect has attracted so much attention from beginners just because it's everywhere on web clients, just as PHP is everywhere on web servers.
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.
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.
> 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
However, modern php isnt being sold as index.php and a mysql connection. It's Doctrine, composer and laravel/symphony. Which have their fair share of boilerplate.
>I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath
The problem with PHP is that you need the online manual everytime you want to use a function because the argument order is so inconsistent.
However, modern php isnt being sold as index.php and a mysql connection. It's Doctrine, composer and laravel/symphony. Which have their fair share of boilerplate.
>I think the best thing I remember about PHP is probably its online manual. Each library function had a few full use cases underneath
The problem with PHP is that you need the online manual everytime you want to use a function because the argument order is so inconsistent.
best documentation in my opinion
Interesting. This is a repo from Mark Karpeles, the former MtGox CEO
Hah. You can lose people hundreds of millions of dollars worth of assets and because it is magic internet money and not real money, you are coding instead of in jail.
Are you advocating for debtors prisons? If someone losses money you gave them, would you rather they were in prison, (living from your taxes) or working and repaying?
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)
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)
I did not read the comment as advocating for debtors prisons. My understanding is that those were (are) for individuals who cannot pay a debt. Instead, I assume the parent commentor meant something more along the lines of a Bernie Madoff.
There are a lot of ways to go to prison for mishandling other people's money that are not "debtors prison".
I think he's advocating for prison time for serious fraud - around $450m of assets stolen/lost through incompetence
The history of mtgox is not that simple and it is somewhat difficult to say who actually was the guilty one. Maybe there was lots of incomptenece involved but I'm pretty sure that also in a situation like that it might be so difficult even think straight.
MtGox was actually developed by Jed McCaleb, and Karpeles (MagicalTux) later bought the business from Jed. At the time of the sale the exchange already had tons of issues and apparently missing 80k BTC. It was perfect timing for Jed, who later started Ripple. For Karpeles the biggest mistake was buying the business. I would consider the latter mistakes only a minor mistakes. I would guess the codebase/security/etc was quite a horrible as well, can't really blame MagicalTux for not managing to save that business.
https://www.newsbtc.com/2016/05/22/mt-gox-a-new-revelation-s...
MtGox was actually developed by Jed McCaleb, and Karpeles (MagicalTux) later bought the business from Jed. At the time of the sale the exchange already had tons of issues and apparently missing 80k BTC. It was perfect timing for Jed, who later started Ripple. For Karpeles the biggest mistake was buying the business. I would consider the latter mistakes only a minor mistakes. I would guess the codebase/security/etc was quite a horrible as well, can't really blame MagicalTux for not managing to save that business.
https://www.newsbtc.com/2016/05/22/mt-gox-a-new-revelation-s...
He did spend some time in jail
He is currently CTO at London Trust Media (owners of Private Internet Access VPN): https://londontrustmedia.com/about/ - (under "Holdings Executive Management")
One of the most "hip to hate" languages implemented in one of the most "hip to love" languages...
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.
Go after PHP is therapy
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 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 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?
> 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.
Are these actually problems? Just things you have to know, and get used to.
So what are problems then? I mean, we live in a world where we have NP-Hard problems every day, but once you get used to being satisfied with a 95% correct solution it is no problem living in this world.
So yes, you can get used to such things and in the case of Smalltalk, it would actually harm the beauty of the language to evaluate that expression differently. Nevertheless, you could also argue that a language which doesn't respect one of the early rules every human learns in school isn't best for being used by humans ;-)
So let's just say it is not binary (just 'yes' and 'no') and PHP is just a language which happens to bring a few more unnecessary challenges for the developer (like the inconsistent function names).
So yes, you can get used to such things and in the case of Smalltalk, it would actually harm the beauty of the language to evaluate that expression differently. Nevertheless, you could also argue that a language which doesn't respect one of the early rules every human learns in school isn't best for being used by humans ;-)
So let's just say it is not binary (just 'yes' and 'no') and PHP is just a language which happens to bring a few more unnecessary challenges for the developer (like the inconsistent function names).
wait for js.rs
You joke but that's very likely to happen eventually if it hasn't already. At the very least I wouldn't be surprised if Mozilla made a prototype JS engine in Rust.
Yeah buddy. https://servo.org/
Also there is already amazing work for Rust and WASM https://rustwasm.github.io/book/
Also there is already amazing work for Rust and WASM https://rustwasm.github.io/book/
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.
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
https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new...
https://github.com/nbp/holyjit
I guess it's less likely for JS as JS already has 3? 4? 5? highly optimised runtimes, and you don't get too much value out of Rust's safety guarantees if you're JITing code anyway...
[deleted]
Isn't that what Mozilla created Rust for in the first place?
js.rs itself wasn’t created by Mozilla, it’s also died now.
I’ve been doing a rewrite of it here:
https://github.com/jasonwilliams/boa
Rust was mainly developed alongside Servo which is more the rendering Engine, the JS side of it remained in C (spidermonkey)
Rust was mainly developed alongside Servo which is more the rendering Engine, the JS side of it remained in C (spidermonkey)
js.hs
Firefox's js engine is already built with rust
> one of the most "hip to love" languages
That's not Rust.
That's not Rust.
A perfect example of error handling in go in the wild:
https://github.com/MagicalTux/goro/blob/3cb3dfe0eef910c03e41...
More php interpreters is of course nice.
https://github.com/MagicalTux/goro/blob/3cb3dfe0eef910c03e41...
More php interpreters is of course nice.
I don't understand. I have a C background. What is wrong with that?
In many languages invented since c that have errors as values, you can use something akin to a specialized monad to sequence things which may fail together.
For example, in rust you could use:
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.
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.
Probably the repetition of
if err != nil {}
You get used to that pretty quickly in Go, but it still looks messy to a lot of people.
if err != nil {}
You get used to that pretty quickly in Go, but it still looks messy to a lot of people.
And so it's clear to others, this probably the worst possible way for a language to go about implementing error handling (maybe aside from just not having any mechanism outright and terminating).
But alas, those are the choices that the Go language made.
But alas, those are the choices that the Go language made.
Is it really though?
I've tried out Exceptions in most languages and Go's error handling stuck out to me as the first one that is clear what it does, which of course is the mantra of the language.
Exceptions are a strawman.
Compare it to another modern language such as rust. Go does not have a stdlib mechanism for converting error types into each other (akin to rust's Into), it doesn't have the idea of mapping values together (akin to rust's carrier operator which is basically like monad do syntax), it doesn't have a way to create a list of errors by default (akin to 'cause' in rust), it doesn't have a way to generate concrete error types for your functions (like the 'failures' or 'error-chain' libraries in rust, which can't be written in go due to a lack of macros and generics and sum types).
It doesn't have a way to match on all possible concrete error values (akin to 'match' in rust or other sum-type things) or to do thing slike '.and_then' or '.map_err' or so on.
Go's error handling is downright insulting in a language that wasn't built at the same time as c.
Compare it to another modern language such as rust. Go does not have a stdlib mechanism for converting error types into each other (akin to rust's Into), it doesn't have the idea of mapping values together (akin to rust's carrier operator which is basically like monad do syntax), it doesn't have a way to create a list of errors by default (akin to 'cause' in rust), it doesn't have a way to generate concrete error types for your functions (like the 'failures' or 'error-chain' libraries in rust, which can't be written in go due to a lack of macros and generics and sum types).
It doesn't have a way to match on all possible concrete error values (akin to 'match' in rust or other sum-type things) or to do thing slike '.and_then' or '.map_err' or so on.
Go's error handling is downright insulting in a language that wasn't built at the same time as c.
The alternative is just as bad, a multi block try and catch mess that is in Java!
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.
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 to declare more classes for specific exceptions.
> 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.
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.
"Better caching of compiled code by allowing sharing of compiled or live objects (classes, objects, etc) between running PHP scripts"
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).
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).
I think the idea is for example creating an object in 1 PHP process, and modify it in the second.
The point is there is no shared state in the running problem
The point is there is no shared state in the running problem
Well, it mentions classes, for example. The opcache handles that already, cross process. For a live object, people tend to use apcu. It's not as nice as a shared object across 2 couroutines, but it's reasonably fast because it's using mmap and fairly fast serialization to share the object.
So, what they are proposing is helpful. But, they seem to be assuming that PHP shares nothing across processes. That's just not true.
So, what they are proposing is helpful. But, they seem to be assuming that PHP shares nothing across processes. That's just not true.
For C#, checkout PeachPie which allows you to run PHP applications on .NET Core including WordPress - https://www.peachpie.io/2017/02/wordpress-announcement.html
PeachPie is really interesting. I haven't had a chance to use it, but the most fascinating bit to me is that it can compile PHP to .NET. Could be a great way to incrementally move legacy code if you like writing servers in .NET, potentially. I do wonder how things like Wordpress extensions and dynamically generated code work, though. phpBB, for example, generates PHP files at runtime for its formatting engine (s9e TextFormatter, it's quite a nice library.)
Why is mcrypt listed as a future extension? it's removed in the latest PHP version and probably best to not even bother with
> PHP is having trouble keeping up with modern language
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.
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.
A great way to look into the future of languages is checking how many people is learning it now compared to the last few years, a great tool for that is google trends and things don't look good for PHP: https://trends.google.com/trends/explore?date=all&geo=US&q=p...
There is also this to consider
https://haydenjames.io/80-percent-web-powered-by-php/
https://haydenjames.io/80-percent-web-powered-by-php/
> Today, PHP is used by more than 80% of all the websites _whose server-side programming language we know_
I find it pretty annoying that they don't post stats on the websites that they couldn't classify. I think it's likely that their survey suffers from some level of survivorship bias: only websites that loudly announce their tech stack get counted.
So, how do they know which programming language is being used by a server? From https://w3techs.com/faq, they look at:
- HTML elements of web pages
- Specific HTML tags, for example the generator meta tag
- The URL structure of a site
- HTTP headers, for example cookies
- HTTP responses to specific requests, for example compression
I typically run Python / Django sites, and the only way, that you would know I'm running Python is a few Django-specific security/auth cookies. _Maybe_ that stuff gets picked up by their crawler. If I was running another Python web framework, like Flask, then you'd have no idea what kind of app server was sitting behind NGINX.
I find it pretty annoying that they don't post stats on the websites that they couldn't classify. I think it's likely that their survey suffers from some level of survivorship bias: only websites that loudly announce their tech stack get counted.
So, how do they know which programming language is being used by a server? From https://w3techs.com/faq, they look at:
- HTML elements of web pages
- Specific HTML tags, for example the generator meta tag
- The URL structure of a site
- HTTP headers, for example cookies
- HTTP responses to specific requests, for example compression
I typically run Python / Django sites, and the only way, that you would know I'm running Python is a few Django-specific security/auth cookies. _Maybe_ that stuff gets picked up by their crawler. If I was running another Python web framework, like Flask, then you'd have no idea what kind of app server was sitting behind NGINX.
I suspect an enormous number of those are WordPress blogs and MediaWiki sites, and I don't feel like that number is very useful without breaking those out. It's a bit like saying Fortran is popular in data science because SciPy is implemented partly in Fortran — not so much an indicator of overall language health as it is an artifact of one product's popularity.
By your tool, then it means that javascript is dying: https://trends.google.com/trends/explore?date=all&geo=US&q=j...
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...
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...
I'm not sure that's a great way to evaluate things.
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.
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.
This is a more fair comparison: https://trends.google.com/trends/explore?date=all&geo=US&q=p...
You can't just compare searches for tutorials on one platform against an entire other platform itself like that.
The vast, vast majority of PHP out there does not use Laravel.
You can't just compare searches for tutorials on one platform against an entire other platform itself like that.
The vast, vast majority of PHP out there does not use Laravel.
So you are saying that PHP is dying since 2004. That’s ridiculous. There are new languages and more alternatives today that’s it.
It just takes a long time for certain things to die.
That argument can be made from the other side about golang being artificially kept alive by Google.
The comparison isn't on equal footing.
The comparison isn't on equal footing.
Is golang dying? Is it losing steam at all?
so are you saying that for javascript the things are not looking good as well ?
https://trends.google.com/trends/explore?date=all&geo=US&q=p...
https://trends.google.com/trends/explore?date=all&geo=US&q=p...
Not really, its a complex issue, look how five years ago "PHP tutorial" was more searched than JS tutorial but this year "JS tutorial" has almost the double than PHP: https://trends.google.com/trends/explore?date=today%205-y&ge...
Any chance someone wants to do a benchmark to compare the performance of this to other PHP implementations?
I'd rather see a simple web app made with this benchmarked against one made with Phalcon. I know that's comparing apples to oranges given that this is an implementation and Phalcon is a framework, but it would be interesting to see if this approach is any faster than writing a framework from extensions in a faster language
But... why?
If you are going to write a go program to run PHP to use go specific features, why use PHP at all?
If you are going to write a go program to run PHP to use go specific features, why use PHP at all?
One common reason is to port/enable feature-specific legacy code without having to drag along a standalone interpreter.
It can also be used as a common in-application scripting language.
It can also be used as a common in-application scripting language.
Can I run WordPress on it today?
pre-alpha, bummer. Over the years I've had quite a few friends and family ask me to arrange hosting of their wordpress sites. Generally I refuse because wordpress has a long history of security problems. An alternate interpreter with sandboxed execution could solve a lot.
I thought wordpress had solved their problem with auto updates ? Not sure if that helps against poorly written third party plugins however. ..
https://codex.wordpress.org/Configuring_Automatic_Background...
This makes hosting php a rather pleasant experience for me: https://uwsgi-docs.readthedocs.io/en/latest/PHP.html
This makes hosting php a rather pleasant experience for me: https://uwsgi-docs.readthedocs.io/en/latest/PHP.html
A lot of us had same idea as you without time to rewrite it. Looking for alternatives, I found one done in Java:
http://quercus.caucho.com/
http://quercus.caucho.com/
I don't see what it fixes. You're just replacing an interpreter and in all likelihood bundling a web server.
PHP 7 is a pretty solid language. I don't like WordPress at all, but there's so much cruft, legacy nonsense and plugin garbage that you won't win that battle.
PHP 7 is a pretty solid language. I don't like WordPress at all, but there's so much cruft, legacy nonsense and plugin garbage that you won't win that battle.
well obviously we won't win the performance battle, and it may be impossible to protect the database and user data, but sandboxed execution with a virtual filesystem could protect the overall system, keep it from joining botnets and sending spam, etc.
Ok, but think about how many other ways you could fix that by wrapping battle tested interpreters.
Does it reproduce the ternary operator order "feature?"
Maybe this one will free some memory once in a while.
Funny how so much is missing. I mean what does work?
Since the author is one of the MtGox folks, this comment is pretty hilarious, possibly accidentally.
Yes, it was accidental. But I had a good laugh. Thanks
[deleted]
Awesome.
What I want to know is, can I just compile PHP under iOS and Android and run it?
Why doesn’t PHP work out of the box on those systems if compiled?
Why doesn’t PHP work out of the box on those systems if compiled?
I don't like unnecessary layers. Interpreted languages waste silicon and energy. I've heard startups justify using Ruby or PHP by saying "servers are cheap", which is just a bad engineering mindset.
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.
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.
> I've heard startups justify using Ruby or PHP by saying "servers are cheap", which is just a bad engineering mindset.
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.
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.
[deleted]
> All popular programming languages in our timeline are bad
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".
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".
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.