nikic

Ruby only needs symbols because it made the questionable choice of using mutable strings with by-object semantics. PHP does not have this problem. It will automatically intern literal strings, thus giving you the performance and memory usage benefits of symbols, but without the crutch of requiring a special syntax for them.

The lifetime constraint in the enum is mandatory, the code won't compile without it.

The tokenization function itself doesn't have to explicitly specify lifetimes like it does in the blog post. It would also work without them and Rust would still ensure that you don't end up with a use-after-free.

Common mistakes: Testing with xdebug enabled in one version or testing with opcache enabled in only one version.

I feel like you're giving a very one-sided representation of the issue. There were some very real concerns about the memory usage of the proposed modifications to phpng (you can see http://news.php.net/php.internals/74284 for an analysis) - what should have happened is that we just went over those changes and decided which parts are feasible and which are not. This happened eventually and now there's a full consensus on how this change is supposed to be implemented (64bit on LLP64, size_t string lengths, uint32_t array lengths). However before that happened the whole discussion was basically a pissing context between Pierre and Zeev. Pierre was most certainly not the one who got us back to cooperating.

PHP has a rather strict no-BC-break policy for minor releases. As such the 5.x series improves the language mostly through additions. I think that's good. PHP has been missing a number of things that are now present.

However that doesn't work forever, at some point you need to clean up some of the old stuff. That's why a PHP 6 release is planned in the near future (i.e. somewhere in the next three years ^^).

While the gist behind this post is right, the article contains a number of factual errors. E.g. the version numbers in the "language features" section are pretty messed up:

* Namespaces, closures and FPM were already in PHP 5.3

* The built-in web server was already in PHP 5.4

* Improved variadic functions, argument unpacking and phpdbg will be in PHP 5.6, which goes to beta in about a week.

It's not like you're writing the regular expressions and lookup tables per hand. You write the routes in whatever format you deem nice and it's automatically translated from there ;)

You can use a lexer, yes - but any fast lexer implementation in a high-level language will actually use the very same technique described here. Generating a character-comparison + goto based FSM works great in C, but has bad performance in PHP (and other dynamic languages).

There's a common misconception that regular expressions are slow, but in many cases they offer much better performance than a manual implementation with lots of strpos etc. In the end PCRE does the same thing, but in C and using a JIT compiler. Apart from very simple cases you don't have a chance to keep up with that using PHP code.

You won't hit catastrophic backtracking problems with the types of regular expressions you need for routing.

Even if you do use some very weird expression, the worst that can happen is that you hit the backtracking limit and a route fails to match because of that. There won't be any code spinning indefinitely.

Did you read on to the end? I also had the problem that performance degraded with large route sets, but resolved it by matching in chunks of ten routes.

Not sure I understand this comment. Your code snippet uses named subpatterns, but not within a (?| group. The interesting question is whether you can combined those two. Without (?| you can use named captures in PCRE as well (there's just little point in this context as a non-named capture would do equally well and be more efficient.)

PCRE actually provides this information. There's a feature called backtracking control verbs, and one of those is (* MARK:NAME). You could put a (* MARK:A), (* MARK:B), etc at the end of every path and PCRE would tell you which of the paths was taken. However PHP does not expose this information - just like it does not expose the (?C) callout feature :(

Maybe I should implement those two things.

Note: There is no whitespace between * and MARK, but if I remove it HN formats it as an italic string.

To make sure you have proper context: With one or two exceptions, those proposals are just vague ideas of what we might want to do in PHP 6. It says very little about what will actually go in. Most of it won't, at least I dearly hope so - otherwise we wouldn't get a release in the next decade ;)

It's a common misconception. Many people don't understand that the normal string functions are perfectly safe on UTF-8, as long as you don't use hardcoded lengths or offsets. I.e. substr($str, 0, 50) is not safe due to the explicit "50" in there, but substr($str, 0, strpos($str, "foo")) will work correctly on any well-formed UTF-8.

If people have encoding issues in PHP it usually just means that they didn't manage to set up their database properly (you know, finding which one of the 10 encoding options in MySQL is the right one ;)

From my personal experience I've had a lot more issues with encoding in Python than I had in PHP - exactly because PHP ignores encoding and lets me deal with it.

Some languages make writing secure code easier than others. When it comes to web-related code of semi-good programmers, I'd conjecture that the amount of vulnerabilities is directly proportional to the amount of magic involved. Early PHP had lots of magic - things like register globals or magic quotes. By now no sane developer uses those things anymore (well, and they were removed). The plethora of recent Rails vulnerabilities was also caused by various magical behavior, especially in parameter parsing. (Actually, I'd expect modern Rails code to have more vulnerabilities than modern PHP code, because they still have a lot more magic involved.)

Please, if you do performance benchmarks, always run them with an opcode cache (PHP 5.5 + opcache would be the obvious choice). Without it your benchmark becomes completely meaningless. I also feel like HHVM devs should be aware of this, so likely the numbers are deliberately misleading.

Apart from that, having FastCGI support is of course nice.

Chances are good that there will be a PHP 6 release in the near future (~3 years?) that contains a non-trivial amount of BC breakage. At least the idea has gained some momentum recently. But no branch / timeline yet ;)

