No, that SIMD is good for string matching and Rust regex crate (written by burntsushi for 'ripgrep') makes very good use of it and is thus a nice library for implementing quick matchers.
Thanks for the kind words, but note that it is actually the other way around! I wrote ripgrep for the regex engine. ;-) The initial version of ripgrep was just a kind of benchmarking tool that I used for the regex engine.
Results from the benchmarks game suggests the performance of the Regex crate and calling PCRE2 from Python are about indistinguishable. The results also suggest CloudFlare could have achieved a 35% improvement using boring technology like the crusty old GCC.
PL evangelism and marketing are fine, but these blogs about Rust that come out 2-3 times a week and always make it to the HN or Lobsters front page seem a bit contrived.
You may feel this, but I find these articles to be a high-light of HN. Optimization adventures are stuff I learn from and actually use. That it's in Rust makes sense as it does offer new ways to do things (in this particular article, the Rust aspect wasn't particular important, but it's a follow up to one where it was).
C and C++ articles are ignored, though, which is where most high-performance work is done. This isn't an optimization article that incidentally mentions Rust. It's a Rust-evangelism article that incidentally mentions optimization. HN has been a dumping ground for Rust content marketers for almost a decade now.
Please see my reply to you downthread: https://news.ycombinator.com/item?id=24601088. You've broken the site guidelines badly and normally we'd be banning an account for doing this.
I don't see many such articles on HN, but is that because they are ignored, or because there aren't many submitted?
> This isn't an optimization article that incidentally mentions Rust. It's a Rust-evangelism article that incidentally mentions optimization
I'm not sure we read the same article - I don't use Rust, but I followed along with the article just fine. It seemed to me much more about SIMD and string matching algorithms
I'm sure that I'm not surprising you when I say that there are members of the Rust community, paid and otherwise, who brigade forums, like this one. You probably know a few by name.
I don't think "the people have spoken, and they want Rust!" I think you have a small number of very obsessive people who treat a programming language's popularity of all things as a crusade. JetBrains publishes the data from their developer surveys, and you can see the last one that very few people use Rust at all, and of those, very few, less than 1 in 8, have ever used it for actual work. If you look at surveys from previous years, you can see very little user retention. Why does nobody keep using the most-loved lang for more than a year?
Because it's just a sham, like how a decade ago everyone was 'learning' Haskell and writing blogs about Monads and how FP was the secret sauce for their next-big-thing. It's exhausting. We've had non-stop but-what-about-Rust since, what, 2011?
You've broken the site guidelines badly with this and other comments. That's a bannable offense on HN. I'm not going to ban you, because you've also posted quite good comments, but if you do this again, we will have to. Please review https://news.ycombinator.com/newsguidelines.html and stick to the rules.
Rust is at the top of the hype cycle heap these days. The programming language in that position always gets undue attention on internet forums. HN has seen it happen more than once over the years, including with Go, Node, and so on. Forum readers like to read about shiny newness, and it's natural to they want to read about languages they don't use yet, especially when they find them exciting and want to believe the "this time is different" story.
That bias may be a problem in the software world (I personally think it is), but it's not evidence of brigading, and you can't make up stories about that here, and particularly not attack others personally about it (https://news.ycombinator.com/item?id=24596207). If you think you're seeing actual evidence of manipulation, please follow the guidelines and email hn@ycombinator.com so we can investigate.
You probably could get same optimization in FORTRAN, but so what?
Rust is just a more modern, better and more approachable programming language than C and C++, and people care about it more and prefer to get their little system programming lessons in it.
Using the benchmark game to judge the performance of regex engines for a specific task for anything other than what the benchmark game is doing is a serious mistake.
And I say this as the person who wrote the only non-PCRE regex engine that appears in the top 20 entries of the regex-redux benchmark.
Besides, if people want to use PCRE2 from Rust, then it's as simple as using a crate (which I also wrote): https://docs.rs/pcre2
This is the brigading I'm talking about. Every thread anywhere on HN or lobsters where anyone gives Rust anything but blind praise, you , Klabnik, Skade, Matklad or one of the entourage write walls of text like lunatics.
Let it go. Even by your own reasoning, reading anything into the Cloudfront article would be a mistake, right? Yet, here it is on the front page. Dutifully upvoted.
Well, in this particular case it was hard. The used version of one our internal libraries didn't support Go 1.13, so we bumped its version, and that required some more dependencies brought in and updated, and then it turned out that the container with Go 1.13 was misconfigured so it literally had no access to that internal library, at all (something with Gitlab deploy keys...), so in a hurry we tried to vendor this internal library wholesale, and then there were some problems with gomod-ed libs and those without go.mod, and some linters had to be explicitly told to skip the 'vendor' directory (wtf), and...
And at this point, I just stopped digging down that rabbit hole and instead added
before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems.
Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?
This is not a simple redirection. cmd <(subcmd) is a bashism that redirects the output of command subcmd to something that looks like a regular file to command cmd. Command cmd receive a path at the place the <(subcmd) syntax is used. Different from cmd < f, which redirects the contents of file f to cmd's input.
Tangentially, the adage "strong opinions, weakly held" is nonsense. If you have a strong opinion, you look like a fool if you change your mind when evidence is shown to you.
It is much better to just stay humble. Show your insecurities and lack of knowledge openly and early, you'll be surprised to see how people reactions change from hostile/confrontational to outright helpful.
I've always been a fan of "strong opinions held weakly" and the rebuttals I read to it so far were, to me, weird straw man articles about assholes at work and not being one.
But your comment totally convinced me, thanks. There's no need for strong opinions, even when weakly held. It adds nothing.
Amazing how a few sentences can do more than entire blog posts sometimes.
>Amazing how a few sentences can do more than entire blog posts sometimes.
A long form article is more likely to try to make many points at the same time, some strong, some weak, some wrong ones.
Comments are usually short, making only one point. Furthermore they're sorted and filtered by popularity. This means that strong, pithy statements are displayed much more prominently.
I always interpret the "strong" part to mean "take ideas to their conclusion" or "don't do anything half-assed". I guess that's the beauty of these aphorisms: their validity is in the eye of the beholder.
I would argue it's possible to be serious about your convictions (i.e. take them to their conclusions), humble and open to being proven wrong.
I agree, I don't think anyone who changes their mind looks like a fool. But if you were humble before, you look great, and if you were (apparently) unreasonably confident, then you look good. The unfounded confidence adds little.
I was doing martial arts in school, and my sensei had me demonstrate some forms. Being new, I was very hesitant.
He was annoyed at this and explained that when I kept hesitating, I didn't complete a motion fully. He couldn't see what I was trying to do because I wouldn't commit to it. Thus he couldn't show me what I was doing wrong and teach me the correct way to do it.
"Strong opinions weakly held" is trying to address the problem of not committing to a position. It can manifest as not fully expressing your ideas, or adding unnecessarily qualifiers to them, or not following them to their conclusions.
The consequences can be you don't fully advocate your position, or someone with a different idea isn't able to identify the weaknesses in your argument.
> If you have a strong opinion, you look like a fool if you change your mind when evidence is shown to you.
If you present your views as mush, you can also sound like a fool. If you're citing a standard and say, "the standard says this, but I'm not really sure I read it correctly," you don't sound humble, you sound like you can't read.
If, otoh, you simply cite the standard, then your colleague is clear on where you're coming from. So now he can object that implementations don't follow it; the discussion can advance.
I think the problem you're getting at is someone staking their reputation unnecessarily on their views. You're right: that's a mistake. I've been in an argument over a fairly subjective design decision where one guy got frustrated and said, "look, my 20 years working with databases says we do it this way."
To avoid that, the key is to be specific; "we tried that on project X and it worked / didn't work, and this is very similar." Now it's not your reputation at stake, you're simply giving a factual account of your experience.
And sometimes the matter really is subjective or the data isn't great. If that's the case, you want to be clear about that uncertainty, "we just don't know because our data is crap." Then it becomes clear the team needs to put more resources into getting better information.
On the other hand, if you're too strong about how you phrase your case, some people will take you at face value and assume "he seems pretty sure about this, he's probably right". A little hedging in how you phrase things gives other people an easier-to-take opening to raise counterpoints without feeling like they're getting into an actual argument.
I once worked with a guy who had strong opinions during code review and changed them often (usually after reading blog). I hated working with him.
With people who have strong opinions and stick to them you can at least learn their opinions and adapt or fight once. If they change every week, you have to fight or adapt constantly. Last week you need to use x syntax wherever possible, this week you must not use it. And big deal about difference each time.
> I once worked with a guy who had strong opinions during code review and changed them often (usually after reading blog). I hated working with him.
> With people who have strong opinions and stick to them you can at least learn their opinions and adapt or fight once. If they change every week, you have to fight or adapt constantly. Last week you need to use x syntax wherever possible, this week you must not use it. And big deal about difference each time.
If they are constantly changing their opinions back and forth based on whatever blog they read most recently, those aren't strong opinions weakly held. They're just weak opinions, strongly advocated (or strongly enforced, depending on your co-worker's authority).
Also, if they are privileging opinionated blog posts over the arguments of their colleagues, the solution is simple: start a blog.
Another reason for people trying too look overly confident is when they are overly exposed over a certain topic.
For example, if you have very narrow job titles and roles in a team ("he is our DevOps, she is our architect"...) everyone will have to defend their role, often trying to sound infallible.
If instead you make the whole team responsible for all team tasks, everyone will be more open to leveraging everyone else's suggestions.
I really cannot agree with the "just use GET" suggestion. GET must not be used for actions that modify the data server-side. Also, POST and PUT means some action is or is not idempotent.
Using different methods than GET is easy in the browser (easier than JSON-P) and avoids a huge class of problems that come with abusing GET.
Yes, honestly this was written at a time when browsers (specifically, the XHR API) did not support non-GET requests reliably at all (e.g. pre-CORS), so there was no other option. (And once you publish an API, it's hard to change.) You're right that today there is better support for POST/PUT, although there might still be some issues lurking in the corners.
In a cross-domain context, when you are expecting the browser to make its XHR for JSON data via JavaScript to a third-party API. Think about making a call to the Flickr.com HTTP API from your own WordPress myblog.com domain. In that context, the XHRs didn't support POST/PUT. Remember, even the fetch() API is pretty recent. POST-based forms are irrelevant for API usage.
I dimly recall a pre-form web, but it could easily be they just took over a little-used Berners-Lee verb. (For instance, PUT support was atrocious for a while.)
This is not about pre-form web. It's about pre-CORS web. Which is pretty recent web. CORS was "widely & properly" supported by "recently released" browsers around 2012-2013. Of course it's only as of very recently that you could safely assume 2010-2013 browser versions were completely out of circulation.
My bad; hadn't parent'ed enough, and the "using different methods than GET" clarification would not have been anachronistic even in the previous century.
PUT can still be weird. For example, PHP doesn't process multipart/form-data if it's a PUT instead of a POST, I'm working on an API in Laravel and for methods that need to PUT a file I have to use Laravel's _method spoofing.
Agreed about the idempotency concern. Safari for example will sometimes make past GET requests while making a current GET request, so you can get oopsied if you put a non-idempotent request in a GET.
On the other hand, if multi submitting causes bad behavior, a failsafe should probably be baked in to the endpoint logic itself rather than relying on POST not being abused.
Languages that to green threads don't do them for memory savings, but to save on context switches when a thread is blocked and cannot run. System threads are scheduled by the OS, green threads my the language runtime, which saves a context switch.
Green threads are scheduled by the language runtime and by the OS. If the OS switches from one thread to another in the same process, there is no context switch, really, apart from the syscall itself which was happening anyway (the recv that blocks and causes the switch). At least not on Linux, where I've measured the difference.
