Not a single other implementation has feature-parity with Perl. Perl regexes are not only Turing-complete, but can also execute arbitrary code¹ as part of the regex evaluation.
PCRE is the pinnacle of deceptive advertising. It is emphatically not Perl-Compatible.
Source: I used to write Perl for a living, and I have battle scars from (¹) above.
When Sun released Java and went on a marketing road show, I drove to Chicago to hear the presentation. Since Perl was my favorite language, I had to ask about regular expression support; the Sun engineer said there wasn’t any, but I could build the first library.
To me, it was inconceivable that you could release a major language and not only not have regular expressions built into the language like Perl, but not even have it in the standard library. Crazy.
When I found out that Jonathan Locke had even a minimal Java implementation of a regex engine, I jumped on it and messaged him to open source it to the Jakarta project. Crazy that that was 20 years ago...
We did the same thing for Rust. Regexes are neither in the language nor in the standard library. Go doesn't have them in the language either (although they're in the standard library).
Sorry, early morning. I should have been more verbose.
Rust has a different target problem space, a different standard library philosophy, a package management system, and exists in a world where adding external dependencies is trivial.
Only really using macOS, so I wouldn't know. But that's great to hear! Maybe they will also catch up with trackpad technology at some point, the £150 Chromebook I tried was astonishingly good!
This, right here, is why I never use acronyms with the sixth letter of the English alphabet anywhere in them. Heck, as you might already have noticed, I don’t use said letter at all, unless it is part of a word.
This is one “human corner case” I have no shame working around. Wouldn’t want to convey hostility where none exists.
The F-word (I'll spare your virgin eyes), or even the letter F, is not capable of conveying hostility on it's own, so there is no sense in omitting it.
The acronym was coined with the non "fine" meaning for that letter. It was much later that internet culture got more polite and people retroactively replaced the meaning on RTFM and RTFA.
I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript. If a startup relies on JavaScript to keep out competition from C coders, well, too bad. They will be decimated in terms of performance. The web will be ruled by the best performing apps written in the language of the Linux kernel.
Performance in web apps is not a goalpost for everybody. While there's certainly web apps that are problematic in terms of performance, you're unlikely to be running at 100% CPU the whole time, so it's not like using C will be the right solution.
I can see how C/C++ (and, well, more likely Rust) will become a de-facto solution for when you need performance or some type of robustness to your apps (ie probably the right thing for Figma). But the potential performance improvement might be negligible on most makes, and unlikely to offset the fact that you'd be working off a completely different stack making things like debugging and inspecting much harder.
What I think is likely is that using WebAssembly will allow new types of web apps to become popular. Things like video encoders, image editors, etc. Things that you just wouldn't do with JS anyway, at least not in the heavy parts. Thing of a standard web app that uses ffmpeg on the background.
>Performance in web apps is not a goalpost for everybody.
But in 2017 startup and companies are starting to understand how fast response times (on a website/web-app) are of critical importance for gaining a good user base.
True, but in my experience bad UI response times are more related to something goddamned dumb like running a series of super expensive scroll events or watching DOM changes for some idiotic reason, more than about raw processing power.
A C solution might make the former faster, but it'd still be a dumb architecture. A cheaper solution than migrating your whole codebase to a separate language and build process is knowing how to deal with events and how to parallelize (or delegate) stuff correctly.
>I am a C coder, and I cannot wait to have my code on the web, decimating inferior languages like JavaScript.
Not only you but many, many programmers out there in other languages, wishing for more performance, or for a higher level of abstraction. I will brace myself for the amazing applications that will be built now for the web.
1. Focuses on memorable passwords, and restricts itself to fewer ASCII characters than rpg.
2. Makes no attempt to preserve entropy; waste of entropy is potentially unbounded. This is a performance concern when reading from /dev/random, and a security concern when reading from /dev/urandom.
3. Has large source code spread across multiple files. Good for reusability of components, not so good for auditability and security.
A command-line password generator that sources entropy from /dev/urandom (configurable in the source to /dev/random), generates printable ASCII passwords without whitespace, and preserves entropy with a guarantee to waste no more than 63 bits of entropy in a single invocation on most modern machines.
PCRE is the pinnacle of deceptive advertising. It is emphatically not Perl-Compatible.
Source: I used to write Perl for a living, and I have battle scars from (¹) above.