Imho the main thing C++ offers are cheap abstractions. In C++ you can easily build abstractions that do not have any runtime overhead at all. You can write beautiful and general code and still not sacrifice a single cycle for it. Go doesn't offer that, not in the least. As such I think that Go and C++ simple have a very small intersection when it comes to use-cases.

Not disagreeing there. Fast NFA implementations are very nice for matching the regular subset and falling back to a more general algorithm for the non-regular cases :)

> They can't be.

That's not exactly right. What "better" or "worse" here refer to is how much the advantage the attacker with specialized hardware has over you running on a standard server.

This advantage is largely dependent on how much memory the algorithm uses. The more memory, the better. In that regard the order is scrypt > bcrypt > PBKDF2.

More memory is better because this makes running on a graphics card or ASIC harder or nigh impossible.

Obligatory comment: Nowadays nearly nothing uses actually "regular" regexes, which is also the reason why regex engines are typically using backtracking and not Thompson NFAs.

For general-purpose applications (e.g. use in programming languages) people usually want a regex flavor with support for at least backreferences and typically also (recursive) subpattern references. Note: Adding support for backreferences makes matching regexes an NP-complete problem (as opposed to a simple linear-time algorithm without them).

(But of course, having fast NFA implementations for really-regular regexes is still useful. After all a large part of the regexes you typically write will not use backreference etc)

> Contrast this to PHP, where /e appears to be on by default and there's no mention of it whatsoever in the documentation, except in the change log to say it's deprecated in 5.5.

The preg_replace documentation says "Several PCRE modifiers are also available, including 'e' (PREG_REPLACE_EVAL), which is specific to this function" with a link to the PCRE modifiers page: http://de2.php.net/manual/en/reference.pcre.pattern.modifier.... This page has a bunch of warnings on the /e modifier :)

Generally putting user input into any regular expression function without running preg_quote over it first is a bad idea. Not just because of /e, but also various other issues, e.g. causing pathologically slow matches (DOS) or segfaults by deep recursion (DOS and maybe security relevant).

Yes, the fact that 0 is returned ~1% more often than other digits is very significant. E.g. if the generated random number stream were used for XOR encryption, then you could just collect a large number of encryptions of the same text, for each character look which one occurs most often and then that would be the encrypted character (because 0 has a bias and occurs most often and c XOR 0 == c).

Using other encryption methods the advantage is often not so obvious, but it exists. Also it should be noted that 1/250 is a pretty large bias and would probably not even need particularly many ciphertexts.

MT is not suitable for crypto because after observing 637 values you can predict all further values. 637 is the size of MTs internal state vector and the output of MT are basically just values from that state vector run through a tempering function. That tempering function is invertible, thus by looking at 637 values you get the full state vector, at which point you can generate the next values as usual.

Yes, of course in the end everything runs on machine code. That does not imply though that it is reasonable to write your web applications in machine code or assembly or C or C++.

I'm not arguing whether or not C++ is actually suitable for web development, I just don't think your line of argumentation makes sense.

crypt() is not extremely easy to use. Actually, it's fairly hard and easy to get wrong. The two things that people usually get wrong is a) salt generation and b) fixed-time comparison.

I'm seeing it too. Probably people have used domains like amazon.XYZ for phishing in the past.

> You can use the private repositories for anything you want.

Does that include using them for purposes that are not directly related to your education?

> PHP version 5.5 (not yet released) will support Bcrypt natively via its password_hash() function. Use it.

This makes it sound like PHP didn't support bcrypt before 5.5. It did. PHP always has bcrypt support in 5.3 and 5.4. In older versions it also has bcrypt support if the operating system supports it.

PHP 5.5 only added a wrapper around the low-level crypt() API, which makes password hashes more convenient to use and less prone to error.

I also come to the conclusion that Ruby-like languages are just not the right tool for this kind of problem, but it should be pointed out that you would have been able to solve the 10^14 data set easily, even with Ruby.

I was solving that problem with PHP and got it running reasonably fast (1s per range) for ranges up to around 10^60. PHP is probably faster than Ruby, but it's still in the same area.

The first trick you can use is that you don't have to go through all numbers between start and end, rather you can directly only traverse the palindromes (i.e. you will only have to increment one half of the integer).

The second trick is that only numbers consisting of 0s and 1s (and a 2 at the start/end or the middle) can satisfy the condition (exception: the number "3"). This further massively reduces the search space.

There are more criteria that you can use to narrow down the numbers to consider (e.g. the number of non-zero digits can't be greater than 9). But in the end, cracking the 10^100 range is probably not possible in a language like Ruby or PHP. Using something like C++ on the other hand it becomes a triviality.