Rebar Alternatives

rebar reviews and mentions

• Go is my hammer, and everything is a nail
  24 projects | news.ycombinator.com | 12 Aug 2024

  The C#'s regex engine would have ran circles around Go's here though while doing so :)

  https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...

• Wc2: Investigates optimizing 'wc', the Unix word count program
  15 projects | news.ycombinator.com | 20 Jun 2024
• Regular Expression Matching Can Be Simple and Fast (2007)
  3 projects | news.ycombinator.com | 21 May 2024

  There's pretty wide variety in the performance of regular expressions between different languages, and good implementations will often recognize when your regular expression has a literal suffix/prefix, and optimize accordingly.

  That doesn't help you if you're stuck using a library that doesn't perform those optimizations, but it means you need to be careful about importing your assumptions about regex performance from one language to another.

  See also: https://github.com/burntSushi/rebar

• Needle: A DFA Based Regex Library That Compiles to JVM ByteCode
  3 projects | news.ycombinator.com | 8 May 2024

  The set of regex engines being compared here is pretty small, and even among backtracking regex engines, Java's is pretty slow. See: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...

  The backtracking engines ahead of are pcre2/jit, javascript/v8, d/ldc/std-regex (technically a hybrid I believe) and regress. Java's engine is about on par with Python's and Perl's (which are both written in C).

• Knuth–Morris–Pratt Illustrated
  2 projects | news.ycombinator.com | 16 Apr 2024

  https://github.com/BurntSushi/rebar

  For regex, you can't really distill it down to one single fastest algorithm.

  It's somewhat similar even for substring search. But certainly, the fastest algorithms are going to be the ones that make use of SIMD in some way.

• Regex character "$" doesn't mean "end-of-string"
  1 project | news.ycombinator.com | 20 Mar 2024

  I'll add two notes to this:

  * Finite automata based regex engines don't necessarily have to be slower than backtracking engines like PCRE. Go's regexp is in practice slower in a lot of cases, but this is more a property of its implementation than its concept. See: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa... --- Given "sufficient" implementation effort, backtrackers and finite automata engines can both perform very well, with one beating the other in some cases but not in others. It depends.

  * Fun fact is that if you're iterating over all matches in a haystack (e.g., Go's `FindAll` routines), then you're susceptible to O(m * n^2) search time. This applies to all regex engines that implement some kind of leftmost match priority. See https://github.com/BurntSushi/rebar?tab=readme-ov-file#quadr... for a more detailed elaboration on this point.

• Re2c
  4 projects | news.ycombinator.com | 22 Feb 2024

  They are extremely fast too: https://github.com/BurntSushi/rebar?tab=readme-ov-file#summa...

• C# Regex engine is now 3rd fastest in the world
  3 projects | news.ycombinator.com | 31 Dec 2023

  I love the flourish of "in the world." I had never thought about it that way. Which makes me think if there are any regex engines that aren't in rebar that could conceivably by competitive with the top engines in rebar. I do maintained a WANTED list of engines[1], but none of them jump out to me except for maybe Nim's engine.

  Of course, there's also the question of whether the benchmarks are representative enough to make such extrapolations. I don't have a good answer for that one. All models are wrong, but, some are useful.

  [1]: https://github.com/BurntSushi/rebar/blob/96c6779b7e1cdd850b8...

• Ugrep – a more powerful, ultra fast, user-friendly, compatible grep
  27 projects | news.ycombinator.com | 30 Dec 2023

  I'm the author of ripgrep and its regex engine.

  Your claim is true to a first approximation. But greps are line oriented, and that means there are optimizations that can be done that are hard to do in a general regex library.

  If you read my commentary in the ripgrep discussion above, you'll note that it isn't just about the benchmarks themselves being accurate, but the model they represent. Nevertheless, I linked the hypergrep benchmarks not because of Hyperscan, but because they were done by someone who isn't the author of either ripgrep or ugrep.

  As for regex benchmarks, you'll want to check out rebar: https://github.com/BurntSushi/rebar

  You can see my full thoughts around benchmark design and philosophy if you read the rebar documentation. Be warned though, you'll need some time.

  There is a fork of ripgrep with Hyperscan support: https://sr.ht/~pierrenn/ripgrep/

• Translations of Russ Cox's Thompson NFA C Program to Rust
  3 projects | news.ycombinator.com | 2 Nov 2023
• A note from our sponsor - SaaSHub
  www.saashub.com | 9 Oct 2024

  SaaSHub helps you find the best software and product alternatives Learn more →