How come PHP seems so much faster than Rust?
reddit.com
reddit.com
I personally believe it's ubiquity is well-deserved, and I actually like it as a language despite all its quirks (which exist in almost every language I've come across)!
I disagree, mostly on the grounds that string concatenation isn't very convenient, so it tends to be easier to do things "the right way" instead of hacking things together. Yes, you can do string concatenation using something like `format!(...)`, but at that point it's really similar to the correct solution that it's not really what you'd reach for by default.
And yeah, the community here is a huge part of it, and IMO languages can and should be judged by their communities. If a language's community promotes insecure solutions, that's a language that I don't want to use at my company because I don't want my employees following that example.
Where's your proof? Modern PHP frameworks are secure by default.
Symfony Laravel CodeIgniter CakePHP Yii Zend Slim
All of these can (and recommend) using either PDO with named parameters, or a full ORM for SQL work. Most came packaged with a PDO (Doctrine, mostly) by default but have always supported whatever you wanted to use.
Write shit code, win shit prizes.
While there are some web-focussed languages (vs frameworks) that deliberately make it hard for you to write that sort of code, barely anyone uses them.
- it is not "input" must be treated, but, so to say - output. It's the destination that matters, not the source. By the time you get the input, you have no idea how and where it will be used. You can tell it right before the output (or, rather, better to call it "use") only. Say, you've got some input that didn't pass the verification and you will have to display it back in the HTML form. And if you already "escaped" it for SQL, it will be malformed. And vice-versa. Moreover, any data must be formatted properly before use, not just something that you tagged as "input".
- the word treated above is for a reason. Because the term "escaping" suggests some certain routine in PHP, which is the actual reason for numerous SQL injections.
I'm working on comprehensive taint analysis for PHP[0], and I'm spending a bunch of time thinking about how to automatically detect those dirty strings.
[0] https://psalm.dev/articles/psalm-3-and-a-half#taint-analysis
Not trying call you out on this point, more it made me laugh. Our lead developer strips out characters that break his XML importer (lets just say they are standard common characters, heck, he changes chr(13) to a string so he can switch it back later because he doesn't know how to handle multiple lines in an XML value). People who don't know how to escape inputs / actually handle data properly are in every language. We cringe on a daily basis.
You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation where programmers can't move fast enough in adding it to their stack. Data exfiltration is no longer a flaw but a feature.
It is very very easy to write sloppy PHP, definitely easier than in many other languages and default frameworks.
> You're not acknowledging all of the gaping security flaws in contemporary web-development frameworks. P
I'm very aware of them, basically none have (had) as many high-impact vulns as PHP-based stuff does.
> Yet somehow, Python, Ruby and NodeJS have all had numerous CVEs despite those attack vectors being well known at the time a given framework was written.
You're not acknowledging the orders of magnitudes difference between the impact of an usual PHP vuln and those you listed.
> You think SQLi was bad? You should spend some time thinking about the numerous attack vectors available today in nearly every GraphQL implementation
The flaws in others are a very poor excuse for flaws in a thing itself.
It was a scripting engine with a such a thin layer of C that it could easily and quickly incorporate the huge number of open source C libraries that existed at the time.
Perhaps I was quite late to the party though - I only started programming in 1999 (got a computer for my 11th birthday!) - so I'm not sure what it was like before then.
CGI just would run any type of script. Originally that was typically Perl but PHP surpassed Perl for a variety of reasons. PHP could be run either through CGI or through mod_php in Apache. There was also a mod_perl I believe and a few others but php is what web hosts typically installed in the early 2000s.
From https://perl.apache.org/about/history.html
> "PHP was also around already, and was an embarrassing witness to Perl's greatest weakness for server-side programming: that embedding Perl was a pain. Although the hooks were there for embedding Perl, they were both undocumented and buggy.
My other take on it is that PHP is like TypeScript, in that the path to adopting PHP from HTML is simple enough—just rename your HTML files with a .php suffix and you can add dynamic elements—or not. Just like how you can rename your JavaScript code with a .ts suffix and add types—or not.
Personally, I remember writing a few Perl CGI scripts. But I ended up using PHP for any quick-and-dirty dynamic stuff.
This is the competition that PHP was so much better than.
PHP was only free beer with a clunky language and 3rd class DB support.
MySQL couldn't hold a candle to real RDMS back then, versus what was available with ODBC connectors.
Perhaps that is your definition, but the dictionary disagrees.
https://dictionary.cambridge.org/dictionary/english/superior
I don't see definitions about being cheaper as sign of quality, quite the opposite.
Maybe you would like to share your dictionary as well?
Getting access to a Windows box was never a problem in countries with more flexibility towards piracy.
80 and 90's Portuguese students could get whatever they wanted from shaddy shops that used to copy books and software.
Booklets with 200+ items on them.
I started doing ASP development before my web host suggested it was cheaper and easier to do PHP. They had both Linux and Windows shared hosting at the time.
http://www.apache-asp.org/faq.html
I was only wrong regarding the language, it made use of Perl instead.
The cheapest of them all was PHP with files being dumped via FTP upload.
The only competition in those early years was Perl iirc.
I'm not entirely sure if PHP was fast at acquiring new features.
PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.
I think how easy it is to pick up the language to do things contributed to its success. The template is built-in and 1000 functions in the global namespace.
Namespaces in 5.3
Javascript namespace/module handling is a nightmare, they should have copied PHP's.
You really have turn back the clock; languages didn't have package management back then. They didn't have packages. The only exception, at the time, was Perl (which had CPAN). PHP acquiring features was not just about language features but also how quickly it's standard library grew to accomplish anything you needed on the web.
> PHP didn't have classes until version 4 iirc. Namespace in 5.4? And 5.x is around NodeJS early days where RoR and Python Django/Pylon/Pyramid was around.
I'm actually talking about the PHP3 era; by the time we're talking about PHP5 then there was already plenty of competition and the "early days" were already long over.
That is not what I remember. CGI existed before PHP (1994), and was used extensively for web apps (ebay still appears to use it to this day). Also, mod_perl and Java Servlets were introduced around the same time, circa 1996, so I don't think it's correct to say PHP had a monopoly on web apps "for a long while".
Java required specialised or dedicated hosting ($$$). CGI was slow as hell. Mod_perl often was not available in shared hosting, for whatever reason.
PHP was cheap, fast, ubiquitous, and Good Enough™, for about a decade. Then VPS happened and the market changed.
While CGI was slow-ish, alternatives like fastcgi were already around (and in fact running PHP via fastcgi was also quite common for a while.
By the time PHP became ubiquitous, most people had moved away from plain CGI regardless of language.
Mind clarifying how this is different from the current hotness (from what I can tell, due to a decade-old shortcoming that no longer exists in mod_php/Apache MPM options) where folks are running PHP via the Fastcgi Process Manager?
That is only in relative terms in its time. For the past few years I keep thinking how the hell did Web Development went from Perl and CGI, arguably troublesome but understandable, to PHP which is ugly but easy to set up and running, to present days of... depending on which timeline you are, vagrant, VM, docker, k8s, Node.js... I would argue even Heroku with Ruby Rails isn't anywhere as easy as they were than the old days.
To this day, cloud functions still deal with "cold starts", where this was already a solved problem with PHP shared hosting.
All PHP needed to be was good enough. It was how it served pages that made it as popular as it was.
Large disclaimer, I know a PHP shared host was not actually scalable like AWS Lambda. Just the idea that any small business could plop down a few servers and start selling shared PHP hosting was huge back then.
If it's just me writing and deploying I use TypeScript but otherwise I tend to use PHP.
PHP only became viable with version 3, around 1998, and having most ISP only offering a choice between CGI (usually C or Perl) and PHP, naturally drove most cost oriented devs to PHPs.
Those willing to shell out more, could use one of the above options.
I could probably compete with python if I used guile's lower level C-procedures, but I sort of lost interest after that :)
The only way to know for sure would be to profile each bit to see what dominates: the file I/O? The regex matching? The FFI? The printing to stdout?
Also, looks like there is a rust wrapper for PCRE[0]; might be interesting to try it to get a more apples-to-apples comparison.
Is it though? I interpreted question the following way.
"Rust is a tool in my tool box, when the reason for picking it over other tools isn't demonstrably true, what am i doing wrong?"
I agree with the rest of your comment, just not with calling the OP or their question silly.
But I agree, I'm not nice at all, indeed.
I have always consistently found the Rust community to be nothing but amazingly helpful and friendly. I've posted in the Rust subreddit before in a different account and got the same helpful and friendly responses I did this time.
If we should judge a language by its community, then I, for one, wholeheartedly recommend Rust.
There was actually another post recently where someone asked a similar question only about Kotlin, and there ended up being this collaborative effort where people kept rewriting and optimizing both his Kotlin and his Rust code. Check it out:
https://www.reddit.com/r/rust/comments/d85gyh/why_is_this_sl...
There's an update too:
https://www.reddit.com/r/rust/comments/d8kew3/why_is_this_sl...
But we can't all be geniuses. I'm not one, either, but I don't feel attacked by anyone for pointing that out, and you shouldn't, either.
The benchmarks game suggests that it's quite fast: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But in that benchmark apparently Rust is faster than PHP (The slowest "Rust #2" is 2.45 sec. while PHP is 2.80 sec. He also mentioned "PCRE", but the ones with Perl in name are even much more slower [the fastest being 14.95 sec.]).
Did I miss his point by linking that benchmark, or did I interpret the benchmark wrong?
[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Other comments address why the Rust program is not optimal.
Id take that slowdown any day just not having to touch Rust though :^)
So any speed difference between Rust's and PCRE/PHP gets lost among the noise.
fyi "Regular Expressions (Perl-Compatible)"
That said, I am surprised that Perl does so poorly. It might just be that no one's submitted a perfectly optimized solution for Perl?
https://docs.rs/regex/1.3.1/regex/#opt-out-of-unicode-suppor...
There will be some difference in the regex engine speed, because PCRE is very fast in common cases.
But doing a single regex match is not that much work, so it probably boils down to I/O.
And PHP might use extra buffering to get better throughput for the common "stream a file" scenario.
Similar question with Python being faster than C++:
https://stackoverflow.com/questions/9371238/why-is-reading-l...
The program source code is shown.
Reference: https://www.reddit.com/r/rust/comments/5zit0e/regex_captures... 2 years ago, but it's still valid to me, I've just tested it and it's much slower as I expected. Feel free to correct me if I'm wrong :)
The php script and the log in question are probably in the kernel's aggressive block layer cache. The new files created by rust are potentially new and uncached, mean that it must be loaded from disk. Therefore the rust version is probably just losing time on disk access.
Quick test: review whether or not the rust version runs faster on the second execution.
Also or alternatively: use a profiler or copy the rust program to an in-memory block device (ramdisk) prior to access.
Majority of developers write crappy code even on a decent environment. But there is so much old and bad PHP code out there as a result of many years of teaching how to right bad PHP code that nothing can stop these bad criticisms forever.
I don't write PHP at this moment but I know PHP7 made major improvements. PHP is still a very good choice for rapid web development and fits for many startups, small, and medium size business, and there are many successful examples to back it up.
There are tradeoffs with PCRE vs RE2 instead of just raw speed.