Goro – An implementation of PHP written in Go(github.com) |
Goro – An implementation of PHP written in Go(github.com) |
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...
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".
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...
Rust was mainly developed alongside Servo which is more the rendering Engine, the JS side of it remained in C (spidermonkey)
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.
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.
Are these actually problems? Just things you have to know, and get used to.
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).
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.
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.
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.
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.
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.
Also there is already amazing work for Rust and WASM https://rustwasm.github.io/book/
This makes hosting php a rather pleasant experience for me: https://uwsgi-docs.readthedocs.io/en/latest/PHP.html
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.
The comparison isn't on equal footing.
Yikes
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...
https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new...
But alas, those are the choices that the Go language made.
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.
Exceptions are one reason other languages don't need this "if err throw err" code, without making a comment on if either is superior.
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 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."
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.
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.
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.
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.
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.
Google+ was designed by geeks for geeks.