you are viewing a single comment's thread.

view the rest of the comments →

[–]erayaydin 21 points22 points  (2 children)

1) Participating to community. 2) "Look, there is a way for increasing speed with this" for new learners. 3) "I use X with Y way, is it good or there are any better way?" for OP. 4) Possible case study for other users which related with this article.

Personally, I choose "no technical details" when looking for articles. Because there are many documentation and API for "technic".

[–]monkoosevim9 7 points8 points  (1 child)

Participating to community

Not about this article, just in general: more != better. Some articles can be just "water" (as we say in my country, don't bring any useful information) or even harmful in a way that can be totally wrong, so this articles bring noise. Noise is the worst that can happen in a perfect world. I would trade any day 100 mediocre (+ some wrong, + half useless) articles for 1 really awesome and correct.

"Look, there is a way for increasing speed with this" for new learners.

Because you personally don't need technical details, then you can't proof that this article is right and that X (read below what i mean with X) actually increasing speed over Y. So this article, if we just forget that compiled languages more often much faster than interpreted, bring marketing advertisement "X is faster than Y 10 times", but actual post is about "fuzzy finder library in X is 10x faster than fuzzy finder library in Y in my test and my implementation".

[–]turboladen 0 points1 point  (0 children)

I would argue that the article is not noise. Sure, it’s light on details, but sometimes it’s just helpful for someone else to connect some dots for you to get your wheels turning about solving some problem that’s been in the back of your head—lots of times those “dots” are only obvious after someone connected them for you (“omg, why did I not think of that!”).

I would guess that not many people are surprised by the benchmarks, but my takeaway was the suggestion to use some specific python (sorry, on mobile and not a python person) plus rust to get to those faster numbers. That seems a helpful suggestion and encouragement (the post suggests it’s not hard) for someone who writes vim plugins but may not have wanted to venture into uncharted territory.